Réduire le temps de latence sur une interface réseau

Support Debian
#1

Hello,

Est-ce qu’il y a une possibilité de diminuer la latence lors du passage des paquets sur une/deux interfaces réseau (pont) ? Un moyen d’augmenter la priorité du traitement du réseau au niveau du kernel ?

J’aimerais utiliser un Debian pour faire office de « switch 10gb » mais j’ai remarqué que la latence était presque deux fois plus élevées en passant par mon Debian que via un switch standard.
Est-ce que quelqu’un connait ou s’est déjà intéressé à cela ?
J’ai vu qu’on pouvait toucher à SO_BUSY_POLL mais si quelqu’un a déjà fait quelques essais ce serait intéressant :slight_smile:

Merci d’avance pour vos réponses

#2

Quelles sont les caractéristique de la machine qui héberge ta Debian?

#3

Un processeur 6 coeurs et un autre 2 coeurs, 32 et 16gb de ram mais ce sont de vieux processeur. Je ne pense pas que ca cause trop de problèmes vu qu’elles doivent juste faire office de « pont ».

#4

sauf que tu oublies quand même un point important: les cartes réseaux!! car comment veux tu faire un routeur 10Gb avec des cartes réseaux qui ne sont elles qu’à 1Gb par exemple, si on considère le niveau standard des PC aujourd’hui!!

#5

En rajoutant des cartes PCIe x8 dual port 10Gb par exemple ce qui en fait un switch 10Gb avec un vlan dédié à 1gb ce qui est amplement suffisant pour la configuration.
Il existe aussi des cartes réseaux PCIe quad port 1Gb si je veux rajouter des ports pour des périphériques bas débit tout cela peut être utilisé en LACP afin d’avoir des liens 2Gb mais bon je pense que vous savez tout ça et ce n’est pas vraiment la question.

#6

Je ne voudrais pas te décevoir mais installer des cartes réseau dans un PC n’en fait pas un switch pour autant. Un switch a une architecture matérielle optimisée pour la commutation de trames, ce qui n’est pas le cas d’un PC qui doit faire la commutation en logiciel.

#7

Oui, je sais bien et j’ai testé pour voir la différence de latence entre un switch et un pont sous Debian en standalone. C’est pour ça que je cherche comment optimiser au mieux le kernel pour cet usage.
J’ai vu qu’il y avait des kernels realtime et lowlatency mais peut-être que ce paramètre busy poll peut suffir car il semble avoir de bons résultats d’après les tests trouvés ~ -2 us lorsqu’il est activé.

Un switch a un ASIC dédié mais il n’est pas cadencé à 2ghz donc même si cela prend un peu plus de cycle cela doit permettre de compenser un peu la non optimisation du processeur x64 :slight_smile:

C’est pour ça que je cherche quelqu’un ayant déjà expérimenté la chose, c’est plus simple de pouvoir échanger que de tester tous les paramètres les uns après les autres voir ce qui est le plus efficace sans trop impacter la bande passante ni surcharger le CPU.
Ou s’il y a une distribution dédiée qui prend en compte déjà tous les paramètres plutôt que de partir sur une Debian. Exemple : opnsense

#8

Bonjour,
Une version de debian ne nécessite pas de modifications particulières dans le noyeau pour commuter du 10gbps.

Un test réalisé sur l’interface loopback :

╰─╼ ~ $ » iperf3 -c 127.0.0.1 
Connecting to host 127.0.0.1, port 5201
[  5] local 127.0.0.1 port 57606 connected to 127.0.0.1 port 5201
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec  5.76 GBytes  49.5 Gbits/sec    0   1.25 MBytes       
[  5]   1.00-2.00   sec  5.74 GBytes  49.3 Gbits/sec    0   1.25 MBytes       
[  5]   2.00-3.00   sec  5.99 GBytes  51.4 Gbits/sec    0   1.25 MBytes       
[  5]   3.00-4.00   sec  6.35 GBytes  54.5 Gbits/sec    0   1.25 MBytes       
[  5]   4.00-5.00   sec  5.83 GBytes  50.1 Gbits/sec    0   1.25 MBytes       
[  5]   5.00-6.00   sec  5.72 GBytes  49.2 Gbits/sec    0   1.25 MBytes       
[  5]   6.00-7.00   sec  5.82 GBytes  50.0 Gbits/sec    0   1.25 MBytes       
[  5]   7.00-8.00   sec  5.86 GBytes  50.4 Gbits/sec    0   1.25 MBytes       
[  5]   8.00-9.00   sec  5.65 GBytes  48.5 Gbits/sec    0   1.25 MBytes       
[  5]   9.00-10.00  sec  5.76 GBytes  49.5 Gbits/sec    0   1.31 MBytes       
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec  58.5 GBytes  50.2 Gbits/sec    0             sender
[  5]   0.00-10.04  sec  58.5 GBytes  50.0 Gbits/sec                  receiver

