Измерение задержки широковещательного сообщения с использованием системных часов, хорошая идея? - PullRequest
2 голосов
/ 14 февраля 2011

Я хочу измерить задержку широковещательных сообщений через нашего брокера сообщений в локальной сети 1 ГБ.

Сообщения передаются в пабе под модом, один издатель, много потребителей. Производитель производит отметки времени каждого сообщения с использованием системных часов (DateTime.Now в C #), а потребители измеряют задержку, вычитая отметку времени сообщения из DateTime.Now.

 double latency = (DateTime.Now - msg.NMSTimestamp).TotalMilliseconds;

Все устройства в нашей локальной сети синхронизируют свое время через NTP один раз в час, но я наблюдаю значительную задержку и даже отрицательное время в диапазоне +/- 1 секунды. Я прочитал, что NTP должен обеспечивать точность ~ 5 мс в среде локальной сети.

Является ли моя стратегия измерения фундаментально ошибочной? Есть ли другое объяснение отрицательной латентности? Если бы я видел только большие задержки, я бы заподозрил, что наша очередь сообщений была медленной, но отрицательные действительно запутали меня.

Ответы [ 2 ]

3 голосов
/ 14 февраля 2011

Как выглядят ваши отрицательные значения в миллис?Если это в пределах 5 мс, это нормально для NTP, как вы знаете.Разница между компьютерами может достигать 10 миллисекунд, если один компьютер опережает истинное время на 5 миллиметров, а другой - на 5.Более того, я бы предположил, что в вашей системе есть ошибки округления, ошибки lookahead / lookbehind или ошибки синхронизации.Существует множество деталей аппаратного обеспечения и реализации, которые вы мало контролируете, что может привести к неточностям.В общем, системные часы достаточно точны на миллисекундном уровне при опросе DateTime.Now, но многие детали аппаратного обеспечения, такие как дросселирование ЦП под нагрузкой, конвейеры, перегрузка кеша и т. Д., Могут вносить достаточно ошибок, чтобы быть значительными на уровне миллисекунд.1002 * Если возможно, настройте свои компьютеры для синхронизации с NTP-сервером, по крайней мере, на расстоянии секунды друг от друга.Если все компьютеры будут пытаться синхронизироваться по часам каждый час, NTP-сервер будет загружен, что приведет к увеличению погрешностей в сообщении правильного времени из-за переполнения и планирования пакетов.Я думаю, что это наиболее вероятная причина того, что происходит.Кроме того, убедитесь, что ваша сеть максимально эффективна, уменьшив протяженность кабелей (300 футов - это теоретический максимум, а в среде с помехами от электромагнитных помех - 40 футов, что может вызвать серьезные проблемы), заменив концентраторы коммутаторами и минимизировав количество беспроводных сетей.использование сети.

0 голосов
/ 14 февраля 2011

У меня записано несколько инцидентов с отрицательной задержкой в ​​сети, измеренной с помощью тех же часов.

Windows не может реализовать перекос часов, поэтому вы видите это всякий раз, когда происходит синхронизация.

Windows не гарантирует точность 5 мс, но только 18,2 тиков в секунду. Моя машина обеспечивает эпсилон 15 мс.

...