Какой протокол быстрее?

На нашем сайте мы решили разместить статистику Раунд-трипа разных протоколов и инструментов:

FIX_CURR USD
Plaza2 Si и TWIME Si
TWIME: GAZ, LUK, VTB...
Plaza2 RTS
SPB_BINARY

http://fkviking.ru/roundtrip.php
Графики можно увидеть на сайте и поиграть с ними.

FIX Plaza II FAST TWIME MOEX SPB exchnge

viking_algotraders

Viking

Москва

960

с 24 августа 2015

28 Комментариев

nik
22 июля 2016, 08:02
не подписывать оси — моветон
да и для подобных граффиков лучше строить распределение.
0
nik
22 июля 2016, 08:03
пс. судя по кардинальной разднице между TWIME Si и TWIME GAZ, LUK, VTB мерить вы вообще не умеете и софт написан очень криво.
0
- Андрей К
  22 июля 2016, 08:42
  nik, там если порыться, много вводных данных. Вроде как два тестовых стенда на разных картах. Может тесты у Викинга с разных машин. Нужно пояснение. Хотя я еще в прошлый раз попытался подметить про правильность софта.
  0
- Viking
  22 июля 2016, 10:50
  Графики с раундтрипами собираются с боевых логинов с живой торговли.
  0
  - nik
    22 июля 2016, 11:03
    Viking, не должны зависить. на промсерверах биржи общая очередь заявок на все инструменты.
    0
    - Arbitrg
      22 июля 2016, 13:38
      nik, очередь одна, а ранудтрип разный) важны нюансы и их может быть множество, особенно если метки собирают с боевых подключений. Очень разные показатели могут быть, например, с разных стратегий отличающихся по тому, как они посылают заявки — тейкер/мейкер. У тейкеров будет стабильно длинее раундтрип чем у мейкеров. Происходит это по тому, что человек который котирует он всегда в рынке в том числе когда цена «вкусная» и когда цена находится в низковолатильной фазе и никому не нужны — в таком раскладе средний раундтрип будет занижен.
      Если человек торгует только тейкером, то у него раундтрип есть только тех заявок, которые были «вкусные» т.е. тех которые хотело бОльшее кол-во участников рынка а это уже значит что возрастает нагрузка на шлюз и далее увеличенный раундтрип.
      И дальше если разбирать, то можно вот еще что нарыть: участников на разных инструментах разное кол-во, кол-во выпущенных заявок на «вкусные» цены, следовательно тоже разное. Очевидно, на Si-шке в разы больше трейдят, чем на остальных и следовательно в пиковые моменты, когда цена «вкусная», скажем на лукойле, в шлюз посылается транзакций гораздо меньше, чем в такие же моменты для Si-шки. А учитывая ограниченные возможности наших шлюзов и раундтрип возрастает в одни моменты сильнее чем в другие.
      Я думаю, что если делать чистые тесты, например просто кидать заявку в пустоту каждые n-секунд по разным инструментам, то в этом случае раундтрип у них будет одинаковый. А вот если снимать метки по живым стратегиям, то разница будет неизбежна и чем слабее пропускная способность шлюза, тем сильнее будет разница.
      +3
    - Cristopher Robin
      23 июля 2016, 01:37
      nik, задержка возникает не там, промы грубо говоря занимаются только раздачей маркет даты, транзакционные сообщения там пыль, объемы трафика не сопоставимы.
      0
