From owner-freebsd-hackers Sat Jun 3 01:54:27 1995 Return-Path: hackers-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id BAA17734 for hackers-outgoing; Sat, 3 Jun 1995 01:54:27 -0700 Received: from cs.weber.edu (cs.weber.edu [137.190.16.16]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id BAA17728 for ; Sat, 3 Jun 1995 01:54:23 -0700 Received: by cs.weber.edu (4.1/SMI-4.1.1) id AA05266; Sat, 3 Jun 95 02:47:16 MDT From: terry@cs.weber.edu (Terry Lambert) Message-Id: <9506030847.AA05266@cs.weber.edu> Subject: Re: Interval timer/System clock To: bde@zeta.org.au (Bruce Evans) Date: Sat, 3 Jun 95 2:47:15 MDT Cc: bde@zeta.org.au, freebsd-hackers@FreeBSD.ORG, james@miller.cs.uwm.edu In-Reply-To: <199506030425.OAA32558@godzilla.zeta.org.au> from "Bruce Evans" at Jun 3, 95 02:25:37 pm X-Mailer: ELM [version 2.4dev PL52] Sender: hackers-owner@FreeBSD.ORG Precedence: bulk > >Would it be resonable to propose a faster system clock than 10ms? The > >DEC hardware seems to run somewhere around 5ms which would give you an > >accurate user level clock at 10ms. > > I used 200Hz for a long time with no problems (I don't run timed or > xntpd). I've used 10000Hz for testing. I think there is little need > for faster than 100Hz except for quasi-real-time stuff. Terry's > one-shot timers might work better for that. The stuff that I usually propose has two purposes: 1) gettimeofday/getitimer/setitimer/select, all of which are considered "Real Time Extensions" according to SVID III. 2) Replacing DELAY in device drivers as part of enabling kernel multithreading, a necessary step in maximizing concurrency and aloowing kernel multithreading in an SMP environment. The Kernel preeemption issue for the QIC-40/80 driver is that it needs "at this time" rather than "at least after this time" for correct operation without buz-looping: in other words, deadlining (another Real Time issue). This is desirable because of the relatively long duration of the intervals where a buzz-loop is currently used, in combination with the lack of a FIFO that exists or that can be detected on most floppy controllers. Up to 60% of your system time (depending on how fast your box is) can be wasted keeping correct timing for the driver (which is why we all hate floppy tape drives). What the previous poster wants is a faster system time update frequency, which is actually only loosely coupled to the system clock frequency. On a relatively idle system, a SPARStation 1+ can keep interval timers/select timeouts/time of day to about 4uS. There's no real hardware reason (if f you accept an HZ value of 64 or 128) that PC hardware couldn't do the same. It's all in the mailing list archive. Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers.