Hi, > On 5 Mar 2020, at 06:33, Peter Jeremy <pe...@rulingia.com> wrote: > > Hi Dewayne, > > Sorry for the delay. Unfortunately, I can't really suggest anything - > it's not clear to me why ntpd would prefer a stratum 14 clock over a > stratum 2 clock. Have you tried looking through the debugging hints > page (https://www.eecis.udel.edu/~mills/ntp/html/debug.html)? > > I haven't seen that problem but I don't use the local clock. > > During startup, it would not seem unreasonable for the local clock to > become valid first because it will have a lower jitter. But ntpd > should switch to the stratum 2 clock and stay with in as the better > time source. One problem is that if ntpd decides to switch away from > the clock for any reason (eg a burst of jitter), it may get stuck on > the local clock as it drifts further from "real" time.
Yes. I’ve had exactly that happen with a stratum 1 (GPS) server with only local as fallback. The GPS signal dropped for a while and the box drifted off sufficiently that it wouldn’t reacquire the accurate clock. The solution is to add a few pool (or whatever) servers into the config - you can still ‘prefer’ a local server but it ensures the box won’t drift off into the weeds. > -- > Peter Jeremy -- Bob Bishop r...@gid.co.uk
signature.asc
Description: Message signed with OpenPGP
