Почему NTP считает мой сервер неадекватным?

У меня есть встроенное устройство Linux, подключенное непосредственно к моему рабочему столу Windows через интерфейс USB / Net. Он основан на платах Freescale iMX6, поэтому я считаю, что аппаратное обеспечение часов - это SNVS RTC.

На рабочем столе 192.0.0.10, У меня W32Time работает как NTP-сервер и встроенное устройство 192.0.0.100 (я думаю) правильно настроен для использования в соответствии с ntp.conf файл:

server 192.0.0.10 iburst minpoll 5 maxpoll 7
driftfile /data/ntp.drift
restrict default nomodify nopeer noquery limited kod
restrict 127.0.0.1
restrict [::1]

Связь не проблема^(а) так как я могу на встроенном устройстве выполнить:

ntpdate -uq 192.0.0.10
ntpdate -ub 192.0.0.10

и это успешно запросит и обновит время.

Однако я обнаружил, что часы, которые должны синхронизироваться ntpd немного дрейфует. Я запустил и синхронизировал ntpd около 18 часов назад, и смещение постепенно увеличилось примерно до 5 секунд:

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 192.0.0.10      192.168.0.4      4 u   31   32  377    1.452  4941.57  11.927

За последние несколько часов он действительно начал возвращаться, но все еще в 3,2 секунды от того, что должно быть. В любом случае, я не уверен, что это не более чем совпадение по следующим причинам.

Когда я увидел, что он постоянно поднимается, я покопал. Выход ntpq Команда ассоциаций была (и остается):

# ntpq -c as

ind assid status  conf reach auth condition  last_event cnt
===========================================================
  1 62876  9024   yes   yes  none    reject   reachable  2

Это указывает на то, что сервер, хотя и доступен, по какой-то причине фильтруется. Основываясь на статусе 9024 (видеть Вот), это, по-видимому, объясняется «отклонено как недействительное (TEST10-TEST13)».

Итак, я иду и смотрю на ntpq переменные для этой ассоциации:

# ntpq -c rv 62876

associd=62876 status=9024 conf, reach, sel_reject, 2 events, reachable,
srcadr=192.0.0.10, srcport=123, dstadr=192.0.0.100, dstport=123, leap=00,
stratum=4, precision=-6, rootdelay=129.150, rootdisp=2193.741,
refid=192.168.0.4,
reftime=ddd30907.eff60ee5  Thu, Dec  7 2017  0:25:43.937,
rec=ddd31287.4db24cd8  Thu, Dec  7 2017  1:06:15.303, reach=377,
unreach=0, hmode=3, pmode=4, hpoll=5, ppoll=5, headway=21,
flash=400 peer_dist, keyid=0, offset=3186.569, delay=1.446,
dispersion=16.036, jitter=11.844, xleave=0.093,
filtdelay=     1.45    1.42    1.41    1.47    1.44    1.43    1.44    1.48,
filtoffset= 3186.57 3189.58 3192.08 3194.56 3197.13 3199.58 3202.57 3205.06,
filtdisp=     15.63   16.12   16.60   17.08   17.58   18.06   18.54   19.03

Я вижу что flash переменная установлена ​​в 400 который на основе той же страницы, указанной выше, показывает 0400/TEST11/peer_dist/peer distance exceeded.

Теперь я понимаю, что это не физическое расстояние (и клиент, и сервер находятся на моем рабочем столе) или сетевое расстояние (два устройства подключены напрямую). Единственная полезная ссылка, которую мне удалось найти в сети, - это Группы Google где один Дэвид Вулли утверждает:

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

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

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

Итак, у меня вопрос, куда я могу пойти дальше? Я не могу получить больше полезной информации из ntpq и даже бег ntpd -dd на переднем плане не проясняется Зачем время сервера отклоняется.

Любая помощь будет принята с благодарностью.

^(а) Как далее указывается в журналах на стороне Windows, включенных с помощью:

w32tm /debug /enable /file:C:\w32time.log /size:10000000 /entries:0-300

и производство:

152281 02:06:57.1968483s - ListeningThread -- DataAvailEvent set for socket 1 (0.0.0.0:123)
152281 02:06:57.1973483s - ListeningThread -- response heard from 192.0.0.100:123 <- 192.0.0.10:123
152281 02:06:57.1973483s - /-- NTP Packet:
152281 02:06:57.1973483s - | LeapIndicator: 3 - not synchronized;  VersionNumber: 4;  Mode: 3 - Client;  LiVnMode: 0xE3
152281 02:06:57.1973483s - | Stratum: 0 - unspecified or unavailable
152281 02:06:57.1973483s - | Poll Interval: 5 - 32s;  Precision: -20 - 953.674ns per tick
152281 02:06:57.1973483s - | RootDelay: 0x0000.0000s - unspecified;  RootDispersion: 0x0000.F1A0s - 0.943848s
152281 02:06:57.1973483s - | ReferenceClockIdentifier: 0x494E4954 - source name: "INIT"
152281 02:06:57.1973483s - | ReferenceTimestamp:   0x0000000000000000 - unspecified
152281 02:06:57.1973483s - | OriginateTimestamp:   0xDDD320A033087D7D - 13157085984199348300ns - 152281 02:06:24.1993483s
152281 02:06:57.1973483s - | ReceiveTimestamp:     0xDDD3209D4DB18BA5 - 13157085981303490400ns - 152281 02:06:21.3034904s
152281 02:06:57.1973483s - | TransmitTimestamp:    0xDDD320BE4D535D3F - 13157086014302053300ns - 152281 02:06:54.3020533s
152281 02:06:57.1973483s - >-- Non-packet info:
152281 02:06:57.1973483s - | DestinationTimestamp: 152281 02:06:57.1973483s - 0xDDD320C132856B0E152281 02:06:57.1973483s -  - 13157086017197348300ns152281 02:06:57.1973483s -  - 152281 02:06:57.1973483s
152281 02:06:57.1973483s - | RoundtripDelay: -562900ns (0s)
152281 02:06:57.1973483s - | LocalClockOffset: -2895576400ns - 0:02.895576400s
152281 02:06:57.1973483s - \--
152281 02:06:57.1973483s - TransmitResponse: sent 0.0.0.0:123(192.0.0.10:123)->192.0.0.100:123

Обновить к комментарию «За последние несколько часов он фактически начал возвращаться»: он фактически снова начал дрейфовать (в настоящее время на 3,7 секунды), поэтому мои мысли о том, что это было совпадением, похоже, поддерживаются.