State of the microserver HOWTO
Gary E. Miller
gem at rellim.com
Tue Jun 7 20:36:51 UTC 2016
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
> Then explain the ordering to avoid startup glitch and the ARP
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.
> 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?
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
# 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.
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
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 220.127.116.11 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 18.104.22.168 maxpoll 5 # catbert
peer 22.214.171.124 maxpoll 5 # pi2
#peer 126.96.36.199 maxpoll 5 # pi3
peer 188.8.131.52 maxpoll 5 # kong
peer 184.108.40.206 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
Size: 473 bytes
Desc: OpenPGP digital signature
More information about the devel