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

Это зависит от того, что Вы разрабатываете.

А, ориентированный на содержание на веб-сайт, будет иметь довольным, изменение часто и Веб-сайт лучше для этого.

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

18
задан Ajaxx 5 August 2009 в 21:28
поделиться

4 ответа

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

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

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

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

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

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

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

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

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

9
ответ дан 30 November 2019 в 09:21
поделиться

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

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

0
ответ дан 30 November 2019 в 09:21
поделиться

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

4
ответ дан 30 November 2019 в 09:21
поделиться

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

1
ответ дан 30 November 2019 в 09:21
поделиться
Другие вопросы по тегам:

Похожие вопросы: