ben@epmooch.UUCP (Rev. Ben A. Mesander) (03/24/91)
I'd like to write a program to compute percent CPU usage and store the usage data every so often into a file (I'd like to monitor how certain programs I run, such as UUCP news unbatching, use my system at 4AM and such). I'm aware of interactive tools like perfmon and Xoper, but I don't know of any program that does what I want for the Amiga. Does anyone know of source to an interactive monitor program that I could look at and see how to collect this sort of data? Or could someone point me in the right direction (I have the RKM's)? Or is there a program that already does what I need? I'd like to be able to set the interval used to collect the CPU usage data, although, I suppose a fixed interval would not be useless. -- | ben@epmooch.UUCP (Ben Mesander) | "Cash is more important than | | ben%servalan.UUCP@uokmax.ecn.uoknor.edu | your mother." - Al Shugart, | | !chinet!uokmax!servalan!epmooch!ben | CEO, Seagate Technologies |
jpotter@ucs.adelaide.edu.au (Jonathan Potter) (03/25/91)
The public domain XOper program by Werner Gunther (last ver fish #318) comes with assembly source, and includes a routine to monitor cpu usage.. Jon
bombadil@diku.dk (Kristian Nielsen) (03/26/91)
ben@epmooch.UUCP (Rev. Ben A. Mesander) writes: >I'd like to write a program to compute percent CPU usage and store the >usage data every so often into a file (I'd like to monitor how certain >programs I run, such as UUCP news unbatching, use my system at 4AM and >such). I'm aware of interactive tools like perfmon and Xoper, but I don't >know of any program that does what I want for the Amiga. >Does anyone know of source to an interactive monitor program that I could >look at and see how to collect this sort of data? Or could someone point >me in the right direction (I have the RKM's)? Or is there a program that >already does what I need? >I'd like to be able to set the interval used to collect the CPU usage data, >although, I suppose a fixed interval would not be useless. Xoper, including the full source code (in >100k assembler) is available on the fish series. From a brief look-over it would sem that it hooks into the exec.library Switch() system call. This, however is less than well-documented in the RMK's (probably for a good reason, but still...) BTW, I suspect that Xoper isn't that accurate in its timings... On my GVP 28Mhz 3001 it likes to report that input.device is using about 40% of CPU-time at full load (ray-tracing or similar). I really don't hope that this is the case! (and if it is, how is a stock A500/2000 to run at all??) Any comments on this? Kristian.
ben@epmooch.UUCP (Rev. Ben A. Mesander) (03/26/91)
>In article <1991Mar25.161731.29334@odin.diku.dk> bombadil@diku.dk (Kristian Nielsen) writes: [...] >Xoper, including the full source code (in >100k assembler) is available on >the fish series. From a brief look-over it would sem that it hooks into the >exec.library Switch() system call. This, however is less than >well-documented in the RMK's (probably for a good reason, but still...) I've noticed that Perfmon seems to use a very low priority task to compute such things (priority -100)? >BTW, I suspect that Xoper isn't that accurate in its timings... On my GVP >28Mhz 3001 it likes to report that input.device is using about 40% of >CPU-time at full load (ray-tracing or similar). I really don't hope that >this is the case! (and if it is, how is a stock A500/2000 to run at all??) >Any comments on this? I've noticed that the amount of CPU usage by input.device varies from almost nothing to 40% of the CPU with things such as screen resolution. I'm not sure everything input.device does, but perhaps some non-obvious things are being accounted to it. I'm not sure what... > Kristian. -- | ben@epmooch.UUCP (Ben Mesander) | "Cash is more important than | | ben%servalan.UUCP@uokmax.ecn.uoknor.edu | your mother." - Al Shugart, | | !chinet!uokmax!servalan!epmooch!ben | CEO, Seagate Technologies |
drysdale@cbmvax.commodore.com (Scott Drysdale) (03/26/91)
In article <1991Mar25.161731.29334@odin.diku.dk> bombadil@diku.dk (Kristian Nielsen) writes: >ben@epmooch.UUCP (Rev. Ben A. Mesander) writes: > >>I'd like to write a program to compute percent CPU usage and store the >>usage data every so often into a file (I'd like to monitor how certain >>programs I run, such as UUCP news unbatching, use my system at 4AM and >>such). I'm aware of interactive tools like perfmon and Xoper, but I don't >>know of any program that does what I want for the Amiga. > >>Does anyone know of source to an interactive monitor program that I could >>look at and see how to collect this sort of data? Or could someone point >>me in the right direction (I have the RKM's)? Or is there a program that >>already does what I need? > >>I'd like to be able to set the interval used to collect the CPU usage data, >>although, I suppose a fixed interval would not be useless. the simplest way to find out how much cpu you've got left when doing something is to create a task at the lowest priority and have it just count. another task runs 0 or higher priority off a timer (say 1 second) and snapshots the counter and clears it. this, of course, doesn't narrow things down to which particular task is using all the cpu time. it also doesn't give you a percentage (just raw machine dependent "ticks"). you'll have to find out what the "no cpu used at all" value is on each system you run it on, and use that number and the running values to get percentages. >Xoper, including the full source code (in >100k assembler) is available on >the fish series. From a brief look-over it would sem that it hooks into the >exec.library Switch() system call. This, however is less than >well-documented in the RMK's (probably for a good reason, but still...) doing things like i just described and patching Switch() and keeping track of all tasks would give you what you want. this isn't simple, though, since there aren't any convenient fields in the task structure for you to use for record keeping. >BTW, I suspect that Xoper isn't that accurate in its timings... On my GVP >28Mhz 3001 it likes to report that input.device is using about 40% of >CPU-time at full load (ray-tracing or similar). I really don't hope that >this is the case! (and if it is, how is a stock A500/2000 to run at all??) >Any comments on this? > > Kristian. --Scotty -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Scott Drysdale Software Engineer Commodore Amiga Inc. UUCP {allegra|burdvax|rutgers|ihnp4}!cbmvax!drysdale PHONE - yes. "Have you hugged your hog today?" =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
andy@research.canon.oz.au (Andy Newman) (03/26/91)
In article <1991Mar25.161731.29334@odin.diku.dk> bombadil@diku.dk (Kristian Nielsen) writes: > >BTW, I suspect that Xoper isn't that accurate in its timings... On my GVP >28Mhz 3001 it likes to report that input.device is using about 40% of >CPU-time at full load (ray-tracing or similar). I really don't hope that >this is the case! (and if it is, how is a stock A500/2000 to run at all??) >Any comments on this? > Is that 40% of the total CPU or 40% of the actual CPU usage, Xoper can report both. On my A1000 Xoper reports that input.device is consuming around 15% of the total CPU when no user input events are occuring (keyboard or mouse) and around 30% when I bang on the keyboard or move the mouse. Anyone have an explanation? Is input.device using timers to wake itself up every now and then? -- Andy Newman (andy@research.canon.oz.au) Canon Info. Systems Research Australia "X: 2. An over-sized, over-featured, over-engineered window system developed at MIT and widely used on UNIX systems." from the jargon file.
jesup@cbmvax.commodore.com (Randell Jesup) (03/27/91)
In article <1991Mar26.033402.2720@research.canon.oz.au> andy@research.canon.oz.au (Andy Newman) writes: >On my A1000 Xoper reports that input.device is consuming around 15% of the >total CPU when no user input events are occuring (keyboard or mouse) and around >30% when I bang on the keyboard or move the mouse. Anyone have an explanation? >Is input.device using timers to wake itself up every now and then? Yes: Intuiticks, etc. They pass through the entire chain. 15% seems a bit high, though. Screen blankers, hotkeys, etc may be the reason. -- Randell Jesup, Keeper of AmigaDos, Commodore Engineering. {uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.commodore.com BIX: rjesup Thus spake the Master Ninjei: "To program a million-line operating system is easy, to change a man's temperament is more difficult." (From "The Zen of Programming") ;-)
dave@unislc.uucp (Dave Martin) (04/02/91)
From article <1991Mar25.161731.29334@odin.diku.dk>, by bombadil@diku.dk (Kristian Nielsen): > > BTW, I suspect that Xoper isn't that accurate in its timings... On my GVP > 28Mhz 3001 it likes to report that input.device is using about 40% of > CPU-time at full load (ray-tracing or similar). I really don't hope that > this is the case! (and if it is, how is a stock A500/2000 to run at all??) > Any comments on this? Is it really at full load, as in cpu usage is 100%? If so, then input device is really using that much time, or xoper is lying. If the cpu usage is NOT 100% then the default display in xoper reports what percentage of the usage is used by some task. Example CPU USAGE 12% input.device 40% Of the 12% cpu usage, input.device accounts for 40% of that. You can get xoper to report the actual cpu usage instead of the relative cpu usage for tasks by typing USAGE. P.S. Has anyone had troubles getting xoper to work correctly with its startup script capability? I can't get xoper to live on the workbench screen when I do this, even when I include the commands to explicity place it on the workbench. It insists on using a custom screen. This is with WB2.02 -- VAX Headroom Speaking for myself only... blah blah blahblah blah... Internet: DMARTIN@CC.WEBER.EDU dave@saltlcy-unisys.army.mil uucp: dave@unislc.uucp or use the Path: line. Now was that civilized? No, clearly not. Fun, but in no sense civilized.
navas@cory.Berkeley.EDU (David C. Navas) (04/03/91)
In article <ben.5484@epmooch.UUCP> ben@epmooch.UUCP (Rev. Ben A. Mesander) writes: >I've noticed that the amount of CPU usage by input.device varies from almost >nothing to 40% of the CPU with things such as screen resolution. I'm not >sure everything input.device does, but perhaps some non-obvious things are >being accounted to it. I'm not sure what... If I recall correctly, intuition does a lot of its stuff "under" input.device's task. Personally, I'd stick an input handler with a very *large* priority, and suck up all the input stream before intuition wakes up. Although I don't know if she'd like that very much :) Disclaimer: ain't never written an input handler in my life. Figure it out... David Navas navas@cory.berkeley.edu 2.0 :: "You can't have your cake and eat it too." Also try c186br@holden, c260-ay@ara and c184-ap@torus
jsmoller@jsmami.UUCP (Jesper Steen Moller) (04/04/91)
In article <12388@pasteur.Berkeley.EDU>, David C. Navas writes: > If I recall correctly, intuition does a lot of its stuff "under" > input.device's task. Personally, I'd stick an input handler with a very *large* > priority, and suck up all the input stream before intuition wakes up. Although > I don't know if she'd like that very much :) Hmm, any standard screen-blanker wouldn't (PopCLI or C='s Blanker) They just blank, and there you go - can't unblank... > Disclaimer: ain't never written an input handler in my life. Figure it out... See examples/popcli.c in the SAS/C distribution. It's not hard to figure out. To suck it all, just return 0... > 2.0 :: "You can't have your cake and eat it too." Then consider: 2.0 :: "You can have your cake, but there might be chili in it..." Greets, Jesper -- __ Jesper Steen Moller /// VOICE: +45 31 62 46 45 Maglemosevej 52 __ /// USENET: cbmehq!cbmdeo!jsmoller DK-2920 Charl \\\/// FIDONET: 2:231/84.45 Denmark \XX/
bombadil@diku.dk (Kristian Nielsen) (04/05/91)
bombadil@diku.dk (Kristian Nielsen) writes: >ben@epmooch.UUCP (Rev. Ben A. Mesander) writes: >>I'd like to write a program to compute percent CPU usage and store the >>usage data every so often into a file (I'd like to monitor how certain >>programs I run, such as UUCP news unbatching, use my system at 4AM and >>such). I'm aware of interactive tools like perfmon and Xoper, but I don't >>know of any program that does what I want for the Amiga. >>Does anyone know of source to an interactive monitor program that I could >>look at and see how to collect this sort of data? Or could someone point >>me in the right direction (I have the RKM's)? Or is there a program that >>already does what I need? >>I'd like to be able to set the interval used to collect the CPU usage data, >>although, I suppose a fixed interval would not be useless. >Xoper, including the full source code (in >100k assembler) is available on >the fish series. From a brief look-over it would sem that it hooks into the >exec.library Switch() system call. This, however is less than >well-documented in the RMK's (probably for a good reason, but still...) >BTW, I suspect that Xoper isn't that accurate in its timings... On my GVP >28Mhz 3001 it likes to report that input.device is using about 40% of >CPU-time at full load (ray-tracing or similar). I really don't hope that >this is the case! (and if it is, how is a stock A500/2000 to run at all??) >Any comments on this? Well, I went and checked this out in the easter holiday. Actually, Xoper IS reporting 40% cpu-usage with the CPU 100% busy. However, this is not really a timing figure. What xoper does is for each task in the system to count how many times the Exec Switch() gets called with ExecBase->ThisTask equal to the task. Assuming that Switch() is the function actually doing the context switch (and I'm going only on the name here), this means that xoper is in fact counting the number of times each task calls Wait() (directly or indirectly), or is preempted. So, if the input.device is scheduled as often as my ray-tracer, xoper will report roughly the same figure for both, even though the ray-tracer is using a full timeslice each time while input.device may only be taking a few hundred microseconds. The lesson is not to to take the xoper figure as an actual indication of cpu load. Also, please note that this is NOT a flame of Xoper - I find it a very handy program, even if it isn't able to measure how cpu-intensive a task is - after all, it does so many other things so nicely (I wouldn't trust it never to crash my system, though..) Kristian.