iperf Done.

Donc le noyeau est bien capable de commuter 100 Gbits/sec (50Gbit/s dans un sens, 50Gbit/s dans l’autre en même temps (voir section suivante))

Interfaces                     │ RX bps       pps     %│ TX bps       pps     %
 >lo                           │   5.67GiB 229.67K     │   5.67GiB 229.67K

ainsi que 460k paquets par secondes.

Je pense alors qu’il est inutile de modifier quoi que soit au niveau du noyeau…

Et petite remarque, il est peut-être préférable d’acheter un switch avec un backplane correspondant à ce que tu attend comme débit, cela te coutera moins chère et consommeras moins d’énergie pour fonctionner. Ou bien mettre le prix des cartes réseaux 10gbps que tu compte acquérir.

PS : Test réalisés sur un pc de bureau avec un processeur 4c/8t intel de 2012 et une carte mère avec un chipset z77.

#9

Test non significatif à mon avis.

  • Ce n’est pas de la commutation (trame ethernet), c’est du routage (paquet IP). Et le code de routage du noyau fait des raccourcis pour le trafic émis sur une interface de loopback.

  • Cela ne fait intervenir aucun pilote ni périphérique avec toute la latence associée.

  • C’est le même trafic qui est émis d’un côté et reçu de l’autre, donc il n’y a pas 100 Gbit/s mais 50 Gbit/s.

#10

Eventuellement, ai entendu parler de l’utilisation de DPDK avec Open vSwitch (OVS).

Il semble y avoir un paquet tout fait pour Bullseye / testing : https://packages.debian.org/search?keywords=dpdk

N’ayant pas eu l’occasion de tester cela par moi-même, je serais très intéressé par un éventuel retour sur la question.

–
AnonymousCoward

#11

Effectivement, j’ai mal interpréter certains résultats, et le test est surement biaisé, et je me suis trompé je n’avais pas compris la finalité.

J’ai lu cet article :

Que j’ai trouvé assez inintéressant à propos des ASIC et du fonctionnement des switch.

Je pense quand même qu’il est difficile d’obtenir des performance identiques à un switch avec du matériel PC ordinaire.

A juste titre nings tu a parler d’un ASIC dédié mais qu’il n’était pas cadencé à 2ghz contrairement a un PC, d’après mes recherches, les ASIC dans les switch disposent aussi d’une mémoire cache haute performance pour les paquets reçus ce dont un PC ne dispose pas. Je pense que quoi qu’il arrive, la latence de commutation sur du matériel ordinaire (non-asic) ne permettra pas d’obtenir les résultat de d’un switch. Certe un processeur de PC tourne à une fréquence largement supérieur à un asic de switch, mais il faut prendre en compte plusieurs paramètres après réception de la trame par l’interface physique qui sont expliqués dans cette vidéo.

#12

Oui, il sera très difficile d’obtenir les mêmes performances après je ne suis pas à la ms non plus. C’est bien meilleur marché car une carte dual port 10gb me coûte dans les 30usd et j’en ai déjà 10 à disposition. Il va me manquer des ports PCIe 8x sur les cartes mères avant de les avoir toutes utilisées.

Le problème des switchs 10gb est très simple soit on a de l’unmanaged qui supprime le tag du vlan donc un peu trop basic pour mon utilisation soit on a une gamme pro bien plus cher mais surtout qui ont ces fichus ventilateurs de 20mm. Netgear faisait du bon matos, il y a quelques années avec des switchs full 1gb fanless pour particulier mais avec quelques fonctions comme le lacp, lag, vlan et le vlan management qui permettaient de ne pas intercepter les trames dhcp. Actuellement, ils ont refait leur gamme et il n’y a plus grand chose car il faut aller taper dans la gamme pro alors que je n’ai pas besoin de routage l3 et ces switchs ont des ventilateurs de 2cm qui font un bruit d’enfer donc ce n’est juste plus utilisable dans un foyer. Leur gamme entre la pro et la unmanaged a perdu tellement de fonctionnalités que ça en devient inutilisable malgré que le prix a bien augmenté plus de 50% sans avoir du full 10gb comme à l’époque. Le switch intercepte les trames dhcp de tous les vlans, du coup votre ip public va se retrouver sur votre switch faute de vlan management. Il y a des paquets qui sont drop sans raison car passe via un autre switch avant celui-ci sans problème. Leur support est une catastrophe et c’est à nous d’utiliser notre matériel pour debug leur switch entre deux car ils ont aussi eu la bonne idée de supprimer la partie debug de cette version comme si un particulier allait utiliser cette fonction sauf pour les aider eux…
J’ai donc retourné ces deux switchs peut-être qu’un jour cette marque ou une autre fera quelque chose d’utilisable silencieusement ou avec des ventilos plus large sur la gamme pro :slight_smile:

