Подтвердить что ты не робот

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

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

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

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

4b9b3361

Ответ 1

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

  • TSA (TS Associates)
  • Correlix
  • Corvil
  • Napatech (устройства захвата оборудования)
  • Endace (устройства захвата оборудования)

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

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

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

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

Аппаратные карты, перечисленные выше, начинаются с $2 тыс. (для карты с голыми костями) и растут (значительно) оттуда.

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

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

Ответ 2

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

Ответ 3

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

Ответ 4

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

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