fa
Feedback
АЛГОтрейдинг | ALKO_trading | CRYPDE | HFT

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

رفتن به کانال در Telegram

Crypto algorithmic trading. High-Frequency arbitrage & market-making. #crypto #trading #hft https://crypde.com/ contact hello@crypde.com

نمایش بیشتر
785
مشترکین
+324 ساعت
+127 روز
+3430 روز

در حال بارگیری داده...

جذب مشترکین
ژوئن '26
ژوئن '26
+25
در 0 کانال‌ها
مه '26
+57
در 1 کانال‌ها
Get PRO
آوریل '26
+67
در 0 کانال‌ها
Get PRO
مارس '26
+170
در 2 کانال‌ها
Get PRO
فوریه '26
+29
در 0 کانال‌ها
Get PRO
ژانویه '26
+82
در 0 کانال‌ها
Get PRO
دسامبر '25
+21
در 0 کانال‌ها
Get PRO
نوامبر '25
+35
در 0 کانال‌ها
Get PRO
اکتبر '25
+56
در 0 کانال‌ها
Get PRO
سپتامبر '25
+18
در 0 کانال‌ها
Get PRO
اوت '25
+46
در 0 کانال‌ها
Get PRO
ژوئیه '25
+25
در 0 کانال‌ها
Get PRO
ژوئن '25
+26
در 0 کانال‌ها
Get PRO
مه '25
+18
در 0 کانال‌ها
Get PRO
آوریل '25
+11
در 0 کانال‌ها
Get PRO
مارس '25
+5
در 0 کانال‌ها
Get PRO
فوریه '25
+5
در 0 کانال‌ها
Get PRO
ژانویه '25
+9
در 0 کانال‌ها
Get PRO
دسامبر '24
+7
در 0 کانال‌ها
Get PRO
نوامبر '24
+19
در 0 کانال‌ها
Get PRO
اکتبر '24
+12
در 0 کانال‌ها
Get PRO
سپتامبر '24
+6
در 0 کانال‌ها
Get PRO
اوت '24
+18
در 0 کانال‌ها
Get PRO
ژوئیه '24
+5
در 0 کانال‌ها
Get PRO
ژوئن '24
+3
در 0 کانال‌ها
Get PRO
مه '24
+6
در 0 کانال‌ها
Get PRO
آوریل '24
+131
در 0 کانال‌ها
Get PRO
مارس '24
+39
در 0 کانال‌ها
Get PRO
فوریه '24
+115
در 0 کانال‌ها
تاریخ
رشد مشترکین
اشارات
کانال‌ها
14 ژوئن0
13 ژوئن+3
12 ژوئن+4
11 ژوئن+3
10 ژوئن+2
09 ژوئن+3
08 ژوئن+2
07 ژوئن+2
06 ژوئن0
05 ژوئن+2
04 ژوئن+2
03 ژوئن+1
02 ژوئن0
01 ژوئن+1
پست‌های کانال
Вот ваша эпичная цепочка багов или почему меня ликвидировало на XMR стечение обстоятельств ценой в 35 000 USDT 1. Все началось вот отсюда - https://t.me/alko_trading/1583 - я решил уменьшить количество процессов и похерил latency. Для большинства бирж это не критично, кромне binance USDT-M, который используется как hedger. 2. Этот косяк дал latency +200 us (микросекунд, не миллисекунд) и из-за этого полностью сломался весь трейдинг на кукухе (kucoin). Да, в HFT-аде есть такая штука, что пока у тебя cancel-реакция 2 ms - ты все успеваешь, 2.2 ms ты работаешь в 0, 2.3 ты все проебал. Вот настолько это критично. 3. Я не сразу понял в чем дело, ушло дней пять чтобы понять что я похерил, а кукуха торговала в минус. Ну я ее и поставил на паузу, нефиг терять бабло пока разбираюсь и чиню. 4. Но знаете в чем прикол? Кукуха давала большое количество сделок по XMR: около 10 сделок buy + 10 сделок sell в час, с небольшой прибылью. Это позволяло постоянно переворачивать позицию на binance futures туда-сюда. 5. Дело не в обороте, а в том, что если туда-сюда переворачивать позицию, то ее entry price все время будет находиться недалеко от mark/index price, и риск ликвидации нивелируется почти в 0. И вот кукуха на паузе, и ее спесительного оборота нет, позиция не переворачивается туда-сюда, а остальные биржи торгуют XMR сильно реже. 6. И вот XMR подрастает-подрастает, а entry-price моего short'a на binance стоит на месте. Потом иголка вверх, margin call и ликвидация. Если что я юзаю isolated margin. Это специально, чтобы никакая иголка не всадила все. Думаете это конец пиздеца? Нет, я к этому был готов! Дальше пиздец еще больший. 7. У меня есть отдельная система, которая обрабатывает margin call и ликвидации. Схема такая: - если близится margin call, то я уменьшаю max position и заставляю систему торговать в другую сторону. Конкретно сейчас это не помогло бы, потому что кукуха на паузе. - если случилась ликвидация - я об этом знаю через 1 минуту максимум и просто снова открою позицию, у меня ж isolated margin. 8. Ситуации с ликвидацями случаются редко, условно 5 раз в год (потому что при активном трейдинге entry price далеко не улетает) - то логика обработки ликвидаций не супер отлажена, не каждый день такое. 9. Но, хуйня случилась из-за хуйоби (htx)! Ночью htx банит мне API key, и похер, у меня там 400 баксов для теста лежит. Но, логика обработки ликвизации это цикл per account. И вот идет себе логика по account 1, account 2, account 3, и примерно на середине account 50 htx, и тут throw Exception(API key failed, cannot get position) - и вылетел скрипт, половина инвесторов не отработалась. То есть код тупо не дошел туда из-за htx api key. 10. В итоге на половине инвесторов все сошлось красиво, а половина аккаунтов и осталась с необработанной ликвидацией. Идеальная доминошка! Если для потери денег нужно совпадение пяти независимых событий - рыночек терпеливо подождет, пока совпадут все пять #bugchain #chronicles

