karl@osu-eddie.UUCP (11/29/84)
From: karl (Karl Kleinpaste)
I'm seriously confused...
We have been doing some major hacking on csh, particularly in the area
of rewriting the tcsh editor interface. (If you're interested, when
it's done, it'll edit in either vi or emacs style.) However, in
tracking down a core-dump bug which affects us only on our Suns, it was
discovered that that the symbol HZ, defined in sh.local.h, is #defined
as 100. Now, obviously, HZ is the ac line frequency; why would it ever
be 100? (Has Berkeley got some really strange power requirements?)
Two fortune cookies to the person who can tell me why HZ should be
100...
Also, as I said, the core-dump bug only affects the Suns. It has to do
with a modification made to periodically note who has logged in and out
by reading /etc/utmp. Any thoughts on that subject would be nice, too.
--
From the badly beaten keyboards of best address---+
him who speaks in _*_T_y_P_e_* _f-_O-_n-_T-_s... |
V
Karl Kleinpaste @ Bell Labs, Columbus 614/860-5107 {cbosgd,ihnp4}!_c_b_r_m_a_!_k_k
@ Ohio State University 614/422-0915 cbosgd!osu-eddie!karlagk@ihuxq.UUCP (Andy Kegel) (11/30/84)
> We have been doing some major hacking on csh, particularly in the area > of rewriting the tcsh editor interface. (If you're interested, when > it's done, it'll edit in either vi or emacs style.) Sounds like ksh(1). > However, in > tracking down a core-dump bug which affects us only on our Suns, it was > discovered that that the symbol HZ, defined in sh.local.h, is #defined > as 100. Now, obviously, HZ is the ac line frequency; why would it ever > be 100? (Has Berkeley got some really strange power requirements?) Obviously, HZ is not the ac line frequency, but more likely related to the periodic timer. The periodic timer is commonly based on the 60 Hz line, but not always. (Horn fanfare) Enter the AT&T 3B computer line. The first 3B machine (the AT&T 3B20D computer) was designed to run without the need for AC power (continuous processing was a requirement, batteries were the solution). The designers thought it would be nice if the clock and scheduler kept running (:-), so they provided a programmable timer. Given a programmable timer, I can understand why some one would decide to count 10 millisecond units than 16.66666666666666666666666666666666666666666666 millisecond units. Now that battery powered machines are becoming more common, I expect that 60 Hz will become an interesting bit of party trivia (but then, I can expect dancing elephants and Santa Claus, too). But why #define HZ 100 ended up in csh is a mystery to me. -andy kegel just another one of them AT&T Bell Labs people with opinions of his own
robert@gitpyr.UUCP (Robert Viduya) (12/01/84)
>< > > But why #define HZ 100 ended up in csh is a mystery to me. > On a wild guess, I would think it may have something to do with csh's capability of checking your mailbox every so often. I can see where there might be a speed increase if it kept a rough track of the time itself instead of issuing time(2) requests all the time. robert -- Robert Viduya Office of Computing Services Georgia Institute of Technology, Atlanta GA 30332 Phone: (404) 894-4669 ...!{akgua,allegra,amd,hplabs,ihnp4,masscomp,ut-ngp}!gatech!gitpyr!robert ...!{rlgvax,sb1,uf-cgrl,unmvax,ut-sally}!gatech!gitpyr!robert
karl@osu-eddie.UUCP (Karl Kleinpaste) (12/01/84)
Oh, my, if I'd just put about 12 seconds more thought into the problem
before I posted on the subject...{:-)}
----------
> > We have been doing some major hacking on csh, particularly in the area
> > of rewriting the tcsh editor interface. (If you're interested, when
> > it's done, it'll edit in either vi or emacs style.)
> Sounds like ksh(1).
----------
Um, no, actually it isn't. The basic problem with ksh is that, deep down
inside itself, it's still the Bourne shell. I've tried using it at work, and
I really don't care for it. I like the interface csh gives me, and so I am
adding (or, actually, re-adding) an editor interface to it. The editor
interface is being rewritten because the original tcsh editor interface is a
rather crufty hack; it works, but just barely, and not very well. This
particular csh also has a whole herd of extra functions and capabilities
that I happen to like/want which Bourne shell still doesn't have.
Anyway, the point is (for all of you who were still wondering, probably very
few by now) that HZ, although defined in csh's sh.local.h as 100 and
commented as being the AC line frequency, is no such thing. It's the
frequency at which the system's clock ticks. It seems that the folks who
were creating 4.2BSD didn't like trying to deal with the highly inconvenient
60 ticks/sec, and so they changed it to 100. I hadn't been aware of that
fact. Non-standard, but workable. OK, I lose. Gads, you'd think I never
hacked the kernel, which I do every single day.
Now about those fortune cookies I promised...I got this torrential rain of
mail, not to mention the articles which appeared as "Re: Csh confusion...",
and I have no idea who it was that first got it across to me. So if someone
can _p_r_o_v_e that they were the first, I'll send you those cookies...{:-)}
All I ask is that everybody _p_l_e_a_s_e stop writing me mail and explaining the
now-self-evident to me...like I said, if I'd just put a couple seconds' more
thought into the problem before posting, I wouldn't have had to bother
anybody else...
Oh, if it matters to anyone, Bill Shannon at Sun informed me that HZ on his
company's systems is 50, so don't get yourself confused if you're on one of
those.
--
From the badly beaten keyboards of best address---+
him who speaks in _*_T_y_P_e_* _f-_O-_n-_T-_s... |
V
Karl Kleinpaste @ Bell Labs, Columbus 614/860-5107 {cbosgd,ihnp4}!_c_b_r_m_a_!_k_k
@ Ohio State University 614/422-0915 cbosgd!osu-eddie!karlemks@uokvax.UUCP (12/01/84)
I don't know why "#define HZ 100" would be there, but government users would probably be the ones using 100 Hz power sups. I've got three 100 Hz generators in a warehouse at Tinker AFB for powering all of our field commo equipment... kurt
mark@tove.UUCP (Mark Weiser) (12/03/84)
HZ is not the line frequency, it is the clock frequency.
SUN picked 100hz for this. At very usenix's various Sun employees
and principals have admitted that this is a mistake--too much cpu overhead.
--
Spoken: Mark Weiser ARPA: mark@maryland Phone: (301) 454-7817
CSNet: mark@umcp-cs UUCP: {seismo,allegra}!umcp-cs!mark
USPS: Computer Science Dept., University of Maryland, College Park, MD 20742<nomdenet%tp3@rand-unix> (12/05/84)
From karl (Karl Kleinpaste): > We have been doing some major hacking on csh . . . it was > discovered that that the symbol HZ, defined in sh.local.h, is #defined > as 100. Now, obviously, HZ is the ac line frequency; why would it ever > be 100? (Has Berkeley got some really strange power requirements?) From: Mike O'Brien <obrien@CSNET-SH> > To the best of my knowledge, 4.2 runs the "line clock" at 100 Hz > instead of 60 Hz, probably so that the millisecond timer system calls > actually have a prayer of coming up with an answer. Probably also to > provide finer granularity to the scheduler at the expense of higher > overhead, but that's a guess so no flames, please! Just this last week I had occasion to burrow into 4.2's innards to check how the UNIX clock is handled. I learned HOW it's done, but nothing about WHY. "HZ" is another anachronism, another name made misleading due to hardware & software changes and kept for compatibility within kernel source files. PDP-11s have only a clock that interrupts 50 or 60 times per second depending on the power-line frequency, but VAXes have interval timers with microsecond precision. Up through at least 4.1, HZ did define the power-line frequency, the VAX interval timer being made to count an appropriate value (either 16,667 or 20,000 microseconds) before interrupting. In 4.2 BSD, HZ is now just the number of clock "ticks", or interrupts from the interval timer, per second, and is #defined as 100. (I don't know when the change was made, whether in 4.1a, 4.1c, or 4.2). 4.n Unix on VAXes uses the interval timer. The value in the Interval Count Register is incremented once per microsecond with at least 0.01% accuracy (which is almost nine times worse than an ordinary digital watch!). The ICR is automatically loaded from the Next Interval Count Register upon a carry out from bit 31 (overflow) which also interrupts at IPL 24 if the interrupt is enabled. The NICR may be reloaded at any time, and its value is retained after reloading the ICR. An Interval Clock Control/Status Register functions in typical DEC manner, with error, interrupt, interrupt-enable, and run bits. (All this is paraphrased from the 1982-83 VAX Hardware Handbook, and holds for 730s, 750s, & 780s). So much for the hardware. In kernel-source file conf/param.c is the defi- nition of HZ and the allocation & initialization of "hz": #define HZ 100 int hz = HZ; This file is included by config in every kernel directory as part of file param.c (e.g., in GENERIC/param.c). At boot time the clock is started by a call to strtrtclock in vax/clock.c. Here's the complete routine: startrtclock() { mtpr(NICR, -1000000/hz); mtpr(ICCS, ICCS_RUN+ICCS_IE+ICCS_TRANS+ICCS_INT+ICCS_ERR); } This loads the NICR with -10000 (it's never reloaded), loads the ICR, begins incrementing, and enables interrrupts. In sys/kern_clock.c is the interrupt routine, hardclock(). There's some "glue" between the hardware interrupt and this routine in vax/locore.s, viz.: SCBVEC(hardclock): PUSHR mtpr $ICCS_RUN|ICCS_IE|ICCS_INT|ICCS_ERR,$ICCS pushl 4+6*4(sp); pushl 4+6*4(sp); calls $2,_hardclock # hardclock(pc,psl) . . . POPR; incl _cnt+V_INTR ## temp so not to break vmstat -= HZ rei The mtpr instruction clears the interrupt. Config includes vax/locore.s in every kernel directory as part of file locore.c (e.g., in GENERIC/locore.c). A. R. White The Rand Corporation 1700 Main Street Santa Monica, California 90406 (213) 393-0411, x7997 ARPA: tp3!nomdenet @ Rand-UNIX UUCP: ... randvax!tp3!nomdenet
shannon@sun.uucp (Bill Shannon) (12/05/84)
> SUN picked 100hz for this. At very usenix's various Sun employees > and principals have admitted that this is a mistake--too much cpu overhead. Let's get our history straight. Bill Joy chose 100Hz. At Sun we decided the overhead was not worth it. We could not convince UCB. Sun systems run at 50Hz. Bill Shannon Sun Microsystems, Inc.
gordon@brl-tgr.ARPA (12/09/84)
One of the reasons for having HZ defined in csh is the "time" command. It's build into csh, and it doesn't call /bin/time. Quantities of CPU time are available in ticks of cpu time, not seconds, and HZ is needed as a conversion factor. There is no particular reason why the system clock has to run at the same speed as the power line frequency. Any reasonably stable clock of an appropriate frequency would do, and a HZ value of 100 makes a lot of math easier for the humans to deal with. Gordon Burditt ...!convex!ctvax!trsvax!sneaky!gordon ...!microsoft!trsvax!sneaky!gordon
guy@rlgvax.uucp (12/09/84)
> One of the reasons for having HZ defined in csh is the "time" command. > It's build into csh, and it doesn't call /bin/time. Quantities of CPU time > are available in ticks of cpu time, not seconds, and HZ is needed as a > conversion factor. Except that in 4.2, quantities of CPU time are available from the "old" system calls ("times", etc.) in ticks of 60ths of a second (not in any units based on the system clock - always 60ths of a second) and are available from the "new" system calls in *very* nominal units of microseconds. As such, under 4.2 no user-mode program need know the system clock frequency in order to interpret values from system calls (which isn't a bad idea, considering there's no way to get the clock frequency on "standard" UNIX systems except by pulling in the system include file giving HZ; not too good an idea if you want the same binaries to run in the US and in Europe on a machine whose system clock runs off the line frequency...). > There is no particular reason why the system clock has to run at the same > speed as the power line frequency. Any reasonably stable clock of an > appropriate frequency would do, and a HZ value of 100 makes a lot of math > easier for the humans to deal with. 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
guy@rlgvax.uucp (12/10/84)
> Except that in 4.2, quantities of CPU time are available from the "old" > system calls ("times", etc.) in ticks of 60ths of a second (not in any > units based on the system clock - always 60ths of a second) and are available > from the "new" system calls in *very* nominal units of microseconds. As > such, under 4.2 no user-mode program need know the system clock frequency > in order to interpret values from system calls... Well, actually, there is one mechanism that does supply time in system clock ticks - the "profil" facility. Somebody just posted a bug report that "profil" works in clock ticks, which are now 1/100 seconds on the VAX, but the "prof" command still thinks profiling works in 1/60 second units. How many systems out there have clocks run off the line frequency rather than off, say, a crystal? Systems running off the line frequency would either have to 1) always supply this time in some nominal units which need not be the unit of the system clock, 2) provide a facility by which a program can ask the OS what the system clock units are, or 3) supply different versions of a lot of the user-mode software in countries with different line frequencies. Systems with programmable clocks wouldn't have this problem. Guy Harris {seismo,ihnp4,allegra}!rlgvax!guy
G.ZEEP%MIT-EECS@MIT-MC.ARPA (12/10/84)
Keep in touch with me and other people at MIT's Project Athena about your tcsh changes. I'll see if I can get back changes to our tcsh to you. Certainly (although we may try to move beyond the simple csh model), a good terminal-based shell would be neat. wz (also try MELTSNER%MIT-ATHENA@MIT-MC.ARPA) -------
rpw3@redwood.UUCP (Rob Warnock) (12/12/84)
+--------------- | 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
mark@tove.UUCP (Mark Weiser) (12/16/84)
You who have done this, and those who are good guessers: suppose
I just reached into my kernel source and #define HZ N, for
some random N. Would anything break or give bad results (other
than profil, which does anyway, which started the whole discussion...)?
It seems to me that N=20 (50ms resolution) is plenty for our Vax 780
and will save a little overhead.
--
Spoken: Mark Weiser ARPA: mark@maryland Phone: (301) 454-7817
CSNet: mark@umcp-cs UUCP: {seismo,allegra}!umcp-cs!mark
USPS: Computer Science Dept., University of Maryland, College Park, MD 20742