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

Breizh29 · « **Réponse #84 le:** 15 janvier 2020 à 13:43:27 »

Voici quelques chiffres avant / pendant / après ton intervention :

15/01/2020 11:10:00 ; 6,19 ; 5,75
15/01/2020 11:20:00 ; 6,19 ; 5,81
15/01/2020 11:30:00 ; 6,27 ; 5,79
15/01/2020 11:40:00 ; 6,27 ; 5,80
15/01/2020 11:50:00 ; 6,18 ; 5,75
15/01/2020 12:00:00 ; 6,08 ; 5,74
15/01/2020 12:10:00 ; 4,29 ; 4,19 <== début supposé
15/01/2020 12:20:00 ; 3,83 ; 3,89
15/01/2020 12:30:00 ; 4,20 ; 3,88
15/01/2020 12:40:00 ; 3,62 ; 3,80
15/01/2020 12:50:00 ; 3,64 ; 3,82
15/01/2020 13:00:00 ; 5,79 ; 5,44 <== 1ere mesure après intervention
15/01/2020 13:10:01 ; 6,02 ; 5,63
15/01/2020 13:20:00 ; 5,89 ; 5,61
15/01/2020 13:30:00 ; 5,99 ; 5,39
15/01/2020 13:40:00 ; 5,70 ; 5,36

vivien · « **Réponse #85 le:** 15 janvier 2020 à 14:07:27 »

Merci,

Demain je pense tester une dernière optimisation : passer initcwnd de 10 à 90

La modification passe par une commande ip route :
ip route change default via IP_GATEWAY dev INTERFACE_NAME onlink initcwnd 90

J'ai toutefois peur que cette valeur fasse éclater les buffers (les paquets sont perdus et doivent être retransmis) pour certaines connexions, quand il y a moins de 135 Ko de buffers.
Avec le bufferBloat on cherche a réduire la taille des buffers et aujourd'hui ils sont optimisés pour un initcwnd de 10.
Augmenter trop la valeur pour faire chuter le débit.

Je veux bien votre avis.

Historiquement, le passage de 1 à 3 a été proposé en septembre 1998, par la RFC 2414 qui a suggéré l'expérimentation d'une fenêtre initiale de 2-4 MSS et mis en place avec la RFC 3390 en octobre 2002.

En décembre 2010 plusieurs proposition ont proposés de passer de 3 à 10. Cela a été mis en place par défaut dans Linux 2.6.39 avait fait l'effet d'une bombe : A l'époque Google disait que "Dans l'ensemble, plus de 90% des connexions clientes ont une fenêtre de réception suffisamment grande pour tirer pleinement parti de l'utilisation de init cwnd = 10 segments." Qu'en est-il en 2019 ? Une taille plus important est-elle pertinente ?

Citation de: vivien le 27 octobre 2011 à 16:12:35

Patch Google ou "TCP Initial Congestion Window" à 10

J'ai pense avoir trouvé l'explication à gain de débit avec le noyaux linux récents coté serveur :

Les réglages par défaut de la pile TCP du noyau ont été modifiés le noyeau linux 2.6.39 et suivant.
C'est un patch proposé par Google research consistant a passer la "TCP Initial Congestion Window" de 3 à 10

Google research à publié en juillet 2010 un PDF An Argument for Increasing TCP’s Initial Congestion Window.
La RFC datait de 2002 : RFC Increasing TCP's Initial Window - October 2002

Le protocole TCP spécifie un algorithme spécial pour découvrir le débit maximum que supporte une connexion. Cet algorithme, nommé « slow start », va commencer par envoyer très peu de données et va progressivement augmenter la cadence jusqu'à la saturation du lien. C'est bien pratique d'avoir ainsi un fonctionnement qui s'adapte aux conditions réelles du réseau... Comme l'indique le nom « slow start », on va commencer en douceur et la fenêtre de congestion (initial congestion window) est très petite au début de la connexion. La limite est de 3 segments pour les noyaux 2.6.38 et inférieurs, ce qui correspond environ à 4 Ko.

