I'm running my BBS in Linux and was initially using dosemu 1.4 for DOS doors, but I got dosemu2 working, which enabled TradeWars 2002 to run (TradeWars 2002 doesn't work with dosemu 1.x). However, I've now noticed that some other doors that were working okay with dosemu 1.4 now are using 100% CPU with dosemu2 and are running/responding very slowly. Some of those are doors I really wanted to work well on my BBS.

With Windows, there was a program I had used called Tame, which would do something to reduce CPU usage of a running process and make it more responsive when running in NTVDM in Windows. I doubt Tame would work with dosemu though. I'm wondering if there is a process-taming program for DOS programs running in dosemu, or if there are any dosemu2 settings that might help a DOS program run better and respond quicker?

I'm wondering if the issue in such DOS programs might be some kind of loop it's running that's taking a lot of CPU time.

Nightfox
--- SBBSecho 3.15-Linux
* Origin: Digital Distortion: digdist.synchro.net (21:1/137)

(TradeWars 2002 doesn't work with dosemu 1.x). However, I've now
noticed that some other doors that were working okay with dosemu 1.4 now are using 100% CPU with dosemu2 and are running/responding very slowly.

I also had some issues with dosemu2. One of them was games that had a somewhat roguelike aspect - namely, lord2 and lore. Those games had some substantial issues with movement and sometimes would render incorrect characters on the screen.

I never noticed the cpu thing but I never checked. Now I'm a bit curious myself.

Any chance you can try lore and/or lord2 to see if it presents the same issues I mentioned?

I think nuskooler was using dosemu AND dosemu2 to get the best of both worlds but I could be wrong.

--- Mystic BBS v1.12 A48 2022/07/11 (Linux/64)
* Origin: m O N T E R E Y b B S . c O M (21:4/173)

Re: Re: Taming some high-CPU usage DOS doors in dosemu2
By: esc to Nightfox on Wed Oct 12 2022 05:45 am

I also had some issues with dosemu2. One of them was games that had a somewhat roguelike aspect - namely, lord2 and lore. Those games had some substantial issues with movement and sometimes would render incorrect characters on the screen.

I never noticed the cpu thing but I never checked. Now I'm a bit curious myself.

Any chance you can try lore and/or lord2 to see if it presents the same issues I mentioned?

I just tried a quick test with LORD2 for a minute and it seems fine. No CPU issue or screen rendering issue that I can tell.

I think nuskooler was using dosemu AND dosemu2 to get the best of both worlds but I could be wrong.

I've thought of trying to rig up something to use both dosemu and dosemu2, depending on which door is being started. I have the dosemu2 package installed, so I might have to download & compile dosemu from source and have it in a different directory for that to work.

Nightfox
--- SBBSecho 3.15-Linux
* Origin: Digital Distortion: digdist.synchro.net (21:1/137)

Nightfox wrote to All <=-

With Windows, there was a program I had used called Tame, which would
do something to reduce CPU usage of a running process and make it more responsive when running in NTVDM in Windows. I doubt Tame would work
with dosemu though. I'm wondering if there is a process-taming program for DOS programs running in dosemu, or if there are any dosemu2
settings that might help a DOS program run better and respond quicker?

Sorry to be so late in responding to this, but I've been off the BBS
awhile.

For doors running slowly, I would try loading a DOS FOSSIL driver and
configure them to use it. Mines of Gorr - I had issues with it being
slow, but the "solution" I came up with is too ugly to share.

To "tame" the CPU usage I used linux cgroup. I set up a group for each
node, and then run the door in the cgroup which limits the CPU to about 20-30%. I haven't tried dosemu2 yet, everything seems good with dosemu.

The virtual hosting gives me 2 cores, so even with 6 nodes running
dos doors, there's still some CPU left to spare. ;)

It worked great for Red-Green BBS, until I updated to the very latest
ubuntu. The kernel switch to cgroup v2, with a completely different
layout, and the utilities haven't been ported over to it yet.

That's still on my list of things to fix.

I tried some other programs to limit the CPU, but they ended up making
the doors really choppy.

Take care,
bugz

... You take the blonde, I'll take the one in the turban.
=== MultiMail/Linux v0.52
--- SBBSecho 3.14-Linux
* Origin: Red-Green BBS - bbs.red-green.com (0:0/0)

Re: Re: Taming some high-CPU usage DOS doors in dosemu2
By: Bugz to Nightfox on Wed Oct 12 2022 09:16 pm

For doors running slowly, I would try loading a DOS FOSSIL driver and configure them to use it. Mines of Gorr - I had issues with it being
slow, but the "solution" I came up with is too ugly to share.

At least one of the slow doors is already configured to use a FOSSIL driver. The BBS software I use (Synchronet) has a built-in FOSSIL driver, and I'm using the door's command-line parameter to tell it to use a FOSSIL driver.

To "tame" the CPU usage I used linux cgroup. I set up a group for each node, and then run the door in the cgroup which limits the CPU to about 20-30%. I haven't tried dosemu2 yet, everything seems good with dosemu.

I might look into that. Thanks.

I really only installed dosemu2 for TradeWars 2002. Other doors seemed to run okay with dosemu. It seems the tradeoff with dosemu2 is other doors don't run as well as with dosemu.. :/

I tried some other programs to limit the CPU, but they ended up making
the doors really choppy.

That's a bummer. :/

Nightfox
--- SBBSecho 3.15-Linux
* Origin: Digital Distortion: digdist.synchro.net (21:1/137)

Re: Taming some high-CPU usage DOS doors in dosemu2
By: Nightfox to All on Tue Oct 11 2022 14:01:36

<CUT>

With Windows, there was a program I had used called Tame, which would do something to reduce CPU usage of a running process
and make it more responsive when running in NTVDM in Windows. I doubt Tame would work with dosemu though. I'm wondering if
there is a process-taming program for DOS programs running in dosemu, or if there are any dosemu2 settings that might help a
DOS program run better and respond quicker?

i don't know if running it "niced" at a lower priority will help. sometimes it does. but i would guess it's just a bad behaving door.

I'm wondering if the issue in such DOS programs might be some kind of loop it's running that's taking a lot of CPU time.

most likely this is the reason

regards
===

Charles Blackburn
The F.B.O BBS 21:1/221 618:250/36
bbs.thefbo.us IPV4/V6
DOVE-Net FSX-Net MicroNET USENET




... Earn cash in your spare time -- blackmail your friends
--- SBBSecho 3.15-Linux
* Origin: The FBO BBS - bbs.thefbo.us (21:1/221)

Re: Re: Taming some high-CPU usage DOS doors in dosemu2
By: Nightfox to Bugz on Wed Oct 12 2022 09:53 pm

Re: Re: Taming some high-CPU usage DOS doors in dosemu2
By: Bugz to Nightfox on Wed Oct 12 2022 09:16 pm

For doors running slowly, I would try loading a DOS FOSSIL driver and configure them to use it. Mines of Gorr - I had issues with it being slow, but the "solution" I came up with is too ugly to share.

At least one of the slow doors is already configured to use a FOSSIL driver. The BBS software I use (Synchronet) has a built-in FOSSIL driver, and I'm using the door's command-line parameter to tell it to use a FOSSIL driver.

Only Synchronet for Windows has the built-in FOSSIL driver. Synchronet for *nix relies on other solutions (e.g. Linux-DOSEMU and X00 or BNU) for FOSSIL support.
--
digital man (rob)

This Is Spinal Tap quote #37:
David St. Hubbins: We are Spinal Tap from the UK - you must be the USA!
Norco, CA WX: 84.2øF, 19.0% humidity, 2 mph E wind, 0.00 inches rain/24hrs
--- SBBSecho 3.15-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (21:1/183)

Re: Re: Taming some high-CPU usage DOS doors in dosemu2
By: Digital Man to Nightfox on Sun Oct 30 2022 03:09 pm

At least one of the slow doors is already configured to use a FOSSIL
driver. The BBS software I use (Synchronet) has a built-in FOSSIL
driver, and I'm using the door's command-line parameter to tell it to
use a FOSSIL driver.

Only Synchronet for Windows has the built-in FOSSIL driver. Synchronet for *nix relies on other solutions (e.g. Linux-DOSEMU and X00 or BNU) for FOSSIL support.

Ah, I had forgotten about that detail. I do remember having to ensure I had a FOSSIL driver for DOSEMU in Linux.

Nightfox
--- SBBSecho 3.15-Linux
* Origin: Digital Distortion: digdist.synchro.net (21:1/137)