Auteur Sujet: FTTH 10G Free: Mesure de débit automatisé avec iPerf3 en IPv4 vs IPv6 (Lu 75720 fois)

Breizh29 · « **Réponse #192 le:** 28 janvier 2020 à 20:50:50 »

Reparti depuis un peu avant 20h40 environ.

vivien · « **Réponse #193 le:** 28 janvier 2020 à 21:37:51 »

Désolé.

Grosse modif :

$ iperf3 -v
iperf 3.7 (cJSON 1.5.2)
Linux 5.3.0-26-generic #28~18.04.1-Ubuntu SMP Wed Dec 18 16:40:14 UTC 2019 x86_64
Optional features available: CPU affinity setting, IPv6 flow label, SCTP, TCP congestion algorithm setting, sendfile / zerocopy, socket pacing, authentication

Citation de: vivien le 28 janvier 2020 à 21:42:27

Lignes de commande pour installer iPerf 3.7 sur Ubuntu / Debian

- Ubuntu 64 bits / Debian 64 bits / Mint 64 bits (AMD64) :

sudo apt remove iperf3 libiperf0
sudo apt install libsctp1
wget https://iperf.fr/download/ubuntu/libiperf0_3.7-3_amd64.deb
wget https://iperf.fr/download/ubuntu/iperf3_3.7-3_amd64.deb
sudo dpkg -i libiperf0_3.7-3_amd64.deb iperf3_3.7-3_amd64.deb
rm libiperf0_3.7-3_amd64.deb iperf3_3.7-3_amd64.deb

- Ubuntu 32 bits / Debian 32 bits / Mint 32 bits (i386) :

sudo apt remove iperf3 libiperf0
sudo apt install libsctp1
wget https://iperf.fr/download/ubuntu/libiperf0_3.7-3_i386.deb
wget https://iperf.fr/download/ubuntu/iperf3_3.7-3_i386.deb
sudo dpkg -i libiperf0_3.7-3_i386.deb iperf3_3.7-3_i386.deb
rm libiperf0_3.7-3_i386.deb iperf3_3.7-3_i386.deb

$ cat /proc/sys/net/ipv4/tcp_congestion_control
cubic

$ cat /proc/sys/net/ipv4/tcp_allowed_congestion_control
reno cubic bbr

Cubic est l'algorithme de congestion TCP par défaut.
Vous pouvez choisir reno ou bbr

J'ai essayé de proposer htcp et illinois, mais cela ne fonctionne pas. Pour faire la chose proprement, j'ai crée un fichier /etc/modules-load.d/tcp_allowed_congestion_control.conf dans lequel je charge les 3 algorithme à proposer.

sudo nano /etc/modules-load.d/tcp_allowed_congestion_control.conf

Code: [Sélectionner]

# TCP congestion control protocol
# cat /proc/sys/net/ipv4/tcp_allowed_congestion_control
tcp_bbr
tcp_htcp
tcp_illinois

Seul bbr est rendu disponible par mon fichier

Pourtant, les fichiers .ko sont bien présents :

# locate tcp_bbr /lib/modules/5.3.0-24-generic/kernel/net/ipv4/tcp_bbr.ko /lib/modules/5.3.0-26-generic/kernel/net/ipv4/tcp_bbr.ko # locate tcp_htcp /lib/modules/5.3.0-24-generic/kernel/net/ipv4/tcp_htcp.ko /lib/modules/5.3.0-26-generic/kernel/net/ipv4/tcp_htcp.ko # locate tcp_illinois /lib/modules/5.3.0-24-generic/kernel/net/ipv4/tcp_illinois.ko /lib/modules/5.3.0-26-generic/kernel/net/ipv4/tcp_illinois.ko

Si vous avez une idée pour proposer htcp et illinois, je suis preneur.

vivien · « **Réponse #194 le:** 28 janvier 2020 à 21:57:35 »

Autre changement important pour vos scripts :

Les ports d'écoute changent pour plusieurs raisons (Apache va prendre la place des ports 5200 à 5209, pour disPorts, un test qui test tous les ports du port 1 au port 9199)

J'en ai profité pour rajouter des ports d'écoute à iPerf3 pour éviter de se retrouver avec les ports qui sont tous utilisés.

