VOGONS

How many cycles is my PC using when running max

First post, by Chamomile

Rank Newbie
Rank
Newbie

I was wondering if there was an easy way for Dosbox to display how many cycles it's using at any given time when you're running cycles=max? Say, having the top show cycles=currentcycles and updating every half second to reflect how many cycles it's using instead of just displaying the word max or 100%?

The best way I have found to figure out how many cycles max is theoretically using, is by looking at htop (in Linux) or Task Manager (in Windows) and raising the cycles until I'm using 100% CPU then decreasing it until it says 80-90% or so to find the limit. If you have a quad core, this would be finding the amount just below 25% CPU (one core). Someone with an i5-4690k overclocked to 4.4GHz told me they get about 6% CPU usage at 120,000 cycles but 25% at 140,000... another person with an i5-4690 (not overclocked) told me they get around 6-14% CPU at 300,000 cycles and 25% CPU at 400,000 cycles, so I'm guessing Dosbox is usually running at ~140,000 and ~400,000 cycles at max for these two people. Based on this, I guess the highest cycles currently possible when running max on the best performing CPU available might be somewhere around 1,000,000? 😁

There must be an easier way to determine how many cycles max is using at any given time, you would think?

Reply 1 of 9, by chickenpee

Rank Newbie
Rank
Newbie

This won't give you an exact answer, but I figure this out by running Phil's Quake benchmark test at max cycles and then at a few different cycle settings. A little math should get you in the ballpark. My 13-year-old Athlon XP 3000+ gets up to a whopping 130,000 or so.

Reply 3 of 9, by Qbix

Rank DOSBox Author
Rank
DOSBox Author

I tend to log them when debugging problems with the auto cycles code and make graphs. Maybe I should post a few, so it would be clearer what is actually happening
But the actual values are getting less relevant when you reach the really high cycle values (1 mil+), because the game is actually stuck waiting then, as DOS games that need a fast PC are often tied to a system timer with regards to speed. If you set really high cycles, then a lot of the cycles are spend waiting. (which I can read from logs 😀 )

I have experimented with displaying the used cycles in the titlebar, but on certain OSes updating the titlebar is an expensive operation, which would slow dosbox down considerably, but given that the cycles are loosing their value if the game runs at the intended speed (because more cycles can then be added for free as they are idled away by the game) . It is not really an useful metric once the game runs at the intended speed.

Another complexity is that a cycle is an entity that doesn't translate well to a real CPU MHz number and the amount a real CPU can handle depends on the complexity of the instructions used by the game.

Benchmarks like a Quaketest would be a reasonable way to determine a listing between different CPUs, but it doesn't translate to a (100% correct) translatable number for other games.

However, I can tell you that 130K cycles isn't a high number anymore for modern CPUs. 500000 are often reached with ease, so 1+ million might be a reasonable number for the max performing PC.

Water flows down the stream
How to ask questions the smart way!

Reply 4 of 9, by Tertz

Rank Oldbie
Rank
Oldbie
Chamomile wrote:

There must be an easier way to determine how many cycles max is using at any given time, you would think?

http://ykhwong.x-y.net

You may be interested also in
DOSBox 0.74 CPU Benchmark
http://www.dosbox.com/wiki/Performance

Qbix wrote:

I have experimented with displaying the used cycles in the titlebar, but on certain OSes updating the titlebar is an expensive operation

You may extend dosbox's internal command "cycles" to display the number of them near besides just "max". Like:
max [123456 cycles]

Reply 5 of 9, by Qbix

Rank DOSBox Author
Rank
DOSBox Author
Tertz wrote:
Qbix wrote:

I have experimented with displaying the used cycles in the titlebar, but on certain OSes updating the titlebar is an expensive operation

You may extend dosbox's internal command "cycles" to display the number of them near besides just "max". Like:
max [123456 cycles]

Well, as I wrote in the quoted text. It is on certain Operating Systems and expensive (computation wise) operation and slowed dosbox down considerably.

Water flows down the stream
How to ask questions the smart way!

Reply 6 of 9, by Serious Callers Only

Rank Member
Rank
Member

My computer is so slow that i've noticed the funny situation that putting in cycles=max was actually running Tomb Raider 1 'slower' than putting in a large value (70000 in this case). When i say slower, i'm talking about the game internal fps, which was 30 fps with 70000 cycles and between 14 and 21 with 'max', so the inference was that max was less cycles than the forced value, and 70000 was slowing down the frame rate externally not internally.

From this, i can only conclude that auto is the right default setting (for the games you don't need to further tweak) and cycles=max is (almost) always a mistake. You're bound to either undershoot (if you have a bad computer like me, and were hoping 'max' was magical and detected the game needs) or grossly overachieve if you have a beastly computer and the game might react badly. Not to mention it's always a bad default so don't even think of putting cycles=max on the default conf.

I wish the game database mentioned the right cycles setting for each game...

I also agree that having 'cycles' on the shell return what the max calculated value is would be valuable, if only to try to make conf files portable by having a starting point to experiment to replace variable 'max' that work fine 'on this computer' by fixed cycles.

I mean sure, max is better to play the games with stable fps if your computer doesn't have the juice or the game doesn't break; but for actual archiving or moving the games between host computers i prefer fixed values that i know the game runs well on, if the host is fast enough.

Ideally i'd just do cycles=max limit NUMBER_OF_CYCLES_GAME_NEEDS_AT_MOST_DEMANDING or something like that for every game.

Reply 7 of 9, by gdjacobs

Rank l33t++
Rank
l33t++
Qbix wrote:
Tertz wrote:
Qbix wrote:

I have experimented with displaying the used cycles in the titlebar, but on certain OSes updating the titlebar is an expensive operation

You may extend dosbox's internal command "cycles" to display the number of them near besides just "max". Like:
max [123456 cycles]

Well, as I wrote in the quoted text. It is on certain Operating Systems and expensive (computation wise) operation and slowed dosbox down considerably.

Would it work better to track max and avg cycles and update less frequently?

All hail the Great Capacitor Brand Finder

Reply 8 of 9, by James-F

Rank Oldbie
Rank
Oldbie

I agree that this cycle matter is confusing to newcomers so a quick guide in the readme is needed with some '486' and 'Pentium' references.
You typical oblivious "gamer" will want everything at max speed and power on his super-duper overclocked i10 machine, which is not how DOSBox should be set and it should be clearly noted in the manual.

I use "Fixed 40,000" with 5000 cycleup and cycledown settings.
This way I start somewhere between 486 66mHz and a Pentium 100, perfect for most DOS games, and only then I adjust manually with 5000 cycle steps for the quickest change.
Somewhere around 150,000 cycles most heavy games play smoothy as on a hardware Pentium 233MMX machine.
If you ask me, the 'auto' setting does a really bad job even with the advanced settings of it, fixed cycles with manual adjustment is the only correct way to properly operate dosbox cycles, in my opinion.

Moreover, I have directory with several batch files to quickly select cycle setting for various games or cpu types.

`1`config -set "cpu cycles=7800"``

Reply 9 of 9, by Tertz

Rank Oldbie
Rank
Oldbie
Qbix wrote:

It is on certain Operating Systems and expensive (computation wise) operation and slowed dosbox down considerably.

If this would work in Windows only - it's ok. As for "expensive computation wise" - this is made in ykhwong's build without significant loss. You'd need to count numbers only after console command, not always.