Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.1 6/24/83; site redwood.UUCP Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!ihnp4!zehntel!hplabs!hpda!fortune!rhino!redwood!rpw3 From: rpw3@redwood.UUCP (Rob Warnock) Newsgroups: net.unix-wizards Subject: Re: Csh confusion: #define HZ 100? Message-ID: <95@redwood.UUCP> Date: Wed, 12-Dec-84 01:53:38 EST Article-I.D.: redwood.95 Posted: Wed Dec 12 01:53:38 1984 Date-Received: Sat, 15-Dec-84 00:19:04 EST References: <6564@brl-tgr.ARPA> Organization: [Consultant], Foster City, CA Lines: 56 +--------------- | From: guy@rlgvax.uucp | True, except humans don't have to deal with the math most of the time; that's | what computers are for. 100 seems to be an inappropriate frequency, as | you spend too much time servicing clock interrupts. (One could imagine | a UNIX system which didn't run the system clock at any set frequency, but | just set it to interrupt when the next "interesting" event happened, like | quantum expiration, a "callout" timeout coming due, etc..) | Guy Harris | {seismo,ihnp4,allegra}!rlgvax!guy +--------------- We (mainly Dave Yost, with my sniping and "+1"s) actually did something similar to this back at Fortune Systems. All internal short-term time intervals (used for callouts, etc.) were converted to fixed-point rational arithmetic -- 32 bits with the binary point 20 bits from the right, so the maximum interval was (signed) 2048 seconds, with a resolution of approximately one microsecond (2**(-20) sec.). This was originally done because the disk driver wanted to be able to do overlapped seeks on "buffered-stepper" ST506-type drives, and needed fine-grained callouts for predicting when to "re-connect" to wait for the final "ready" from the drive. (A similar strategy used back on TOPS-10 for DECtapes was called "dead reckoning". Yes, you could do overlapped seeks on DECtape!) The hardware clock was driven off a Z80B-CTC (which also supplied baud rates to certain devices) and was the highest (non-fatal) interrupt level, but ALL scheduling and callouts (and "pseudo-DMA" completions) took place at the lowest level via a hardware "doorbell" interrupt. All other I/O devices were at intermediate levels. Because of this, actual hardware clock interrupt code was VERY short: decrement a count of micro-ticks-to-go, and trigger a scheduler interrupt if negative. (It was allowed to underflow so that real time would not be lost; any underflow was accounted for when the low-level code actually got to run.) Even in critical sections, the clock interrupt was left enabled ("spl7()" actually meant "spl5()"), so as to not lose real time. The "lbolt" scheduler was just another callout event. Since you always know what the next event is (it's the first one in the callout chain), it's easy to have the (soft) clock interrupt only when needed, rather than at a fixed interval. Given the above, and given the very small overhead of the hardware clock interrupt, we found that the hardware clock rate didn't affect system overhead nearly as much as before. Rates as high as 900 Hz were used during certain debugging sessions, with little affect on performance. (Of course, even one or two percent is worth SOMETHING, so I believe the standard rate used in the field is 50 or 60 or 90 or something low like that.) Rob Warnock Systems Architecture Consultant UUCP: {ihnp4,ucbvax!dual}!fortune!redwood!rpw3 DDD: (415)572-2607 Envoy: rob.warnock/kingfisher USPS: 510 Trinidad Ln, Foster City, CA 94404