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

Dave Hart hart at ntp.org
Wed Nov 9 02:59:30 UTC 2011


On Fri, Nov 4, 2011 at 23:27, Nathan Kitchen
<nkitchen at aristanetworks.com> 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.
>
> After the offset is corrected, configuration #1 takes 921 seconds to
> synchronize to the server. Configuration #2 takes 472.
>
> Can you provide any insight?

And in a later message, Nathan points out he's testing ntpd 4.2.6p1 on
64-bit Linux 2.6.32.28.

I agree that I would not expect to see any difference in behavior
between LAN source only (#1) and LAN source + orphan mode (#2).  I am
not surprised to see difference in behavior with 4.2.6 between either
of those and using a LAN source and the LOCAL driver (#3) as that
version is prone to switch to the LOCAL driver more often than is
helpful.  If you stick with that version of ntpd, I would advise
avoiding the LOCAL driver, and I would also wonder if even orphan mode
is helpful in this case.  Why not use config #1, what problem is LOCAL
or orphan mode solving?

I suspect if you try the latest ntp-dev, you'll see more symmetric
behavior between the setup with a a network source as well as either
the undisciplined local clock or orphan mode (which I would not
describe as a local reference clock, though it does behave similarly
if the system becomes the orphan parent as if it selects the LOCAL
driver as the system peer).

In the configuration using the LOCAL driver, after the clock is
stepped massively, I suspect the LOCAL driver is being selected as the
system peer before the network source has provided enough samples to
be selectable (to have a low-enough dispersion).  It is normal and
expected that reference clocks are selectable after a single poll,
rather than the several required for a network source.  Once it is
selected, it continues to appear to be a better source than the
network source, even after many polls, thanks to the 0 delay and root
dispersion of reference clocks.  This behavior is why this
list/newsgroup is full of advice to avoid using the LOCAL driver, and
why in 4.2.7 ntpd now refuses to use the LOCAL driver (or ACTS modem
driver lacking prefer, or to become orphan parent) until after a
holdoff period of 300s default (tos orphanwait), so that network
sources have a chance to become selectable before backup sources are
engaged.

Without understanding why you are using LOCAL or orphan mode, it's
hard to say much more.  Between the two, I think you'll find orphan
mode works better unless you actually have some other mechanism
disciplining the system clock and ntpd is there solely to serve that
time, in which case LOCAL should be the only source in ntp.conf and be
marked "prefer".

Cheers,
Dave Hart


More information about the questions mailing list