Pull to refresh
5
0
Send message

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

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

Идея здесь больше в оптимизации софта для получения огромного кол-ва котировок (через некоторый аггрегатор) с нескольких бирж.

Думаю я постарался подробнее ответить на вопрос в этом комментарии — habr.com/ru/company/itiviti/blog/567336/#comment_23260260
Интересный и сложный вопрос! Тут у каждого может быть свое мнение. Мое личное (сформированное на основе опыта работы с этой сфере) — рынок становится более ликвидными и эффективным, а это определенно хорошо для как людей, так и для человечества.
Да, речи о colocation одновременно с десятком бирж быть не может. Здесь конкретный сетап — есть аггрегатор расположенный в определенном месте. Он собирает котировки с десятка рынков (нормализирует и предоставляет как aggregated feed). Стратегия хочет эти данные потреблять и посылать заказы. Задача сделать это максимально быстро и не захлебнуться!

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

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

Вот тут мне трудно комментировать. Для большого кол-ва ликвидных инстурментов я знаю не так много софтверных решений который могут показать подобные характеристики. Могу судить только по тому, что наши клиенты, занимающиеся low-latency, торговлей остаются весьма довольны такими результатами.
Да, конечно, посылать устаревшие цены неправильно! Конкретно мы этот момент решаем тем что храним данные в некотором объекте, который описывает текущее состояние инструмента (best price, order book, market status etc), а в очереди кладем событие на его обновление. Когда срабатывет таймер мы по состоянию объекта можем понять, было ли оно уже послано через Priority Queue или его надо отправить.
Хорошее резюме! Наверное, только одна неточность — flush происходит не для группы сообщений (пачки), а для последнего состояния цены для конкретного инструмента, так как только оно имеет значение в данный момент!
На самом деле все ориентированные на 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 рынка, оставляя скорость внешнего нетворка за скобками, т.к. она уже минимально возможная.
Добрый день!
Да, порядок котировок для конкретного инструмента гарантируется, иначе бы трейдеры бы и вправду ныли, а точнее не пользовались бы нашим софтом :)

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

Information

Rating
Does not participate
Registered
Activity