VOGONS

Common searches


DOSBOX eating up CPU

Topic actions

  • This topic is locked. You cannot reply or edit posts.

First post, by stecdose

User metadata
Rank Newbie
Rank
Newbie

Hi,

when I start DOSBOX one of my two cores goes up to 100% usage by dosbox. When I start dosidle in dosbox, this goes down to 80%. On 100% the fan in my laptop starts to make loud noise. On 80% it is much better.

Is there a way to reduce this even further? Why isn't idle-handling not yet in dosbox, when almost every os since mid 90s uses HLT to save power?

//edit: a KVM / VTx backend for dosbox would be awesome.

Reply 1 of 13, by DosFreak

User metadata
Rank l33t++
Rank
l33t++

That's not normal behavior:
Post specs
Use the official ver of DOSBox
Post your dosbox.conf
Are you running a game in DOSBox? If so name it.

KVM/VTx would not be awesome for DOSBox. Use dosemu2,vmware,QEMU/KVM if that's what you want.

DOSBox Compilation Guides
DosBox Feature Request Thread
PC Game Compatibility List
How To Ask Questions The Smart Way
Running DRM games offline

Reply 2 of 13, by stecdose

User metadata
Rank Newbie
Rank
Newbie

Okay, specs are:

OS: Linux (debian, gentoo, both the same)
System: i5 520m, 2.40GHz, 4GB RAM
DOSBOX: 0.74, 0.74-2, SVN

I always have used official version of dosbox. This behaviour is everytime, no program but command shell loaded. See the attached dosbox.conf autoexec section. A few mounts, keyboard, done.

It is difficult to catch dosbox with top with screenshot tool. The moment the screenshot is taken, dosbox is already somewhere else in list.
It jumps always between 88% and 100%, sometimes I see 90%, 95%, 100%, but never goes below 88% and most of the time it is near 100%.

I am using a stock dosbox.conf that comes with distro-packages. Just have edited autoexec-section to my needs.

Booting a whole VM like qemu is a waste of time. I usually use dosbox for cross-development on my linux-box. This way I can really easy test:
Makefile contains a "make test" target. This target starts dosbox and the program I am currently working on. This goes within max. 2 seconds.
Does dosemu2 take advantage of KVM/VTx?

Okay, I havent thought to the end. Havin dosbox with KVM will result in a way too fast system. But slowing it down again with "NOPs" would bring a huge efficiency benefit compared to emulating a CPU.
While waiting for the cycle-time to be complete the host-system is free for other tasks.

Attachments

  • Filename
    dosbox-SVN.conf
    File size
    10.56 KiB
    Downloads
    26 downloads
    File license
    Fair use/fair dealing exception

Reply 3 of 13, by kjliew

User metadata
Rank Oldbie
Rank
Oldbie

I just tried my DOSBox SVN in Ubuntu 16.04LTS on the aging system with Core2 Q9300/NVIDIA graphics. With "cycles=auto", DOSBox started up with 3000 cycles, and the TOP showed max %CPU at ~10%. Ubuntu System Monitor also showed similar result on CPU history. Different output options (surface, opengl, openglnb) do not make any difference. 3000 cycles is too petty regardless if DOSBox rendering window was in focus for any CPU/GPU from the past 10 years.

With "cycles=max 105%, DOSBox would eat CPU when the rendering window was in focus. TOP/System Monitor showed %CPU at ~97%. If the rendering window was not in focus, then DOSBox consumed ~50% CPU. The system remained responsive even if DOSBox at ~97% CPU since it only used 1 core. The 3 remaining cores were at <10% CPU.

Reply 4 of 13, by krcroft

User metadata
Rank Oldbie
Rank
Oldbie

That sounds normal to me. When you set "100%", you're telling DOSBox to emulate as many dos-cycles/s as possible given the limits of your host cpu. On the other hand, setting DOSBox to emulate 3000 cycles/s is pretty easy for a modern host cpu (in this case, DOSBox needs about 100 MHz on a modern cpu, so you might notice that your cpu is clocked down to its lowest speed as well).

