CLOUDBOT-2: Первый облачный бот для торговли на Binance, ByBit, Poloniex, Exmo, Bitmex, Huobi, Kucoin, OKX. Теперь с фьючерсами на Binance и ByBit.

[izlevinv]

а у меня пашет на поло и не жужжит...
UPD: забыл по голове дереву постучать, пофиксил.

Изменено 10 июн 2017, 22:50 пользователем izlevinv

[kotiki]

@xcyr, таки да, у меня бот №14 на поло. Посмотрел за сегодня логи, всё те же 1-2 минуты на 10 ордеров весь день

Может это приколы поло? Например понижает приоритет тех апи кто много запросов делает, я смотрю у всех кто жалуется от 20 до 40 ордеров выставляется

У izlevinv тоже быстро бот на поло работает, он вчера свои логи выкладывал в соседней теме. 21 ордер за 3 минуты.

а у меня пашет на поло и не жужжит...

UPD: забыл по голове дереву постучать, пофиксил.

какой номер у вашего бота на поло?

[Evgeny Pozharsky]

По поло, из чего складывается задержка:

1) В нормальном режиме поло ограничивает количество запросов с одного IP до 6 в секунду. Это написано у них в доках, иначе - бан. Бот ограничивает количество запросов в секунду для поло на меньшем уровне (что-то около 4, сейчас не помню). Эти ограничения видны в логах как сообщения "Waiting next call window...". Эти задержки совсем небольшие, вы можете видеть в логах (всегда меньше секунды).

2) Ожидание ответа на HTTP запрос. Это обязательная часть протокола, в ответе мы получаем результат операции. Между запросом и ответом биржа исполняет ваши команды. В нормальном режиме здесь теряется до нескольких секунд. А вот во время перегрузки полоникса здесь может теряться много времени, вплоть до таймаута транспортного уровня (что тоже бывает).

3) Во время перегрузки поло ограничивает количество вызовов с одного IP по другой схеме. Фильтр стоит не на самом поло, а на уровне сервиса хоста (cloudflare). Этот фильтр работаем по нелинейному алгоритму (я не выяснил методом тыка, по какому). Половский сервис сказал, что он считает сколько ответов приходит от поло со статусом 4хх для этого IP и если много - банит его. Это логично для защиты от аттак (пустых и левых запросов). Но это работает как-то странно. Например, когда включен этот фильтр, можно зайти на сайт поло, нажать подрят раз 5 "обновить страницу" и получить бан на свой IP. Здесь время бана - 10 минут. Такие ситуации тоже видно в логах, что-то типа "сервер попросил подождать еще столько то".

 

Вот как-то так.

 

Да, когда бот что-то делает, он посылает довольно много запросов - не все видны в логах. Например, он может проверять реальный баланс, запрашивать у биржи точность округления цены, минмальные объемы ордеров, текущую комиссию пользователя и так далее.

Изменено 11 июн 2017, 05:26 пользователем Evgeny Pozharsky

[Evgeny Pozharsky]

Kraken доступен.

 

ВНИМАНИЕ! Не знаю, как там дальше пойдет, но вчера вечером кракен тупил не хуже полоникса. И даже TabTrader постоянно отключался.

[JpS]

@Evgeny Pozharsky, скажите пожалуйста, _все_ боты ходят с одного ИП или все же разеление на bot1,2,3... - это и есть желание дать какждой группе пользователей отдельный ИП адрес? но даже если и так, подтвердите (или опровергните) тот факт что даже в пределах одного botX есть _несколько_ пользователей вашего бота. ведь верно? у вас ведь явно не 10-15 пользователей _всего_. просто тогда получается что лимиты на количество вызовов с одного ИП "шарятся" между пользователями и чем больше пользователей (в какой-то пик их может быть больше чем в более спокойное время) - тем больше паза между запросами (как лично ваша по п.1, так и CF-ная по п.3).

если так, то наверное надо провести суммарную диагностику со всех аккаунтов и посчитать эти простои и оценить их процент от всех простоев. если это значительная цифра, то "надо что-то с этим делать".

 

