Date: Wed, 5 Apr 1995 23:31:23 +1000 From: Bruce Evans <bde@zeta.org.au> To: rgrimes@gndrsh.aac.dev.com, steve2@freefall.cdrom.com Cc: freebsd-hackers@FreeBSD.org Subject: Re: Colorado Jumbo 250MB ft, and FreeBSD 2.0R Message-ID: <199504051331.XAA20445@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>> timing problems. At one time the timing characteristics of the driver >> worked for almost everyone as long as your CPU and bus speed was not >> on the extreme in either direction. It seems with PCI and/or pentium >> systems this may no longer be the case. Has anyone examined the DELAY >> (microtime?) function to see if it is running noticeably faster on those >> systems? >Bruce, do we need to something with the DELAY code? I have 4 different >Pentiums here, 3 w/PCI if you need someone to run some test code. DELAY(n) is currently only guaranteed to delay for n - 20 + small_machine_dependent_delay(machine(time)) microseconds. small_machine_dependent_delay(machine(time)) is a rapidly decreasing positive function of time :-). You could add 20 to guarantee a minimal delay, but then DELAY(1) would take much too long on slow machines and too long on most machines. Use the kernel option DELAYDEBUG to get some boot-time calibration. Add another test `for (n1 = 0; n1 < 1000000[0...]; ++n1) DELAY(20);' and use a stopwatch to see how wrong DELAY(20) is. The calibration should be done in the kernel. This requires 1) finding a suitable clock calibrate against. The 8254 clock is suitable, but nit very easy to use because it has a small maximum count and DELAY() is first run with interrupts disabled so it can't depend on clock interrupts to keep track of counter overflows. 2) recalibration often enough to allow variations in machine speed. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199504051331.XAA20445>