Performance problem with VBox 6.1 on Windows 10 host

[Old-Boy]

I have a performance problem running Ubuntu guests on a Windows 10 host (Windows 7 works properly).
Setup:
I have two (nearly) identical machines:
- Lenovo T430s with an i5-3320M CPU (2 core), 8 resp. 16GB RAM, SSD
- running in high-performance mode, no Hyper-V
- VBox 6.1.18
- all virtual machines are configured with: 1CPU, 2GB RAM, 20GB fixed size storage, VBoxSVGA, 16MB video memory, VT-x, KVM paravirtualization
- Ubuntu Desktop 20.04.2 resp 18.04.2, Guest Additions installed
- Machine A (16GB) uses Windows 10. Machine B (8 GB) uses Windows 7

Using 3 different programs to check performance (calculations only, no GUI/filesystem/networking...):
P1: Python, pystone benchmark
P2: Python, calculating primes (Python 3.8 on Windows & Ubuntu 20.04, Python 3.6 on Ubuntu 18.04)
P3: Perl, calculating primes

All perfomance figures: higher is better

Code: Select all

Environment, P1, P2, P3
Machine A, Host :: 120.000, 30, 36 
Machine B, Host :: 108.000, 25, 38
Machine A, VM:Ubuntu 20.04 :: 64.000, 12, 17    <= slow
Machine A, VM:Ubuntu 18.04 :: 60.000, 9, 18     <= slow
Machine B, VM:Ubuntu 20.04 :: 131.000, 36, 43

It looks like VBox on Windows 10 consistently only delivers about 35-50% of performance.

[fth0]

Are you really sure that no Hyper-V component is running on your Windows 10 host? Please post a zipped VBox.log file of the Ubuntu 20.04 VM.

[Old-Boy]

This is the log from the Ubuntu20.04 VM on Machine A (Windows 10 host).

[fth0]

First of all, Hyper-V is not running on your Windows 10 host, so far, so good. A few random comments:

00:00:04.471710 VirtualBox VM 6.1.22 r144080 win.amd64 (Apr 28 2021 17:23:11) release log
00:00:04.617527 Installed Extension Packs:
00:00:04.617541   Oracle VM VirtualBox Extension Pack (Version: 6.1.18 r142142; VRDE Module: VBoxVRDP)

VirtualBox and the VirtualBox Extension Pack have to be the same version. But this would rather provoke a crash than influence the CPU performance IMO.

In general, I'd suggest to provide 2 vCPUs to the VMs, so that the performance measurements and other simultaneous CPU usages by the guest OS do not interfere with each other (there is no such thing as an idle guest OS ). I know that your CPU only has 2 cores, but you're sharing them with the VM anyway.

Linux guests are supposed to use the VMSVGA graphics controller. Using VBoxSVGA is possible, but not supported.

I'd also suggest to not resume the VM from a saved state, which is like resuming a movie after a short break. You're inheriting everything the VM has done during the previous run this way, and unknown starting conditions aren't ideal for measurements.

Nonetheless, you're sharing the CPU resources with the host OS. Ideally, you would take a CPU with 4 cores and provide 2 vCPUs to a VM, so that the host OS and the guest OS can equally share the 4 CPU cores. You could further investigate the CPU sharing, by letting the measurements run "forever", and investigate using your favorite task manager on the host OS and in the guest OS.

FWIW, in my own measurements all VMs exhibit between 80% and 95% of the host CPU performance.

[Old-Boy]

Thank you for your elaborate response.

First of all, Hyper-V is not running on your Windows 10 host, so far, so good. A few random comments:

00:00:04.471710 VirtualBox VM 6.1.22 r144080 win.amd64 (Apr 28 2021 17:23:11) release log
00:00:04.617527 Installed Extension Packs:
00:00:04.617541   Oracle VM VirtualBox Extension Pack (Version: 6.1.18 r142142; VRDE Module: VBoxVRDP)

