# Wireguard Serverhardware Testinitiative **URL:** \ **Category:** Technik\ **Created:** [6. April 2023 um 19:51 UTC](https://forum.freifunk.net/t/wireguard-serverhardware-testinitiative/23711 "2023-04-06T19:51:28Z")\ **Posts on this page:** 16\ **Page:** 1
**Author:** ![lemoer](https://forum.freifunk.net/letter_avatar_proxy/v4/letter/l/8e8cbc/32.png) [@lemoer](https://forum.freifunk.net/u/lemoer)\ **Post date:** [6. April 2023 um 19:51 UTC](https://forum.freifunk.net/t/wireguard-serverhardware-testinitiative/23711/1 "2023-04-06T19:51:28Z")
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](https://github.com/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. ---
**Author:** ![windoof](https://forum.freifunk.net/user_avatar/forum.freifunk.net/windoof/32/1434_2.png) [@windoof](https://forum.freifunk.net/u/windoof)\ **Post date:** [13. April 2023 um 11:22 UTC](https://forum.freifunk.net/t/wireguard-serverhardware-testinitiative/23711/2 "2023-04-13T11:22:39Z")
Ich könnte das virtuelle anbieten ohne weitere VMs auf bis zu 24 Cores da kann man frei regeln … aber amd ---
**Author:** ![lemoer](https://forum.freifunk.net/letter_avatar_proxy/v4/letter/l/8e8cbc/32.png) [@lemoer](https://forum.freifunk.net/u/lemoer)\ **Post date:** [13. April 2023 um 19:52 UTC](https://forum.freifunk.net/t/wireguard-serverhardware-testinitiative/23711/3 "2023-04-13T19:52:29Z")
Was meinst du mit „das virtuelle“? ---
**Author:** ![windoof](https://forum.freifunk.net/user_avatar/forum.freifunk.net/windoof/32/1434_2.png) [@windoof](https://forum.freifunk.net/u/windoof)\ **Post date:** [13. April 2023 um 20:12 UTC](https://forum.freifunk.net/t/wireguard-serverhardware-testinitiative/23711/4 "2023-04-13T20:12:46Z")
Mit linux als vm ---
**Author:** ![lemoer](https://forum.freifunk.net/letter_avatar_proxy/v4/letter/l/8e8cbc/32.png) [@lemoer](https://forum.freifunk.net/u/lemoer)\ **Post date:** [13. April 2023 um 20:22 UTC](https://forum.freifunk.net/t/wireguard-serverhardware-testinitiative/23711/5 "2023-04-13T20:22:56Z")
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. ---
**Author:** ![lemoer](https://forum.freifunk.net/letter_avatar_proxy/v4/letter/l/8e8cbc/32.png) [@lemoer](https://forum.freifunk.net/u/lemoer)\ **Post date:** [13. April 2023 um 20:24 UTC](https://forum.freifunk.net/t/wireguard-serverhardware-testinitiative/23711/6 "2023-04-13T20:24:22Z")
> Mit linux als vm Klingt gut. Beschreib dann am besten das Setup ein bisschen. ---
**Author:** ![lemoer](https://forum.freifunk.net/letter_avatar_proxy/v4/letter/l/8e8cbc/32.png) [@lemoer](https://forum.freifunk.net/u/lemoer)\ **Post date:** [13. April 2023 um 22:53 UTC](https://forum.freifunk.net/t/wireguard-serverhardware-testinitiative/23711/7 "2023-04-13T22:53:19Z")
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](https://www.netgate.com/blog/wireguard-in-pfsense-2-5-performance). ---
**Author:** ![Manawyrm](https://forum.freifunk.net/letter_avatar_proxy/v4/letter/m/aeb1de/32.png) [@Manawyrm](https://forum.freifunk.net/u/Manawyrm)\ **Post date:** [22. April 2023 um 21:52 UTC](https://forum.freifunk.net/t/wireguard-serverhardware-testinitiative/23711/8 "2023-04-22T21:52:21Z")
Mal ein paar Benchmarks gemacht: Side 1: ```auto 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: ```auto 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) ```auto [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: ```auto [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: ```auto [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: ```auto [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: ```auto [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: ```auto [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: ```auto [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: ```auto ethtool -K enp10s0f0np0 rx off tx off gso off tso off sg off ``` jegliches Offloading ausgeschaltet, veraendert aber exakt 0 an der Performance. ---
**Author:** ![lemoer](https://forum.freifunk.net/letter_avatar_proxy/v4/letter/l/8e8cbc/32.png) [@lemoer](https://forum.freifunk.net/u/lemoer)\ **Post date:** [24. April 2023 um 22:06 UTC](https://forum.freifunk.net/t/wireguard-serverhardware-testinitiative/23711/9 "2023-04-24T22:06:00Z")
@Manawyrm Danke dir für die interessanten Ergebnisse! Zu wieviel % waren die CPU-Kernne denn etwa ausgelastet? ---
**Author:** ![fmaurer](https://forum.freifunk.net/letter_avatar_proxy/v4/letter/f/439d5e/32.png) [@fmaurer](https://forum.freifunk.net/u/fmaurer)\ **Post date:** [29. April 2023 um 14:37 UTC](https://forum.freifunk.net/t/wireguard-serverhardware-testinitiative/23711/10 "2023-04-29T14:37:05Z")
Testergebnis FFAC: Side 1 und 2 auf verschiedenen baugleichen proxmox hypervisors: ```auto 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 ```auto 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. ```auto 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](https://tailscale.com/blog/more-throughput/) ---
**Author:** ![MrMM](https://forum.freifunk.net/user_avatar/forum.freifunk.net/mrmm/32/328_2.png) [@MrMM](https://forum.freifunk.net/u/MrMM)\ **Post date:** [29. April 2023 um 16:25 UTC](https://forum.freifunk.net/t/wireguard-serverhardware-testinitiative/23711/11 "2023-04-29T16:25:43Z")
> [@fmaurer](#): > > war inkl frischen VMs ne halbe Stunde Aufwand. > Bin aber doch etwas verwundert über die Wireguard performance In der Tat interessant, dass WG so weit unter RAW liegt. @Sirius sollte der Traffic im WG nicht nahezu der Leitungskapazität entsprechen? ---
**Author:** ![lemoer](https://forum.freifunk.net/letter_avatar_proxy/v4/letter/l/8e8cbc/32.png) [@lemoer](https://forum.freifunk.net/u/lemoer)\ **Post date:** [4. Mai 2023 um 18:23 UTC](https://forum.freifunk.net/t/wireguard-serverhardware-testinitiative/23711/12 "2023-05-04T18:23:35Z")
@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! 🙂 ---
**Author:** ![fmaurer](https://forum.freifunk.net/letter_avatar_proxy/v4/letter/f/439d5e/32.png) [@fmaurer](https://forum.freifunk.net/u/fmaurer)\ **Post date:** [4. Mai 2023 um 19:22 UTC](https://forum.freifunk.net/t/wireguard-serverhardware-testinitiative/23711/13 "2023-05-04T19:22:11Z")
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 ---
**Author:** ![awlnx](https://forum.freifunk.net/letter_avatar_proxy/v4/letter/a/57b2e6/32.png) [@awlnx](https://forum.freifunk.net/u/awlnx)\ **Post date:** [12. März 2024 um 07:36 UTC](https://forum.freifunk.net/t/wireguard-serverhardware-testinitiative/23711/14 "2024-03-12T07:36:05Z")
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](https://forum.freifunk.net/uploads/default/original/3X/e/d/ed3de98efd7b85b210e16bdc5fd9e41db5f4b489.svg) ---
**Author:** ![awlnx](https://forum.freifunk.net/letter_avatar_proxy/v4/letter/a/57b2e6/32.png) [@awlnx](https://forum.freifunk.net/u/awlnx)\ **Post date:** [12. März 2024 um 07:57 UTC](https://forum.freifunk.net/t/wireguard-serverhardware-testinitiative/23711/15 "2024-03-12T07:57:20Z")
Hier noch etwas Erklärung zum Thema [https://www.net.in.tum.de/fileadmin/bibtex/publications/theses/2018-pudelko-vpn-performance.pdf](https://www.net.in.tum.de/fileadmin/bibtex/publications/theses/2018-pudelko-vpn-performance.pdf) Eventuell auch einfach ein Bug in Ubuntu > **[Bug #2004145 “Massive (3x) performance regression for WireGuard ...” : Bugs :...](https://bugs.launchpad.net/ubuntu/+source/wireguard/+bug/2004145)** > > I have fully reproducible steps to demonstrate this issue on a vanilla DigitalOcean droplet, minimal WireGuard configuration and no firewall rules. I've also seen this issue on other hosting providers. > > Testing with \`iperf3 -c XXX -P 5\`: > > \-... ---
**Author:** ![fmaurer](https://forum.freifunk.net/letter_avatar_proxy/v4/letter/f/439d5e/32.png) [@fmaurer](https://forum.freifunk.net/u/fmaurer)\ **Post date:** [1. Dezember 2024 um 00:43 UTC](https://forum.freifunk.net/t/wireguard-serverhardware-testinitiative/23711/16 "2024-12-01T00:43:34Z")
Ich habe grade, weil das auf Matrix unter [#freifunk:matrix.org](https://matrix.to/#/#freifunk:matrix.org) ein Thema war, Hardware mit Intel N100 CPU hier auch getestet. Diese Endgeräte haben in der Regel mindestens 2 Gigabit-Ethernets und sind recht stromsparend, eignen sich auch als Home-Server gut. So betreibe ich den auch, deshalb gibt es während den Tests natürlich etwas grundrauschen, schätze ich aber als unerheblich ein. Benutzt wurde ein T-Bao T8 N100 mit 16GB RAM und Proxmox 8.3 als Hypervisor. ### Plain VM, virtio CPU | Type | Speed | | --- | --- | | WG | 1.3 GBit/s | | WG+VXLAN | 1.15 GBit/s | | WG+VXLAN+BATMAN | 0.5 GBit/s | ### Proxmox VM - CPU type=host | Type | Speed | | --- | --- | | WG | 1.8 GBit/s | | WG+VXLAN | 1.3 GBit/s | | WG+VXLAN+BATMAN | 1.08 GBit/s | ### LXC | Type | Speed | | --- | --- | | WG | 2.1 GBit/s | | WG+VXLAN | 1.68 GBit/s | | WG+VXLAN+BATMAN | - GBit/s | Batman klappt in dem LXC container nicht, weil der proxmox kernel 6.8.12-4-pve kein batman-adv module hat. ## Info Die Lehre hieraus ist, dass es sich für supernodes/Gateways lohnt den CPU-Type auf `host` zu ändern (bzw genau genommen mindestens `x86-64-v2-AES` reicht aus).