Je ne veux pas m’amuser à rajouter de l’électronique pour contrôler le courant afin de réduire le bruit sur du matériels neuf à 300usd/pce. L’idée est simple recycler du vieux matériel avec des ventilateurs de 80/120mm tournant à basse vitesse qui ne font pas de bruit et imprimer une tour atx minimaliste où la carte mère va tenir en-dessus de l’alimentation afin de pouvoir mettre ça derrière un meuble. J’ai juste besoin d’un seul lien 2.5/5gb et je le transfère via du lacp 1gb sur des switchs 24 ports. Ca marche parfaitement, il y a juste la latence qui est un peu élevée quand je passe par le pont plutôt que par le switch donc plus qu’à optimiser un petit peu ça.
Ce n’est pas l’idéal au niveau consommation mais je peux désactiver des cores, downclock pour rendre le processeur plus efficace car je ne pense pas avoir besoin de plus de 1/1.5ghz surtout s’il n’y a que ça qui tourne dessus. Il ne fera que passer les paquets d’une interface à une autre des différents vlan.

On peut refaire tourner un linux 100% en ram ?
J’avais trouvé un tuto pour faire tourner une machine en ram à l’époque mais avec une nouvelle version de grub ça ne fonctionnait plus. Il n’acceptait plus de démarrer sur « / » mais c’était top surtout sur ce genre de machine même pas besoin d’un ssd juste un stick usb pour démarrer et copier le système en ram au démarrage.

#13

Je veux bien savoir ou tu T’est procuré des cartes dual port 10gb ethernet ^^ a ce prix la ou du moins avoir la ref

#14

Ensuite, il faut un adaptateur sinon pas compatible PCIe :


Imprimer un bracket avec une imprimante 3d pour pouvoir fixer ça correctement et le tour est joué :slight_smile:
La carte est reconnue et fonctionelle mais je ne l’ai pas encore laissée tourner sur une longue période mais je ne vois pas trop ce qu’il peut y avoir comme problème. Certes cela prend un peu de temps mais ça permet d’avoir du matériel pas trop cher et ça permet d’en faire ce qu’on veut au niveau soft sans aucune limitation grâce à Linux :slight_smile:

#15

C’est un détail mais ce sont des ventilateurs de 40mm. 1 U faisant 44,5mm de haut.

La totalité des switchs L2 auxquels j’ai touché gèrent les VLANs et permettent de ne pas assigner d’adresse IP pour tel ou tel VLAN. Et donc de ne pas chercher d’adresse IP pour le VLAN utilisé pour remplacer ta box opérateur par un routeur fait maison.
Il n’y a pas besoin d’aller chercher du switch L2+ ou L3 pour cela.

Il existe très peu de switchs avec du 10GBASE-T, donc en cuivre. Il y en a bien plus avec des ports SFP+. Ce, pour une raison bien simple.
Le 10 GBASE-T a une consommation électrique très élevée. Alors que c’est plusieurs fois moins en SFP+, suivant si on met de l’optique ou du Direct Attach Copper (DAC).
Voir medium.com - 10GBASE-t VS SFP+ ou encore wavesplitter.com blog .

Il y a aussi la latence qui est énorme avec le 10GBASE-T. Est-ce que les chiffres que tu constates ne viendraient pas de là ?

Je n’ai pas de chiffre à l’appui de mes dires mais le 2Gbps et le 5Gbps sont probablement bien moins énergivores que le 10 et il y a des raisons de croire que l’on verra un jour apparaître de bons switchs passifs sur ces débits.

Conclusion : attendez que de bons switchs 2/5Gbps sortent ou installez un lan fibre chez vous.

(et je dis m… à cette abomination NF C 15-100 et ses RJ45 arrivant dans le tableau électrique !)

–
AnonymousCoward

#16

Tout a fait juste, désolé

