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
207.7.148.214 216.218.254.202 2 u - 512 377 1045.07 -209713 11784.0
72.14.179.211 127.67.113.92 2 u - 512 377 1029.80 -201710 6559.37
173.255.224.22 128.4.1.1 2 u 245 512 377 919.628 -202629 7684.05
130.207.165.28 130.207.244.240 2 u - 512 377 994.543 -204125 7778.28
131.144.4.10 65.212.71.102 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
saturating?
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.
_______________________________________________
questions mailing list
[email protected]
http://lists.ntp.org/listinfo/questions
