Список проголосовавших за комментарий "Viking, <p>Для каждого типа измерения должна быть своя метрика. И четкое понимание, что вы измеряете, в данном контексте между чем и чем осуществляется замер.<br/> Допустим, если вы, что покрутил с драйверами карточек 10G и настройками операционки, поставьте простой тест.<br/> Эмуляция market data ( 1/2 UDP round trip ) отправляете с одного сервера UPD пакет 64 байта с меткой, в обратку эмулируете execution feed (1/2 TCP round trip)<br/> отправляете TCP пакет 400 байт с меткой. Прогнали объем данных, сохранили логи, потом скриптом прошлись посчитали стату, показали совой min, max, average.<br/> Вот ваши абсолютные значения и понятно, что и как вы измеряете.</p><p>Если речь про вашу библиотеку и вы делаете замеры трактов обработки данных, то тоже самое, сперва опишите, что вы измеряете и самое главное как.<br/> Не хочу комментировать измерения на примере вашей стратегии, это как то application specific очень. На мой взгляд banchmark должен быть по generic стадиям обработки. Допустим ваша замечательная библиотека декодирует поток заявок, фильтрует, нормализует данные и строит стакан, далее вы предоставляете ваше API для дальнейшей работы. Опять разрисуйте test harness, покажите, что вы, допустим, измеряете от выхода MAC на вашей 10G карточки (где и ставится аппаратная метка) до callback'a вашего API. Возьмите один торговый день на moex постройте гистограмму распределения плотности потока UDP пакетов рыночных данных.<br/> Сразу будет понятно, что 99.99% сообщений как раз 64 байта (2 инкрементальных апдейта). Вот и измерьте вашу латентность на 50%, 99%, 99.9% и 99.99% сообщений. Тогда ваши результаты будут понятны и интересны широкому кругу людей.<br/> Ну и не забываем, что по классике computer science latency это величина измеряющая задержку от первого байта на входе системы до первого байта на выходе системы. А от первого на входе до последнего на выходе это уже throughput.</p>"