2
Говорят что молния не бьет второй раз в одну и ту же точку. Но это не правда, как раз вероятнее всего что она сейчас попадет туда-же. Второй раз ликвидация на XMR!
324
3
Всем доброго утрочка: меня ликвиднуло
Всем доброго утрочка: меня ликвиднуло
367
4
latency public market-data binance USDT-M ETHUSDT от timestamp T до полностью распаршенного json'a за 24 часа суко, я не верю
latency public market-data binance USDT-M ETHUSDT от timestamp T до полностью распаршенного json'a за 24 часа суко, я не верю
357
5
777
777
355
6
Неожиданный update по ECMP Что такое ECMP - https://t.me/alko_trading/1165 + https://t.me/alko_trading/1555 + https://t.me/alko_trading/1167 плюс ищите поиском ECMP по каналу, было с десяток постов По всем правилам ECMP работает через 5-tuple-hash: destination ip destination port source ip source port protocol (tcp, udp) Строится hash, по которому маршрутизатор выбирает по какому маршруту дальше отправлять пакет. То есть меняя просто source port (bind port) можно подбирать лучшее соединение. НО! Это сетевая маршрутизация. А вот когда пакетик прилетает на AWS ELB (load balancer), то там для определения куда дальше - используется source IP клиента (1st priority). Звучит логично, но я не знал, но мог бы догадаться. И вот это блять поворот: - потому что ECMP позволяет найти луший машрут до точки подключения; - но если точка подключения это Load Balancer - то он дальше будет пихать ваш коннект в одну и ту же ноду (api gateway, push gateway). = то есть магия ECMP заканчивается на точке подключения, а дальше балансировка идет per ip. Для примера: если на сервак с которого подписываемся к binance навесить N elastic IP и подбирать соединения от них - то можно изи срезать 300 us на получение маркет-даты. А это просто космос в мире хули-факинг-трейдинга. Прямо сейчас у меня binance USDTM public market data = avg 0.6 ms (это с учетом cutoff 1 ms, без нее 1.1 ms). Это ж пиздец как быстро. #network #datastream
357
7
В HFT есть такая проблемка, что в целом публичные технологии сильно недоразвиты для HFT. Хочу объяснить на примере: Если мы пилим какое-нибудь веб-приложение (сайтик, магазин), что у нас: - есть операционка linux которую мы не делали, но ей доверяем (ядро, шедулер, сеть); - есть php, python, которые мы не делали, но им доверяем; - есть mysql/postges/redis/memcached, которому доверяем; - есть конекторы к mysql, postgres, redis которые мы просто качнули и им доверяем; - есть веб-сокеты которые мы качнули и им доверяем, - есть веб-сервер nginx которому доверяем, - есть браузер которому кое-как доверяем, - есть HTTP-протокол который мы вообще не ставим под соменение. Мы нихера из этого не пилили, и надеемся что оно работает правильно, что там нет багов и это все не наши проблемы, там типа все по уму сделано (на самом деле нет). А в HFT это не так: - linux, которому по дефолту нельзя доверять, надо тюнить все ради latency; - сети, которые просто пиздец; - api бирж, которым тоже нельзя доверять; - свои бинарные протоколы передачи данных; - свои хранилища вместо баз; - коннекторы к своим хранилищам; - свои коннекторы websocket, https, udp; - свои менеджеры tcp & udp соединений; - свой event loop; - я даже модели osi не доверяю и начинается kernel-by-pass-дерьмо; - я не доверяю json_decode (потому что медленно), - и тд. Потом на этом всем строятся симуляторы, live-execution и тд. Это все очень многослойная архитектура, одно говно на другом. И все проблемы можно поделить на: 1. как это блять удержать все в голове 2. баг где-то в начале цепочки (в менеджере соединений, например, или в парсере websocket'a) заставляет сразу вверх и вниз искать все что это может затронуть. В HFT большинство багов нелокальны. То есть ошибка появляется в одном месте, а проявляется через 10 слоев. Дебажить можно неделями. Умножте это на "я сломал систему или сегодня просто плохой день?" Веб-разработчик может позволить себе иметь 10 багов на лям открытий страницы. А в HFT так нельзя. При потоке в 10_000 событий в секунду баг будет ловиться каждые 2 минуты. И это только вопрос инженерии: архитектура и кодинг. Это не про стратегию, не про toxic flow, не про симуляции. Кстати, когда пишешь веб-приложение то обычно все измерения идут в диапазоне 100 ms. Например, какой-нибудь запрос в базу типа select * from table where by id=1 limit 1 - это 10 ms. А в HFT весь hot-path это несколько микросекунд. Условный поиск объекта по ключу должен исполняться за 10 ns. И никаких opensource решений с такой производительностью тупо нет. #bugchain
348
8
Ранее я втирал вам за context switching, настало время сделать немного оговорок на эту тему. С вами рубрика цепочка багов, которая сломала мне все почти на неделю. 1. И-так, представьте что есть сервер на 4 cpu, на нем висит 50 процессов, каждый процесс подписывается на websocket binance 3 раза, выбирает лучшее соединение, слабое постоянно подбирает, реконструирует стакан и шлет его дальше по UDP подписчикам. Таких процессов 50, а ядер 4. 2. И вот я такой: бля, я шо лох шедулеру линукса доверять переключение между процессами, я все слеплю в 4 процесса по 12-15 сокетов, не будет никаких контекстных переключений, красота. Ну и сделал. И наебнулось все тазиком. А теперь слушайте самый головняк почему так происходит: 3. Если слепить все сокеты в live в кучу - то получим такую проблему: например, в одном процессе мы обрабатываем ETH:USDT + LTC:USDT. По ETH будет 200 событий в секунду, по LTC 2. И в 99% времени мой процесс будет занят тем, что разбирает ETH, LTC будет немного терятся. Обычно это не заметно, пока одновременно на ETH не прилетит 2000 событий за 10 ms, и на LTC еще 100. В этот момент latency всего просядет, а LTC p99 вообще станет адом. Если бы процессы были разные - есть шанс что процесс1 прыгнет на ядро1, а процесс2 на ядро2 и все разберется параллельно. А у меня - нет. 4. вторая проблема которая начинается - это socket fanout. Теперь один процесс - и значит писать в сокеты можно только по очереди. И вот если по ETH я начинаю по UDP пушить socket_write, то в этот момент я не могу вовремя сделать socket_write по LTC. И прийомщик такой: кажись мы потеряли датастрим, чао-какао, снимаем ордера, всему пиздарики. А пиздарики эпичные, у меня все останавливается на время потери хотя-бы одного datastream, перестают считаться jitter (а там еще ебнутая багнутая EMA...) То есть мало того что я медленее читаю при бурстах, так я еще медленее пишу дальше. 5. Вся эта хероса сделала весьма странную картину: пока процессы разные - я по binance получал median 1.3 ms, avg 1.5 ms. слепил все в один процесс - median 1.6 ms, avg 1.5 ms. И это очень забавный момент: поменялось само распределение. Раньше был avg > median (тяжелые хвосты, это логично). А стало - avg < median (появились короткие хвосты, хотя все стало хуже). 6. Эти несчасные 100-200 микросекунд (не миллисекунд) сломали мне кукуху (kucoin), неделю торговали в минус. Всем пожалуйста. Вы не представляете как я заебался. #bugchain #network
404
9
بدون متن...
409
10
Как же без багов, вы точно соскучились по ним. У меня есть система, которая считает hitrate между соединениями (какое лучше). hitrate - это скользящая EMA по hit +1 miss 0. Считается супер быстро за O(1), найс. То есть, я по каждому соединению считаю применил ли я пакет из него - если да - этому соединению повышаю hitrate EMA, не применил - понижаю. Так за условные 100 пакетов можно сразу понять что быстрее, а что медленее, и раз в минуту перезапустить лузера. А теперь минутка математики: EMA считается как EMA = EMA + alpha x (1 - EMA), где alpha = 2/(N+1). И тут я допускаю два эпичнейших бага: 1. вместо 2/(N+1) я пишу 1/(N+1), что замедляет EMA в 2 раза. И никакой джуниорgpt не видит проблемы. 2. мне кажется, что если прошло N точек - то EMA уже стабилизировалась и ее можно использовать. Но нет, надо чтобы прошло 3N или 4N точек - в 4 раза больше. Потому что за первые N точек EMA станет справедливой только на 86.5%. 2.1. А если скрестить баг 1+2 - то EMA за N точек устаканится только на 63%. Бляяя Сука, вы не представляете сколько у меня завязано на этой EMA: и расчет jitter, и race всех соединений везде, и все на дохлой EMA. Если шо - день рождения бага - 14 января 2025, и до этого времени все как-то работало. Неважно насколько крутая может быть идея (connection race, ema jitter, etc) - в процессе кодинга я все равно допущу эпичный косяк и все будет почти работать, но нет. #bugchain
439
11
топовые трейдеры по курсам Герчика
топовые трейдеры по курсам Герчика
443
12
я вообще не понимаю приколов аниме (не пытайтесь мне это объяснить), но это ж полный угар: https://github.com/pystardust/ani-cli эта софтина позволяет смотреть аниме в консоли
465
13
вы исчерпали свои кредиты
вы исчерпали свои кредиты
526
14
Это кольцо? Нет - это NFT кольца!
Это кольцо? Нет - это NFT кольца!
483
15
بدون متن...
480
16
Придумал чувак стратегию: покупать акции которые стоят 1 цент. Идея такая: акция стоит самый минимум, падать уже некуда, значит или рост или на месте. Покупает на 1000 баксов - хоп, цена подросла до 0.05. Покупает еще на 1000 - рынок отреагировал и цена уже 0.10. Покупает еще - цена 1 доллар. И думает: во, заебись, теперь продаю. А стакан блять пуст.
720
17
Немного оффтоп, но все-таки KPI - коллективно пашем извилинами ТЗ - текст-загадка PR - пиздец репутации SMM - слезы молодого маркетолога
634
18
Я не могу этим не поделиться: вы думаете aws загоняется с тарификацией? С меня только что взяли деньги за хранение документа в принтере: я закинул документ в офисный shared принтер, нажал print + keep вместо print+delete, и PDF-ка на одну страничку пролежала там месяц. Сегодня пришел инвойс и там добавлена строка на 0.21 EUR за хранение
616
19
بدون متن...
580
20
بدون متن...
646