BMW DIS: Ultimate VMware Performance Tuning & Bug Fix Guide
SCO OpenServer and DIS itself are ancient software, designed for ancient, low-performance hardware. By modern standards, it's hopelessly obsolete.
All modern software is optimized to work with drivers. Without them, you can't harness the full power of your hardware — like your video card. Without drivers, performance and stability drop by orders of magnitude, or the software just refuses to run.
SCO OpenServer has a set of built-in drivers for hardware that was current at the time. And DIS is fully optimized to run on that exact hardware. That's why DIS doesn't need many resources. The specs of the Group Tester One tablet are more than enough: a single-core 500 MHz CPU, 20 GB of disk space, 256 MB of RAM, and 10/100 Mbps networking. The IBM T30's specs are already overkill.
At first glance, it might seem that on modern hardware, DIS should simply fly. Especially on an AMD Ryzen Threadripper PRO 3995WX and an NVIDIA RTX A6000.
But SCO OpenServer has no drivers for modern hardware, which means DIS is simply not optimized for it. This significantly reduces overall performance in a virtual machine. The Windows OS and the VMware hypervisor partially compensate for the lack of proper drivers by brute-forcing with raw horsepower.
However, a native DIS installation on a Group Tester One or IBM T30 still provides better performance due to optimization, compared to virtualization, even on more powerful hardware than what's inside the GT1 or T30.
So, is it a lost cause?
It is not. Otherwise, this article wouldn't exist. First, we need to decide how to measure DIS performance. Without objective data, we can't talk about where DIS runs faster: on native hardware or in a VM. Subjective feelings can't be measured, so they are not a valid performance metric.
We'll take the boot time of DIS on the original Group Tester One tablet as our performance benchmark.
Key Stages:
- BIOS boot — 12 seconds
- SCO OpenServer boot — 42 seconds
- DIS launch — 1 minute 16 seconds
Total time for DIS to be ready on a BMW Group Tester One: 2 minutes 10 seconds.
Now we have objective data to compare a native DIS installation against virtualization.
I won't compare the speed of the DIS GUI, button response, or window opening times. It's too hard to gauge performance on short, 1-5 second actions. For objectivity, we need to compare the duration of longer processes. That's the only way to guarantee we're not fooling ourselves with subjective feelings of a performance boost. In reality, there's a direct correlation between speeding up DIS boot and improving its GUI performance. By accelerating the first, we also accelerate the second.
I also won't consider the performance of any low-power devices like laptops, netbooks, portable computers, all-in-ones, or tablets. The Group Tester One tablet was a costly device, around $10,000 at launch. My goal isn't to make it cheaper, but to optimize time = money.
My workstation specs (2018):
- OS — Windows 7
- CPU — Intel Core i7-3770K
- RAM — DDR3 1600 32Gb
- SSD — Samsung 860 Pro 1024 GB
- Hypervisor — VMware Workstation 15 Pro
To start the DIS virtual machine, you first need to boot the physical host, which takes time — unlike a native DIS installation. These are many additional intermediate stages, and optimizing them also reduces the total time for DIS to be ready in the VM.
Intermediate Stages
- Physical host BIOS boot
- Windows 7 boot
- VMware hypervisor load
- DIS virtual machine startup
Main Stages:
- SCO OpenServer boot
- DIS boot
CPU Impact on DIS Performance
I conducted numerous tests with different CPUs and VM configurations. I concluded that there is no dependence of DIS performance on VMware Workstation configuration. In all cases, the boot speed remained the same. You cannot improve performance using VMware's built-in virtualization tools without using a more powerful CPU.
DIS does not use parallel computing. Therefore, allocating more cores, threads, or switching virtualization engines gives zero performance gain. However, tests showed a dependency of DIS boot speed on single-threaded CPU performance. Simply put: the more GHz, the better. More technically: architecture, bit depth, cache size, etc.
RAM Impact on DIS Performance
SCO Openserver 5.0.7 supports up to 4 GB of RAM, but DIS only uses 256 MB. You can't force DIS to use more RAM because it's optimized for the specific amount installed in the Group Tester One tablet.
Tests showed that allocating more than 256 MB of RAM to the VM does not speed up but actually slows down the DIS boot, due to increased memory check time by SCO Openserver.
There is also no performance gain from using faster RAM.
Storage Speed Impact on Performance
I ran hundreds of tests on various storage devices, from the slowest HDDs to RAM disks.
The results show that for optimal performance, an SSD with a Sata 3.0 / PCIe / NVMe interface is sufficient. The IOPS rating of the drive is far more important. Tests using a RAMDisk are not very objective because the bottleneck will still be the bus speed during the data copy phase from non-volatile storage to RAM. But if you never turn off the physical host, you could use a RAMDisk. Therefore, I'll take the results from a Sata 3.0 SSD as the best practical benchmark.
The main boot stage, utilizing my workstation's full performance, was reduced by 85 seconds.
The intermediate stages take me 20 seconds.
Total time for DIS to be ready: 70 seconds. That's 46% faster than the Group Tester One tablet.
We can confidently state that virtualization has defeated the native DIS installation in an objective comparison. Of course, the DIS GUI also works lightning-fast during any operation, but subjective feelings can't be measured. I can only demonstrate the GUI speed using DISLauncher.
Can we achieve even more performance?
Tests also showed that VMware Workstation 6 loads SCO OpenServer 2 seconds faster, but launching DIS takes 2 seconds longer than in VMware Workstation 15. In the end, this negates any difference in boot speed.
In theory, virtualization allows for unlimited DIS performance. But at some point, we hit the ceiling of VMware's capabilities for virtualizing SCO Openserver. After that, using more powerful hardware ceases to have a noticeable impact on DIS boot speed and GUI performance.
DIS does not use multithreading or parallel data reading from storage. In fact, DIS is specifically optimized for slow hard drives and weak CPUs.
DIS is a collection of numerous processes and scripts, all intricately linked. Each subsequent process or script waits for the previous one to finish, and here the developers did something stupid. DIS relies on the execution time of certain scripts. If a script runs faster than the developers anticipated, things start to break. To simplify: DIS has built-in deliberate pauses that significantly slow down the boot process. Attempting to remove these pauses from the scripts immediately breaks DIS.
Using even more powerful hardware reduces DIS boot time by just a couple of seconds, which is incomparable to the cost of such hardware. The performance gain will only be noticeable in synthetic benchmarks — let the overclockers chase those imaginary points. The theoretical minimum DIS boot time is ≈ 40 seconds.
Hypervisors allow for snapshots. You can pause a VM and instantly resume it from the exact state of the snapshot. In this case, the DIS boot time is just 1 second. This negates the entire need for powerful, expensive hardware. It's more logical to focus on reducing the boot time of the physical host (BIOS, Windows, VMware), for which there are drivers for powerful modern hardware and software.
Using the autostart function in DISLauncher, booting DIS from a snapshot, from the moment my workstation is powered on, takes just 21 seconds. That's 84% faster than the Group Tester One tablet.
What about the cursor?
This is the most infamous problem with DIS running under virtualization. Because of it, mouse speed and performance will never be as smooth as in a native DIS installation on a Group Tester One or IBM T30.
SCO OpenServer lacks the necessary mouse drivers for VMware hypervisors. Modern high-performance hardware partially compensates for this issue. But the longer your DIS session, the worse the mouse performance gets. Eventually, DIS simply stops responding to mouse clicks unless you move the cursor sideways. The only cure is to reboot DIS. And so on, again and again.
Unix-like operating systems, in our case SCO OpenServer, use the X-Window system to display the graphical interface. The DIS program is a client that connects to X-Window, which acts as the server. The server handles not only the DIS GUI but also the mouse — cursor position, clicks.
Any X-Window server for the Windows operating system will have the necessary mouse drivers. They will provide mouse performance in the virtual machine identical to a native DIS installation. The server will pass the cursor position and mouse clicks to the client, and the client will process this data as if it came from the VMware virtual machine.
To simplify: you need to replace the built-in X-Window server in SCO OpenServer with any other one that can be installed on the Windows OS, for example, X-Win32.
X-Win32 2012 is the best X-Window server for Windows. It's the only one supporting 8-bit pseudo-color for 32-bit color depth in Windows and is not sensitive to screen resolution differences.
Set your Windows display to 32-bit color and a resolution of 1024x768. Install X-Win32 on the computer from which you will use DIS (it doesn't have to be the same machine hosting the DIS VM). Add Russian fonts to the root directory and configure X-Win32.
Launch X-Win32 and the DIS virtual machine. Wait for the DIS start screen to appear in the VMware window. Press Ctrl+Alt+Print Screen; this will open a SCO OpenServer console window to change the X-Window server IP address.
Enter the IP address of the physical machine from which you will use DIS and press Enter. Then confirm the change of the X-Window server IP address. Wait for the DIS screen to appear in the X-Win32 window.
Fixing the poor mouse performance in DIS is now complete. The cursor smoothness in the virtual machine will now be analogous to a native DIS installation on a Group Tester One tablet or IBM T30.
DIS might fail to connect to the specified IP address.
In that case, before changing the X-Window server IP, execute a PING command in the Windows command prompt to the DIS IP address to verify connectivity from the physical machine to the VM. If there's no ping, check the network configuration of both machines.
Few know this, but DIS must be shut down correctly, similar to the "Shut Down" process in Windows. Turning off DIS via the "Shut Down Guest" command in VMware slowly kills SCO OpenServer over time and reduces DIS stability. To properly shut down DIS, you need to execute the init 0 command in SCO OpenServer and wait for the virtual machine to power off.
The power button on the front of the BMW Group Tester One tablet handles the proper shutdown, and you also have to wait for DIS to finish, just like with virtualization. This is the official SCO OpenServer procedure.
Similarly, a forced shutdown of Windows also breaks the OS over time, eventually leading to the Blue Screen of Death.
Of course, even this process can be automated, thanks to VMware snapshots.
- Launch the virtual machine and wait for the DIS start screen.
- Shut down DIS properly.
- Create a snapshot.
- Configure the VM to revert to this snapshot upon shutdown.
It's better to do this right after a fresh DIS installation on the VM, not after six months when SCO OpenServer is already half-dead.
Now, regardless of how DIS was closed — even by killing the VMware process via Windows Task Manager — the VM will always revert to the snapshot with a pristine DIS. This provides reliability and stability unattainable on a Group Tester One tablet, where any unexpected shutdown (e.g., due to a dead battery) also slowly kills SCO OpenServer.
However, I recommend a slightly different approach. After all, this article is about optimization and speed. Resuming DIS from a paused VM takes just one second. Therefore, you can create a snapshot of the VM while it's "paused". And after every VM shutdown, DIS will always start from the paused snapshot in just one second.
- Launch the VM and wait for the DIS start screen.
- Pause the virtual machine.
- Create a snapshot.
- Start the VM and immediately shut it down.
- Configure the VM to revert to the snapshot upon shutdown.
Now DIS will always start instantly, regardless of the shutdown method. This should also be done right after a fresh DIS installation.
These are essentially all possible optimizations, bug fixes, and speed-ups for DIS running on a virtual machine. Now, the speed of working in DIS is limited only by the performance of your diagnostic interface (EDIC, OPS, OPPS, ADS, OBD).
Price for .iso images with author's modifications - $125
Included:
- .iso image of Base version 52
- .iso image of Programs version 57 in English
Price for a VMware Workstation 16 PRO license key - $10
Price for the StarNet X-Win32 2012 license - $10
I didn't understand any of that 🤪
Then pack your equipment and mail it to me. Pick it up in a week, fully configured. I don't work via remote desktop.