Есть с нуля мною написанный инструмент для внутрибиржевого latency arbitrage с временем обработки тика датафида ~0.2микросекунды (с уже вычтенными сетевыми расходами), сетевой стек и многопоточный код накидывает еще ~0.3 микросекунды на тик, итого на круг(за вычетом пинга) выходит ~0.5 микросекунд. Арбитражит датафид сугубо по контенту, временные метки от биржи не нужны. Знаю, как допилить до ~0.1 микросекунды сам процессинг. Как далее бороться за уменьшение издержек на сеть тоже знаю куда двигаться(FStack, кастомное железо от Solarflare и прочее). На Битмексе ловятся дельты в моменте до сотен миллисекунд(обычное дело десятки миллисекунд), на том же Бинансе-десятки миллисекунд. Вопрос-кто занимается арбитражами латентности на современных техстеках/инструментах, это нормальные цифры или медленно и есть куда дальше стремиться? Кто вообще сейчас этой темой занимается на форуме? Что-то мало с кем можно на эти темы пообщаться, кручусь в полнейшем информационном вакууме.
В "Загранице"-потому что за бугром похоже законодатели мод в области HFT живут, РФ в этом отношении в лучшем случае реализаторы на сабконтракте чужих идей или я ошибаюсь?
Короче-кто в этой теме что-то на практике копал либо копает-велкам обсудить(не нарушая NDA )
Здравствуйте, HFTMan, Вы писали:
HFT>Есть с нуля мною написанный инструмент для внутрибиржевого latency arbitrage с временем обработки тика датафида ~0.2микросекунды (с уже вычтенными сетевыми расходами), сетевой стек и многопоточный код накидывает еще ~0.3 микросекунды на тик, итого на круг(за вычетом пинга) выходит ~0.5 микросекунд. Арбитражит датафид сугубо по контенту, временные метки от биржи не нужны. Знаю, как допилить до ~0.1 микросекунды сам процессинг. Как далее бороться за уменьшение издержек на сеть тоже знаю куда двигаться(FStack, кастомное железо от Solarflare и прочее). На Битмексе ловятся дельты в моменте до сотен миллисекунд(обычное дело десятки миллисекунд), на том же Бинансе-десятки миллисекунд. Вопрос-кто занимается арбитражами латентности на современных техстеках/инструментах, это нормальные цифры или медленно и есть куда дальше стремиться? Кто вообще сейчас этой темой занимается на форуме? Что-то мало с кем можно на эти темы пообщаться, кручусь в полнейшем информационном вакууме. HFT>В "Загранице"-потому что за бугром похоже законодатели мод в области HFT живут, РФ в этом отношении в лучшем случае реализаторы на сабконтракте чужих идей или я ошибаюсь? HFT>Короче-кто в этой теме что-то на практике копал либо копает-велкам обсудить(не нарушая NDA )
В этой области не кручусь, но слышал, что все эти микросекунды которые можно выжать из CPU это ерунда, правильные пацаны давно перешли на FPGA и десятками наносекунд оперируют.
Ну и ясен пень там от сетевого соединения много что зависит. Если у тебя нет как минимум прямого без промежуточных хостов подключения к биржевой площадке — там тебе делать нечего (ну кроме таких площадок которые мало кому нужны по большому счету). Это все конечно про настоящие биржи. Все эти ваши биткоины — это дикий запад, что там сама эти площадки делают с вашими котировками никому неизвестно, плюс большие дельты скорее всего компенсируются высокими транзакционными издержками.
Здравствуйте, VladiCh, Вы писали:
VC>В этой области не кручусь, но слышал, что все эти микросекунды которые можно выжать из CPU это ерунда, правильные пацаны давно перешли на FPGA и десятками наносекунд оперируют.
В районе ~100 нс, но это не арбитраж датафида как таковой, а это время отработки самой HFT стратеги от момента прихода данных в сетевое железо и до ухода ордера в сетевое железо же.
Заставить арбитражить сам датафид посредством FPGA конечно можно, но представляю цену такого решения и становится весело
Ну и в конце концов-0.5 мкс на круг сейчас моего CPU железа-это 500нс с пониманием, как это время срезать еще, так что не совсем все плохо.
VC>Ну и ясен пень там от сетевого соединения много что зависит. Если у тебя нет как минимум прямого без промежуточных хостов подключения к биржевой площадке — там тебе делать нечего (ну кроме таких площадок которые мало кому нужны по большому счету). Это все конечно про настоящие биржи. Все эти ваши биткоины — это дикий запад, что там сама эти площадки делают с вашими котировками никому неизвестно, плюс большие дельты скорее всего компенсируются высокими транзакционными издержками.
Ну стакан виден же, понятно что биржа клеит ордера в одну дельту стакана, но это и правильно, надо же траффик наружу жать алгоритмически.
А хосты в большинстве случаев в любом случаев почти на любой криптобирже будут-стать в стойку рядом с биржей ИМХО непросто.
В любом случае-иметь инфу раньше чем 99.9% потребителей стакана биржи, уже отлично.
с такими latency я подозреваю, что это ФПГА и есть.
Автор — никто в интернете такими технологиями и не делится, все HFT же конкурируют. Также, побеждает именно самый быстрый, остальным ничего не достается.
Советую написать в какой-нить Citadel и продать наработки
Здравствуйте, Ip Man, Вы писали:
IM>с такими latency я подозреваю, что это ФПГА и есть.
Не, народ путает арбитраж латентности(т.е. отлов быстрейшего в моменте датафида из множества датафидов) и арбитраж цены(их прорва всяких, но они о другом). Так вот да, для второго FPGA давно есть и успешно применяются(я об этом в районе 2012 года услышал еще), и там да-цифры в районе 100нс и меньше у всех приличных HFT фондов.
Арбитраж латентности датафида возможно и на FGPA можно скрутить, но памяти надо прилично(для стакана размером в пару десятков тысяч уровней цен), а она у FPGA недешевая.
Можно конечно строить стакан только в районе Bid/Ask, но если будет резкое движение цены-то надо достраивать стакан, и получается-данные о всем стакане все равно надо как-то хранить. IM>Автор — никто в интернете такими технологиями и не делится, все HFT же конкурируют. Также, побеждает именно самый быстрый, остальным ничего не достается.
Так технологией никто не просит делиться, мне интересно-цифры у тех кто именно арбитражем латентности датафидов занимается, насколько отличаются.
IM>Советую написать в какой-нить Citadel и продать наработки
Посмеялся. Кому они там нужны, эти наработки, а если и нужны-нет безопасных для меня механизмов продажи, которые гарантируют, что не нагреют. Я лучше сам попробую воспользоваться.
Здравствуйте, Sharov, Вы писали:
S>Здравствуйте, HFTMan, Вы писали:
HFT>> Что-то мало с кем можно на эти темы пообщаться, кручусь в полнейшем информационном вакууме.
S>В ods.ai есть соотв. канал в слаке, он так и называется #trading. На нем 1500 человек сидит. Я бы там еще спросил.
Здравствуйте, HFTMan, Вы писали:
HFT>Короче-кто в этой теме что-то на практике копал либо копает-велкам обсудить(не нарушая NDA )
Арбитражем заниматься без машины на бирже — бесполезно. У всех других игроков машины там уже стоят и микроволновые линки между площадками, они тебя разденут.
Если крипта, то там до таких скоростей еще долго, можно и по интернету
Здравствуйте, StanislavK, Вы писали:
SK>Здравствуйте, HFTMan, Вы писали:
HFT>>Короче-кто в этой теме что-то на практике копал либо копает-велкам обсудить(не нарушая NDA ) SK>Арбитражем заниматься без машины на бирже — бесполезно. У всех других игроков машины там уже стоят и микроволновые линки между площадками, они тебя разденут.
Да, на консервативном рынке так и есть, нечего лезть, все верно.
Но есть нюанс, я именно про latency arbitrage интересуюсь, а вот он на FPGA вообще есть?
Я тут разницу описал: http://rsdn.org/forum/abroad/7836151.1
Здравствуйте, HFTMan, Вы писали:
HFT>выходит ~0.5 микросекунд
Ну круто. А это какой percentile? И success rate в итоге?
У самой биржи какой примерно latency variance? Если миллисекунды, то на спичках экономить смысла нет. Лучше стратегию улучшить или risk checks. И FPGA в этих случаях не нужен. Разработка сложнее и дороже, возможностей меньше.
ned>У самой биржи какой примерно latency variance? Если миллисекунды, то на спичках экономить смысла нет. Лучше стратегию улучшить или risk checks. И FPGA в этих случаях не нужен. Разработка сложнее и дороже, возможностей меньше.
А насколько часто FPGA используется?
Интересно, имеет ли смысл в эту область двигать. В смысле FPGA. Пока впечатление, что пара вакансий есть и все.
Здравствуйте, gardener, Вы писали:
G>А насколько часто FPGA используется?
Во многих случаях без него уже никак. И не только там где utra-low-latency, а там где нужно предсказуемая latency. Вот даже если топикстартер всё правильно делает: core isolation, cache warming и т.п. Но пришёл пакет когда дата в L3 провалилась и прощай 100ns.
G>Интересно, имеет ли смысл в эту область двигать. В смысле FPGA. Пока впечатление, что пара вакансий есть и все.
Да, имеет. Очень горячая область. Трейдинг очевидно, но слышал что уже и FAANG используют вовсю. Можно заодно и ASIC смотреть.
Здравствуйте, ned, Вы писали:
ned>Здравствуйте, HFTMan, Вы писали:
HFT>>выходит ~0.5 микросекунд
ned>Ну круто. А это какой percentile? И success rate в итоге? ned>У самой биржи какой примерно latency variance? Если миллисекунды, то на спичках экономить смысла нет. Лучше стратегию улучшить или risk checks. И FPGA в этих случаях не нужен. Разработка сложнее и дороже, возможностей меньше.
90%, нет пока success rate, в разработке все, это же не стратега арбитража цен, это стратега арбитража датафидов от одной биржи, т.е. берем множество датафидов и в моменте ловим
самые свежие данные, для ловли самых свежих данных таймштамп от биржи не нужен, а если он и есть-то погрешность его такова, что для построения непригоден.
Latency variance от сотен наносекунд до десятков(иногда сотен) мс
Здравствуйте, ned, Вы писали:
ned>Здравствуйте, gardener, Вы писали:
G>>А насколько часто FPGA используется?
ned>Во многих случаях без него уже никак. И не только там где utra-low-latency, а там где нужно предсказуемая latency. Вот даже если топикстартер всё правильно делает: core isolation, cache warming и т.п. Но пришёл пакет когда дата в L3 провалилась и прощай 100ns.
В этом и сложность арбитража датафидов(в частности датафида стакана)-объемы данных в десятки(сотни МБ), как не танцуй-все в кешах CPU не поместится.
Остальные меры, да, необходимы, минимизация случайного доступа к памяти для оптимизации работы кэша CPU, минимизация вызовов ядра Linux(пока стандартный epoll используется, а он в ядре работает, но на user space TCP/IP стек переезд вполне реален), пристегивание каждого потока обработки только к одному ядру CPU, чтобы стек не тягать сжирая латентность при вытеснении потоков,учет когерентности кэша, в том числе правильная нарезка данных и их размеры и прочая, прочая...
HFT... Вопрос-кто занимается арбитражами латентности на современных техстеках/инструментах, это нормальные цифры или медленно и есть куда дальше стремиться? Кто вообще сейчас этой темой занимается на форуме? Что-то мало с кем можно на эти темы пообщаться, кручусь в полнейшем информационном вакууме.
Такое бьіло медленно еще 10 лет назад. И Solarflare тогда уже тоже не спасал.
Здравствуйте, cockRoach, Вы писали:
R>Здравствуйте, HFTMan, Вы писали:
R>HFT... Вопрос-кто занимается арбитражами латентности на современных техстеках/инструментах, это нормальные цифры или медленно и есть куда дальше стремиться? Кто вообще сейчас этой темой занимается на форуме? Что-то мало с кем можно на эти темы пообщаться, кручусь в полнейшем информационном вакууме. R>Такое бьіло медленно еще 10 лет назад. И Solarflare тогда уже тоже не спасал.
Ты путаешь арбитраж цены и внутрибиржевой арбитраж латентности произвольного датафида(будь то ордербук, трейды либо другой временной ряд) с множества коннектов(что я и запилил).
Для первого медленно, для второго вообще цифры для меня неизвестны, т.к. я их нигде не видел.
Здравствуйте, HFTMan, Вы писали:
HFT>Есть с нуля мною написанный инструмент для внутрибиржевого latency arbitrage с временем обработки тика датафида ~0.2микросекунды (с уже вычтенными сетевыми расходами), сетевой стек и многопоточный код накидывает еще ~0.3 микросекунды на тик, итого на круг(за вычетом пинга) выходит ~0.5 микросекунд. Арбитражит датафид сугубо по контенту, временные метки от биржи не нужны. Знаю, как допилить до ~0.1 микросекунды сам процессинг. Как далее бороться за уменьшение издержек на сеть тоже знаю куда двигаться(FStack, кастомное железо от Solarflare и прочее). На Битмексе ловятся дельты в моменте до сотен миллисекунд(обычное дело десятки миллисекунд), на том же Бинансе-десятки миллисекунд. Вопрос-кто занимается арбитражами латентности на современных техстеках/инструментах, это нормальные цифры или медленно и есть куда дальше стремиться? Кто вообще сейчас этой темой занимается на форуме? Что-то мало с кем можно на эти темы пообщаться, кручусь в полнейшем информационном вакууме. HFT>В "Загранице"-потому что за бугром похоже законодатели мод в области HFT живут, РФ в этом отношении в лучшем случае реализаторы на сабконтракте чужих идей или я ошибаюсь? HFT>Короче-кто в этой теме что-то на практике копал либо копает-велкам обсудить(не нарушая NDA )
Сначала прифигел от очень крутых цифр. Но потом, почитав твои же комменты, понял, что ты имеешь ввиду, у нас это называли channel arbitrage. На обычных биржах (которые отправляют маркет дату по протоколам типа ITСH или FAST), это делается достаточно просто, слушаешь несколько каналов и выкидываешь устаревшие сообщения по sequence number. На криптовалютных биржах раньше это сделать было достаточно трудно, так как сталкивался с ситуацией, что на разных фидах просто идут немного разные данные, хотя сейчас может все изменилось к лучшему.
Вообще не очень понимаю, что именно у тебя делается за 0.2 микросекунды. Если это крипта, то данные скорее всего идут до вебсокету и и закодированы в json. Я правильно понимаю что это время от получения сообщения по сети, до окончания парсинга контента и построения стакана по уровням? Думаю, результат вполне нормальный, но самые большие задержки именно на уровне сети ИМХО их надо оптимизировать в первую очередь.
Ну и потом, быстрая маркет дата не особо нужна без такой же быстрой отправки ордера. А управление ордерами, это еще тот геморрой (особенно на криптобиржах). Ну и главное, есть предположение, что на многих криптобиржах цены и объемы показываются не совсем верные (хотя, может сейчас это уже поправили).
Вообще, то что ты тут поисываешь, это конечно круто, но это очень маленькая часть торговой системы. ИМХО с этими вещами есть смысл заморачиваться только если уже есть как-то работающая торговая система.
R>>HFT... Вопрос-кто занимается арбитражами латентности на современных техстеках/инструментах, это нормальные цифры или медленно и есть куда дальше стремиться? Кто вообще сейчас этой темой занимается на форуме? Что-то мало с кем можно на эти темы пообщаться, кручусь в полнейшем информационном вакууме. R>>Такое бьіло медленно еще 10 лет назад. И Solarflare тогда уже тоже не спасал. HFT>Ты путаешь арбитраж цены и внутрибиржевой арбитраж латентности произвольного датафида(будь то ордербук, трейды либо другой временной ряд) с множества коннектов(что я и запилил).
Нет. HFT>Для первого медленно, для второго вообще цифры для меня неизвестны, т.к. я их нигде не видел.
А они есть, но тебе их не скажут.
R>>>HFT... Вопрос-кто занимается арбитражами латентности на современных техстеках/инструментах, это нормальные цифры или медленно и есть куда дальше стремиться? Кто вообще сейчас этой темой занимается на форуме? Что-то мало с кем можно на эти темы пообщаться, кручусь в полнейшем информационном вакууме. R>>>Такое бьіло медленно еще 10 лет назад. И Solarflare тогда уже тоже не спасал. HFT>>Ты путаешь арбитраж цены и внутрибиржевой арбитраж латентности произвольного датафида(будь то ордербук, трейды либо другой временной ряд) с множества коннектов(что я и запилил). R>Нет.
Путаешь. Почитай того же ksandro в этой теме. HFT>>Для первого медленно, для второго вообще цифры для меня неизвестны, т.к. я их нигде не видел. R>А они есть, но тебе их не скажут.
Угу, видимо ветром надуло цифры FPGA HFT роботов почти 10 лет назад и прочие цифры, которые всегда всплывают рано или поздно.
Ты ведь явно в HFT бизнесе не крутился, какого члена щОки дуешь?
Здравствуйте, ksandro, Вы писали:
K>Здравствуйте, HFTMan, Вы писали:
K>Сначала прифигел от очень крутых цифр. Но потом, почитав твои же комменты, понял, что ты имеешь ввиду, у нас это называли channel arbitrage. На обычных биржах (которые отправляют маркет дату по протоколам типа ITСH или FAST), это делается достаточно просто, слушаешь несколько каналов и выкидываешь устаревшие сообщения по sequence number. На криптовалютных биржах раньше это сделать было достаточно трудно, так как сталкивался с ситуацией, что на разных фидах просто идут немного разные данные, хотя сейчас может все изменилось к лучшему.
Я по старинке, как на FX площадках в 2000е повелось-latency arbitrage, только не между площадками, а внутри одной площадки.
У многих бирж нет sequence number в протоколе, в лучшем случае таймштамп с детальностью в 1мс, и толку от него? K>Вообще не очень понимаю, что именно у тебя делается за 0.2 микросекунды. Если это крипта, то данные скорее всего идут до вебсокету и и закодированы в json. Я правильно понимаю что это время от получения сообщения по сети, до окончания парсинга контента и построения стакана по уровням? Думаю, результат вполне нормальный, но самые большие задержки именно на уровне сети ИМХО их надо оптимизировать в первую очередь.
Не, архитектура сложнее, делиться деталями не буду, все таки элементы ноу-хау имеются, придержу их при себе.
K>Ну и потом, быстрая маркет дата не особо нужна без такой же быстрой отправки ордера. А управление ордерами, это еще тот геморрой (особенно на криптобиржах). Ну и главное, есть предположение, что на многих криптобиржах цены и объемы показываются не совсем верные (хотя, может сейчас это уже поправили).
Согласен, подобный инструмент нужен для тех случаев, когда и ордера улетают быстро.
Ну да, некоторые нюансы всплывают (с дубляжами маркетдаты как пример), но жить можно, правда алгоритмы должны быть устойчивые к этим нюансам.
K>Вообще, то что ты тут поисываешь, это конечно круто, но это очень маленькая часть торговой системы. ИМХО с этими вещами есть смысл заморачиваться только если уже есть как-то работающая торговая система.
Согласен.
)