maxman
22 июля 2016, 11:06
Правильные карточки стоят у вас, но проведите нормальный benchmarking вашей библиотеки с использованием аппаратных timestamps, а то прочитав
Меряем время отправки и приема сетевых пакетов на проводе
на цифры ваши смотреть совсем не хочется :(
0
- Viking
  22 июля 2016, 14:30
  maxman, мы и используем аппаратные timestamps.
  И sockperf умеем гонять
  +1
  - maxman
    22 июля 2016, 15:29
    Viking,
    Так будьте технически грамотными людьми, разрисуйте подробней ваш test harness, покажите где вы ставите метки и как по этим меткам вы вычисляете latency.
    Вы публикуете результат своего исследования на достаточно широкую публику, при этом вы коммерческая организация, а не исследовательская, но после первого прочтения складывается впечатления, ну очередной «брат финансист» измеряет, что-то на проводах, а потом данные волшебным образом попадают в компьютер.
    0
    - Viking
      22 июля 2016, 15:37
      maxman, мы аппаратно ставим метки на пакеты на сетевой карте тестирующего сервера. Таким образом измеряется time to market тестируемого сервера с роботом
      +1
      - nik
        22 июля 2016, 19:41
        Viking, если это так, то заявленные мение 2мкс у 30% выглядят нериалестично. уверены, что действительно все правильно меряете?
        -1
        Viking
        23 июля 2016, 00:56
        nik, заявленные 30% менее 2мкс где?
        0
        nik
        23 июля 2016, 11:32
        Viking,
        SiXX_test HWAdds 0 < 407; 2 < 407; 4 < 407; 8 < 21; 10 < 0; 12 < 0; 16 < 0; 32 < 0; 48 < 0; 64 < 0; avg = 6582nsec
        -1
        Viking
        23 июля 2016, 20:11
        nik, здесь 95% измерений больше 4 микросекунд (2<407) и 5%>8. Среднее 6.5 микросекунд. Ни одного измерения меньше двух
        0
- Viking
  22 июля 2016, 14:43
  maxman, а какой benchmarking считаете нлрмальным?
  +1
  - maxman
    22 июля 2016, 16:04
    Viking,
    Для каждого типа измерения должна быть своя метрика. И четкое понимание, что вы измеряете, в данном контексте между чем и чем осуществляется замер.
    Допустим, если вы, что покрутил с драйверами карточек 10G и настройками операционки, поставьте простой тест.
    Эмуляция market data ( 1/2 UDP round trip ) отправляете с одного сервера UPD пакет 64 байта с меткой, в обратку эмулируете execution feed (1/2 TCP round trip)
    отправляете TCP пакет 400 байт с меткой. Прогнали объем данных, сохранили логи, потом скриптом прошлись посчитали стату, показали совой min, max, average.
    Вот ваши абсолютные значения и понятно, что и как вы измеряете.
    Если речь про вашу библиотеку и вы делаете замеры трактов обработки данных, то тоже самое, сперва опишите, что вы измеряете и самое главное как.
    Не хочу комментировать измерения на примере вашей стратегии, это как то application specific очень. На мой взгляд banchmark должен быть по generic стадиям обработки. Допустим ваша замечательная библиотека декодирует поток заявок, фильтрует, нормализует данные и строит стакан, далее вы предоставляете ваше API для дальнейшей работы. Опять разрисуйте test harness, покажите, что вы, допустим, измеряете от выхода MAC на вашей 10G карточки (где и ставится аппаратная метка) до callback'a вашего API. Возьмите один торговый день на moex постройте гистограмму распределения плотности потока UDP пакетов рыночных данных.
    Сразу будет понятно, что 99.99% сообщений как раз 64 байта (2 инкрементальных апдейта). Вот и измерьте вашу латентность на 50%, 99%, 99.9% и 99.99% сообщений. Тогда ваши результаты будут понятны и интересны широкому кругу людей.
    Ну и не забываем, что по классике computer science latency это величина измеряющая задержку от первого байта на входе системы до первого байта на выходе системы. А от первого на входе до последнего на выходе это уже throughput.
    +1
    - Viking
      22 июля 2016, 16:09
      maxman, годы работы в НИИ не прошли бесследно)
      +1
Cash
22 июля 2016, 14:48
У вас на Twime есть значения меньше 200мкс, это как-то совсем мало, есть точки, где вообще около 20мкс, вы уверены в точности замеров?
0
- Viking
  22 июля 2016, 15:33
  Cash, это баг в измерялке. Мы его уже исправили. Такое получалось, когда до прихода orderAdded заявки снималась по clOrdId
  0
  - Cristopher Robin
    23 июля 2016, 01:51
    Viking, как можно снять заявку, которая еще не стала в стакан? Расскажите, очень полезная фича)
    +1
    - Viking
      23 июля 2016, 07:56
      Cristopher Robin, в фиксе при помощи снятия по clOrderId а в плазе и твайме при помощи massCancelRequest
      0
Viking
22 июля 2016, 16:05
madman, годы работы в НИИ не прошли бесследно;)
0
- maxman
  22 июля 2016, 16:07
  Viking,
  Я бы сказал, отпечатались тяжелым наследием.
  0
kapodes
04 октября 2016, 11:30
По графикам получается, что FIX быстрее всех как я понял? А если сравнивать FIX / PLAZA2 на SPECTRA? А то я слышал, что спектра работает на плазе и фикс в неё перепаковывается, поэтому на срочке FIX должен PLAZA2 проигрывать.

А подобные данные по сравнению FAST/PLAZA2 у вас есть? Интересно проигрывает ли фаст плазе по тому же потоку сделок и ордеров.
0