English Amiga Board - CPU usage in Idle Workbench

English Amiga Board (https://eab.abime.net/index.php)

- support.AmigaOS (https://eab.abime.net/forumdisplay.php?f=142)

- - CPU usage in Idle Workbench (https://eab.abime.net/showthread.php?t=108976)

CPU usage in Idle Workbench

Hi Folks :)
I was wondering, why the CPU usage in an idle Workbench is so High.

You see, i was looking at Dopus Cpu usage Gauge and i was wondering why it was changing,
without doing anything :shocked

It was always changing, from 14% to 18 to 38% and then repeat the same loop.

So, i did download PerfMonitor

https://aminet.net/package/util/moni/PerfMonitor

and it showed me that the Input.Device needs a lot of Cpu usage.
Even the wait for the Trackdisk.device needs a few Procent.

But the results are completly different from DOpus. :shocked

The Tool System Idle
https://aminet.net/package/dev/src/SystemIdle10

on the other hand, showed 99-100% free Cpu. ?

Now, i am really confused. Maybe you can help me out ?

1) Is it normal that the Input Device needs that much Cpu ?

2) Are those tests even real ? (Dopus Cpu, PrefMonitor, SystemIdle, ect.)

3) If they are, why are they conflicting each other in the results ?

4) If the Input.device really needs that much Cpu, why dosent multitask (OS friendly) Apps/games suffer.

Hmmm, i dont understand these results :shocked ....; a confused, Torti :spin

It may be that the software that does the measurement itself takes important amount of cpu.
As input.device is the context GUI is normally handled, as long as you need to draw something -- it will take its toll.
In short, this kind of measurement isn't reliable.
But you could see how much is taken by just creating and running some program whose instruction timing is known and measures its own speed, then compare the result with the counted clocks (i dunno if i'm clear here :D).

Sounds Complicated; at least for a baked Smurf like me :p

Those Cpu Monitors report pretty much always the same results.
(dosent matter if real Hardware or Emulated.

68020 or 68060 Cpu ..... dosent make a difference :nuts

Weird :crazy

Quote:

Originally Posted by Torti-the-Smurf (Post 1519124)

So, i did download PerfMonitor

https://aminet.net/package/util/moni/PerfMonitor

and it showed me that the Input.Device needs a lot of Cpu usage.
Even the wait for the Trackdisk.device needs a few Procent.

Only 'ready' tasks use a lot a lot of CPU time. These are tasks that want to run when a timeslice is available.

Tasks that are 'waiting' use almost no CPU time. These tasks don't get any CPU time unless something they are waiting for becomes active.

Quote:

1) Is it normal that the Input Device needs that much Cpu ?

It doesn't. It shows 83% 'waiting' because it has a higher priority and is always waiting for something.

Tally up all the 'waiting' percentages and you will get close to 100%. That doesn't mean the CPU is being used during that time. On the Amiga the CPU doesn't just 'spin its heels' when no tasks need it, it actually goes into an idle state while waiting for the task scheduling (or any other) interrupt. It does this using the 'STOP' instruction, which halts the CPU until an interrupt occurs. This reduces system power consumption because there is no CPU bus activity, and also significantly reduces CPU power consumption on CMOS CPUs.

Quote:

2) Are those tests even real ? (Dopus Cpu, PrefMonitor, SystemIdle, ect.)

I'm betting Dopus isn't 'real' if it shows high CPU usage.

Quote:

3) If they are, why are they conflicting each other in the results ?

Because some are badly implemented?

Quote:

4) If the Input.device really needs that much Cpu, why dosent multitask (OS friendly) Apps/games suffer.

It doesn't is why.

Quote:

Originally Posted by Bruce Abbott (Post 1520809)

On the Amiga the CPU doesn't just 'spin its heels' when no tasks need it, it actually goes into an idle state while waiting for the task scheduling (or any other) interrupt. It does this using the 'STOP' instruction, which halts the CPU until an interrupt occurs.

Do you have any evidence on this? I've never before heard that amiga os doesn't just "waste" idle cycles while waiting for something to do.

Quote:

Originally Posted by hooverphonique (Post 1520819)

I've never before heard that amiga os doesn't just "waste" idle cycles while waiting for something to do.

Just run an emulator with speed set to max : host cpu will not go 100% if emulated cpu doesn't.

If you want more concrete proof, here is idle loop from rom 39.106 (A1200) :

Code:

00f8138e: move.w #$2700,sr

00f81392: movea.l (a0),a3

00f81394: move.l (a3),d0

00f81396: bne.s $f813a8

00f81398: addq.l #1,$118(a6)

00f8139c: bset #7,$124(a6)

00f813a2: stop #$2000

00f813a6: bra.s $f8138e

Note the STOP instruction.

Quote:

Originally Posted by meynaf (Post 1520822)

Just run an emulator with speed set to max : host cpu will not go 100% if emulated cpu doesn't.

If you want more concrete proof, here is idle loop from rom 39.106 (A1200) :

Code:

00f8138e: move.w #$2700,sr

00f81392: movea.l (a0),a3

00f81394: move.l (a3),d0

00f81396: bne.s $f813a8

00f81398: addq.l #1,$118(a6)

00f8139c: bset #7,$124(a6)

00f813a2: stop #$2000

00f813a6: bra.s $f8138e

Note the STOP instruction.

Thanks :)
So the emulator will suspend the native emulator process when emulating the STOP instruction (or something along those lines) - interesting...

Quote:

Originally Posted by hooverphonique (Post 1520826)

So the emulator will suspend the native emulator process when emulating the STOP instruction (or something along those lines) - interesting...

This is linked to the "CPU Idle" setting in Winuae properties pages. I don't know how it works exactly, it is possible this has no effect if "Fastest possible" isn't ticked.

The interesting thing about this is that it took the Windows NT branch until the early 2000s (?) to add such a simple feature.

Really interestig stuff. Thanks for all the feedback so far :great

In general CPU usage should be very low, unless you have some 'devils' running in the background that do something, even if you don't see it.
It could be a busy signal from one of the devices that causes problems..

http://eab.abime.net/attachment.php?...1&d=1640357702

PS: The DOpus5 CPU meter is a simple approach to the problem, that does not do justice most of the time untill there is some real load. Use something more dedicated if you really wish to see how cpu usage varies.
Like above, small spikes are windows moved.