АЛГОтрейдинг | ALKO трейдинг | CRYPDE | HFT

Пополнение в словарь алготрейдера миньйон = стратежка с очень маленькой капибарой (капиталом) by @nirtik #glossary

Найден самый тупой баг ever (хотя нет, были и по-хуже) 1. У меня симулятор устроен по пессимистичному сценарию: то есть в live должно быть НЕ хуже чем на симуляторе. Я так специально сделал. 2. Но иногда бывают дни, когда симулятор говорит что будет $ PNL, а в реальности на этом же volume получается почти в 2 раза ниже. 3. Ну и вот вам баг: в симуляторе PNL тупо множится на два. Ахаха! 4. Конечно там не настолько тупо, вот вам чуть подробностей: симулятор оперирует капиталом, на вход поступает переменная capital=10_000 USDT, и симулятор начинает свою магию. Но есть if, который говорит как вести себя на спотовом рынке, а как на фьючерсном. Потому что 10К капитала на фьючах позволяют набирать позицию -10K...+10K, а на споте только 0..+10K. Ну и в итоге я симулировал спотовые рынки по правилам фючей, а фьючерсные по правилам спота. А для спота это почти равносильно что я умножаю капитал на два. Раунд! #bugchain

прислал @wlsbot02

Хроники алготрейдинга Похоже я не выдержу и закошу сетку ордеров в maker'e. Вместо этого будет только один ордер buy и один sell. Потому что когда в сетке больше одного ордера, появляются такие проблемы: 1. В момент fill каждый следующий уровень имеет бОльшую latency fill. Если первый уровень летит за 1 ms, второй за 1.1, третий за 1.3 ms и так далее. Это связано с тем, как происходит match на бирже внутри matching engine. А повышенные latency - это проблемы. 2. Если посмотреть статистику, то на нормальных монетах стакан обычно почти не пробивается, то есть 99% филлов будут именно на первом уровне. 3. Сильно проще FSM машина: не надо заниматься ебаниной с перестановкой кучи ордеров, меньше API запросов, код сводится до if stay / if not stay, каждый сдедующий place/cancel не занимает микросекунды своим socket_write. Короче, все проще и быстрее. 4. Но самая вишенка из-за которой я хочу это сделать: это сходимость симулятора. Дело в том, что симулятор умеет показывать что будет если я буду стоять на этом уровне, и он предполагает что все мои сделки происходят именно на этом maker-уровне. А если сделать сетку на 2-3-5 ордеров, то получаем проблему: - сработал fill level 1 - сработал fill level 2 - сработал fill level 3 - все, теперь у меня на level 1 еще есть капитал, а на level 2 и 3 - уже нет. И сходимость с симуляцией нарушена, уже другая выборка трейдов: все трейды на level1, а на level2/3 уже меньше чем надо. Это конечно можно исправить сказав что на level1 вот сколько капитала, а на level2 вот столько. Но это усложнит управление позициями. Да и нахер это надо, если можно сделать просто разными аккаунтами и сетапами: аккаунт 1 стоит level1, аккаунт 2 - level2. У всех свои позиции. Полная сходимость с симулятором. #chronicles

1400 Пользуясь случаем хочу сказать: я не размещаю рекламу, хватит мне писать об этом =)

По монете XMR Monero, coinmarketcap, coingecko выдает HTX на третьем месте по объемам торгов на споте. Ввод и вывод XMR с 8 октября закрыт на HTX, не доступна для торгов в веб интерфейсе HTX Цены которые отдает HTX API на графике. Все что надо знать об объемах торгов которые публикуют крипто биржи 🙈

Похоже в список PressF надо добавлять woox Сначала было The system is under maintenance А теперь [GW] no upstream server

Лучшее соединение постоянно меняется 1. Это касается всех бирж, всех соединений, просто ниже пример для бинанса. 2. Предположим, вы подключились к public websocket и начали получать bbo. Перебрали сотню соединений и нашли лучшее, которое выдает вам маркет-дату за 1100 us. 3. Через час оно уже не будет лучшим. Если держать 10 соединений одновременно, то лидер будет меняться каждую минуту-две. 4. Это происходит по разными причинам: особенности aws fabric, особенности aws elb, нагрузка на push gateway к которому вы подключены, порядок в очереди push gw, и еще куча всякой неведанной херни. 5. Недостаточно один раз подобрать лучший коннект, это надо делать постоянно. Для некоторых пар это будут сотни соединений одновременно. #datastream #network