кстати, я думаю, что это не единственные грабли, на которые мы наступили. количество пользователей вашего бота растет (я сам являюсь адептом и распространителем идеи мао бота в массы в определенных кругах) и когда то мы упремся в потолок еще где-нибудь, кроме поло.

 

моя идея, о которой я намекал выше, заключается в том, что бота надо разделить на две части, протокольную (что шлет запросы на АПИ бирж) и алгоритмическую (собственно самого бота). протокольная часть может размещаться на каких-то отдельных серверах, причем во многих случаях эту часть "хостить" могли бы сами пользователи бота (вот у меня например вполне хватает ресурсов на это), но для тех кто это сделать не в состоянии (по уровню технической подготовленности например ну или по финансовым соображениям), для них можно предоставлять услугу хостинга. я думаю вы очень хорошо договоритесь с каким-то хостингом, который вам позволит реселить какие-то виртуальные хостинги. он будет только рад и еще вам бонусов каких-то за это навешает.

в простейшем случае эта протокольная часть могла бы быть банальным прокси сервером или тунелем, но такой подход введет дополнительную задержку (но тут надо смотреть, если дополнительная задержка будет 1 секунда, но зато ордера будут выставлять не за полчаса, а за одну минуту, то я думаю что задержку в протоколе в 1 сек мы переживем как-то :) ). а в более сложном (требующем дополнительной разработки) "протокольная" часть будет общаться с алгоритмической на каком-то собственном протоколе. например это вполне может выглядеть как макро-команды вида "снять всю сетку", "выставить сетку ордеров с такой-то позиции по такую", "проверить актуальность всех ордеров" и т.п., что значительно уменьшит количество обращений между "ядром" бота и "прокладкой".

[JpS]

@pitbred, речь ни капли не о ресурсах, а о _выделенных_ ИП. сколько бы серверов у евгения не было, их явно не столько, сколько у него пользователей :) хотя конечно же если это так, то снимаю шляпу конечно же, но что-то мне подсказывает что с таким альтруизмом он вряд ли смог бы предоставлять услуги по тем ценам, которые есть. и даже если предположить что у евгения выкуплены пулы адресов целыми сетями, то вполне вероятен бан на целую сеть (в моей жизни неоднократно встречались подобные случаи), когда идет массовый поток запросов из одной сети, хоть даже и с разных ИП.

 

по трафику тоже разговор не по пропускной способности канала (мы чай не тьюб-хостинг обсуждаем), а о времени отклика, что гораздо важнее в обсуждаемой теме.

[JpS]

@pitbred, вы меня видимо не слышите или даже не пытаетесь. я для этого и рекомендую разнести протокольную часть от ядра. протокольная часть может хоститься даже не в пределах сервера на отдельном интерфейсе, мало того, она может быть вообще _на другом_ сервере, с ИП _по определению_ уже другим. или эта часть может быть вообще (о боже, такое возможно? /сарказм/) в пределах другого ДЦ (к примеру например совсем рядом в ДЦ сервера _конкретной_ биржи.

 

ну а уж изменить исходящий адрес на одном сервере при наличии нескольких ИП, я думаю, евгений в состоянии и без всяких разных джейлов и вируалок.

правда же, @Evgeny Pozharsky?

например как-нибудь так:

https://stackoverflow.com/questions/335607/how-do-i-make-an-outgoing-socket-to-a-specific-network-interface

задача в общем-то для олимпиады по информатике 3 класс, вторая четверть /сарказм/ :)

[JpS]

 

 

Если биржа тупит

если биржа тупит по причине лимита запросов с одного ИП, то разнесение протокольной части на каждого клиента в разные сервера, дц и прочие технические способы, кардинальным образом решает эту проблему.

если протокольную часть клиента, торгующего на битфайнексе воткнуть с один дц с битфанексом, а протокольную часть клиента торгующего на бтц-е - в ДЦ бтце, то каждый из них получит максимально быстрый отклик для своей биржи. ну и уникальный ИП (!!!), лимит по запросам с которого будет только в пределах одного клиента, а не всех клиентов евгения, ходящих с одного (или нескольких, но ограниченно количества) адресов ИП.

 

