Здравствуйте, HFTMan, Вы писали:
HFT>Здравствуйте, ksandro, Вы писали:
K>>Здравствуйте, HFTMan, Вы писали:
K>>Сначала прифигел от очень крутых цифр. Но потом, почитав твои же комменты, понял, что ты имеешь ввиду, у нас это называли channel arbitrage. На обычных биржах (которые отправляют маркет дату по протоколам типа ITСH или FAST), это делается достаточно просто, слушаешь несколько каналов и выкидываешь устаревшие сообщения по sequence number. На криптовалютных биржах раньше это сделать было достаточно трудно, так как сталкивался с ситуацией, что на разных фидах просто идут немного разные данные, хотя сейчас может все изменилось к лучшему. HFT>Я по старинке, как на FX площадках в 2000е повелось-latency arbitrage, только не между площадками, а внутри одной площадки.
Возможно я что-то недопонимаю, но latency арбитраж между площадками, на форексе заключается в том, что форекс кухни сами с тобой торгуют, и если одна форекс кухня тормозит и торгует с тобой по устаревшей цене, то ты на этом можешь сделать прибыль. А тут же биржа... Что с того, что ты по одному каналу увидел цену быстрее чем по другому, если это одна площадка, все равно купить можно только то, что на бирже есть. Ты должен все-таки делать или арбитраж с другой площадкой, или делать треугольник с разными валютами, ну или использовать какую-то крутую стратегию. А это просто оптимизация, для того чтоб чуть быстрее видеть цену.
HFT>У многих бирж нет sequence number в протоколе, в лучшем случае таймштамп с детальностью в 1мс, и толку от него?
Ну, вот поэтому я и говоорю, что с криптовалютными приходится извращаться. Методы есть разные. Но самое неприятное когда на разных коннекшенах идут немного разные данные (думаю у крипто биржи делают какую-то фигню для балансировки нагрузки и могут показывать разные данные с разных серверов).
K>>Вообще не очень понимаю, что именно у тебя делается за 0.2 микросекунды. Если это крипта, то данные скорее всего идут до вебсокету и и закодированы в json. Я правильно понимаю что это время от получения сообщения по сети, до окончания парсинга контента и построения стакана по уровням? Думаю, результат вполне нормальный, но самые большие задержки именно на уровне сети ИМХО их надо оптимизировать в первую очередь.
HFT>Не, архитектура сложнее, делиться деталями не буду, все таки элементы ноу-хау имеются, придержу их при себе.
Ну, ты говоришь: "обрабатываю тик за 0.2 микросекунды", я спрашиваю, что входит в эту обработку, ты говоришь, что не расскажешь. Опять же "0.5 мс на круг", круг — это откуда и до куда?
K>>Ну и потом, быстрая маркет дата не особо нужна без такой же быстрой отправки ордера. А управление ордерами, это еще тот геморрой (особенно на криптобиржах). Ну и главное, есть предположение, что на многих криптобиржах цены и объемы показываются не совсем верные (хотя, может сейчас это уже поправили).
HFT>Согласен, подобный инструмент нужен для тех случаев, когда и ордера улетают быстро. HFT>Ну да, некоторые нюансы всплывают (с дубляжами маркетдаты как пример), но жить можно, правда алгоритмы должны быть устойчивые к этим нюансам.
Ну, вот я и говорю, что это уже микрооптимизации, которые имеет смысл делать, когда у тебя уже есть работающая система, для того, чтоб выжать из нее максимум. Просто так, конкурировать с крупными игроками, у которых сервера в коллокейшене и договоренность с биржей на выделенный VIP канал, по latency ты все равно не сможешь. Так что у тебя должна быть какая-то крутая торговая стратегия, а к ней уже можно приделывать все эти прибомбасы.
K>>Вообще, то что ты тут поисываешь, это конечно круто, но это очень маленькая часть торговой системы. ИМХО с этими вещами есть смысл заморачиваться только если уже есть как-то работающая торговая система. HFT>Согласен.
Здравствуйте, HFTMan, Вы писали:
HFT>>>Короче-кто в этой теме что-то на практике копал либо копает-велкам обсудить(не нарушая NDA ) SK>>Арбитражем заниматься без машины на бирже — бесполезно. У всех других игроков машины там уже стоят и микроволновые линки между площадками, они тебя разденут. HFT>Да, на консервативном рынке так и есть, нечего лезть, все верно. HFT>Но есть нюанс, я именно про latency arbitrage интересуюсь, а вот он на FPGA вообще есть? HFT>Я тут разницу описал: HFT>http://rsdn.org/forum/abroad/7836151.1
Зачем его на FPGA? У вас там крипта по интернету, все так медленно, что можно sleep-ы вставлять. Когда же реально будут нужны скорости, то лавочку быстро закроют, так как это было с теми, кто это проворачивал на FX.
HFT>Но есть нюанс, я именно про latency arbitrage интересуюсь, а вот он на FPGA вообще есть?
Если я правильно понимаю то, что вы имеете ввиду под "latency arbitrage", то это на хабре проскакивало, что даже русские ребята такое сделали лет этак 4-5 назад ...
Из: Реализация HFT роботов на устройствах CEPappliance
Основные особенности HFT системы
Чтобы обеспечить малую задержку реакции системы на сигнал с биржи, нужно как можно раньше “узнавать” о появлении этого сигнала. Для этого HFT система должна:
“слушать” множество различных потоков рыночных данных, в которых нужный сигнал может быть транслирован, например, потоки ордеров, сделок, статистики и т.д. — любой из этих потоков может быстрее других;
реконсилировать несколько (2 или 4) фидов в рамках одного потока данных — любой из этих фидов может быть быстрее других, но данные не должны дублироваться; строить “стакан” по данным из 2-х потоков, например, ордеров и сделок — любой из этих потоков может быть быстрее другого.
Кстати, непонятные какие-то ребята. Я сам FPGA не делал, так что могу что-то упускать, но:
1. Их скорости с современным железом можно и без FPGA. Тут, кстати, интересная тема — насколько в принципе стоит в такое вкладываться. Хотя, наверно, если надо порвать всех и сейчас, то сойдет.
2. Тест немного забавен. При таких скоростях тестировать на 90K сообщений это просто как-то... даже не знаю, что сказать. Что это за тест такой на пол-секунды?
3. latency & std сильно зависят от того, как настроена OS, они про это молчат.
4. Погуглил я их — ничего не слышно с 2017 года. Хотя может где-нить в хедж-фанде осели, вместе с железками.
Здравствуйте, StanislavK, Вы писали:
SK>Кстати, непонятные какие-то ребята.
Да, это был кстати один из поинтов, что "даже" у них было объединение фидов ... очень давно. То что их не слышно, я знаю, тоже интересно почему.
Те тесты, которые они выкладывают у меня вызывают доверие, по многим причинам. Методология. Технологии. Описание. Открытый код.
+ на 2017 год (они тестировали TCP Direct), что как бы показывает, что парни знают, с чем сравнивать. Это тоже очень важно.
SK> Я сам FPGA не делал, так что могу что-то упускать, но: SK> 1. Их скорости с современным железом можно и без FPGA.
Давайте, уточним. Latency ... не абстрактная скорость. Беру на "слабо" , предлагайте (ставлю на то, что ни DPKG ни netmap не сравнятся). Что бы latency была сравнима и дисперсия (посмотрите их отклонение max от 99.9%). Еще бы желательно и бюджет.
Даже сейчас, их цифры очень хороши для общего финтеха. Для российского HFT они где-то писали, что они забирали что-то около 70% ( если не ошибаюсь ) заявок по цене L1.
Для взорслых бирж, думаю они врядли будут конкуренто способны, хотя опять-таки без теста "боем" такое утверждать сложно.
SK> Тут, кстати, интересная тема — насколько в принципе стоит в такое вкладываться. Хотя, наверно, если надо порвать всех и сейчас, то сойдет.
Всем интересно. Но это 1 billion question. Мое предположение, что где-то с 2015 года этот рынок ( я только про HFT ) начал сжиматься.
И с каждым годом вкладывать надо больше, и обратно получаешь все меньше и меньше.
SK>2. Тест немного забавен. При таких скоростях тестировать на 90K сообщений это просто как-то... даже не знаю, что сказать. Что это за тест такой на пол-секунды?
Если не ошибся, то около 0.1 секунды. Да нормальный тест, для статьи. Плюс тут очень часто важно, не персентили, как таковые а дисперсия между ними. И MAX тоже. А это у них на высоте.
Это если вы хотите немного "приукрасить средниее показатели" тогда, круто прогонять долгие тесты, тогда среднее значение получается красивее.
SK>3. latency & std сильно зависят от того, как настроена OS, они про это молчат.
Я так понимаю, раз вся логика происходит у них на карте, настройки OS не должны так влиять, как например для TCP Direct.
Так, там тех основных настроек по большому счету не так много ( я про latency конфигурацию), отключение энергосбережение cpu, изоляция ядер для critical path кода, прерываний, и всего остального, правильный биндинг потоков на логические/физические ядра cpu ... 100% socket pooling ( в user space, конечно же). ну а дальше по обстоятельствам. От их уровня я бы ожидал как минимум этого.
SK>4. Погуглил я их — ничего не слышно с 2017 года. Хотя может где-нить в хедж-фанде осели, вместе с железками.
Будем надеятся за коллег.
Здравствуйте, HFTMan, Вы писали:
HFT>Здравствуйте, ned, Вы писали:
ned>>Здравствуйте, HFTMan, Вы писали:
HFT>90%, нет пока success rate, в разработке все, это же не стратега арбитража цен, это стратега арбитража датафидов от одной биржи, т.е. берем множество датафидов и в моменте ловим HFT>самые свежие данные, для ловли самых свежих данных таймштамп от биржи не нужен, а если он и есть-то погрешность его такова, что для построения непригоден. HFT>Latency variance от сотен наносекунд до десятков(иногда сотен) мс
Только сейчас увидел что это все с одной биржей. Что там арбитрировать то непонятно. Ну даёт она одни и те же фиды с разными задержками, может репликация подтормаживает. Но ты ж не сделаешь с этим ничего, данные то одни и те же.
Здравствуйте, VladiCh, Вы писали:
VC>Только сейчас увидел что это все с одной биржей. Что там арбитрировать то непонятно. Ну даёт она одни и те же фиды с разными задержками, может репликация подтормаживает. Но ты ж не сделаешь с этим ничего, данные то одни и те же.
RTFM, ссылок что вверху достаточно, там аргументы приводились. Хотя не все
Здравствуйте, Engler, Вы писали:
E>Здравствуйте, StanislavK, Вы писали:
SK>>Кстати, непонятные какие-то ребята. E>Те тесты, которые они выкладывают у меня вызывают доверие, по многим причинам. Методология. Технологии. Описание. Открытый код. E>+ на 2017 год (они тестировали TCP Direct), что как бы показывает, что парни знают, с чем сравнивать. Это тоже очень важно.
В смысле отличный? Там из всего что вы перечислили там только открытый код.
SK>> 1. Их скорости с современным железом можно и без FPGA. E>Давайте, уточним. Latency ... не абстрактная скорость. Беру на "слабо" , предлагайте (ставлю на то, что ни DPKG ни netmap не сравнятся). Что бы latency была сравнима и дисперсия (посмотрите их отклонение max от 99.9%). Еще бы желательно и бюджет.
Я даже говорить не хочу про 99.9%, разговор начинается с 99.999%
E>Даже сейчас, их цифры очень хороши для общего финтеха. Для российского HFT они где-то писали, что они забирали что-то около 70% ( если не ошибаюсь ) заявок по цене L1.
Все, что они написали, это то, что если отправить пакет быстрее других, они вероятнее других исполнится. Ну да есть такая тема, правда уже не везде. Про то, что они там забирали нет ни слова.
SK>> Тут, кстати, интересная тема — насколько в принципе стоит в такое вкладываться. Хотя, наверно, если надо порвать всех и сейчас, то сойдет. E>Всем интересно. Но это 1 billion question. Мое предположение, что где-то с 2015 года этот рынок ( я только про HFT ) начал сжиматься. E>И с каждым годом вкладывать надо больше, и обратно получаешь все меньше и меньше.
Это да, есть такое, но я не про то. Я про то, что их перфоманс сейчас можно выжать и на сравнительно обычном железе.
SK>>2. Тест немного забавен. При таких скоростях тестировать на 90K сообщений это просто как-то... даже не знаю, что сказать. Что это за тест такой на пол-секунды? E>Если не ошибся, то около 0.1 секунды. Да нормальный тест, для статьи. Плюс тут очень часто важно, не персентили, как таковые а дисперсия между ними. И MAX тоже. А это у них на высоте.
Чего? 0.1 секунды это нормальный тест? Этого просто тупо не достаточно.
E>Это если вы хотите немного "приукрасить средниее показатели" тогда, круто прогонять долгие тесты, тогда среднее значение получается красивее.
Долгие тесты как раз, для того, чтобы посмотреть на те самые не частые тормоза и странности. На среднее никто в своем уме смотреть не будет.
SK>>3. latency & std сильно зависят от того, как настроена OS, они про это молчат. E>Я так понимаю, раз вся логика происходит у них на карте, настройки OS не должны так влиять, как например для TCP Direct.
На них — нет, а на Solarflare с которым они сравнивают — да.
E>Так, там тех основных настроек по большому счету не так много ( я про latency конфигурацию), отключение энергосбережение cpu, изоляция ядер для critical path кода, прерываний, и всего остального, правильный биндинг потоков на логические/физические ядра cpu ... 100% socket pooling ( в user space, конечно же). ну а дальше по обстоятельствам. От их уровня я бы ожидал как минимум этого.
Так как настроек нет, то и ожиданий тоже нет.
Здравствуйте, StanislavK, Вы писали:
SK>Это да, есть такое, но я не про то. Я про то, что их перфоманс сейчас можно выжать и на сравнительно обычном железе.
ИМХО конечно, но на CPU с кастомным TCP в user space можно сделать в то же время, что и они на FPGA.
Что-то вообще все затихло. Но не страшно, нашел наконец с кем приватно пообщаться на интересную обоим сторонам тему HFT
Хотя над той стороной скорее всего NDA висит, в отличии от меня, вольного стрелка
Ориентировался на буржуйские источники, а оно вот-под носом 
