Changing the kernel's tick

Mac Mini.

The offset is like half a second. Enough that it wants to correct it with a step. But after that, it wants to keep stepping, and never goes back into synch, at least with the standard apple ntp.conf file. It just keeps stepping forward, then backwards.

If I change the ntp.conf to the "normal" of just listing the server, not any minpoll/maxpoll, then it resets the timing to 64 seconds, and can synch again.

Edit: The idea is that if I know how long the system was asleep for, and I know the approximate drift factor, then I can make a single step at wakeup that should cover the drift while I slept; that should be more accurate than the (determined to be inaccurate) guess that ntpd keeps making.

Actually, ntpdate is a BAD choice, even the docs say so.

ntpd -q is the replacement, and has better behavior for determining the actual time, rather than "ok, the first estimate we get must be accurate".

Well, lets try something.

I've got the apple standard conf file in place
I've got a good drift adjustment (from a normal ntpd run)
I've got a well synched clock to start with

Lets start by seeing how long it takes for a 4096 poll to synch

Alright, displaying the tick can be done with

% sysctl kern.clockrate
kern.clockrate: hz = 100, tick = 10000, profhz = 100, stathz = 100

Setting it requires a custom program.

It took about 5 hours to synch with a known good drift file.
With no drift file ... (testing).

Alright, here's more information.

#1. Setting "iburst" has no effect that I can detect.
#2. If there is no initial drift file, ntpd assumes the drift is 0.0.
#3. When the system wakes up from a sleet, the first poll that ntpd takes will seem way off, and the clock will go "unsychronized". The second sample will be consistent with the first; ntpd will assume "accurate", and step the clock. ** It will also change the drift. It assumes that the entire overnight drift happened in about one hour, so it changes the drift from 4.5 to about 500.
#4. This means that about 3 hours after waking up, it will step forward about 1.5s, and 5 and a half hours later it will take another step backwards (about 2.5 seconds). It takes about 14 hours before the clock is synchronized properly -- just in time to go to sleep again.

Work arounds?

Mar 22 08:09:55 stb-mac kernel[0]: System Sleep
Mar 22 08:09:55 stb-mac kernel[0]: System Wake
Mar 22 08:09:55 stb-mac kernel[0]: Wake event 0020
Mar 22 08:09:55 stb-mac configd[33]: posting notification com.apple.system.config.network_change
Mar 22 08:09:58 stb-mac kernel[0]: USB caused wake event (OHCI)

Console log shows that the sleep event is noticed after wakeup. Not good. It doesn't seem possible to "Note time of sleep, note time of wake up, adjust clock".

The "best" answer I have at the moment is to just restart ntpd after system wakeup. The clock will be 1.5s off for about 5 hours, but it will keep the right drift, and will only have to step once, and it won't step backwards.

Meanwhile, I do not know how to automatically do something on the wakeup. I don't know what scripts are run at wakeup.