Date: Tue, 8 Apr 2014 21:16:02 +0700 From: Alexey Dokuchaev <danfe@nsu.ru> To: John Hein <john.hein@microsemi.com> Cc: ppc@freebsd.org Subject: Re: System clock falls behind quickly on Mac mini G4 Message-ID: <20140408141602.GA39088@regency.nsu.ru> In-Reply-To: <21311.7096.419714.506103@gromit.timing.com> References: <20140328071714.GA45961@regency.nsu.ru> <CAFY7cWBCFmtx4Tsg3=mSJyscpk5nCY3S6Sxy52TKEoTmy1sFPA@mail.gmail.com> <CA%2BWntOtEoqG_RJ2D9vSb7mO-UfT13RZbAb04p6rV2mWLBu=H9Q@mail.gmail.com> <20140329100134.GA7863@regency.nsu.ru> <20140404144753.GA58190@regency.nsu.ru> <21311.7096.419714.506103@gromit.timing.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Apr 04, 2014 at 02:53:12PM -0600, John Hein wrote: > Alexey Dokuchaev danfe-at-nsu.ru wrote at 21:47 +0700 on Apr 4, 2014: > > Running ntpd(8) unfortunately does not make things better (well maybe it > > helps a bit, but clock still drifts away pretty fast). I guess my only > > option is to run ntpdate(8) periodically. :-( > > You could try chronyd vs. ntpd - the former works with a larger > frequency error. Untested by me. I also don't think we have a port > yet. Thanks for suggestion; I'll take a look into chronyd and report of the results. > It may be that your mini G4 may have real clock issues - that would > require some analysis to determine if that's real or a software bug. > But chronyd might be a workaround (if it's not too hard to port) until > someone who is motivated can do a more careful analysis. True; I'll follow up with verbose dmesg(8) output in a separate email on this thread; maybe it'll give some clues. ./danfe
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140408141602.GA39088>