Trading tools

Сотрудничество


 
Полезное
Подписка на RSS-ленту

Поддержать проект:

WM:
R757443857681
Z305778025977

Plaza2 и МТС

29
Июль

Plaza2 и МТС #5. Обработка заявок

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

25
Июнь

Plaza2 и МТС #4. Время

Потоки

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

  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 мс, без учета корректировок по таблицам маркетдаты, т.е. на самом деле ещё точнее.

28
Май

Plaza2 и МТС #3. Потоки

Потоки

Предыдущие посты под тэгом «Plaza2 и МТС» были посвящены введению в разработку МТС на Plaza2. Они представляли собой обзорный вью по устройству плазы и помочь начать разработку МТС для Plaza2. Начиная с этой публикации фокус будет смещен в сторону вопросов разработки МТС, по поводу которых (я надеюсь) можно будет подискутировать в комментариях.
Сегодня речь пойдет о потоках (threads), точнее о преимуществах и недостатках однопоточного клиента по сравнению с многопоточным. Согласно документации, существует возможность использовать клиента с несколькими потоками, и для этих целей реализовано 2 различные версии P2ClientGate.dll – для работы с STA либо MTA типами апартаменов при использовании COM-интерфейсов клиента шлюза. Рассмотрим, как может быть организован однопоточный и многопоточный клиент.

Однопоточный клиент:
Здесь всё просто, и, как мне кажется без вариантов: в одном потоке последовательно выполняется цикл, состоящий из следующих этапов:

  1. получение новых рыночных данных, состояний заявок, позиций по инструментам (выгребаем всё, что возможно вызовами ProcessMessage)
  2. расчет индикаторов, параметров рынка, торговых сигналов
  3. расчет новых цен заявок
  4. отправка транзакций на удаление, перемещение и выставление новых заявок

Пункты 2-4 должны исполняться максимально быстро. Любое промедление, любой лишний вложенный цикл, полный повторный перерасчетный цикл на каждой итерации вместо частичного перерасчета, где это возможно, или цикл с полным перебором для поиска, там где возможен индексный – всё это увеличивает время исполнения цикла и уменьшает эффективность работы торгового алгоритма.

Многопоточный клиент:
Каждый поток данных плазы получаем в отдельном программном потоке (thread), плюс один или несколько программных потоков на транзакции. Реакция торговой системы на события в виде транзакций возможна из любого потока при детектировании определенной рыночной ситуации (данные в одном из потоков плазы, например сделки), либо какие-то сложные триггеры.

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

Я однозначно за однопоточного клиента:

Во-первых, многопоточность – это зло, которое следует избегать во всех ситуациях, кроме тех, когда она объективно необходима. В основном случаи такой необходимости – это когда один поток может или должен работать независимо от других и результат его деятельности не влияет на ход выполнения остальных потоков. Например, при работе со шлюзом ASTS, транзакции можно отправить только синхронно и соединение будет заблокировано, до тех пор, пока не будет принят ответ на транзакцию. В этом случае необходимо отправить транзакцию в отдельном потоке через отдельное соединение, при этом получение и обработка рыночных данных происходит независимо. Бывают случаи, когда один поток не может не влиять на другой – это значит придется заниматься таким малоприятным занятием, как синхронизация потоков – это очень аккуратное программирование и отлов трудноуловимых багов.

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

А зачем объективно может быть нужен многопоточный клиент для плазы?

06
Фев

Plaza2 и МТС #2

В протоколе Plaza2 применяется push-технология распространения данных. Это означает, что данные клиенту поступают по мере их возникновения, без запроса. Клиент определяет, какие данные он будет получать во время работы на первоначальном этапе согласования схемы обмена данными между клиентом и сервера Plaza2.

Топология, или что к чему подключается, описано в документе P2ClienGate.doc в разделе «Топология сети». Простыми словами схему подключения можно описать так: конечное клиентское приложение (робот) соединяется и обменивается данными с роутером по протоколу TCP, либо по протоколу LRPCQ на ваш выбор. Роутер соединяется и обменивается данными по протоколу TCP с инфраструктурой биржи. Роутер – это приложение Windows, которое также было установлено на ваш компьютер из дистрибутива вместе с библиотекой P2ClientGate, если в процессе установки были отмечены соответствующие опции. Роутер может быть установлен на той же машине, что и клиент, либо клиент и роутер могут находиться на разных машинах. Возможно 2 варианта установки роутера (опции в мастере установки): Роутер может быть установлен как служба Windows, либо как приложение. О протоколе LRPCQ в документации написано так:

