Puzzling clock offset spikes

[Paul Theodoropoulos]

Hi Hal,

On 6/30/2018 0:26 AM, Hal Murray wrote:
> What's in your ntp.conf?
refclock shm unit 1 refid PPS minpoll 0 maxpoll 0 prefer
refclock shm unit 0 refid GPS time1 .40 noselect

server clock.fmt.he.net           minpoll 5 maxpoll 10 iburst # Fremont
server clock.sjc.he.net           minpoll 5 maxpoll 10 iburst # San Jose
server clepsydra.dec.com          minpoll 5 maxpoll 10 iburst # Palo Alto
server stratum-1.sjc02.svwh.net   minpoll 5 maxpoll 10 iburst # San Jose
server gpstime.la-archdiocese.net minpoll 5 maxpoll 10 iburst # Los Angeles

restrict 0.0.0.0/0 limited nomodify nopeer noquery
restrict 127.0.0.1
restrict 192.168.1.222

leapfile /var/lib/ntp/leap-seconds.list
logfile /var/log/ntp.log
driftfile /var/lib/ntp/ntp.drift
statsdir /var/log/ntpstats/
statistics loopstats peerstats clockstats
filegen loopstats file loopstats type day enable
filegen peerstats file peerstats type day enable
filegen clockstats file clockstats type day enable

> You might try increasing any maxpolls if they are less than 6.  It's likely to
> make the normal case worse, but if the spikes get better that might tell
> you/us something.
I think I'm good above in the ntp.conf, right?

> Do you have full logging?
>    logfile /var/log/xxx
>    logconfig =syncall +clockall +peerall +sysall
Hmm - wasn't even familiar with logconfig until I looked it up just now. 
I think I'm okay, the manpage says that everything is on by default.
> There might be something interesting in there.
>
> You might try putting all the log files into a memory file system.  Maybe the
> disk writes are disabling interrupts long enough to cause troubles.  Or try a
> USB hard drive.
Yeah, I definitely need to try this. I know that any significant fs 
activity will cause spikes. And there's a nice setup out there that will 
write to memory fs, and flush back to disk when rebooting. I've tried 
adjusting the 'commit' interval both longer (60s) and shorter (5s) but 
no apparent difference.
> If you run out of other ideas, try without gpsd.  Use the NMEA and PPS drivers.
This is new to me too. I thought you had to run gpsd to send the data 
from the GPS to ntpd. I'll look into this.
>> I have a thin, closed-cell insulation sheet  affixed to the back of the GPS
>> hat to slow temp variations coming from  the Raspi itself
> The temperature of the GPS isn't important.  Time comes from the crystal that
> drives the CPU.  I think it's on the bottom of the board.

Another area of confusion for me here. The datasheet for the MT3339 
specifically mentions 'reference oscillator' -


      Reference oscillator

  *

    TCXO Frequency 16.368 MHz, 12.6 ~ 40 MHz

  *

    TCXO Frequency variation: ±2.0 ppm

  *

    Crystal Frequency: 26 MHz, 12.6 ~ 40.0 MHz

  *

    Crystal Frequency accuracy: ±10 ppm


So based on that, I assumed that controlling the temp of that crystal 
would be a good thing too. But then, looking at those specs, +/- 2ppm is 
horrendous, compared to the PPS's +/- 10ns. So it would seem the gps 
crystal is quite irrelevant...

Perhaps a thermal (conductive) pad on the bottom of the board to draw 
heat away from the crystal might be good...

Thanks for the suggestions/insights, Hal. I'll be poking around all day 
it looks like!


-- 
Paul Theodoropoulos
www.anastrophe.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ntpsec.org/pipermail/users/attachments/20180630/0f1fe2ef/attachment.html>