Bonjour,
Je viens ici soumettre à vos expériences et expertises quelques questions relatives aux débits que j’observe sur ma ligne FTTH 10G Free.
Mon logement est en ZMD AMII Orange (zone 4RD Free donc ?), la Freebox Delta est en mode routeur.
Entre le PC de mesure et la box, il y a 2 switches :
- Un netgear XS508M - relié au PC comme à l’autre switch via RJ45 connecté en 10 Gb/s
- Un netgear MS510TX - relié à la box via DAC SFP+ connecté en 10 Gb/s
Le « PC » de mesure est en réalité un Mac mini (i7 3,2 GHz, 32 Go mémoire, 1 To SSD, macOS 10.15.2 - équipé d’un chip Aquantia AQC107).
Jumbo frames activés (mtu 16k) - mode full duplex avec contrôle de flux (ai essayé sans contrôle également, pas de différence a priori)
Protocole de test : Via script en Crontab, lancement toutes les 10 minutes d’un test iPerf3, sur le serveur paris.testdebit.info ($serveur), en IPv4 puis en IPv6, avec les commandes suivantes:
iperf3 -c $serveur -R -t 20 -O 5 -p $numPort -4 -P 16 -w 4m -f g
iperf3 -c $serveur -R -t 20 -O 5 -p $numPort -6 -P 16 -w 4m -f g
A compter du 15/01/2020 ~17h, suppression de la fenêtre de 4m :
Multithread :
iperf3 -c $serveur -R -t 20 -O 5 -p $numPort -4 -P 16 -f g
iperf3 -c $serveur -R -t 20 -O 5 -p $numPort -6 -P 16 -f g
Monothread :
iperf3 -c $serveur -R -t 20 -O 5 -p $numPort -4 -P 1 -f g
iperf3 -c $serveur -R -t 20 -O 5 -p $numPort -6 -P 1 -f g
(10s de pause entre chaque test, $numPort étant le 1er numéro de port disponible entre 5200 et 5209).
A compter du 29/01/2020 ~22h30, évolution du protocole :
- Mesure d'une durée totale de 8s, dont seules les 4 dernières sont conservées pour le calcul du débit
Multithread :
iperf3 -c $serveur -R -t 4 -O 4 -p $numPort -4 -P 16 -f g
iperf3 -c $serveur -R -t 4 -O 4 -p $numPort -6 -P 16 -f g
Monothread :
iperf3 -c $serveur -R -t 4 -O 4 -p $numPort -4 -P 1 -f g
iperf3 -c $serveur -R -t 4 -O 4 -p $numPort -6 -P 1 -f g
(5s de pause entre chaque test, $numPort étant le 1er numéro de port disponible entre 9200 et 9222).
Ci-joint le graphique correspondant :
Les 2 questions que je me pose :
- Suis-je face à un « plafond de verre » à 7 Gbits/s environ ?
Car je ne dépasse jamais les 7 Gbits/s, tout en stagnant non loin en-dessous une partie de chaque nuit.
A contrario, sur un wget vers le serveur Freebox, je monte à 1,09 Go/s (8,72 Gbits/s) ; ce n’est a priori pas la carte réseau ou le LAN…
Est-ce lié aux paramètres passés à iPerf ?
Faudrait-il augmenter la fenêtre (-w), sachant que le serveur refuse davantage d’après les retours de la commande ?
> Augmenter le parallélisme ne semble plus améliorer, donc je ne pousse pas.
> J’ai essayé de tuner certains paramètres de MacOS (pile TCP…), mais je ne suis pas spécialiste, et, si dans certains cas les performances se sont clairement écroulées, à l’inverse je n’ai pas réussi à obtenir mieux qu’actuellement (peut-être pas trouvé la combinaison optimale…).
Vous auriez des pistes ? d’autres idées ?
EDIT SUITE TESTS : le suivi a montré qu'avec certains algos de gestion de la congestion TCP, je parviens à dépasser les 7 Gb/s et à talonner les 8 Gb/s (solution logicielle, donc).
- Pourquoi les maxima en IPv6 sont inférieurs à l’IPv4 lors des pics IPv4 (à quelques exceptions près - qui semblent prouver que c’est néanmoins théoriquement faisable d'égaler l'IPv4) ?
Et pourquoi ces valeurs se « rejoignent » lorsque les débits sont moindres en IPv4 ?
EDIT SUITE TESTS : Selon l'algo de gestion de la congestions TCP (voire d'autres facteurs), les débits peuvent devenir similaires. Là encore, c'est donc au niveau logiciel qu'on peut agir.
Je sais, je sais. Ce sont des problèmes de riche… Je fais ça par curiosité et intérêt pour l’apprentissage du fonctionnement de tout cela, pas pour me plaindre du Gbit/s qui me manque
Merci d’avance de vos retours d’expérience ! 
EDIT : mise à jour du graphe au 27/01/2020 9h
-
07/02/2020 :
Mise à jour automatisée via génération scriptée avec gnuplot (7 jours glissants - màj horaire)
Graphiques sur fond blanc disponibles tout en bas de ce post.
-
14/02/2020 16h30 :
passage sur une VM Ubuntu + algo BBR côté clientLa machine est un NUC10 i7 10710U ; 32 GB mémoire ; SSD NVMe 1 To
La connectivité 10G est assurée par un Sonnet Solo 10G Thunderbolt 3 édition
La VM est montée sous ESXi (6.7u2), la configuration réseau de VMWare est laissée d'origine.
La MTU est passée à 9000 dans la conf. Ubuntu.
Utilisation de l'algorithme de gestion de la congestion: bbr - via ajout ci-dessous dans /etc/sysctl.conf :
net.core.default_qdisc=fq
net.ipv4.tcp_congestion_control=bbr
-
15/02 9h00: optimisation sysctl.conf : net.core.optmem_max = 268435456
net.core.rmem_default = 212992
net.core.wmem_default = 212992
net.core.rmem_max = 134217728
net.core.wmem_max = 134217728
net.ipv4.tcp_rmem = 4096 87380 134217728
net.ipv4.tcp_wmem = 4096 65536 134217728
net.ipv4.tcp_fastopen = 1
net.ipv4.tcp_tso_win_divisor = 8
-
15/02 11h40 : ajout de l’option -C bbr (BBR côté serveur) aux commandes iperf3 :Multithread :iperf3 -c $serveur -R -t 4 -O 4 -p $numPort -4 -P 16 -f g -C <algo>
iperf3 -c $serveur -R -t 4 -O 4 -p $numPort -6 -P 16 -f g -C <algo>Monothread :iperf3 -c $serveur -R -t 4 -O 4 -p $numPort -4 -P 1 -f g -C <algo>
iperf3 -c $serveur -R -t 4 -O 4 -p $numPort -6 -P 1 -f g -C <algo>où <algo> = bbr-
15/02 15h20 : passage du nom de serveur "paris.testdebit.info" à "bouygues.testdebit.info"
Le premier posait des problèmes de connexion en IPv6 depuis 12h10 (pas de souci en IPv4).
P
asser sur le nom bouygues.testdebit.info a résolu ce souci, bien que ce soit, au bout, le même serveur (
là où une désactivation / réactivation de la connexion réseau, et même un reboot de la VM n'avait rien résolu).
Note 17/02 : la "résolution" ne fut que temporaire : de nouveaux épisodes ont eu lieu le 16/02, entre 13h et 17h puis entre 18h40 et 19h20, ce dernier étant rentré dans l'ordre sans intervention (vu après coup).-
21/02 23h50 : Passage de iPerf 3.6 à iPerf 3.7
-
22/02 0h00 : Passage de la RAM de 4 à 8 Go
Débits fibre Free