[ntp:questions] NTP request retry?
elliott.ch at verizon.net
Tue Jan 28 12:30:45 UTC 2014
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)
say that 16 seconds between packets are OK for short bursts, and that 32
seconds between packets are OK anytime.
From: questions-bounces+elliott.ch=verizon.net at lists.ntp.org
[mailto:questions-bounces+elliott.ch=verizon.net at lists.ntp.org] On Behalf Of
Sent: Monday, January 27, 2014 4:45 PM
To: questions at lists.ntp.org
Subject: Re: [ntp:questions] NTP request retry?
Rick Jones <rick.jones2 at hp.com> wrote:
> Brian Inglis <Brian.Inglis at systematicsw.ab.ca> wrote:
>> You don't specify which system and devices you are using, so here are
>> a couple of articles about changing ARP timeouts:
> 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
questions mailing list
questions at lists.ntp.org
More information about the questions