colocation why & benefits

Долгожданное и для меня самого продолжение, некоторая пауза, надеюсь пошла на пользу качеству в плане логики и информативности.

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

Обозначим также слабые места интернет соединения и влияние стабильности пропускной способности (bandwidth) публичных сетей на эффективность электронной торговли. Фактический материал кропотливо собирался на основе информации, полученной как из публичных источников, так и из контактов с представителями фьючерсного брокера Mirus Futures и технологического провайдера Zen-Fire.
colocation
Начну с определения колокации (colocation) – это физическое размещение сервера клиента в локальной сети, в которой необходимо соединение с иными сетевыми устройствами и серверами (в нашем случае – с серверами брокера и его системы риск-менеджмента). Реализуется без включения интернета в качестве промежуточного коммуникационного уровня между системами трейдера и брокера, предполагает мониторинг соединения сервисными службами технологического провайдера, предоставляющего подобную услугу. Позволяет достичь максимально возможного уровня надежности прямого соединения и ультранизкой латентности (ultra-low latency).
о тестировании торговых систем
Ключевым фактором автоматизации торговли финансовыми инструментами помимо создания и формализации торговой идеи, позволяющей обеспечить статистическое преимущество на рынке, безусловно, является тестирование торговой системы на исторических данных, затем на out of sample и, наконец, на реальных деньгах.
Тестирование на real money является, пожалуй, наиболее финансово затратным процессом и на реальном рынке является стадией, когда в силу повышенной чувствительности системы к мгновенной ликвидности маркета выясняется нежизнеспособность системы вообще, либо повышенная требовательность к качеству исполнения и латентности (в частности, проскальзывание превышает пороговое расчетное значение устойчивости торговой системы).
Здесь отметим, что стандартные серии данных (часы, минуты, кратные им и так далее) не позволяют однозначно учитывать и оценивать такие вещи, как внутрибаровые гепы, отсутствие достаточной ликвидности на определенных ценовых уровнях и много чего еще интересного, вернее для девелопера системы совсем даже не интересного. С учетом того, что это касается как входов, так и стоп-приказов, результаты тестирования системы могут оказаться совершенно виртуальными.
Когда такое происходит, первое, что должны сделать разработчик и тестер торговой системы – произвести тестирование системы на исторических тиках. Казалось бы, открывается возможность без открытых рыночных рисков существенно улучшить реалистичность тестов.
Наличие тиковых данных с глубиной, соответствующей биржевому «стакану» дает материальную основу для написания по сути дела специализированных алгоритмов, с высокой степенью достоверности эмулирующих алгоритмы непрерывного встречного аукциона, применяемого биржей для торговли на реальном рынке. То есть речь идет о реализации такого инструмента как matching algorithms.
В последующих выпусках я коротко коснусь технических вопросов и принципов функционирования подобных алгоритмов. Оговорюсь сразу, мне не известны случаи реализации чего-либо подобного в открытых для retail системах, возможно, меня коллеги поправят.
внимание, засада!
НО… Ничего заранее определенного и эффективного, как выясняется, не имеет места.
Дело в том, что авторизованные дистрибуторы исторических данных биржи не собирают тиковые данные посредством биржевого датафида, а всего лишь перепродают тиковую историю, предоставляемую биржей.
Соответственно эти данные, как любые обработанные и заархивированные тики, будут отличаться от реального фида и иметь другие отметки времени, без миллисекундных меток (что не позволяет достоверно оценить интенсивность торгового потока в единицу времени, помимо иных не менее важных факторов).
И здесь весь ужас заключается в том, что реалтайм тиковый поток от брокера отличается от исторических данных, в том числе и продаваемых самой биржей, а торговый алгоритм должен принимать решения, исходя из этих данных. Поэтому результатам тестирования на покупной истории и торговым идеям, на ней построенным, доверять нельзя. Исторические данные должны быть полностью идентичны тому потоку, который дает брокер, через которого мы собираемся торговать. И это грустно, ибо коллекционировать надо самому из реалтайма, а другого выхода нет. (с) Adventurer forex.kbpauk.ru, вносились только стилистические правки.
Дополню цитату мыслью о том, что по моему мнению, надлежит тестировать еще и качество фида, предоставляемого брокером, с учетом качества соединения и прочих факторов, лежащих за пределами рыночных и операционных рисков, то есть дополнительные торговые риски для системы создаем мы сами.
коллекционирование данных – реальное время
О ритейл софте здесь речи не идет по определению, только высокоскоростной фид через API, и вот почему.
CME для систем прямого доступа устанавливает минимально допустимое условие – минимальная пропускная способность – не менее 70 транзакций в секунду. Мое понимание мне говорит о том, что под транзакцией понимается здесь обработка всех сообщений, исходящих от биржевого централа и требующих ответной реакции присоединенной системы.
Тем не менее, оценим исходя из того предположения, что при 20 сделках в секунду мы имеем общее число событий, включая всего лишь 5-уровневый стакан при явно заниженном количестве изменений в 1 изменение на уровень при заданном количестве сделок. Получаем 260 событий в секунду, и это только на 1 инструмент, то есть латентность клиентской системы на инструмент при заданной плотности тиков не должна превышать 3,8 миллисекунды на инструмент.
К слову, биржевой стакан, получаемый через API содержит уже 10 уровней Level 2.

