From owner-freebsd-hackers Sat Apr 6 10:46:48 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id KAA10714 for hackers-outgoing; Sat, 6 Apr 1996 10:46:48 -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 KAA10709 for ; Sat, 6 Apr 1996 10:46:45 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id EAA06070; Sun, 7 Apr 1996 04:46:05 +1000 Date: Sun, 7 Apr 1996 04:46:05 +1000 From: Bruce Evans Message-Id: <199604061846.EAA06070@godzilla.zeta.org.au> To: alk@Think.COM, nate@sri.MT.net Subject: Re: interrupts and such Cc: hackers@freebsd.org Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >> Why retain clk0? It *does* seem a bit excessive. >Both are necessary. It's basically a 'sampling' problem. You must >sample faster than events are occuring to more accurately gain >information about them. Since the sheduling algorithm still uses clk0 More precisely, you must sample independently to obtain unbiased information, and you may sample faster to obtain more accurate information. The usual rtc0 rate is only slightly faster than the clk0 rate (128:100). 128 Hz is too slow to give accurate profiling information while you wait on anything faster than 1 Mhz 8088, so a faster rtc0 rate of 1024 Hz is used for profiling. This is fast enough for a 10 MHz 8088 :-). >With the current system, it's possible for a process to burn up just a old (BSD before 4.4Lite) >tiny bit less than it's quantum at times but *never* have any of it show >up in scheduling or profiling. It could start the quantum in one >routine, jump into the 'hog' routine, and return back before the quantum >expires. In this case, the scheduler and profiler would not have >accurate statistics so therefore couldn't be counted on unless something >better existed. (Which we have now). Bruce