MSDOS 6.22 Performance Problem

[jbecker]

We're running MSDOS 6.22 as a guest in order to run a 16 bit application that connects to a Novell IPX netowk. It took some doing but everything works.

Problem is that performance is a fraction of what it is under similar environments and hardware. A straight CPU performance test consistently produces results that are 11% of the same application on the same hardware. Under the current configuration it peaks out at 25% Task Manager (due to 4 processor configuration of Windows 7 VM). But again, results were the same under WIndows 7 32 bit on dedicated hardware.

Issues / attempts:
- Tested in Virtualbox under Windows 7 (32 bit w/ dedicated hardware and 64 bit running under XCP-ng) with same results;
- As expected it runs under one processor;
- Test was configured to minimize or eliminate memory access issues to isolate as CPU issue;
- Changed priority and affinity with no change in results;
- Tried changing various other settings in Virtualbox and WIndows with no change in results.

Any suggestions?

[socratis]

Problem is that performance is a fraction of what it is under similar environments and hardware.

Can you describe in detail the "similar environment and hardware"? Do you have a modern computer that you've managed to install DOS into?

Under the current configuration it peaks out at 25% Task Manager (due to 4 processor configuration of Windows 7 VM).

Exactly right. Which means that your guest is running at 100%, as fast as it can with the single CPU that a DOS VM would support.

Test was configured to minimize or eliminate memory access issues to isolate as CPU issue;

Not sure what the even means...

Changed priority and affinity with no change in results;

You can't change the affinity or the priority of a VirtualBox VM, AFAIK. Plus it's not the best option to try and outsmart the host OS scheduler...

Tried changing various other settings in Virtualbox and WIndows with no change in results.

I'm not sure there's that many options to change in a DOS VM...

Finally,

We're running MSDOS 6.22 as a guest in order to run a 16 bit application that connects to a Novell IPX netowk

Why aren't you running the application natively on your host? Win7 (for sure the 32-bit) has support for running 16-bit apps...

[jbecker]

Basically, this is a heavily customized 16 bit legacy application currently running under XP and Win Svr 2003 command shell. We're trying to find a viable long term environment that will keep it alive as long as necessary. We're also dealing with limited hardware options but most are modern. All workstations require other (Windows) applications for employees to do their jobs so a dedicated DOS machine isn't a viable solution.

With this limited hardware environment our testing is also limited. We have a server running XCP-ng with a Windows 7 (64 bit) VM. Running VBox in that VM works, but the performance is down to about 11%. It's worse in the Win 7 (32) on dedicated hardware.

The CPU test is a BASIC program that repeatedly runs the same statement against memory resident variables. There is no network access during the benchmark and very limited changes to memory in that no variables are created or destroyed. Since it's 16 bit MSDOS it has one thread. This benchmark is the latest in a series of benchmarks used to isolate the performance hit.

Our benchmarks for this test are:
Windows 2003 (on XCP-ng / XenServer) Command Shell: 7 seconds
Windows 7 (64) (same server) running VirtualBox / MSDOS 6.22: 66 seconds
Windows 7 (32) (desktop hardware) running VirtualBox / MSDOS 6.22: 162 seconds
Windows 2003 Command Shell (different hardware no VM): 17 seconds

Note that we had VirtualBox running under Windows 7 with and without XCP-ng and saw a performance hit with both. The DOS VM was exported from the desktop and imported into the server. Both showed similar performance degradation.

All that to say that our focus is on the VirtualBox scheduler as the source of the performance degradation. We're looking into other environments to test their scheduler but we're hoping that we can use VirtualBox since it's the best fit in the work environment.

I hope that answers your questions.

[michaln]

You can ask the people peeking over your shoulder what the problem is. Or you can provide the benchmark program (for lack of a better word) you're using so that someone can have a look.