Gluon: Mauvaises performances VXLAN

Créé le 21 janv. 2018 · 5Commentaires · Source: freifunk-gluon/gluon

Lors du test du maître actuel, j'ai remarqué une baisse significative des performances lors de l'utilisation de VXLAN pour wiremesh au lieu de l'ancienne méthode qui lie l'interface Wiremesh directement à bat0:

Mise à l'essai: TP-Link TL-WDR4300 v1 vs Siemens Futro S550, tous deux connectés au même commutateur compatible GBE, VPN désactivé sur le WDR4300:

Test avec l'ancien Wiremesh:

Initié depuis WDR4300:

root<strong i="10">@ffnoc12</strong>:~# batctl tp -t 10000 a6:07:f9:5a:71:db
Test duration 10010ms.
Sent 382825692 Bytes.
Throughput: 36.47 MB/s (305.95 Mbps)

Initié par Offloader

root<strong i="14">@ffnocoffloader</strong>:~# batctl tp -t 10000 46:3d:e1:c3:7f:63
Test duration 10020ms.
Sent 457679556 Bytes.
Throughput: 43.56 MB/s (365.41 Mbps)

Même test avec VXLAN:

Initié sur WDR:

root<strong i="20">@ffnoc12</strong>:~# uci set network.mesh_wan.legacy='0'
root<strong i="21">@ffnoc12</strong>:~# uci commit network
root<strong i="22">@ffnoc12</strong>:~# /etc/init.d/network restart
root<strong i="23">@ffnoc12</strong>:~# batctl tp -t 10000 a6:07:f9:5a:71:db
Test duration 10020ms.
Sent 30967956 Bytes.
Throughput: 2.95 MB/s (24.72 Mbps)

Initié sur le déchargeur:

root<strong i="27">@ffnocoffloader</strong>:~# batctl tp -t 10000 46:3d:e1:c3:7f:63
Test duration 10110ms.
Sent 47189196 Bytes.
Throughput: 4.45 MB/s (37.34 Mbps)

Pour la prévention des raccourcis de domaine, VXLAN (ou toute option pour authentifier le Wiremesh) est une bonne idée, mais pour les besoins du backbone RF, c'est trop lent.

bug regression

Source

lephisto

Commentaire le plus utile

Cette vérification était avec iperf sur le WDR3600. Cela a évidemment nui aux performances des tests, mais je voulais uniquement tester les performances relatives avec et sans VXLAN, et non le débit maximal possible.

NeoRaider le 26 janv. 2018

👍2

Tous les 5 commentaires

J'ai testé cela avec iperf et batctl tp ; J'ai pu reproduire la baisse de performance extrême avec batctl, mais pas avec iperf (ou plutôt, avec iperf, les performances étaient plutôt mauvaises même en mode hérité). La raison en est la fragmentation: la taille de paquet utilisée par le débitmètre de batctl est choisie de manière à ce qu'elle passe par une liaison de 1500 octets sans fragmentation, mais elle doit être fragmentée sur une liaison de 1430 octets.

Par conséquent, les nombres donnés par iperf sont plus précis pour les scénarios de la vie réelle, car la fragmentation est généralement nécessaire à la fois en mode VXLAN et en mode hérité (ou dans aucun des deux, avec un serrage MSS approprié). J'ai poussé quelques optimisations pour le maillage filaire (2950cc3f596d5565390aaa1188cdb67d2401840b affecte à la fois le mode hérité et le mode VXLAN, a9edd43693a02e0829d04a83a13ebbf0f7eef3ee et e54b37d835624059d005bdb777d835624059d005bdb7 améliorent légèrement les performances de VXBB1). Il y aura également un suivi de 7ae8a511267e7f280862fcd57f8ae394b947b799 dans quelques jours.

Avec tous ces correctifs appliqués (y compris le suivi), j'ai mesuré les nombres suivants avec iperf sur un WDR3600 (en utilisant mon ordinateur portable de l'autre côté) sans serrage MSS:

RX hérité: 96,9 Mbits / s
TX hérité: 107 Mbits / s
VXLAN RX: 56,5 Mbits / s
TX VXLAN: 46,2 Mbits / s

En réduisant le MSS pour éviter la fragmentation, j'obtiens les chiffres suivants:

RX hérité: 164 Mbits / s
TX hérité: 149 Mbits / s
VXLAN RX: 88,5 Mbits / s
TX VXLAN: 74,3 Mbits / s

Donc, VXLAN coûte sans aucun doute des performances, mais il n'est en aucun cas aussi mauvais que batctl tp pourrait le suggérer. Je vais examiner d'autres options d'optimisation (par exemple, ip6tables, qui est responsable d'une partie considérable de la baisse de performance).

NeoRaider le 25 janv. 2018

👍1

avez-vous exécuté iperf sur le wdr3600? si oui, ce test n'était-il pas limité par les performances du processeur utilisé par iperf lui-même?
nous avons toujours fait iperf avec de vraies machines x86 aux deux extrémités, uniquement.
si je suis sur la mauvaise piste, veuillez ignorer :-D

rotanid le 26 janv. 2018

NeoRaider le 26 janv. 2018

👍2

Avec d87a798ac3d1e8cef3d83c22c4482afd21886c34, toutes les optimisations de débit facilement possibles ont été effectuées. Les performances du pare-feu seront revisitées après la prochaine version.

NeoRaider le 16 mars 2018

peut-être pourrions-nous documenter à quel point les performances ont été améliorées par rapport aux mesures effectuées par @lephisto et @NeoRaider en janvier?
ou l'inverse, combien les performances souffrent encore par rapport au maillage hérité.

rotanid le 19 mars 2018

Cette page vous a été utile?

0 / 5 - 0 notes