WinUAE 1.3.2 - "fastest possible" not at 100% cpu usage?

[rsn8887]

I noticed something that might be a bit strange about winuae 1.3.2.

When I set the speed to "fastest possible but maintain custom chipset timing", the cpu usage is not always at 100%. In older versions (1.2 etc.), I remember having 100% cpu usage all the time on this setting. Now, it seems to hover at 64% on my 1.4 GHz machine. Seems it is not using all the speed available anymore?!?!? Happens both for A1200 config and A500 config.

Noticable e.g. in llamatron. Llamatron used to run super smooth at "fastest possible" setting. Now, while still ok, it is noticably slower than in older UAE.
Still smoother than on stock A500, though

Or is it just my mind playing tricks on me?

[thomas]

Use the "CPU Idle" slider. Either full to the left or full to the right gives you the old behaviour back. For me WinUAE is fastest when the slider is in the center.

Bye,
Thomas

[rsn8887]

Thanks.

However, I don't really think that is it. The cpu idle slider is all the way to the left, which should give all cpu to winuae, shouldn't it? If i crank it to the right, cpu usage counter in UAE drops even lower (UAE becomes slower), if I remember right.

Will check again tonight, though.

[rsn8887]

No, that cpu-idle slider gives fastest speed if all the way to the left, at least for me.

I bet it is the new "custom chipset timing fixes" that were done for latest winuae versions.

Maybe it really is ok this way, since the custom chips take up a different amount time now that they are emulated better?!?! And maybe this makes uae not use all of the host cpu, since it waits more accurately for the custom chips?
It still seems a bit strange to me.

[thomas]

Originally Posted by rsn8887

cpu usage counter in UAE

Erm, you are speaking about the cpu counter besides the floppy LEDs ? This is the 68k CPU usage, not your PC's usage. The faster your PC, the faster the emulated 68k and the lower is the CPU usage displayed. Only programs which constantly loop will give you 100% CPU usage there. It might even give you more than 100%, indicating that your PC is too slow. A value lower than 100% means that every task in the Amiga's multitasking environment gets as much CPU as it needs. This is normal and should make you happy.

If you want to see how much of your PC's CPU is used, you have to watch TaskManager.

[rsn8887]

@thomas
Thanks for the remark, I will now double check again tonight using taskmanager etc.
But if I set the speed to "fastest possible" how can every task in the amiga system get as much as it needs? Since there's no throttle, it should want as much as it can possibly get. Thus, shouldn't the speed of everything (e.g. my games, apps etc.) increase until the counter in uae is constantly at 100%? In other words - since it is fastest possible, the 68k cpu should eat up every cycle it can get from the host cpu? Hmm, maybe I am just confused.

I just found a quote on winuae website Q&A:

WinUAE uses all host CPU power when active
- Fastest possible-mode uses all CPU power by design. Move CPU idle-slider in CPU-tab
couple of steps right until CPU usage is under 30% but don't adjust too much or emulation
performance will suffer.

[thomas]

In a multitasking environment all tasks are waiting most of the time, be it for disk access, playing sound, gfx operation, human input or just an amount of time. While all tasks are waiting, the CPU goes to sleep and waits for the next interrupt to occur. Since the "CPU idle" detection is implemented, WinUAE recognises the sleeping CPU and goes to sleep, too. So the host CPU is not fully loaded.

Also Windows is a multitasking environment, too. So if WinUAE's CPU emulation would eat up all of the hosts's CPU, it would become slow, either. Because although most of the things are done by DMA, sound, gfx and disk operations etc. need some CPU, too. And if WinUAE takes all CPU it would wait forever for the host operating system to display or get the results.

[andreas]

Originally Posted by thomas

Only programs which constantly loop will give you 100% CPU usage there.

This a bit too much generalized IMHO.

Also when you set 'Fastest Possible' you'll get the 100%. Without any success, I was trying to persuade Toni that Fastest Possible in Quickstart A1200 mode is NOT a good idea. Leaving QS settings alone and only changing back to Adjustable between CPU->Chipset and setting it to 4 has brought my PC back to "operable" state again.

[Toni Wilen]

CPU% = amount of host CPU power currently used to emulate everything. (not just CPU). If >100% = more CPU power needed than is available.

Fastest possible is always 100% (all free host cpu power is given to CPU emulation) except if CPU idle is enabled and AmigaOS is running OR there is continuous sound buffer overflow state (=emulation is waiting for sound buffer space)

[andreas]

And it's good that way!
Just with Quickstart, I can't say I'd recommend that ...
If the user wants it, OK. But not by default ...

[Toni Wilen]

Originally Posted by andreas

And it's good that way!
Just with Quickstart, I can't say I'd recommend that ...
If the user wants it, OK. But not by default ...

Yes, enabled by default (maybe you have bad priority settings?).

Other settings can result in too slow CPU (if in AGA-mode for example, better have too fast than too slow)

[rsn8887]

@Toni
Thanks for clearing this up once and for all! In fact, that's how I interpreted the uae percentage reading anyways. So if I only get 64% in fastest possible, I must have problems with sound. This also explains my other post about having scratchy sound sometimes Nevertheless, the sound seems fine now at a buffer of 4 or 5, but stilll no 100% in fastest possible. I will try again tonight, using a super huge sound buffer to see if it increases to 100%. From older uae versions, I always had 100% in fastest possible. But from remembering fiddling with the sound in 1.3.2, I suspect I will still get 64% percent even with large sound buffer and perfect sound. Any idea of another cause of this, especially comparing to 1.2? Or is just and only the sound buffer overflow that can cause this?

Something interesting happened yesterday:
I toyed with it some more, and I found out that the behaviour I was expecting (and might not have experienced due to problems with my sound buffers, I guess) from the fastest possible setting is in fact obtained using custom timing and sliding the slider all the way away from Custom chipset towards "CPU". If I do that in A1200 mode, wb games, especially LLamatron run super silky smooth even with tons of enemies on screen. However, in llamatron sprite flicker appears towards the bottom of the screen. I guess because the custom chips do not get enough host cpu time. I also tested with airtaxi (the game I uploaded couple of days ago). And airtaxi seems to run perfectly smooth without artifacts in this setting. The difference is like day and night. Especially with 3 players or 5 players on screen. The game crawls to a halt on my machine in "fastest possible" mode and 5 players on screen. But it runs silky smooth (much smoother than on real A1200) if I use the above setting!

It just amazes me again how much improvement or slow down one can get out of some games by just playing with all these settings.

[andreas]

Originally Posted by Toni Wilen

Yes, enabled by default (maybe you have bad priority settings?).

Toni,

I see I have to be a bit less confusing ...

If the user wants it, OK. But not by default ...

That was supposed to read:

If the user does want it, he should activate it. But leave that decision to the user and do not force him to have it activated just because he uses quickstart. Thus fastest possible should be OFF by default in Quickstart A1200 configurations, as this is a major CPU and machine hog. So you'd better not "punish" the user for using quickstart by hogging his PC by default. If the user DOES want to give all CPU power to WinUAE, so be it. But then it's because HE wants it.

And no, I do not accept your "buy a faster pc" saying this time
That's because WinUAE has always worked fine with a 1.33 GHz CPU and I do not expect these requirements will change in upward direction (unless MMU becomes reality )