On Fri, Nov 4, 2011 at 23:27, Nathan Kitchen <nkitc...@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 _______________________________________________ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