Les ports à utiliser sont les ports 9200 à 9222

A la fin du mois de janvier, iPerf3 n'écoutera plus sur les ports 5200 à 5209.

Breizh29 · « **Réponse #195 le:** 29 janvier 2020 à 11:39:17 »

OK, je mettrai à jour le paramétrage du script asap.

Sinon, est-il possible d'installer un serveur goben à des fins d'expérimentation et de comparaison ? (on peut le limiter à certaines IP clientes pour le moment, si crainte au niveau sécurité)

vivien · « **Réponse #196 le:** 29 janvier 2020 à 13:10:43 »

C'est plus compliqué car j'administre ces serveurs hébergés par Bouygues Telecom dans un cadre définit.

Optimiser, mettre à jour => Oui

Rajouter un nouveau logiciel, c'est plus compliqué.

Breizh29 · « **Réponse #197 le:** 29 janvier 2020 à 14:59:32 »

Bon, je ne sais pas s'il s'agit d'un ~~bug lié à la version d'iPerf3 installée~~, ou tout autre chose (changement dans la chaîne de retour que je parse), mais depuis peu, j'ai certaines valeurs de débits qui sont retournées mal formatées.

Exemples :

28/01/2020 22:10:00 ; 57614 ; 5,48 ; 2,37 ; 2,07
29/01/2020 05:20:00 ; 62390 ; 7,18 ; 7,13 ; 6,97
29/01/2020 14:20:00 ; 5,67 ; 64108 ; 0,56 ; 0,69

Ça a commencé à partir de 21h30 environ hier soir (4 cas depuis).
Faut que j'analyse ça.

EDIT : ok - il y a du changement dans le retour de la commande dans le cas multithread, dans certaines conditions. Adaptation du script nécessaire...

vivien · « **Réponse #198 le:** 29 janvier 2020 à 15:56:16 »

Tu as du changement sans changer la version que tu utilises ?

Lesquels ?

Au passage, tu utilises quelle version sur ton mac ?

Breizh29 · « **Réponse #199 le:** 29 janvier 2020 à 16:39:48 »

Effectivement, je n'ai rien changé côté client, et j'observe un changement de comportement, a priori depuis la màj côté serveur (à confirmer)
Tout ce que je sais pour l'instant, c'est que je ne récupère plus la "bonne" ligne, dans certains cas en multithread.
Je n'ai pas tous les éléments pour analyser pour le moment.

EDIT : iperf 3.7 (cJSON 1.5.2)

vivien · « **Réponse #200 le:** 29 janvier 2020 à 20:46:26 »

Version 3.7, c'est parait. Cela serait bien de tester deux algorithmes de congestion TCP en lançant le script :
- Monothread Cubic
- Multithread Cubic
- Monothread BBR
- Multithread BBR

L'option -C bbr devrait forcer bbr.
On devrait vite être fixé si elle permet bien de changer l'algorithme coté serveur, vu les différence de perf.

iperf3 prévient si l'algorithme choisit n'est pas disponible :

Code: [Sélectionner]

$ iperf3 -c paris.testdebit.info -R -i 1 -t 4 -p 9221 -C illinois
Connecting to host paris.testdebit.info, port 9221
Reverse mode, remote host paris.testdebit.info is sending
iperf3: error - unable to set TCP_CONGESTION: Supplied congestion control algorithm not supported on this host

$ iperf3 -c paris.testdebit.info -R -i 1 -t 4 -p 9221 -C bbr
Connecting to host paris.testdebit.info, port 9221
Reverse mode, remote host paris.testdebit.info is sending
[  5] local 192.168.0.20 port 32990 connected to 89.84.1.186 port 9221
[ ID] Interval           Transfer     Bitrate
[  5]   0.00-1.00   sec  12.6 MBytes   105 Mbits/sec                  
[  5]   1.00-2.00   sec  11.4 MBytes  95.4 Mbits/sec                  
[  5]   2.00-3.00   sec  11.4 MBytes  95.4 Mbits/sec                  
[  5]   3.00-4.00   sec  11.4 MBytes  95.4 Mbits/sec                  
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-4.02   sec  53.6 MBytes   112 Mbits/sec    0             sender
[  5]   0.00-4.00   sec  46.7 MBytes  97.9 Mbits/sec                  receiver

iperf Done.

Je serais partant d'optimiser au passage les ressources serveur que tu consomme. Aujourd'hui chaque test dure 20 secondes. Je propose de réduire un peu.

L'option -O d'iPerf3 pour ne pas prendre en compte le slow start. -O 4 permet de ne pas prendre en compte les 4 premières secondes du test dans le débit moyen. On est large en prenant 4 secondes, normalement la montée en débit est plus courte avec une seule connexion TCP. Le fait de mettre plusieurs connexion TCP en parallèle fait que cela va monter plus vite.

Limiter le test (-t) à 4 secondes est suffisant, il y a très peu de gain à faire plus de 4 secondes. Les tests sont quand même très impactant pour le serveur.

Dans mon hypothèse (-t 4 et -O 4), le débit moyen serait calculé entre la 4ème et la 8ème seconde du test.
4 seconde c'est largement suffisant pour avoir une donnée fiable.

Breizh29 · « **Réponse #201 le:** 29 janvier 2020 à 22:14:10 »

J’ai commencé les changements.
A ma connaissance, pas d’option « C » (ou autre) permettant de spécifier un algo de gestion de congestion TCP sur la version MacOS d’iperf3.
Et rien trouvé sur le man d’iperf3.

A compter de 22h10 ce jour, mise à jour du protocole :

- 1er port disponible entre 9200 et 9222
- Test au total de 8s, dont seules les 4 dernières sont prises en compte dans le calcul

Si tout se passe bien, je ferai donc débuter une nouvelle série de graphiques à compter de minuit ce jour.

vivien · « **Réponse #202 le:** 30 janvier 2020 à 09:37:38 »

L'option ne fonctionn pas sur Mac ou Windows, mais pour le trafic descendant, c'est coté serveur donc Linux => J'aurais aimé qu'un mac puisse demander à mon Linux de changer.

L’option -C "-C, --congestion algo Set the congestion control algorithm (Linux and FreeBSD only). An older --linux-congestion synonym for this flag is accepted but is deprecated." est dans la partie "CLIENT SPECIFIC OPTIONS" il est donc pour moi impossible de mettre sur certains ports du Cubic et sur certains ports du BBR.

Ce que ne dit pas la documentation, c'est si l'utilisation de l'option -C sur le client change uniquement l'algorithme coté client ou coté client et coté serveur.

J'ai l'impression que c'est bien des deux cotés :

Il faut qu'il se connecte au serveur pour refuser :

Code: [Sélectionner]

$ iperf3 -c paris.testdebit.info -R -i 1 -t 4 -p 9221 -C illinois
Connecting to host paris.testdebit.info, port 9221
Reverse mode, remote host paris.testdebit.info is sending
iperf3: error - unable to set TCP_CONGESTION: Supplied congestion control algorithm not supported on this host

Si pas de connexion, pas de refus :

Code: [Sélectionner]

$ iperf3 -c paris.testdebit.info -R -i 1 -t 4 -p 9221 -C illinois
Connecting to host paris.testdebit.info, port 9221
Reverse mode, remote host paris.testdebit.info is sending
[  5] local 178.248.208.44 port 49322 connected to 89.84.1.186 port 9221
iperf3: error - control socket has closed unexpectedly

C'est pas encore super sec, cela entraîne des plantage coté serveur le changement d'alogo.

Sinon on voit clairement la baisse de trafic suite à ta modification : (chaque point est une moyenne sur 5 minute)

vivien · « **Réponse #203 le:** 02 février 2020 à 16:19:30 »

J'ai fais le changement sur tous les serveurs que je gère vendredi 31 janvier vers 22h30 : On est passé d'Illinois à Cubic.

Je ferais une comparaison des deux dernières semaines de janvier avec les deux premières semaines de février sur les serveurs nPerf (tests multithread) et 5G Mark (tests monothread)

Concernant iPerf3, il est mis à jours en version 3.7 sur tous les serveurs et il écoute sur les nouveaux ports (9200 à 9222). J'ai laissé les anciens ports pour quelques jours pour faire une transition plus facile.