On 12/21/2012 11:51, Rick Jones wrote:
David Taylor <david-tay...@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.
_______________________________________________
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
