Блог им. fkViking

Анализ TWIME против PLAZA2

    • 11 июня 2016, 09:53
    • |
    • Viking
  • Еще

Анализ TWIME против PLAZA2

Все использованные далее замеры проведены 7 июня 2016 года.

Рис 1. 
Анализ TWIME против PLAZA2
На рисунке 1 раунд трип заявки на выставление (микросекунды): серым — TWIME, желтым – PLAZA2, синим – фикс срочного рынка.
Видно, что клиенты подключены к одному и тому же пром-серверу, т.к. графики сильно коррелируют.
Средний раунд трип в этот день: фикс 989 мкс, PLAZA2 842 мкс, TWIME 841 мкс
В данной ситуации TWIME на одну-две заявки опережает PLAZA2 по скорости выставления, а PLAZA2 опережает фикс. Видно так же, что TWIME менее стабилен, чем фикс и PLAZA2. Из-за этого среднее время раунд трипа у TWIME и PLAZA2 почти одинаковое.
Такими же обнадеживающими были наши замеры TWIME в первые две недели его работы, на основе которых мы стали рекомендовать его клиентам.

Но, как выяснилось теперь, не всегда графики коррелируют. Посмотрите на следующий рисунок.

Рис 2. 
Анализ TWIME против PLAZA2
На рисунке 2 раунд трип заявки на выставление (микросекунды): представлена статистика по трем одинаковым конфигурациям TWIME, работающим параллельно на одном сервере на разных ядрах, серым – TWIME с рисунка 1.

Если разные роутеры PLAZA2 демонстрируют сильные расхождения в раунд трипе, это объясняется тем, что роутеры, на которых проводятся замеры, подключены к разным пром-серверам с большой разницей в нагрузке. Из такой ситуации есть выход. Можем переподключить роутер к пром-серверу с меньшей нагрузкой. Но с TWIME есть проблема. Во-первых, не получается переподключиться: выжидая десять минут после отключения показатели раунд трипа остаются теми же. Так же в TWIME нигде не написано, каким путем заявки идут на биржу. Ясно, что TWIME может отправлять заявки в ядро несколькими маршрутами, и не все маршруты хороши. Вопрос возможности выбора маршрута пока что остается открытым.

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

 

 

★14
Подпишите рис2. Что где.
avatar

Андрей К

 Кстати, а почему вы не думаете, что на twime, ваш код может давать нестабильность?
avatar

Андрей К

вот что нужно на главную выносить
Что то вы не то делаете. Совсем не то.

avatar

Cristopher Robin

>Ясно, что TWIME может отправлять заявки в ядро
>несколькими маршрутами,
уточните о каких маршрутах речь? от куда до куда?
avatar

crazyFakir

crazyFakir, тоже было интересно. Ведь боевой ip один.
avatar

Андрей К

crazyFakir, это была рабочая гипотеза причины просадок. После комментария сотрудников биржи ее отмели. Стало известно, что железо, на котором запущен твайм, не справляется с нагрузкой. В этом основная причина спайков.
avatar

Viking

Viking, а биржа не говорила, планируют ли они обновить это железо? Если да, то в какие сроки?
avatar

Schurik

Спасибо за инфо
avatar

korn

уточните про плаза роутер, он был биржевой или ломаный?
Александр, для чего это спрашиваете?
avatar

Андрей К

Андрей К, если это биржевой роутер то тут только один вариант, уровень программистов этого тестера == уровню программистов биржи которые писали роутер. хотя нет немного хуже, так-как в роутере есть сжатие а это еще + время. вообще нужно больше деталей, мы сейчас обсуждаем черный ящик. вообще не понятно как они работают с сетью, как разбирают сообщения. быстрые парни говорят TWIME быстрее плазы.
Александр, даже без быстрых парней видно, на скрине он быстрее. Правда на практике возможно и не на 1-2 заявки =)
avatar

Андрей К

Андрей К, вообще странно что биржа не сделала аналог mqsender для TWIME
Александр, ну twime в первую очередь позиционируется как аналог fix, только бинарный, что ведет к несомненным плюсам для разработчика. А в фиксе mqsender'а нет, всему свое место =)
avatar

Андрей К

Андрей К, да я срать хотел как что позиционируют, дайте нормальную возможность алготрейдеру.
Александр, вам дали прекрасную возможность исключить роутер из постановки заявки =))
кстати, чем не устроил twime?
avatar

Андрей К

Андрей К, меня всем устраивает
На рис.2 неплохой результат только у котировщика с 75000+ заявок за тестовый период. У роботов, показавших плохой результат по 1000 заявок. Код просадок не дает. Тесты без отгрузки сетевого стека.
avatar

Viking

Viking, спасибо за ответ.
avatar

Андрей К

