Как вы измеряете задержку в средах с низкой задержкой?

Question

Вот настройка ... Ваша система получает поток данных, который содержит дискретные сообщения (обычно между 32-128 байтами на сообщение). Как часть вашего конвейера обработки, каждое сообщение проходит через два физически отдельных приложения, которые обмениваются данными с использованием подхода с низкой задержкой (например, обмен сообщениями по UDP) или RDMA и, наконец, клиенту через тот же механизм.

Предполагая, что вы можете внедрить себя на любом уровне, включая анализ проводного протокола, какие инструменты и / или методы вы бы использовали для измерения задержки вашей системы. В рамках этого я предполагаю, что каждое сообщение, доставляемое в систему, приводит к тому, что соответствующее (хотя и не эквивалентное) сообщение проталкивается через систему и доставляется клиенту.

Единственный инструмент, который я видел на рынке, это TS-Associates TipOff. Я уверен, что с правильным доступом вы, вероятно, могли бы измерить ту же информацию, используя инструмент анализа проводов (ala wireshark) и правильные анализаторы, но это правильный подход или есть какие-то товарные решения, которые я могу использовать?

Answer 1

Ваш последний абзац - типичный способ, которым это нужно сделать. Обычные подозреваемые в этой области (по крайней мере, насколько мне известно для латентности рыночных данных (Уолл-стрит)):

• TSA (TS Associates)
• Корреликс
• Corvil
• Napatech (аппаратные устройства захвата)
• Endace (аппаратные устройства захвата)

Была еще одна плохо управляемая компания, которая недавно потратила свои деньги на ВК (4 миллиона?).

Для данных, которые обрабатываются (скажем, на прямом обменном канале, или в RMDS, или на другом сервере, который изменяет протокол) в разные форматы, вам необходимо иметь возможность анализировать полезные нагрузки для сопоставления сообщений. Это может быть сложно, поскольку иногда поставщики данных не предоставляют определения сообщений.

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

В последний раз, когда я разговаривал с TSA, установка с 4 точками наблюдения была порядка 150 тысяч долларов. Я подозреваю, что остальные, перечисленные выше, похожи по цене.

Перечисленные выше аппаратные карты начинаются примерно с 2 тыс. Долларов (для карты без костей) и увеличиваются (значительно) оттуда.

Чтобы сделать это в программном обеспечении, вам нужно, чтобы клиенты использовали pcap (или что-то подобное), смотрели на полезные нагрузки и пытались сопоставить их. В некоторых случаях трудно сделать это детерминированным - особенно в начале «сеанса» или если сообщения отсутствуют в одном канале. Обычно после некоторого порога, если вы не соответствуете чему-либо, вы просто отбрасываете его.

EDIT: ОТКАЗ ОТ ОТВЕТСТВЕННОСТИ: Я также являюсь частью предприятия сейчас и должен раскрыть это.

Answer 2

Недавняя статья может оказаться полезной (и также будет намного дешевле, чем аппаратные решения). Существуют также способы достаточно точного учета перекоса часов; В последний раз, когда я всерьез изучал однонаправленное измерение латентности (пару лет назад), наиболее точной техникой был алгоритм линейного программирования от Сью Мун (с удобным кодом для справки) здесь ), но без использования некоторых довольно современных методов линейного программирования его практически невозможно использовать в качестве онлайн-алгоритма; Лучше всего записывать временные метки, не выполняя каких-либо вычислений периодически в течение дня, а затем запустить алгоритм LP для накопленных данных. Было несколько других техник, которые были достаточно быстрыми, чтобы их можно было делать в режиме онлайн (включая оригинальную статью Верна Паксона), но все они были гораздо менее точными.

Answer 3

Если еще несколько байтов в сообщении не будут для вас излишним, я бы рекомендовал просто помечать сообщение в источнике с полной отметкой времени (64 бита) и на каждом прыжке добавлять дельты входа / выхода из отметки времени (один байт на отметку) , Анализируя двунаправленный поток, вы выясните перекос часов между блоками, и тогда вы сможете получить полную информацию о задержке в реальном времени для вашего рассмотрения или для публикации в инструментах мониторинга.

Answer 4

Проблема, связанная с этим, во многом аналогична измерению «скорости» в космосе: вам нужно задать время ожидания относительно чего? Если вы попытаетесь измерить его по проводам, вы потеряете лишнюю задержку при переключении или в стеке протоколов на принимающей стороне. Вы не можете реально измерить его сквозным, поскольку у компьютеров будет два разных тактовых генератора, которые почти невозможно согласовать без внесения небольших ошибок (и они расходятся друг с другом!)

Единственный подход, который действительно имеет какие-либо надежды, - это измерение задержки в оба конца, при условии, что у вас есть сообщения, которые возвращаются с одного конца, подтверждающего получение. У UDP нет ACK в стеке, поэтому они должны быть где-то закодированы в приложении. Что вы делаете, это используете что-то вроде таймера высокого разрешения x86 для измерения времени между отправкой сообщения и появлением его ответа.