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 _______________________________________________ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