Google à publié un graphe que j'ai commenté en bleu pour le rendre un peu plus lisible :

Si la durée de connexion fait mois de 3 segments, pas de souci.

Si la durée de connexion fait plus plus de 3 segments, le serveur va attendre un acquittement avant d'envoyer plus de données, ce qui fait perdre du temps si la connexion à un haut débit ou une forte latence. (Si la connexion à un haut débit et une forte latence, le gain sera encore plus important vu que les 3 segments seront transmis immédiatement et qu'il faudra attendre pour le transfert de l'acquittement).

Google préconise d'augmenter la taille de la "TCP’s Initial Congestion Window" de 3 (valeur par défaut pour tous les système d'exploitation suivant la RFC 3390 qui date de 2002) à 10 segments, afin de profiter des gain qu'on subit les réseaux ces 9 dernières années.

La figure 1 montre que la 80% des requêtes à une recherches Google font entre 3 et 10 segments. Le gain (figure 2) sur une recherche google est intéressant et on a dans certains cas 20% de gain (cf pdf de l'étude). Le gain moyen serait d'environ 10% de gain de temps de latence d'une requête HTTP.

Comment expliquer que sur un fichier de 1 gigabit, le gain soit si élevé alors qu'il dépasse largement les 10 segments ?

J'ai remarqué que la monté en débit dépend fortement du ping (normal). Le fait d'avoir une TCP’s Initial Congestion Window va permettre une montée en débit beaucoup plus rapide et le gain ne se limite pas aux 10 premiers segments. En fait la TCP’s Initial Congestion Window ferait comme une baisse de ping et permettrais d'être beaucoup plus agressif sur la monté en débit et pas uniquement sur les 10 premiers segments :

Je trouve tout de même étonnant qu'une modification censée améliorer le débit de transfert des petits fichiers offre un gain sur la monté en débit encore plus important pour les gros fichiers dans le cas de très haut débit.

Breizh29 · « **Réponse #86 le:** 15 janvier 2020 à 14:44:37 »

Question au-delà de ton dernier essai de demain.

On a vu que les impacts de l'algo de gestion de la congestion sont importants :
- illinois est plutôt dans la stabilité (on ne monte jamais au max, mais on ne descend pas trop non plus)
- cubic permet des débits très élevés mais plonge très bas dès que la congestion est présente
- bbr a tout de suite fait plonger les débits (on peut refaire des essais sur un temps plus long si tu le souhaites, mais il faudrait anticiper des optimisations s'il en existe, car sinon c'est la cata)
- autre ?

Y a-t-il des pistes restant à approfondir de ce côté ?

vivien · « **Réponse #87 le:** 15 janvier 2020 à 14:53:14 »

Je pense repasser sur BBR puis Cubic une fois les jours suivants (et dés demain si vous ce n'est pas une bonne idée d'augmenter l'initcwnd à 90).

Le gros travail qu'il reste, c'est bien le choix de l'algorithme de congestion TCP. Il n' ya pas de réponse mathématique, pas d'étude complète comparant les 3 avec des débits de 10 Gb/s,...

- BBR sensé être l'algorithme miracle.
- Illinois, l'algorithme qui était souvent proposés pour des très haut débit
- Cubic l'algorithme par défaut de presque tous les Linux.

On a vu avec tes test que ce n'est pas si simple.

kgersen · « **Réponse #88 le:** 15 janvier 2020 à 15:27:20 »

optimiser le serveur pour un mac qui nécessite 16 flux pour atteindre 8G n'est absolument pas la bonne approche. C'est que mon avis bien sur

Ce que je ferais:

qdisc = inutile en mono usage, laisser le pfifo_fast par default
algo: cubic ou bbr, le reste est obsolete dans ce contexte (= serveur speedtest haut debit, faible latence (<20ms))). Bien mettre IPerf3 3.7 a jour. Je rappel que le client (hors Mac/Windows) peut choisir l'algo donc pour faire des benchs comparatifs des algos il faut un client Linux pas un Mac...

Passer le serveur sur une distrib moderne non généraliste et avec rolling update. (pas obligé).

Idéalement utiliser FreeBSD d'ailleurs pour le max de perf y'a pas mieux.

Linux c'est bien pour LAMP et faire joujou.

Éventuellement mettre les buffers a 16Mo max si ce n'est deja pas le cas.

Ignorer tous les écrits, blogs, avis, etc qu'on trouve sur le Net et qui ont plus de 2 ans ou sont des copier/coller de trucs qu'on plus de 2 ans.

Trouver plus de monde en 10G pour tester en boucle comme fait Breizh29 mais avec des client Linux.

On n'a aucune visibilité sur ce qui se passe avec IPerf3 (pas de courbe détaillant un test, ni le taux d'erreurs, etc).
-> collecter des données détaillées coté serveur (par test pas la moyenne).

