[ntp:questions] A Christmas puzzler - intermittent offset oscillations with a PPS source

A C agcarver+ntp at acarver.net
Fri Dec 21 21:55:57 UTC 2012


On 12/21/2012 11:51, Rick Jones wrote:
> David Taylor <david-taylor at blueyonder.co.uk.invalid> wrote:
>> Although the offset appears to have a 1.25 hour period from the MRTG
>> graphs, examining the loopstats directly shows that the actual
>> period is just over about 5/3 minutes - just over 100 seconds.  I
>> don't know what's happening.  I would have put it down to poor GPS
>> strength, except that the effect lasts almost a whole day, and GPS
>> missing usually contributes bigger offset spikes.  I would not
>> expect it to be the navigation mode of the GPS as the excursions are
>> larger than I would expect between navigation and timing modes, but
>> I don't have a lot of experience in that area.  One difference in
>> the configuration is that #1 - the one with the offsets - runs and
>> uses gpsd for the coarse seconds, whereas #2 relies on the rest of
>> the network.  This seems to causes a higher CPU usage in #1, shown
>> in there graphs:
>
>>     http://www.satsignal.eu/mrtg/performance_raspi-1.php
>>     http://www.satsignal.eu/mrtg/performance_raspi-2.php
>
> Does the gpsd do anything every 5/3 minutes?  Or put another way, can
> you find a similar periodicity in the CPU utilization?  If it does do
> something interesting at that frequency and it involves a system call,
> while the act of tracing would perturb things, you might find it in a
> (timestamped) system call trace (strace) of the gpsd.
>
> Perhaps the luck of process scheduling and the gpsd or some other
> daemon holds-off the ntpd?  (Raspberry Pi's are single-core systems
> right?)  Does the ntpd run at a higher (realtime?) priority than the
> gpsd?
>
> Might there be any other background dameons consuming more CPU on the
> one system than the other?
>

I see something similar under NetBSD and a GlobalSat receiver using gpsd 
for coarse numbering and direct PPS via DCD into ntpd for the PPS sync 
(ATOM driver).  The period of instability in my case is much longer but 
regular at something like 100 hours (there's also a smaller spike every 
24 hours due to logrotate and similar housekeeping).  I've never tracked 
down the 100 hour cycle, though.



More information about the questions mailing list