Медленное исполнение заявок в небольшой проп-трейдинговой фирме: куда уходит время и кто может это исправить

Медленное исполнение исправляет тот, кому принадлежит участок пути заявки, где теряется время, поэтому первая задача — найти этот участок. Ставьте отметки времени на каждой заявке в тех точках, которые вам видны, и самый большой разрыв подскажет, к кому обращаться: к вашим разработчикам или инженерной компании — если задержка внутри вашего софта, к хостинг-провайдеру — если дело в расстоянии, к брокеру — если задержка на его стороне.

Что значит «у нас слишком медленное исполнение заявок»?

Эта жалоба может означать четыре разные проблемы, и за каждую отвечает кто-то свой.

• Медленно идёт каждая заявка. Задержка примерно одинакова и тихим утром, и на открытии торгов. Это указывает на цену, которую платит каждая заявка, например расстояние, способ подключения к брокеру или медленную работу, которую ваш собственный софт выполняет перед отправкой каждой заявки
• Заявки идут быстро, пока рынок не оживится. На открытии торгов или на новостях задержка подскакивает. Где-то заявки ждут в очереди: за программой, которая не успевает, за лимитом сообщений или за машиной, занятой другой работой
• Заявки приходят вовремя, но исполняются поздно. Лимитная заявка стоит в стакане, пока кто-то не заключит против неё сделку, а на быстром рынке цена уходит. Отметки времени показывают, опоздала ли заявка. Какая цена была доступна, они показать не могут
• Запаздывает экран. Если цены на торговом экране отстают, трейдеры кликают поздно и винят исполнение. Это проблема рыночных данных, ей посвящена отдельная статья в этом блоге

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

Куда уходят миллисекунды между нашей системой и биржей?

На пути туда заявка проходит четыре участка, а подтверждение возвращается от брокера — иногда только после того, как биржа приняла заявку.

• Ваша сторона. Стратегия или трейдер принимает решение, заявка собирается, проходят ваши собственные проверки, и заявка отправляется. Задержки здесь дают работа перед отправкой, паузы программы, сетевые настройки или загруженная машина. Изменить этот участок могут ваши разработчики или инженерная компания
• Канал связи. Заявка идёт от вашего сервера до точки входа брокера. Задержку здесь добавляют расстояние, маршрутизация в интернете и лишние промежуточные узлы вроде VPN. Сократить её может хостинг-провайдер, провайдер колокации или сетевой инженер
• Брокер. Его гейтвей принимает заявку, прогоняет проверки и маршрутизирует её на биржу. Задержки здесь дают собственные системы брокера и обязательные проверки. Изменить их может только брокер; вы выбираете, как подключаться и каким брокером пользоваться
• Биржа. Матчинг-движок принимает заявку и отправляет обратно подтверждение. Времени здесь уходит мало: по данным Nasdaq, в её высокоскоростной сети колокации 10G полный цикл от заявки до подтверждения занимает меньше 50 микросекунд. Этот участок не изменит никто из тех, кого вы можете нанять; к нему можно только приблизиться

В США проверки брокера обязательны. Правило SEC 15c3-5 требует от брокера с доступом к рынку «не допускать ввода заявок, превышающих надлежащие заранее установленные пороги по кредиту или капиталу» и отклонять заявки, «превышающие надлежащие параметры цены или объёма». То же правило требует, чтобы эти проверки находились «под прямым и исключительным контролем брокера или дилера». Спросить брокера, сколько времени занимают его проверки, можно, но отключить их правило ему не позволяет.

Как выяснить, где теряется время?

Записывайте четыре отметки времени для каждой заявки:

• Решение: стратегия или трейдер решили отправить заявку
• Отправка: заявка ушла с вашего сервера
• Подтверждение: до вашего сервера дошло подтверждение брокера о том, что он принял заявку
• Исполнение: пришло сообщение об исполнении

От решения до отправки — это ваш софт. От отправки до подтверждения — канал связи и брокер, туда и обратно, плюс биржа, если брокер её ждёт. Спросите брокера, как это устроено у него. Для заявки, стоящей в стакане, время от подтверждения до исполнения — это в основном рынок.

