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

Синхронизация времени в HFT (High-frequency trading) мире

Уровень сложностиСредний
Время на прочтение6 мин
Количество просмотров28K

Точное определение времени и его синхронизация чрезвычайно важна в мире высокочастотной торговли.

Конечно же, синхронизация времени важна в общей инфраструктуре компании, думаю многие из вас встречались хотя бы раз с проблемами, вызванными некорректным временем на сервере, выполняющем ту или иную роль. Например, возможно некорректное формирование бэкапов, задержка в обработке запросов, некорректная интерпретация валидности сертификатов, ошибки аутентификации и авторизации и т. д. Тут на помощь придет NTP (Network Time Protocol) протокол, который широко распространен повсеместно, а далеко не только в HFT отрасли. Наилучшая точность синхронизации времени с помощью NTP будет порядка 1мс и то, в случае если NTP сервер находится в локальной сети с вашим сервером, а также оптимально настроен, например, дает опрашивать себя достаточно часто. Для среднего случая, когда NTP сервер будет использоваться из интернета, вы сможете добиться 10-100 мс точности, а если сетевой путь до источника времени будет совсем не идеален (зачастую колокация биржи может предоставлять только IPSec туннель в качестве доступа до вашей биржевой инфраструктуры), то и сотен миллисекунд.

Решение же торгового алгоритма об отправке заявки на биржу может и не опираться на абсолютное время. Алгоритм может брать в расчет только биржевое время, иными словами время, обозначенное во временных метках сообщений от биржи. Однако синхронизация времени на локальных часах и тут необходима для получения представления о том когда событие, которое произошло на бирже, пришло на сетевой интерфейс вашего торгового сервера. Это даст возможность более точно определять интервал времени за который анализируются биржевые данные торговой системой, а также более точно проводить симуляцию торгов вашего торгового алгоритма на исторических биржевых данных, ведь вы сможете понимать задержку, вносимую сетевым путем доставки биржевых данных. Привязка записываемого потока биржевых данных к точному абсолютному времени также позволит производить анализ возможности арбитражной торговли между двумя или более биржами, находящимися в разных географических локациях.

Для этих целей лучше всего подходит проставление временных меток непосредственно на сетевом устройстве вашего сервера, чтобы избежать ошибки связанной с неоднородностью задержки PCI шины, ядра ОС, и т. д. Для более точного определения времени и его точной «проштамповкой» на каждый входящий пакет нам потребуется доступ до сервиса PTP (IEEE 1588-2008 (PTP version 2)). А также клиентское сетевое устройство с возможностью hardware timestamping.

Говоря о доступе к источнику точного времени, тут есть два варианта, либо нам нужно самостоятельно покупать сервер точного времени PTP Grandmaster Clock, который, как правило, синхронизируется с GPS, GLONASS, арендовать место под его размещение, вывод его антенны на крышу дата центра, что в случае нашего стремления к точности порядка десятков наносекунд может в сумме стоить от одного до нескольких десятков тысяч долларов, в зависимости от страны, биржи, поставщика оборудования. Или же искать поставщика времени в зоне колокации или проксимити (не сама колокация, но связанный с ней машзал). Обычно это стоит до тысячи долларов в месяц, цена варьируется от поставщика и точности. Посредником предоставления услуги PTP может выступать ваш брокер, но нужно учитывать, что несмотря на то, что протокол PTP позволяет сетевым устройствам добавлять к измерениям времени задержку, вносимую каждым промежуточным сетевым устройством, существенно повышая точность, для этого крайне желательно, чтобы промежуточное сетевое устройство поддерживало PTP, и выполняло функцию Boundary Clock или вело себя как Transparent Switch.

Стоит также отметить что передовые большие биржи, для синхронизации времени между своими узлами начали использовать протокол синхронизации времени, разработанный для большого адронного коллайдера в ЦЕРНе, который обеспечивает саб-наносекундную точность для синхронизации более 1000 узлов через оптоволоконные или медные соединения длиной до 10 км. Названный в честь одноименного персонажа в романе Льюиса Кэрролла, протокол White Rabbit, использует ранее упомянутый PTP (IEEE 1588) для синхронизции, но также использует синхронный Ethernet (SyncE) для достижения синтонизации и модуль точного измерения разности фаз между эталонными часами и локальными часами на основе фазовых частотных детекторов. Однако отсутствие нативной поддержки данного протокола сетевым оборудованием, в том числе коммутаторами и сетевыми адаптерами, и его сложность, обычно ограничивает сферу его использования до самых развитых бирж, которые стремятся глубоко анализировать неидеальности своей инфраструктуры, и гарантировать равные технические условия для всех участников торгов. Клиентские же подключения к такой сети обычно не предусмотрены, по крайней мере на данный момент.

Итак, вернемся к протоколу PTP, как к доступному, но достаточно точному для большинства задач в HFT протоколу времени, и рассмотрим два нюанса настройки PTP сервиса. Основной принцип работы PTP базируется на калькуляции оффсета локальных часов от Master часов используя метки времени отправки и получения сообщений Sync, Follow-Up, Delay_Req и Delay_Resp:

Принципиальная схема работы PTP
Принципиальная схема работы PTP

