On Thu, Aug 27, 2020 at 11:41:44AM +1200, Bryan Christianson wrote: > It worked!!! I left the daemon running for over 30 minutes and it held the > system time to +/- 5 usecs of NTP, (mostly better than +/- 1usec). The timed > daemon did NOT change the clock at all during this test and chronyd behaved > as expected.
That's good to hear. > > I repeated the test with ntp_adjtime() enabled and kept a log of debug > messages (attached). A simple analysis of the debug trace seems to say that > the reference clock is leaping about, but I proved that it isn't with my > first adjtime() test. Also the reference clock works perfectly with earlier > versions of macOS, my linux machines etc. > > My current conclusion is that the Darwin kernel in Big Sur has a bad > implementation of ntp_adjtime() that somehow causes the clock to jump by > random intervals. I would really appreciate help in building a *simple* > program to be able to demonstrate this to Apple in a new bug report. You could start with the test/kernel/ntpadjtime.c program, modified to very slowly change the frequency of the clock, e.g. 1 ppm per minute. If you run at the same time chronyd with the -x option and a short polling interval, you should see in the tracking log when the offset jumped. -- Miroslav Lichvar -- To unsubscribe email chrony-dev-requ...@chrony.tuxfamily.org with "unsubscribe" in the subject. For help email chrony-dev-requ...@chrony.tuxfamily.org with "help" in the subject. Trouble? Email listmas...@chrony.tuxfamily.org.
