The only way that NTPD works well is to find 4 to 9 stratum 2 servers near your location by searching the server lists at www.ntp.org. Then observe the servers over a few days so that none of the ones you pick have highly variable transit times. Then set your clients facing external servers to minpoll 4 maxpoll 5. There is no way on earth that NTPD can detect and compensate for intermittent transit delays, which are endemic to the Internet, by sampling every 2^10 = 1024 seconds = 17 minutes, 4 seconds. Shannon's or Nyquist's, whichever, law applies here as everywhere. Then within your own LAN use broadcast mode. That will give you much lower offset and jitter readings because delay times are not considered, as they should be non-existent. If you can, use Gigabit Ethernet on your LAN. You will then see transit times with ping go from >1 ms to <1 ms. But the real advantage is that the temporal gap between packets on Gb Ethernet is much (~10X) larger than on fast Ethernet, so the exponential back-off algorithm rarely kicks in, virtually eliminating variable delays.
The doomsayers on this list will tell you that minpoll 4 maxpoll 5 is abuse and cite the tragedy of the commons. They have a point, but not a valid one. It is true that the fact that everyone and his brother insists on using the stratum 1 servers has ruined them as a source of time, especially the government's servers. But so far, the stratum 2 servers are not stressed. And the rules (I don't remember where I read them) specifically say that 16 seconds between packets are OK for short bursts, and that 32 seconds between packets are OK anytime. C Elliott -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Rob Sent: Monday, January 27, 2014 4:45 PM To: [email protected] Subject: Re: [ntp:questions] NTP request retry? Rick Jones <[email protected]> wrote: > Brian Inglis <[email protected]> wrote: > >> You don't specify which system and devices you are using, so here are >> a couple of articles about changing ARP timeouts: >> http://www.embeddedsystemtesting.com/2013/01/arp-timeout-value-for-li >> nux-windows.html >> http://support.microsoft.com/kb/949589 > > And if indeed these are all the OP's own systems, he can add > hardwired, "permanent" ARP cache entries via the arp command (under > most *nixes at least). I'm still not sure if ARP is really the problem, but fixing the clients to maxpoll 6 seems to cure it. (at least the reach now sticks at 377) > If a mix of wired and wireless is involved, if there is some way to > get traces at the point where the two join that would be goodness. If both would be WiFi, I would point at the WiFi. However, one is connected to the wired network (a switch where the server is connected as well). I can ping it as much as I like, no loss: 1571 packets transmitted, 1571 received, 0% packet loss, time 20468ms rtt min/avg/max/mdev = 0.702/0.845/1.168/0.090 ms But when ntpd is allowed to climb to 1024-second polls, it gets almost no replies. _______________________________________________ questions mailing list [email protected] http://lists.ntp.org/listinfo/questions _______________________________________________ questions mailing list [email protected] http://lists.ntp.org/listinfo/questions
