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

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

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

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


person Ajaxx    schedule 05.08.2009    source источник
comment
не совсем связано с программированием, может быть лучше на serverfault, но все же очень интересно.   -  person Cheeso    schedule 06.08.2009


Ответы (4)


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

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

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

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

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

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

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

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

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

person Tim    schedule 05.08.2009
comment
++ TipOff хорошо работает после настройки на специфику. Вы можете сделать это самостоятельно, используя необработанные снимки, но их оборудование значительно упрощает получение данных и их эффективную привязку к временным меткам. Как только вы пройдете начальную фазу, замечательно, что что-то будет делать это автоматически. - person ShuggyCoUk; 06.08.2009

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

person strangelydim    schedule 18.11.2009

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

person bobah    schedule 10.05.2010
comment
Часто в такой среде у вас нет контроля над содержанием сообщений, то есть вы не можете просто вставить в них информацию. Некоторые биржи помещают в сообщения отметки времени, но я не уверен, что вы можете на это рассчитывать. Также обратите внимание, что тогда существует зависимость от точной синхронизации часов. Также - ... анализ двунаправленного потока ... я думаю, нетривиально. - person Tim; 12.05.2010
comment
анализ двунаправленного потока может быть частью встроенного сердцебиения. если вы не можете изменить сообщение, но можете надежно идентифицировать его в потоке, вы, вероятно, можете использовать snoop / tcpdump на каждом прыжке для генерации дампов, а затем постобработку дампов для определения совпадающих сообщений и вычисления временных дельт - person bobah; 13.05.2010

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

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

person T.E.D.    schedule 05.08.2009
comment
Я думаю, ему нужна задержка в двух точках. Это приятно знать, поскольку если это значение изменяется, то это не связано со скоростью света - это связано с каким-то узким местом в транспорте. - person Tim; 06.08.2009
comment
Я не понимаю, что вы имеете в виду, когда говорите, что единственный подход, на который есть надежда, - это задержка в оба конца. Вы можете уточнить? - person Tim; 06.08.2009
comment
Прости, Тим. Иногда я говорю так, будто говорю со своими коллегами, которые работают над тем же делом, что и я, и знают, о чем я говорю. В конце я добавил фразу, которая может немного прояснить ситуацию. - person T.E.D.; 06.08.2009
comment
Согласны с вами обоими, но, как вы, наверное, догадались, я имею дело с системами, которые доставляют данные в одну сторону. Попытка сделать rtt для борьбы с перекосом и задержкой достаточно плоха, но когда тайминги в микросекундах, лучшее, что я могу начать, - это отслеживать дельту задержки, чтобы понять, становится ли нам лучше или хуже со временем и под нагрузкой условия. Что касается измерений, мы уже используем таймеры с высоким разрешением для измерения времени, но измерения от 2 реперных точек подвержены перекосу часов. При измерении от 1 точки возможны потери при передаче. Хорошие комментарии вам обоим. - person Ajaxx; 06.08.2009