Epyc VM to VM networking slow
-
@olivierlambert said in Epyc VM to VM networking slow:
Or maybe AMD CPU are a lot slower with memcpy()?
Has anyone reviewed this issue? Is there a way to test with a newer version of
glibc? -
@nicols give me your VM specs and I'll run the exact same tests. vCPU, RAM, anything else relevant.
-
@Danp That's interesting...
-
@JamesG said in Epyc VM to VM networking slow:
@nicols give me your VM specs and I'll run the exact same tests. vCPU, RAM, anything else relevant.
Debian 12: 16 VCPU, 2GB RAM
Windows 10 pro: 16 VCPU, 8GB RAM, citrix vmtols 9.3.1On Linux Debian there is no much difference between 8 and 16 VCPU
On Windows 10, 8 VCPU: 16 Gbit/sec, 16 VCPU: 21 Gbit/sec -
@JamesG said in Epyc VM to VM networking slow:
@Danp That's interesting...
Yes, it is, but as i wrote earlier, i get full 21 Gbps Linux VM to VM on Proxmox/KVM (on exact same host, same BIOS settings), so i think it must be some problem on relation Epyc - Xen hypervisor....
-
@nicols Agreed. I'm pretty sure this is a Xen/Epyc issue.
This evening I'll build a couple of VM's to your config, run iperf, and report back the results.
-
@nicols said in Epyc VM to VM networking slow:
i get full 21 Gbps Linux VM to VM on Proxmox/KVM
If
glibcis the source of the issue, then a likely explanation for your results is that Proxmox/KVM are using an updated version of this library where the patch has been applied.@olivierlambert Do you know if anyone on your team has looked into this?
-
We are very very busy ATM.
Also, about comparing to KVM doesn't make sense at all: there's no such network/disk isolation in KVM, so you can do zero copy, which will yield to much better performances (at the price of the thin isolation).
First, we should compare between 2x fully patched systems (one Intel one AMD) a similar config, we could have a baseline and understands why AMD is a lot slower.
-
Adding @dthenot in the loop in case it rings a bell.
-
The past couple of days have been pretty nuts, but I've dabbled with testing this and in my configuration with XCP-ng 8.3 with all currently released patches, I top out at 15Gb/s with 8 threads on Win 10. Going further to 16 threads or beyond doesn't really improve things.
Killing core boost, SMT, and setting deterministic performance in BIOS added nearly 2Gb/s on single-threaded iperf.
When running the iperf and watching htop on the XCP-ng server, I see nearly all cores running at 15-20% for the duration of the transfer. That seems excessive.
Iperf on the E3-1230v2...Single thread, 9.27Gbs. Neglibile improvement for more threads. Surprisingly, a similar hit on CPU performance. Not as bad though. 10Gbps traffic hits about 10% or so. Definitely not as bad as on the Epyc system.
I'll do more thorough testing tomorrow.
-
I've found that iperf isnt super great at scaling it's performance, which might be a small factor here.
I too have similar performance figures VM<->VM on a AMD EPYC 7402P 24-Core server. About 6-8Gbit/s.
-
Today, i got my hands on HPE ProLiant DL325 Gen10 server with Epyc 7502 32 core (64 threads) CPU. I have installed XCP-ng 8.2.1, and applied all pathes wth yum update. Installed 2 Debian and 2 Windows 10 VMs. Results are very similar:
Linux to Linux VM on single host: 4 Gbit/sec on single thread, max 6 Gbit/sec on mulčtiple threads.
I have tried various amountss of VCPU (2,4,8.12,16) and various combinations of iperf threads.Windws to Windows VM: 3.5 Gbit/sec on single thread, and 18 Gbit/sec um multiple threads.
All this was with default bios settings, just changed to legacy boot.
Wet performance tuning in bios (c states and other settings), i believe i can get 10-15% more, i will try that tommorow.So, i think this confirms that this is not Supermicro related problem, but something on relation Xen (hypervisor?) <-> AMD CPU.
-
@olivierlambert said in Epyc VM to VM networking slow:
Also, about comparing to KVM doesn't make sense at all: there's no such network/disk isolation in KVM, so you can do zero copy, which will yield to much better performances (at the price of the thin isolation).
Yes, we are all aware of KVM / Xen differences, BUT: there is something important here to consider: I am getting similar result in Winsows VM to VM network traffic on Prox and XCP-ng. This proves that network/disk isolation on XCP-ng isn't slowing anything down.
Prox/KVM Linux VM to VM network speed is the same as with Windows VMs.
Problem is much slower network traffic on Linux VM to VM on single XCP-ng host.
-
That's exactly what I'd like to confirm with the community. If we can spot a different in Windows guests and Linux guests, it might be interesting to find why
-
@nicols said in Epyc VM to VM networking slow:
Today, i got my hands on HPE ProLiant DL325 Gen10 server with Epyc 7502 32 core (64 threads) CPU. I have installed XCP-ng 8.2.1, and applied all pathes wth yum update. Installed 2 Debian and 2 Windows 10 VMs. Results are very similar:
Linux to Linux VM on single host: 4 Gbit/sec on single thread, max 6 Gbit/sec on mulčtiple threads.
I have tried various amountss of VCPU (2,4,8.12,16) and various combinations of iperf threads.Windws to Windows VM: 3.5 Gbit/sec on single thread, and 18 Gbit/sec um multiple threads.
All this was with default bios settings, just changed to legacy boot.
Wet performance tuning in bios (c states and other settings), i believe i can get 10-15% more, i will try that tommorow.So, i think this confirms that this is not Supermicro related problem, but something on relation Xen (hypervisor?) <-> AMD CPU.
Same hardware, VmWare ESXi 8.0, Debian 12 VMs with 4 vCPU and 2GB RAM.
root@debian-on-vmwareto:~# iperf -c 10.33.65.159 ------------------------------------------------------------ Client connecting to 10.33.65.159, TCP port 5001 TCP window size: 16.0 KByte (default) ------------------------------------------------------------ [ 1] local 10.33.65.160 port 59124 connected with 10.33.65.159 port 5001 (icwnd/mss/irtt=14/1448/164) [ ID] Interval Transfer Bandwidth [ 1] 0.0000-10.0094 sec 29.0 GBytes 24.9 Gbits/secwith more threads:
root@debian-on-vmwareto:~# iperf -c 10.33.65.159 -P4 ------------------------------------------------------------ Client connecting to 10.33.65.159, TCP port 5001 TCP window size: 16.0 KByte (default) ------------------------------------------------------------ [ 3] local 10.33.65.160 port 46444 connected with 10.33.65.159 port 5001 (icwnd/mss/irtt=14/1448/107) [ 1] local 10.33.65.160 port 46446 connected with 10.33.65.159 port 5001 (icwnd/mss/irtt=14/1448/130) [ 2] local 10.33.65.160 port 46442 connected with 10.33.65.159 port 5001 (icwnd/mss/irtt=14/1448/136) [ 4] local 10.33.65.160 port 46468 connected with 10.33.65.159 port 5001 (icwnd/mss/irtt=14/1448/74) [ ID] Interval Transfer Bandwidth [ 3] 0.0000-10.0142 sec 7.59 GBytes 6.51 Gbits/sec [ 1] 0.0000-10.0142 sec 15.5 GBytes 13.3 Gbits/sec [ 4] 0.0000-10.0136 sec 7.89 GBytes 6.77 Gbits/sec [ 2] 0.0000-10.0142 sec 14.7 GBytes 12.6 Gbits/sec [SUM] 0.0000-10.0018 sec 45.6 GBytes 39.2 Gbits/secWill try with with windows VMs next.
I know it is apples and oranges, but i would accept speed difference of abbout 10-20%.
Here, we are talking about more tahn 600% difference. -
Those are really interesting results.
How can we as a community best help find the root cause/debug this issue?
For example, is it an ovswitch issue or perhaps something to do with excessive context switches?
-
It's not OVS, it's related to the inherent copy in RAM needed by Xen to ensure the right isolation between guests (including the dom0).
However, to me what's important isn't the difference with VMware, it's the difference between hardware. Old Xeon shouldn't be faster (at equal frequency) than any EPYCs.
-
It could be a cpu/xeon specific optimisation that is very unfortunate on EPYCs. It isn't unheard of.
-
Yeah, that's why I'd like to get more data, and if I have enough, to brainstorm with some Xen dev to think if it's something that could be fixed on "our" side (software) or not (if it's purely a hardware thing)
-
@olivierlambert said in Epyc VM to VM networking slow:
I wonder about the guest kernel too (Debian 11 vs 12)
Here are my results with Debian11 vs. Debian12 on our EPYC 7313P 16-Core Processor on the same host. Fresh and fully updated VMs with 4vcpu /4GB RAM, XCP-NG guest tools 7.30.0-11 are installed.:
All tests were made 3 times showing the best result.
All tests with multiple connections were made three times -P2 /-P4/-P8/-P12/-P16 showing here the best result:
DEBIAN11>DEBIAN11 ------------------------- **root@deb11-master:~# iperf3 -c 192.168.1.95** Connecting to host 192.168.1.95, port 5201 ------------------------------------------------ [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.00 sec 8.84 GBytes 7.60 Gbits/sec 1687 sender [ 5] 0.00-10.04 sec 8.84 GBytes 7.56 Gbits/sec receiver **root@deb11-master:~# iperf3 -c 192.168.1.95 -P2** Connecting to host 192.168.1.95, port 5201 ------------------------------------------------------------ [SUM] 0.00-10.00 sec 12.0 GBytes 10.3 Gbits/sec 2484 sender [SUM] 0.00-10.04 sec 12.0 GBytes 10.3 Gbits/sec receiverDEBIAN12>DEBIAN12 ------------------------- **root@deb12master:~# iperf3 -c 192.168.1.98** Connecting to host 192.168.1.98, port 5201 ----------------------------------------------- [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.00 sec 5.12 GBytes 4.40 Gbits/sec 953 sender [ 5] 0.00-10.00 sec 5.12 GBytes 4.39 Gbits/sec receiver **root@deb12master:~# iperf3 -c 192.168.1.98 -P4** Connecting to host 192.168.1.98, port 5201 ----------------------------------------------- [SUM] 0.00-10.00 sec 3.58 GBytes 3.08 Gbits/sec 3365 sender [SUM] 0.00-10.00 sec 3.57 GBytes 3.07 Gbits/sec receiverConclusion: Debian12 with kernel 6.1.55-1 compared to Debain 11 with kernel 5.10.197-1 run less performant on this EPYC host.
I will check now if I could perform the same test with a Windows VM.
Update
A quick test with two Windows 7 VMs, both with 2 vcpu / 2GB RAM have shown the best result with, the latest available Citrix guest tools are installed:
C:\Tools\Iperf3\iperf3.exe -c 192.168.1.108 -P8
In average 11.3 GBits/sec were reached.
