Dear all,
I like to use an old DOS/Clipper application through DOSEMU on a Linux
application server in a hotel. It works, but (as usual with DOS), it causes
a processor load of 100% in certain situations, while just waiting for user
interaction.
That's kind of stupid, as power saving is heavily disturbed by such a
program and other applications loose some responsiveness. I asked the DOSEMU
crowd how to address this problem and got the following answers:
* "nice" the process to address the latter problem (ok, that's obvious), but
the load of "1" is still there.
* Configure dosemu that way the program is suspended if the dosemu window is
iconified, but users are lazy.
* And I learned there's a "tamedos" DOS application which works a little
(tears down CPU usage to 50%), but that's not enough in my view.
All that is not really great, I think. My question now is: Is there already
a way to advise the linux scheduler to limit CPU usage of certain
processes? Or do I have to develop such a thing myself?
Any better ideas?
Kind regards
Jan
On Jun 21 2007 19:50, Jan Kandziora wrote:
>
>Dear all,
>
>I like to use an old DOS/Clipper application through DOSEMU on a Linux
>application server in a hotel. It works, but (as usual with DOS), it causes
>a processor load of 100% in certain situations, while just waiting for user
>interaction.
That's how it is. When DOS was written, cpu relaxing like the HLT instruction
was not known yet (or was it?), so everything was (and still is) a busy loop.
(Yes, including today's typical x86 BIOSes. Aw crap!)
Of course there may be hacks that try to figure out if a DOS window is idle,
waiting for user input. (Seems like a new invention in Windows 2000 and up).
Since dosemu and all the emulators are not running a genuine Microsoft DOS /
have source, it should be easy game for them to wait non-busily. Or maybe
busy-waiting is _part_ of the emulation; maybe some DOS driver(s) require it.
Jan
--
Am Donnerstag, 21. Juni 2007 20:26 schrieb Jan Engelhardt:
>
> Of course there may be hacks that try to figure out if a DOS window is
> idle, waiting for user input. (Seems like a new invention in Windows 2000
> and up). Since dosemu and all the emulators are not running a genuine
> Microsoft DOS / have source, it should be easy game for them to wait
> non-busily.
>
Well, the "tamedos" shareware does it that way. It works fairly well, but not
too well. DOSEMU doesn't address this problem besides from the suspending
whenever the dosemu window is iconified.
My idea was *not* to schedule a process for running, even if it is the only
runnable one, if it is marked as a "presumably bad mannered" process and
consumed its previous timeslice to the whole. Instead an idle slice is done.
After a configureable amount of time, the bad mannered process is allowed to
run again.
I know it's a crude idea for everyday Linux processes, but for dosemu driven
applications, which behave badly in a multitasking OS *and* for which source
code isn't available, it may be worth to discuss.
Kind regards
Jan
On Jun 21 2007 21:00, Jan Kandziora wrote:
>I know it's a crude idea for everyday Linux processes, but for
>dosemu driven applications, which behave badly in a multitasking OS
>*and* for which source code isn't available, it may be worth to
>discuss.
Would dosbox do? (it does busy-loops too, but at least, it's got
source)
Jan
--
On Thursday 21 June 2007 22:11, Jan Engelhardt wrote:
> On Jun 21 2007 21:00, Jan Kandziora wrote:
> >I know it's a crude idea for everyday Linux processes, but for
> >dosemu driven applications, which behave badly in a multitasking OS
> >*and* for which source code isn't available, it may be worth to
> >discuss.
>
> Would dosbox do? (it does busy-loops too, but at least, it's got
> source)
>
>
> Jan
Hi.
Try to set $_hogthreshold = (1) in dosemu.conf
This helps a lot for me.
Regards,
Maxim Levitsky
Am Dienstag, 26. Juni 2007 03:44 schrieb Maxim Levitsky:
>
> Hi.
>
> Try to set $_hogthreshold = (1) in dosemu.conf
>
> This helps a lot for me.
>
This "nice"s the dosemu process -- I already use this setting. However, if no
other process is runnable, dosemu will get again all CPU power, which
disturbs power-saving. Thanks for sharing ideas, anyway.
Kind regards
Jan
On Tuesday 26 June 2007 12:48, Jan Kandziora wrote:
> Am Dienstag, 26. Juni 2007 03:44 schrieb Maxim Levitsky:
> > Hi.
> >
> > Try to set $_hogthreshold = (1) in dosemu.conf
> >
> > This helps a lot for me.
>
> This "nice"s the dosemu process -- I already use this setting. However, if
> no other process is runnable, dosemu will get again all CPU power, which
> disturbs power-saving. Thanks for sharing ideas, anyway.
>
> Kind regards
>
> Jan
Hi,
Well, I almost sure that this is not true,
or maybe you are not using dosemu 1.4.0, and other one behaves differently.
Anyway, if I run dosemu 1.4.0 with that setting and stock freedos
command.com the cpu usage is well below 5%, and dosemu task is not reniced
There are even times that I forget that dosemu is running.
Also I don't know why but dosemu 1.4.0 has new sound system that is way better
that 1.2 one, but it is not enabled so you need to set $_sound=(2) to get it,
what is nice is that this one uses SDL ( read alsa) for output, and has OPL3
emulation, so MIDI plays out of box
Regards,
Maxim Levitsky
Am Mittwoch, 27. Juni 2007 15:06 schrieb Maxim Levitsky:
>
> Well, I almost sure that this is not true,
> or maybe you are not using dosemu 1.4.0, and other one behaves differently.
>
> Anyway, if I run dosemu 1.4.0 with that setting and stock freedos
> command.com the cpu usage is well below 5%, and dosemu task is not reniced
> There are even times that I forget that dosemu is running.
>
It's like I wrote in the top post. The problem is not command.com or some
other freedos application, but an old, proprietary clipper DB application,
which, in a lot of situations, doesn't behave nice but loops while waiting
for user interaction.
I tested with dosemu 1.4.0 btw. With dosemu 1.2.x, clipper apps aren't even
working.
> Also I don't know why but dosemu 1.4.0 has new sound system that is way
> better that 1.2 one, but it is not enabled so you need to set $_sound=(2)
> to get it, what is nice is that this one uses SDL ( read alsa) for output,
> and has OPL3 emulation, so MIDI plays out of box
>
Nice, but out of my focus...
Kind regards
Jan