IPerf3 n'est pas forcement le mieux:
-> mettre en place un serveur goben sur la meme machine.

Exemple:

Goben:

Code: [Sélectionner]

$goben -hosts pox-4.nspeed.app -passiveClient
...
2020/01/15 15:15:55 handleConnectionClient: starting TCP 0/1 195.154.113.23:8080
2020/01/15 15:15:55 handleConnectionClient: options sent: {2s 10s 50000 50000 false 0 map[]}
2020/01/15 15:15:55 handleConnectionClient: TCP ack received
2020/01/15 15:15:55 clientReader: starting: 0/1 195.154.113.23:8080
2020/01/15 15:15:57 0/1  report   clientReader rate:    925 Mbps   3931 rcv/s
2020/01/15 15:15:59 0/1  report   clientReader rate:    928 Mbps   7880 rcv/s
2020/01/15 15:16:01 0/1  report   clientReader rate:    934 Mbps   3962 rcv/s
2020/01/15 15:16:03 0/1  report   clientReader rate:    935 Mbps   4007 rcv/s
2020/01/15 15:16:05 handleConnectionClient: 10s timer
2020/01/15 15:16:05 workLoop: 0/1 clientReader: read tcp 192.168.1.3:47824->195.154.113.23:8080: use of closed network connection
2020/01/15 15:16:05 0/1 average   clientReader rate:    931 Mbps   4762 rcv/s
2020/01/15 15:16:05 clientReader: exiting: 0/1 195.154.113.23:8080
2020/01/15 15:16:05 195.154.113.23:8080 input:
 935 ┤                                                               ╭─────
 934 ┤                                             ╭─────────────────╯
 933 ┤                                         ╭───╯
 932 ┤                                     ╭───╯
 931 ┤                                 ╭───╯
 930 ┤                             ╭───╯
 930 ┤                         ╭───╯
 929 ┤                    ╭────╯
 928 ┤             ╭──────╯
 927 ┤     ╭───────╯
 926 ┼─────╯
        Input Mbps: 195.154.113.23:8080 Connection 0
2020/01/15 15:16:05 handleConnectionClient: closing: 0/1 195.154.113.23:8080
2020/01/15 15:16:05 aggregate reading: 931 Mbps 4762 recv/s
2020/01/15 15:16:05 aggregate writing: 0 Mbps 0 send/s

IPerf3:

Code: [Sélectionner]

$iperf3 -4 -c pox.nspeed.app -R -V --get-server-output
iperf 3.7
Linux xxxxxx 5.4.8-arch1-1 #1 SMP PREEMPT Sat, 04 Jan 2020 23:46:18 +0000 x86_64
Control connection MSS 1448
Time: Wed, 15 Jan 2020 14:18:50 GMT
Connecting to host pox.nspeed.app, port 5201
Reverse mode, remote host pox.nspeed.app is sending
      Cookie: xxxxxxxxxxxxxxxxxxxxxx
      TCP MSS: 1448 (default)
