wagner@utcs.UUCP (12/02/86)
I've heard it said on the net that, when idling, an Amiga is using about 17% of the CPU (at least in my case, the numbers seem worse, but that's another problem). I've also heard it said that this is the price for multi-tasking. The more I think about this, the less likely it seems. People have often criticized large mainframe operating systems like MVS for using up 3 or 4 % when idling. In MVS's case, there is a small amount of timer-interrupt driven performance monitoring going on all the time. In the case of the Amiga, some work is being done every vertical retrace time, to set up the copper. But 17%? ... So I did some simple experiments. It happens even for simple screens. It happens even at the very beginning of boot (well, once one can ^D out of the boot process). It decreases if you take out one of the disks, and, on close examination, the clicks correspond to times when the CPU load *goes down*!.?! Does this mean that some disk-related software is polling? Whatever for? The disks are nice, interrupt-driven things, aren't they? I have a simple performance monitor tool that I got from someone in the Toronto area. It produces a bar-chart sort of display of CPU and memory use (its real handy, as far as it goes). (It's Icon is a cute little rabbit, but, once again, that's another story). What I'd really like now is a tool that told me which task/process was using how much of the CPU. Does such a thing exist? The search for answers continues. Michael P.S. The monitor I have deduces CPU busy by putting a subservient, low-priority task into a loop. There are two fields in the EXECBASE structure for counting idle and dispatched time slices. Are they not good enough, somehow?
mwm@eris.BERKELEY.EDU (Mike (Don't have strength to leave) Meyer) (12/03/86)
In article <1986Dec2.102542.4658@utcs.uucp> wagner@utcs.uucp (Michael Wagner) writes: > >I've heard it said on the net that, when idling, an Amiga is using about 17% >of the CPU (at least in my case, the numbers seem worse, but that's another >problem). I've also heard it said that this is the price for multi-tasking. > >The more I think about this, the less likely it seems. People have often >criticized large mainframe operating systems like MVS for using up 3 or 4 >% when idling. In MVS's case, there is a small amount of timer-interrupt >driven performance monitoring going on all the time. In the case of the >Amiga, some work is being done every vertical retrace time, to set up the >copper. But 17%? ... One thing to remember - 3 or 4 % of a 3081 or 3090 is a *LOT* more CPU than 17% of an Amiga (or maybe even 100% of an Amiga!). The larger the CPU, the less you expect to spend on system overhead. For instance, 17% for 4.2BSD on a VAX 750 is high, but not outrageous. The same figures on an VAX 8800 are bad enough to call for firing a system manager. For the Amiga, 17% is high enough that someone should explain it, then fix it. The Amiga CPU is about the same as a 750, but the OS is doing a lot less, and so should have correspondingly lower overhead. <mike
daveh@cbmvax.cbm.UUCP (Dave Haynie) (12/10/86)
> Checksum: 37661 > > I have a simple performance monitor tool that I got from someone in the > Toronto area. It produces a bar-chart sort of display of CPU and memory > use (its real handy, as far as it goes). (It's Icon is a cute little > rabbit, but, once again, that's another story). What I'd really like > now is a tool that told me which task/process was using how much of > the CPU. Does such a thing exist? > > The search for answers continues. > > Michael I saw a nice tool up at the World of Commodore show, in Toronto this past weekend, that looks like it would do just such a thing. Its called "System Monitor", from Zen Software (815 East 7th Avenue, Olympia, WA 98501, or on the Well as "zen"). This utility answers questions like "How much RAM is available", "How hard is the 68000 working (globally)", "What is slowing down this program", "What's this task waiting for", "Could this task use more CPU time if available", "How much of the allocated stack space is this task actually using", "What program is a given CLI running", etc. You could give 'em a call at (206) 352-0766. I'm not in any way affiliated with these guys, but even so, they've put together a nice utility, and its not very expensive (somewhere under $60, not sure exactly). -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Dave Haynie {caip,ihnp4,allegra,seismo}!cbmvax!daveh "Laws to supress tend to strengthen what they would prohibit. This is the fine point on which all the legal professions of history have based their job security." -Bene Gesserit Coda These opinions are my own, though for a small fee they may be yours too. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
wagner@utcs.UUCP (12/12/86)
Yes, I saw the Zen Monitor. But it doesn't seem to answer the question about where all the cpu time is going. We tried for a while (me and the author). Alas, more exploration may still be necessary. I'm getting more and more convinced that the problem is in the File systems and the trackdisk.devices. I now have a copy of AMIGAMON20, and by turning it up to very fast, I'm able to see that the trackdisk.devices and the file systems are being dispatched regularly, even when there is no disk activity. Still no clues as to why, however. Michael
jacc@midas.UUCP (Jac Colby) (12/15/86)
In article <1986Dec11.185731.13459@utcs.uucp> wagner@utcs.UUCP (Michael Wagner) writes: >I'm getting more and more convinced that the problem is in the File systems >and the trackdisk.devices. I now have a copy of AMIGAMON20, and by turning >it up to very fast, I'm able to see that the trackdisk.devices and the file >systems are being dispatched regularly, even when there is no disk activity. When I was trying to figure out how to add my own external disks, I noticed that the select lines went active once every second if a disk was not present in a drive. When a disk is placed in a drive, its presence is always detected within one second, and the validator is run. However, the select lines *continue* to be pulsed, and at an even higher rate. I presume that this is done to check for disk removal. The disk-removed signal is active low, so detection of disk removal or insertion must be done by polling. An obvious question, though, is why doesn't the trackdisk.device just check for disk-removed prior to each disk access? I would guess that the overhead would go down if no disks are present when running benchmarks. Jac Colby - they disclaim me around here, too. UUCP: {ucbvax,decvax,pur-ee,cbosg,ihnss}!tektronix!midas!jacc -or- jacc@midas.TEK.COM US: 5529 SW Patton Rd, Portland, OR 97221 (503) 292-1609 -or- MS 94-442, PO Box 4600, Beaverton, OR, 97075 (503) 629-1129
wagner@utcs.UUCP (12/22/86)
In article <926@midas.UUCP> jacc@midas.TEK.COM (Jac Colby) writes: >When I was trying to figure out how to add my own external disks, >I noticed that the select lines went active once every second if a >disk was not present in a drive. When a disk is placed in a >drive, its presence is always detected within one second, and the >validator is run. However, the select lines *continue* to be >pulsed, and at an even higher rate. I presume that this is done >to check for disk removal. The disk-removed signal is active low, >so detection of disk removal or insertion must be done by polling. >An obvious question, though, is why doesn't the trackdisk.device >just check for disk-removed prior to each disk access? A very interesting observation, that sent me scurrying for my manuals. In the RKM (part2), the discussion of the trackdisk.device includes the command TD_REMOVE. This nominates your routine to get control when a disk is removed. I guess you could use this support to put up a requestor and say PUT THAT BACK! or something. Sounds marginally useful. The trackdisk driver promises to check and tell you, in any case, when you go to do I/O. So, you ask, how does it do this? Well, the hardware manual claims there is a signal. However, it doesn't interrupt at the point of removal. Rather, 'the drives that support this signal latch it until the next time the heads are stepped'. Is it perhaps stepping the heads on a regular basis to see if the disk got removed? If so, could it be induced to be a little less eager? Michael
lachac@topaz.RUTGERS.EDU (Gerard Lachac) (12/22/86)
In article <1986Dec21.165050.4430@utcs.uucp> wagner@utcs.UUCP (Michael Wagner) writes: > >command TD_REMOVE. This nominates your routine to get control when a >disk is removed. I guess you could use this support to put up a requestor >and say PUT THAT BACK! or something. Sounds marginally useful. The >trackdisk driver promises to check and tell you, in any case, when you go >to do I/O. I believe Marble Madness does this. I remember trying to figure out how to back the thing up when I first got it. I tried using the "not booting" backup I made by switching disks in the middle of the game. It knew I did that and if I remember properly it either asked me for the REAL Marble Madness or it crashed. This was so long ago and finals do tend to waste one's mind.... -- ---------------------------------------------------------------------------- "Isn't fun the best thing to have?" lachac@topaz.rutgers.edu