Plaza2 и МТС. Время

Доброго времени суток, уважаемые Дамы и господа!

Наконец-то решил завести блог на Смартлабе, и это моя первая статья здесь
Несколько месяцев назад я начал писать цикл статей о Plaza2 и механических торговых системах (HFT в основном) и сейчас подумал, что тема то наверняка интересна и близка многим читателям (и писателям) Smart-lab'а.
Многие считают, что HFT — это секретный алгоритм плюс быстрый робот на собственном сервере, а еще лучще собственном шлюзе размещенный в метре от ядра биржи и соединенный с ним, непременно, золотым проводком. Плюс  самый быстрый в мире датафид с запада, всё это и есть залог успеха. Однако, есть еще такой важный аспект, как техническая реализация. Как бы не был продвинут торговый алгоритм и насколько золотой не была бы инфраструктура, торговый робот, технически реализованный неэффективно имеет мало шансов. В этой статье речь пойдет о синхронизации времени машины, на которой работает торговый алгоритм с временем ядра плазы.
 
При реализации торговых автоматов важно как можно точнее определять текущее время сервера в реальном времени. Это необходимо для:

1. измерительных задач (например, измерить задержку маркетдаты)
2. максимально точного исполнения частей торгового алгоритма, связанного со временем (например, прекратить открывать позиции после 16:30 до 16:31)
3. Для максимально точного сохранения рыночных данных с привязкой к текущему моменту для последующего исторического тестирования
4. Наверое, для чего-то еще.

На первый взгляд, задача достаточно проста: необходимо лишь получить время сервера, которое транслируется каждую секунду в таблице heartbeat и скорректировать время локальной машины, на которой работает торговый алгоритм.
Такой способ подходит для грубой синхронизации, с точностью примерно до секунды. Но ведь когда речь идет о Plaza2, подразумевается, что возможно торговый алгоритм будет высокочастотным и необходима максимально возможная точность. Здесь придется столкнуться с четырьмя нюансами, которые необходимо учитывать.
Первый связан с механизмом распространения рыночных данных (в том числе и таблицы heartbeat и остальных таблиц с временной меткой, которые понадобятся для синхронизации). Дело в том, что рыночные данные рассылаются биржей клиентам с определенной задержкой. Точнее, не так, чтобы абсолютно все данные задерживались ровно на N миллисекунд; каждая порция данных накапливается в течение этого времени и рассылается клиентам целиком. То есть, если событие произошло сразу после отправки клиенту очередного кванта данных, то клиент будет уведомлен через интервал N, а если событие произошло непосредственно перед очередной рассылкой, то уведомление будет отправлено клиенту без задержки. С развитием инфраструктуры биржи значение времени этой задержки постепенно уменьшается и на текущий момент значение N составляет 100 мс.
Второй нюанс связан с общей проблемой точной синхронизации двух компьютеров. Дело в том, что ни одни часы в мире не могут идти абсолютно точно, и по истечении определенного временного интервала двое самых точных часов без промежуточной синхронизации покажут существенное расхождение. Компьютерные часы в среднем могут убегать или отставать на несколько секунд за сутки. Учитывая, что накопление погрешности с течением времени может бать нелинейным, синхронизировать 2 компьютера достаточно сложно. Поэтому для синхронизации понадобится динамическая и максимально частая сверка часов.
Третий нюанс связан с технологией измерения времени операционной системы (Windows). Точкой отсчета для измерения времени, очевидно, является время локальной машины, на которой работает торговый алгоритм, более доступного точного источника времени в данной ситуации просто нет. Существует несколько функций Windows, предназначенных для получения текущего значения времени, однако не все они одинаково полезны. Для максимально точных замеров времени потребуются функции максимального разрешения. Для этих целей обычно испльзуют функции QueryPerformanceFrequency / QueryPerformanceCounter, или/и процессорную инструкцию RDTSC
Четвертый нюанс связан с особенностями синхронизации времени самого ядра биржи. Время ядра плавно подстраивается по внешнему GPS-датчику, благодаря чему обеспечивается точная синхронность времени в ядра биржи с мировым временем, но приводит к большим нелинейностям разности счета времени сервера торговой системы и ядра.
В потоках плазы есть несколько таблиц, с помощью которых можно синхронизировать время сервера торговой системы и ядра биржи. Это таблицы, которые содержат время события в «реальном времени» одним из полей. Это таблица всех сделок, собственно heartbeat, таблица полного лога заявок (если подключена). Синхронизируя время по этим таблицам можно получить точность синхронизации [0..N], а точнее, если учесть время на сетевые задержки маркетдаты T [T..N+T]. T зависит от качества маршрута между шлюзом биржи и торговым автоматом и минимизируется инвестициями в и работой над торговой инфраструктурой. Такой разброс уже гораздо лучше, чем использование heartbeat. На этом этапе можно легко добиться отклонений [0..150мс], или 75 мс в среднем. Если синхронизировать время по каждому событию из этих таблиц, то каждая синхронизация может как улучшить так и ухудшить точность, по сравнению с предыдущей синхронизацией. Причем, если пришедшее в новой реплике время меньше чем текущее – однозначно синхронизация улучшает результат, если больше – улучшает в половине случаев. То есть, если будут получены лучшие показатели, то такую синхронизацию всё равно имеет использовать частично, для корректировки случаев, если время в реплике меньше, чем установленное время в момент последней синхронизации.
Добиться лучшего результата можно, используя собственные заявки. В ответе шлюза на транзакцию добавления/перемещения заявки содержится время изменения параметров заявки, т.е. если при отправке заявки и при получении ответа запомнить локальное время, это и будет интервал времени локальной машины, внутри которого находится (можно считать посередине) время сервера, которое указано в реплике-ответе шлюза на постановку заявки. Таким способом можно получить синхронизацию серверного времени с локальным с точностью ± 15 мс, без учета корректировок по таблицам маркетдаты, т.е. на самом деле ещё точнее.
Предыдущие статьи можно прочитать здесь