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" <[email protected]> wrote: > Gary E. Miller <[email protected]>: > > > 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 [email protected] Tel:+1 541 382 8588 # My RasPi 2/Adafruit HAT config. # contributor: Gary E. Miller <[email protected] # 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
pgpcZkaND6CXO.pgp
Description: OpenPGP digital signature
_______________________________________________ devel mailing list [email protected] http://lists.ntpsec.org/mailman/listinfo/devel