как тут уже писали выше. люди отмечают тот факт что в моменты когда бот тормозит, биржа через веб интерфейс работает нормально, т.е. клиент со своего ИП не имеет проблем с таймаутами, а с ИП серверов евгения - имеет. и повторюсь,  дело не в том что у евгения сервера плохие или какие-то некошерные. дело все в том, что МЫ ВСЕ ломимся на одну и туже биржу с одного адреса.

[Nojozap]

если быть точным то с одного айпи ломятся те кто сидят на одном боте. У бот 1 и бот 2 айпи будут разными все-таки.

На  отдельном впс скорость выставления и снятия ордеров действительно выше, но все равно крайне низкая в сравнении с теми же биттрексом или бтце. 

[JpS]

@Nojozap, ну я не пытаюсь защитить поло в данном треде. то что с ним проблемы есть - это факт и он отражается не только ботом евгения. многие жалуются.

но вот ваша информация что на выделенном ВПС бот работает пободрее - вот это мне уже интересно услышать. о чем я и писал: неплохо бы собрать статистику по "туплению" и попробовать выявить закономерность.

[Evgeny Pozharsky]

Так, по порядку.

 

- у каждого бота свой IP, каждый бот обслуживает несколько пользователей (не много)

- тормоза полоникса на стороне их сервера, канал тут не при чем абсолютно => не имеет значения, где сидит вызывающая сторона территориально

- API полоникса и веб-морда полоникса - независимые сервисы. Один может работать, второй в это время тупить.

- лимит на количество запросов у полоникса всегда одинаковый, он не зависит от нагрузки.

- во время перегрузок полоникс может ДОПОЛНИТЕЛЬНО отключать клиентов по только ему понятному (хотя и в этом я сомневаюсь) алгоритму. Это не влияет на тормоза, потому что после срабатывания такого бана все дружно ждут 10 минут (это видно по логам бота, он так и пишет в логи - жду).

 

Ну и все же помнят про февральские случаи возврата неверных данных от полоникса? Проблема тут гораздо глубже.

[JpS]

 

 

- лимит на количество запросов у полоникса всегда одинаковый, он не зависит от нагрузки.

 

а от ИП? этот лимит исчисляется на ИП или на клиента (ключ)? или вообще один на весь мир?

 

 

Это не влияет на тормоза, потому что после срабатывания такого бана все дружно ждут 10 минут (это видно по логам бота, он так и пишет в логи - жду).

т.е. при бане одного _из ваших_ клиентов, банят _всех_ ваших клиентов, так?

а если потенциальный клиент будет не на вашем сервере, а где-то в другом месте, его тоже забанят вместе со всеми вашими клиентами?

[Evgeny Pozharsky]

а от ИП? этот лимит исчисляется на ИП или на клиента (ключ)? или вообще один на весь мир?

 

Честно - не знаю, но это не столь важно, посколько с одного бота одновременно работает не более десятка пользователей. Плюс они между собой не синхронны, работают вразнобой. Поэтому задержки по этой причине несущественны. Вы их видите у себя в логах как "waiting for next call window". Можете посмотреть, сколько там времени тратится на ожидание.

а от ИП? этот лимит исчисляется на ИП или на клиента (ключ)? или вообще один на весь мир?

 

 

т.е. при бане одного _из ваших_ клиентов, банят _всех_ ваших клиентов, так?

а если потенциальный клиент будет не на вашем сервере, а где-то в другом месте, его тоже забанят вместе со всеми вашими клиентами?

 

Банят только адрес одного бота. Второе предложения не понял.

[JpS]

 

 

Поэтому задержки по этой причине несущественны.

вот этого ответа мне достаточно. меня интересовала существенность этой задержки _по сравнению_ со всеми остальными задержками. как я писал, если бот (биржа) тупит 30 минут и 1 секунду из них по причине лимита ИП, то понятно дело что за 1 секундой гоняться не стоит. я же не знаю сколько это число _в среднем_ по всей системе. у меня в логах - это только то что теряет лично мой бот, а сколько теряют все вместе - мне по моим логам не посмотреть.

 

 

Банят только адрес одного бота. Второе предложения не понял.

тут мне тоже в общем уже вашего ответа хватает и хоть и объяснять мое предложение не нужно, я все же поясню чтобы не быть непонятым.

