Hi Gary, Hal, All,

On 1/02/2017 06:19, Gary E. Miller wrote:
Yo Hal!

On Tue, 31 Jan 2017 01:35:41 -0800
Hal Murray <hmur...@megapathdsl.net> wrote:

Does a 1.42 GHz Mac mini really run at 1.42?  Why does Open Firmware
say 1.416666?

I think we are heading the wrong way on this.  It is not an Open
Firmware problem and it is not a Mac problem.  I have seen this before
with NTP Classic.  I have verified before that Chronyd does not have the
same issue.

There was a time I used to buy and provision  10 identical servers at a
time. Of the 10, one often had this problem.  The fix was chrony.

Sometimes the clock needs to be pulled more than ntpd expects and ntpd
gives up just before it succeeds.

I think this is clearly an ntpd bug.

I'd wondered about that too - is this just an ntpd bug. So I guess I'm more poking at this holistically - we have a piece of hardware, albeit old-ish - that doesn't seem to play nice with free software when it comes to its time keeping.

So I figure if we narrow it down and fix a bug in ntpd that's cool. If we narrow it down to an issue in open firmware or otherwise unique to that particular system that needs a kernel workaround that's not a bad result either :)

Embarrassingly it only just occurred to me to apply some google fu to "Mac Mini G4 clock problem" and it yielded some interesting hits.

"Clock Drift on Mac Mini (G4-based), ajdtimex, ntp" - undated
http://i1.dk/misc/mac_mini_clock_drift_adjtimex_ntp.html

"System clock falls behind quickly on Mac mini G4" (2014 on FreeBSD)
https://lists.freebsd.org/pipermail/freebsd-ppc/2014-April/006931.html

So I'm leaning towards us being onto something :)

Cheers,
Hugh



_______________________________________________
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Reply via email to