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

Nathan Kitchen nkitchen at aristanetworks.com
Wed Nov 9 03:12:23 UTC 2011


On Tue, Nov 8, 2011 at 6:59 PM, Dave Hart <hart at ntp.org> wrote:
>
> 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?

It doesn't exactly solve a problem, but faster synchronization is nice
to have, and it does appear to have that effect.

Thanks for the insight on the appropriate use of LOCAL and orphan mode.

-- Nathan

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