Блог им. fkViking

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

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

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

http://fkviking.ru/roundtrip.php 
Графики можно увидеть на сайте и поиграть с ними.
★12
не подписывать оси — моветон
да и для подобных граффиков лучше строить распределение.
avatar

nik

пс. судя по кардинальной разднице между TWIME Si и TWIME GAZ, LUK, VTB мерить вы вообще не умеете и софт написан очень криво.
avatar

nik

nik, там если порыться, много вводных данных. Вроде как два тестовых стенда на разных картах. Может тесты у Викинга с разных машин. Нужно пояснение. Хотя я еще в прошлый раз попытался подметить про правильность софта.
Графики с раундтрипами собираются с боевых логинов с живой торговли.
avatar

Viking

Viking, не должны зависить. на промсерверах биржи общая очередь заявок на все инструменты.
avatar

nik

nik, очередь одна, а ранудтрип разный) важны нюансы и их может быть множество, особенно если метки собирают с боевых подключений. Очень разные показатели могут быть, например, с разных стратегий отличающихся по тому, как они посылают заявки — тейкер/мейкер. У тейкеров будет стабильно длинее раундтрип чем у мейкеров. Происходит это по тому, что человек который котирует он всегда в рынке в том числе когда цена «вкусная» и когда цена находится в низковолатильной фазе и никому не нужны — в таком раскладе средний раундтрип будет занижен.
Если человек торгует только тейкером, то у него раундтрип есть только тех заявок, которые были «вкусные» т.е. тех которые хотело бОльшее кол-во участников рынка а это уже значит что возрастает нагрузка на шлюз и далее увеличенный раундтрип.
И дальше если разбирать, то можно вот еще что нарыть: участников на разных инструментах разное кол-во, кол-во выпущенных заявок на «вкусные» цены, следовательно тоже разное. Очевидно, на Si-шке в разы больше трейдят, чем на остальных и следовательно в пиковые моменты, когда цена «вкусная», скажем на лукойле, в шлюз посылается транзакций гораздо меньше, чем в такие же моменты для Si-шки. А учитывая ограниченные возможности наших шлюзов и раундтрип возрастает в одни моменты сильнее чем в другие.
Я думаю, что если делать чистые тесты, например просто кидать заявку в пустоту каждые n-секунд по разным инструментам, то в этом случае раундтрип у них будет одинаковый. А вот если снимать метки по живым стратегиям, то разница будет неизбежна и чем слабее пропускная способность шлюза, тем сильнее будет разница.
avatar

Arbitrg

nik, задержка возникает не там, промы грубо говоря занимаются только раздачей маркет даты, транзакционные сообщения там пыль, объемы трафика не сопоставимы.
Правильные карточки стоят у вас, но проведите нормальный benchmarking вашей библиотеки с использованием аппаратных timestamps, а то прочитав 
Меряем время отправки и приема сетевых пакетов на проводе
на цифры ваши смотреть совсем не хочется :(
avatar

maxman

maxman, мы и используем аппаратные timestamps.
И sockperf умеем гонять
avatar

Viking

Viking, 

Так будьте технически грамотными людьми, разрисуйте подробней ваш test harness, покажите где вы ставите метки и как по этим меткам вы вычисляете latency.
Вы публикуете результат своего исследования на достаточно широкую публику, при этом вы коммерческая организация, а не исследовательская, но после первого прочтения складывается впечатления, ну очередной «брат финансист» измеряет, что-то на проводах, а потом данные волшебным образом попадают в компьютер.

avatar

maxman

maxman, мы аппаратно ставим метки на пакеты на сетевой карте тестирующего сервера. Таким образом измеряется time to market тестируемого сервера с роботом
avatar

Viking

Viking, если это так, то заявленные мение 2мкс у 30% выглядят нериалестично. уверены, что действительно все правильно меряете?
avatar

nik

nik, заявленные 30% менее 2мкс где?
avatar

Viking

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
avatar

nik

nik, здесь 95% измерений больше 4 микросекунд (2<407) и 5%>8. Среднее 6.5 микросекунд. Ни одного измерения меньше двух
avatar

Viking

maxman, а какой benchmarking считаете нлрмальным?
avatar

Viking

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.

avatar

maxman

maxman, годы работы в НИИ не прошли бесследно)
avatar

Viking

У вас на Twime есть значения меньше 200мкс, это как-то совсем мало, есть точки, где вообще около 20мкс, вы уверены в точности замеров?
avatar

Cash

Cash, это баг в измерялке. Мы его уже исправили. Такое получалось, когда до прихода orderAdded заявки снималась по clOrdId
avatar

Viking

Viking, как можно снять заявку, которая еще не стала в стакан? Расскажите, очень полезная фича)
Cristopher Robin, в фиксе при помощи снятия по clOrderId а в плазе и твайме при помощи massCancelRequest
avatar

Viking

madman, годы работы в НИИ не прошли бесследно;)
avatar

Viking

Viking, 
Я бы сказал, отпечатались тяжелым наследием. 
avatar

maxman

По графикам получается, что FIX быстрее всех как я понял? А если сравнивать FIX / PLAZA2 на SPECTRA? А то я слышал, что спектра работает на плазе и фикс в неё перепаковывается, поэтому на срочке FIX должен PLAZA2 проигрывать.

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

kapodes


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

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

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