Re: ntp questions
Hi there,
On Sun, 15 Mar 2020, Gene Heskett wrote:
... What I wanted was to sync to the debian servers with this
machine, and then let it broadcast to the rest of the local network,
Some observations about ntpd and NTP in general:
1. Unless you're running a time laboratory, don't use ntpd. Use chrony.
In my experience it's much more forgiving, easier to configure and does
the job it needs to do for those of us who are happy with accuracies in
the order of a couple of milliseconds. I used ntpd for decades. Since
I started using chrony a few years ago it has been *much* less trouble,
and I no longer feel the need to be subscribed to a 'time' mailing list.
This has the happy side-effect that I also don't need to worry about
being berated by some NTP guru for using a Linux box as a time server.
2. If you must use your own server, in addition to them use a pool of
remote time servers such as provided by Debian. You really don't want
the time on your network hunting around following a single rogue box
after it unexpectedly rebooted with the wrong time. Please use the
'makestep' chrony directive on machines which aren't running 24/7; by
all means use prefer, iburst etc. if you feel the need.
3. Enable the (three) chrony logs and look at them often - especially
just after boot, so you get a feel for how quickly you can expect the
time to be recovered. It should be no more than a couple of minutes.
4. Use e.g. Nagios/Icinga to monitor things like this. I can let you
have some example graphs privately, and configuration snippets too if
it will help. If the time on any box goes out of spec. I get an email
within minutes.
I can add more stratum 2 stuff to this machine, and I can move this
machine to above the debian servers in the ntp.conf if order helps.
5. You shouldn't worry about strata yourself, let the servers do that.
Low strata don't necessarily equate to high accuracy, and vice-versa.
6. For a few $currency_units you can add a RTC module to any device
which doesn't have one. I prefer to keep the hardware clock on UTC,
and let the OS and/or application software worry about any timezones,
and especially about changes such as Daylight Saving. With a bit of
effort, the hardware clock will see only the (very) occasional leap
second adjustments.
7. See https://en.wikipedia.org/wiki/NTP_server_misuse_and_abuse for
many ways of inadvertently abusing NTP, which you should avoid, and a
few ways of being led down the garden path too (also to be avoided).
currently 3 amd64 boxes, and the rpi4.
I note with interest that you're using a Raspberry Pi 4. In my recent
experience these are particularly flaky compared with other Pis - and,
well, everything else. They really hate disturbances on the USB ports
for example and will hang/crash/reboot/remount-read-only/trash-the-fs
without warning if you should happen to plug in a second USB camera or
disc. It seems to me it's the power conditioning that's at the root
of this, but at the moment I haven't worked with them for long enough
to say much more than that. I'm using Pi 3s for things like my backup
servers, they seem to be much more reliable. I'm writing this mail on
a Pi3b+ which has been my desktop thin client and also a backup server
for some months. It's never put a foot wrong. Even the one venerable
Pi 2 that we have here is more reliable than the 4. The Zeros seem OK
if you don't overtax them, but we tend to use them just for gadgetry.
Or rather _did_ use them. AFAICT at the moment you can't actually buy
one anywhere, and this situation does not seem to be improving; so any
time spent designing with Zeros seems to have been pretty much wasted.
--
73,
Ged.
Reply to: