From owner-freebsd-current Tue Apr 2 03:23:59 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id DAA06976 for current-outgoing; Tue, 2 Apr 1996 03:23:59 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id DAA06951 for ; Tue, 2 Apr 1996 03:23:38 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id VAA10642; Tue, 2 Apr 1996 21:18:01 +1000 Date: Tue, 2 Apr 1996 21:18:01 +1000 From: Bruce Evans Message-Id: <199604021118.VAA10642@godzilla.zeta.org.au> To: bde@zeta.org.au, phk@critter.tfs.com Subject: Re: calcru: negative time: Cc: freebsd-current@freefall.freebsd.org, kuku@gilberto.physik.rwth-aachen.de Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >> >My i386 has really high numbers here. >> >> Highly negative numbers? They can't go more than 10000 usec negative >> on i386's due to the causes that I know about. >Generally in the ~5000 range (+/-3000) and occasionally >>10000. I think 5000 means that you missed a whole clock interrupt. E.g.: actual time event reported time comments 0 Xintr0() 10 hardclock() 9000 splhigh() 10000 Xintr0() sets ipending bit for intr0 19000 microtime() 19000 no problem yet 20000 Xintr0() oops, missed a whole intr0 24000 microtime() 14000 oops 25000 splx() 25005 hardclock() 26000 microtime() 16000 oops Another possibility is that TIMER0_LATCH_COUNT = 20 is too small. Now I'm worried that it is too small if there are bus-hogging DMA controllers. My U34F seems to cause a maximum latency of > 160 usec. siointr() can also cause a latency of a few hundred usec if there multiple active lines. TIMER0_LATCH_COUNT should be smaller than 62.5 for operation at 16Khz (used by pcaudio). Perhaps the correct fix is to drop support for pcaudio. >It seems to be connected to fork/exec on my mach. It (actually failing of a more complete test in mi_switch()) seems to be connected with doing a bunch of disk accesses after the system has been idle for some time. I suspect vm. I didn't like changing splimp() in vm to splhigh(). I turned off my i586 clock fixup code in hardclock() and got the expected reports from test code in hardclock() about negative microtime deltas. The worst case over a period of 8 hours was -37 usec. This normally isn't a problem because microtime() calls are normally separated by more than 37 usec. >How about ESDI disks, could they monopolize the cpu on slow systems ? The could only monopolize the cpu, not the clock. The worst case is if wdstrategy() is called at splhigh() (it shouldn't be) and writes 16 (?) 512-byte sectors in 2 ms to 4ms. After doing the initial transfer it can only be called at splbio() when it can't hurt the clock. Bruce