LRPCQ является простым транспортом, основанным на использовании shared-memory в ОС Windows. Использование LRPCQ возможно только при запуске приложения-клиента и роутера на одном компьютере. Протокол LRPCQ имеет меньшие накладные расходы, чем TCP, передача сообщений между приложением и роутером с использованием LRPCQ будет происходить быстрее.

Файлы установленных модулей, включая настройки и log файлы, находятся в папке установки ( по умолчанию C:\Program Files\P2FORTSGate\ ).

Данные от сервера поступают в виде реплик. Реплика- это команда от сервера на изменение/добавление/удаление записей таблиц (заявок, сделок, и т.д). Таблицы сгруппированы в потоки репликационных данных.

На этапе согласования схемы репликации клиент сообщает, какие потоки данных требуются для получения, какие таблицы в потоках и какие поля в таблицах. Программно это осуществляется посредством набора COM-интерфейсов, описанных в документации. Клиент назначает набор функций обратного вызова для обработки реплик каждого необходимого потока данных. Поступающие от сервера реплики обрабатываются путем вызова одного из методов ProcessMesage ( либо ProcessMessage2 или ProcessMessage3) интерфейса IP2Connection. В зависимости от потоков данных и действиям, к которым относятся вновь пришедшие реплики, метод ProcessMessage последовательно вызывает зарегистрированные процедуры обратного вызова клиента, передавая в них параметры реплик. Метод ProcessMessage должен вызываться как можно чаще, иначе новые реплики накапливаются в очереди и очень быстро теряют свою актуальность с течением времени. Если у клиента накапливаются очереди в течении сессии, значит он теряет в своевременности получения рыночных данных из-за неэффективности реализации. Для контроля состояния очереди необходимо в файле P2SimpleReplClient_trace.ini в каталоге установки найти и установить в 1 (вместо точек) значение в строке «New message added to recvList. Size: %d=…» В ходе записи логов можно просматривать записи вида New message added to recvList. Size: xxx в файле лога P2ClientGate.log.

Транзакции (заявки на покупку/продажу, снятие, перемещение заявок) также организованы как методы интерфейсов. На каждую транзакцию от сервера приходит ответ в виде реплике с информацией об успешном или не успешном результате выполнения транзакции, причиной неудачи (если транзакция не выполнена), а также информацией, связанной с исполнением транзакции (например присвоенный номер заявки). Реализован метод асинхронной отправки транзакций, т.е. сообщение-транзакция отправлятся на сервер и код клиентского приложения продолжает исполняться без задержек на ожидание ответа от сервера. Когда ответ будет получен – он встанет в очередь вместе с остальными репликами и будет получен при следующем вызове функции ProcessMessage. Обработка ответов на транзакции осуществляется похожим механизмом, что и остальные реплики: при инициализации клиента регистрируется специальная функция обратного вызова, которая и будет вызвана из ProcessMessages для обработки ответов на транзакции

18
Янв

Plaza2 и МТС

Plaza2

Решил открыть новую рубрику “Plaza2 и МТС” на ttools.ru и написать серию постов на эту тему. Тема в последнее время очень популярна, и, надеюсь, найдет интерес. Речь о Plaza2 пойдет в контексте разработки фронт-систем алгоритмического трейдинга

Основные причины, по которым применение Plaza2 в торговых автоматах популярно (на мой взгляд) две: это относительное преимущество в скорости обработки транзакций и получения рыночных данных, а также повышение надежности за счет сокращения цепочки обмена данными от “биржа-сервер брокера-терминал клиента – торговый алгоритм клиента” до “биржа-торговый алгоритм клиента”
Читать полностью »

Скальперский привод для Quik QuikOrdersDOM

Подписаться на блог ttools.ru по email: