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.
