[ntp:questions] Choice of local reference clock seems to affect synchronization on a leaf node
nkitchen at aristanetworks.com
Mon Nov 7 19:37:57 UTC 2011
On Sun, Nov 6, 2011 at 2:13 PM, Danny Mayer <mayer at ntp.org> wrote:
> On 11/4/2011 7:27 PM, Nathan Kitchen wrote:
> > I'm curious about some behavior that I'm observing on a host running
> > ntpd as a client. As I understand it, configuring a local reference
> > clock--either an undisciplined local clock or orphan mode--shouldn't
> > help me, but I see different behavior when I do have one. In
> > particular, when I'm synchronizing after correcting a very large
> > offset, I synchronize about 2x faster in orphan mode than with no
> > local clock, and with an undisciplined local clock I don't even fix
> > the offset.
> > I'm curious about whether this difference should be expected.
> > I'm using the following configuration in all cases:
> > driftfile /persist/local/ntp.drift
> > server 172.22.22.50 iburst
> > My three different configurations for local clocks are the following:
> > 1. No additional commands
> > 2. tos orphan 10
> > 3. server 127.127.1.0
> > fudge 127.127.1.0 stratum 10
> > In all three cases, my test has these steps:
> > 1. Stop ntpd.
> > 2. Set the clock to 2000-1-1 00:00:00 (that is, more than 10 years ago).
> > 3. Run ntpd -g.
> > 4. Check that the 11-year offset is corrected.
> > 5. Wait for synchronization to the time server.
> > With either configuration #1 (no local clock) or #2 (orphan mode), the
> > offset is corrected quickly: 4 and 13 seconds, respectively. With
> > configuration #3 (undisciplined local clock), it fails to be corrected
> > within 60 seconds.
> In case #3 that's expected if there are no servers to get the correct
> time. What else would you expect? Where would it get it's time from?
In case #3, as in the other cases, the configuration includes the
> > After the offset is corrected, configuration #1 takes 921 seconds to
> > synchronize to the server. Configuration #2 takes 472.
> First, correcting the offset is the major concern. After that figuring
> out the frequency changes need to be calculated with additional packets
> being received and that takes time. It needs to have enough of them to
> do the calculation.
Why would it take fewer packets with orphan mode enabled (and no
peers) than with no local clock?
More information about the questions