Измерьте ещё одну величину: время сетевого пути туда и обратно от вашего сервера до точки входа брокера. Она покажет, какая часть интервала от отправки до подтверждения приходится на канал связи.

FIX — стандарт торговых сообщений, который поддерживает FIX Trading Community. Если вы подключены по нему, сообщения брокера несут две отметки времени: когда сообщение было отправлено и когда произошло событие, о котором оно сообщает. В спецификации FIX эти поля называются SendingTime и TransactTime, и брокер может сказать вам, чьи часы проставляют каждое из них. Рядом с вашими собственными отметками времени они показывают, какая часть пути туда и обратно пришлась на чью сторону.

Сравнивать свои отметки времени с брокерскими имеет смысл, только если и ваши, и брокерские часы идут точно. Правило FINRA 6820 требует от брокеров-дилеров, отчитывающихся в Consolidated Audit Trail, держать часы своих систем в пределах 50 миллисекунд от атомных часов NIST. По правилам ЕС участник торговой площадки, применяющий высокочастотную алгоритмическую торговлю, должен держать свои часы в пределах 100 микросекунд от UTC. По часам, которым разрешено расходиться на 50 миллисекунд, задержку в несколько миллисекунд не локализовать.

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

Затем посмотрите на самые медленные заявки. Отсортируйте заявки за неделю по времени пути туда и обратно и отметьте значение, которое превышает только одна заявка из ста; сделайте то же для первых минут после открытия торгов и для времени вокруг запланированных новостей. Среднее скрывает те моменты, на которые жалуются трейдеры.

Что может замедлять исполнение в небольшой проп-фирме?

Сначала проверьте эти шесть причин.

• API брокера работает через программу, которую вам приходится запускать у себя. Interactive Brokers, например, описывает свой TWS API как основанный на «подключении к Trader Workstation или IB Gateway», поэтому каждая заявка сначала проходит через одну из этих программ. Документация задаёт лимит по умолчанию в «50 запросов в секунду» на клиентское подключение и предупреждает, что в некоторых случаях при превышении этой частоты «часть заявок может быть поставлена в очередь и задержана». На этот случай Interactive Brokers предлагает перейти на свой FIX API. Если узкое место у вас именно здесь, спросите брокера, как ещё можно подключиться
• Сервер далеко от того места, куда уходят заявки. Офисная машина или далёкий облачный регион платят за расстояние дважды на каждой заявке, туда и обратно, и никакая правка кода этого не уберёт. Ради кратчайшего расстояния Nasdaq предлагает клиентам возможность «разместить свои серверы и оборудование в дата-центре Nasdaq». Прежде чем платить за колокацию, измерьте время сетевого пути туда и обратно от вашего сервера до точки входа брокера
• Перед отправкой заявки выполняется медленная работа. Запись заявки в базу данных, ожидание, пока строка лога попадёт на диск, или запрос к другому сервису, разрешена ли сделка, добавляют ожидание к каждой заявке. Когда база данных или диск заняты, ожидание растёт. Держите всё, что нужно заявке, в памяти, а записи делайте после того, как заявка ушла
• Сетевые настройки придерживают маленькие сообщения. Заявка — маленькое сообщение. В руководстве Linux сказано, что, если не выставлена опция сокета TCP_NODELAY, исходящие данные буферизуются, «пока не наберётся достаточно для отправки». Ваши разработчики могут проверить, выставлена ли она
• Программа встаёт на паузу. Некоторые сборщики мусора останавливают всю программу, пока чистят память. Даже у сборщика мусора Go, который делает большую часть работы параллельно с программой, есть «короткие паузы stop-the-world», и руководство по сборщику мусора Go называет их среди возможных источников задержки. Если пауза приходится на момент отправки заявки, заявка уходит с опозданием. Графики, бэктесты или отчёты, запущенные на той же машине, дают похожий эффект: заявка ждёт процессор
• Медленный собственный путь брокера. Его гейтвей, проверки и маршрутизация стоят на пути каждой заявки, а заглянуть внутрь вы не можете. Можно спросить, где его точка входа, какие типы подключения он предлагает, какие лимиты на сообщения действуют для вашего счёта и поделится ли он своими отметками времени по вашим заявкам

Как устраняется каждая причина и насколько велик объём работы?