[  5] local xxxxxxxxx port 47988 connected to 195.154.113.23 port 5201
Starting Test: protocol: TCP, 1 streams, 131072 byte blocks, omitting 0 seconds, 10 second test, tos 0
[ ID] Interval           Transfer     Bitrate
[  5]   0.00-1.00   sec   101 MBytes   849 Mbits/sec
[  5]   1.00-2.00   sec  95.0 MBytes   797 Mbits/sec
[  5]   2.00-3.00   sec  92.2 MBytes   773 Mbits/sec
[  5]   3.00-4.00   sec  98.9 MBytes   830 Mbits/sec
[  5]   4.00-5.00   sec  88.7 MBytes   744 Mbits/sec
[  5]   5.00-6.00   sec   106 MBytes   893 Mbits/sec
[  5]   6.00-7.00   sec  95.3 MBytes   799 Mbits/sec
[  5]   7.00-8.00   sec  95.0 MBytes   797 Mbits/sec
[  5]   8.00-9.00   sec  98.0 MBytes   822 Mbits/sec
[  5]   9.00-10.00  sec  94.2 MBytes   790 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
Test Complete. Summary Results:
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.01  sec   968 MBytes   812 Mbits/sec   32             sender
[  5]   0.00-10.00  sec   965 MBytes   810 Mbits/sec                  receiver
snd_tcp_congestion cubic
rcv_tcp_congestion bbr

Server output:
-----------------------------------------------------------
Server listening on 5201
-----------------------------------------------------------
Accepted connection from 176.185.233.60, port 47986
[  5] local 195.154.113.23 port 5201 connected to xxxxxxxxx port 47988
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec   105 MBytes   878 Mbits/sec   14    509 KBytes
[  5]   1.00-2.00   sec  95.0 MBytes   796 Mbits/sec    0    638 KBytes
[  5]   2.00-3.00   sec  91.2 MBytes   766 Mbits/sec    3    557 KBytes
[  5]   3.00-4.00   sec  98.8 MBytes   828 Mbits/sec    3    475 KBytes
[  5]   4.00-5.00   sec  88.8 MBytes   744 Mbits/sec    0    601 KBytes
[  5]   5.00-6.00   sec   106 MBytes   891 Mbits/sec    0    727 KBytes
[  5]   6.00-7.00   sec  96.2 MBytes   807 Mbits/sec    6    624 KBytes
[  5]   7.00-8.00   sec  95.0 MBytes   797 Mbits/sec    3    536 KBytes
[  5]   8.00-9.00   sec  97.5 MBytes   818 Mbits/sec    0    660 KBytes
[  5]   9.00-10.00  sec  93.8 MBytes   786 Mbits/sec    3    570 KBytes
[  5]  10.00-10.01  sec  1.25 MBytes  2.12 Gbits/sec    0    573 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.01  sec   968 MBytes   812 Mbits/sec   32             sender

iperf Done.

-> le meme client, le meme serveur, Goben arrive au max mais pas IPerf3. donc c'est aussi une question de logiciel de test pas que de réglage serveur.

Breizh29 · « **Réponse #89 le:** 15 janvier 2020 à 15:34:10 »

Hmmmmm..... On fait aussi avec ce qu'on a, hein !
Je n'ai jamais prétendu que mon setup permettait d'étalonner de manière scientifique un serveur de speedtest...

Et d'ailleurs ce n'était pas du tout l'objectif ... j'aurais aimé comprendre pourquoi mon setup ne permettait pas d'atteindre le max, je n'imaginais pas aboutir à une remise en question du serveur de speedtest lui-même. Je n'ai rien contre aider, au contraire, mais si ça le fait pas, suffit de me le dire, et je me retire respectueusement

vivien · « **Réponse #90 le:** 15 janvier 2020 à 15:41:09 »

J'avais l'habitude de faire aussi des optimisation sur des test monothread, cela change un peu.

