Как стать автором
Обновить

Тюним thread model: Как нам удалось получить котировки с десятка американских бирж за 3 микросекунды

Время на прочтение 8 мин
Количество просмотров 7.7K
Всего голосов 12: ↑12 и ↓0 +12
Комментарии 28

Комментарии 28

Добрый день. Я так понял, вы базируетесь в Спб.

Правильно понимаю, через вас можно торговать на Америке гражданам РФ?

Добрый день! Да, основная разработка Tbricks базируется в СПб.
А вот клиенты наши это не физические лица, а организации — трейдинговые компании, фонды и т.д.

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

Добрый день!
Да, порядок котировок для конкретного инструмента гарантируется, иначе бы трейдеры бы и вправду ныли, а точнее не пользовались бы нашим софтом :)

И в GCD и в Disruptor подходе это гарантируется некоторым маппингом между конкретным потоком и набором инструментов которые он обрабатывает.
НЛО прилетело и опубликовало эту надпись здесь
Поддерживаю. Очевидно, что автор что-то упускает по метрологии.

Да даже 3мс - по сути только в локальной сети, в лучшем случае датацентр у этого же провайдера.

Или скоростные трейдеры уже втайне от всех пользуются модемом на запутанных фотонах
На самом деле все ориентированные на low-latency рынки предоставляют colocation услуги. Поэтому low-latency системы всегда расположены там, иначе, как справедливо замечено, сеть просто нивелирует преимущество в скорости.

Примеры
CME — www.cmegroup.com/trading/colocation/co-location-services.html
Eurex — www.eurex.com/ex-en/support/technology/connectivity/Connectivity-2393262?frag=2444324

Собственно low-latency системы обычно меряются насколько быстро они сами могут обрабатывать и реагировать на события c рынка, оставляя скорость внешнего нетворка за скобками, т.к. она уже минимально возможная.
НЛО прилетело и опубликовало эту надпись здесь
Да, речи о colocation одновременно с десятком бирж быть не может. Здесь конкретный сетап — есть аггрегатор расположенный в определенном месте. Он собирает котировки с десятка рынков (нормализирует и предоставляет как aggregated feed). Стратегия хочет эти данные потреблять и посылать заказы. Задача сделать это максимально быстро и не захлебнуться!

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

> Скорость обработки маркет-данных стратегиям давно уже считают в наносекундах и 3us никого не удивят.

Вот тут мне трудно комментировать. Для большого кол-ва ликвидных инстурментов я знаю не так много софтверных решений который могут показать подобные характеристики. Могу судить только по тому, что наши клиенты, занимающиеся low-latency, торговлей остаются весьма довольны такими результатами.
НЛО прилетело и опубликовало эту надпись здесь
Мы все-таки работаем в разных сегментах, большое количество компаний (и Tier1 banks и узкоспециализированные автоматические маркет-мейкеры) далеко не всегда могут позволить себе поддерживать даже софтовое in-house решение, не говоря уже о железном.
НЛО прилетело и опубликовало эту надпись здесь

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

Интересно чем и как измеряете производительность и задержки на каждом этапе?

В основном используем https://lttng.org для end-to-end измерений и RDTSC для локальных измерений.

Он показал, что 42% сообщений в итоге проходили через Throttle Queue. А убрав проблему outliers, мы увидели улучшение времени доставки сообщений до подписчиков более чем в два раза с 7 мкс до 3 мкс практически для всех событий (до 99.9 перцентили)

Кратко про содержание статьи: раньше гейтвей был хорош, и данные флушались клиенту в течении одной микросекунды. Новые реалии в несколько раз увеличили задержку данных на гетвеи. Прикрутили новую модель обработки сообщений. Задержка упала с 7 до 3 мкс, но не всегда. Подкрутили ещё: стали делить быстрые и медленные котировки на два пула. Далее собирать и флушить пачкой чтобы уж задержка была чаще 3 мкс.

Заголовок должен быть таким: Как нам удалось получить котировки с десятка американских бирж и обрабатывать нашим новым гетвеем за 3 мкс.

Хорошее резюме! Наверное, только одна неточность — flush происходит не для группы сообщений (пачки), а для последнего состояния цены для конкретного инструмента, так как только оно имеет значение в данный момент!

_Вторая хитрость в том, что если выполняется какое-то заранее оговоренное условие, например, если цена меняется слишком сильно (скажем +/- 1%), то стоит сразу же сделать Flush и не ждать, когда сработает таймер._

И это называется дельта-модуляция...

