State of the microserver HOWTO

Tue Jun 7 20:36:51 UTC 2016

Yo Eric!

Whoops, the last one I sent you wass an old copy.  See below for my
latest update.  Really.  I hope...

On Tue, 7 Jun 2016 08:37:07 -0400
"Eric S. Raymond" <esr at thyrsus.com> wrote:

> Gary E. Miller <gem at rellim.com>:
> > > Assume I've never read that list, or anything else about NTP other
> > > than the HOWTO itself.  Remember who we're teaching!  
> > 
> > You want me to do all the work?!?  You're the writer.  :-)  
> 
> Yes, which is why I know how error-prone and crazy-making for both of
> us it would be to do this by micropatching.

But then I can't blame you when someone finds an issue!

> Trust me, I'll be doing
> plenty of work, some of which you won't be positioned to notice.

Yes, and a lot of the results are very noticeable.

> > > Complete config with improved header comment, please.  Having me
> > > edit in stuff every time someone needs to correct or amplify an
> > > explanation will not scale and *will* drive me bugfuck crazy.  
> > 
> > See below.  Not sure what you want in the header.  
> 
> Well, to start with, something like:
> 
> "This configuration uses the shared-memory refclock (28), which is

Done.

> Then explain the ordering to avoid startup glitch and the ARP
> problem,

Whoops, I had done that, but I sent you the wrong copy.

My bad.  In this copy.

> noting that these are arguably due to bugs and the startup
> glitch should be fixed in a future release.

Done.

> What is mode 16 doing?  What are flag1 and flag2 doing?

I do not use mode 16, or flag1 or flag2.

> How was the 0.450 fudge derived?

This is starting to sound like the howto redone?

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
	gem at rellim.com  Tel:+1 541 382 8588

# My RasPi 2/Adafruit HAT config.
# contributor: Gary E. Miller <gem at rellim.com
# date: 7 June 2016

# /etc/ntp.conf, configuration for ntpd; see ntp.conf(5) for more help

# This configuration uses the shared-memory refclock (28), which is
# assumed to have gpsd on the other end.  Unit 0 is the in-band data,
# Unit 1 the PPS.

# for best performance, start ntpd last.  First start gpsd, and confirm 
# you have a good GPS # lock, Then confirm gpsd is supplying time to the 
# SHM interface.  Then you can start ntpd.

# I start gpsd this way:
#       # gpsd -n /dev/ttyAMA0
# check for GPS 3D fix this way:
#       # cgps
# check the SHM for good time:
#       # ntpshmmon
# Then start NTP
#       # ntpd -N -g

# save the clock drift when shutting down ntpd.
# this allows for faster NTP reconvergence after a restart
driftfile /var/lib/ntp/ntp.drift

# You want some logging, it will be useful later.
# 
# If you add the logging now, then you have the data when you figure
# out you want it.  If you wait until you want it then it is too late.  

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

logfile /var/log/ntpd.log  
logconfig =syncall +clockall +peerall +sysall

# we want some security
# do not let random people remotely modify your ntpd server
restrict default nomodify notrap nopeer noquery
restrict -6 default nomodify notrap nopeer noquery
# allow access from localhost, IPv4 and IPv6
restrict 127.0.0.1 mask 255.255.255.0
restrict -6 ::1
# replace this with your local IPv4 network
restrict 204.17.205.0 mask 255.255.255.0
# replace this with your local IPv6 network
restrict -6 [2001:470:e815::]/64

# The order of servers and peers in ntp.conf matters.
#
# On startup ntpd will take the first time it gets to set the system
# clock. If this first time is an imprecise clock, say derived from
# NMEA, then ntpd may takes days to restabilize.
# 
# The first time ntpd acquires will tend to be the ones higher up in
# the file with the lowest maxpoll.
# 
# So to work around this ntpd glitch put your best time sources high
# in the ntp.conf file, with your shortest maxpoll and your worst one
# at the bottom with higher maxpolls.

# SHM(1) is the PPS from gpsd
# PPS is first, it is the most precise.
server 127.127.28.1 prefer minpoll 4 maxpoll 4
fudge 127.127.28.1 refid PPS

# Next come my other local chimers, just in case the GPS loses signal, 
# and for comparison

# The default APR timeout on Cisco switch gear may be as long as
# 4 hours.  On windows and Linux it may be as short as 60 seconds.
# 
# If the polling interval for a chimer is greater than 60 seconds (maxpoll 6+)
# then when ntpd sends a time request to a remote ntpd daemon the OS may
# be adding an ARP roundtrip to the process, delaying the return
# by that much extra time.  This convinces ntpd that the remote ntpd
# is further away, and has more jitter, than it actually does.
# 
# To prevent this glitch in ntpd behavior, be sure to use 'maxpoll 4' or
# 'maxpoll 5' on servers and peers on the local network.

peer 204.17.205.1 maxpoll 5 # catbert
peer 204.17.205.17 maxpoll 5 # pi2
#peer 204.17.205.23 maxpoll 5 # pi3
peer 204.17.205.27 maxpoll 5 # kong
peer 204.17.205.30 maxpoll 5
peer [2001:470:e815::8] maxpoll 5 # spidey

# SHM(0) in band time from gpsd
# NMEA is last, it is the least precise, it has a lot of delay and jitter.
# time1 tells ntpd that the NMEA time arrives 450 millSec after the
# start of the second.  0.450 was selected to give the lowest average
# offset from PPS.
server 127.127.28.0 minpoll 4 maxpoll 4
fudge 127.127.28.0 time1 0.450  refid GPS

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.ntpsec.org/pipermail/devel/attachments/20160607/66cd5d3d/attachment.bin>