[ntp:questions] Choice of local reference clock seems to affect synchronization on a leaf node

Danny Mayer mayer at ntp.org
Sun Nov 6 22:13:33 UTC 2011

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 iburst
> My three different configurations for local clocks are the following:
> 1. No additional commands
> 2. tos orphan 10
> 3. server
>     fudge 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?

> 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.


More information about the questions mailing list