Network Adapter speed in Windows XP Virtualbox 7.0.97 r156683

[FranceBB]

Hi guys,
I've been fiddling with the network adapter in Virtualbox 7.0.97 r156683 on my Fedora 37 x64, in particular with the Intel PRO 1000 MT Desktop.
Now, here's what I found in terms of speed test:

Host: Fedora Linux 37 x64 kernel 6.1.13
CPU: i7 6700HQ 4c/8th 2.60GHz
RAM: 64GB DDR4 (2x32)
GPU: NVIDIA GTX 950M 4GB GDDR5
SSD: Samsung EVO 1TB Sata III (OS)
SSD: Samsung QVO 1TB Sata III (Data)
SSD: Intel 660p NVME 1TB (Virtual Machines)


Guest: Windows XP Professional x86 (with Microsoft Premier Support Updates 'till July 2019)

Adapter: Intel Pro 1000 MT Desktop
Speed: 150 Mbit/s
Adapter: Virtio
Speed: 110 Mbit/s
Adapter: PCNet Fast III
Speed: 100 Mbit/s

Guest: Windows 8.1 Professional x64 (with Microsoft Premier Support Updates 'till the end of 2023)

Adapter: Intel Pro 1000 MT Deskop
Speed: 890 Mbit/s


Host and native adapter: 960 Mbit/s


Considering that it's a Bridged Network from the host and that I have a 1 Gbit/s connection, taking into account a bit of overhead due to emulation etc, I guess 890 Mbit/s in the virtual environment is a really good result.
What baffles me, though, is the performances of the very same adapter (Intel Pro 1000 MT Desktop) on the Windows XP VM which is much much slower than the 8.1 counterpart.

I'm not complaining, I'm just asking to the Windows XP users in this forum if this is expected and if they have similar results.


Oh, one more thing, obviously Guest Additions are installed.

[FranceBB]

A bit of an update since last time, this time using version 7.0.97 r156983.
I noticed that, when switching to virtio, the default reported connection speed reported was 1 Gbit/s despite the fact that the virtual adapter should support 10 Gbit/s.
I went in the settings and changed the reported speed from 1 Gbit/s to 10 Gbit/s (it's possible to do it from the registry as well, eventually):

Screenshot from 2023-04-23 13-45-42.png (19.02 KiB) Viewed 8319 times

however it always ends up in a bluescreen:

Screenshot from 2023-04-23 13-47-52.png (3.64 KiB) Viewed 8319 times

Zipped logs in attachment:

WindowsEmbedded-2023-04-23-13-47-46.zip

Logs

(21.54 KiB) Downloaded 124 times

Looks like virtio has some problems so I opened a ticket: https://www.virtualbox.org/ticket/21609

[FranceBB]

The virt-io guys suggested me to apply the following settings in the registry on Windows XP:

Code: Select all

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\AFD\Parameters]
"DefaultSendWindow"=dword:00100000
"DefaultReceiveWindow"=dword:00100000
"FastSendDatagramThreshold"=dword:00004000


[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters]
"Tcp1323Opts"=dword:00000001
"TcpWindowSize"=dword:00100000

where
Tcp1323Opts - allows the scaling of the TCP window above 16k.
"DefaultSendWindow", "DefaultReceiveWindow" and "TcpWindowSize" control TCP window size
"FastSendDatagramThreshold" - controls fast UDP transmit.

I did and I rebooted, but it made almost no difference. I went from 150 Mbit/s to 167 Mbit/s top, far below the 1 Gbit/s expected speed...

[mpack]

You need to describe how you are measuring to obtain these results.

Bear in mind that the hardware (virtual or not) is the hardware, regardless of which OS you install. The OS can't and doesn't control the speed of the hardware.

[FranceBB]

I do it in two ways.
The first is by opening chromium 108 on XP (currently the last ESR version available, not publicly, for XP), go to the Google speed test and measure the results.
The second is by setting up an SMB Share and testing the transfer.

I do the same thing with Chromium 108 on Windows 8.1 (also the last version working on it) and the speed test and then I try the same transfer on the same SMB share.

Windows 8.1 is almost as consistent as the host in terms of speed. We're talking about 960 Mbits on the host and 890 Mbits on the guest, as I wrote in my first post.
The problem is that with the very same virtual network adapter, XP has a maximum speed of 160 Mbits, far far slower than the host (Fedora 38) and far far slower than other guests like Windows 8.1.

[mpack]

go to the Google speed test and measure the results.

So you are running a benchmarking tool inside the VM. Never reliable. You need a timing tool that is independent of the thing you are testing: virtual timers are not independent of the virtual environment.

I'm happy with the point I made above: the hardware is the hardware regardless of the OS you install. If your timing tests show differences then either the software inside the OS differs in efficiency, or there is something wrong with your timing methodology.

[fth0]

I've got the general information (from @klaus) that a Windows XP guest should be able to get close to 1 GBit/s, but perhaps needs more than 1 vCPU to achieve that.

If your Windows XP VM already has more than 1 vCPU and if you want to investigate the issue in much more detail, I could provide further ideas about how to do that. Please let me know if you're so inclined.

[mpack]

If your Windows XP VM already has more than 1 vCPU

You need to be careful with that with XP. It has no "plug and play" mechanism to recognize additional CPUs or cores. If XP was originally installed with the single processor HAL (i.e. if XP was installed while the VM only had one core) then it won't matter how many cores you give it later, XP won't use them. You have to change the HAL. See Changing the HAL in an XP VM.

[FranceBB]

go to the Google speed test and measure the results.

So you are running a benchmarking tool inside the VM. Never reliable.

Fair enough, but during the SMB Share test I measured it the other way round as well, so basically the transfer speeds were measured on both the physical storage and the guest VM.
Surprisingly, those two matched.

In other words, the Google Speed Test might be unreliable for a VM, but when the transfer of a file via SMB is between a VM with bridged network and a bare metal storage, the speed reported by the VM matches the transfer speed I can see on the physical bare metal Windows 10 that is running the SMB Share, but of course while on the VM is reported as download ('cause it's retrieving the file from the share), on the physical bare metal instance it's reported as upload ('cause it's serving the file).

Here are the updated data of the last test with the speeds reported by the physical Windows 10 x64 installation:

Fedora 38 x64 (Host) to Windows 10 x64 (Bare Metal): 967 Mbit/s
Windows 8.1 x64 (Guest) to Windows 10 x64 (Bare Metal): 893 Mbit/s
Windows XP x86 (Guest) to Windows 10 x64 (Bare Metal): 165 Mbit/s

All speeds are measured at the Bare Metal side, so they're reliable and not affected by the non standard flow of time inside the VM.
Both Windows 8.1 and Windows XP were using the same virtual adapter, namely the Intel Pro 1000 MT Deskop.
Both VM have the same number of virtual cores (4c/4th) in a 4c/8th guest.
Both VM are set as bridged network and have an IP address in the very same subnet, so much so that tracert to the target (the physical bare metal storage used for the test) shows the same path.
Testing on different bare metal computers and servers show consistent results in which the Windows 8.1 VM outperforms the Windows XP one by a margin and while the Windows 8.1 VM has speeds similar to the host, the XP one is far slower.

At this point I wonder if it has something to do with the fact that XP is a 32bit OS...
Repeating the tests on a Windows 10 VM I had lying around shows similar consistent results with the Windows 8.1 one, which are very close to the performances that the host has, so XP seems to be the outlier here.

I've got the general information (from @klaus) that a Windows XP guest should be able to get close to 1 GBit/s, but perhaps needs more than 1 vCPU to achieve that.

Oh, that's good to know.
What worries me is that although on the chromium test it might as well been the number of cores (4 cores all at 100% during the test), when I move files around with Total Commander the 4 virtual cores are not all at 100%, but the overall usage is spread across the cores and accounts for around 25-38% of the total.

if you want to investigate the issue in much more detail, I could provide further ideas about how to do that. Please let me know if you're so inclined.

Yes please, I would really like to do something to tackle this and at least improve performances.
In a way or another, the XP Guest is something I use a lot and having slow speeds affects everything, from RDP to VNC Viewer to file transfer of course.

[fth0]

What worries me is that although on the chromium test it might as well been the number of cores (4 cores all at 100% during the test), when I move files around with Total Commander the 4 virtual cores are not all at 100%, but the overall usage is spread across the cores and accounts for around 25-38% of the total.

The Chromium test indicates that you're using one of the multicore HALs in Windows XP, so far, so good. The Total Commander test is probably only using 1 vCPU for copying the files. Note that the vCPUs do not correspond to the host CPU cores or hyperthreads, so 1 vCPU at 100% can mean 4 host CPU cores at 25% or any asymmetrical distribution.

Since your host CPU has only 4 cores and since hyperthreads only add to that to some degree (~30%), providing the VM with 4 vCPUs can have negative consequences in high load situations. For a test, please provide only 2 vCPUs to your Windows XP VM and see if that makes a difference.

I would really like to do something to tackle this and at least improve performances.

To be able to perform some controlled measurements, I'd suggest to install iPerf3 (https://iperf.fr/iperf-download.php) on your host and your Windows XP and 8.1 guests. iPerf3 is a command line program doing TCP and UDP measurements with a lot of tweakable parameters.

As a first test, I'd like to compare two UDP transmissions that both VMs can easily manage. Open a terminal on your host and start iPerf3 in server mode with "iperf3 -s". Start the Windows XP VM, open a Windows command prompt, let iPerf3 perform a standard UDP measurement with the default 1 Mbit/s for the default 10 seconds with "iperf3 -c <host IP> -u", shut down the VM from within Windows XP and save the VBox.log file. Do the same with your Windows 8.1 VM. Then repeat both tests with switched roles, starting iPerf3 in server mode in the VMs and in client mode on the host. Finally, provide a zip file with all 4 VBox.log files and the measurement results. In the VBox.log files, I want to compare the detailed statistics of the virtual network adapter (use Intel PRO/1000 MT Desktop in both VMs), to identify differences in low-level algorithms like Interrupt Coalescing and Segmentation Offloading.

As a second test, experiment further with UDP (-u) traffic, modifying bitrate (-b) and buffer length (-l) to see how much you can unidirectionally transfer without noticeable packet loss. Depending on the results, it could make sense to use Wireshark on the host to capture the measurement traffic, to analyze the inter-packet-spacing and timing behavior.

If all those tests do not show real differences, the next step would be to make TCP measurements, which is closer to the Google speed test, but also introduces additional networking mechanisms.

[FranceBB]

Thank you so much for the detailed info and for pointing me to iperf3, I didn't know this awesome open source command line tool and I will totally use it in the future to make some tests on my own as well!

Now, on to the tests, shall we?
I'm gonna use a Windows 10 Enteprise x64 Bare Metal server with 2 Ethernet ports connected with Intel Teaming Mode. I also have some servers with 10 Gbit/s Ethernet and Windows Server 2019 x64, but it wouldn't matter 'cause the machine which is hosting the VMs is my own computer which is only connected via a 1 Gbit/s connection anyway, so...
Well, to be 100% honest (since you're gonna see it from the VM logs anyway), I do have 2x1 Gbit/s Ethernet, but XP is too old to be using any of that, which means that no matter if you connect 4 adapters, it will only use one at a time, given that multi-adapter transport has been introduced later on.
Anyway, we're digressing.

Here are the results:

Bare Metal: Windows 10 Enterprise x64
Adapter1: Intel I210 1 Gbit/s Ethernet
Adapter2: Intel I218 1 Gbit/s Ethernet

Guest: Windows XP Professional x86
Adapter: Intel PRO/1000 MT Desktop

Windows XP Professional x86 VM to Windows 10 Enterprise x64 Bare Metal

Protocol: TCP with unlimited bitrate

Connecting to host 10.75.144.142, port 5201
[ 4] local 10.75.144.233 port 1403 connected to 10.75.144.142 port 5201
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-1.01 sec 18.8 MBytes 157 Mbits/sec
[ 4] 1.01-2.01 sec 20.2 MBytes 169 Mbits/sec
[ 4] 2.01-3.01 sec 21.1 MBytes 177 Mbits/sec
[ 4] 3.01-4.00 sec 19.7 MBytes 167 Mbits/sec
[ 4] 4.00-5.00 sec 21.1 MBytes 177 Mbits/sec
[ 4] 5.00-6.01 sec 19.8 MBytes 166 Mbits/sec
[ 4] 6.01-7.01 sec 19.3 MBytes 162 Mbits/sec
[ 4] 7.01-8.01 sec 20.4 MBytes 171 Mbits/sec
[ 4] 8.01-9.00 sec 18.3 MBytes 155 Mbits/sec
[ 4] 9.00-10.01 sec 19.6 MBytes 164 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-10.01 sec 199 MBytes 166 Mbits/sec sender
[ 4] 0.00-10.01 sec 199 MBytes 166 Mbits/sec receiver

iperf Done.



Guest: Windows 8.1 Professional x64
Adapter: Intel PRO/1000 MT Desktop

Windows 8.1 Professional x64 VM to Windows 10 Enterprise x64 Bare Metal

Protocol: TCP with unlimited bitrate

Connecting to host 10.75.144.84, port 5201
[ 4] local 10.75.144.176 port 49199 connected to 10.75.144.84 port 5201
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-1.00 sec 117 MBytes 984 Mbits/sec
[ 4] 1.00-2.00 sec 116 MBytes 971 Mbits/sec
[ 4] 2.00-3.00 sec 116 MBytes 978 Mbits/sec
[ 4] 3.00-4.00 sec 117 MBytes 983 Mbits/sec
[ 4] 4.00-5.00 sec 107 MBytes 901 Mbits/sec
[ 4] 5.00-6.00 sec 106 MBytes 891 Mbits/sec
[ 4] 6.00-7.00 sec 105 MBytes 880 Mbits/sec
[ 4] 7.00-8.00 sec 104 MBytes 873 Mbits/sec
[ 4] 8.00-9.00 sec 105 MBytes 883 Mbits/sec
[ 4] 9.00-10.00 sec 106 MBytes 887 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-10.00 sec 1.07 GBytes 923 Mbits/sec sender
[ 4] 0.00-10.00 sec 1.07 GBytes 923 Mbits/sec receiver

iperf Done.


Now, let's do the other way round, namely from Bare Metal to the VMs respectively.

Windows 10 Enterprise x64 Bare Metal to Windows XP Professional x86 VM

Protocol: TCP with unlimited bitrate

Connecting to host 10.75.144.138, port 5201
[ 4] local 10.75.144.84 port 7026 connected to 10.75.144.138 port 5201
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-1.00 sec 39.9 MBytes 134 Mbits/sec
[ 4] 1.00-2.00 sec 35.4 MBytes 197 Mbits/sec
[ 4] 2.00-3.01 sec 39.5 MBytes 129 Mbits/sec
[ 4] 3.01-4.01 sec 35.6 MBytes 199 Mbits/sec
[ 4] 4.01-5.01 sec 37.6 MBytes 116 Mbits/sec
[ 4] 5.01-6.00 sec 38.4 MBytes 123 Mbits/sec
[ 4] 6.00-7.00 sec 37.8 MBytes 117 Mbits/sec
[ 4] 7.00-8.00 sec 40.1 MBytes 137 Mbits/sec
[ 4] 8.00-9.00 sec 38.9 MBytes 125 Mbits/sec
[ 4] 9.00-10.00 sec 39.2 MBytes 130 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-10.00 sec 382 MBytes 121 Mbits/sec sender
[ 4] 0.00-10.00 sec 382 MBytes 121 Mbits/sec receiver

iperf Done.


Windows 10 Enterprise x64 Bare Metal to Windows 8.1 Professional x64 VM

Protocol: TCP with unlimited bitrate


Connecting to host 10.75.144.176, port 5201
[ 4] local 10.75.144.84 port 1348 connected to 10.75.144.176 port 5201
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-1.00 sec 112 MBytes 938 Mbits/sec
[ 4] 1.00-2.00 sec 112 MBytes 940 Mbits/sec
[ 4] 2.00-3.00 sec 112 MBytes 937 Mbits/sec
[ 4] 3.00-4.00 sec 112 MBytes 935 Mbits/sec
[ 4] 4.00-5.00 sec 110 MBytes 927 Mbits/sec
[ 4] 5.00-6.00 sec 112 MBytes 935 Mbits/sec
[ 4] 6.00-7.00 sec 109 MBytes 916 Mbits/sec
[ 4] 7.00-8.00 sec 110 MBytes 926 Mbits/sec
[ 4] 8.00-9.00 sec 111 MBytes 929 Mbits/sec
[ 4] 9.00-10.00 sec 111 MBytes 930 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-10.00 sec 1.08 GBytes 931 Mbits/sec sender
[ 4] 0.00-10.00 sec 1.08 GBytes 931 Mbits/sec receiver

iperf Done.



Now let's move to UDP with unlimited bitrate cap.

Windows XP Professional x86 VM to Windows 10 Enterprise x64 Bare Metal

Protocol: UDP with unlimited bitrate


Connecting to host 10.75.144.84, port 5201
[ 4] local 10.75.144.233 port 1541 connected to 10.75.144.84 port 5201
[ ID] Interval Transfer Bandwidth Total Datagrams
[ 4] 0.00-1.00 sec 37.0 MBytes 310 Mbits/sec 4730
[ 4] 1.00-2.00 sec 35.9 MBytes 301 Mbits/sec 4600
[ 4] 2.00-3.00 sec 37.0 MBytes 310 Mbits/sec 4730
[ 4] 3.00-4.00 sec 36.8 MBytes 309 Mbits/sec 4710
[ 4] 4.00-5.00 sec 37.1 MBytes 311 Mbits/sec 4750
[ 4] 5.00-6.00 sec 37.1 MBytes 311 Mbits/sec 4750
[ 4] 6.00-7.00 sec 37.3 MBytes 313 Mbits/sec 4780
[ 4] 7.00-8.00 sec 37.5 MBytes 315 Mbits/sec 4800
[ 4] 8.00-9.00 sec 37.0 MBytes 311 Mbits/sec 4740
[ 4] 9.00-10.00 sec 36.6 MBytes 307 Mbits/sec 4680
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datag
rams
[ 4] 0.00-10.00 sec 369 MBytes 310 Mbits/sec 0.993 ms 0/47269 (0%)
[ 4] Sent 47269 datagrams

iperf Done.

way faster, topping 310 Mbit/s, compared to TCP, sitting at around 166 Mbit/s, however it still falls short of the target, which is 1 Gbit/s.


Windows 8.1 Professional x64 VM to Windows 10 Enterprise x64 Bare Metal

Protocol: UDP with unlimited bitrate

Connecting to host 10.75.144.84, port 5201
[ 4] local 10.75.144.176 port 56829 connected to 10.75.144.84 port 5201
[ ID] Interval Transfer Bandwidth Total Datagrams
[ 4] 0.00-1.00 sec 141 MBytes 1.18 Gbits/sec 18040
[ 4] 1.00-2.00 sec 142 MBytes 1.19 Gbits/sec 18170
[ 4] 2.00-3.00 sec 142 MBytes 1.19 Gbits/sec 18140
[ 4] 3.00-4.00 sec 151 MBytes 1.27 Gbits/sec 19340
[ 4] 4.00-5.00 sec 138 MBytes 1.16 Gbits/sec 17640
[ 4] 5.00-6.00 sec 134 MBytes 1.12 Gbits/sec 17100
[ 4] 6.00-7.00 sec 159 MBytes 1.33 Gbits/sec 20330
[ 4] 7.00-8.00 sec 152 MBytes 1.28 Gbits/sec 19510
[ 4] 8.00-9.00 sec 158 MBytes 1.32 Gbits/sec 20170
[ 4] 9.00-10.00 sec 153 MBytes 1.28 Gbits/sec 19580
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datag
rams
[ 4] 0.00-10.00 sec 1.43 GBytes 1.23 Gbits/sec 435.608 ms 98033/186244 (
53%)
[ 4] Sent 186244 datagrams

iperf Done.


Well, 1.23 Gbit/s in UDP is an amazing speed, however this data from the bare metal isn't really comforting:

[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[ 5] 0.00-11.46 sec 0.00 Bytes 0.00 bits/sec 196.690 ms 84603/169749 (50%)
[SUM] 0.0-11.5 sec 3067 datagrams received out-of-order

if I understand that correctly, with UDP there are LOTS of packets lost, which might explain the slower speed of TCP as it's retransmitting a lot of data.
Also, it would make sense that lots of packets are lost 'cause the VM is really only supposed to be using 1 connection of 1 Gbit/s, so it's not really physically possible for it to exceed 1 Gbit/s, which might explain why the packets are lost and the reported speed are bogus.

Anyway, none of that matters as it's Windows 8.1 Professional x64.
The interesting (and much slower) figures come from the Windows XP Professional x86 VM.
In any case, I've attached the logs of both VMs performing the test.

[fth0]

Thank you so much for the detailed info and for pointing me to iperf3, I didn't know this awesome open source command line tool and I will totally use it in the future to make some tests on my own as well!

Now, on to the tests, shall we?

You're welcome! It sounds like you got carried away a bit. Did you also do the tests I asked you to do?

---

[SUM] 0.0-11.5 sec 3067 datagrams received out-of-order

This could be a consequence of your setup "with 2 Ethernet ports connected with Intel Teaming Mode". Using such a setup might be interesting for end-to-end measurements, but not really for analyzing a local problem. Unless it is necessary to reproduce the issue, of course, but then it's also part of the problem.

---

TCP is generally slower than UDP because it adapts to the minimum bandwidth of the whole path.

Regarding the VBox.log files, I noticed that most of the network traffic was using different network interfaces on the host (Windows XP -> enp0s20f0u1u3i5; Windows 8.1 -> enp3s0f1). Why should this lead to comparable results?

Regarding the Windows XP VM, you should only provide 2 vCPUs (as I already told you) and the one virtual network interface that you want to use.

[FranceBB]

I noticed that most of the network traffic was using different network interfaces on the host (Windows XP -> enp0s20f0u1u3i5; Windows 8.1 -> enp3s0f1).

Daaaaaamn, I'm an idiot.
I mean, well, technically they're both 1 Gbit/s connections that go down to the same switch, but one is through Thunderbolt 3 (enp0s20f0u1u3i5) and the other is through the RJ45 connector (enp3s0f1).
Anyway, good catch, I repeated the test and this time I only enabled enp3s0f1 on XP so that it's the same as Windows 8.1.

I repeated the tests.

Windows XP VM to Windows 10 bare metal
Virtual Core Assigned: 4
Type: TCP Unlimited


Connecting to host 10.75.144.142, port 5201
[ 4] local 10.75.144.138 port 1690 connected to 10.75.144.142 port 5201
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-1.00 sec 8.37 MBytes 70.2 Mbits/sec
[ 4] 1.00-2.00 sec 6.83 MBytes 57.3 Mbits/sec
[ 4] 2.00-3.00 sec 5.91 MBytes 49.5 Mbits/sec
[ 4] 3.00-4.00 sec 5.91 MBytes 49.5 Mbits/sec
[ 4] 4.00-5.00 sec 9.29 MBytes 77.9 Mbits/sec
[ 4] 5.00-6.00 sec 7.32 MBytes 61.4 Mbits/sec
[ 4] 6.00-7.00 sec 8.37 MBytes 70.2 Mbits/sec
[ 4] 7.00-8.00 sec 6.58 MBytes 55.2 Mbits/sec
[ 4] 8.00-9.00 sec 8.06 MBytes 67.6 Mbits/sec
[ 4] 9.00-10.00 sec 7.94 MBytes 66.6 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-10.00 sec 74.6 MBytes 62.5 Mbits/sec sender
[ 4] 0.00-10.00 sec 74.6 MBytes 62.5 Mbits/sec receiver

iperf Done.


Windows XP VM to Windows 10 bare metal
Virtual Core Assigned: 4
Type: UDP Unlimited


Connecting to host 10.75.144.142, port 5201
[ 4] local 10.75.144.138 port 1381 connected to 10.75.144.142 port 5201
[ ID] Interval Transfer Bandwidth Total Datagrams
[ 4] 0.00-1.01 sec 33.7 MBytes 279 Mbits/sec 4310
[ 4] 1.01-2.01 sec 46.9 MBytes 394 Mbits/sec 6000
[ 4] 2.01-3.01 sec 49.9 MBytes 420 Mbits/sec 6390
[ 4] 3.01-4.00 sec 52.1 MBytes 439 Mbits/sec 6670
[ 4] 4.00-5.00 sec 50.5 MBytes 425 Mbits/sec 6470
[ 4] 5.00-6.01 sec 49.2 MBytes 409 Mbits/sec 6300
[ 4] 6.01-7.01 sec 48.7 MBytes 410 Mbits/sec 6230
[ 4] 7.01-8.00 sec 48.4 MBytes 408 Mbits/sec 6200
[ 4] 8.00-9.00 sec 50.1 MBytes 421 Mbits/sec 6410
[ 4] 9.00-10.00 sec 53.3 MBytes 446 Mbits/sec 6820
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datag
rams
[ 4] 0.00-10.00 sec 483 MBytes 405 Mbits/sec 0.659 ms 0/61799 (0%)
[ 4] Sent 61799 datagrams

iperf Done.



Windows XP VM to Windows 10 bare metal
Virtual Core Assigned: 4
Type: UDP default (Limited 1 Mbit/s)


Connecting to host 10.75.144.142, port 5201
[ 4] local 10.75.144.138 port 1412 connected to 10.75.144.142 port 5201
[ ID] Interval Transfer Bandwidth Total Datagrams
[ 4] 0.00-1.01 sec 264 KBytes 2.15 Mbits/sec 33
[ 4] 1.01-2.01 sec 248 KBytes 2.02 Mbits/sec 31
[ 4] 2.01-3.00 sec 272 KBytes 2.25 Mbits/sec 34
[ 4] 3.00-4.01 sec 272 KBytes 2.22 Mbits/sec 34
[ 4] 4.01-5.01 sec 272 KBytes 2.22 Mbits/sec 34
[ 4] 5.01-6.01 sec 264 KBytes 2.17 Mbits/sec 33
[ 4] 6.01-7.01 sec 272 KBytes 2.22 Mbits/sec 34
[ 4] 7.01-8.00 sec 224 KBytes 1.86 Mbits/sec 28
[ 4] 8.00-9.00 sec 216 KBytes 1.77 Mbits/sec 27
[ 4] 9.00-10.01 sec 200 KBytes 1.63 Mbits/sec 25
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datag
rams
[ 4] 0.00-10.01 sec 2.45 MBytes 2.05 Mbits/sec 6.673 ms 0/312 (0%)
[ 4] Sent 312 datagrams

iperf Done.

Did you also do the tests I asked you to do?
Regarding the Windows XP VM, you should only provide 2 vCPUs

Here they are, with 2 virtual cores assigned, as you said.


Windows XP VM to Windows 10 bare metal
Virtual Core Assigned: 2
Type: TCP Unlimited

Connecting to host 10.75.144.142, port 5201
[ 4] local 10.75.144.138 port 1553 connected to 10.75.144.142 port 5201
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-1.00 sec 7.08 MBytes 59.4 Mbits/sec
[ 4] 1.00-2.00 sec 8.18 MBytes 68.6 Mbits/sec
[ 4] 2.00-3.00 sec 8.06 MBytes 67.6 Mbits/sec
[ 4] 3.00-4.00 sec 9.17 MBytes 76.9 Mbits/sec
[ 4] 4.00-5.00 sec 8.86 MBytes 74.3 Mbits/sec
[ 4] 5.00-6.00 sec 6.95 MBytes 58.3 Mbits/sec
[ 4] 6.00-7.00 sec 8.86 MBytes 74.3 Mbits/sec
[ 4] 7.00-8.00 sec 7.44 MBytes 62.4 Mbits/sec
[ 4] 8.00-9.00 sec 8.31 MBytes 69.7 Mbits/sec
[ 4] 9.00-10.00 sec 8.24 MBytes 69.2 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-10.00 sec 81.1 MBytes 68.1 Mbits/sec sender
[ 4] 0.00-10.00 sec 81.1 MBytes 68.1 Mbits/sec receiver

iperf Done.


Windows XP VM to Windows 10 bare metal
Virtual Core Assigned: 2
Type: UDP Unlimited


Connecting to host 10.75.144.142, port 5201
[ 4] local 10.75.144.138 port 1438 connected to 10.75.144.142 port 5201
[ ID] Interval Transfer Bandwidth Total Datagrams
[ 4] 0.00-1.01 sec 33.8 MBytes 282 Mbits/sec 4330
[ 4] 1.01-2.01 sec 51.1 MBytes 426 Mbits/sec 6540
[ 4] 2.01-3.00 sec 45.0 MBytes 381 Mbits/sec 5760
[ 4] 3.00-4.00 sec 44.1 MBytes 369 Mbits/sec 5640
[ 4] 4.00-5.00 sec 35.5 MBytes 297 Mbits/sec 4550
[ 4] 5.00-6.01 sec 52.0 MBytes 435 Mbits/sec 6660
[ 4] 6.01-7.01 sec 45.7 MBytes 382 Mbits/sec 5850
[ 4] 7.01-8.01 sec 47.0 MBytes 394 Mbits/sec 6020
[ 4] 8.01-9.01 sec 33.5 MBytes 280 Mbits/sec 4290
[ 4] 9.01-10.00 sec 42.4 MBytes 360 Mbits/sec 5430
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datag
rams
[ 4] 0.00-10.00 sec 430 MBytes 361 Mbits/sec 1.013 ms 0/55069 (0%)
[ 4] Sent 55069 datagrams

iperf Done.


Windows XP VM to Windows 10 bare metal
Virtual Core Assigned: 2
Type: UDP default (Limited 1 Mbit/s)


Connecting to host 10.75.144.142, port 5201
[ 4] local 10.75.144.138 port 1508 connected to 10.75.144.142 port 5201
[ ID] Interval Transfer Bandwidth Total Datagrams
[ 4] 0.00-1.00 sec 176 KBytes 1.44 Mbits/sec 22
[ 4] 1.00-2.00 sec 80.0 KBytes 655 Kbits/sec 10
[ 4] 2.00-3.00 sec 128 KBytes 1.05 Mbits/sec 16
[ 4] 3.00-4.00 sec 128 KBytes 1.05 Mbits/sec 16
[ 4] 4.00-5.00 sec 128 KBytes 1.05 Mbits/sec 16
[ 4] 5.00-6.00 sec 128 KBytes 1.05 Mbits/sec 16
[ 4] 6.00-7.00 sec 128 KBytes 1.05 Mbits/sec 16
[ 4] 7.00-8.01 sec 128 KBytes 1.05 Mbits/sec 16
[ 4] 8.01-9.01 sec 128 KBytes 1.05 Mbits/sec 16
[ 4] 9.01-10.00 sec 176 KBytes 1.45 Mbits/sec 22
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datag
rams
[ 4] 0.00-10.00 sec 1.30 MBytes 1.09 Mbits/sec 6.743 ms 0/165 (0%)
[ 4] Sent 165 datagrams

iperf Done.


Windows 8.1 VM to Windows 10 bare metal
Virtual Core Assigned: 4
Type: UDP default (Limited 1 Mbit/s)


Connecting to host 10.75.144.142, port 5201
[ 4] local 10.75.144.176 port 61748 connected to 10.75.144.142 port 5201
[ ID] Interval Transfer Bandwidth Total Datagrams
[ 4] 0.00-1.02 sec 128 KBytes 1.03 Mbits/sec 16
[ 4] 1.02-2.02 sec 128 KBytes 1.05 Mbits/sec 16
[ 4] 2.02-3.01 sec 128 KBytes 1.05 Mbits/sec 16
[ 4] 3.01-4.01 sec 128 KBytes 1.05 Mbits/sec 16
[ 4] 4.01-5.01 sec 128 KBytes 1.05 Mbits/sec 16
[ 4] 5.01-6.03 sec 128 KBytes 1.03 Mbits/sec 16
[ 4] 6.03-7.03 sec 128 KBytes 1.05 Mbits/sec 16
[ 4] 7.03-8.03 sec 128 KBytes 1.05 Mbits/sec 16
[ 4] 8.03-9.03 sec 128 KBytes 1.05 Mbits/sec 16
[ 4] 9.03-10.03 sec 128 KBytes 1.05 Mbits/sec 16
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Jitter Lost/Total
rams
[ 4] 0.00-10.03 sec 1.25 MBytes 1.05 Mbits/sec 12.532 ms 0/159 (0%)

[mpack]

Your host has 4 physical cores. It does not make good sense to assign all of them to guest code. Note that VirtualBox itself is a host process, very little of it is guest code. Two cores is fine for the guest.

[FranceBB]

For what it's worth, I also upgraded from Virtualbox 7.0.97 r156683 to Virtualbox 7.0.97 r157070, I repeated the tests and there was no speed change whatsoever.