Viking, я почему спросил про код, я человек въедливый и делаю замеры и изучения кода под разным углом. Профилировщик может и не показывать просадок. Но например, если замерить определенный участок кода 100т раз, в силу внешних, либо каких то других факторов, он может выйти из обычной колеи в определенные моменты. Ну например во время копирования памяти и одновременного вывода на экран. Такая ситуация может наложить отпечаток на вашем графике twime.

plaza может избежать такие моменты, так как выведена в отдельную единицу в виде роутера, да и вообще чужая разработка вне нашего кода =))

сам такие замеры в течении всего дня не делал, поэтому и спрашиваю вас. Прошу понять правильно.
avatar

Андрей К

Плаза не дает таких спайков, как твайм в данный момент. Поэтому проскальзывание на ней будет меньше.
avatar

Viking

У нас нет вывода на экран и копирования памяти, о котором мы бы не знали. Источником задержек здесь могут быть прерывания таймера и сетевой стек ядра в данной конфигурации. Но это +100 мкс в самом худшем случае. Стек ядра немного тюненый.
avatar

Viking

Попробую на следующей неделе тестовый пологировать целый день, будет ли там такая ситуация.
avatar

Андрей К

Подтверждаю, надеялись на лучшее с TWIME
Алексей Никитин, и что получили на деле?
avatar

Андрей К

На деле получили надежду на то что биржа поправит подкрутит)))
Алексей Никитин, я думаю, первоочередная цель twime — это выключить из цепи постановки заявки звено роутера. Это несомненный плюс для не огромно бюджетных hft
avatar

Андрей К

А какие минимальные значения раундтрипов выставления заявок на разных шлюзах у вас получаются?
avatar

Schurik

Schurik, последнюю неделю фикс сэлта показывал 470 мкрс
плаза по-разному медиана порядка 900 мкрс
на форуме биржи наши трейдера выкладывают свою статистику : http://forum.moex.com/viewtopic.asp?t=30036
 кто хочет можем провести сравнительные замеры, алгоритм там описан.
avatar

Viking

Viking, расскажите лучше о «Минимальный дистрибутив Linux, настроенный под low latency»
Надо учитывать, что получение ответа на заявку и появление ее в системе это разные вещи. Величина задержки от момента отправки до попадания в систему не измерена. Тема не раскрыта. Все выводы сделаны с допущением, что время от отправки до получения ответа = времени от отправки до появления в системе.
avatar

SECRET

SECRET, «Надо учитывать, что получение ответа на заявку и появление ее в системе это разные вещи. Величина задержки от момента отправки до попадания в систему не измерена. согласен в первой части» — согласен. Раундтрип — это косвенный показатель скорости работы.
«Все выводы сделаны с допущением, что время от отправки до получения ответа = времени от отправки до появления в системе» — таких допущений здесь не сделано. В ядре биржи у нас отсечка времени не ставится по понятным причинам. А отсечка, которая ставится самой биржей, рассинхронизирована. Единственный вариант точно мерить скорость — сравнивать номера заявок, отправленных одновременно с разных шлюзов. Сравнение номеров дало хороший результат по твайму в первые дни. Но и раундтрип тогда был стабильнее теперешнего. У нас написано, что твайм на 1-2 заявки опережает плазу — это как раз результат теста номеров заявок. Но пожалуй вы правы. Тему можно было бы раскрыть получше. В следующий раз будем в первую очередь выкладывать графический анализ теста на номера заявок, а раундтрип второй очередью, как косвенное свидетельство.
avatar

Viking

«Из такой ситуации есть выход. Можем переподключить роутер к пром-серверу с меньшей нагрузкой.» — Вы так написали как-будто можно легко переключиться на менее нагруженный пром-сервер :) команда такая — подключиться к самому быстрому пром :)
avatar

matrix

matrix, ога-ога (ждал кто же откомментирует этот момент топика),

с учетом того, что наебиржа декларирует рандомный (относительно клиента) проброс на промы с нет-балансеров.
avatar

flextrader

flex trader, вообще ПРОМ непонятный элемент инфраструктуры биржи, если его не считать «сетевым» устройством, тогда биржа нарушает самое главное правило FIFO. А уж схема работы балансировщика большая тайна moex, но насколько я понимаю забивают 1 пром под завязку клиентами, потом начинают на следующий роутить подключения… такая вот х… я балансировка :) 
*очень ведь сложно сделать балансировку, чтобы на всех промах было равное кол-во клиентов и еще сложнее сделать одинаковый аппаратный конфиг у каждого прома, чтобы задержка была примерно одинаковая для всех клиентов, про одинаковое время например через PTP и мечтать не приходиться, хотя на любой бирже это работает по умолчанию :) 2016 год вроде бы — скоро xeon будет с FPGA и ASIC, а тут на moex такое :) 
avatar

matrix


теги блога Viking

....все тэги



2010-2020
UPDONW