VirtualBox and the VirtualBox Extension Pack have to be the same version. But this would rather provoke a crash than influence the CPU performance IMO.

Upgrading VirtualBox Extension Pack to 6.1.22 doesn't change anything.

Linux guests are supposed to use the VMSVGA graphics controller. Using VBoxSVGA is possible, but not supported.

Using VMSVGA doesn't change anything.

I'd also suggest to not resume the VM from a saved state, which is like resuming a movie after a short break. You're inheriting everything the VM has done during the previous run this way, and unknown starting conditions aren't ideal for measurements.

For benchmarking I always do a cold start (from the power-off state).

In general, I'd suggest to provide 2 vCPUs to the VMs, so that the performance measurements and other simultaneous CPU usages by the guest OS do not interfere with each other (there is no such thing as an idle guest OS ). I know that your CPU only has 2 cores, but you're sharing them with the VM anyway.

Nonetheless, you're sharing the CPU resources with the host OS. Ideally, you would take a CPU with 4 cores and provide 2 vCPUs to a VM, so that the host OS and the guest OS can equally share the 4 CPU cores. You could further investigate the CPU sharing, by letting the measurements run "forever", and investigate using your favorite task manager on the host OS and in the guest OS.

FWIW, in my own measurements all VMs exhibit between 80% and 95% of the host CPU performance.

This doesn't answer the question: why is VBox on a Windows10 host so much slower than on a Windows7 host.

Any other ideas?

[scottgus1]

One thing that has been advised by the forum gurus is to not trust benchmarks run inside a VM. The timers are virtual so not reliable.

Get a stopwatch-timeable process, like transcoding a video, to run in the VM on each host (best to have it be the same VM copied, so no VM OS differences can influence the result). Run each transcode and take note of the stopwatch time on each run. See what the differences are.

FWIW to pin it down to the host OS when the hosts are two different PCs, though nearly identical but with different memory, could be too much a logical jump. Having the ability to run this test on the same physical hardware would produce a more reliable test. Another host drive (SSD preferred) with a dual-boot 7 & 10 and the same VM for both OSs would be the ultimate test.

FWIW2 Virtualbox 6.1 is no longer supported on Windows 7. Though it may still work.

[scottgus1]

One other thing:

For benchmarking I always do a cold start (from the power-off state).

When you're highlighting a problem with the VM doing a certain thing, you'll want the posted log to be while the VM is doing that certain thing.
Your log clearly shows the VM starting from saved state, not cold boot:

00:00:04.618432 Console: Machine state changed to 'Restoring'

[Old-Boy]

One thing that has been advised by the forum gurus is to not trust benchmarks run inside a VM. The timers are virtual so not reliable.

Get a stopwatch-timeable process, like transcoding a video, to run in the VM on each host (best to have it be the same VM copied, so no VM OS differences can influence the result). Run each transcode and take note of the stopwatch time on each run. See what the differences are.

My benchmark programs usually run at least 30 sec and use both
- process time (systen + user) as well as
- wallclock time
Both times are within 5% and match the elapsed time according to my wristwatch.

FWIW to pin it down to the host OS when the hosts are two different PCs, though nearly identical but with different memory, could be too much a logical jump. Having the ability to run this test on the same physical hardware would produce a more reliable test. Another host drive (SSD preferred) with a dual-boot 7 & 10 and the same VM for both OSs would be the ultimate test.

FWIW2 Virtualbox 6.1 is no longer supported on Windows 7. Though it may still work.

I was using Virtualbox (multiple versions) during the last 6 years on Windows7 hosts and Ubuntu guests (14.04 upto 20.04) and always had pretty
consistent performance between host and guests.

[scottgus1]

Interesting. Though I would point out a couple things:

My benchmark programs ... elapsed time according to my wristwatch

One thing that has been advised by the forum gurus is to not trust benchmarks run inside a VM.

