In message <1489782793.40576.185.ca...@freebsd.org>, Ian Lepore writes: > On Fri, 2017-03-17 at 13:26 -0700, Don Lewis wrote: > > On 17 Mar, O. Hartmann wrote: > > > > > > > > Just some strange news: > > > > > > I left the server the whole day with ntpd disabled and I didn't > > > watch > > > a gain of the RTC by one second, even stressing the machine. > > > > > > But soon after restarting ntpd, I realised immediately a 30 minutes > > > off! This morning, the discrapancy was almost 5 hours - it looked > > > more > > > like a weird ajustment to another time base than UTC. > > > > > > Over the weekend I'll leave the server with ntpd disabled and only > > > RTC > > > running. I've the strange feeling that something is intentionally > > > readjusting the ntpd time due to a misconfiguration or a rogue ntp > > > server in the X.CC.pool.ntp.org > > A ntp should recognize a single bad server and ignore it in favor ofÂ > > the other servers that are sane. > > > > It sounds like something is going off the rails once ntpd starts > > calling > > adjtime().Â Â What is the output of: > > sysctl kern.clockrate > > > > I'd suggest starting ntpd and running "ntpq -c pe" a few times a > > minute > > and capturing its output to monitor the status of ntpd as it starts > > up > > and try to capture things going wrong.Â Â Â You should probably disable > > iburst in ntp.conf to give more visibility in the early startup. > > > > For the first few minutes ntpd should just be getting reliable > > timestamp > > info and won't start trying to adjust the clock until it has captured > > endough samples and figured out which servers are best.Â Â Then the > > behaviour of the offset is the thing to watch.Â Â If the iniital offset > > is > > large enough, ntpd will step the clock once to get it close to zero, > > otherwise it will just use adjtime to slowy push the offset towards > > zero.Â Â I think though that you will see the offset start gyrating > > madly. > > > > You might want to set /var/db/ntpd.drift to zero beforehand if there > > is > > an insane value in there.Â Â If the initial drift value is bogus, will > > try > > to use it which will push the time offset away from zero so fast that > > it > > will decide to keep stepping the clock back to zero before it can > > capture enough samples from the external servers to determine the > > true > > local clock drift rate. > > Do not set ntpd.drift contents to zero. Â Delete the file. Â There's a > huge difference between a file that says the clock is perfect and a > missing file which triggers ntpd to do a 15-minute frequency > measurement to come up with the initial drift correction.
Yes. And, without debugging output and/or a dump, I don't think we'll be any closer to the truth. Until then the best we can do is make educated guesses. -- Cheers, Cy Schubert <cy.schub...@cschubert.com> FreeBSD UNIX: <c...@freebsd.org> Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. _______________________________________________ email@example.com mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"