Что такое tick-to-trade и как его замерять

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

Например, приложение автоматизированной торговли слушает поток market data, анализирует его и в случае благоприятной комбинации сигналов отправляет на биржу приказ о продаже или покупке определенного финансового инструмента. Или несколько приказов. Время, прошедшее с момента поступления события в рыночных данных до момента, когда приказ сформирован закодирован и вытолкнут в сеть называется tick-to-trade. В кратце, это скорость реакции вашей системы на заданное ключевое событие.

Все звенья цепи на простом примере

В рассматриваемом примере есть несколько границ, на которых мы можем замерять latency. Они отражают примерно следующую последовательность событий, связанных причинно-следственной связью:

• внутри биржевого движка произошло сведение двух ордеров (т.е. именно это событие является точкой отсчета и причиной всех последующих событий)
• внутри информационной системы биржи сформированы данные об этом событии — trade tick, содержащий символ инструмента (symbol), объем сделки (qty/volume) и цену (price)
• информационная биржа выталкивает эти данные на Market Data Gateway
• данные покидают Market Data gateway и прибывают на Ethernet-коммунтатор сопряжения с клиентскими системами, слушающими эти рыночные данные
• данные покидают коммутатор сопряжения и прибывают на сетевую карту (NIC) клиентской торговой системы
• данные на Ethernet-карте формируются в Ethernet frame
• происходит прерывание операционной системы, которая считывает данные из буфера и формирует пакет IP,
• из IP пакета формируется UDP пакет (так как рыночные данные обычно идут по протоколу UDP)
• ОС передает UDP-пакеты в приложение и вызывает код приложения, который должен эти пакеты обработать
• встроенный FIX-движок приложения разбирает побайтово пакеты и декодирует их в свое внутреннее представление — это скорей всего FIX-сообщение
• FIX-сообщение передается внутрь приложения, где оно разбирается на части, анализируется, возможно — отбрасывается, возможно — преобразовывается во внутреннее представление (класс какого-то объекта),
• если поступившее сообщение представляет интерес, вызывается обработчик этого сообщения, некая внутренняя логика приложения, которая определяет, что должно произойти при поступлении данного события, формируется (или не формируется) ответ, например, ордер на покупку (Buy order) по определенной цене и в определенном количестве
• ордер отправляется на биржу, для чего все действия повторяются в обратном порядке
• кодирование внутреннего представления в FIX-сообщение
• FIX-сообщение — в TCP-пакет
• TCP-пакет в IP-пакет
• IP-пакет — в Ethernet-frame
• Ethernet frame в байты из сетевой карты на коммутатор сопряжения
• коммутатор сопряжение — в FIX-gateway биржи (O/E gateway)
• FIX-gateway биржи — в matching engine биржи

Я постарался изобразить эти все события на рисунке ниже. Каждое звено цепочки событий я для удобства обозначил буквами.

Несколько замечаний

Обратите внимание на некоторые детали:

• рыночные данные как правило раздаются биржами по UDP-протоколу, приказы же отправляются по TCP-протоколу.
• поток приказов и исполнений (orders and executions) и рыночные данные (market data) разделены физически: они обслуживаются разными шлюзами, и разными коммутаторами
• сетевое сопряжение между клиентом биржи и биржей может быть разным. Например, клиент должен подключаться к коммутатору биржи не напрямую, а через свой собственный коммутатор. Все зависит от конкретной биржи.
• на стороне клиентской системы приём рыночных данных и отправка ордеров в принципе тоже могут быть разделены, если в торговой системе установлено две сетевые карты (или одна сетевая карта с поддержкой двух раздельных Ethernet-портов). Но нередко, что на все про все используется только одна скоростная сетевая карта типа Mellanox, Exablaze или Solarflare.

На схеме подразумевается, что система автоматизированной торговли расположена рядом с биржей (co-located) и напрямую слушает «сырые» рыночные данные с биржи. Торговая система может слушать рыночные данные от вендора (Reuters или Bloomberg), т.е. они будут поступать в систему не напрямую с биржи, а через посредника, т.е. еще через несколько дополнительных звеньев, каждое из которых будет вносить свой вклад в увеличение tick-to-trade.

На каждом этапе существуют возможности оптимизации и сокращения tick-to-trade до минимальных значений. На какие только ухищрения не идут инженеры финансовых торговых систем, чтобы опередить своих конкурентов в этой гонке (так называемая «race to zero»)! Но об этом речь пойдет в отдельных статьях данного блога.

Замер tick-to-trade

При замере latency надо сначала выяснить, что именно мы меряем. Исходя из рисунка, Tick-to-trade может считаться по разным границам, например:

• время от поступления данных до момента сформирования ордера внутри приложения (G -> H),
• время от поступления данных до момента формирования FIX-сообщения (G -> I), или
• время от поступления данных до времени, когда Ethernet появился на сетевой карте компьютера (G -> J)
• время от поступления данных до времени, когда Ethernet появился на сетевом коммутаторе (G -> K)

В каждом случае замер производится разными средствами. Замеряя latency на всех звеньях цепочки (E -> F -> G -> H -> I -> J), мы точно можем определить, где именно происходит наибольшая задержка, чтобы думать, как ее можно устранить. Например, измерение участка G -> H осуществляется путем сравнения timestamps в начале исполнения программной логики и в конце ее исполнения. Измерение на участке E — > J можно осуществлять с помощью утилит tcpdump, pcap или Wireshark. Измерения на участке D -> K утилитами предназначенными для сетевых коммутаторов (Corvil и др.)

Если копнуть чуть-чуть глубже

На рисунке в упрощенной форме показано, что клиентская система посылает на биржу только ордера. Но в реальности на ордера биржа посылает ответы (execution messages), это могут быть отказы в исполнении ордера (rejects), подтверждения (acks) и сообщения об исполнении (fills / partial fills).

В определенных случаях важно также не только оценить скорость передачи ордера, но и следить за тем, как быстро происходит обработка ответа от биржи. Т.е. latency замеряется не только по цепочке H -> K, но и по обратному направлению — K -> H. Сравнивая время в точке K при отправке сообщения и время в точке K при получении ответа, можно оценить так называемую внешнюю latency (external latency) — т.е. latency самой биржи. Это необходимо, например, в тех случаях, когда надо выяснить, то ли в нашей системе идет просадка производительности, то ли это на самой бирже что-то начало тормозить.

Реклама