This note is about the clock drift in G4-based Mac Mini, ntp setup and adjtimex. I hope it is useful for someone else.
The problem is that there is something about the bus speed on G4-based Mac Mini or the clock detection in the linux kernel that makes the clock drift more than NTP is willing to correct. NTP will start but after a while complain and not correct the clock due to too much clock drift (more than 4 seconds per hour or something like that)
You can measure the clock drift using the approach described in NTP support page, but if your mac mini is like mine then you can jump ahead and fix it like this:
Execute: adjtimex --tick 10030 --frequency -7396720
This will change the tick setting of the kernel to the best estimate I can give. It will bring the kernel clock closer to being accurate and more importantly, accurate enough for NTP to correct.
I recommend putting that command into /etc/rc.local. There are nicer solutions, but there is no reason for making this more complicated than necessary.
Then (re-)start NTP. After a few hours (remember: be patient with ntp) ntpq -p will show something like this:
remote refid st t when poll reach delay offset jitter
==============================================================================
+redacted redacted 2 u 136 512 377 8.666 -2.543 0.267
-redacted redacted 2 u 174 512 377 12.358 -2.542 0.167
-redacted redacted 2 u 171 512 377 7.456 -3.509 0.722
+redacted .GPS. 1 u 237 512 377 33.783 1.015 0.078
*redacted .PPS. 1 u 284 512 377 18.951 -2.408 0.186
-redacted redacted 2 u 199 512 377 48.248 -14.544 0.508
LOCAL(0) .LOCL. 10 l 37 64 377 0.000 0.000 0.001
Wait a day or two, then issue adjtimex -p to find out what NTP thinks the clock correction is:
mode: 0
offset: -1128
frequency: -7457136
maxerror: 698880
esterror: 407
status: 1
time_constant: 9
precision: 1
tolerance: 33554432
tick: 10030
raw time: 1217685645s 182757us = 1217685645.182757
Then fix the adjtimex command you put into /etc/rc.local