Re: [chrony-dev] chronyd broken on macOS Big Sur

[Bryan Christianson <bryan@xxxxxxxxxxxxx>]

> On 24/08/2020, at 12:29 AM, David Bohman <debohman@xxxxxxxxx> wrote:
> 
> Are you certain that that timed is remaining suspended? That launchd is not resuming it? I don't have a machine which will run Big Sur, so I cannot investigate it myself.
> 

I think I have ruled out timed as being the cause of the problem and have left it in the same state as earlier versions of macOS. It still runs every 5 minutes (visible in the system log) but is not causing the clock to jump.

When timed was first introduced by Apple on 10.13, the managed to completely break adjtime() because of inconsistent treatment of signed/unsigned integers. I wondered if they might have done something similar in Big Sur so I compiled chronyd with the ntp_adjtime() calls disabled, forcing use of adjtime() to slew the clock.

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.

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.

Thanks, Bryan

-- 
Bryan Christianson
bryan@xxxxxxxxxxxxx

Attachment: chronyd-debug.txt.gz
Description: GNU Zip compressed data