Наиболее популярными сетевыми устройствами в HFT среде являются AMD XtremeScale (ранее Xilinx, еще ранее Solarflare) адаптеры и Cisco Nexus SmartNIC (ранее ExaNIC от Exablaze). В случае с XtremeScale наиболее точным демоном для работы PTP будет sfptpd, тогда как для Nexus SmartNIC производитель не педоставляет своих наработок для работы с PTP, и можно пользоваться ptp4l (LinuxPTP) или ptpd.

Выше перечисленные устройства имеют достаточно точные встроенные осцилляторы, но стоит не забывать что без синхронизации этих часов, их точность будет утекать со скоростью до нескольких десятков мс в день (доли нс в секунду). Для достижения максимальной точности синхронизации таймстемпинг пакетов должен происходить с минимальным интервалом от отправки пакета (или после получения), для этого необходимо использовать hardware timestamping, точность которого не будет подвержена неоднородной задержке в десятки микросекунд, вызванной сетевым стеком ОС.

На адаптерах AMD XtremeScale для возможности использовать hardware timestamp должна быть активна лицензия Plus, что можно проверить с помощью утилиты sfkey

# sfkey

p1p1,p1p2: 000F53650950

Product name Solarflare XtremeScale X2522‐25G Adapter

Serial number 2522...0104

Installed keys Plus

Для включения hw таймстемпов необходимо указать в конфигурационном файле /etc/sfptpd.conf строку указывающую на интерфейс, по которому будет происходить синхронизация часов:

timestamping_interfaces [<name>|<mac‐address>|*]

В качестве параметра указывается имя интерфейса, его мак адрес или * для включения hw таймстемпов на всех интерфейсах, которые его поддерживают. После применения конфигурации, для проверки актуального состояния можно проверить файлы /var/lib/sfptpd/state-ptp1 или /var/lib/sfptpd/topology где будут указано используется ли hw timestamping.

Для Nexus SmartNIC и LinuxPTP в конфигурационном файле /etc/linuxptp/ptp4l.conf в разделе #Default interface options стоит указать:

time_stamping hardware

А для общей проверки возможности использования hw timestamp на вашем устройстве, можно воспользоваться утилитой ethtool:

# ethtool -T enp1s0

Time stamping parameters for enp1s0:

Capabilities:

hardware-transmit (SOF_TIMESTAMPING_TX_HARDWARE)

software-transmit (SOF_TIMESTAMPING_TX_SOFTWARE)

hardware-receive (SOF_TIMESTAMPING_RX_HARDWARE)

software-receive (SOF_TIMESTAMPING_RX_SOFTWARE)

software-system-clock (SOF_TIMESTAMPING_SOFTWARE)

hardware-raw-clock (SOF_TIMESTAMPING_RAW_HARDWARE)

PTP Hardware Clock: 1

Hardware Transmit Timestamp Modes:

off (HWTSTAMP_TX_OFF)

on (HWTSTAMP_TX_ON)

Hardware Receive Filter Modes:

none (HWTSTAMP_FILTER_NONE)

all (HWTSTAMP_FILTER_ALL)

Также хочется рассмотреть ситуацию которая может возникать в процессе отладки или бенчмаркинга торгового алгоритма, но возможности синхронизировать время на вашем сетевом адаптере с высокой точностью нет. Например это может быть полезно для измерения времени между событиями, которые очень близки друг к другу, соответственно дрифтом (утеканием) осциллятора можно пренебречь. Для этого используется freerun mode.

Для его конфигурации на адаптерах AMD XtremeScale используется следующая инструкция в конфигурационном файле /etc/sfptpd.conf в разделе [general] :

sync_module freerun fr1

В то время как для Nexus SmartNIC и LinuxPTP в конфигурационном файле /etc/linuxptp/ptp4l.conf следует указать:

free_running 1

Когда sfptpd использует Freerun sync модуль, он синхронизирует системные часы и часы адаптера к локальному источнику времени. Источником может выступать как системное время, так и более точный осциллятор на вашем сетевом адаптере. Если в качестве локального источника времени используется часы адаптера, то при запуске sfptpd однократно устанавливает время часов адаптера по системным часам, и в последствии начинает регулярно синхронизировать все остальные часы по локальному источнику времени, в том числе и системные часы. В это время ваша система не синхронизируется с внешним источником времени. Таким образом, перед запуском sfptpd в режиме freerun важно предварительно выставить системное время, в противном случае ваши системные часы будут начинать отсчет с 1 января 1970 года.

Если в случае с AMD XtremeScale демон sfptpd сам перед запуском в freerun синхронизирует ваши часы адаптера по системным, то для Nexus SmartNIC придется самим позаботиться о том чтобы ваши PHC clock (часы адаптера) выставились по CLOCK_REALTIME (системным часам), для этого перед запуском ptp4l и phc2sys демонов, стоит воспользоваться утилитой phc_ctl указав в качестве аргумента те HW часы которые вы хотите выставить:

/usr/sbin/phc_ctl /dev/ptp0 set

Пожалуй, на этом я завершу этот небольшой дайджест, а также отмечу, что чем больше углубляешься в нюансы настройки точного времени, тем больше узнаешь про особенности исчисления времени и даже скорости вращения Земли. Например для приведения из версии всемирного времени UT1 (среднее солнечное время) в UTC могут к 2035 году перестать периодически прибавлять дополнительную секунду, а пока, вероятно, ее станут отнимать впервые с 1972 года, ведь Земля вдруг неожиданно ускорила свое вращение.

Теги:
Хабы:
+7
Комментарии4

Публикации

Истории

Работа

Ближайшие события