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
