Wireguard Serverhardware Testinitiative

Technik
1

Hallo zusammen,

wir sind gerade am überlegen, welche Server-Hardware man am besten für Wireguard-Tunnel nutzen kann und wie viel Performance man sich von welcher Hardware erhoffen kann. Dazu wollen wir Performancewerte für unterschiedliche Hardware sammeln. Falls ihr zwei x86-Geräte mit 10G-Interfaces habt, die ihr direkt mit einem LAN-Kabel (oder mit einer Faser) verbinden könnt, könnt ihr zu dem Test beitragen.

Ich habe ein Skript geschrieben, das die Konfiguration die komplette Konfiguration übernimmt: GitHub - lemoer/ff-wg-testenv

Das Skript kennt drei Modi: wg, wg+vxlan oder wg+vxlan+batman. Bitte testet alle drei Modi separat. Dann können wir einschätzen, welcher Overhead durch die zusätzlichen Schichten entsteht.

Voraussetzungen:

  • Auf beiden Geräten muss irgendein Linux laufen.
  • Es muss ein direkter 10G Link existieren.
  • (Bei 1G Links ist zu erwarten, dass der limitierender Faktor nicht die CPU, sondern der Link ist.)

Schreibt dann hier in dem Thread eine kurze Nachricht, welche Hardware (CPU und NIC) ihr verwendet habt und was eure erzielte Performance ist. Ich hoffe, dass wir hier Daten sammeln können, auf die alle Communities irgendwann zurückgreifen können.

3 „Gefällt mir“
2

Ich könnte das virtuelle anbieten ohne weitere VMs auf bis zu 24 Cores da kann man frei regeln … aber amd

3

Was meinst du mit „das virtuelle“?

4

Mit linux als vm

5

Testergebnisse von heute:

Hardware (beide Seiten gleich):

CPUs: 2x AMD EPYC 7763 64-Core Processor (256 Threads in Total)
NIC: Intel 10G X550T
OS: CentOS 7
Kernel: Linux 3.10.0-1160.45.1.el7.x86_64

wireguard (only): 1.88 Gbits/sec
wireguard + vxlan: 1.76 Gbits/sec

Getestet wurde mit 10 Streams in IPerf.

  • Die Rx-Seite scheint der Grund für die Auslastung zu sein.
  • Auf der Rx-Seite waren 1,3 Threads (von 256 Threads) ausgelastet:
    • Zwei kworker haben den einen Thread zu 100% ausgelastet.
    • Der zweite Thread wurde zu 30% von iperf3 ausgelastet.
  • Auf der Tx-Seite waren nur 0,8 Threads ausgelastet.
  • Leider habe ich es bei dem 3.10er-Kernel nicht hinbekommen, ein aktuelles batman-adv zu bauen.
  • Außerdem ist bei dem 3.10er-Kernel auch fraglich, wieviele Bugs wir da in dem Stack noch haben. Ich erinnere mich zumindest, dass es vxlan-Performance-Patches der Münchener gab, die (glaube ich) erst in 5.x germergt wurden.
6

Mit linux als vm

Klingt gut. Beschreib dann am besten das Setup ein bisschen.

7

Hier habe ich noch ein paar Testergebnisse für Wireguard gefunden. Ist zwar keine Linux-Implementation, aber evtl. trdm. interessant: WireGuard in pfSense 2.5 Performance.

8

Mal ein paar Benchmarks gemacht:

Side 1:

AMD Ryzen 9 3950x (16 cores, 32 threads, passmark ST 2710 / MT 38980)
Mellanox MT42822 ConnectX-6 Dx
B.A.T.M.A.N. adv 2023.1
Linux 6.3.0rc2

Side 2:

Intel Core i9-13900K (16 cores, 32 threads, passmark ST 4683 / MT 60033)
Mellanox MT42822 ConnectX-6 Dx
B.A.T.M.A.N. adv 2022.3
Linux 6.1.25

Direct IP (single TCP connection)

[  5]   0.00-10.00  sec  27.3 GBytes  23.4 Gbits/sec  106             sender
[  5]   0.00-10.00  sec  26.1 GBytes  22.4 Gbits/sec                  receiver

Wireguard only

Single TCP connection:

[  5]   0.00-10.00  sec  8.21 GBytes  7.05 Gbits/sec  228             sender
[  5]   0.00-10.00  sec  6.37 GBytes  5.47 Gbits/sec                  receiver

10 parallel TCP connections:

[SUM]   0.00-10.00  sec  7.76 GBytes  6.66 Gbits/sec  34706             sender
[SUM]   0.00-10.00  sec  6.10 GBytes  5.24 Gbits/sec                  receiver

VXLAN

Single TCP connection:

[  5]   0.00-10.00  sec  5.14 GBytes  4.41 Gbits/sec   27             sender
[  5]   0.00-10.00  sec  5.99 GBytes  5.14 Gbits/sec                  receiver

10 parallel TCP connections:

[SUM]   0.00-10.01  sec  5.87 GBytes  5.03 Gbits/sec  2808             sender
[SUM]   0.00-10.00  sec  5.38 GBytes  4.62 Gbits/sec                  receiver

BATMAN

Single TCP connection:

[  5]   0.00-10.00  sec  3.91 GBytes  3.36 Gbits/sec   44             sender
[  5]   0.00-10.00  sec  4.36 GBytes  3.75 Gbits/sec                  receiver

10 parallel TCP connections:

[SUM]   0.00-10.02  sec  4.12 GBytes  3.54 Gbits/sec  279             sender
[SUM]   0.00-10.00  sec  4.05 GBytes  3.48 Gbits/sec                  receiver