J’ai eu des milliers de paquets drop en quelques heures sans raison sur les liens LACP alors que j’en ai jamais ou presque via un switch 1gb en une année même configuration même fabricant le trafic internet passant sur un des vlans était coupé au bout d’un moment sans aucune raison. Le switch écoutant sur tous les vlans sans vlan management prenait très certainement l’ip public pour lui ou l’interceptait sans retransmettre les requêtes dhcp ou il y avait tellement d’erreurs que le lien tombait, je ne sais pas honnêtement surtout que je n’ai même pas essayé de passer en 10gb. Le vlan avec le LAN ne tombait pas pourtant lorsque le vlan internet tombait alors que tout passait par les mêmes câbles. Ce switch m’a pris une IP du vlan wifi alors que ce vlan était juste passant entre deux uplink :slight_smile:

C’est tout à fait possible que la latence soit plus élevée en 10gb mais ça me semblait un peu élevé surtout en passant par un seul pont si je double et qu’il fait l’aller retour cela me rajoute 4x cette latence ce qui me semblait un peu élevé après ce n’est pas bien grave non plus l’essentiel est de pouvoir passer du 2x 1gb.
J’ai pas mal cherché pour trouver un switch 10gb en fanless mais rien trouvé à part celui que j’ai pris qui semblait bien mais il y a soit un souci au niveau du soft ou c’est vraiment du bas de gamme mais j’ai été très déçu de trouver une interface avec si peu de fonctions pour ce prix surtout que les anciens étaient moins cher avec toutes les fonctions nécessaires sans aucun bug. Le support a dit qu’il ne fallait pas faire transiter un vlan avec ip public à travers ce switch et qu’il fallait prendre la gamme pro réponse bateau habituel d’un support. Il n’y a toujours pas de nouveaux firmwares donc ils n’ont juste rien fait pour tenter de corriger ce bug mais en gros, c’est au client de débugguer leur switch en allant voir les logs sur les autres équipements car eux ne font rien.

Je ne peux plus tirer la fibre, ce n’est plus possible de changer le câblage maintenant. Je vais essayer de faire tourner ça et on verra bien ce que ça donne. Ca m’intéresse aussi de tester linux de cette façon :slight_smile:
Je n’ai encore jamais rencontré aucune limitation sous linux et ça ne semble pas être pour cette fois.

#17

salut, excuse de me mêler à la conversation mais je n’ai pas compris, peux tu donner un exemple sur une config cisco pas exemple?

J’ai du mal avec cette position car sauf si tu parles d’installation de l’épine dorsale du réseau domestique en fibre je n’en vois pas l’intérêt ailleurs. La fibre est fragile, dangereuse à installer (lors de la coupe et de l’épissure) et chère (requiert un matos cher pour l’installation). Sans parler des contraintes d’installation spécifiques à la fibre)

Je viens de voir ca et je suis d’accord avec toi à 100% que vient foutre ce coffret communication…

#18

On s’éloigne du sujet Debian mais cela m’intéresserait de connaître la référence du switch en question.

J’utilise une paire de TP-Link T1700G-28TQ v3 mis en stack et, si l’appareil n’est pas parfait (pas de GVRP, pas de RA guard, pas de console série vu que c’est du « smart »), c’est du fanless avec 4 ports SFP+ et je n’ai pas rencontré de problèmes aussi horribles que ce que tu décris.
Le prix de l’appareil étant très bas pour un switch L2+ comparativement à la conccurence.

–
AnonymousCoward

#19

N’ayant pas de Catalyst qui traîne à la maison, ce ne sera que du Cisco SG :

$ ssh 192.168.0.25



User Name:cisco
Password:*****************


switch458f00#
switch458f00#show vlan
Created by: D-Default, S-Static, G-GVRP, R-Radius Assigned VLAN, V-Voice VLAN

Vlan       Name           Tagged Ports      UnTagged Ports      Created by
---- ----------------- ------------------ ------------------ ----------------
 1           1                             gi2-6,gi8,Po1-4          D 
 11         LAN               gi8                gi1                S
100         BT               gi7-8                                  S
4093       4093                                                     S

switch458f00#
switch458f00#show ip interface


    IP Address        I/F    I/F Status  Type   Directed  Prec Redirect Status
                             admin/oper         Broadcast
------------------ --------- ---------- ------- --------- ---- -------- ------
192.168.0.25/24    vlan 11   UP/UP      DHCP    disable   No   enable   Valid

switch458f00#

Et pour l’interface web, c’est encore plus explicite. Pour chaque VLAN, on peut choisir de ne pas activer IP, d’activer IP en DHCP ou IP en statique.

–
AnonymousCoward

#20

:worried:

Donc pas d’

ip default gateway xxx.xxx.xxx.xxx

?