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

A C agcarver+ntp at acarver.net
Sat Dec 22 04:37:50 UTC 2012

On 12/21/2012 19:38, Mischanko, Edward T wrote:
>> -----Original Message-----
>> From: questions-
>> bounces+edward.mischanko=arcelormittal.com at lists.ntp.org
>> [mailto:questions-
>> bounces+edward.mischanko=arcelormittal.com at lists.ntp.org] On
>> Behalf Of A C
>> Sent: Friday, December 21, 2012 3:56 PM
>> To: questions at 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-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.

> 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.

More information about the questions mailing list