Sind recht spannende Ergebnisse geworden. Man merkt recht deutlich, dass die Intel-Seite mit dem i9 noch ein klein wenig zuegiger unterwegs ist.
Mit dem doch recht brutalen Performance-Impact von Wireguard habe ich so auch nicht gerechnet.
Bei den Tests war dann spannenderweise keine Volllast auf den CPU-Kernen zu sehen, einiges an ksoftirq-Last, 32 kworker-wg-crypt. Die Netzwerkkarten haben auch jeweils 32 Queues exposed.

Die Hardware ist hier definitiv noch nicht am Ende ihrer Leistung, das braucht noch etwas mehr Investigation. hmm

Habe auch mal mittels:

ethtool -K enp10s0f0np0 rx off tx off gso off tso off sg off

jegliches Offloading ausgeschaltet, veraendert aber exakt 0 an der Performance.

4 „Gefällt mir“
9

@Manawyrm Danke dir für die interessanten Ergebnisse!

Zu wieviel % waren die CPU-Kernne denn etwa ausgelastet?

10

Testergebnis FFAC:

Side 1 und 2 auf verschiedenen baugleichen proxmox hypervisors:

AMD EPYC 7402P 24-Core Processor
virtualisiertes Debian 11 mit - nur 8 Cores
Mellanox Technologies MT27710 Family [ConnectX-4 Lx]
B.A.T.M.A.N. adv 2020.4
5.10.0-20-amd64

usage geht auf 2.5 hoch während der tests

RAW
iperf3 -c 192.168.102.31 -R -P10 -t15
[SUM]   0.00-15.03  sec  15.1 GBytes  8.62 Gbits/sec  120478             sender
[SUM]   0.00-15.00  sec  15.1 GBytes  8.62 Gbits/sec                  receiver

WG
iperf3 -c 192.168.121.2 -R -P10 -t15
[SUM]   0.00-15.02  sec  3.51 GBytes  2.01 Gbits/sec  979             sender
[SUM]   0.00-15.00  sec  3.49 GBytes  2.00 Gbits/sec                  receiver

VXLAN
iperf3 -c 192.168.121.2 -R -P10 -t15
[SUM]   0.00-15.04  sec  2.71 GBytes  1.55 Gbits/sec  680             sender
[SUM]   0.00-15.00  sec  2.69 GBytes  1.54 Gbits/sec                  receiver

BATMAN (braucht 5 sekunden bis der link besteht)
iperf3 -c 192.168.121.2 -R -P10 -t15
[SUM]   0.00-15.04  sec  2.30 GBytes  1.31 Gbits/sec  520             sender
[SUM]   0.00-15.00  sec  2.29 GBytes  1.31 Gbits/sec                  receiver

war inkl frischen VMs ne halbe Stunde Aufwand.
Bin aber doch etwas verwundert über die Wireguard performance

Sonntag-Nachtrag: Backports-Kernel brachte keinen Unterschied.
Nur 4 statt 8 cores pro VM etwas bessere Werte - generell schwankt es gerne mal um 0.2 Gbits/sec.

WG
[SUM]   0.00-15.04  sec  4.88 GBytes  2.79 Gbits/sec  2717             sender
[SUM]   0.00-15.00  sec  4.87 GBytes  2.79 Gbits/sec                  receiver

BATMAN
[SUM]   0.00-15.02  sec  3.56 GBytes  2.04 Gbits/sec  683             sender
[SUM]   0.00-15.00  sec  3.54 GBytes  2.03 Gbits/sec                  receiver

Was besser, aber die 10GBit WG experimente funktionieren wohl nicht mit unseren MTU oder irgendwas ist komisch?
Frage mich wie die 11.8 Gbits/sec inkernel-WG mit i5-12400 hier zustande kommt: Surpassing 10Gb/s over Tailscale · Tailscale

11

In der Tat interessant, dass WG so weit unter RAW liegt. @Sirius sollte der Traffic im WG nicht nahezu der Leitungskapazität entsprechen?

12

@fmaurer: Wie war denn die CPU-Auslastung während deines Tests? War die CPU gut ausgelastet? Und wie hast du die NIC in die VMs durchgereicht? Über Bridges? Oder direkt PCIe-Passthrough?

Vielen Dank für die Ergebnisse! :slight_smile:

13

Also die VM hatte ne load usage von bis zu 2.5 - egal ob 4 oder 8 vcpu zugewiesen sind
An dem interface liegt ne bridge vmbr (notwendig bei proxmox) und in der VM dann virtio
Direkt passthrough kann ich nicht ausprobieren, da auch noch bisschen anderes drauf läuft.
Ist aber noch genug rechenleistung und Platz im Link verfügbar

14

Hypervisor: Ubuntu 22.04 - 5.15.0-100-generic - AMD EPYC 9754 128-Core Processor - Mellanox 5 2x 10G
VM: Ubuntu 20.04 - 5.4.0-173-generic
VM mit 16 Cores, virtio Treiber und 10 vnic queues.

Direkt: 18,9Gbps
wg: 2,4gbps
wg+vxlan: 2,2gbps
mit batman 800mbps

Also auch hier der riesige Wireguard Verlust wie bei @fmaurer

Attached ein Flamegraph während dem Run

perf

15

Hier noch etwas Erklärung zum Thema https://www.net.in.tum.de/fileadmin/bibtex/publications/theses/2018-pudelko-vpn-performance.pdf

Eventuell auch einfach ein Bug in Ubuntu

2 „Gefällt mir“