если несколько клиентов сидят на одном боте (ИП) и одного из этих клиентов банят, то банят всех кто сидит на _этом_ боте. вы ответили своим ответом - да.

я в своем предложении выразил мысль, что если бы клиент сидел на _другом_ боте (другом сервере, в другом ДЦ и пр.), то он бы _той же самой_ ситуации не был бы забанен. и из вашего ответа естественно следует - нет, он не был бы забанен. т.е .мне ясен ваш ответ.

[Evgeny Pozharsky]

вот этого ответа мне достаточно. меня интересовала существенность этой задержки _по сравнению_ со всеми остальными задержками. как я писал, если бот (биржа) тупит 30 минут и 1 секунду из них по причине лимита ИП, то понятно дело что за 1 секундой гоняться не стоит. я же не знаю сколько это число _в среднем_ по всей системе. у меня в логах - это только то что теряет лично мой бот, а сколько теряют все вместе - мне по моим логам не посмотреть.

 

А зачем вам сумма всех задержек? Боты работают полностью параллельно. То, сколько параллельно работает ботов, на вас никак не влияет, кроме того, что у вас могут появлятся задержки ожидания следующего доступного окна вызова биржи (это как раз место синхронизации всех виртуальных ботов в рамках одного физического), которые вы как раз видите.

[JpS]

 

 

А зачем вам сумма всех задержек?

не сумма, а процент от общего времени задержки. т.е. если скажем этот процент существенен, то это мне интересно. если бы я "жил" отдельно от всех этих людей - стало бы мне лучше или нет? (предположение гипотетическое, я знаю что это технически не возможно _сейчас_).

это как с шаред хостингом. сидим мы на одном сервере с другим клиентом. у него 200 тыс посетителей в день, а у меня 10 (штук) и у обоих блог на вордпресе. и у меня не работает форма загрузки фотографий потому что общая нагрузка на сервер велика. а у клиента с 200к трафика нет формы загрузки фотографий и его это не беспокоит. ваши же клиенты имеют разные настройки, разное количество обращений, разные объемы транзакций и пр. может быть один из клиентов вашего бота номер Х приводит к тому что остальных 10 клиентов банят вместе с ним по причине лимита его запросов. не думаю что остальных 10ти клиентам это будет приятно узнать :)

но вы отвечаете что это число (процент) незначительно. если так, то вопрос конечно же снимается.

[kotiki]

не сумма, а процент от общего времени задержки. т.е. если скажем этот процент существенен, то это мне интересно. если бы я "жил" отдельно от всех этих людей - стало бы мне лучше или нет? (предположение гипотетическое, я знаю что это технически не возможно _сейчас_).

это как с шаред хостингом. сидим мы на одном сервере с другим клиентом. у него 200 тыс посетителей в день, а у меня 10 (штук) и у обоих блог на вордпресе. и у меня не работает форма загрузки фотографий потому что общая нагрузка на сервер велика. а у клиента с 200к трафика нет формы загрузки фотографий и его это не беспокоит. ваши же клиенты имеют разные настройки, разное количество обращений, разные объемы транзакций и пр. может быть один из клиентов вашего бота номер Х приводит к тому что остальных 10 клиентов банят вместе с ним по причине лимита его запросов. не думаю что остальных 10ти клиентам это будет приятно узнать :)

но вы отвечаете что это число (процент) незначительно. если так, то вопрос конечно же снимается.

Может попробовать всем пользователям поло, например, на гугл диске создать и вести несколько дней статистику в одном файле с общим доступом на редактирование. Записываем ник, номер бота, дату, время начала цикла, кол-во ордеров, время выставления. Так мы хотя бы поймем зависит ли задержка от конкретного бота с индивидуальным айпи. А дальше уже можно разбираться по какому принципу поло создает проблемы конкретным ботам.

Есть желающие?  :)

Изменено 11 июн 2017, 15:25 пользователем kotiki

[amnesiac]

Евгений. здравствуйте! Довольно долго не приходит письмо с подтверждением регистрации. Скажите, с чем это связано и в какие сроки ожидать письма?

[Evgeny Pozharsky]