При этом по самому резвому инструменту – ES были моменты и по 100 трейд тиков в секунду. Достаточно.
Поскольку доставка всех пакетов данных клиенту с контролем доставки со стороны провайдера невозможна физически, остановимся на ряде аксиоматических тезисов.
Как из публичных источников (путем утверждений и отсутствия опровержений), можно говорить о том, что Zen-Fire транслирует все, что уходит с биржи (в смысле потока данных). 
Но вопрос здесь заключается вот в чем. Насколько стабильна пропускная способность (даже не латентность) сети? Как было выше отмечено, быстродействие клиентского программного обеспечения является также критичной функцией. Все это в совокупности обуславливает организацию потока данных по принципу – что доехало, то и получите.
Полный биржевой поток по значительному числу инструментов всех уровней можно видеть только при размещении сервера в непосредственно датацентре биржи (сотни инструментов). Сравните с вышеприведенными цифрами требований к производительности системы – всего лишь по одному инструменту. В случае необходимости получения полной глубины рынка в разрезе всех ордеров, на скорости, соответствующей биржевому потоку, существенным препятствием является стабильность bandwidth интернет соединения, в том числе даже на хостингах премиум уровня.
При поставке неаггрегированных биржевых данных технологический провайдердолжен уделять приоритет именно трейд тикам, поскольку именно на реальных трейдах построены алгоритмические компоненты 99.9% систем алгоритмической торговли, в том числе высокочастотной.
некоторые факты и статистика
При колокации в датацентре Zen-Fire сервер клиента устанавливается во внутренней сети брокера, за firewall. Только это по сравнению со всеми прочими спецификациями прямого подключения позволяет улучшить латентность минимум на 50 микросекунд.
При колокации с Zen-Fire ожидаемая латентность соединения между сервером клиента и сервером datafeed и order routing составляет менее микросекунды. При соединении во внутренней сети по 10-гигабитному каналу показатели латентности доступа могут составить порядка 50 наносекунд.
Достигается это за счет настройки в премиум — пакете от Zen-Fire протокола прямого сетевого доступа к памяти (RDMA), который в настоящее время активно применяется в индустрии высокопроизводительных вычислений (HPC, high-performance computing).

По данным Zen-Fire, стабильный поток коммуникаций не прерывался с 2003 года, несмотря на очень внимательное изучение разнообразных публичных источников, опровержений этому заявлению мною не найдено, да и сомнительно.
Статистически, на проверку ордера системой риск-менеджмента тратится порядка500 микросекунд – 1 миллисекунды, время от поступления в систему риск-менеджмента брокера и до появления ордера в системе биржи – порядка 5-7 миллисекунд. Информацией по латентности доставки ордеров в случае применения премиум пакетов пока, к сожалению, не располагаю.
Напоследок. Mirus Futures, благодаря Zen-Fire, работает в той же network, что в частности, один из крупнейших инвестиционных банков JP Morgan, т.е. для клиента Zen-Fire, технически открыты все те же возможности по высокоскоростной торговле с низкой латентностью.
Отдельное спасибо представителю фьючерсного брокера Mirus Futures Светлане Орловской, без доброжелательно критического участия которой статья в том виде, в котором она представлена сообществу, родиться, безусловно, не могла.

 

http://westtrd.livejournal.com/3468.html