У меня есть приложение, в котором мы используем нестандартное сетевое оборудование (не может быть изменено), которое переходит в неактивное состояние между всплесками трафика. Задержка в сети составляет очень высокий для первого пакета, поскольку он, по сути, будит систему, ожидает ее повторного подключения, а затем выполняет первый круговой обход. Последующие сообщения (при условии, что они поступают в течение следующей минуты или около того) намного быстрее, но все еще очень скрыты. Типичный набор эхо-запросов будет выглядеть как 2500 мс, 900 мс, 880 мс, 885 мс, 900 мс, 890 мс и т. Д.
Учитывая, что NTP использует несколько циклов приема-передачи перед вычислением смещения, насколько хорошо я могу ожидать, что ntpd будет работать с таким типом ссылки? Будет ли проигнорирован изначально медленный первый круговой обход из-за сильно различающихся (и более быстрых) последующих сообщений на / от сервера ntp?
Короткий ответ - да, NTP предпочтет низкие метки времени туда и обратно, а не высокие метки времени туда и обратно. Раньше был calldelay возможность сообщить NTP об этой проблеме, обычно создаваемая сетями, использующими технологии дозвона по запросу, которые накладывают задержку вызова. Однако теперь NTP делает это автоматически.
Если вы хотите ускорить начальную синхронизацию времени, вы можете использовать iburst ключевое слово на server/peer линий. Это говорит NTP использовать 8 разнесенных пакетов вместо 1 для измерения времени. Он будет игнорировать любые пакеты, которые имеют намного большее время приема-передачи. Если у вас есть пропускная способность, вы можете использовать burst чтобы он использовал 8 пакетов каждый раз при измерении времени.