[ntp:questions] ntpd losing sync
agcarver+ntp at acarver.net
Sat Feb 4 09:23:27 UTC 2012
On 2/4/2012 01:11, Harlan Stenn wrote:
> A C wrote:
>> Here's the current configuration for version 4.2.7p236:
>> server 0.us.pool.ntp.org minpoll 9 iburst
>> server 1.us.pool.ntp.org minpoll 9 iburst
>> server 0.north-america.pool.ntp.org minpoll 9 iburst
> You might try replacing the above 3 lines with:
> pool us.pool.ntp.org minpoll 9 iburst
> I do not remember offhand if iburst is supported for the "pool"
> directive but give it a shot.
>> server ntp1.gatech.edu prefer minpoll 9
> Is this server close enough that you want to "prefer" it?
It's usually pretty stable, more stable than some of the pool servers
that I get which is why I have it set to prefer.
>> server rolex.usg.edu minpoll 9
>> server 127.127.22.0 minpoll 2 maxpoll 4
>> fudge 127.127.22.0 time1 +0.000 flag2 1 flag3 1 refid PPS
> 0.0 is the default for time1.
> flag2 1 means PPS capture on the falling (clear) edge of the pulse.
> flag3 1 enables the kernel PPS discipline.
> I haven't been following this thread - what OS are you using?
The time1 flag is in there from a point when I was fiddling with it on
PPS. I just left it in there, I know the default is zero. I need flag2
for the system to detect the pulse because it is inverted. Kernel PPS
is enabled because I have compiled the kernel for PPS so that's correct,
too. All of this is NetBSD 5.1 on sparc.
>> server 127.127.28.0 minpoll 7 noselect
>> fudge 127.127.28.0 time1 -0.6 refid GPSD
> OK, GPSD via the shared memory driver, and "noselect". Nasty jitter on
> this one...
Yes, it does have a lot of jitter that I've been trying to monitor which
is why I had the noselect in place. Eventually I may remove noselect
and just fudge its stratum to avoid using it unless necessary.
>> The peer list after waiting about a day from the initial system upset:
>> remote refid st t when poll reach delay offset jitter
>> x127.127.22.0 .PPS. 0 l - 16 377 0.000 -465.49 355.933
>> 127.127.28.0 .GPSD. 0 l - 128 377 0.000 -208986 2833.87
>> 22.214.171.124 126.96.36.199 2 u - 512 377 1045.07 -209713 11784.0
>> 188.8.131.52 127.67.113.92 2 u - 512 377 1029.80 -201710 6559.37
>> 184.108.40.206 220.127.116.11 2 u 245 512 377 919.628 -202629 7684.05
>> 18.104.22.168 22.214.171.124 2 u - 512 377 994.543 -204125 7778.28
>> 126.96.36.199 188.8.131.52 2 u 23 512 377 1000.21 -203648 7687.63
>> Note that the offset for PPS is swinging wildly, not exactly visible in
>> this static snapshot.
> What's with the delay numbers? Are you on a network link that is
No, my link shouldn't saturate. I do have an asymmetric DSL but the
downstream rate is consistently above 22 Mbit/sec and upstream is 5
Mbit/sec. I keep an eye on the rate through the router and it's fairly
flat with only occasional spikes. In the past 24 hours the largest data
spike was 240 kbyte/sec (2.4 Mbit/sec) downstream for about one minute.
The upstream at that time was nearly zero. For the same 24 hour
period, the largest upstream spike was about 10 kbyte/sec (100
kbit/sec). The delays are normally pretty good usually staying below
100 milliseconds. I only see delays like that when everything goes haywire.
I've been watching the log file now that I just restarted ntpd and am
noticing a lot of spike_detect messages. The clock is stepping around
and the entire peer list refreshes, resetting the reach flags to zero
for everything, dropping all syspeers and acting like it's starting over.
More information about the questions