Get a stopwatch-timeable process, like transcoding a video, to run in the VM on each host

Further:

I was using Virtualbox (multiple versions) during the last 6 years on Windows7 hosts and Ubuntu guests (14.04 upto 20.04) and always had pretty consistent performance between host and guests.

This is reasonable. You always had the old OS and had good results. Now you're trying the new OS and are having worse results.

My point is that for a good test that truly pins the problem on the host OS and nothing else, run the same not-a-benchmark test on the same hardware with the two different host OS's. This will eliminate possible unknown differences between the two PCs you're testing on now.

Results from such a test may show exactly what you're seeing with the benchmarks. But with a correctly-developed test then we could know for sure. There's too many variables now.

[Old-Boy]

My point is that for a good test that truly pins the problem on the host OS and nothing else, run the same not-a-benchmark test on the same hardware with the two different host OS's. This will eliminate possible unknown differences between the two PCs you're testing on now.
Results from such a test may show exactly what you're seeing with the benchmarks. But with a correctly-developed test then we could know for sure. There's too many variables now.

What do you mean by not-a-benchmark test?

What do you mean by: There's too many variables now.
There's a minor difference between the two LenovoT430s (RAM, SSD model, BIOS version), but both machines (running under Windows 7 resp 10) are very
consistent in there performance. Which differences can you imagine, that could explain a performance drop of 60 %?

[scottgus1]

What do you mean by not-a-benchmark test?

Not using a benchmark program for the test:

like transcoding a video

There's a minor difference between the two LenovoT430s

for a good test that truly pins the problem on the host OS and nothing else, run the same not-a-benchmark test on the same hardware with the two different host OS's. This will eliminate possible unknown differences

[Old-Boy]

What do you mean by not-a-benchmark test?

Not using a benchmark program for the test:

like transcoding a video

There's a minor difference between the two LenovoT430s

for a good test that truly pins the problem on the host OS and nothing else, run the same not-a-benchmark test on the same hardware with the two different host OS's. This will eliminate possible unknown differences

Some of the programs I am using to test the performance:
- written in plain Python 3.x
- single process, single thread
- memory requirements between 20MB and 1 GB (depending on available memory)
- only doing calculations
- no GUI, no file i/o, no networking
- running at least 30 sec
- using process time (system + user), elapsed time and wristwatch time.

If you think there is something wrong with this approach, please specify.

[scottgus1]

Ah, so these are your own progs, not an official 'benchmarker'. I'd reckon that as long as they aren't relying on CPU timers or some such, they could indicate performance well.

[fth0]

In general, I'd suggest to provide 2 vCPUs to the VMs, so that the performance measurements and other simultaneous CPU usages by the guest OS do not interfere with each other (there is no such thing as an idle guest OS ). I know that your CPU only has 2 cores, but you're sharing them with the VM anyway.

Nonetheless, you're sharing the CPU resources with the host OS. Ideally, you would take a CPU with 4 cores and provide 2 vCPUs to a VM, so that the host OS and the guest OS can equally share the 4 CPU cores. You could further investigate the CPU sharing, by letting the measurements run "forever", and investigate using your favorite task manager on the host OS and in the guest OS.

This doesn't answer the question: why is VBox on a Windows10 host so much slower than on a Windows7 host.

It rather gives you hints on what and how to investigate further, the easy way.

Which differences can you imagine, that could explain a performance drop of 60 %?

Windows 7 and Windows 10 are quite different under the hood, and your host CPU with its 2 cores is not really suited to run a modern host OS and guest OS simultaneously. There could be all sorts of interferences, and although/because I know quite a few things about it, I cannot really answer your question. To give you one example topic: CPU caches ...

[Old-Boy]

For those suggesting to increase the number of vCPUS for the VMs:
Increasing the number of vCPUs from 1 to 2 DIDN'T CHANGE ANYTHING, both host and guest results are the same on both Window10 and Windows7 hosts.