Date: Sat, 21 Oct 1995 15:42:21 +1000 From: Bruce Evans <bde@zeta.org.au> To: joerg_wunsch@uriah.heep.sax.de, wollman@lcs.mit.edu Cc: freebsd-current@FreeBSD.org Subject: Re: clock running faster? Message-ID: <199510210542.PAA05176@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>>> The changes have the effect of making the Pentium clock the reference. >> I don't think this has been a good idea. >Please explain your reason for believing this, keeping in mind that a >similar technique was used on MicroVAXen in 4.3 (except using >microtime() rather than a purpose-built function). The 8254 clock, being intended for timekeeping, is perhaps more accurate and/or stable than the system clock. The system clock should be slowed down to save power when the system is not in use... Perhaps apm compensates for this. See apm_default_suspend() and apm_default_resume() in apm.c. Hmm. These routines seem to be buggy. inittodr() has a resolution of 1 second and is called twice for each suspend/resume. There is more jitter for residuals in the counters. The 8254 residual is limited to the (small) maximum count, but if the Pentium clock continues to run while clock interrupts are masked, then its residual is bounded only by the 64 bits in the counter register. This is a problem for settimeofday() too, but then the residuals are limited to what has accumulated since the last clock interrupt. The splsoftclock() in apm_default_suspend() is a bug. splsoftclock() doesn't nest. It sets the pl to the softclock pl, blowing away the previous pl. Masking softclock() is neither necessary for calling microtime() or inittodr() nor sufficient for atomicicity. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199510210542.PAA05176>