Citation de: kgersen le 15 janvier 2020 à 15:27:20

Éventuellement mettre les buffers a 16Mo max si ce n'est deja pas le cas.

Quels buffers ?

Citation de: kgersen le 15 janvier 2020 à 15:27:20

qdisc = inutile en mono usage, laisser le pfifo_fast par default

pfifo_fast c'est le défault pour Ubuntu server 16.04

Avec Ubuntu server 18.04, c'est fq_codel
Et je cite :

Citation de: kgersen le 07 janvier 2020 à 16:56:33

(le qdisc est optionnel depuis le kernel 4.13 mais autant mettre fq dans des machines d'extrémités (serveur, client) plutot que fq_codel le défaut plutôt utile sur routeur).

Citation de: kgersen le 15 janvier 2020 à 15:27:20

Bien mettre IPerf3 3.7 a jour.

Oui, c'est dans ma todo liste à court terme.

kgersen · « **Réponse #91 le:** 15 janvier 2020 à 15:44:43 »

Quand DamienC sera de la partie ca sera plus clair deja.

Citation de: Breizh29 le 15 janvier 2020 à 15:34:10

Je n'ai rien contre aider, au contraire, mais si ça le fait pas, suffit de me le dire, et je me retire respectueusement

non au contraire c'est bien d'avoir un Mac. C'est juste qu'il ne faut pas forcement chercher a 'tuner' le serveur pour un seul Mac.

Ce qu'il manque de ton coté c'est une 2eme courbe sans le -P 16 pour voir le comportement en mono flux au fil de la journée et idéalement une courbe avec la valeur de Retr.

vivien · « **Réponse #92 le:** 15 janvier 2020 à 15:50:48 »

Citation de: kgersen le 15 janvier 2020 à 15:44:43

Ce qu'il manque de ton coté c'est une 2eme courbe sans le -P 16 pour voir le comportement en mono flux au fil de la journée et idéalement une courbe avec la valeur de Retr.

+1 le débit mono-thread est vraiment intéressant à avoir. (cela nécessite deux autres tests iPerf3)

kgersen · « **Réponse #93 le:** 15 janvier 2020 à 15:54:33 »

Citation de: vivien le 15 janvier 2020 à 15:41:09

Quels buffers ?

Les net.core.wmem_max et autres tcp_wmem mais je crois que c'est déjà le cas sur ton serveur.

vivien · « **Réponse #94 le:** 15 janvier 2020 à 15:58:05 »

J'ai ça actuellement :

Code: [Sélectionner]

# Increase TCP buffers
net.ipv4.tcp_rmem=4096 131072 16777216
net.ipv4.tcp_wmem=4096 87380 16777216
net.core.rmem_max=851968
net.core.wmem_max=851968

J'ai vu des tuto avec

Code: [Sélectionner]

net.core.rmem=851968
net.core.wmem=851968

Mais je ne pense pas que ce soit une bonne idée.

Breizh29 · « **Réponse #95 le:** 15 janvier 2020 à 16:03:01 »

Citation de: vivien le 15 janvier 2020 à 15:50:48

+1 le débit mono-thread est vraiment intéressant à avoir. (cela nécessite deux autres tests iPerf3)

Va falloir réserver des plages de temps serveur pour nos tests !
Si je rajoute ça, et qu'on est au moins 2 à "jouer", sans compter les autres utilisateurs, on va finir par fausser les résultats en se marchant sur les pieds, non ?

DamienC : 05 / 15 / 25 / ...
Qui gère le planning et réserve les ressources ?

Et du coup, faudrait aussi qu'on voit à automatiser nos tracés (upload de nos csv vers un espace où un truc type gnuplot trace et publie ?)

Vivien, vu les capacités de Bouygues, faut monter un paris2.testdebit.info avec l'aide de kgersen, réservé pour nos tests

On y mettra un goben, vous m'aiderez à le compiler sous macos et on fera ça au mieux !