Если получателю доставлены сообщения из priority, а потом начинают доезжать из throttle, как он понимает, что они старые? Он вынужден сортировать их у себя? Может быть их вообще уже не нужно учитывать, ведь алгоритму нужна последняя цена.
Да, конечно, посылать устаревшие цены неправильно! Конкретно мы этот момент решаем тем что храним данные в некотором объекте, который описывает текущее состояние инструмента (best price, order book, market status etc), а в очереди кладем событие на его обновление. Когда срабатывет таймер мы по состоянию объекта можем понять, было ли оно уже послано через Priority Queue или его надо отправить.

А зачем всё это, какая от этого польза? Имеется ввиду не выгода отдельного биржевого спекулянта, а какая польза человечеству, цивилизации в целом? Что для неё улучшилось от того, что один спекулянт купил/продал на микросекунду быстрее другого?

Интересный и сложный вопрос! Тут у каждого может быть свое мнение. Мое личное (сформированное на основе опыта работы с этой сфере) — рынок становится более ликвидными и эффективным, а это определенно хорошо для как людей, так и для человечества.
На самом деле это хороший вопрос, но на него сложно дать простой ответ.

Если совсем коротко: некоторым участникам финансового рынка, чья роль критически важна для его функционирования, нужно уметь достаточно быстро принимать и менять торговые решения при существенном изменении мира, в противном случае они как часть отрасли не смогут покрывать стоимость ведения бизнеса (техника, софт, персонал, соблюдение регулирования, налоги) + разумная прибыль, и тупо исчезнут. Самый, наверное, иллюстративный пример — опционные маркет-мейкеры, трейдеры, являющиеся продавцом и покупателям последней инстанции в опционах, торгуемых на бирже. Грубо говоря, если никто для своих целей не торгует инструмент, который Вам нужен сейчас, вы сможете купить у маркет-мейкера. Для них «картина мира» это кривая процентных ставок, поверхность волатильности и, самое главное, цена базового инструмента. Первое (кривая ставок) меняется не очень часто, второе (поверхность волатильности) — заметно чаще, а уж последнее (цена базового актива) меняется тысячи раз в секунду. У маркет-мейкера куча проблем, которые ему нужно решать, но в контексте скорости самая важная состоит в том что если маркет-мейкер будет тормозить, то другой участик (арбитражер) может совершить с ним серию сделок, которая будет выгодна для арбитражера, но с точки зрения маркет-мейкера будет гарантированной потерей денег. Что интересно, наличие арбитражеров _тоже_ важно для выполнения финансовой системой своих функций, как минимум для того чтобы финансовый инструмент имел одну наблюдаемую цену, пригодную для использования, а не много разных.

В разное время регуляторы и торговые площадки пытались решить эту проблему на своей стороне, например, рассматривалась возможность дать маркет-мейкерам возможность скармливать торговой площадке апроксимацию своих теоретических моделей, вводились механизмы подтверждения решения провести сделку маркет-мейкером, вводились механизмы дискретных аукционов, вводились механизмы, ограничивающие торговлю между некоторыми классами участников (маркет-мейкеров с арбитражерами) etc etc. Некоторые из идей где-то прижились, некоторые — нет. В итоге получается что если посмотреть на глобальный сетап маркет-мейкеров, торгующих на многих площалках одновременно, то получается что о latency нужно очень и очень беспокоиться, так как в-общем у маркет-мейкера нет защиты от систематической потери денег кроме как быть очень быстрым.
Что-то у меня цифры не сходятся…
Если биржа в штатах, их там несколько, для примера возьмем Нью-Йорк и Чикаго, расстояние между ними 1145 км по прямой, т.е. это около 3.86 мс. или 3680 мкс,
Если агрегатор между ними, то 1908 мкс.

Это без затрат на время обработки сообщений.
У вас сервера, скорее всего не на colocation с агрегатором,
Далее клиенты у вас тоже скорее всего не на colocation с вами, но допустим, что все сидят ровно между Нью-Йорком и Чикаго и у всех все работает вообще без затрат времени, тогда ваши 3-10 мкс, вообще ничего не решают, так как время доставки сообщения в 272 раза больше…
Идея здесь больше в оптимизации софта для получения огромного кол-ва котировок (через некоторый аггрегатор) с нескольких бирж.

Думаю я постарался подробнее ответить на вопрос в этом комментарии — habr.com/ru/company/itiviti/blog/567336/#comment_23260260

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

Хорошо, постараемся запилить публикацию про Disruptor и GCD в ближайшем будущем!

Зарегистрируйтесь на Хабре , чтобы оставить комментарий