On 12/21/2012 19:38, Mischanko, Edward T wrote:
-----Original Message-----
From: questions-
bounces+edward.mischanko=arcelormittal....@lists.ntp.org
[mailto:questions-
bounces+edward.mischanko=arcelormittal....@lists.ntp.org] On
Behalf Of A C
Sent: Friday, December 21, 2012 3:56 PM
To: questions@lists.ntp.org
Subject: Re: [ntp:questions] A Christmas puzzler - intermittent
offset oscillations with a PPS source
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.
Why use GPSD? I am running FreeBSD 8.2 and use the NMEA driver along with the
ATOM driver. If this is incorrect, how do I use GPSD? I am very new to
FreeBSD and UNIX in general, so your patience is appreciated.
I'm choosing to use gpsd because my receiver is configured to emit SiRF
data instead of NMEA. I'm also using the SiRF data for other functions
and gpsd will export the data across network connections. Using the
NMEA driver isn't incorrect. It's perfectly acceptable if you're only
using the GPS receiver for ntpd. Since I'm using it for other things, I
need gpsd's ability to supply data to multiple clients (ntpd is the
client by shared memory, other programs are clients by socket
connections) and I want some of the SiRF data. Of course ntpd doesn't
support SiRF in the first place.
_______________________________________________
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
