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

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

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

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

nik, задержка возникает не там, промы грубо говоря занимаются только раздачей маркет даты, транзакционные сообщения там пыль, объемы трафика не сопоставимы.

Viking, 

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

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

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

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.

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

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