[ntp:questions] NTPD 4.2.8 -- Packet Data that affects NTP client's reach metric

William Dell william.dell at metecs.com
Mon Nov 30 20:34:10 UTC 2020


Hoping for some definitive answers on what specifically affects the reach
metric of NTP clients. We have several clients onboard the International
Space Station that frequently have trouble syncing to the onboard NTP
server NASA administers there.

A while back we were able to get a packet capture of some of the
communications between our clients and the NTP server. We noticed that the
root dispersion of the packets being sent from the onboard NTP server that
were not being accepted by the client's all had a root dispersion value
ranging from 2-10 seconds.

The real fix here would be for NASA's Space Station Computers (SSC) team to
resolve the issues affecting the onboard NTP server's root dispersion but
this is out of my hands. What I can control is our client's willingness to
accept packets from the NTP server onboard. To that end, after seeing the
high root dispersion value from the onboard NTP Server we added tos maxdist
60 to /etc/ntp.conf This change was made to reflect some changes the SSC
team made to their onboard NTP server which included the same tos maxdist
60.

Since making this change our reach metric has gone from roughly 30% daily
success average, ranging from 20-60% to ~90% average.This is converted from
the octal values reach actually provides of course. So things have improved
considerably but we're needing to get this value to 100% if at all
possible. Our clients restart nightly on a cronjob that fires at 6 minutes
after midnight, the reboot causes them to lose their clock and so a 90%
average still gives us around a 1/10 chance that our clients won't sync on
the first reboot.

What I'm trying to figure out is:

1) What other values (aside from root dispersion/root delay) in the packets
being sent by the NTP server would cause the NTP client to reject that
packet

and/or

2) if there are any other possible conf changes we can make to our clients
to make them more willing to accept "bad" time being handed to it from it's
NTP server? We don't care if we're seconds or minutes off, we just need to
keep it in roughly the same day/year. Realistically if there's some way to
just accept time from an NTP server no matter how bad it is -- say,
ignoring every test in the process_packet() function from ntp_proto.c


Thanks for any help you can provide, or even for just reading this wall of
text,

William


More information about the questions mailing list