When it comes to host cpu usage, I think emulating cpu "noop" cycles (or idling) in DOSBox is no different than emulating any other instruction. Like revving a car engine to 8,000 RPM; the engine does the same work regardless if you drive from A to B or if it's stationary on a dynamo.

I'm not sure if it's possible or elegant in DOSBox to detect and short circuit cpu "idle" states and replace them with an OS busy/wait call, like select() on Linux, without negatively impacting proper emulation of hardware peripherals like the sound card or video card, which are cuurently emulated serially in the same thread.
(maybe possible if each peripheral were emulated in a separate thread? interesting topic though!)

Reply 6 of 13, by stecdose

User metadata
Rank Newbie
Rank
Newbie

I have cycles=auto. When I try to change cycles it does not affect cpu usage by more than 5%. Even if I go down to 100 cycles, where norton commander takes a couple of seconds to start.

I'm afraid this almost 9 nine year old mobile i5 is a very weak performer... (i5 520m).

Reply 7 of 13, by DosFreak

User metadata
Rank l33t++
Rank
l33t++

No something else is going on. If you use DOSBox from a liveCD to you have the same issue?

DOSBox Compilation Guides
DosBox Feature Request Thread
PC Game Compatibility List
How To Ask Questions The Smart Way
Running DRM games offline

Reply 9 of 13, by kjliew

User metadata
Rank Oldbie
Rank
Oldbie
stecdose wrote:

I'm afraid this almost 9 nine year old mobile i5 is a very weak performer... (i5 520m).

That is still much more powerful than AMD mobile C60, and as I said 3000 cycles is petty on any CPU/GPU for the past 10 years. ASUS EeePC 900MHz can also handle 3000 cycles with less than 30% CPU on Windows XP, and that's with the crappy i910 Intel Graphics.

I think you need to check your SDL or the display driver aspects on your Linux distro. The only reason that I can think of that the CPU/GPU cannot handle 3000 cycles is due to an un-accelerated display issue.

Have you tried different output options in the conf file? In your attached conf file, you have "output=opengl". You should check out "output=surface". Perhaps your setup has issues with OpenGL acceleration, and it was using software rendering.

Reply 10 of 13, by stecdose

User metadata
Rank Newbie
Rank
Newbie

I tried a few settings now.

frameskip=1 does not change anything, same as frameskip=5 does not change anything.

changed to surface, also tried openglnb and overlay. No change in CPU usage. I ran glxgears for testing opengl capability, this goes well. It runs 60fps.

Also I played around with cpu core and cputype (auto, dynamic, normal, simple, 386, 386_slow).

Just tried dosemu 1.4.1 which is in my distro's repos, this takes 3% cpu when idling with a command shell.

Reply 11 of 13, by digger

User metadata
Rank Member
Rank
Member
DosFreak wrote on 2018-11-06, 14:19:

KVM/VTx would not be awesome for DOSBox.

Can you or someone else please elaborate on that? How could emulating a CPU in software ever be faster or more efficient than running the code natively, having to emulate only the I/O stuff (graphics, sound) instead? Yes, I am aware that eventually in a post-x86 world this will cease to be a viable option anyway, but for the time being, why not take advantage of the fact that most of the game's instructions can be executed on the host CPU natively?

DOSBox is often praised for offering better DOS game performance than hypervisors, but the only reason for that is superior graphics and sound emulation, not the fact that is is emulating an entire CPU for the game to run on.

Reply 12 of 13, by leileilol

User metadata
Rank l33t++
Rank
l33t++

By virtualizing, you introduce more variables into incompatibility as those supported modern CPUs passed through with unpredictable results with old 16-bit stuff as well as far less cycles control... and DOSBox's dynarec is fast enough to never need any use case for a virtualizer by that point since your CPU's quite new enough to handle the most demanding DOS games in emulation anyway.

apsosig.png