I'm in favour of the cpu.library idea. I think a consistent interface would benefit not only those dockies which already exist, but dockies and other applications in the future.
Question re measuring CPU activity: currently the method used is to run a lowest-priority task that estimates how much of the time it has control of the CPU, right? Surely this calculation would be easier to implement, less invasive and more accurate if built into the idle task itself?
Question re measuring CPU activity: currently the method used is to run a lowest-priority task that estimates how much of the time it has control of the CPU, right?
Yes, and that has 2 major flaws: - It doesn't use the time but an estimation based on a counter which fails completely if I change the CPU speed after it was started and calibrated itsef. - It does something in the idle.task replacement (even "just" updating a counter needs at least an integer unit and load/store unit), which kills DPM and other methods of shutting down unused parts of the CPU.
Quote:
Surely this calculation would be easier to implement, less invasive and more accurate if built into the idle task itself?
Or even better in execsg, which does that already for all tasks CPU usage in percent = (elapsed time - time idle.task was running) * 100 / elapsed time There is just a "little" problem, the code which updates the accumulated running time of the tasks was broken and I only fixed it 2 days ago But it's no problem to add a workaround for idle.task in such a cpu.library.
... the AmigaOS4 idle.task never gets the CPU as long as CPUClock.docky is running, CPUTemp.docky can't switch off (parts of) the CPU when the system is idle and the CPU gets warmer.
Thanks for info! I'll checkout the new CPUTemp file.
... the AmigaOS4 idle.task never gets the CPU as long as CPUClock.docky is running, CPUTemp.docky can't switch off (parts of) the CPU when the system is idle and the CPU gets warmer.
Thanks for info! I'll checkout the new CPUTemp file.
I've uploaded a new version (52.9) of CPUTemp.docky which includes the features of CPUClock.docky/CPUInfo.docky as well.
But maybe someone should draw some nicer graphics for it
And how does your current code monitor CPU usage? I suppose it's a more accurate approach than what CPUClock docky does? Would it be difficult to add the possibility to filter dnetc, so that the CPU usage meter is still usable when you have dnetc running in the background? I've been told that most CPU meter tools on MorphOS do this already.
And how does your current code monitor CPU usage? I suppose it's a more accurate approach than what CPUClock docky does? Would it be difficult to add the possibility to filter dnetc, so that the CPU usage meter is still usable when you have dnetc running in the background? I've been told that most CPU meter tools on MorphOS do this already.
dnetc runs in the idle time, when nothing else runs. Without dnetc running the idle time is spent in exec's idle task. The idle task also uses CPU time, but still we don't want to see 100% CPU usage even when nothing but the idle task runs. Same with dnetc, I know that it's crunching in the idle time of my system, but I want to see the CPU time that my real applications use.
I mean dnetc eats all idle cpu time and so does the CPU docky shows it.
Exec's idle task also eats all idle CPU time, something always runs in the background, the idea of dnetc is that it makes the CPU do something useful in this idle time rather than just busy looping. You don't notice whether the idle CPU time is spent in a simple busyloop or something else like crunching dnetc. This is why it's a good idea if a CPU meter can filter out the dnetc task so that with dnetc running in the idle time I can still see how much CPU time is really used when I start 3 instances of dvplayer or whatever. Filtering out dnetc task should be optional of course, some people might for some reason prefer to look at a constant 100% gauge all the time.
@joerg
I know that your CPUTemp docky uses some exec hooks to power down the CPU during idle time on 750 CPUs, but even on other CPUs where this cannot be done and exec's idle task busyloops in the idle time, most people don't want to look at a constant 100% CPU gauge, but rather to see CPU usage spent outside of idle time.
I second COBRA's request, if thoses dockies wouldn't always show me 100% usage, I would use them. For this to be done, docky should be able to filter out some task(s) (now it's dnetc for COBRA and me, but this could be anything else that works in the bg for someone else). Even if I understand that the true CPU usage is really 100% everytime, it's the purpose of such utilies that installs during idle time, so I'm aware of this fact, instead I would be interested in knowing what CPU usage anything else is taking. If such option would be added I would find an interest in thoses dockies, without they are of no use for me : I have dnetc launched all the time on my A1....
I had a chat with joerg about how he does CPU usage measurement in his CPUTemp docky and with that approach it'd be easy to filter out some tasks so I'll see if I can add this to CPUInfo.docky when I get some time, maybe via a tooltype where the user can specify a task name to filter out.
I second COBRA's request, if thoses dockies wouldn't always show me 100% usage, I would use them. For this to be done, docky should be able to filter out some task(s) (now it's dnetc for COBRA and me, but this could be anything else that works in the bg for someone else). Even if I understand that the true CPU usage is really 100% everytime, it's the purpose of such utilies that installs during idle time, so I'm aware of this fact, instead I would be interested in knowing what CPU usage anything else is taking. If such option would be added I would find an interest in thoses dockies, without they are of no use for me : I have dnetc launched all the time on my A1....
I wont add an option to completely ignore such tasks, but in CPUTemp.docky 52.10 you can add the names of some special tasks like dnetc (since I've never used it I don't know it's task name, you have to add it to the tooltypes) and their CPU usage will be displayed differently to "normal" tasks.
I was thinking of it being only optional of course. I tested CPUTemp.docky 52.10 and added "dnetc crunch #1" to the tasks to ignore and it works! I see that you display a dimmer graph which includes all tasks and a brighter one with tasks filtered out, this is nice. Although the two percentage values I don't really like (I'd prefer to have only the filtered out version displayed) but I can live with it for now :) Thanks!
Just tried out your docky. Quite nice. I have a question about the WARNTEMP option though. I deliberately set it too low in order to test it out. Are you lowering the CPU's internal clock frequency or using some other technique? And what are you throttling it back to? My machine really crawls when that happens, I can see the windows and icons being redrawn!
thank you !! It has already found its way into my amidock Just do you think it would be possible not to draw the two % usage and have a tooltype to choose between something like : DISPLAY_PERCENT=NONE|BOTH|TOTAL|FILTERED
this way someone can choose not to display percentage at all, display both (it's actual display), only the total (what you get without filtering), or only the filtered percentage (i.e. percentage after removing the tasks to filter out).
Just tried out your docky. Quite nice. I have a question about the WARNTEMP option though. I deliberately set it too low in order to test it out. Are you lowering the CPU's internal clock frequency or using some other technique?
Instruction cache throttling. Instead of forwarding one (for example on 750 CPUs, more on some other PowerPC CPUs, for example 3 on e600 cores, don't know if it's 1 or more on the 7451/7455 CPUs) instruction each clock cycle from the intruction cache it's only done every x? cycles.
Quote:
And what are you throttling it back to? My machine really crawls when that happens, I can see the windows and icons being redrawn!
I'm using the maximum possible slowdown, 255, i.e. you have something like a 3.1 MHz CPU when it's active