Каким может быть стек технологий для высокочастотного трейдинга

В нашем блоге на Хабре мы уже рассказывали о том, какие дата-центры используются для размещения «железа» с торговыми движками бирж и софта для высокочастотного трейдинга. Сегодня мы пойдем дальше и поговорим о том, каким может быть весь стек технологий, необходимых для HFT-торговли.

Forbes приводит рассказ об этом сооснователя сервиса Robinhood (мы писали про этот проект здесь), болгарина Влада Тенева.

До начала работы над собственным мобильным приложением для онлайн-трейдинга Тенев работал в компании Chronos Research, которая разрабатывала сверхбыстрый софт для HFT-компаний, банков и хедж-фондов. Во многих случаях конкретная конфигурация используемой для торговли инфраструктуры зависела от того, какими активами предстоит торговать, а также какие стратегии поведения на рынке будут использоваться. К примеру, инфраструктура, подходящая для работы на валютном рынке, далеко не всегда может быть конкурентоспособной на рынке акций или деривативов.

В 2011 году Chronos разработала две программные платформы, объединенных под единым именем Zardoz (как фильм с Джоном Коннери) — одна из них работала на стандартном x86 железе и могла быть использована для торговли с задержками на уровне 15 микросекунд. Другая была оптимизирована для работы с железом фирмы Tilera, при ее использовании задержки можно было снизить до значений меньше 5 микросекунд. Каждая из систем предназначалась для размещения на условиях колокации в дата-центрах бирж.

Для частных трейдеров больший интерес представляет платформа для архитектуры x86, поэтому Тенев описывает именно ее.

Передача данных

Как правило, торговая площадка предоставляет одно физическое соединение (в виде оптоволокна) к движку биржи, в котором происходит «сведение» заявок разных продавцов и покупателей. Для работы с системой Chronos рекомендовалось наличие канала с пропускной способностью в 10 гигабит, поскольку в таком случае снижалась задержка сериализации, однако редко когда пользователям удавалось получить канал шире 1 гигабита. Через одно физическое соединение передаются рыночные данные (обычно через TCP или UDP multicast) и отправляются приказы (через TCP или UDP unicast).

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

Оборудование

Для объединения всего этого многообразия специалисты Chronos рекомендовали использовать высокоскоростной коммутатор вроде 24-портового Arista. Использование такого оборудование вносило межпортовую задержку на уровне 350 наносекунд. Также некоторые трейдеры использовали свитч от Blade Networks (куплена IBM), который также работал на Fulcrum ASIC, а стоил дешевле.

Кроме того, для успешной работы HFT-трейдеру нужна высокоскоростная сетевая карта с драйвером для работы в режиме ядра (kernel bypass driver). Тенев упоминает сетевой адаптер 10G-PCIE2-8C2-2S от Myricom для UDP-трафика и Solarflare Flareon Ultra SFN7122F Dual-Port 10GbE PCIe 3.0 Server I/O Adapter – Part ID: SFN7122F для TCP.

Софт

У каждой из этих карточек есть нужные драйверы для работы в режиме ядра, что позволяет отправить и получать данные по TCP и UDP в пользовательском пространстве. Переключение контекста — дорогая операция в плане задержек, поэтому в HFT-трейдинге ее нужно избегать. Поэтому обработка важных данных выносится в ядро.

Для работы с системой Chronos поставлялась и «кастомная» версия Gentoo Linux, которую поддерживали разработчики софта.

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

Код логики платформы был написан на С и являлся событийно-ориентированным (в цикле статей мы рассказывали о создании бэктестера, работающего по такой схеме). Разработчики создали собственные «безблокировочные» структуры данных – в итоге каждый поток работал в бесконечном цикле, опрашивая на вход свой собственный FIFO.

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

Другие материалы на тему инфраструктуры трейдинга:

This entry passed through the Full-Text RSS service - if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.