[ntp:questions] NTP server with Garmin GPS 18 LVC

Adrian P ntp at pascalau.ro
Wed Dec 18 19:32:49 UTC 2013

> It is hard to say, but it could be that the interrupt for the PPS is
> delayed because of, say, disk activity which ties up the interrupts for
> 50us. The next one will of course occur on time ( ie 50us early with
> respect to the previous interrupt). That may be what you are seeing. Are
> you looking at the raw graphs of offset every second? The median filter
> should remove those spikes. (it basically throws away about 40% of the
> measurements that are furthest from the median in order to eliminate
> "popcorn" events) so they should not affect your timing.
> Looking at your graph, the events are extremely regular. Unfortunately I
> have no idea what the lower axis is. You claim seconds, but there are no
> tick marks. Does that span represent a day, a year, a microsecond?
> If it is say minutes or hours, then the decay suggests that the computer
> say a huge spike for a relatively long time ( many seconds) responded by
> changing the clock rate, and then that anomaly disappeared and it
> relaxed back to its proper rate.

That graph (http://goo.gl/JpSyeO) is based on the entries in the
peerstats file, and the lower axis is the time past midnight in
seconds. The peerstats file is rotated every day, so the graph shows
the clock offset and the RMS jitter for a 24h period, as the graph
title tells. I have configured the NMEA driver using minpoll 4 maxpoll
4, so I have an entry in the peerstats file every 16 secconds or so.

To be more precise, I recreated the graph for the first negative /
positive spike only, see this URL: http://goo.gl/pBrI4C. I displayed
the ticks for the lower axis as well. As can be seen from this newer
graph, the negative spikes takes around 9 minutes, while the positive
spike takes somewhere around 24 minutes.

So, what do you think?

Best regards,

More information about the questions mailing list