[ntp:questions] Sure GPS - Very High Jitter and Offset
klink at numberzero.org
Tue Aug 16 14:42:09 UTC 2011
I wrote a script to compare the previous/current assert timestamp
(ignoring the seconds), and this is what I get when NTP is *not*
So it appears my system clock lags a bit behind, which I guess one
would expect. With NTP running, I can see the results of it adjusting
my clock accordingly:
I tried setting flag3 to 0 but it didn't appear to make a difference.
Also, I would have expected NTP to mark the clock as a PPS source with
'o', but when I let it sync it seems to stick with '*' instead:
$ ntpq -p
remote refid st t when poll reach delay offset jitter
LOCAL(0) .LOCL. 12 l 232 64 10 0.000 0.000 0.002
*GPS_NMEA(0) .GPS. 0 l 7 16 377 0.000 20.012 26.423
I also don't see *anything* about PPS in the syslog from NTP, I only
see the kernel messages that it's loading the driver and that's it.
There are no warnings or errors from NTP, only what one would expect
to see when (re)starting NTP.
On Tue, Aug 16, 2011 at 5:52 AM, Miroslav Lichvar <mlichvar at redhat.com> wrote:
> On Mon, Aug 15, 2011 at 10:58:45PM -0500, Ken Link wrote:
>> Now, I get timestamps in the assert and clear files: 1313465775.004708342#4545
>> However, the source is still jittery! 15ms sometimes, like it's not
>> using the PPS signal at all.
> If you compare few assert timestamps in row, how stable is the offset?
> Couple of microseconds?
>> The important configuration lines are:
>> server 127.127.20.0 mode 18 minpoll 4 prefer
>> fudge 127.127.20.0 flag1 1 flag2 0 flag3 1 flag4 0
> You wrote earlier that you use a 2.6.38 kernel. I think the kernel PPS
> discipline was added later, so maybe it would help to remove the flag3
> Also, how is marked the PPS source in ntpq -p output?
> Miroslav Lichvar
> questions mailing list
> questions at lists.ntp.org
More information about the questions