Вызываю помощь зала: у кого-нибудь есть прямой контакт кого-то живого из Revolut Business? Они заблокировали счет Кирпской компании, уже недели две ебут мозг комплаенсом и не отвечают что не так. Только ждите ждите. Второй раз за месяц комплаенс.

Срочный выпуск рубрики "цепочка багов" 1. У меня забесился новый cross-hedger: из-за перехода границ float/double. Хеджер принял небольшой amount, а затем float1 - float1 получилось -0.0000....1 и хеджер такое обрабатывать не умел. Поэтому ему казалось что позиция всегла есть, и надо продолжать покупать. 2. В 01:29 каждые 500 ms я начал дуть пачку buy ордеров в binance XMRUSDT. 3. В какой-то момент даже бинансу стало плохо и он начал выдавать 408 Timeout waiting for response from backend server. Send status unknown; execution status unknown. 4. при этом у меня очень хитрая защита, куча race-соединений, кучи IPшников - в итоге я кидал небольшие place order пока не набрал 1200 XMR long в 5м плечом. Продолжал пока не закончились деньги, all-in. 5. На скриншоте tradeid binance'a - как видите они идут по счетчику, и все мои :) 6. В итоге вот эта свеча полностью моя. #bugchain

иногда бывает и так

Дурка оптимизации вышла на новый уровень: Мне приснилось что я исправил тупой баг. А потом утром я открыл код - и оказалось что не исправил 😢 #hellcode

Продолжение истории по bingx - как проебать 160к на комиссиях за 9 минут

иконик пикча

Загадка: будет ли коррелировать websocket layer ping-pong с latency получения маркет-даты Короткий ответ: нет, не будет. Внутри websocket'a есть специальные frame opcode=9, которые позволяют отправить на сервер свой ping вместе с полезной нагрузкой. В эту полезную нагрузку можно впихнуть свой timestamp. А сервер обязан ответить на каждый ваш ping фреймом 0xA в котором передавать вашу полезную нагрузку. Так можно на лету считать rtt-соединения. Это очень красивая схема: не выжирая никакие API лимиты можно подбирать наиболее быстрое соединение. Но в реальности это для большинства бирж хуйня, хотя бывают моменты когда оно коррелирует. В чем собственно проблема: Предположим, мы хотим подписаться на public маркет-дату бинанса и просто слушать bbo & trades. В этом случае схема как летит маркет-дата примерно такая: YOUR_SERVER << CLOUDFRONT/CLOUDFLARE << AWS ELB (load balancer) << PUSH GATEWAY << MATCHING ENGINE/RISK ENGINE (Если у вас colo - то схема может быть упрощена до YOUR_SERVER << PUSH GATEWAY << MATCHING ENGINE/RISK ENGINE) То есть, matching генерирует событие, оно поступает на N push gateways, а потом через ELB+CloudFront доставляется вам. При этом на websocket ping-pong будет отвечать push gateway. Получается, если мы ориентируемся на ping-pong latency - то мы подбираем лучшее соединение к gateway. Но не факт, что от gateway до matching будет самый быстрый маршрут. Можно подобрать лучший push gw, но потом от него до нужного matching engine будет долго. Понимаете, matching, push - это все разные серваки. Matching еще как правило per symbol - на каждую монетку свой. И не факт что внутри aws все серваки стоят рядом. Даже если биржа сказала "хочу cluster placement group" - то aws физически не позволит впихнуть туда сотни инстансов. Поэтому будет задержка между matching & push. Для примера кукуха (kucoin): у нее от matching до push gateway 2 ms, а от push gateway до меня - 0.2 ms. И что самое забавное: некоторые биржи в своих hft handbook прямым текстом говорят подбирайте соединения по пингам - только вот это хуйня полная, потому что оно не коррелирует. #network #datastream

приехали!

Вот вам загадка на ночь: найди тупезный баг в этом коде