Timekeeping oddities on MacMini G4s

[Hugh Blemings]

Hiya,

Ben's email may have got bounced by the ntpsec list so forwarding here
for folk following along :)

Cheers,
Hugh



-------- Forwarded Message --------
Subject: Re: Timekeeping oddities on MacMini G4s
Date: Wed, 01 Feb 2017 14:34:48 +1100
From: Benjamin Herrenschmidt <benh at kernel.crashing.org>
To: Hugh Blemings <hugh at blemings.org>, linuxppc-dev at ozlabs.org
CC: devel at ntpsec.org, Hal Murray <hmurray at megapathdsl.net>, Paul
Mackerras <paulus at ozlabs.org>, Michael Ellerman <michael at ellerman.id.au>

On Wed, 2017-02-01 at 14:10 +1100, Hugh Blemings wrote:
> Hi,
>
> I've recently been lurking on the ntpsec project mailing list.
>
> One of the developers (Hal Murray, CCd) has been doing some tests of
> the codebase using FreeBSD and Debian on a G4 based Mac Mini - this
> largely motivated by checking all is well on a big-endian system.
>
> Hal has identified what appears to be a systemic inaccuracy in
> kernel timekeeping of around 2500ppm on both Linux and FreeBSD and on
> several different MacMini G4s (1.42GHz and 1.5GHz variants)
>
> That it appears on both Linux and FreeBSD kernels and some other
> data points leads us to wonder if the CPU frequency reported by Open
> Firmware being different to the actual raw clock is the root cause,
> but I/we speculate at this point.

Right, we just use the value provided by Open Firmware. Any chance you
can try with MacOS X ?

 From the value in the properties you showed me (and the ones I have in
some DT snapshots) it looks like the value isn't fixed but somewhat
calibrated by Open Firmware during boot.

It could be that this calibration sucks. MacOS X seems to do its own
calibration at boot time based on the KeyLargo timer. It would be useful
to see if their stuff is more precise, we could write something similar
for Linux and BSD.

Cheers,
Ben.