Date: Thu, 23 Jul 1998 09:15:09 +0200 From: Poul-Henning Kamp <phk@critter.freebsd.dk> To: Bruce Evans <bde@zeta.org.au> Cc: brian@Awfulhak.org, freebsd-current@FreeBSD.ORG, jak@cetlink.net Subject: Re: tickadj -t not changing tick Message-ID: <371.901178109@critter.freebsd.dk> In-Reply-To: Your message of "Thu, 23 Jul 1998 14:01:38 %2B1000." <199807230401.OAA09064@godzilla.zeta.org.au>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <199807230401.OAA09064@godzilla.zeta.org.au>, Bruce Evans writes: >>>The whole problem may be caused by APM. APM's time handling is of low >>>quality. >> >>As currently designed, there is only the RTC chip which is reliably keeping >>track of time on a APMized system, and only reading the registers is reliable, >>the number of interrupts and their frequency is subject to change without >>notice. > >The RTC is sufficiently reliable. One reason that APM's time handling is >of low quality because it doesn't sync with the RTC; it just reads it. You're talking about our APM code, I was talking about the APM bios spec and what it guarantees. Our implementation can be improved, the spec not so. >My version of inittodr() syncs with the RTC. This takes a second or two. >The delay would be bad if suspension intervals are short enough for the >innaccurate reading of the RTC to casue negative times. The problem is the "your clock is probably wrong now" events which I belive we currently ignore, they can happen as frequently as once ever few seconds, so a 1-2 sec delay in synchronizing to the rtc just will not do. -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." "ttyv0" -- What UNIX calls a $20K state-of-the-art, 3D, hi-res color terminal To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?371.901178109>