• Интервал от решения до отправки велик на каждой заявке. Уберите медленную работу с пути заявки и проверьте сетевые настройки. Работа сводится к правке вашего кода, иногда — одной настройки
• Интервал от решения до отправки подскакивает в загруженные моменты. Найдите, что держит заявку: пауза, очередь, машина, общая с другими задачами. Работа сводится к правке кода или хостинга, а если очередь заложена в саму архитектуру — к перестройке пути заявки
• Интервал от отправки до подтверждения велик на каждой заявке. Перенесите сервер ближе к точке входа брокера или смените тип подключения. Рассчитывайте на договор хостинга и переезд либо на интеграционную работу под новое подключение
• Интервал от отправки до подтверждения подскакивает с ростом объёма. Найдите лимит, в который вы упираетесь, — у брокера или в вашем собственном подключении. Может хватить одного разговора с брокером или сокращения числа сообщений с вашей стороны
• Велик интервал от подтверждения до исполнения. Смотрите на тип заявки и на рынок. Это не инженерная задача

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

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

Кто может помочь, зависит от того, куда уходит время.

• Ваш брокер. Единственная сторона, которая может видеть и менять свою часть пути. Попросите у него отметки времени по вашим заявкам, его лимиты и варианты подключения
• Хостинг-провайдер или провайдер колокации либо отдел подключений биржи. Они сдают место рядом с точкой входа брокера или биржи и продают каналы связи до неё
• Вендор вашей торговой платформы, если вы торгуете через лицензированную платформу. Изменить её внутреннее устройство может только вендор, поэтому принесите ему свои отметки времени
• Инженерная компания, которая работает с торговыми системами. Она измеряет весь путь, а затем меняет или перестраивает части на вашей стороне, например путь заявки, риск-проверки и подключение к брокеру
• Ваши собственные разработчики, если они есть. С четырьмя отметками времени толковый разработчик может проверить каждую причину на вашей стороне пути

Кого бы вы ни наняли, сначала задайте четыре вопроса:

• Будете ли вы измерять, прежде чем предлагать исправление, и где именно будете ставить отметки времени?
• Разделит ли отчёт нашу сторону, канал связи и брокера и покажет ли самые медленные заявки, а не только среднее?
• По каждой цифре, которую вы называете: на каком перцентиле, под какой нагрузкой, какого числа?
• Если задержка окажется на стороне брокера, что вы нам скажете?

Если и на последний вопрос ответ — перестройка вашей системы, ищите дальше.

Где здесь место amBrain?

amBrain — инженерная компания из Еревана, Армения: строим low latency торговые платформы, matching engine и системы real-time bidding на Rust. amBrain диагностирует медленные системы в трейдинге, беттинге и AdTech: работающую платформу замеряют от начала до конца, и в отчёте названо, куда уходит время.

amBrain строит инфраструктуру алгоритмической торговли: исполнение заявок, рыночные данные и предторговый риск-контроль. Работа amBrain в трейдинге включает разработку торговых терминалов, систем управления заявками и биржевую интеграцию по протоколу FIX. amBrain берёт на себя проекты, застрявшие у другой команды, и доводит их до продакшена. Три формата: полная разработка, выделенная команда или инженеры внутри вашей команды.

Если вы в самом начале, запишите четыре отметки времени в обычный день и в загруженный. Принесите их тому, к кому обратитесь, — amBrain или кому-то ещё, — чтобы первый разговор начался с того, куда уходит время.

Частые вопросы

• Ускорит ли исполнение переписывание нашей системы на Rust? Только если время теряется внутри вашего софта, и только на том участке, через который проходит заявка. Rust даёт гарантии безопасности памяти «без необходимости в сборщике мусора», и это убирает паузы сборки мусора из списка причин. С загруженной машиной, расстоянием или брокером он ничего не делает
• Можно ли измерить, не меняя код? Да, если ваша система уже пишет в лог исходящие заявки и входящие подтверждения с отметками времени: путь туда и обратно от отправки до подтверждения уже есть в этих логах
• Даст ли более быстрое исполнение лучшие цены? Этого никто не может обещать. Скорость сокращает время между решением и прибытием заявки; цена, которую вы получите, зависит ещё и от ликвидности, типа заявки и того, что рынок делает тем временем