не сумма, а процент от общего времени задержки. т.е. если скажем этот процент существенен, то это мне интересно. если бы я "жил" отдельно от всех этих людей - стало бы мне лучше или нет? (предположение гипотетическое, я знаю что это технически не возможно _сейчас_).

это как с шаред хостингом. сидим мы на одном сервере с другим клиентом. у него 200 тыс посетителей в день, а у меня 10 (штук) и у обоих блог на вордпресе. и у меня не работает форма загрузки фотографий потому что общая нагрузка на сервер велика. а у клиента с 200к трафика нет формы загрузки фотографий и его это не беспокоит. ваши же клиенты имеют разные настройки, разное количество обращений, разные объемы транзакций и пр. может быть один из клиентов вашего бота номер Х приводит к тому что остальных 10 клиентов банят вместе с ним по причине лимита его запросов. не думаю что остальных 10ти клиентам это будет приятно узнать :)

но вы отвечаете что это число (процент) незначительно. если так, то вопрос конечно же снимается.

Вот вам охота в тех подробности погрузиться :)

 

Сравнение с хостингом вордпресса некорректно, потому как количество юзеров на одном боте ограничивается не мощностью сервера, а именно нагрузками на биржи. Сам по себе один бот может не напрягаясь тянуть в сотни раз больше ботов. Но вот тогда будут задержки из-за большого количества юзеров на одном IP (и то не на всех биржах). Реальная загрузка серверов с ботом - меньше 1-2 процентов.

 

Вот пример сейчас, не знаю чей бот:

 

 

INFO  [2017-06-11 18:55:25,726] DownExecutor-7DODQ0AP-7738XJRS-K1TCGQML-73HUE74C: Use percentage depo value: 0.2765913600 DASH

INFO  [2017-06-11 18:55:25,730] DownExecutor-7DODQ0AP-7738XJRS-K1TCGQML-73HUE74C: Create macro order 0.00835600DASH@0.06629982BTC

INFO  [2017-06-11 18:55:36,864] DownExecutor-7DODQ0AP-7738XJRS-K1TCGQML-73HUE74C: Create macro order 0.00877400DASH@0.06699771BTC

INFO  [2017-06-11 18:55:39,806] DownExecutor-7DODQ0AP-7738XJRS-K1TCGQML-73HUE74C: Wait for next call window for 345 ms

INFO  [2017-06-11 18:55:40,592] DownExecutor-7DODQ0AP-7738XJRS-K1TCGQML-73HUE74C: Create macro order 0.00921200DASH@0.06769560BTC

INFO  [2017-06-11 18:55:42,188] DownExecutor-7DODQ0AP-7738XJRS-K1TCGQML-73HUE74C: Create macro order 0.00967300DASH@0.06839349BTC

INFO  [2017-06-11 18:55:55,616] DownExecutor-7DODQ0AP-7738XJRS-K1TCGQML-73HUE74C: Create macro order 0.01015700DASH@0.06909139BTC

INFO  [2017-06-11 18:55:56,926] DownExecutor-7DODQ0AP-7738XJRS-K1TCGQML-73HUE74C: Create macro order 0.01066500DASH@0.06978928BTC

INFO  [2017-06-11 18:55:58,810] DownExecutor-7DODQ0AP-7738XJRS-K1TCGQML-73HUE74C: Wait for next call window for 147 ms

INFO  [2017-06-11 18:55:59,358] DownExecutor-7DODQ0AP-7738XJRS-K1TCGQML-73HUE74C: Create macro order 0.01119800DASH@0.07048717BTC

INFO  [2017-06-11 18:56:00,878] DownExecutor-7DODQ0AP-7738XJRS-K1TCGQML-73HUE74C: Create macro order 0.01175800DASH@0.07118506BTC

INFO  [2017-06-11 18:56:04,165] DownExecutor-7DODQ0AP-7738XJRS-K1TCGQML-73HUE74C: Create macro order 0.01234600DASH@0.07188296BTC

INFO  [2017-06-11 18:56:04,620] DownExecutor-7DODQ0AP-7738XJRS-K1TCGQML-73HUE74C: Wait for next call window for 43 ms

INFO  [2017-06-11 18:56:05,030] DownExecutor-7DODQ0AP-7738XJRS-K1TCGQML-73HUE74C: Create macro order 0.01296300DASH@0.07258085BTC

