<HELP> for explanation

Блог им. 3XTR

Измерения RTT заявок TWIME в небоевом тестовом окружении

Здравствуйте.
Хочу поделится результатами замеров раунд трипа заявок, который я проделал на днях на тестовой системе, которая используется для разработки.

В тестовую систему входит
— боевое ПО с транзакционной частью на TWIME
— тестовое ПО эмулятор сервера TWIME
— тестовый стенд в виде двух обычных серверов с прямым Ethernet линком между собой

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

Предметом тестирования является внутренняя задержка системы при выставлении заявок Order на бижу и при получении ответов Response по протоколу TWIME. В качестве параметров теста используется интервал отправки между сообщениями в мкс и общее количество сообщений при отправке. Задержка считается по формуле Latency = RTT/2 и включает в себя затраты бизнес логики приложения, а также затраты всей сетевой части. Тестирование производится в различных режимах для того чтоб оценить поведение системы в условиях далеких от оптимальных. На мой взгляд, это наиболее интересная часть материала, поскольку в сети не трудно найти много тестов производительности TCP стека различных систем, но все они показывают свои оптимальные значения далеко не в тех условиях, в которых могут работать торговые роботы.

Итак. Первый тест — отправка 20 сообщений подряд.
Измерения RTT заявок TWIME в небоевом тестовом окружении
На графике заметна некоторая нестабильность и относительно высокое среднее значение задержки. Эффект понятен не до конца.

Второй тест — отправка 20 сообщений с интервалом 20 мкс.
Измерения RTT заявок TWIME в небоевом тестовом окружении
Первая заявка уходит со значительной задержкой, затем происходит оптимизация памяти.

Третий тест — отправка 20 сообщений с интервалом 2000 мкс.
Измерения RTT заявок TWIME в небоевом тестовом окружении
То же самое, с увеличение интервала отправки в сто раз ничего не меняется.

Четвертый тест — отправка 20 сообщений с интервалом 20мс.
Измерения RTT заявок TWIME в небоевом тестовом окружении
Средняя задержка незначительно выросла, причина в устройстве работы кешпамяти CPU.

Пятый тест — отправка 20 сообщений с интервалом около 2 сек
Измерения RTT заявок TWIME в небоевом тестовом окружении
Дальнейшее увеличение интервала отправки не приводит к деградации. Средний RTT соответствует значению первых заявок в предыдущих тестах.

Итог.
Тестирование показало нетерпимость системы к условиям, когда сигналы на отправку заявок поступают относительно редко. Ущерб от такой неэффективности может составлять десятки микросекунд и более. Что касается скорости протокола TWIME это наиболее легкий протокол с минимальным временным оверхэдом, издержки на обработку TWIME сообщений составляют сущие пустяки.

 

А в чем смысл частоты в 20 мксек, если обновление информации на бирже 30мсек? 
Активный Инвестор, у кого 30, у кого 3, а у кого и того меньше.
avatar

Cristopher Robin

Cristopher Robin, но очередь заявок обновляется раз в 30 мсек, зачем в нее несколько раз заходить через 20 мксек?
Активный Инвестор, что бы биржа и брокер списывали коммис в полтора раза чаще.... 
Активный Инвестор, 
очередь заявок обновляется раз в 30 мс
чего-чего, вы б называли вещи своими именами или пруфы сразу
avatar

flextrader

flextrader, разве на бирже другая частота обновления информации?
Активный Инвестор, другая
avatar

Андрей К

Активный Инвестор, 
она разная для разных типов инфы и если (правильно понял) цифра касается периодичности трансляции «констистентных» (для которых это св-во м.б. справедливым) блоков данных (которые ранее, да бэтчились плазовым стыком с периодом 30мс) с  то про неё тут

moex.com/n10696

но это никак не отменяет необходимость и возможность реагировать (на нашем рынке) с микросекундной быстротой
avatar

flextrader

flextrader, понял, период уменьшили до 10 мсек. То есть матчинг проходит раз в 10 мсек, что дает скорость в 1000 раз больше?
Активный Инвестор, Кристофер показал стандартную проблему кэширования CPU
avatar

Андрей К


Только зарегистрированные и авторизованные пользователи могут оставлять комментарии.

Залогиниться

Зарегистрироваться
....все тэги
Регистрация
UPDONW