greg@xios.XIOS.UUCP (Greg Franks) (04/04/88)
In article <1574@osiris.UUCP> mjr@osiris.UUCP (Marcus J. Ranum) writes: > Maybe computers could issue an impressive spine chilling whine when >the load average gets high - I see spoilers, air dams, MIPS-meters, and curb- >feelers as integral parts of the next generation of super-computers. Don't laugh - I remember a (now ancient) Honeywell 66/60 that came with an IBM selectric as a console, and had a little mechanical guage that measured CPU utilization. Back to the future? :-) -- Greg Franks XIOS Systems Corporation, 1600 Carling Avenue, utzoo!dciem!nrcaer!xios!greg Ottawa, Ontario, Canada, K1Z 8R8. (613) 725-5411. "Those who stand in the middle of the road get hit by trucks coming from both directions." Evelyn C. Leeper.
Paul_L_Schauble@cup.portal.com (04/25/88)
All of the Honeywell (Now Honeywell-Bull) machines have percent busy meters
for each processor. We've progressed from mechanical meters to bar graphs.
They can be very useful for OS debugging.
Paulrober@weitek.UUCP (Don Rober) (04/26/88)
The Burroughs A9 and A10 had busy meters on the console. A bar graph on the
25th line conatined up to 20 'R's (meaning 'running', 5%/R).
It was done by using the idle instruction to send a message to the maintenance
processor at a fixed rate. The maintenance processor integrated the messages
over time, and subtracted from 1 to get the busy rate.
A crude measure, but no cost and it was sometimes useful.
--
----------------------------------------------------------------------------
Don Rober UUCP: {pyramid, cae780}!weitek!rober
Weitek Corporation 1060 East Arques Sunnyvale, CA 94086earl@mips.COM (Earl Killian) (04/27/88)
My favorite cpu meter was on the MIT AI Lab PDP-10 in the mid 70's.
AI had about 20 bitmap screens connected to it, and could memory map
the frame buffers. The operating system (ITS) would execute a SETOM
to your frame buffer (store -1) when it began running one of your
processes, and a SETZM (store 0) when it stopped. Thus your display
had a 36-pixel bar in the corner that flashed on and off, showing when
you were getting cpu cycles. The best 2-instruction performance monitor
I ever saw.
--
UUCP: {ames,decwrl,prls,pyramid}!mips!earl
USPS: MIPS Computer Systems, 930 Arques Ave, Sunnyvale CA, 94086malcolm@spar.SPAR.SLB.COM (Malcolm Slaney) (04/28/88)
In article <2087@gumby.mips.COM> earl@mips.COM (Earl Killian) writes: > My favorite cpu meter was on the MIT AI Lab PDP-10 in the mid 70's. > AI had about 20 bitmap screens connected to it, and could memory map > the frame buffers. Thus your display had a 36-pixel bar in the corner > that flashed on and off, showing when > you were getting cpu cycles. Oh, that's where Symbolics got the idea!!! Symbolics machines (and I believe TI LispM's) do the same thing even today. For my money I still prefer the SunView approach. I like a pointer that quickly shows the average load. It is just too hard to quantify the load with load bars. (I've also used the bar graph (load average vs. time) approach but I don't think it is as responsive.) On the other hand the LispM's also show bars for Garbage Collection and paging time so it is easier to judge how much time your process is not getting because of system overhead. Malcolm P.S. We could also talk about the (switching) power supply on my Sun that whines when the CPU gets busy.....
schwartz@gondor.cs.psu.edu (Scott Schwartz) (04/28/88)
In article <359@spar.SPAR.SLB.COM> malcolm@spar.slb.com (Malcolm Slaney) writes: > For my money I still >prefer the SunView approach. I like a pointer that quickly shows >the average load. It is just too hard to quantify the load with load >bars. I like Sun's perfmeters too. For the totally minimal approach, consider the new IBM RT's, which have a pair of 7-segment LED's on the front panel that indicate the load average. >P.S. We could also talk about the (switching) power supply on my Sun >that whines when the CPU gets busy..... Yeah, X windows really makes it scream. Could be a good heuristic for the quality of a window system: if it makes your cpu's circuit boards vibrate, it might be too expensive :-) :-) -- Scott Schwartz schwartz@gondor.cs.psu.edu schwartz@psuvaxg.bitnet
rpw3@amdcad.AMD.COM (Rob Warnock) (04/28/88)
In article <2087@gumby.mips.COM> earl@mips.COM (Earl Killian) writes: +--------------- | My favorite cpu meter was on the MIT AI Lab PDP-10 in the mid 70's. | AI had about 20 bitmap screens... (ITS) would execute a SETOM [SETZM] | when it began [stopped] running one of your processes,...[to] a 36-pixel | bar in the corner... showing when you were getting cpu cycles. +--------------- Ah yez... PDP-10's. Well, PDP-10's also had the ability to display in real time the contents of any memory location if you set the front panel switches, though normally that was location 0 (= reg. 0), where an idle counter ran. I added a 3-4 line hack to the scheduler to stuff "Bit0 >> job_no_being_run" (note: BigEndian, bit 0's on the left) into a location, and set the front panel to display that. As long as there were less than 35 active user jobs, that gave you a light for each job (including 0, the null job). Gave a really good overview of system mix and load, especially since the major daemons (batch, lptspl, etc.) always ended up with the same job numbers at boot time. Rob Warnock Systems Architecture Consultant UUCP: {amdcad,fortune,sun,attmail}!redwood!rpw3 ATTmail: !rpw3 DDD: (415)572-2607 USPS: 627 26th Ave, San Mateo, CA 94403
ralphw@IUS3.IUS.CS.CMU.EDU (Ralph Hyre) (04/28/88)
In article <359@spar.SPAR.SLB.COM> malcolm@spar.slb.com (Malcolm Slaney) writes: >In article <2087@gumby.mips.COM> earl@mips.COM (Earl Killian) writes: >> My favorite cpu meter was on the MIT AI Lab PDP-10 in the mid 70's. >> AI had about 20 bitmap screens connected to it, and could memory map >> the frame buffers. Thus your display had a 36-pixel bar in the corner >> that flashed on and off, showing when... you were getting cpu cycles. > > For my money I still prefer the SunView approach. I like a pointer that >quickly shows the average load. It is just too hard to quantify the load >with load bars. (I've also used the bar graph (load average vs. time) >approach but I don't think it is as responsive.) > >On the other hand the LispM's also show bars for Garbage Collection and >paging time so it is easier to judge how much time your process is not >getting because of system overhead. > As I recall, the KTV system had high-persistence monitors, I could imagine the user seeing the bar on all the time, especially in darkened rooms, which was usually how it was. You really want something that shows your process' share of CPU, not just the 'system' average. With appropriate kernel hooks, you could have a bar graph that moves up or down depending on CPU state. (each tick in user mode (or the user's program) bumps up one, each tick in supervisor mode (~system time), bumps it down by one, you'd be swapping or paging when it stopped blurring up and down :-) [This is a bit tricky in software, since the clock tick handler probably runs in supervisor mode, but it should be straighforward with external hardware.] On a Sun, you could probably use the LED's on the CPU board for something similar. >P.S. We could also talk about the (switching) power supply on my Sun >that whines when the CPU gets busy..... Yeah, I'm waiting for a music program to come across the net.... The FPA tests make the most interesting sounds. -- - Ralph W. Hyre, Jr. Internet: ralphw@ius2.cs.cmu.edu Phone:(412)268-{2847,3275} CMU-{BUGS,DARK} Amateur Packet Radio: N3FGW@W2XO, or c/o W3VC, CMU Radio Club, Pittsburgh, PA
walter@garth.UUCP (Walter Bays) (04/29/88)
I liked the UNIVAC 1108. Its console had a light that indicated CPU busy. Normally, the light would flicker. If the machine was idle the light was off. If it was very busy the light was on continuously. I thought of, but never tried, using a photo light meter to read percent busy. You could estimate I/O busy by laying your hands on the disk drives. (Even back then, UNIVAC had a good software performance monitor, but that's no fun :-) -- ------------------------------------------------------------------------------ Any similarities between my opinions and those of the person who signs my paychecks is purely coincidental. E-Mail route: ...!pyramid!garth!walter USPS: Intergraph APD, 2400 Geng Road, Palo Alto, California 94303 Phone: (415) 852-2384 ------------------------------------------------------------------------------
jay@splut.UUCP (Jay Maynard) (04/30/88)
In article <505@xios.XIOS.UUCP> greg@sdn.UUCP (Greg Franks) writes: >Don't laugh - I remember a (now ancient) Honeywell 66/60 that came with >an IBM selectric as a console, and had a little mechanical guage that >measured CPU utilization. Back to the future? :-) OK...I give up. How did this work? Was it just a meter measuring the duty cycle of the wait signal, or was it something much more deserving to be entered in the annals of computer kloogery? -- Jay Maynard, EMT-P, K5ZC...>splut!< | GEnie: JAYMAYNARD CI$: 71036,1603 uucp: {uunet!nuchat,hoptoad!academ!uhnix1,{ihnp4,bellcore}!tness1}!splut!jay Never ascribe to malice that which can adequately be explained by stupidity. Let's rename it talk.bizarre.Kent.Paul.Dolan.for.President.in.88!
rick@pcrat.UUCP (Rick Richardson) (05/01/88)
In article <4777@cup.portal.com> Paul_L_Schauble@cup.portal.com writes: >All of the Honeywell (Now Honeywell-Bull) machines have percent busy meters >for each processor. We've progressed from mechanical meters to bar graphs. >They can be very useful for OS debugging. Simple methods often provide valuable information. On many occasions I've used what I call a "Real Time Meter" to measure the average amount of time a program spends processing interrupts. A very simple gadget: it consists of a milliamp meter and a (variable) resistor. I simply arrange for any ISR's to turn on any convenient output bit on entry, and turn the bit off on exit. The gadget, being mechanical and all, does the integration for you, and the readout (once calibrated) gives a good picture of how much time is being spent processing interrupts. -- Rick Richardson, President, PC Research, Inc. (201) 542-3734 (voice, nights) OR (201) 834-1378 (voice, days) uunet!pcrat!rick (UUCP) rick%pcrat.uucp@uunet.uu.net (INTERNET)
jlw@lznv.ATT.COM (j.l.wood) (05/02/88)
In article <621@garth.UUCP>, walter@garth.UUCP (Walter Bays) writes: > I liked the UNIVAC 1108. Its console had a light that indicated CPU busy. > Normally, the light would flicker. If the machine was idle the light was > off. If it was very busy the light was on continuously. I thought of, > but never tried, using a photo light meter to read percent busy. Many moons ago, when I worked in a big mainframe shop, I had a boss's, boss's, boss who didn't believe the machine's up-time reports the comp genter guys were giving him. He believed that total machine availability included the hardware, the OS (OS/MVT if you really must know.), the I/O channels - etc., and the application server (IMS - ugh.). So ..... he had someone tape a photo-transistor to the poll led on our local cluster controller. This was in turn hooked to a strip-chart recorder upon which a clerk came in three times a day to record the date and time. Needle on the right - everything ipsy-pipsy - needle on the left - no-polling - wavering line - trouble coming. A real truth meter. Also in ESS-COs ten or so years ago there was an x-y CRT hanging off the address bus of the processor. An experienced frameman could tell at a glance what the switch was doing and if it was in trouble. Joe Wood lznv!jlw