INFO  [2017-06-11 18:56:17,415] DownExecutor-7DODQ0AP-7738XJRS-K1TCGQML-73HUE74C: Wait for next call window for 36 ms

INFO  [2017-06-11 18:56:27,218] DownExecutor-7DODQ0AP-7738XJRS-K1TCGQML-73HUE74C: Create macro order 0.01361100DASH@0.07327874BTC

INFO  [2017-06-11 18:56:29,610] DownExecutor-7DODQ0AP-7738XJRS-K1TCGQML-73HUE74C: Create macro order 0.01429200DASH@0.07397664BTC

INFO  [2017-06-11 18:57:46,010] DownExecutor-7DODQ0AP-7738XJRS-K1TCGQML-73HUE74C: Wait for next call window for 302 ms

INFO  [2017-06-11 18:57:56,776] DownExecutor-7DODQ0AP-7738XJRS-K1TCGQML-73HUE74C: Create macro order 0.01500600DASH@0.07467453BTC

INFO  [2017-06-11 18:58:00,999] DownExecutor-7DODQ0AP-7738XJRS-K1TCGQML-73HUE74C: Create macro order 0.01575600DASH@0.07537242BTC

INFO  [2017-06-11 18:58:31,730] DownExecutor-7DODQ0AP-7738XJRS-K1TCGQML-73HUE74C: Create macro order 0.01654400DASH@0.07607031BTC

INFO  [2017-06-11 18:58:32,134] DownExecutor-7DODQ0AP-7738XJRS-K1TCGQML-73HUE74C: Wait for next call window for 94 ms

INFO  [2017-06-11 18:58:42,327] DownExecutor-7DODQ0AP-7738XJRS-K1TCGQML-73HUE74C: Create macro order 0.01737100DASH@0.07676821BTC

INFO  [2017-06-11 18:58:44,363] DownExecutor-7DODQ0AP-7738XJRS-K1TCGQML-73HUE74C: Create macro order 0.01824000DASH@0.07746610BTC

INFO  [2017-06-11 18:59:47,700] DownExecutor-7DODQ0AP-7738XJRS-K1TCGQML-73HUE74C: Create macro order 0.01915200DASH@0.07816399BTC

INFO  [2017-06-11 19:00:00,286] DownExecutor-7DODQ0AP-7738XJRS-K1TCGQML-73HUE74C: Create macro order 0.02011000DASH@0.07886188BTC

INFO  [2017-06-11 19:00:42,244] DownExecutor-7DODQ0AP-7738XJRS-K1TCGQML-73HUE74C: Create macro order 0.02111500DASH@0.07955978BTC

INFO  [2017-06-11 19:00:57,921] DownExecutor-7DODQ0AP-7738XJRS-K1TCGQML-73HUE74C: DONE.

INFO  [2017-06-11 19:01:57,933] DownExecutor-7DODQ0AP-7738XJRS-K1TCGQML-73HUE74C: There are 20 macro orders and 0 fix orders found in database.

 

Таблица выставилась за 7 минут, при этом задержка из-за ограничения количества вызовов составила чуть меньше 1 секунды. Вот о чем я говорю, ограничение количества запросов за единицу времени совершенно несущественно затормаживает бот. Можно пренебречь.

А вот конкретные запросы биржа обрабатывала долго. Между созданием ордеров нет никаких промежуточных запросов. То есть как только создание текущего ордера закончилось - сразу создается следующий. Видно, что некоторые ордера биржа выставляла более минуты. То есть это время между отсылкой команды на создание ордера и получением ответа от биржи.

Так же здесь видно, что время создания ордеров сильно плавает. В этом же цикле есть ордера, созданные меньше чем за 2 секунды. То есть скорость обработки ордеров меняется на порядки хаотично, что говорит о том, что это не затормаживание конкретного IP адреса или ключа, а нестабильность отклика сервера биржи.

Евгений. здравствуйте! Довольно долго не приходит письмо с подтверждением регистрации. Скажите, с чем это связано и в какие сроки ожидать письма?

Все должно работать, гляньте может в спаме. Приходит сразу после регистрации.

[JpS]

Таблица выставилась за 7 минут, при этом задержка из-за ограничения количества вызовов составила чуть меньше 1 секунды. Вот о чем я говорю, ограничение количества запросов за единицу времени совершенно несущественно затормаживает бот. Можно пренебречь.

собственно все что мне и требовалось знать :)

и вы мне как автор бота (и его логов) мне это разъяснили.

по логам есть еще один вопрос (возник прямо сейчас):

вот я вижу что между началом создания одного ордера и началом создания следующего есть время. значительное. вы объяснили откуда оно берется. бот _последовательно_ выставляет ордера и пока не выставится один ордер, не начинает выставлять другой. а параллельно не будет работать выставление ордеров? т.е. если из нескольких потоков сразу пробовать устанавливать 20 ордеров, а не 20 раз подряд выставлять и ждать ответа. возможно такое технически вообще? как со стороны биржи, так и со стороны алгоритма работы бота.

Изменено 11 июн 2017, 19:42 пользователем JpS

[izlevinv]

Я фанат @JpS, - где-то выше приводил тебя в пример, как человека, умеющего самостоятельно мыслить.
Приведу еще раз - побольше бы таких людей, которые пытаются понять все до конца.
Там еще полтора шага и свой бот будет написан

[JpS]

@izlevinv, на самом деле свой бот есть. он занимается другими делами и он арбитражный бот. там другие принципы вообще. ну а главное его качество - он состоит (пока) весь из костылей :)

продукт евгения можно назвать продуктом и он мне интересен вплоть до того что я его использую и оплачиваю. себя конкурентом ему не считаю, ибо мы не пересекаемся ни по логике (здесь бот торговый, у нас - арбитражный), ни по маркетнигу (мы не продаем бота и не сдаем в аренду и никаким другим образом не предоставляем услуг, он только для личного пользования).

 

посему мне очень интересно обсуждать и "быть в тренде", в группе единомышленников. поэтому я наверное настолько и погружаюсь в детали, изредка докучая обычным пользователям в этой ветке.

[dikanevn]

Тут кто то писал про возможность выбора профита в разных фикс ордерах. Так вот это можно настроить(на уменьшения профита хотябы) с помощью выставления профита числом, а не процентом. Если мы с первого ордера суммой 50$ продаём с профитом 1$ - это 2 %. А если с последнего к примеру 1000$ депо - это 0.1% профита. Чем больше волна, тем меньше шанса с отскоком остаться инвестором.  Разве что сейчас этот параметр (на шорте точно) не работает, он криво считает предпросмотр, Евгений обещал посмотреть, ошибка такая, важная всё таки.

И ещё этот профит нельзя поставить меньше двух знаков после запятой. для битка 0.01 это очень много, не знаю, исправили ли с обновлением.

П.С. всю ветку дочитал, думал не осилю DDD

Изменено 11 июн 2017, 21:38 пользователем dikanevn

[Evgeny Pozharsky]

собственно все что мне и требовалось знать :)

и вы мне как автор бота (и его логов) мне это разъяснили.

по логам есть еще один вопрос (возник прямо сейчас):

вот я вижу что между началом создания одного ордера и началом создания следующего есть время. значительное. вы объяснили откуда оно берется. бот _последовательно_ выставляет ордера и пока не выставится один ордер, не начинает выставлять другой. а параллельно не будет работать выставление ордеров? т.е. если из нескольких потоков сразу пробовать устанавливать 20 ордеров, а не 20 раз подряд выставлять и ждать ответа. возможно такое технически вообще? как со стороны биржи, так и со стороны алгоритма работы бота.

 

Надо проверять, разрешит ли биржа параллельно для одного ключа запросы присылать. Там много нюансов. В боте конечно можно так сделать технически, но это бессмысленно логически - он сейчас в параллели ставит ордера других пользователей.

[Fireglow]

ERROR [2017-06-12 06:24:13,187] Executor-ZP3FPPHS-R42VATMT-T8QTEP9F-VO2VGG66: Can not get active orders with message: Nonce must be greater than 1497200858359. You provided 561001012. (HTTP status code: 422)

Добрый день. Подскажите как это интерпретировать? В чем может быть проблема? (кроме проблемы с моим скудным мозгом)