La Fibre
Fournisseurs d'accès à Internet fixe en France métropolitaine => Free => 
Débits fibre Free => Discussion démarrée par: Breizh29 le 05 janvier 2020 à 15:42:33
-
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).
(https://lafibre.info/images/free_debit/202001_comparatif_bubic_bbr_1.png)
(https://lafibre.info/images/free_debit/202001_comparatif_bubic_bbr_2.png)
(https://lafibre.info/images/free_debit/202001_comparatif_bubic_bbr_3.png)
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 :
(https://lafibre.info/images/free_debit/202001_free_tests_debit_multithread.png)
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
(https://lafibre.info/images/free_debit/202001_free_tests_debit_1_thread.png)
(https://lafibre.info/images/free_debit/202001_free_tests_debit_16_thread.png)
(https://lafibre.info/images/free_debit/202001_free_tests_debit_1et16_thread.png)
- 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é client
La 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).
Passer 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
(https://lafibre.info/images/free_debit/202002_comparatif_cubic_bbr_1.png)
(https://lafibre.info/images/free_debit/202002_comparatif_cubic_bbr_2.png)
-
C'est un plafond sympa :D Tu dois le savoir mais la limite de la techno 10g-epon semble être à 8Gbps environ, donc de toute façon si tu visais les 10, ce 'nest pas possible. Alors arriver à 7, c'est déja top, sachant que le réseau doit être relativement vide pour les atteindre. Ici j'ai déja tapé 7.9Gbps, vers 6h du mat. En journée je suis entre 3 et 6.
Pour la différence de débit entre ipv4 et v6, je ne la constate pas de mon coté. A ces débits, iperf doit jouer aussi, les serveurs en face également (l'ipv6 moins offloadée ?), bref... Mais la différence n'est pas énorme. Tu as essayé avec curl, si tu pouvais reproduire le phénomène ?
Pour les jumbos à 16k, tu seras à 1500 sur le net de toute façon. Et la plupart des nas&co que tu peux avoir en interne doivent limiter à 9k ... Je ne suis pas sur de la pertinence du 16k du coup.
-
Pourrais tu faire un traceroute (plutôt un mtr-zrwc100) vers paris.testdebit.info en IPv4 et ne IPv6 ?
Envoi moi tes IPv4 / IPv6 pour que je réaliser un reverse traceroute.
Le trajet IPv4 va passer par le peering privé entre Free et Bouygues Telecom.
Pour l'IPv6, des anomalies de routage sont possible.
Sinon tu n'es pas seul sur le serveur, voici le trafic (chaque point représente le trafic moyen sur 5 minutes)
(https://lafibre.info/images/stats/202001_stats_testdebit_paris.png)
-
@Florian
Merci pour ton retour.
Oui, c'est clair que c'est un plafond sympa !
Non, je ne visais bien sûr pas plus que 8 Gbits/s environ. C'est juste que je me demande pourquoi je reste comme bloqué à cette valeur. Je vais laisser le script tourner pour confirmer sur plus de temps.
Pour les jumbo, oui, je sais bien. Certaines personnes pensent qu'il vaut parfois mieux activer (au moins 9k, 16k effectivement c'est très peu supporté) de sorte que la fragmentation soit effectuée par des équipements plus adaptés que sa propre petite carte réseau. Mais je ne suis pas spécialiste réseau.
IPv4 versus IPv6, j'ai lu d'autres posts ici et ailleurs qui font le même genre de remarques, sans l'expliquer réellement (hypothèses autour des équipements, en effet). Je vais poursuivre, et creuser curl.
A+
-
@Vivien
Merci pour les suggestions. Je te fais ça asap.
-
Tu pourrais aussi essayer sur un autre serveur moins chargée.
Attention avec la latence qui augmente, la montée en débit sera plus lente.
Tous les serveurs sont en 10 Gb/s connecté à un routeur ou switch Bouygues Telecom qui lui même à une capacité beaucoup plus importante (LAG de plusieurs liens de 100 Gb/s vers le cœur de réseau pour ceux qui sont en direct sur un BSR). Ce sont des Intel Xeon E3-1240 v5 @3.5 GHz utilisés sans virtualisation avec un Kernel Linux 5.0 (passage au Kernel 5.3 dans quelques jours)
Paris : https://paris.testdebit.info/
(https://lafibre.info/images/stats/202001_stats_testdebit_paris.png)
Lille : https://lille.testdebit.info/
(https://lafibre.info/images/stats/202001_stats_testdebit_lille.png)
Lyon : https://lyon.testdebit.info/
(https://lafibre.info/images/stats/202001_stats_testdebit_lyon.png)
Bordeaux : https://bordeaux.testdebit.info/
(https://lafibre.info/images/stats/202001_stats_testdebit_bordeaux.png)
Aix-Marseille : https://bordeaux.testdebit.info/
(https://lafibre.info/images/stats/202001_stats_testdebit_aix-marseille.png)
Le peering entre Free et Bouygues Telecom est par contre beaucoup plus limité, quelques liens 10 Gb/s ou dans le maximum des cas un lien 100 Gb/s.
-
t'as quoi dans la colonne "Retr" a la fin du iperf3 ?
-
@Vivien
(+ IP en MP)
Un MTR en IPv6 vers paris.testdebit.info :
Start: 2020-01-05T18:53:48+0100
HOST: Mac-mini-BZH.local Loss% Snt Last Avg Best Wrst StDev
1. AS12322 monIP 0.0% 100 0.3 0.4 0.2 1.0 0.1
2. AS12322 2a01:e03:12:f836:7e2c::ffff 0.0% 100 2.7 2.4 1.6 12.2 1.2
3. AS12322 2a01:e03:12:1700::ffff 77.0% 100 1.8 2.9 1.7 17.1 3.1
4. AS12322 2a01:e03:11::1 0.0% 100 3.1 4.4 3.0 21.0 2.5
5. AS12322 2a01:e03:f::1 0.0% 100 4.4 4.7 3.9 12.4 1.2
6. AS12322 2a01:e03:e::5 0.0% 100 5.5 6.1 5.2 12.6 1.3
7. AS12322 2a01:e03:e::2 18.0% 100 9.6 8.5 6.2 10.4 1.2
8. AS12322 2a01:e03:1::22 40.0% 100 12.4 12.3 11.7 13.0 0.3
9. AS12322 2a01:e00:3f::5 9.0% 100 12.6 12.4 11.8 18.0 0.7
10. AS5410 2001:860:0:81::1 0.0% 100 11.9 12.1 11.6 12.8 0.3
11. AS5410 2001:860:bbee:b4::2 0.0% 100 12.2 12.8 12.2 13.4 0.3
12. AS5410 2001:860:bbe0:128::2 0.0% 100 13.3 13.2 12.7 13.7 0.3
13. AS5410 2001:860:de01:1100::2 0.0% 100 12.4 12.5 12.0 13.2 0.3
Idem en IPv4 :
Start: 2020-01-05T18:58:09+0100
HOST: Mac-mini-BZH.local Loss% Snt Last Avg Best Wrst StDev
1. AS??? 192.168.200.1 0.0% 100 0.3 0.3 0.2 0.4 0.1
2. AS??? 194.149.164.52 3.0% 100 12.3 12.6 12.0 13.7 0.3
3. AS??? 194.149.171.198 0.0% 100 12.6 12.4 11.8 13.0 0.3
4. AS5410 la110.rpt02-th2.net.bbox.fr 0.0% 100 12.4 12.1 11.5 12.9 0.3
5. AS5410 62.34.2.53 0.0% 100 14.9 14.0 12.6 15.4 0.6
6. AS5410 212.194.171.68 10.0% 100 13.0 12.7 12.2 13.3 0.3
7. AS5410 89.89.101.141 0.0% 100 13.1 12.9 12.4 13.5 0.3
8. AS5410 89.84.1.186 0.0% 100 12.4 12.6 12.1 13.2 0.3
-
J'ai refait un mtr IPv6 dans le doute, vu le nombre de perte d'une des étapes... mais pareil :
Start: 2020-01-05T19:02:10+0100
HOST: Mac-mini-BZH.local Loss% Snt Last Avg Best Wrst StDev
1. AS12322 monIP 0.0% 100 0.4 0.3 0.2 0.5 0.1
2. AS12322 2a01:e03:12:f836:7e2c::ffff 0.0% 100 2.6 2.6 1.6 12.2 1.8
3. AS12322 2a01:e03:12:1700::ffff 75.0% 100 2.0 2.6 1.8 7.9 1.6
4. AS12322 2a01:e03:11::1 0.0% 100 3.5 3.8 2.8 13.9 1.3
5. AS12322 2a01:e03:f::1 0.0% 100 4.2 5.5 3.7 50.9 5.6
6. AS12322 2a01:e03:e::5 0.0% 100 5.4 6.3 5.1 39.1 3.4
7. AS12322 2a01:e03:e::2 15.0% 100 6.7 8.2 5.9 10.7 1.2
8. AS12322 2a01:e03:1::22 47.0% 100 12.6 12.3 11.8 13.1 0.3
9. AS12322 2a01:e00:3f::5 20.0% 100 12.6 12.4 11.9 12.9 0.3
10. AS5410 2001:860:0:81::1 0.0% 100 12.2 12.1 11.5 12.6 0.3
11. AS5410 2001:860:bbee:b4::2 0.0% 100 12.4 12.7 12.2 13.4 0.3
12. AS5410 2001:860:bbe0:128::2 0.0% 100 13.1 13.2 12.7 13.8 0.3
13. AS5410 2001:860:de01:1100::2 0.0% 100 12.4 12.6 12.0 13.2 0.3
-
t'as quoi dans la colonne "Retr" a la fin du iperf3 ?
Sur un test à l'instant en IPv4 : 22054 / en IPv6 : 19870
(je ne conserve pas les détails des lancements via le script)
-
Reverse traceroute réalisé depuis paris.testdebit.info :
On passe bien par le PNI dans les deux cas et dans les deux sens.
Il ne devrait pas y avoir de différence significative entre IPv4 et IPv6 (au-delà de l'en-tête IP un peu plus longue en IPv6)
IPv6 :
$ mtr -zrwc 100 2a01:e0a:1fc:6xx0::1
Start: 2020-01-05T19:05:24+0100
HOST: Loss% Snt Last Avg Best Wrst StDev
1. AS5410 2001:860:de01:1100::1 0.0% 100 0.8 0.7 0.6 1.0 0.1
2. AS5410 2001:860:bbe0:128::1 0.0% 100 0.3 0.3 0.2 0.8 0.1
3. AS5410 2001:860:bbee:d8::1 0.0% 100 1.0 0.9 0.8 1.4 0.1
4. AS5410 freetelecom-clubint-peeering-t2.ipv6.club-internet.fr 3.0% 100 1.3 1.3 1.2 1.6 0.1
5. AS12322 2a01:e00:3f::6 45.0% 100 1.3 1.3 1.2 2.3 0.1
6. AS12322 2a01:e03:4::9 10.0% 100 6.9 7.0 6.8 8.3 0.2
7. AS12322 2a01:e03:4::2 9.0% 100 10.2 10.1 9.9 10.4 0.1
8. AS12322 2a01:e03:12::1 0.0% 100 12.4 12.6 11.9 30.4 2.1
9. AS12322 2a01:e03:12:1700:fe00::7e2c 0.0% 100 12.9 12.4 12.1 15.7 0.4
10. AS12322 2a01:e0a:1fc:6xx0::1 0.0% 100 12.7 12.3 11.8 12.9 0.3
IPv4 :
$ mtr -zrwc 100 82.64.142.xx
Start: 2020-01-05T19:07:27+0100
HOST: Loss% Snt Last Avg Best Wrst StDev
1. AS5410 89.84.1.185 0.0% 100 0.6 0.5 0.4 0.7 0.1
2. AS5410 89.89.101.140 0.0% 100 0.3 0.3 0.2 0.9 0.1
3. AS5410 212.194.171.69 0.0% 100 2.1 2.4 1.3 5.5 0.7
4. AS5410 62.34.2.52 51.0% 100 0.8 1.0 0.8 1.2 0.1
5. AS5410 free-bouygtel-peering-10g.club-internet.fr 0.0% 100 1.2 1.3 1.1 1.5 0.1
6. AS??? 194.149.171.197 39.0% 100 1.5 1.6 1.4 2.4 0.2
7. AS??? ? ? 100.0 100
8. AS??? ? ? 100.0 100
9. AS??? ? ? 100.0 100
10. AS??? ? ? 100.0 100
11. AS??? ? ? 100.0 100
12. AS12322 82-64-142-xx.subs.proxad.net 0.0% 100 12.7 12.3 11.9 12.9 0.3
Lol Club-internet est toujours vivant en 2020 !
J'imagine qu'on est sur les même IP depuis Club-Internet et si Club-Internet ne proposait pas d'IPv6 a ses clients, les peering étaient bien montés en IPv6, on en a encore la preuve avec le reverse DNS IPv6 qui n'a pas été mis à jour : freetelecom-clubint-peeering-t2.ipv6.club-internet.fr (comme l'indique le reverse DNS, le peering sur fait sur T2 soit Telehouse 2)
Bouygues, il faudrait ce séparer de ce nom de domaine qui renvois en plus chez SFR.
-
@Florian:
2 tests avec curl successivement (MTU 9k) :
IPv4 :
curl -k -o /dev/null http://ipv4.bouygues.testdebit.info/10G.iso
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 9536M 100 9536M 0 0 324M 0 0:00:29 0:00:29 --:--:-- 413M
IPv6 :
curl -k -o /dev/null http://ipv6.bouygues.testdebit.info/10G.iso
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 9536M 100 9536M 0 0 246M 0 0:00:38 0:00:38 --:--:-- 284M
L'écart semble présent, là aussi (31% environ plus long en IPv6, ici)
-
Il se passe quoi si tu n'actives pas les jumbo frames ?
-
Sur un test à l'instant en IPv4 : 22054 / en IPv6 : 19870
(je ne conserve pas les détails des lancements via le script)
A partir de combien de flux (option -P) ca ne progresse plus ? 16 semble overkill.
y'a t'il des différences sans l'option '-w 4m' ?
-
Il se passe quoi si tu n'actives pas les jumbo frames ?
Depuis 18h environ, j’avais passé le mtu de 16k à 9k, pour voir.
J’essaierai de les désactiver totalement plus tard, ou en dehors du script.
-
A partir de combien de flux (option -P) ca ne progresse plus ? 16 semble overkill.
y'a t'il des différences sans l'option '-w 4m' ?
Justement, c’est jusqu’à 16 que j’avais noté de la progression. Ensuite, ça stagne.
Sans l’option -w 4m, le débit est plus faible.
Dans l’immédiat, je ne peux pas faire de nouveaux tests. Je fais ça dès que je peux.
-
Il est intéressant de travailler avec une seule connexion TCP, car cela met plus en avant les problèmes.
Le test avec curl est vraiment perturbant, je m'attend a bien plus comme débit.
quand tout est bon, le débit monothread mutlthread devrait être identique. C'est le cas en 1 Gb/s : une bonne connexion 1 Gb/s doit offrir 1 Gb/s en monothread comme en multithread.
Pour le 10 Gb/s il y a une exception : les lag de n x 10 Gb/s. Une même connexion TCP ne passe que par un seul lien du LAG pour éviter que les paquets arrivent dans le désordre. Si ce lien est rempli à 5 Gb/s, il n'y aura que 5 Gb/s de disponible.
Exemple : lag de 4 x 10 Gb/s rempli à 50% équitablement sur les 4 liens : monothread : débit de 5 Gb/s sur un seul lien, multithread débit de 2,5 Gb/s sur chacun des 4 liens du LAG (soit un débit de 7,5 Gb/s pour chaque lien 10 Gb/s)
Je ne sais pas si le peering entre Free et Bouygues est constitué d'un lag de n liens 10 Gb/s ou si c'est un lien 100 Gb/s.
-
Ce sont des Mo/s je crois dans la sortie de curl, du coup c'est quand même pas rien.
-
Exact.
A noter qu'une multiplication de x8 ne suffit pas car ce sont des multiples de 1024 alors que le débit est en multiple de 1000.
413Mo/s = 3,46 Gb/s
-
Bonjour,
J'ai mis à jour la courbe avec les données de la nuit dernière.
En passant le mtu 16k -> 9k,
- le niveau nocture moyen de l'IPv4 s'est légèrement écrété
- le niveau nocture moyen de l'IPv6 a légèrement augmenté
Autant je peux comprendre l'amélioration IPv6 par le moindre nombre de fragmentations nécessaires (en IPv6 c'est systématiquement la source qui fragmente, c'est bien ça ?), autant je ne m'explique pas l'effet côté IPv4 (ou alors c'est un facteur extérieur sans rapport qui a joué)
Ce soir, je désactive les jumbo frames...
-
C'est intriguant et je suis assez curieux de voir l'impact d'un passage à une MTU "classique".
-
Exact.
A noter qu'une multiplication de x8 ne suffit pas car ce sont des multiples de 1024 alors que le débit est en multiple de 1000.
413Mo/s = 3,46 Gb/s
Ça dépend si l'outil calcul en SI (en toute rigueur, 413 Mo/s = 413000000 o/s en SI) ou en unité informatique historique (qui devrait être en toute rigueur Mio en SI).
-
J'ai refait les tests curl d'hier avec cette fois MTU 1500 :
IPv4 :
curl -k -o /dev/null http://ipv4.bouygues.testdebit.info/10G.iso
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 9536M 100 9536M 0 0 332M 0 0:00:28 0:00:28 --:--:-- 339M
IPv6 :
curl -k -o /dev/null http://ipv6.bouygues.testdebit.info/10G.iso
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 9536M 100 9536M 0 0 399M 0 0:00:23 0:00:23 --:--:-- 335M
Cette fois, c'est l'IPv6 qui l'emporte (21% plus long en IPv4)
-
Faudrait connaitre le mtu avec le serveur de test.
Sur Windows c'est visible avec "netsh interface ipv6 show destinationcache address=<adresse destination>" (ipv4 aussi)
Sur Linux avec la commande 'tracepath <adresse destination>'
sur Mac j'en sais rien, peut-etre tracepath aussi ?
-
MàJ après soirée/nuit/matinée en MTU 1500.
J'ai pas l'impression qu'on puisse conclure grand chose...
-
Cela pourrait impacter tes résultats :
Depuis 21h15, j'ai passé le serveur paris.testdebit.info (qui correspond au serveur utilisé par les clients Free quand ils utilisent le nom de domaine anycast bouygues.testdebit.info) en BBR
$ sysctl net.ipv4.tcp_congestion_control
net.ipv4.tcp_congestion_control = bbr
On attend la suite de tes tests pour savoir si c'est une bonne solution.
-
Bien noté.
Réponse demain matin.
-
Je viens de regarder mes resultats de 21h20 /21h30 / 21h40.
Les debits se sont écroulés subitement de 2 gbits/s environ !
Extrait des chiffres pour illustrer :
Date ; IPv4 ; IPv6
08/01/2020 20:40:00 ; 5,89 ; 5,73
08/01/2020 20:50:00 ; 5,84 ; 5,63
08/01/2020 21:00:00 ; 5,75 ; 5,50
08/01/2020 21:10:00 ; 5,59 ; 5,06
08/01/2020 21:20:01 ; 3,62 ; 3,61
08/01/2020 21:30:00 ; 3,51 ; 3,69
08/01/2020 21:40:00 ; 3,58 ; 3,55
C’est fou un tel impact et une telle différence entre 2 algos de gestion de la congestion.
-
Confirmation de la "catastrophe" BBR entre chez moi et le serveur !
Au secours !...
-
Ah ? du changement ?
Le dernier résultat (8h20) est revenu aux valeurs habituelles (+2 gbits/s en IPv4 comme en IPv6)... intervention ou hasard ? :)
EDIT: ah ben peut-être une fausse joie, on est redescendu...
EDIT2: je retire le doute, c'est bien toujours le bazar.
-
Non seulement les débits ont beaucoup baissé, mais en plus ils semblent très instables.
-
MàJ 1er post à 12h20.
Ca ne s'arrange pas... Sauf changement, j'interromprai le script ce soir.
-
Non, n'éteint pas, si on peut continuer les optimisations, je suis intéressé.
Depuis 14h44, j'ai passé le serveur paris.testdebit.info (qui correspond au serveur utilisé par les clients Free quand ils utilisent le nom de domaine anycast bouygues.testdebit.info / bouygues.iperf.fr) en cubic
$ sysctl net.ipv4.tcp_congestion_control
net.ipv4.tcp_congestion_control = cubic
- avant 8 janvier 21h15 => illinois
- entre 8 janvier 21h15 et 9 janvier 14h44 => bbr
- depuis 14h44 => cubic (algorithme par défaut)
PS: Tu fait comment pour générer le graphique ? Tu importes les données dans Excel ?
(https://lafibre.info/images/free_debit/202001_free_debit_illinois_vs_bbr.png)
-
OK si on poursuit les optimisations :)
Oui, j'importe des lignes d'un csv dans Excel car je n'ai pas eu le temps d'automatiser cette partie du traitement (trouver l'outil de rendu graphique le plus adapté/riche/souple, compatible macos, etc.).
Ça sera peut-être la prochaine étape, quand j'aurai du temps...
-
Bon, j'ai pas envie de me prononcer trop tôt, mais cette modification d'algo (BBR -> Cubic) semble radicalement améliorer les choses.
Je mettrai à jour avec un peu plus de recul...
-
J'ai très peu d’équipements nux/nix, mais j'ai toujours eu de bons résultats avec l'algo "HighSpeed" (https://tools.ietf.org/html/rfc3649.html).
-
Non seulement les débits ont beaucoup baissé, mais en plus ils semblent très instables.
t'as essayé en réduisant le -P 16 ?
quoique c'est trop tard Vivien a enlever BBR.
-
t'as essayé en réduisant le -P 16 ?
J'aurais pu, mais en dehors du script, car je voulais éviter de changer plusieurs facteurs à la fois.
Effectivement, c'est à présent trop tard. Qu'est-ce qui te fait penser que ça aurait pu donner de meilleurs résultats ?
-
J'ai mis à jour le 1er post.
A première vue, on améliore nettement les choses, mais on ne revient pas au niveau d'Illinois sur les mêmes tranches horaires. A confirmer.
-
J'aurais pu, mais en dehors du script, car je voulais éviter de changer plusieurs facteurs à la fois.
Effectivement, c'est à présent trop tard. Qu'est-ce qui te fait penser que ça aurait pu donner de meilleurs résultats ?
Ben y'a clairement un souci de ton coté si t'es obligé de monter a -P 16 quand meme. Soit un probleme de buffers ou un truc du genre.
avec -P 1 (sans -P quoi) tu obtient quoi ? si t'a pas au moins 1Gbps c'est deja ca qu'il faut résoudre je pense.
-
En IPv4 :
iperf3 -c paris.testdebit.info -R -t 20 -O 5 -p 5202 -4
Connecting to host paris.testdebit.info, port 5202
Reverse mode, remote host paris.testdebit.info is sending
[ 6] local 192.168.200.115 port 49507 connected to 89.84.1.186 port 5202
[ ID] Interval Transfer Bitrate
[ 6] 0.00-1.00 sec 120 MBytes 1.01 Gbits/sec (omitted)
[ 6] 1.00-2.00 sec 160 MBytes 1.34 Gbits/sec (omitted)
[ 6] 2.00-3.00 sec 159 MBytes 1.33 Gbits/sec (omitted)
[ 6] 3.00-4.00 sec 159 MBytes 1.33 Gbits/sec (omitted)
[ 6] 4.00-5.00 sec 151 MBytes 1.26 Gbits/sec (omitted)
[ 6] 0.00-1.00 sec 118 MBytes 991 Mbits/sec
[ 6] 1.00-2.00 sec 130 MBytes 1.09 Gbits/sec
[ 6] 2.00-3.00 sec 137 MBytes 1.15 Gbits/sec
[ 6] 3.00-4.00 sec 131 MBytes 1.10 Gbits/sec
[ 6] 4.00-5.00 sec 108 MBytes 903 Mbits/sec
[ 6] 5.00-6.00 sec 113 MBytes 947 Mbits/sec
[ 6] 6.00-7.00 sec 119 MBytes 999 Mbits/sec
[ 6] 7.00-8.00 sec 106 MBytes 887 Mbits/sec
[ 6] 8.00-9.00 sec 89.4 MBytes 750 Mbits/sec
[ 6] 9.00-10.00 sec 76.7 MBytes 644 Mbits/sec
[ 6] 10.00-11.00 sec 69.5 MBytes 583 Mbits/sec
[ 6] 11.00-12.00 sec 53.1 MBytes 446 Mbits/sec
[ 6] 12.00-13.00 sec 56.7 MBytes 476 Mbits/sec
[ 6] 13.00-14.00 sec 60.8 MBytes 510 Mbits/sec
[ 6] 14.00-15.00 sec 66.5 MBytes 558 Mbits/sec
[ 6] 15.00-16.00 sec 69.6 MBytes 583 Mbits/sec
[ 6] 16.00-17.00 sec 75.7 MBytes 636 Mbits/sec
[ 6] 17.00-18.00 sec 79.5 MBytes 667 Mbits/sec
[ 6] 18.00-19.00 sec 74.5 MBytes 625 Mbits/sec
[ 6] 19.00-20.00 sec 66.5 MBytes 558 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 6] 0.00-20.00 sec 1.76 GBytes 756 Mbits/sec 7 sender
[ 6] 0.00-20.00 sec 1.76 GBytes 755 Mbits/sec receiver
iperf Done.
En IPv6 :
iperf3 -c paris.testdebit.info -R -t 20 -O 5 -p 5202 -6
Connecting to host paris.testdebit.info, port 5202
Reverse mode, remote host paris.testdebit.info is sending
[ 6] local 2a01:e0a:1fc:xxxxx port 49585 connected to 2001:860:de01:1100::2 port 5202
[ ID] Interval Transfer Bitrate
[ 6] 0.00-1.00 sec 104 MBytes 869 Mbits/sec (omitted)
[ 6] 1.00-2.00 sec 124 MBytes 1.04 Gbits/sec (omitted)
[ 6] 2.00-3.00 sec 126 MBytes 1.05 Gbits/sec (omitted)
[ 6] 3.00-4.00 sec 137 MBytes 1.15 Gbits/sec (omitted)
[ 6] 4.00-5.00 sec 145 MBytes 1.22 Gbits/sec (omitted)
[ 6] 0.00-1.00 sec 125 MBytes 1.05 Gbits/sec
[ 6] 1.00-2.00 sec 110 MBytes 923 Mbits/sec
[ 6] 2.00-3.00 sec 81.8 MBytes 686 Mbits/sec
[ 6] 3.00-4.00 sec 84.8 MBytes 711 Mbits/sec
[ 6] 4.00-5.00 sec 65.2 MBytes 547 Mbits/sec
[ 6] 5.00-6.00 sec 69.1 MBytes 579 Mbits/sec
[ 6] 6.00-7.00 sec 74.0 MBytes 621 Mbits/sec
[ 6] 7.00-8.00 sec 78.7 MBytes 660 Mbits/sec
[ 6] 8.00-9.00 sec 81.8 MBytes 686 Mbits/sec
[ 6] 9.00-10.00 sec 87.1 MBytes 731 Mbits/sec
[ 6] 10.00-11.00 sec 66.4 MBytes 557 Mbits/sec
[ 6] 11.00-12.00 sec 73.5 MBytes 617 Mbits/sec
[ 6] 12.00-13.00 sec 79.5 MBytes 667 Mbits/sec
[ 6] 13.00-14.00 sec 83.7 MBytes 702 Mbits/sec
[ 6] 14.00-15.00 sec 68.5 MBytes 574 Mbits/sec
[ 6] 15.00-16.00 sec 64.2 MBytes 539 Mbits/sec
[ 6] 16.00-17.00 sec 69.3 MBytes 581 Mbits/sec
[ 6] 17.00-18.00 sec 73.2 MBytes 614 Mbits/sec
[ 6] 18.00-19.00 sec 78.6 MBytes 658 Mbits/sec
[ 6] 19.00-20.00 sec 81.7 MBytes 686 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 6] 0.00-20.00 sec 1.56 GBytes 670 Mbits/sec 5 sender
[ 6] 0.00-20.00 sec 1.56 GBytes 669 Mbits/sec receiver
iperf Done.
Je croyais que c'était slow Start ?
Moi j'ai quick start and slow after... ;D
-
quelle version d'iperf3? (iperf3 -v)
ajoute les options "--get-server-output -V ", enleve les "-O 5"
essai aussi avec ces serveur: pox.nspeed.app et ping.online.net
-
iperf3 -v
iperf 3.7 (cJSON 1.5.2)
Darwin Mac-mini-BZH.local 19.2.0 Darwin Kernel Version 19.2.0: Sat Nov 9 03:47:04 PST 2019; root:xnu-6153.61.1~20/RELEASE_X86_64 x86_64
Optional features available: sendfile / zerocopy, authentication
iperf3 -c paris.testdebit.info --get-server-output -R -p 5202 -6 -t 20
Connecting to host paris.testdebit.info, port 5202
Reverse mode, remote host paris.testdebit.info is sending
[ 6] local 2a01:e0a:1fc:xxx port 50508 connected to 2001:860:de01:1100::2 port 5202
[ ID] Interval Transfer Bitrate
[ 6] 0.00-1.00 sec 108 MBytes 906 Mbits/sec
[ 6] 1.00-2.00 sec 157 MBytes 1.32 Gbits/sec
[ 6] 2.00-3.00 sec 159 MBytes 1.33 Gbits/sec
[ 6] 3.00-4.00 sec 155 MBytes 1.30 Gbits/sec
[ 6] 4.00-5.00 sec 117 MBytes 980 Mbits/sec
[ 6] 5.00-6.00 sec 130 MBytes 1.09 Gbits/sec
[ 6] 6.00-7.00 sec 103 MBytes 862 Mbits/sec
[ 6] 7.00-8.00 sec 96.5 MBytes 810 Mbits/sec
[ 6] 8.00-9.00 sec 76.4 MBytes 641 Mbits/sec
[ 6] 9.00-10.00 sec 66.8 MBytes 560 Mbits/sec
[ 6] 10.00-11.00 sec 60.7 MBytes 509 Mbits/sec
[ 6] 11.00-12.00 sec 63.8 MBytes 535 Mbits/sec
[ 6] 12.00-13.00 sec 69.2 MBytes 581 Mbits/sec
[ 6] 13.00-14.00 sec 74.4 MBytes 625 Mbits/sec
[ 6] 14.00-15.00 sec 78.5 MBytes 658 Mbits/sec
[ 6] 15.00-16.00 sec 83.6 MBytes 702 Mbits/sec
[ 6] 16.00-17.00 sec 87.2 MBytes 731 Mbits/sec
[ 6] 17.00-18.00 sec 92.7 MBytes 778 Mbits/sec
[ 6] 18.00-19.00 sec 96.3 MBytes 807 Mbits/sec
[ 6] 19.00-20.00 sec 101 MBytes 844 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 6] 0.00-20.00 sec 1.94 GBytes 832 Mbits/sec 8 sender
[ 6] 0.00-20.00 sec 1.93 GBytes 828 Mbits/sec receiver
Server output:
-----------------------------------------------------------
Server listening on 5202
-----------------------------------------------------------
Accepted connection from 2a01:e0a:1fc:xxx, port 50507
[ 5] local 2001:860:de01:1100::2 port 5202 connected to 2a01:e0a:1fc:xxx port 50508
[ ID] Interval Transfer Bandwidth Retr Cwnd
[ 5] 0.00-1.00 sec 114 MBytes 960 Mbits/sec 0 2.01 MBytes
[ 5] 1.00-2.00 sec 158 MBytes 1.32 Gbits/sec 0 2.01 MBytes
[ 5] 2.00-3.00 sec 159 MBytes 1.33 Gbits/sec 0 2.01 MBytes
[ 5] 3.00-4.00 sec 155 MBytes 1.30 Gbits/sec 2 1.41 MBytes
[ 5] 4.00-5.00 sec 116 MBytes 975 Mbits/sec 0 1.57 MBytes
[ 5] 5.00-6.00 sec 130 MBytes 1.09 Gbits/sec 0 1.69 MBytes
[ 5] 6.00-7.00 sec 104 MBytes 870 Mbits/sec 2 1.27 MBytes
[ 5] 7.00-8.00 sec 96.2 MBytes 807 Mbits/sec 2 966 KBytes
[ 5] 8.00-9.00 sec 76.2 MBytes 640 Mbits/sec 0 1.01 MBytes
[ 5] 9.00-10.00 sec 67.5 MBytes 566 Mbits/sec 2 780 KBytes
[ 5] 10.00-11.00 sec 60.0 MBytes 503 Mbits/sec 0 830 KBytes
[ 5] 11.00-12.00 sec 63.8 MBytes 535 Mbits/sec 0 886 KBytes
[ 5] 12.00-13.00 sec 70.0 MBytes 587 Mbits/sec 0 944 KBytes
[ 5] 13.00-14.00 sec 73.8 MBytes 619 Mbits/sec 0 1001 KBytes
[ 5] 14.00-15.00 sec 78.8 MBytes 661 Mbits/sec 0 1.03 MBytes
[ 5] 15.00-16.00 sec 83.8 MBytes 703 Mbits/sec 0 1.09 MBytes
[ 5] 16.00-17.00 sec 87.5 MBytes 734 Mbits/sec 0 1.15 MBytes
[ 5] 17.00-18.00 sec 92.5 MBytes 776 Mbits/sec 0 1.21 MBytes
[ 5] 18.00-19.00 sec 96.2 MBytes 807 Mbits/sec 0 1.26 MBytes
[ 5] 19.00-20.00 sec 100 MBytes 839 Mbits/sec 0 1.32 MBytes
[ 5] 20.00-20.01 sec 1.25 MBytes 786 Mbits/sec 0 1.32 MBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Retr
[ 5] 0.00-20.01 sec 1.94 GBytes 831 Mbits/sec 8 sender
[ 5] 0.00-20.01 sec 0.00 Bytes 0.00 bits/sec receiver
iperf Done.
-
Sur Online, ça semble plus stable :
iperf3 -c ping.online.net --get-server-output -R -p 5205 -6 -t 20
Connecting to host ping.online.net, port 5205
Reverse mode, remote host ping.online.net is sending
[ 7] local 192.168.200.115 port 50677 connected to 62.210.18.40 port 5205
[ ID] Interval Transfer Bitrate
[ 7] 0.00-1.00 sec 143 MBytes 1.20 Gbits/sec
[ 7] 1.00-2.00 sec 160 MBytes 1.35 Gbits/sec
[ 7] 2.00-3.00 sec 160 MBytes 1.34 Gbits/sec
[ 7] 3.00-4.00 sec 162 MBytes 1.36 Gbits/sec
[ 7] 4.00-5.00 sec 160 MBytes 1.34 Gbits/sec
[ 7] 5.00-6.00 sec 162 MBytes 1.36 Gbits/sec
[ 7] 6.00-7.00 sec 161 MBytes 1.35 Gbits/sec
[ 7] 7.00-8.00 sec 158 MBytes 1.32 Gbits/sec
[ 7] 8.00-9.00 sec 160 MBytes 1.35 Gbits/sec
[ 7] 9.00-10.00 sec 160 MBytes 1.35 Gbits/sec
[ 7] 10.00-11.00 sec 160 MBytes 1.34 Gbits/sec
[ 7] 11.00-12.00 sec 160 MBytes 1.34 Gbits/sec
[ 7] 12.00-13.00 sec 162 MBytes 1.36 Gbits/sec
[ 7] 13.00-14.00 sec 160 MBytes 1.34 Gbits/sec
[ 7] 14.00-15.00 sec 161 MBytes 1.35 Gbits/sec
[ 7] 15.00-16.00 sec 160 MBytes 1.34 Gbits/sec
[ 7] 16.00-17.00 sec 160 MBytes 1.34 Gbits/sec
[ 7] 17.00-18.00 sec 160 MBytes 1.35 Gbits/sec
[ 7] 18.00-19.00 sec 160 MBytes 1.34 Gbits/sec
[ 7] 19.00-20.00 sec 162 MBytes 1.36 Gbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 7] 0.00-20.00 sec 3.13 GBytes 1.35 Gbits/sec 0 sender
[ 7] 0.00-20.00 sec 3.12 GBytes 1.34 Gbits/sec receiver
Server output:
iperf 3.1.3
Linux ping 4.15.0-47-generic #50-Ubuntu SMP Wed Mar 13 10:44:52 UTC 2019 x86_64
-----------------------------------------------------------
Server listening on 5205
-----------------------------------------------------------
Time: Thu, 09 Jan 2020 18:22:29 GMT
Accepted connection from xxx, port 50676
Cookie: piwaxi5xlrwe5jxom6rr2s7hqnypg7bduwrc
TCP MSS: 1448 (default)
[ 5] local 62.210.18.40 port 5205 connected to xxx port 50677
Starting Test: protocol: TCP, 1 streams, 131072 byte blocks, omitting 0 seconds, 20 second test
[ ID] Interval Transfer Bandwidth Retr Cwnd
[ 5] 0.00-2.00 sec 318 MBytes 1.33 Gbits/sec 0 4.00 MBytes
[ 5] 2.00-4.00 sec 322 MBytes 1.35 Gbits/sec 0 4.00 MBytes
[ 5] 4.00-6.00 sec 322 MBytes 1.35 Gbits/sec 0 4.00 MBytes
[ 5] 6.00-8.00 sec 318 MBytes 1.33 Gbits/sec 0 4.00 MBytes
[ 5] 8.00-10.00 sec 321 MBytes 1.35 Gbits/sec 0 4.00 MBytes
[ 5] 10.00-12.00 sec 320 MBytes 1.34 Gbits/sec 0 4.00 MBytes
[ 5] 12.00-14.00 sec 321 MBytes 1.35 Gbits/sec 0 4.00 MBytes
[ 5] 14.00-16.00 sec 322 MBytes 1.35 Gbits/sec 0 4.00 MBytes
[ 5] 16.00-18.00 sec 320 MBytes 1.34 Gbits/sec 0 4.00 MBytes
[ 5] 18.00-20.00 sec 322 MBytes 1.35 Gbits/sec 0 4.00 MBytes
[ 5] 20.00-20.01 sec 1.25 MBytes 799 Mbits/sec 0 4.00 MBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
Test Complete. Summary Results:
[ ID] Interval Transfer Bandwidth Retr
[ 5] 0.00-20.01 sec 3.13 GBytes 1.35 Gbits/sec 0 sender
[ 5] 0.00-20.01 sec 0.00 Bytes 0.00 bits/sec receiver
CPU Utilization: local/sender 2.6% (0.0%u/2.6%s), remote/receiver 9.3% (1.7%u/7.8%s)
iperf Done.
-
Sur le dernier :
iperf3 -c pox.nspeed.app --get-server-output -R -p 5201 -6 -t 20
Connecting to host pox.nspeed.app, port 5201
Reverse mode, remote host pox.nspeed.app is sending
[ 6] local 2a01:e0a:1fc:xxx port 50860 connected to 2001:bc8:2679:100::1 port 5201
[ ID] Interval Transfer Bitrate
[ 6] 0.00-1.00 sec 97.3 MBytes 816 Mbits/sec
[ 6] 1.00-2.00 sec 109 MBytes 912 Mbits/sec
[ 6] 2.00-3.00 sec 111 MBytes 928 Mbits/sec
[ 6] 3.00-4.00 sec 109 MBytes 915 Mbits/sec
[ 6] 4.00-5.00 sec 111 MBytes 928 Mbits/sec
[ 6] 5.00-6.00 sec 111 MBytes 928 Mbits/sec
[ 6] 6.00-7.00 sec 111 MBytes 929 Mbits/sec
[ 6] 7.00-8.00 sec 111 MBytes 928 Mbits/sec
[ 6] 8.00-9.00 sec 111 MBytes 928 Mbits/sec
[ 6] 9.00-10.00 sec 100 MBytes 840 Mbits/sec
[ 6] 10.00-11.00 sec 90.7 MBytes 761 Mbits/sec
[ 6] 11.00-12.00 sec 69.0 MBytes 578 Mbits/sec
[ 6] 12.00-13.00 sec 58.2 MBytes 488 Mbits/sec
[ 6] 13.00-14.00 sec 48.4 MBytes 405 Mbits/sec
[ 6] 14.00-15.00 sec 47.0 MBytes 394 Mbits/sec
[ 6] 15.00-16.00 sec 50.3 MBytes 422 Mbits/sec
[ 6] 16.00-17.00 sec 54.2 MBytes 455 Mbits/sec
[ 6] 17.00-18.00 sec 58.3 MBytes 489 Mbits/sec
[ 6] 18.00-19.00 sec 61.9 MBytes 520 Mbits/sec
[ 6] 19.00-20.00 sec 66.2 MBytes 555 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 6] 0.00-20.01 sec 1.65 GBytes 707 Mbits/sec 32 sender
[ 6] 0.00-20.00 sec 1.64 GBytes 706 Mbits/sec receiver
Server output:
-----------------------------------------------------------
Server listening on 5201
-----------------------------------------------------------
Accepted connection from 2a01:e0a:1fc:xxx, port 50859
[ 5] local 2001:bc8:2679:100::1 port 5201 connected to 2a01:e0a:1fc:xxx port 50860
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 98.5 MBytes 826 Mbits/sec 0 3.31 MBytes
[ 5] 1.00-2.00 sec 109 MBytes 912 Mbits/sec 1 2.32 MBytes
[ 5] 2.00-3.00 sec 111 MBytes 933 Mbits/sec 0 2.32 MBytes
[ 5] 3.00-4.00 sec 109 MBytes 912 Mbits/sec 27 1.67 MBytes
[ 5] 4.00-5.00 sec 111 MBytes 933 Mbits/sec 0 1.73 MBytes
[ 5] 5.00-6.00 sec 110 MBytes 923 Mbits/sec 0 1.73 MBytes
[ 5] 6.00-7.00 sec 111 MBytes 933 Mbits/sec 0 1.84 MBytes
[ 5] 7.00-8.00 sec 110 MBytes 923 Mbits/sec 0 1.84 MBytes
[ 5] 8.00-9.00 sec 111 MBytes 933 Mbits/sec 0 1.84 MBytes
[ 5] 9.00-10.00 sec 100 MBytes 839 Mbits/sec 1 1.36 MBytes
[ 5] 10.00-11.00 sec 91.2 MBytes 765 Mbits/sec 1 1.01 MBytes
[ 5] 11.00-12.00 sec 68.8 MBytes 577 Mbits/sec 1 782 KBytes
[ 5] 12.00-13.00 sec 58.8 MBytes 493 Mbits/sec 0 840 KBytes
[ 5] 13.00-14.00 sec 48.8 MBytes 409 Mbits/sec 1 635 KBytes
[ 5] 14.00-15.00 sec 46.2 MBytes 388 Mbits/sec 0 682 KBytes
[ 5] 15.00-16.00 sec 50.0 MBytes 419 Mbits/sec 0 732 KBytes
[ 5] 16.00-17.00 sec 55.0 MBytes 461 Mbits/sec 0 787 KBytes
[ 5] 17.00-18.00 sec 57.5 MBytes 482 Mbits/sec 0 841 KBytes
[ 5] 18.00-19.00 sec 62.5 MBytes 524 Mbits/sec 0 895 KBytes
[ 5] 19.00-20.00 sec 66.2 MBytes 556 Mbits/sec 0 950 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-20.01 sec 1.65 GBytes 707 Mbits/sec 32 sender
iperf Done.
-
yeah pas top.
essai de recevoir un flux UDP a 1Gbps par exemple:
iperf3 -4 -u -c ping.online.net --get-server-output -V -R -p 520x -b 1G(ajuster 520x a un dispo, puis en IPv6)
puis monte a 5G pour voir (-b 5G). Mais pas plus de 10s , sert a rien flooder le Net avec de l'UDP.
a priori paris.testdebit.info ne fonctionne pas en UDP.
Apres avec Free ce n'est pas la meilleur heure pour tester :P
-
J'aurais pu, mais en dehors du script, car je voulais éviter de changer plusieurs facteurs à la fois.
Effectivement, c'est à présent trop tard. Qu'est-ce qui te fait penser que ça aurait pu donner de meilleurs résultats ?
Non ce n'est pas trop tard.
J'ai changé rapidement car tu disais arrêter rapidement les tests.
Je suis prêt à repasser sur BBR si tu t'en sert pour faire des tests.
Le mieux c'est peut-être que ce soit toi qui me dise quand changer.
-
A la base, avec ce thread je souhaitais voir comment optimiser au mieux la connexion 10G (mtu, stack TCP, ...) pour voir si les 7 gb/s sont dépassables en heure creuse et si les debits IPv4 et IPv6 peuvent être proches tout au long de la journée.
Si cela permet au passage d’optimiser le serveur de test, c’est tant mieux.
Si tu repasses en BBR, et à supposer qu’un test montre que ça se passe mieux avec moins de threads, quelle en sera la conclusion ?
Je suis un peu perdu sur les pistes à explorer...
Ps: je fais les test udp asap
-
Test UDP bande passante 1 Gb/s :
iperf3 -4 -u -c ping.online.net --get-server-output -V -R -p 5207 -b 1G
iperf 3.7
Darwin Mac-mini-BZH.local 19.2.0 Darwin Kernel Version 19.2.0: Sat Nov 9 03:47:04 PST 2019; root:xnu-6153.61.1~20/RELEASE_X86_64 x86_64
Control connection MSS 1448
Setting UDP block size to 1448
Time: Thu, 09 Jan 2020 21:58:13 UTC
Connecting to host ping.online.net, port 5207
Reverse mode, remote host ping.online.net is sending
Cookie: bcu7sffkstneqml4no757netfegtf5yrhqlm
Target Bitrate: 1000000000
[ 6] local 192.168.200.115 port 60932 connected to 62.210.18.40 port 5207
Starting Test: protocol: UDP, 1 streams, 1448 byte blocks, omitting 0 seconds, 10 second test, tos 0
[ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams
[ 6] 0.00-1.00 sec 118 MBytes 991 Mbits/sec 0.007 ms 0/85567 (0%)
[ 6] 1.00-2.00 sec 119 MBytes 1000 Mbits/sec 0.009 ms 1/86303 (0.0012%)
[ 6] 2.00-3.00 sec 118 MBytes 990 Mbits/sec 0.009 ms 1/85488 (0.0012%)
[ 6] 3.00-4.00 sec 120 MBytes 1.01 Gbits/sec 0.006 ms 0/87071 (0%)
[ 6] 4.00-5.00 sec 120 MBytes 1.01 Gbits/sec 0.007 ms 0/87053 (0%)
[ 6] 5.00-6.00 sec 116 MBytes 974 Mbits/sec 0.005 ms 1/84095 (0.0012%)
[ 6] 6.00-7.00 sec 121 MBytes 1.02 Gbits/sec 0.010 ms 1/87810 (0.0011%)
[ 6] 7.00-8.00 sec 120 MBytes 1.00 Gbits/sec 0.006 ms 0/86577 (0%)
[ 6] 8.00-9.00 sec 117 MBytes 980 Mbits/sec 0.007 ms 1/84580 (0.0012%)
[ 6] 9.00-10.00 sec 119 MBytes 1.00 Gbits/sec 0.005 ms 0/86398 (0%)
- - - - - - - - - - - - - - - - - - - - - - - - -
Test Complete. Summary Results:
[ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams
[ 6] 0.00-10.00 sec 1.16 GBytes 999 Mbits/sec 0.000 ms 0/860942 (0%) sender
[ 6] 0.00-10.00 sec 1.16 GBytes 997 Mbits/sec 0.005 ms 5/860942 (0.00058%) receiver
Server output:
iperf 3.1.3
Linux ping 4.15.0-47-generic #50-Ubuntu SMP Wed Mar 13 10:44:52 UTC 2019 x86_64
-----------------------------------------------------------
Server listening on 5207
-----------------------------------------------------------
Time: Thu, 09 Jan 2020 21:58:14 GMT
Accepted connection from 82.64.xxx, port 57983
Cookie: bcu7sffkstneqml4no757netfegtf5yrhqlm
[ 7] local 62.210.18.40 port 5207 connected to 82.64.xxx port 60932
Starting Test: protocol: UDP, 1 streams, 1448 byte blocks, omitting 0 seconds, 10 second test
[ ID] Interval Transfer Bandwidth Total Datagrams
[ 7] 0.00-2.00 sec 237 MBytes 995 Mbits/sec 171855
[ 7] 2.00-4.00 sec 238 MBytes 999 Mbits/sec 172531
[ 7] 4.00-6.00 sec 236 MBytes 991 Mbits/sec 171138
[ 7] 6.00-8.00 sec 241 MBytes 1.01 Gbits/sec 174382
[ 7] 8.00-10.00 sec 236 MBytes 990 Mbits/sec 170954
[ 7] 10.00-10.01 sec 2.70 MBytes 1.71 Gbits/sec 1958
- - - - - - - - - - - - - - - - - - - - - - - - -
Test Complete. Summary Results:
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[ 7] 0.00-10.01 sec 1.16 GBytes 998 Mbits/sec 0.000 ms 0/862818 (0%)
CPU Utilization: local/sender 23.0% (2.9%u/20.2%s), remote/receiver 2.6% (0.5%u/2.1%s)
iperf Done.
Avec bande passante 5 Gb/s
ça ne passe pas : "iperf3: error - control socket has closed unexpectedly", soit tout de suite, soit au bout de quelques secondes.
EDIT: + MàJ 1er post avec chiffres jqà 23h ; Bonne nuit.
-
Test Complete. Summary Results:
[ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams
[ 6] 0.00-10.00 sec 1.16 GBytes 999 Mbits/sec 0.000 ms 0/860942 (0%) sender
[ 6] 0.00-10.00 sec 1.16 GBytes 997 Mbits/sec 0.005 ms 5/860942 (0.00058%) receiver
Donc en UDP tu recois bien a 100% (enfin -0.00058%) ce qui est remarquable...mais le serveur distant est en 3.1.3 ce qui ne valide rien car y'a des bugs connus avec UDP et les vieilles versions d'IPerf3.
-
J'ai mis en place un serveur Goben (https://github.com/udhos/goben). C'est un outil comparable a IPerf3 mais plus moderne bien que moins complet.
binaires Goben: https://github.com/udhos/goben/releases
test download en IPv4:
goben -hosts pox-4.nspeed.app -passiveClient
test download en IPv6 :
goben -hosts pox.nspeed.app -passiveClient
Par default Goben teste le download et upload en meme temps d'ou l'option -passiveClient pour couper l'upload (on met -passiveServer a la place si on ne veut que l'upload)
On peut aussi avoir plusieurs flux en meme temps avec l'option "-connections 4" (similaire a "-P 4" d'IPerf3).
Je n'ai pas de serveur 10Gbps public ou de lien Internet 10Gbps sortant de mon labo donc on ne peut tester a plus de 1G :P
L'idée est de comparé a IPerf3 pour voir ce que ca donne. J'ai des meilleurs résultats avec Goben qu'IPerf sur certaines machines.
-
MàJ du matin avec la nuit passée en CUBIC.
Des résultats qui répondent à une de mes questions: le plafond de verre n'en est pas un : il a été allègrement franchi pendant une bonne partie de la nuit !
(pointe mesurée à 7,79 Gbits/s à 5h50)
Vu les résultats plus médiocres en journée / soirée, est-ce à dire qu'il est "moins gênant" quand il y a peu/pas de congestion, et moins performant en cas de congestion ?
Je laisse les nombreux experts réseau & telco de ce forum interpréter...
-
A noter que IPv4 et IPv6 se rejoignent davantage.
Est-ce à dire que les algos sont plus ou moins favorables à une version ou à l'autre ?
En tout cas, il serait intéressant de poursuivre en cubic jusqu'à demain, de sorte de confirmer qu'en journée, on est moins bon que sur illinois (écarter tout effet de "persistance" lié au changement d'algo)
-
Dans le genre pas de bol : plus de jus chez moi... les onduleurs ont couvert 20 min environ, mais ce n'est pas revenu.
Les records de débit ont du faire sauter les plombs ! ;D
Sans doute plus de données jusqu'à ce soir.
-
Je me demandais, comme je suis proche de chez Breizh29 (cf https://lafibre.info/1gb-free/question-debit-en-upload-question-reseau-free/) et que j'ai un serveur avec iperf3.7 et goben dessus (dont Breizh29 a l'adresse) , est ce que ça peut aider même si je suis en mini4k pour le débit.
Le serveur étant en debian, je peux le passer en cubic, reno et bbr.
Je pense bien que ça ne peut pas servir coté test débit, mais peut être algos de congestion ?
Pour info le mtr entre chez moi et chez lui (quand il a du courant) :
HOST: xeon Loss% Snt Last Avg Best Wrst StDev
1. AS12322 2a01:e0a:19b:fMOI::1 0.0% 10 0.3 0.3 0.3 0.3 0.0
2. AS12322 2a01:e03:12:f836:7a45::ffff 0.0% 10 1.9 2.2 1.9 3.0 0.3
3. AS12322 2a01:e03:12:1700::ffff 50.0% 10 2.0 2.1 1.8 2.8 0.4
4. AS12322 2a01:e03:12:1700:fe00::7e2c 0.0% 10 2.6 2.1 1.7 2.6 0.3
5. AS12322 2a01:e0a:1fc:6LUI::1 0.0% 10 1.9 2.2 1.9 2.7 0.3
-
Vu les résultats plus médiocres en journée / soirée, est-ce à dire qu'il est "moins gênant" quand il y a peu/pas de congestion, et moins performant en cas de congestion ?
Je laisse les nombreux experts réseau & telco de ce forum interpréter...
Déja il faut voir sur la durée ce que ca donne.
Apres oui c'est une question de circonstances et d'interaction. Ce qui marche chez toi peut ne pas marcher ailleurs. Il n'y a pas d'algo parfait sinon tout le monde l'utiliserait depuis longtemps, c'est tout le probleme de TCP d'ailleurs.
Quoiqu'il en soit tu as quand meme un souci avec ton debit, il n'est pas normal de devoir monter a 16 flux pour avoir le max.
@esver : ton upload est trop faible pour aider vraiment, il obtiendra sans doute le max quelque soit l'algo. D'autant que la latence est faible entre vous.
Le souci est qu'avec une latence plus élevée (a priori 12 ms vers paris.testdebit.info) il peine sur les connexions uniques (sans -P 16). Pour moi y'a un souci de buffers mais je connais pas MacOs suffisamment pour aider.
Pour ce qui est de l'algo de congestion à mettre dans les serveurs IPerf3: la encore c'est un compromis. On n'a pas de données statistiques suffisantes pour savoir si le cas de Breizh29 est particulier ou représente une moyenne. D'autres signalent des amélioration notable avec bbr. Du coup c'est du pifometre ou de la comm (on prend celui qui 'fait bien' car y'a un graphes joli). Il faudrait collecter les données coté serveur en fonction de l'algo et en déduire ce que la moyenne favorise. Mais personne n'a fait cela pour IPerf3.
En plus il faut de la congestion ce qui n'est le cas que chez Free a priori ...
-
Le souci est qu'avec une latence plus élevée (a priori 12 ms vers paris.testdebit.info) il peine sur les connexions uniques (sans -P 16). Pour moi y'a un souci de buffers mais je connais pas MacOs suffisamment pour aider.
Pour ça, j'ai fait pas mal de tentatives sur différents paramètres de la stack TCP (dont les buffers), en me référant notamment à la littérature en la matière.
Mais je n'ai pas vu d'amélioration spectaculaire... alors je suis revenu aux valeurs natives de l'OS.
Je ferai de nouveaux essais.
-
@esver : ton upload est trop faible pour aider vraiment, il obtiendra sans doute le max quelque soit l'algo. D'autant que la latence est faible entre vous.
On a vu justement qu'entre brr et cubic il y avait des différences de débit et avec brr des Retr élevés (37000) entre chez nous.
-
On a vu justement qu'entre brr et cubic il y avait des différences de débit et avec brr des Retr élevés (37000) entre chez nous.
C'est saturé entre vous...sur le meme NRO ? ce n'est pas bon signe pour Free ca :P
-
On n'est hélas pas sur le même NRO il me semble
Je suis sur
http://francois04.free.fr/connex_dslam.php?dslam=2a01:e03:12:1700:fe00::7a45
et lui sur
http://francois04.free.fr/connex_dslam.php?dslam=2a01:e03:12:1700:fe00::7e2c
mais je n'ai trouvé personne de plus proche.
-
Donc tu es connecté à Miossec, c'est ça ?
Moi je suis sur Quimper Gare, normalement.
-
Oui je suis bien sur Miossec (29232QRM dans mon compte free)
-
Petite mise à jour du matin :)
Toujours des débits qui montent haut, mais on confirme des écarts sur la journée plus importants qu'avec Illinois.
Note: Hier, 10/01/2020, il n'y a pas eu de chiffres entre 9h20 et 17h50 (ces données là étant présentes). Les courbes de tendance s'en ressentent donc.
-
@kgersen et les autres spécialistes :
Pour ce qui est de la pile TCP, voici les valeurs que j'avais positionnées dans mon sysctl.conf (mises en commentaires pour le moment) :
#net.inet.tcp.win_scale_factor=8
#net.inet.tcp.autorcvbufmax=33554432
#net.inet.tcp.autosndbufmax=33554432
#net.inet.tcp.sendspace=1042560
#net.inet.tcp.recvspace=1042560
#net.inet.tcp.mssdflt=1448
#net.inet.tcp.v6mssdflt=1428
#net.inet.tcp.slowstart_flightsize=20
#net.inet.tcp.local_slowstart_flightsize=9
sachant que les valeurs actuelles (et a priori natives) de mon OS pour net.inet.tcp sont :
net.inet.tcp.rfc1644: 0
net.inet.tcp.mssdflt: 512
net.inet.tcp.keepidle: 7200000
net.inet.tcp.keepintvl: 75000
net.inet.tcp.sendspace: 131072
net.inet.tcp.recvspace: 131072
net.inet.tcp.keepinit: 75000
net.inet.tcp.v6mssdflt: 1024
net.inet.tcp.backoff_maximum: 65536
net.inet.tcp.ecn_timeout: 60
net.inet.tcp.disable_tcp_heuristics: 0
net.inet.tcp.clear_tfocache: 0
net.inet.tcp.log_in_vain: 0
net.inet.tcp.blackhole: 0
net.inet.tcp.delayed_ack: 3
net.inet.tcp.tcp_lq_overflow: 1
net.inet.tcp.recvbg: 0
net.inet.tcp.drop_synfin: 1
net.inet.tcp.reass.overflows: 0
net.inet.tcp.slowlink_wsize: 8192
net.inet.tcp.maxseg_unacked: 8
net.inet.tcp.rfc3465: 1
net.inet.tcp.rfc3465_lim2: 1
net.inet.tcp.recv_allowed_iaj: 5
net.inet.tcp.doautorcvbuf: 1
net.inet.tcp.autorcvbufmax: 2097152
net.inet.tcp.lro: 0
net.inet.tcp.lrodbg: 0
net.inet.tcp.lro_startcnt: 4
net.inet.tcp.disable_access_to_stats: 1
net.inet.tcp.challengeack_limit: 10
net.inet.tcp.do_rfc5961: 1
net.inet.tcp.rcvsspktcnt: 512
net.inet.tcp.rexmt_thresh: 3
net.inet.tcp.path_mtu_discovery: 1
net.inet.tcp.slowstart_flightsize: 1
net.inet.tcp.local_slowstart_flightsize: 8
net.inet.tcp.tso: 1
net.inet.tcp.ecn_setup_percentage: 100
net.inet.tcp.ecn_initiate_out: 2
net.inet.tcp.ecn_negotiate_in: 2
net.inet.tcp.packetchain: 50
net.inet.tcp.socket_unlocked_on_output: 1
net.inet.tcp.rfc3390: 1
net.inet.tcp.min_iaj_win: 16
net.inet.tcp.acc_iaj_react_limit: 200
net.inet.tcp.doautosndbuf: 1
net.inet.tcp.autosndbufinc: 8192
net.inet.tcp.autosndbufmax: 2097152
net.inet.tcp.ack_prioritize: 1
net.inet.tcp.rtt_recvbg: 1
net.inet.tcp.recv_throttle_minwin: 16384
net.inet.tcp.enable_tlp: 1
net.inet.tcp.sack: 1
net.inet.tcp.sack_maxholes: 128
net.inet.tcp.sack_globalmaxholes: 65536
net.inet.tcp.sack_globalholes: 0
net.inet.tcp.fastopen_backlog: 10
net.inet.tcp.fastopen: 3
net.inet.tcp.now_init: 35215102
net.inet.tcp.microuptime_init: 758579
net.inet.tcp.minmss: 216
net.inet.tcp.do_tcpdrain: 0
net.inet.tcp.pcbcount: 88
net.inet.tcp.tw_pcbcount: 0
net.inet.tcp.icmp_may_rst: 1
net.inet.tcp.rtt_min: 100
net.inet.tcp.rexmt_slop: 200
net.inet.tcp.randomize_ports: 0
net.inet.tcp.win_scale_factor: 3
net.inet.tcp.init_rtt_from_cache: 1
net.inet.tcp.tcbhashsize: 4096
net.inet.tcp.keepcnt: 8
net.inet.tcp.msl: 15000
net.inet.tcp.max_persist_timeout: 0
net.inet.tcp.always_keepalive: 0
net.inet.tcp.timer_fastmode_idlemax: 10
net.inet.tcp.broken_peer_syn_rexmit_thres: 10
net.inet.tcp.tcp_timer_advanced: 157
net.inet.tcp.tcp_resched_timerlist: 92483
net.inet.tcp.pmtud_blackhole_detection: 1
net.inet.tcp.pmtud_blackhole_mss: 1200
net.inet.tcp.cc_debug: 0
net.inet.tcp.newreno_sockets: 0
net.inet.tcp.background_sockets: 0
net.inet.tcp.cubic_sockets: 87
net.inet.tcp.use_newreno: 0
net.inet.tcp.cubic_tcp_friendliness: 0
net.inet.tcp.cubic_fast_convergence: 0
net.inet.tcp.cubic_use_minrtt: 0
net.inet.tcp.lro_sz: 8
net.inet.tcp.lro_time: 10
net.inet.tcp.bg_target_qdelay: 100
net.inet.tcp.bg_allowed_increase: 8
net.inet.tcp.bg_tether_shift: 1
net.inet.tcp.bg_ss_fltsz: 2
net.inet.tcp.log.level_info: 0
net.inet.tcp.log.enable: 0
net.inet.tcp.log.enable_usage: connection:0x1 rtt:0x2 ka:0x4 loop:0x10 local:0x20 gw:0x40 syn:0x100 fin:0x200 rst:0x400 dropnecp:0x1000 droppcb:0x2000 droppkt:0x4000
net.inet.tcp.log.rtt_port: 0
net.inet.tcp.log.thflags_if_family: 0
net.inet.tcp.log.privacy: 1
net.inet.tcp.log.rate_limit: 600
net.inet.tcp.log.rate_duration: 60
net.inet.tcp.log.rate_max: 0
net.inet.tcp.log.rate_exceeded_total: 0
net.inet.tcp.log.rate_current: 0
Si jamais vous aviez des idées d'amélioration étant donné les constats sur les iperf...
Merci d'avance.
-
sur *BSD dont MacOs s'inspire, pour du 10G on met:
# ajuster le max ipc du noyau car la pile tcp/ip utilise ipc
kern.ipc.maxsockbuf=16777216
# ajuster les max tcp
net.inet.tcp.recvspace=131072
net.inet.tcp.sendspace=131072
net.inet.tcp.sendbuf_max=16777216 (autosndbufmax sur Mac ?)
net.inet.tcp.recvbuf_max=16777216 (autorcvbufmax sur Mac ?)
net.inet.tcp.sendbuf_inc=65536
net.inet.tcp.recvbuf_inc=65536
le point important c'est que le max tcp ne peut dépasser le max ipc.
Apres y'a peut-etre des trucs spécifiques MacOS, attention toutefois a ne pas chercher a appliquer des trucs "anciens" a la version actuelle c'est souvent le souci de copier/coller ce qu'on lit sans comprendre ;D
et bien backup les valeurs actuelles avant de faire des changements.
Le mieux serait de trouver la doc officiel Apple pour sysctl, apres on peut chercher nous meme les valeurs a changer.
-
OK merci.
Voici quelques éléments complémentaires :
http://newosxbook.com/bonus/vol1ch16.html
(ce n'est pas la tout dernière version, mais c'est une bonne base je pense)
-
Mise à jour du matin (9h20).
Comportement similaire à celui de la veille.
-
Mise à jour de 8h10 ce jour.
@Vivien : le comportement entrevu ces derniers jours se confirme (amplitude plus forte avec cet algo par rapport à Illinois). Si tu y vois un intérêt, on peut passer à un autre algo (ou autres modifications utiles sur le serveur) dans la journée.
-
Je suis revenu a illinois depuis 9h45, qui permet d'avoir des résultats plus homogènes et j'ai rajouté une nouvelle modification :
# Désactiver la mémorisation des tests précédents afin d'éviter que le serveur bride les tests suite à une performances limitée
net.ipv4.tcp_no_metrics_save=1
Cela permet que chaque test soit indépendant des précédents, ce qui n'était pas le cas avant.
Voici la liste de mes optimisation : J'ai créer le fichier /etc/sysctl.d/19-patch-swappiness.conf pour que les modif soient permanentes :
# Reduce the swap
vm.swappiness = 2
# Reduce the threshold where a DDOS impacts the server
net.ipv4.tcp_max_syn_backlog = 2048
# TCP congestion control protocol for high-speed and long-distance networks
net.ipv4.tcp_congestion_control=illinois
#net.ipv4.tcp_congestion_control=bbr
# Désactiver la mémorisation des tests précédents afin d'éviter que le serveur bride les tests suite à une performances limitée
net.ipv4.tcp_no_metrics_save=1
# Increase TCP buffers
net.ipv4.tcp_rmem=4096 87380 16777216
net.ipv4.tcp_wmem=4096 65536 16777216
net.core.rmem_max=851968
net.core.wmem_max=851968
# default queuing discipline for 10GigE speeds
net.core.default_qdisc=fq
# Increase the queue within the Linux kernel where traffic is stored after reception from the NIC
net.core.netdev_max_backlog=4000
# Increase number of incoming connections
net.core.somaxconn = 512
Depuis la migration Ubuntu 18.04 (il y 18 mois) la modification net.core.default_qdisc=fq ne fonctionne plus.
Quand je vérifie je suis en fq_codel savez-vous pourquoi ?
# cat /proc/sys/net/core/default_qdisc
fq_codel
Ubuntu 16.04 avec le même fichier :
$ cat /proc/sys/net/core/default_qdisc
fq
A noter, avec un Ubuntu 16.04 de base (sans modification) on est en pfifo_fast
$ cat /proc/sys/net/core/default_qdisc
pfifo_fast
Autre optimisation qu'il me semble intéressante à tester, porter l'initCwnd de 10 à 90.
(je ne modifie pas tout en même temps, c'est pour une prochaine optim)
-
C'est marrant, tu viens à peine de repasser à Illinois, et les premières mesures semblent déjà montrer que l'IPv6 est défavorisée par rapport à l'IPv4
date; ipv4 ; ipv6
20200113 09:50:00 6,4 6,04
20200113 10:00:00 6,46 6,2
20200113 10:10:00 6,51 6,03
20200113 10:20:00 6,23 6,37
20200113 10:30:00 6,62 6,09
20200113 10:40:00 7,02 6,17
20200113 10:50:00 6,54 6,07
20200113 11:00:00 6,87 6,03
20200113 11:10:00 6,41 6,1
20200113 11:20:00 6,49 6,15
20200113 11:30:00 6,55 6,19
20200113 11:40:00 6,48 6,12
-
A mon avis, Illinois n'a aucun intérêt. Il date d'avant cubic.
sur un kernel récent, default_qdisc a la valeur par défaut suffit (pfifo_fast) d'autant si le serveur ne sert que de speedtest.
'tc -s qdisc show dev eth0' pour voir ce qui est actif.
Pour un serveur speedtest dédié, ce qui est plus inquiétant est d'utiliser Ubuntu 18.04 plutôt qu'une distrib plus a jour niveau kernel/driver (archlinux par exemple).
Ubuntu c'est la voiture familiale pépère , si on veut exploiter a fond son matériel ce n'est pas trop ce que je recommenderai. Apres si le serveur est surdimensionné ca peut le faire.
-
C'est marrant, tu viens à peine de repasser à Illinois, et les premières mesures semblent déjà montrer que l'IPv6 est défavorisée par rapport à l'IPv4
date; ipv4 ; ipv6
20200113 09:50:00 6,4 6,04
20200113 10:00:00 6,46 6,2
20200113 10:10:00 6,51 6,03
20200113 10:20:00 6,23 6,37
20200113 10:30:00 6,62 6,09
20200113 10:40:00 7,02 6,17
20200113 10:50:00 6,54 6,07
20200113 11:00:00 6,87 6,03
20200113 11:10:00 6,41 6,1
20200113 11:20:00 6,49 6,15
20200113 11:30:00 6,55 6,19
20200113 11:40:00 6,48 6,12
Désolé, ca a déjà du être demandé, mais tu passes par des routes/transitaires similaires en v4 et v6 ?
-
Oui, Vivien avait vérifié.
Concernant IPv4 / IPv6, j'avais déjà fait cette remarque au début des tests. Cet écart avait disparu avec Cubic, et est revenu depuis que Vivien a remis Illinois.
-
Ok, merci pour les précisions :)
-
A mon avis, Illinois n'a aucun intérêt. Il date d'avant cubic.
Pourtant la plupart des outil de test débit recommandent de changer Cubis par Illinois.
Je reconnais que ce n'est pas super représentatif d'où mon intérêt pour BBR, plus représentatif.
Pour un serveur speedtest dédié, ce qui est plus inquiétant est d'utiliser Ubuntu 18.04 plutôt qu'une distrib plus a jour niveau kernel/driver (archlinux par exemple).
J'ai fait un comparatif il y a quelques années de différents OS serveur et Ubuntu arrivait clairement en tête : https://lafibre.info/serveur-linux/comparatif-os-server/
(pour ce comparatif, je suis resté avec les paramètres par défaut proposés)
Pour le noyaux Linux utilisé, il est régulièrement mis à jour. Si tu installe Ubuntu 18.04.4, tu peut voir que le noyau par défaut est le noyau HWE, aujourd'hui en version 5.3
Pour le parc installé avec le noyau HWE, la migration du noyau 5.0 vers le noyau 5.3 va intervenir cette semaine. Si vous n'êtes pas sur un noyau HWE, le commande sont dans le sujet Linux 4.18 : gain de performance sur certains serveurs (https://lafibre.info/serveur-linux/linux-4-18/)
-
Mon point c'est juste que Ubuntu n'est pas de base une distro de type 'Rolling release'. T'es obligé de faire la manip que t'indique pour avoir un pseudo rolling release partiel du noyau. Dans le cadre d'un usage desktop ou server généraliste (si cette notion existe...) pourquoi pas mais dans le cadre d'un serveur dédié test de débit une distro rolling release a plus de sens. Par exemple ton iperf3 n'est pas a jour car tu dépend des packages Ubuntu.
Pour ce qui est des comparatifs de performance pour moi ca n'a pas de sens, une bonne installation doit être 'tuner' par rapport a l'usage qu'on veut en faire. Un comparatif 'synthétique' généraliste n'apporte aucune information utile si on veut faire un serveur speedtest (iperf ou autre) dédié.
-
Mise à jour de ce matin 8h.
Comme on pouvait le supposer, on retrouve le comportement Illinois du début avec des amplitudes moindres.
D'un côté cela homogénéise les débits, comme Vivien l'a dit précédemment, de l'autre, c'est dommage, pour un serveur de speedtest, de ne pas livrer un résultat plus proche du max possible de la connexion...
@Vivien :
Nouvelles optimisations prévues ? ou on essaie un autre algo ? ou autre ?
-
a 10h20, je suis passé de fq_codel à fq :
Avant :
# tc qdisc show
qdisc noqueue 0: dev lo root refcnt 2
qdisc mq 0: dev enp1s0f0 root
qdisc fq_codel 0: dev enp1s0f0 parent :10 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 32Mb ecn
qdisc fq_codel 0: dev enp1s0f0 parent :f limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 32Mb ecn
qdisc fq_codel 0: dev enp1s0f0 parent :e limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 32Mb ecn
qdisc fq_codel 0: dev enp1s0f0 parent :d limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 32Mb ecn
qdisc fq_codel 0: dev enp1s0f0 parent :c limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 32Mb ecn
qdisc fq_codel 0: dev enp1s0f0 parent :b limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 32Mb ecn
qdisc fq_codel 0: dev enp1s0f0 parent :a limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 32Mb ecn
qdisc fq_codel 0: dev enp1s0f0 parent :9 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 32Mb ecn
qdisc fq_codel 0: dev enp1s0f0 parent :8 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 32Mb ecn
qdisc fq_codel 0: dev enp1s0f0 parent :7 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 32Mb ecn
qdisc fq_codel 0: dev enp1s0f0 parent :6 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 32Mb ecn
qdisc fq_codel 0: dev enp1s0f0 parent :5 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 32Mb ecn
qdisc fq_codel 0: dev enp1s0f0 parent :4 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 32Mb ecn
qdisc fq_codel 0: dev enp1s0f0 parent :3 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 32Mb ecn
qdisc fq_codel 0: dev enp1s0f0 parent :2 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 32Mb ecn
qdisc fq_codel 0: dev enp1s0f0 parent :1 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 32Mb ecn
Après :
# tc qdisc add dev enp1s0f0 root fq
# tc qdisc show
qdisc noqueue 0: dev lo root refcnt 2
qdisc fq 8001: dev enp1s0f0 root refcnt 65 limit 10000p flow_limit 100p buckets 1024 orphan_mask 1023 quantum 3028 initial_quantum 15140 low_rate_threshold 550Kbit refill_delay 40.0ms
-
Mise à jour de ce matin 8h20 après une apm / soirée / nuit de test.
Le résultat est plutôt médiocre, ça semble plutôt se détériorer par rapport à l'ancien paramétrage.
Vivien, qu'envisages-tu pour la suite, le cas échéant ?
-
Hello, je me joins à la partie samedi, j'aurai mon accès Freebox 10G.
-
Depuis 12h10, chute de presque 2 Gbits/s...
Hasard ou Vivien a touché aux réglages ? ;D
EDIT: ça se confirme à 12h20 (baisse encore un peu...)
-
Je confirme, mon fichier avec les optimisation n'est plus pris en compte.
J'ai cherché et j'ai compris pourquoi net.core.default_qdisc=fq n'était pas pris en compte : il était appliqué trop tôt.
J'ai donc supprimer le fichier /etc/sysctl.d/19-patch-swappiness.conf pour mettre /etc/sysctl.d/90-server-optimization
90 arrivant après 19, la configuration est cette fois-ci bonne (j'ai fais les test sur Ubuntu 19.10)
Dans les modifications il y a aussi :
net.ipv4.tcp_wmem=4096 65536 16777216
par :
net.ipv4.tcp_wmem=4096 87380 16777216
87380 fait parti des recommandations "IBM's High Performance Computing page"
Coté rmem on passe de :
net.ipv4.tcp_rmem=4096 87380 16777216
A :
net.ipv4.tcp_rmem=4096 131072 16777216
Voici le fichier :
nano /etc/sysctl.d/90-server-optimization
# Reduce the swap
vm.swappiness = 1
# Reduce the threshold where a DDOS impacts the server
net.ipv4.tcp_max_syn_backlog = 4096
# TCP congestion control protocol for high-speed and long-distance networks
net.ipv4.tcp_congestion_control=illinois
#net.ipv4.tcp_congestion_control=bbr
# Désactiver la mémorisation des tests précédents afin d'éviter que le serveur bride les tests suite à une performances limitée
net.ipv4.tcp_no_metrics_save=1
# 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
# default queuing discipline for 10GigE speeds
net.core.default_qdisc=fq
# Increase the queue within the Linux kernel where traffic is stored after reception from the NIC
net.core.netdev_max_backlog=4000
# Increase number of incoming connections
net.core.somaxconn = 512
Là le gros souci c'est que aucune de ces optimisation n'est prise en compte.
Je bosse dessus.
-
OK merci.
Bon courage.
-
erreur de débutant, j'ai oublié un .conf à l'extension du fichier (et j'ai cherché a beaucoup d'autres choses avant de trover)
C'est ok depuis 12h58
Je suis intéressé pour les données entre les deux.
Outre l'augmentation de la Rwin expliquée avant, on a donc maintenant un fq différent.
Avant je passais en fq via la commande tc qdisc add dev enp1s0f0 root fq, maintenant c'est via net.core.default_qdisc=fq qui est dans le fichier /etc/sysctl.d/90-server-optimization.conf
Avant :
# tc qdisc show
qdisc noqueue 0: dev lo root refcnt 2
qdisc fq 8001: dev enp1s0f0 root refcnt 65 limit 10000p flow_limit 100p buckets 1024 orphan_mask 1023 quantum 3028 initial_quantum 15140 low_rate_threshold 550Kbit refill_delay 40.0ms
Maintenant :
$ tc qdisc show
qdisc noqueue 0: dev lo root refcnt 2
qdisc mq 0: dev enp1s0f0 root
qdisc fq 0: dev enp1s0f0 parent :10 limit 10000p flow_limit 100p buckets 1024 orphan_mask 1023 quantum 3028 initial_quantum 15140 low_rate_threshold 550Kbit refill_delay 40.0ms
qdisc fq 0: dev enp1s0f0 parent :f limit 10000p flow_limit 100p buckets 1024 orphan_mask 1023 quantum 3028 initial_quantum 15140 low_rate_threshold 550Kbit refill_delay 40.0ms
qdisc fq 0: dev enp1s0f0 parent :e limit 10000p flow_limit 100p buckets 1024 orphan_mask 1023 quantum 3028 initial_quantum 15140 low_rate_threshold 550Kbit refill_delay 40.0ms
qdisc fq 0: dev enp1s0f0 parent :d limit 10000p flow_limit 100p buckets 1024 orphan_mask 1023 quantum 3028 initial_quantum 15140 low_rate_threshold 550Kbit refill_delay 40.0ms
qdisc fq 0: dev enp1s0f0 parent :c limit 10000p flow_limit 100p buckets 1024 orphan_mask 1023 quantum 3028 initial_quantum 15140 low_rate_threshold 550Kbit refill_delay 40.0ms
qdisc fq 0: dev enp1s0f0 parent :b limit 10000p flow_limit 100p buckets 1024 orphan_mask 1023 quantum 3028 initial_quantum 15140 low_rate_threshold 550Kbit refill_delay 40.0ms
qdisc fq 0: dev enp1s0f0 parent :a limit 10000p flow_limit 100p buckets 1024 orphan_mask 1023 quantum 3028 initial_quantum 15140 low_rate_threshold 550Kbit refill_delay 40.0ms
qdisc fq 0: dev enp1s0f0 parent :9 limit 10000p flow_limit 100p buckets 1024 orphan_mask 1023 quantum 3028 initial_quantum 15140 low_rate_threshold 550Kbit refill_delay 40.0ms
qdisc fq 0: dev enp1s0f0 parent :8 limit 10000p flow_limit 100p buckets 1024 orphan_mask 1023 quantum 3028 initial_quantum 15140 low_rate_threshold 550Kbit refill_delay 40.0ms
qdisc fq 0: dev enp1s0f0 parent :7 limit 10000p flow_limit 100p buckets 1024 orphan_mask 1023 quantum 3028 initial_quantum 15140 low_rate_threshold 550Kbit refill_delay 40.0ms
qdisc fq 0: dev enp1s0f0 parent :6 limit 10000p flow_limit 100p buckets 1024 orphan_mask 1023 quantum 3028 initial_quantum 15140 low_rate_threshold 550Kbit refill_delay 40.0ms
qdisc fq 0: dev enp1s0f0 parent :5 limit 10000p flow_limit 100p buckets 1024 orphan_mask 1023 quantum 3028 initial_quantum 15140 low_rate_threshold 550Kbit refill_delay 40.0ms
qdisc fq 0: dev enp1s0f0 parent :4 limit 10000p flow_limit 100p buckets 1024 orphan_mask 1023 quantum 3028 initial_quantum 15140 low_rate_threshold 550Kbit refill_delay 40.0ms
qdisc fq 0: dev enp1s0f0 parent :3 limit 10000p flow_limit 100p buckets 1024 orphan_mask 1023 quantum 3028 initial_quantum 15140 low_rate_threshold 550Kbit refill_delay 40.0ms
qdisc fq 0: dev enp1s0f0 parent :2 limit 10000p flow_limit 100p buckets 1024 orphan_mask 1023 quantum 3028 initial_quantum 15140 low_rate_threshold 550Kbit refill_delay 40.0ms
qdisc fq 0: dev enp1s0f0 parent :1 limit 10000p flow_limit 100p buckets 1024 orphan_mask 1023 quantum 3028 initial_quantum 15140 low_rate_threshold 550Kbit refill_delay 40.0ms
-
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
-
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 ?
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 :
(https://lafibre.info/images/wireshark/201110_augmentation_tcp_initial_congestion_window_comparaison_2.png)
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
(https://lafibre.info/images/logo/logo_google_research.png)
Google research à publié en juillet 2010 un PDF An Argument for Increasing TCP’s Initial Congestion Window (http://research.google.com/pubs/archive/36640.pdf).
La RFC datait de 2002 : RFC Increasing TCP's Initial Window - October 2002 (http://www.ietf.org/rfc/rfc3390.txt)
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 :
(https://lafibre.info/images/wireshark/201110_augmentation_tcp_initial_congestion_window_google.png)
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 (http://tools.ietf.org/html/rfc3390) 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 (http://research.google.com/pubs/archive/36640.pdf)). 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 :
(https://lafibre.info/images/wireshark/201110_augmentation_tcp_initial_congestion_window_comparaison.png)
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.
-
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é ?
-
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.
-
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. :P 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:
$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:
$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.
-
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... :P
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 ;)
-
J'avais l'habitude de faire aussi des optimisation sur des test monothread, cela change un peu.
Éventuellement mettre les buffers a 16Mo max si ce n'est deja pas le cas.
Quels buffers ?
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 :
(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).
Bien mettre IPerf3 3.7 a jour.
Oui, c'est dans ma todo liste à court terme.
-
Quand DamienC sera de la partie ca sera plus clair deja.
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.
-
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)
-
Quels buffers ?
Les net.core.wmem_max et autres tcp_wmem mais je crois que c'est déjà le cas sur ton serveur.
-
J'ai ça actuellement :
# 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
net.core.rmem=851968
net.core.wmem=851968
Mais je ne pense pas que ce soit une bonne idée.
-
+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 ? :P
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 !
-
Les net.core.wmem_max et autres tcp_wmem mais je crois que c'est déjà le cas sur ton serveur.
Iperf a déjà l'option -w pour ça qui utilise setsockopt() / SO_SNDBUF / SO_RCVBUF.
Le max peut être augmenté éventuellement si on veut dépasser les 16 Mo max sur le serveur de vivien.
-
17h21 :
J'ai mis à jour le script et tout juste commencé à collecter en plus les données en monothread.
J'en ai profité pour retirer l'option "-w 4m" de l'ensemble des tests, vu qu'elle pouvait potentiellement interférer avec des optimisations serveur, si je comprends bien.
Il me faut maintenant gérer l'aspect graphique...
Donc à présent, dans l'ordre :
IPv4 - 1 thread : iperf3 -c $serveur -R -t 20 -O 5 -p $numPort -4 -P 1 -f g
IPv6 - 1 thread : iperf3 -c $serveur -R -t 20 -O 5 -p $numPort -6 -P 1 -f g
IPv4 - 16 threads : iperf3 -c $serveur -R -t 20 -O 5 -p $numPort -4 -P 16 -f g
IPv6 - 16 threads : iperf3 -c $serveur -R -t 20 -O 5 -p $numPort -6 -P 16 -f g
-
J'ai ça actuellement :
# 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
Il me semble que net.core.[rw]mem_max prend le pas sur la valeur max de net.ipv4.tcp_[rw]mem (contrairement à la valeur par défaut).
Si c'est vrai, ça voudrait dire que sur ton serveur, les buffers TCP ne peuvent pas dépasser 832Ko.
https://www.ibm.com/support/knowledgecenter/linuxonibm/liaag/wkvm/wkvm_c_tune_tcpip.htm (https://www.ibm.com/support/knowledgecenter/linuxonibm/liaag/wkvm/wkvm_c_tune_tcpip.htm)
net.ipv4.tcp_wmem
Similar to the net.ipv4.tcp_rmem this parameter consists of 3 values, a minimum, default, and maximum.
The minimum represents the smallest receive buffer size a newly created socket is entitled to as part of its creation. The minimum value defaults to 1 page or 4096 bytes.
The default value represents the initial size of a TCP sockets receive buffer. This value supersedes net.core.rmem_default used by other protocols. It is typically set lower than net.core.wmem_default. The default value for this setting is 16K bytes.
The maximum represents the largest receive buffer size for auto-tuned send buffers for TCP sockets. This value does not override net.core.rmem_max. The default value for this setting is somewhere between 64K bytes and 4M bytes based on the amount of memory available in the system.
The recommendation is to use the maximum value of 16M bytes or higher (kernel level dependent) especially for 10 Gigabit adapters.
-
Merci Thornhill, la documentation est claire.
Ce qui est étonnant, c'est qu'il me semble que cela n'avait pas été modifié pour des test très haut débit dans les DROM avec un serveur sur Paris (donc forte latence) sur une connexion TCP.
J'ai augmenté la valeur à 16777216 :
net.ipv4.tcp_rmem=4096 131072 16777216
net.ipv4.tcp_wmem=4096 87380 16777216
net.core.rmem_max=16777216
net.core.wmem_max=16777216
Note Breizh29: cela ne change rien pour tes tests: cela impact les tests avec une forte latence.
Je me demande si il faut que j'augmente net.ipv4.tcp_mem :
# cat /proc/sys/net/ipv4/tcp_mem
381555 508741 763110
-
Ce qui est étonnant, c'est qu'il me semble que cela n'avait pas été modifié pour des test très haut débit dans les DROM avec un serveur sur Paris (donc forte latence) sur une connexion TCP.
Ces valeurs ne jouent que pour le tuning automatique des buffers, si l'outil de test utilise setsockopt() / SO_SNDBUF / SO_RCVBUF comme peut le faire iperf3 avec l'option -w, il passera outre ces valeurs.
Pour tcp_mem, c'est une valeur globale pour toutes les sockets, en pages de 4k, donc tu es déjà à 2 Go pour pressure et 3 Go pour max (en dessous de pressure il ne diminue pas les buffers en autotuning).
https://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt (https://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt)
tcp_rmem - vector of 3 INTEGERs: min, default, max
min: Minimal size of receive buffer used by TCP sockets.
It is guaranteed to each TCP socket, even under moderate memory pressure.
Default: 4K
default: initial size of receive buffer used by TCP sockets.
This value overrides net.core.rmem_default used by other protocols.
Default: 87380 bytes. This value results in window of 65535 with default setting of tcp_adv_win_scale and tcp_app_win:0 and a bit less for default tcp_app_win. See below about these variables.
max: maximal size of receive buffer allowed for automatically
selected receiver buffers for TCP socket. This value does not override net.core.rmem_max. Calling setsockopt() with SO_RCVBUF disables automatic tuning of that socket's receive buffer size, in which case this value is ignored.
Default: between 87380B and 6MB, depending on RAM size.
tcp_mem - vector of 3 INTEGERs: min, pressure, max
min: below this number of pages TCP is not bothered about its
memory appetite.
pressure: when amount of memory allocated by TCP exceeds this number of pages, TCP moderates its memory consumption and enters memory pressure mode, which is exited when memory consumption falls under "min".
max: number of pages allowed for queueing by all TCP sockets.
Defaults are calculated at boot time from amount of available
memory.
-
On y mettra un goben, vous m'aiderez à le compiler sous macos et on fera ça au mieux !
Goben est déja compilé pour Mac : https://github.com/udhos/goben/releases
Il te faut télécharger 'goben_darwin_amd64' (darwin = pour Mac).
Fais ensuite un test avec :
goben -hosts pox-4.nspeed.app -passiveClientpuis
goben -hosts pox-6.nspeed.app -passiveClient
-
Et pourquoi ne pas tester l'algo CAIA (module cdg du noyau) ?
-
Goben est déja compilé pour Mac : https://github.com/udhos/goben/releases
Ah ben désolé, j'avais pas fait gaffe qu'il y avait un binaire darwin...
OK, je regarde ça dès que possible (Vivien, envisages-tu l'installation du module serveur ?)
-
Mise à jour de ce matin 8h sur le graphe multithread + ajout d'une première version d'un graphe monothread.
Côté multi, pas de changement franchement notable du comportement.
Côté mono, c'est plus stable que ce que mes premiers tests me laissaient penser...
-
A 8h47, j'ai basculé initcwnd de 10 à 90, uniquement pour le trafic IPv4
Concrètement, j'ai rajouté une ligne qui change la route par défaut avec initcwnd 90 en plus.
iface enp1s0f0 inet static
address 89.84.1.186
netmask 255.255.255.248
gateway 89.84.1.185
post-up /sbin/ip route change default via 89.84.1.185 dev enp1s0f0 initcwnd 90
-
A 15h03, j'ai basculé initcwnd de 10 à 90, pour le trafic IPv6: On a donc IPv4 et IPv6 qui sont tous les deux en initcwnd 90
iface enp1s0f0 inet6 static
address 2001:860:de01:1100::2
netmask 64
gateway 2001:860:de01:1100::1
post-up /sbin/ip -6 route change default via 2001:860:de01:1100::1 dev enp1s0f0 initcwnd 90
accept_ra 0
dns-nameservers 2001:860:b0ff:1::1 2001:860:b0ff:1::2
Demain matin je recommence les tests de différents algorithme de congestion TCP en gardant les optimisations actuelles.
- Aujourd'hui : Illinois, l'algorithme qui était souvent proposés pour des très haut débit (qdisc fq)
- Demain : Cubic l'algorithme par défaut de presque tous les Linux (qdisc fq)
- Après-demain : Cubic (test avec qdisc fq_codel)
- Les jours suivants : BBR sensé être l'algorithme miracle.
-
A 5h56 ce matin, j'ai basculé sur le noyau 5.3 (avant on était sur le noyau 5.0)
Cela pourrait apporter des améliorations (ou pas)
Avant :
$ uname -srvmpio
Linux 5.0.0-37-generic #40~18.04.1-Ubuntu SMP Thu Nov 14 12:06:39 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
Maintenant :
$ uname -srvmpio
Linux 5.3.0-26-generic #28~18.04.1-Ubuntu SMP Wed Dec 18 16:40:14 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
-
Mise à jour de ce matin, 8h.
Question: en monothread, pourquoi ne dépasse-t-on jamais 1,3 Gb/s environ (là, c'est flagrant) ?
Est-ce une limite liée au paramétrage de la pile TCP ? du PC ?
-
Depuis 9h32 on est passé en cubic pour l'algorithme d'évitement de congestion TCP.
Avant on était en illinois.
Petit rectificatif : le passage du kernel 5.0 au kernel 5.3 s'est fait à 5h56 ce matin et non 6h56.
On semble voir que cela ne change rien dans ton graphique, de même que les nombreuses optimisations réalisées les deux jours précédents.
-
@Vivien
Je ne sais pas encore si ça vient de chez moi ou de tes changements, mais je n'arrive plus à avoir des résultats en IPv6 depuis tes modifs... timeout sur tous les n° de port.
J'ai pas trop d'accès de là où je travaille, donc ma capacité d'analyse est limitée.
Peux-tu jeter un oeil de ton côté ?
EDIT: bon je regarderai dès que je pourrai, mais le truc est parti en vrille suite à l'intervention.
-
Bon, je confirme que tous les lancements iperf3 en IPv6 tombent en timeout, port après port...
-
Pas de soucis de mon coté, en ipv6 ça passe sans soucis via paris.testdebit.info
moon@Freeze:[~] > iperf3 -f m -c paris.testdebit.info -p 5205 -6 -R -P4 -t 2
Connecting to host paris.testdebit.info, port 5205
Reverse mode, remote host paris.testdebit.info is sending
[ 5] local 2a01:e0a:1d2:xxxx::xxxx:xxxx port 48850 connected to 2001:860:de01:1100::2 port 5205
[ 7] local 2a01:e0a:1d2:xxxx::xxxx:xxxx port 48852 connected to 2001:860:de01:1100::2 port 5205
[ 9] local 2a01:e0a:1d2:xxxx::xxxx:xxxx port 48854 connected to 2001:860:de01:1100::2 port 5205
[ 11] local 2a01:e0a:1d2:xxxx::xxxx:xxxx port 48856 connected to 2001:860:de01:1100::2 port 5205
[ ID] Interval Transfer Bitrate
[ 5] 0.00-1.00 sec 26.9 MBytes 226 Mbits/sec
[ 7] 0.00-1.00 sec 25.4 MBytes 213 Mbits/sec
[ 9] 0.00-1.00 sec 24.8 MBytes 208 Mbits/sec
[ 11] 0.00-1.00 sec 26.8 MBytes 225 Mbits/sec
[SUM] 0.00-1.00 sec 104 MBytes 871 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ 5] 1.00-2.00 sec 27.9 MBytes 234 Mbits/sec
[ 7] 1.00-2.00 sec 29.3 MBytes 246 Mbits/sec
[ 9] 1.00-2.00 sec 22.7 MBytes 190 Mbits/sec
[ 11] 1.00-2.00 sec 30.8 MBytes 258 Mbits/sec
[SUM] 1.00-2.00 sec 111 MBytes 928 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-2.00 sec 56.9 MBytes 239 Mbits/sec 125 sender
[ 5] 0.00-2.00 sec 54.8 MBytes 230 Mbits/sec receiver
[ 7] 0.00-2.00 sec 56.8 MBytes 238 Mbits/sec 131 sender
[ 7] 0.00-2.00 sec 54.7 MBytes 230 Mbits/sec receiver
[ 9] 0.00-2.00 sec 49.6 MBytes 208 Mbits/sec 94 sender
[ 9] 0.00-2.00 sec 47.5 MBytes 199 Mbits/sec receiver
[ 11] 0.00-2.00 sec 59.6 MBytes 250 Mbits/sec 124 sender
[ 11] 0.00-2.00 sec 57.6 MBytes 241 Mbits/sec receiver
[SUM] 0.00-2.00 sec 223 MBytes 935 Mbits/sec 474 sender
[SUM] 0.00-2.00 sec 215 MBytes 900 Mbits/sec receiver
iperf Done.
-
OK, alors je vais tenter un reboot machine...
C'est marrant, aucun problème en IPv4, mais plus rien en IPv6
-
Après reboot machine, c'est bon en IPv6 aussi.
A n'y rien comprendre...
-
C'est pas en rapport avec le DNS ?
-
Je n'ai pas répondu, mais le serveur a toujours sont trafic habituel.
Le pb c'était le port iperf3 occupé ?
J'ai prévu un changement des ports iPerf3 quand je passerais à la nouvelle version.
Il y aura plus de ports disponibles.
Aujourd'hui : Apache écoute du port 1 au port 32767 (sauf les ports 5200 à 5209 qui écoutent avec iPerf3) pour des tests de neutralité.
Demain : du port 1 au port 9199, car il n'y a pas d'application intéressante à tester au delà de 9051 (Tor). Les ports iPerf3 seront à la suite, du port 9200 à 9222, soit 23 ports contre 10 aujourd'hui.
-
Modification du jour (à 9h42) :
Passer de fq (généralement recommandé pour du 10 Gb/s) à fq_codel (défault pour Ubuntu 18.04)
On avait vu une baisse de débit en passant à fq_codel, je voudrais voir si c'est bien lié à en revenant en arrière sachant que l'on reste sur cubic en algo de congestion TCP.
Avant :
# cat /proc/sys/net/core/default_qdisc
fq
# tc qdisc show
qdisc noqueue 0: dev lo root refcnt 2
qdisc mq 0: dev enp1s0f0 root
qdisc fq 0: dev enp1s0f0 parent :10 limit 10000p flow_limit 100p buckets 1024 orphan_mask 1023 quantum 3028 initial_quantum 15140 low_rate_threshold 550Kbit refill_delay 40.0ms
qdisc fq 0: dev enp1s0f0 parent :f limit 10000p flow_limit 100p buckets 1024 orphan_mask 1023 quantum 3028 initial_quantum 15140 low_rate_threshold 550Kbit refill_delay 40.0ms
qdisc fq 0: dev enp1s0f0 parent :e limit 10000p flow_limit 100p buckets 1024 orphan_mask 1023 quantum 3028 initial_quantum 15140 low_rate_threshold 550Kbit refill_delay 40.0ms
qdisc fq 0: dev enp1s0f0 parent :d limit 10000p flow_limit 100p buckets 1024 orphan_mask 1023 quantum 3028 initial_quantum 15140 low_rate_threshold 550Kbit refill_delay 40.0ms
qdisc fq 0: dev enp1s0f0 parent :c limit 10000p flow_limit 100p buckets 1024 orphan_mask 1023 quantum 3028 initial_quantum 15140 low_rate_threshold 550Kbit refill_delay 40.0ms
qdisc fq 0: dev enp1s0f0 parent :b limit 10000p flow_limit 100p buckets 1024 orphan_mask 1023 quantum 3028 initial_quantum 15140 low_rate_threshold 550Kbit refill_delay 40.0ms
qdisc fq 0: dev enp1s0f0 parent :a limit 10000p flow_limit 100p buckets 1024 orphan_mask 1023 quantum 3028 initial_quantum 15140 low_rate_threshold 550Kbit refill_delay 40.0ms
qdisc fq 0: dev enp1s0f0 parent :9 limit 10000p flow_limit 100p buckets 1024 orphan_mask 1023 quantum 3028 initial_quantum 15140 low_rate_threshold 550Kbit refill_delay 40.0ms
qdisc fq 0: dev enp1s0f0 parent :8 limit 10000p flow_limit 100p buckets 1024 orphan_mask 1023 quantum 3028 initial_quantum 15140 low_rate_threshold 550Kbit refill_delay 40.0ms
qdisc fq 0: dev enp1s0f0 parent :7 limit 10000p flow_limit 100p buckets 1024 orphan_mask 1023 quantum 3028 initial_quantum 15140 low_rate_threshold 550Kbit refill_delay 40.0ms
qdisc fq 0: dev enp1s0f0 parent :6 limit 10000p flow_limit 100p buckets 1024 orphan_mask 1023 quantum 3028 initial_quantum 15140 low_rate_threshold 550Kbit refill_delay 40.0ms
qdisc fq 0: dev enp1s0f0 parent :5 limit 10000p flow_limit 100p buckets 1024 orphan_mask 1023 quantum 3028 initial_quantum 15140 low_rate_threshold 550Kbit refill_delay 40.0ms
qdisc fq 0: dev enp1s0f0 parent :4 limit 10000p flow_limit 100p buckets 1024 orphan_mask 1023 quantum 3028 initial_quantum 15140 low_rate_threshold 550Kbit refill_delay 40.0ms
qdisc fq 0: dev enp1s0f0 parent :3 limit 10000p flow_limit 100p buckets 1024 orphan_mask 1023 quantum 3028 initial_quantum 15140 low_rate_threshold 550Kbit refill_delay 40.0ms
qdisc fq 0: dev enp1s0f0 parent :2 limit 10000p flow_limit 100p buckets 1024 orphan_mask 1023 quantum 3028 initial_quantum 15140 low_rate_threshold 550Kbit refill_delay 40.0ms
qdisc fq 0: dev enp1s0f0 parent :1 limit 10000p flow_limit 100p buckets 1024 orphan_mask 1023 quantum 3028 initial_quantum 15140 low_rate_threshold 550Kbit refill_delay 40.0ms
Maintenant :
$ cat /proc/sys/net/core/default_qdisc
fq_codel
# tc qdisc show
qdisc noqueue 0: dev lo root refcnt 2
qdisc mq 0: dev enp1s0f0 root
qdisc fq_codel 0: dev enp1s0f0 parent :10 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 32Mb ecn
qdisc fq_codel 0: dev enp1s0f0 parent :f limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 32Mb ecn
qdisc fq_codel 0: dev enp1s0f0 parent :e limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 32Mb ecn
qdisc fq_codel 0: dev enp1s0f0 parent :d limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 32Mb ecn
qdisc fq_codel 0: dev enp1s0f0 parent :c limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 32Mb ecn
qdisc fq_codel 0: dev enp1s0f0 parent :b limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 32Mb ecn
qdisc fq_codel 0: dev enp1s0f0 parent :a limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 32Mb ecn
qdisc fq_codel 0: dev enp1s0f0 parent :9 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 32Mb ecn
qdisc fq_codel 0: dev enp1s0f0 parent :8 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 32Mb ecn
qdisc fq_codel 0: dev enp1s0f0 parent :7 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 32Mb ecn
qdisc fq_codel 0: dev enp1s0f0 parent :6 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 32Mb ecn
qdisc fq_codel 0: dev enp1s0f0 parent :5 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 32Mb ecn
qdisc fq_codel 0: dev enp1s0f0 parent :4 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 32Mb ecn
qdisc fq_codel 0: dev enp1s0f0 parent :3 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 32Mb ecn
qdisc fq_codel 0: dev enp1s0f0 parent :2 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 32Mb ecn
qdisc fq_codel 0: dev enp1s0f0 parent :1 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 32Mb ecn
-
Mise à jour à 13h30.
- En multithread, on retrouve le comportement précédemment observé avec Cubic. Cela dit, la chute d'hier soir semble moindre que lors des précédentes tentatives : effet des autres optimisations peut-être ? on tient peut-être une alternative avantageuse à Illinois, surtout si on peut encore améliorer. A confirmer sur la durée.
- En mono thread, moins de stabilité on dirait. Effet week-end peut-être ?
-
"tc -s qdisc show dev enp1s0f0" c'est plus utile.
Je ne vois pas pourquoi tu cherches a changer la qdisc sur le serveur, tu veux privilégier un traffic plus qu'un autre ? y'a quoi d'autre sur ce serveur en plus d'IPerf3 ?
(l'histoire du qdisc fq pour BBR ne concernait que les anciens kernel. la confusion vient peut-etre de la)
-
Le serveur a été presque 24h avec Cubic + qdisc=fq et les débits sont restés comme en illinois, avec un meilleur débit en IPv4 vs IPv6.
Depuis 9h32 on est passé en cubic pour l'algorithme d'évitement de congestion TCP.
Avant on était en illinois.
"tc -s qdisc show dev enp1s0f0" c'est plus utile.
Voila :
$ tc -s qdisc show dev enp1s0f0
qdisc mq 0: root
Sent 2882198390815 bytes 2059419059 pkt (dropped 0, overlimits 0 requeues 72039)
backlog 0b 0p requeues 72039
qdisc fq_codel 0: parent :10 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 32Mb ecn
Sent 356733539433 bytes 257715765 pkt (dropped 0, overlimits 0 requeues 5856)
backlog 0b 0p requeues 5856
maxpacket 68264 drop_overlimit 0 new_flow_count 37136 ecn_mark 0
new_flows_len 0 old_flows_len 0
qdisc fq_codel 0: parent :f limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 32Mb ecn
Sent 730126997402 bytes 513812841 pkt (dropped 0, overlimits 0 requeues 23906)
backlog 0b 0p requeues 23906
maxpacket 68264 drop_overlimit 0 new_flow_count 149626 ecn_mark 0
new_flows_len 0 old_flows_len 0
qdisc fq_codel 0: parent :e limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 32Mb ecn
Sent 345974573962 bytes 247635138 pkt (dropped 0, overlimits 0 requeues 5230)
backlog 0b 0p requeues 5230
maxpacket 68264 drop_overlimit 0 new_flow_count 36085 ecn_mark 0
new_flows_len 0 old_flows_len 0
qdisc fq_codel 0: parent :d limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 32Mb ecn
Sent 682679426134 bytes 480775485 pkt (dropped 0, overlimits 0 requeues 22553)
backlog 0b 0p requeues 22553
maxpacket 68796 drop_overlimit 0 new_flow_count 130776 ecn_mark 0
new_flows_len 0 old_flows_len 0
qdisc fq_codel 0: parent :c limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 32Mb ecn
Sent 183780202712 bytes 132185123 pkt (dropped 0, overlimits 0 requeues 2898)
backlog 0b 0p requeues 2898
maxpacket 68796 drop_overlimit 0 new_flow_count 11586 ecn_mark 0
new_flows_len 0 old_flows_len 0
qdisc fq_codel 0: parent :b limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 32Mb ecn
Sent 184874910117 bytes 135001884 pkt (dropped 0, overlimits 0 requeues 3509)
backlog 0b 0p requeues 3509
maxpacket 68264 drop_overlimit 0 new_flow_count 15505 ecn_mark 0
new_flows_len 0 old_flows_len 0
qdisc fq_codel 0: parent :a limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 32Mb ecn
Sent 197856694076 bytes 147393790 pkt (dropped 0, overlimits 0 requeues 4581)
backlog 0b 0p requeues 4581
maxpacket 68796 drop_overlimit 0 new_flow_count 32582 ecn_mark 0
new_flows_len 0 old_flows_len 0
qdisc fq_codel 0: parent :9 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 32Mb ecn
Sent 200172044499 bytes 144899011 pkt (dropped 0, overlimits 0 requeues 3506)
backlog 0b 0p requeues 3506
maxpacket 68130 drop_overlimit 0 new_flow_count 19855 ecn_mark 0
new_flows_len 0 old_flows_len 0
qdisc fq_codel 0: parent :8 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 32Mb ecn
Sent 220 bytes 2 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
maxpacket 0 drop_overlimit 0 new_flow_count 0 ecn_mark 0
new_flows_len 0 old_flows_len 0
qdisc fq_codel 0: parent :7 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 32Mb ecn
Sent 110 bytes 1 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
maxpacket 0 drop_overlimit 0 new_flow_count 0 ecn_mark 0
new_flows_len 0 old_flows_len 0
qdisc fq_codel 0: parent :6 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 32Mb ecn
Sent 110 bytes 1 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
maxpacket 0 drop_overlimit 0 new_flow_count 0 ecn_mark 0
new_flows_len 0 old_flows_len 0
qdisc fq_codel 0: parent :5 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 32Mb ecn
Sent 110 bytes 1 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
maxpacket 0 drop_overlimit 0 new_flow_count 0 ecn_mark 0
new_flows_len 0 old_flows_len 0
qdisc fq_codel 0: parent :4 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 32Mb ecn
Sent 680 bytes 6 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
maxpacket 0 drop_overlimit 0 new_flow_count 0 ecn_mark 0
new_flows_len 0 old_flows_len 0
qdisc fq_codel 0: parent :3 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 32Mb ecn
Sent 330 bytes 3 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
maxpacket 0 drop_overlimit 0 new_flow_count 0 ecn_mark 0
new_flows_len 0 old_flows_len 0
qdisc fq_codel 0: parent :2 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 32Mb ecn
Sent 480 bytes 4 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
maxpacket 0 drop_overlimit 0 new_flow_count 0 ecn_mark 0
new_flows_len 0 old_flows_len 0
qdisc fq_codel 0: parent :1 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 32Mb ecn
Sent 440 bytes 4 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
maxpacket 0 drop_overlimit 0 new_flow_count 0 ecn_mark 0
new_flows_len 0 old_flows_len 0
Je n'ai pas bien compris, tu ne me conseillait pas de mettre fq pour le qudisc, à la place du fq_codel ?
en 2020, tout le monde devrait être en BBR mais pas mal de distro ne font pas l'effort de le mettre par défaut.
pour changer:
sudo sysctl net.ipv4.tcp_congestion_control=bbr
sudo sysctl net.core.default_qdisc=fq
(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).
Donc si je comprends bien avec un kernel récent on ne touche pas au qdsic (il n'y a pas qu'iPerf sur ce serveur, il y a aussi Apache également pour des tests de débit)
-
Ce n'est peut-être plus pertinent, mais le wiki bufferbloat recommande ceci :
For servers with tcp-heavy workloads, particularly at 10GigE speeds, for queue management, we recomend sch_fq instead of fq_codel as of linux 3.12.
(Tiré de : https://www.bufferbloat.net/projects/codel/wiki/#binary-code-and-kernels-for-linux-based-operating-systems)
EDIT :
Commentaire plus récent (2018) sur GitHub (le reste du thread est intéressant aussi) : https://github.com/systemd/systemd/issues/9725#issuecomment-412286509
sch_fq is for tcp-serving heavy workloads, primarily from the datacenter, and does nothing sane for other forms of traffic including acks in the reverse direction. IF all you are doing is tcp serving at 10gigE+, sch_fq is totally the right thing. Otherwise it can actually be worse than pfifo_fast! At 1gigE, sch_fq's defaults are set too high (for example) for even your typical nas or laptop.
-
8h13 : J'ai juste remis la ligne net.core.default_qdisc=fq dans mon fichier /etc/sysctl.d/90-server-optimization.conf pour quelques heures afin de vérifier qu'il y a bien de nouveau une forte dégradation des débits.
Ensuite je passerais à BBR
-
Surprise en monothread le nuit dernière, où bien que l'instabilité soit de mise, j'ai réussi à atteindre des niveaux de débit proches du max multithread et du théorique tout court.
Hier soir, j'ai ré-appliqué des modifications sur la pile TCP (taille des buffers largement augmentée...) que j'avais entreprises avant la réalisation du graphe monothread, et qui doivent probablement expliquer ce phénomène.
Mais pourquoi est-il si flagrant, et uniquement en heures très creuses ? J'avoue que l'ampleur m'étonne, tout comme les brutalités de la hausse et surtout de la baisse.
Pour détails, voici les chiffres depuis ce matin 1h, heure à laquelle j'ai stoppé toute intervention sur ma machine :
Date ; IPv4 multi ; IPv6 multi ; IPv4 mono ; IPv6 mono
20200119 01:00:00 5,42 6,47 0,37 1,59
20200119 01:10:00 5,72 6 0,65 0,8
20200119 01:20:00 6,29 6,95 0,99 1,22
20200119 01:30:00 6,85 7,03 1,2 2,36
20200119 01:40:00 6,3 7,17 1,24 2,5
20200119 01:50:01 6,75 7,03 1,32 1,42
20200119 02:00:00 6,66 7,11 1,78 4,14
20200119 02:10:00 6,58 7,39 1,84 3,21
20200119 02:20:00 6,92 7,48 2,34 2,46
20200119 02:30:01 6,85 7,38 2,38 2,02
20200119 02:40:00 7,04 7,45 1,43 6,09
20200119 02:50:00 6,9 7,38 2,55 4,67
20200119 03:00:00 6,99 7,44 2,37 3,45
20200119 03:10:00 7,03 7,37 3,6 5,87
20200119 03:20:00 6,35 7,31 5,15 4,41
20200119 03:30:00 7,16 7,44 4,94 4,79
20200119 03:40:00 7,12 7,41 2,33 7,2
20200119 03:50:00 6,95 7,34 1,73 5,54
20200119 04:00:00 7,31 7,62 3,04 6,87
20200119 04:10:00 7,23 7,21 3,86 6,61
20200119 04:20:00 7,4 7,56 2,12 6,45
20200119 04:30:00 7,1 7,65 6,51 5,2
20200119 04:40:00 7,48 7,6 7,1 6,5
20200119 04:50:00 7,46 7,68 6,66 6,63
20200119 05:00:00 7,25 7,63 5,2 7,08
20200119 05:10:00 7,08 7,34 5,75 7,1
20200119 05:20:00 7,51 7,64 6,32 3,46
20200119 05:30:00 7,52 7,71 6,3 7,2
20200119 05:40:00 7,6 7,59 5,81 7,09
20200119 05:50:01 7,66 7,7 3,4 6,18
20200119 06:00:00 7,46 7,68 4,52 7,18
20200119 06:10:00 7,38 7,56 2,54 7,19
20200119 06:20:01 7,75 7,63 4,68 7,1
20200119 06:30:00 7,45 7,7 7,08 7
20200119 06:40:01 7,42 7,16 5,07 6,37
20200119 06:50:00 7,54 7,62 3,94 4,92
20200119 07:00:00 7,68 7,36 6,17 7,03
20200119 07:10:00 7,54 7,51 7,09 7,19
20200119 07:20:00 7,55 7,46 5,61 2,8
20200119 07:30:00 7,45 7,68 4,01 6,92
20200119 07:40:00 7,64 7,66 5,33 1,54
20200119 07:50:01 7,57 7,51 3,76 2,52
20200119 08:00:00 7,52 7,8 3,25 5,16
20200119 08:10:00 7,28 7,56 1,16 7,18
20200119 08:20:00 7,06 7,15 4,47 5,19
20200119 08:30:01 7,22 7,57 2,48 6,54
20200119 08:40:00 7,26 7,15 4,46 6,7
20200119 08:50:00 7,12 7,22 4,15 3,97
20200119 09:00:01 7,18 7,13 0,53 3,32
20200119 09:10:00 6,58 6,11 1,06 1,7
20200119 09:20:00 6,25 6,46 1,59 1,59
20200119 09:30:01 6,49 6,49 1,01 1,33
20200119 09:40:00 6,44 6,31 2,08 1,32
20200119 09:50:00 6,46 6,7 0,97 0,49
20200119 10:00:00 6,39 6,71 0,54 1,8
20200119 10:10:00 6,26 6,44 0,96 1,24
20200119 10:20:00 6,35 6,6 1,02 1,58
20200119 10:30:00 5 5,06 1,26 1,46
20200119 10:40:01 5,78 5,8 0,93 0,55
20200119 10:50:00 5,77 6,02 1,18 0,74
20200119 11:00:00 5,91 6,05 0,77 1,31
20200119 11:10:00 5,91 6,33 0,84 1,02
20200119 11:20:00 5,96 6,22 0,57 0,83
20200119 11:30:00 4,78 5,98 0,59 1,28
20200119 11:40:00 6,09 5,7 0,78 1,39
@Vivien : si tu souhaites les mesures de certains créneaux horaires pour analyser toi-même les impacts de tes changements, fais le moi savoir.
-
Les graphiques :
(https://lafibre.info/images/free_debit/202001_free_tests_debit_multithread.png)
(https://lafibre.info/images/free_debit/202001_free_tests_debit_monothread.png)
@Vivien : si tu souhaites les mesures de certains créneaux horaires pour analyser toi-même les impacts de tes changements, fais le moi savoir.
Il serait intéressant de garder les graphiques historique et de mettre sur un graphique qui commence le 19/01 les 4 tests sur le même graphique avec 4 couleurs différentes
Tu fait comment pour générer ces graphiques avec une aussi grande résolution ? Je supposait que c'était Excel mais je ne vois pas de fonction d'export (et vu la résolution cela ne dois pas être une capture d'écran, sauf si tu es en 4k)
Je note que en monothread tu as un meilleur débit en IPv6.
Finalement, le week-end la saturation démarre tôt (il y a bien une baisse à 8h00, mais pas sur que cela soit ma modification) et il n'est pas pertinent de faire une seconde modification en cours de journée.
Je passe en BBR demain matin.
-
Oui impressionnant l'écart. On n'a pas de visibilité sur ce qui passe coté serveur (crosstalk notamment) du coup difficile de dire ou est la cause.
par contre :
Le serveur a été presque 24h avec Cubic + qdisc=fq et les débits sont restés comme en illinois, avec un meilleur débit en IPv4 vs IPv6.
Voila :
$ tc -s qdisc show dev enp1s0f0
qdisc mq 0: root
Sent 2882198390815 bytes 2059419059 pkt (dropped 0, overlimits 0 requeues 72039)
backlog 0b 0p requeues 72039
qdisc fq_codel 0: parent :10 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 32Mb ecn
Sent 356733539433 bytes 257715765 pkt (dropped 0, overlimits 0 requeues 5856)
backlog 0b 0p requeues 5856
maxpacket 68264 drop_overlimit 0 new_flow_count 37136 ecn_mark 0
new_flows_len 0 old_flows_len 0
qdisc fq_codel 0: parent :f limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 32Mb ecn
Sent 730126997402 bytes 513812841 pkt (dropped 0, overlimits 0 requeues 23906)
backlog 0b 0p requeues 23906
maxpacket 68264 drop_overlimit 0 new_flow_count 149626 ecn_mark 0
new_flows_len 0 old_flows_len 0
qdisc fq_codel 0: parent :e limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 32Mb ecn
Sent 345974573962 bytes 247635138 pkt (dropped 0, overlimits 0 requeues 5230)
backlog 0b 0p requeues 5230
maxpacket 68264 drop_overlimit 0 new_flow_count 36085 ecn_mark 0
new_flows_len 0 old_flows_len 0
qdisc fq_codel 0: parent :d limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 32Mb ecn
Sent 682679426134 bytes 480775485 pkt (dropped 0, overlimits 0 requeues 22553)
backlog 0b 0p requeues 22553
maxpacket 68796 drop_overlimit 0 new_flow_count 130776 ecn_mark 0
new_flows_len 0 old_flows_len 0
qdisc fq_codel 0: parent :c limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 32Mb ecn
Sent 183780202712 bytes 132185123 pkt (dropped 0, overlimits 0 requeues 2898)
backlog 0b 0p requeues 2898
maxpacket 68796 drop_overlimit 0 new_flow_count 11586 ecn_mark 0
new_flows_len 0 old_flows_len 0
qdisc fq_codel 0: parent :b limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 32Mb ecn
Sent 184874910117 bytes 135001884 pkt (dropped 0, overlimits 0 requeues 3509)
backlog 0b 0p requeues 3509
maxpacket 68264 drop_overlimit 0 new_flow_count 15505 ecn_mark 0
new_flows_len 0 old_flows_len 0
qdisc fq_codel 0: parent :a limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 32Mb ecn
Sent 197856694076 bytes 147393790 pkt (dropped 0, overlimits 0 requeues 4581)
backlog 0b 0p requeues 4581
maxpacket 68796 drop_overlimit 0 new_flow_count 32582 ecn_mark 0
new_flows_len 0 old_flows_len 0
qdisc fq_codel 0: parent :9 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 32Mb ecn
Sent 200172044499 bytes 144899011 pkt (dropped 0, overlimits 0 requeues 3506)
backlog 0b 0p requeues 3506
maxpacket 68130 drop_overlimit 0 new_flow_count 19855 ecn_mark 0
new_flows_len 0 old_flows_len 0
qdisc fq_codel 0: parent :8 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 32Mb ecn
Sent 220 bytes 2 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
maxpacket 0 drop_overlimit 0 new_flow_count 0 ecn_mark 0
new_flows_len 0 old_flows_len 0
qdisc fq_codel 0: parent :7 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 32Mb ecn
Sent 110 bytes 1 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
maxpacket 0 drop_overlimit 0 new_flow_count 0 ecn_mark 0
new_flows_len 0 old_flows_len 0
qdisc fq_codel 0: parent :6 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 32Mb ecn
Sent 110 bytes 1 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
maxpacket 0 drop_overlimit 0 new_flow_count 0 ecn_mark 0
new_flows_len 0 old_flows_len 0
qdisc fq_codel 0: parent :5 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 32Mb ecn
Sent 110 bytes 1 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
maxpacket 0 drop_overlimit 0 new_flow_count 0 ecn_mark 0
new_flows_len 0 old_flows_len 0
qdisc fq_codel 0: parent :4 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 32Mb ecn
Sent 680 bytes 6 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
maxpacket 0 drop_overlimit 0 new_flow_count 0 ecn_mark 0
new_flows_len 0 old_flows_len 0
qdisc fq_codel 0: parent :3 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 32Mb ecn
Sent 330 bytes 3 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
maxpacket 0 drop_overlimit 0 new_flow_count 0 ecn_mark 0
new_flows_len 0 old_flows_len 0
qdisc fq_codel 0: parent :2 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 32Mb ecn
Sent 480 bytes 4 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
maxpacket 0 drop_overlimit 0 new_flow_count 0 ecn_mark 0
new_flows_len 0 old_flows_len 0
qdisc fq_codel 0: parent :1 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 32Mb ecn
Sent 440 bytes 4 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
maxpacket 0 drop_overlimit 0 new_flow_count 0 ecn_mark 0
new_flows_len 0 old_flows_len 0
ca fait beaucoup de lignes la je trouve. t'as configurer comment ton qdisc ?
reset:
sudo tc -p qdisc delete dev enp1s0f0 rootpuis ajoute
sudo tc -p qdisc add dev enp1s0f0 root fq_codel (ou fq)
Je n'ai pas bien compris, tu ne me conseillait pas de mettre fq pour le qudisc, à la place du fq_codel ?
Donc si je comprends bien avec un kernel récent on ne touche pas au qdsic (il n'y a pas qu'iPerf sur ce serveur, il y a aussi Apache également pour des tests de débit)
oui fallait mettre fq si le kernel est ancien car bbr nécessite impérativement fq sur un ancien kernel. Sur un nouveau kernel on peut garder le qdisc en place.
Apres dans le code source de BBR il est mentionné que ne pas mettre fq engendre plus de conso de ressource. Donc autant mettre fq quand on utilise bbr.
-
Oui impressionnant l'écart. On n'a pas de visibilité sur ce qui passe coté serveur (crosstalk notamment) du coup difficile de dire ou est la cause.
Coté serveur, la charge est stable :
(https://lafibre.info/images/stats/202001_stats_bouygues_iperf_day.png) (https://lafibre.info/images/stats/202001_stats_bouygues_iperf_week.png)
Je suis intéressé pour connaître en détail l'optimisation que tu as fait pour MacOS , cela servira a d'autres utilisateurs.
-
ca fait beaucoup de lignes la je trouve. t'as configurer comment ton qdisc ?
C'est sans aucune modification.
Sur un Ubuntu 18.04 sans aucun tunning, ni logiciel installé à part Apache qui écoute sur le port 80 et 443, j'ai :
$ tc -s qdisc show dev eno1
qdisc mq 0: root
Sent 3176 bytes 44 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
qdisc fq_codel 0: parent :1 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 32Mb ecn
Sent 3176 bytes 44 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
maxpacket 0 drop_overlimit 0 new_flow_count 0 ecn_mark 0
new_flows_len 0 old_flows_len 0
$ tc -s qdisc show dev eno2
qdisc mq 0: root
Sent 3106 bytes 43 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
qdisc fq_codel 0: parent :1 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 32Mb ecn
Sent 3106 bytes 43 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
maxpacket 0 drop_overlimit 0 new_flow_count 0 ecn_mark 0
new_flows_len 0 old_flows_len 0
$ tc -s qdisc show dev enp2s0f0
qdisc mq 0: root
Sent 8692466210818 bytes 1532106743 pkt (dropped 0, overlimits 0 requeues 136326)
backlog 0b 0p requeues 136326
qdisc fq_codel 0: parent :8 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 32Mb ecn
Sent 1096363650344 bytes 735096903 pkt (dropped 0, overlimits 0 requeues 19701)
backlog 0b 0p requeues 19701
maxpacket 68796 drop_overlimit 0 new_flow_count 26095 ecn_mark 0
new_flows_len 0 old_flows_len 0
qdisc fq_codel 0: parent :7 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 32Mb ecn
Sent 1062000567154 bytes 711774005 pkt (dropped 0, overlimits 0 requeues 11640)
backlog 0b 0p requeues 11640
maxpacket 68796 drop_overlimit 0 new_flow_count 5803 ecn_mark 0
new_flows_len 0 old_flows_len 0
qdisc fq_codel 0: parent :6 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 32Mb ecn
Sent 1093329258305 bytes 732950108 pkt (dropped 0, overlimits 0 requeues 19320)
backlog 0b 0p requeues 19320
maxpacket 68952 drop_overlimit 0 new_flow_count 19959 ecn_mark 0
new_flows_len 0 old_flows_len 0
qdisc fq_codel 0: parent :5 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 32Mb ecn
Sent 1099425254672 bytes 737179948 pkt (dropped 0, overlimits 0 requeues 20945)
backlog 0b 0p requeues 20945
maxpacket 69564 drop_overlimit 0 new_flow_count 22746 ecn_mark 0
new_flows_len 0 old_flows_len 0
qdisc fq_codel 0: parent :4 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 32Mb ecn
Sent 1102078737978 bytes 738920622 pkt (dropped 0, overlimits 0 requeues 19732)
backlog 0b 0p requeues 19732
maxpacket 73160 drop_overlimit 0 new_flow_count 20769 ecn_mark 0
new_flows_len 0 old_flows_len 0
qdisc fq_codel 0: parent :3 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 32Mb ecn
Sent 1086794275891 bytes 728217355 pkt (dropped 0, overlimits 0 requeues 11444)
backlog 0b 0p requeues 11444
maxpacket 68952 drop_overlimit 0 new_flow_count 5824 ecn_mark 0
new_flows_len 0 old_flows_len 0
qdisc fq_codel 0: parent :2 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 32Mb ecn
Sent 1077302264082 bytes 722130461 pkt (dropped 0, overlimits 0 requeues 16181)
backlog 0b 0p requeues 16181
maxpacket 69564 drop_overlimit 0 new_flow_count 11720 ecn_mark 0
new_flows_len 0 old_flows_len 0
qdisc fq_codel 0: parent :1 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 32Mb ecn
Sent 1075172202392 bytes 720804637 pkt (dropped 0, overlimits 0 requeues 17363)
backlog 0b 0p requeues 17363
maxpacket 68796 drop_overlimit 0 new_flow_count 14398 ecn_mark 0
new_flows_len 0 old_flows_len 0
Bref, pour moi c'est lié au pilote.
Les deux premières cartes sont :
04:00.0 Ethernet controller: Broadcom Inc. and subsidiaries NetXtreme BCM5720 Gigabit Ethernet PCIe
Subsystem: Dell NetXtreme BCM5720 Gigabit Ethernet PCIe
Flags: bus master, fast devsel, latency 0, IRQ 16
Memory at 95a30000 (64-bit, prefetchable) [size=64K]
Memory at 95a40000 (64-bit, prefetchable) [size=64K]
Memory at 95a50000 (64-bit, prefetchable) [size=64K]
Expansion ROM at 90200000 [disabled] [size=256K]
Capabilities: [48] Power Management version 3
Capabilities: [50] Vital Product Data
Capabilities: [58] MSI: Enable- Count=1/8 Maskable- 64bit+
Capabilities: [a0] MSI-X: Enable+ Count=17 Masked-
Capabilities: [ac] Express Endpoint, MSI 00
Capabilities: [100] Advanced Error Reporting
Capabilities: [13c] Device Serial Number 00-00-50-9a-4c-6d-b2-22
Capabilities: [150] Power Budgeting <?>
Capabilities: [160] Virtual Channel
Kernel driver in use: tg3
Kernel modules: tg3
La dernière est :
02:00.0 Ethernet controller: Intel Corporation Ethernet Controller X710 for 10GbE SFP+ (rev 01)
Subsystem: Intel Corporation Ethernet 10G 2P X710 Adapter
Flags: bus master, fast devsel, latency 0, IRQ 17
Memory at 92000000 (64-bit, prefetchable) [size=16M]
Memory at 93008000 (64-bit, prefetchable) [size=32K]
Expansion ROM at 90100000 [disabled] [size=512K]
Capabilities: [40] Power Management version 3
Capabilities: [50] MSI: Enable- Count=1/1 Maskable+ 64bit+
Capabilities: [70] MSI-X: Enable+ Count=129 Masked-
Capabilities: [a0] Express Endpoint, MSI 00
Capabilities: [e0] Vital Product Data
Capabilities: [100] Advanced Error Reporting
Capabilities: [140] Device Serial Number e0-1d-1a-ff-ff-fe-fd-3c
Capabilities: [150] Alternative Routing-ID Interpretation (ARI)
Capabilities: [1a0] Transaction Processing Hints
Capabilities: [1b0] Access Control Services
Capabilities: [1d0] #19
Kernel driver in use: i40e
Kernel modules: i40e
C'est du haut de gamme, le chips (connecté en PCIe 3) sait gérer le un dual-port 40 GbE, dual-port 25 GbE ou quad-port 10 GbE.
Edit, si il y a une chose que j'ai rajouté sur ce serveur qui n'est pas par défaut :
#!/bin/dash
# Limiter le nombre de sessions tcp par client (un client = une IPv4 ou un /64 en IPv6)
/sbin/iptables -A INPUT -p tcp --syn -m connlimit --connlimit-above 600 -m limit --limit 30/hour --limit-burst 1 -j LOG --log-prefix="drop-c-"
/sbin/iptables -A INPUT -p tcp --syn -m connlimit --connlimit-above 600 -j REJECT
/sbin/ip6tables -A INPUT -p tcp --syn -m connlimit --connlimit-above 600 --connlimit-mask 64 -m limit --limit 30/hour --limit-burst 1 -j LOG --log-prefix="drop-c-"
/sbin/ip6tables -A INPUT -p tcp --syn -m connlimit --connlimit-above 600 --connlimit-mask 64 -j REJECT
-
Tu fait comment pour générer ces graphiques avec une aussi grande résolution ? Je supposait que c'était Excel mais je ne vois pas de fonction d'export (et vu la résolution cela ne dois pas être une capture d'écran, sauf si tu es en 4k)
Oui, pour aller plus vite, ce sont bien des captures d'Excel, sur un écran 4K.
Je vais essayer de regrouper...
Je note que en monothread tu as un meilleur débit en IPv6.
Effectivement, ça semble bien être le cas.
-
Je suis intéressé pour connaître en détail l'optimisation que tu as fait pour MacOS , cela servira a d'autres utilisateurs.
La voici.
Sachant qu'on n'est pour l'instant pas absolument certain que le changement provienne de ces modifications.
Comme je suis sous Catalina, la modification suivante est à opérer en mode recovery (boot en maintenant cmd + R, puis utiliser le terminal) :
nvram boot-args="ncl=262144"
Pour le reste, voici les valeurs de mon /etc/sysctl.conf :
kern.ipc.maxsockbuf=33554432
kern.ipc.somaxconn=2048
net.inet.tcp.sendspace=4194304
net.inet.tcp.recvspace=4194304
net.inet.tcp.win_scale_factor=8
net.inet.tcp.autorcvbufmax=33554432
net.inet.tcp.autosndbufmax=33554432
net.inet.tcp.slowstart_flightsize=20
net.inet.tcp.local_slowstart_flightsize=9
net.inet.tcp.mssdflt=1432
net.inet.tcp.v6mssdflt=1452
Note: c'est empirique, il y a sûrement encore pas mal de sources d'optimisation, et plein d'autres entrées à tuner.
Pour les valeurs de MSS, j'ai essayé de les déduire à partir des infos trouvées sur un autre fil de ce forum sur la MTU pour Free en zone FTTH 10G-EPON.
Par ailleurs, je suis preneur de conseils, car il s'agit de tests empiriques à partir de diverses lectures (que j'ai quand même essayé de comprendre, hein...).
Car bien que du métier, je ne suis spécialisé ni en réseau, ni en système.
-
Je conseillerais de ne pas toucher la MSS.
Comme expliqué dans le sujet Négociation MTU MSS: comment ça fonctionne ? (https://lafibre.info/tcpip/negociation-mtu-comment-ca-fonctionne/) si un équipement a beoin de le réduire la MSS, il va modifier à la volée dans les paquets [SYN] / [SYN-ACK] qui passent par lui.
Je ne connais pas le mac, mais pourquoi se mettre en mode recovery ?
-
Je ne connais pas le mac, mais pourquoi se mettre en mode recovery ?
Uniquement pour la modification des boot-args, depuis une des dernières versions de macOS, on est obligé de passer en mode recovery : même un sudo, qui suffisait avant, ne passe plus.
Augmenter le ncl (par défaut à 65536) est un passage obligatoire pour monter kern.ipc.maxsockbuf au-delà de 8 Mo.
Pour les autres, un sudo sysctl -w xxx=yyyy en mode classique suffit pour tester à chaud, avant de confirmer à chaque démarrage via sysctl.conf.
-
Je conseillerais de ne pas toucher la MSS.
Par défaut, les valeurs sont :
net.inet.tcp.mssdflt: 512
net.inet.tcp.v6mssdflt: 1024
Tu me conseilles de repasser à ces valeurs ?
-
Une MSS de 512 octets ?
Ce serait la valeur minimale ? (c'est a peine plus élevée que le minimum permis par la norme. Oui en IPv6 la MSS min à augmentée)
Si c'était la valeur par défaut, cela voudrait dire que tu ne met pas grand chose dans tes paquets !
Wireshark permet vite de voir la vraie valeur.
-
Une MSS de 512 octets ?
Ce serait la valeur minimale ? (c'est a peine plus élevée que le minimum permis par la norme. Oui en IPv6 la MSS min à augmentée)
Si c'était la valeur par défaut, cela voudrait dire que tu ne met pas grand chose dans tes paquets !
Wireshark permet vite de voir la vraie valeur.
Si j'en crois http://newosxbook.com/bonus/vol1ch16.html, c'est bien le cas.
[v6]mssdflt [0x400]/0x200 Default TCP Maximum Segment Size
Et en provenance de : https://rolande.wordpress.com/2014/05/17/performance-tuning-the-network-stack-on-mac-os-x-part-2/
The default MSS value that Apple has configured is a measly 512 bytes. That setting value is really targeted to be optimal for dial-up users or users with fairly slow broadband connections ~3Mbps and below
-
C'est sans aucune modification.
...
C'est le nombre de queues matérielles du drivers (visible avec ls -ld /sys/class/net/enp2s0f0/queues/tx*') mais on dirait que tu en as 8 pour enp2s0f0 et 16 pour enp1s0f0 ?
Ce qui étonne c'est la disparité des compteurs "Sent" dans le 1er tc que tu as posté par rapport au deuxieme.
Quand on fait 'tc -s qdisc show dev enp2s0f0 | grep Sent' c'est bien visible:
compare:
tc -s qdisc show dev enp1s0f0 | grep Sent
avec
tc -s qdisc show dev enp2s0f0 | grep Sent
si je prend tes 2 posts ca donne:
pour enp1s0f0:
Sent 2882198390815 bytes 2059419059 pkt (dropped 0, overlimits 0 requeues 72039)
Sent 356733539433 bytes 257715765 pkt (dropped 0, overlimits 0 requeues 5856)
Sent 730126997402 bytes 513812841 pkt (dropped 0, overlimits 0 requeues 23906)
Sent 345974573962 bytes 247635138 pkt (dropped 0, overlimits 0 requeues 5230)
Sent 682679426134 bytes 480775485 pkt (dropped 0, overlimits 0 requeues 22553)
Sent 183780202712 bytes 132185123 pkt (dropped 0, overlimits 0 requeues 2898)
Sent 184874910117 bytes 135001884 pkt (dropped 0, overlimits 0 requeues 3509)
Sent 197856694076 bytes 147393790 pkt (dropped 0, overlimits 0 requeues 4581)
Sent 200172044499 bytes 144899011 pkt (dropped 0, overlimits 0 requeues 3506)
Sent 220 bytes 2 pkt (dropped 0, overlimits 0 requeues 0)
Sent 110 bytes 1 pkt (dropped 0, overlimits 0 requeues 0)
Sent 110 bytes 1 pkt (dropped 0, overlimits 0 requeues 0)
Sent 110 bytes 1 pkt (dropped 0, overlimits 0 requeues 0)
Sent 680 bytes 6 pkt (dropped 0, overlimits 0 requeues 0)
Sent 330 bytes 3 pkt (dropped 0, overlimits 0 requeues 0)
Sent 480 bytes 4 pkt (dropped 0, overlimits 0 requeues 0)
Sent 440 bytes 4 pkt (dropped 0, overlimits 0 requeues 0)
pour enp2s0f0:
Sent 8692466210818 bytes 1532106743 pkt (dropped 0, overlimits 0 requeues 136326)
Sent 1096363650344 bytes 735096903 pkt (dropped 0, overlimits 0 requeues 19701)
Sent 1062000567154 bytes 711774005 pkt (dropped 0, overlimits 0 requeues 11640)
Sent 1093329258305 bytes 732950108 pkt (dropped 0, overlimits 0 requeues 19320)
Sent 1099425254672 bytes 737179948 pkt (dropped 0, overlimits 0 requeues 20945)
Sent 1102078737978 bytes 738920622 pkt (dropped 0, overlimits 0 requeues 19732)
Sent 1086794275891 bytes 728217355 pkt (dropped 0, overlimits 0 requeues 11444)
Sent 1077302264082 bytes 722130461 pkt (dropped 0, overlimits 0 requeues 16181)
Sent 1075172202392 bytes 720804637 pkt (dropped 0, overlimits 0 requeues 17363)
(tu peux:
tc -s qdisc show dev enp1s0f0 | grep Sent | awk '{a=$2/1000/1000/1000;b=$4/1000/1000; printf("%.0f GB %d Mpackets\n",a,b);}'
pour voir les valeurs en GB et Millions de pkt).
le 1er Sent étant le total donc pour enp2s0f0 ca semble normal le traffic émit est bien réparti sur les 8 queues.
Mais pour enp1s0f0 c'est curieux. Les 8 dernières queues ne servent quasi et les 8 premieres sont disparates. On dirait qu'il y a une classification quelque part. ce n'est pas du tout réparti équitablement. Y'a des priorités quelque part ?
que donne:
sudo tc -s class show dev enp1s0f0
tc -s class show dev enp2s0f0
et
sudo tc -s filter show dev enp1s0f0
tc -s filter show dev enp2s0f0
-
8h12 : On est passé sur BBR (on est resté avec fq, je ne change qu'une chose à la fois)
$ cat /proc/sys/net/ipv4/tcp_congestion_control
bbr
-
Mise à jour de ce matin 8h.
En monothread, marrant ce pic temporaire de débit au pire moment (soirée) hier dimanche.
-
8h12 : On est passé sur BBR (on est resté avec fq, je ne change qu'une chose à la fois)
Quelques chiffres avant/après cette modification :
DATE ; IPv4 multi ; IPv6 multi ; IPv4 mono ; IPv6 mono
20/01/2020 07:00:00 ; 7,49 ; 7,70 ; 2,82 ; 2,52
20/01/2020 07:10:00 ; 7,40 ; 7,65 ; 4,94 ; 4,20
20/01/2020 07:20:00 ; 7,01 ; 7,69 ; 0,52 ; 0,89
20/01/2020 07:30:00 ; 7,37 ; 7,18 ; 2,70 ; 2,54
20/01/2020 07:40:00 ; 7,71 ; 7,26 ; 1,51 ; 2,75
20/01/2020 07:50:00 ; 7,44 ; 7,84 ; 1,36 ; 0,70
20/01/2020 08:00:01 ; 7,42 ; 7,54 ; 2,60 ; 4,08
20/01/2020 08:10:00 ; 7,32 ; 7,55 ; 4,50 ; 2,16
20/01/2020 08:20:00 ; 1,74 ; 2,54 ; 6,05 ; 6,11 <== 1ères mesures après changement. Oui, vous l'auriez vite remarqué... ;)
20/01/2020 08:30:00 ; 2,13 ; 3,60 ; 6,97 ; 6,84
20/01/2020 08:40:00 ; 5,43 ; 2,70 ; 6,63 ; 6,61
20/01/2020 08:50:00 ; 4,18 ; 1,70 ; 5,72 ; 5,55
20/01/2020 09:00:00 ; 3,77 ; 2,44 ; 6,44 ; 6,79
20/01/2020 09:10:00 ; 4,90 ; 6,29 ; 5,00 ; 6,47
20/01/2020 09:20:00 ; 1,84 ; 1,89 ; 6,61 ; 6,67
20/01/2020 09:30:00 ; 1,72 ; 2,45 ; 5,53 ; 6,73
20/01/2020 09:40:00 ; 1,69 ; 2,13 ; 4,70 ; 6,60
20/01/2020 09:50:01 ; 1,67 ; 6,35 ; 5,31 ; 6,38
Clairement, comme la dernière fois, on s'effondre en multithread.
En monothread (informations dont on ne disposait pas la dernière fois), c'est plutôt pas mal du tout en revanche. A confirmer dans la durée.
BBR semble préférer le monothread, mais ça reste quand même assez fluctuant, pour le moment.
-
Si on garde du BBR dans la durée, faudrait essayer de baisser le nombre de threads en multi, pour voir jusqu'où l'algo arrive à gérer (16 -> 12 -> 8 -> ... ).
-
Je propose deux modifications coté serveur avec BBR :
- passer initcwnd de 90 à 10 (valeur par défaut). Je n'ai pas vu de gain suite à ce changement, je suis étonné.
- supprimer la ligne net.core.default_qdisc=fq pour voir si le fq_codel par défaut à un impact.
-
Ce qui n'est pas normal avec ce serveur c'est qu'avec plusieurs flux on n'a pas une répartition égale entres les flux.
avec -P 4 les 4 flux devraient être a peu près identiques. Hors c'est loin d'être le cas.
Sur une connection Bytel Uytym 1G/500M
avec "iperf3 -4 -c paris.testdebit.info -R -P4 -p 5203":
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 256 MBytes 214 Mbits/sec 11283 sender
[ 5] 0.00-10.00 sec 250 MBytes 209 Mbits/sec receiver
[ 7] 0.00-10.00 sec 258 MBytes 216 Mbits/sec 11060 sender
[ 7] 0.00-10.00 sec 252 MBytes 212 Mbits/sec receiver
[ 9] 0.00-10.00 sec 164 MBytes 138 Mbits/sec 6568 sender
[ 9] 0.00-10.00 sec 160 MBytes 135 Mbits/sec receiver
[ 11] 0.00-10.00 sec 465 MBytes 390 Mbits/sec 24199 sender
[ 11] 0.00-10.00 sec 454 MBytes 381 Mbits/sec receiver
[SUM] 0.00-10.00 sec 1.12 GBytes 959 Mbits/sec 53110 sender
[SUM] 0.00-10.00 sec 1.09 GBytes 936 Mbits/sec receiver
flux 1: 209 Mbps
flux 2: 212 Mbps
flux 3: 135 Mbps
flux 4: 381 Mbps
Le "théorique" équitable étant autour de 230 Mbps.
le meme client avec ping.online.net: "iperf3 -4 -c ping.online.net -R -P4"
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 316 MBytes 265 Mbits/sec 157 sender
[ 5] 0.00-10.00 sec 313 MBytes 263 Mbits/sec receiver
[ 7] 0.00-10.00 sec 262 MBytes 219 Mbits/sec 73 sender
[ 7] 0.00-10.00 sec 260 MBytes 218 Mbits/sec receiver
[ 9] 0.00-10.00 sec 265 MBytes 222 Mbits/sec 133 sender
[ 9] 0.00-10.00 sec 262 MBytes 220 Mbits/sec receiver
[ 11] 0.00-10.00 sec 270 MBytes 226 Mbits/sec 72 sender
[ 11] 0.00-10.00 sec 268 MBytes 225 Mbits/sec receiver
[SUM] 0.00-10.00 sec 1.09 GBytes 933 Mbits/sec 435 sender
[SUM] 0.00-10.00 sec 1.08 GBytes 926 Mbits/sec receiver
flux 1: 263 Mbps
flux 2: 218 Mbps
flux 3: 220 Mbps
flux 4: 225 Mbps
c'est nettement plus equitable.
La colonne 'Retr' est significative: 53110 retransmission de part de paris.testdebit.info contre 435 pour online. Y'a clairement un truc qui cloche.
Le phénomene est nettement plus sensible en bbr qu'en cubic:
iperf3 -4 -c paris.testdebit.info -R -P4 -p 5203 --congestion=bbr
flux 1: 177 Mbits/s
flux 2: 333 Mbits/s
flux 3: 136 Mbits/s
flux 4: 310 Mbits/s
Retr total: 57370
iperf3 -4 -c paris.testdebit.info -R -P4 -p 5203 --congestion=cubic
flux 1: 217 Mbits/s
flux 2: 210 Mbits/s
flux 3: 262 Mbits/s
flux 4: 266 Mbits/s
Retr total: 25830
cubic est mieux pour ce serveur mais y'a quand meme trop de retransmissions meme avec cubic.
-
Mise à jour de ce matin 8h.
BBR, sur ce serveur et sur les dernières 24h, c'est effectivement pas brillant : bons résultats uniquement sur les tests monothread, quand... il n'y a pas (trop) de congestion ? ;D
-
kgersen mes serveur n'ont pas deux cartes réseau 10 Gb/s.
- enp1s0f0 => Carte sur serveur paris.testdebit.info
- enp2s0f0 => Carte sur un serveur sans aucune optimisation, en l’occurrence fr.archive.ubuntu.com
Voici les stats sur paris.testdebit.info aprés une journée de trafic. C'est le serveur iPerf utilisé ici (qui est dans le groupe anycast bouygues.testdebit.info et bouygues.iperf.fr)
# cat /proc/sys/net/core/default_qdisc
fq
# tc -s qdisc show dev enp1s0f0 | grep Sent
Sent 13211459496692 bytes 891164247 pkt (dropped 128631, overlimits 0 requeues 599)
Sent 2443893935256 bytes 1732130454 pkt (dropped 19452, overlimits 0 requeues 126)
Sent 1118920704494 bytes 809363638 pkt (dropped 13210, overlimits 0 requeues 20)
Sent 1624253413379 bytes 1161309714 pkt (dropped 16431, overlimits 0 requeues 31)
Sent 1393148045189 bytes 1002149899 pkt (dropped 15490, overlimits 0 requeues 20)
Sent 1748422951877 bytes 1259229980 pkt (dropped 24527, overlimits 0 requeues 54)
Sent 2586109052255 bytes 1845078801 pkt (dropped 18241, overlimits 0 requeues 306)
Sent 1214571703559 bytes 883020716 pkt (dropped 8698, overlimits 0 requeues 29)
Sent 1082139684113 bytes 788815578 pkt (dropped 12582, overlimits 0 requeues 13)
Sent 550 bytes 5 pkt (dropped 0, overlimits 0 requeues 0)
Sent 590 bytes 5 pkt (dropped 0, overlimits 0 requeues 0)
Sent 770 bytes 7 pkt (dropped 0, overlimits 0 requeues 0)
Sent 920 bytes 8 pkt (dropped 0, overlimits 0 requeues 0)
Sent 990 bytes 9 pkt (dropped 0, overlimits 0 requeues 0)
Sent 990 bytes 9 pkt (dropped 0, overlimits 0 requeues 0)
Sent 880 bytes 8 pkt (dropped 0, overlimits 0 requeues 0)
Sent 880 bytes 8 pkt (dropped 0, overlimits 0 requeues 0)
# tc -s qdisc show dev enp1s0f0 | grep Sent | awk '{a=$2/1000/1000/1000;b=$4/1000/1000; printf("%.0f GB %d Mpackets\n",a,b);}'
13219 GB 896 Mpackets
2444 GB 1732 Mpackets
1120 GB 810 Mpackets
1624 GB 1161 Mpackets
1394 GB 1002 Mpackets
1750 GB 1260 Mpackets
2588 GB 1846 Mpackets
1216 GB 883 Mpackets
1083 GB 789 Mpackets
0 GB 0 Mpackets
0 GB 0 Mpackets
0 GB 0 Mpackets
0 GB 0 Mpackets
0 GB 0 Mpackets
0 GB 0 Mpackets
0 GB 0 Mpackets
0 GB 0 Mpackets
# tc -s class show dev enp1s0f0
class mq :1 root
Sent 880 bytes 8 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
class mq :2 root
Sent 880 bytes 8 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
class mq :3 root
Sent 990 bytes 9 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
class mq :4 root
Sent 990 bytes 9 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
class mq :5 root
Sent 920 bytes 8 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
class mq :6 root
Sent 770 bytes 7 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
class mq :7 root
Sent 590 bytes 5 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
class mq :8 root
Sent 550 bytes 5 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
class mq :9 root
Sent 1082685378750 bytes 789405428 pkt (dropped 12582, overlimits 0 requeues 13)
backlog 6056b 2p requeues 13
class mq :a root
Sent 1216099773625 bytes 884076422 pkt (dropped 8698, overlimits 0 requeues 29)
backlog 3028b 2p requeues 29
class mq :b root
Sent 2587645288017 bytes 1846179221 pkt (dropped 18241, overlimits 0 requeues 306)
backlog 0b 0p requeues 306
class mq :c root
Sent 1750438908248 bytes 1260876518 pkt (dropped 24527, overlimits 0 requeues 54)
backlog 0b 0p requeues 54
class mq :d root
Sent 1394328225679 bytes 1003043709 pkt (dropped 15490, overlimits 0 requeues 20)
backlog 0b 0p requeues 20
class mq :e root
Sent 1624366668098 bytes 1161446240 pkt (dropped 16431, overlimits 0 requeues 31)
backlog 3028b 1p requeues 31
class mq :f root
Sent 1119850965687 bytes 810056035 pkt (dropped 13210, overlimits 0 requeues 20)
backlog 0b 0p requeues 20
class mq :10 root
Sent 2443998448891 bytes 1732306917 pkt (dropped 19452, overlimits 0 requeues 126)
backlog 6056b 2p requeues 126
class mq :11 root
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
class mq :12 root
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
class mq :13 root
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
class mq :14 root
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
class mq :15 root
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
class mq :16 root
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
class mq :17 root
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
class mq :18 root
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
class mq :19 root
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
class mq :1a root
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
class mq :1b root
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
class mq :1c root
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
class mq :1d root
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
class mq :1e root
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
class mq :1f root
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
class mq :20 root
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
class mq :21 root
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
class mq :22 root
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
class mq :23 root
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
class mq :24 root
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
class mq :25 root
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
class mq :26 root
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
class mq :27 root
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
class mq :28 root
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
class mq :29 root
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
class mq :2a root
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
class mq :2b root
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
class mq :2c root
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
class mq :2d root
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
class mq :2e root
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
class mq :2f root
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
class mq :30 root
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
class mq :31 root
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
class mq :32 root
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
class mq :33 root
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
class mq :34 root
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
class mq :35 root
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
class mq :36 root
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
class mq :37 root
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
class mq :38 root
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
class mq :39 root
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
class mq :3a root
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
class mq :3b root
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
class mq :3c root
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
class mq :3d root
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
class mq :3e root
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
class mq :3f root
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
class mq :40 root
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
tc -s filter show dev enp1s0f0 ne donne aucun résultat
-
Voici les mêmes stats, sur https://ubuntu.lafibre.info/ serveur de même type mais la carte réseau est sur un slot PCI express différent, d'où la différence de nomage.
$ cat /proc/sys/net/core/default_qdisc
fq_codel
$ tc -s qdisc show dev enp2s0f0 | grep Sent
Sent 21721141899435 bytes 1695798147 pkt (dropped 0, overlimits 0 requeues 276666)
Sent 2711607802761 bytes 1820392980 pkt (dropped 0, overlimits 0 requeues 37073)
Sent 2664240429274 bytes 1788334131 pkt (dropped 0, overlimits 0 requeues 28827)
Sent 2707954728426 bytes 1817686483 pkt (dropped 0, overlimits 0 requeues 35519)
Sent 2746799673780 bytes 1844104656 pkt (dropped 0, overlimits 0 requeues 40316)
Sent 2728945381684 bytes 1832040588 pkt (dropped 0, overlimits 0 requeues 36603)
Sent 2724850111553 bytes 1828744892 pkt (dropped 0, overlimits 0 requeues 28488)
Sent 2715696352988 bytes 1822893976 pkt (dropped 0, overlimits 0 requeues 33105)
Sent 2721047421981 bytes 1826502331 pkt (dropped 0, overlimits 0 requeues 36735)
$ tc -s qdisc show dev enp2s0f0 | grep Sent | awk '{a=$2/1000/1000/1000;b=$4/1000/1000; printf("%.0f GB %d Mpackets\n",a,b);}'
21723 GB 1697 Mpackets
2712 GB 1820 Mpackets
2665 GB 1788 Mpackets
2708 GB 1817 Mpackets
2747 GB 1844 Mpackets
2729 GB 1832 Mpackets
2725 GB 1828 Mpackets
2716 GB 1823 Mpackets
2721 GB 1826 Mpackets
$ tc -s class show dev enp2s0f0
class mq :1 root
Sent 2721350159660 bytes 1826705567 pkt (dropped 0, overlimits 0 requeues 36737)
backlog 0b 0p requeues 36737
class mq :2 root
Sent 2716155925857 bytes 1823203782 pkt (dropped 0, overlimits 0 requeues 33116)
backlog 0b 0p requeues 33116
class mq :3 root
Sent 2725442468434 bytes 1829142131 pkt (dropped 0, overlimits 0 requeues 28499)
backlog 0b 0p requeues 28499
class mq :4 root
Sent 2729410406673 bytes 1832351085 pkt (dropped 0, overlimits 0 requeues 36610)
backlog 0b 0p requeues 36610
class mq :5 root
Sent 2747230142368 bytes 1844393260 pkt (dropped 0, overlimits 0 requeues 40322)
backlog 0b 0p requeues 40322
class mq :6 root
Sent 2708343620192 bytes 1817948585 pkt (dropped 0, overlimits 0 requeues 35521)
backlog 0b 0p requeues 35521
class mq :7 root
Sent 2664756430440 bytes 1788678339 pkt (dropped 0, overlimits 0 requeues 28829)
backlog 0b 0p requeues 28829
class mq :8 root
Sent 2712013824367 bytes 1820663694 pkt (dropped 0, overlimits 0 requeues 37074)
backlog 0b 0p requeues 37074
class mq :9 root
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
class mq :a root
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
class mq :b root
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
class mq :c root
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
class mq :d root
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
class mq :e root
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
class mq :f root
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
class mq :10 root
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
class mq :11 root
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
class mq :12 root
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
class mq :13 root
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
class mq :14 root
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
class mq :15 root
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
class mq :16 root
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
class mq :17 root
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
class mq :18 root
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
class mq :19 root
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
class mq :1a root
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
class mq :1b root
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
class mq :1c root
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
class mq :1d root
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
class mq :1e root
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
class mq :1f root
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
class mq :20 root
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
class mq :21 root
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
class mq :22 root
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
class mq :23 root
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
class mq :24 root
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
class mq :25 root
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
class mq :26 root
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
class mq :27 root
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
class mq :28 root
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
class mq :29 root
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
class mq :2a root
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
class mq :2b root
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
class mq :2c root
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
class mq :2d root
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
class mq :2e root
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
class mq :2f root
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
class mq :30 root
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
class mq :31 root
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
class mq :32 root
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
class mq :33 root
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
class mq :34 root
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
class mq :35 root
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
class mq :36 root
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
class mq :37 root
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
class mq :38 root
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
class mq :39 root
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
class mq :3a root
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
class mq :3b root
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
class mq :3c root
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
class mq :3d root
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
class mq :3e root
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
class mq :3f root
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
class mq :40 root
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
$ tc -s filter show dev enp2s0f0
=> ne donne rien non plus.
-
Depuis 9h34, j'ai supprimé la ligne net.core.default_qdisc=fq de mon fichier /etc/sysctl.d/90-server-optimization.conf
ON est en configuration qdisc par défaut :
$ cat /proc/sys/net/core/default_qdisc
fq_codel
On reste en BBR.
On va voir si cela a un impact (en théorie ce n'est que quand on sature le lien du serveur)
-
net.core.default_qdisc est un "defaut". ca ne s'applique qu'au boot ou si on supprime le qdisc d'une interface.
j'ai pas l'impression que tu n'applique pas un qdisc top level ?
si c'est le cas, pour changer le qdisc sans reboot, le plus immédiat est d'ajouter un puis enlever une top level disc:
sudo tc qdisc add dev xxxx root fq
sudo tc qdisc delete dev xxxx root 1. on ajoute une top level disc (logiciel)
2. on l'enleve donc ca reset a un top level de type mq (=multiqueue (https://lwn.net/Articles/351021/)) utilisant "net.core.default_qdisc" pour les queues matérielles.
Mais vu ton hardware, tu peux aussi essayer ceci: https://www.kernel.org/doc/Documentation/networking/multiqueue.txt
sudo tc qdisc add dev xxxxx root handle 1: multiq
Bon apres le souci de retransmissions de ton serveur est peut-etre du a autre chose. "glances" est un bon outil pour voir ce qui ce passe.
-
J'ai une question plus générale : Le qdisc ne devrait impacter que si on sature la bande passante 10 G du serveur, non ? Je me demande si il y a un gain a attendre d'avoir une gestion de file différente sachant qu'il n'y a pas de flux prioritaire.
Sinon pour répondre à ta question, je n'ai pas précisé, mais a chaque modification, je reboot le serveur.
Voici son uptime :
-
J'ai une question plus générale : Le qdisc ne devrait impacter que si on sature la bande passante 10 G du serveur, non ? Je me demande si il y a un gain a attendre d'avoir une gestion de file différente sachant qu'il n'y a pas de flux prioritaire.
Ben disons qu'un FQ ou FQ_CODEL permet de privilégier les traffics qui se 'vident' des files par rapport a ceux qui bouchonnent parce qu'au delà du lien est saturé ou le récepteur est 'lent'. Donc il peut y a voir un gain quand y'a beaucoup de flux vers différentes destinations en meme temps (ca rempli les files bien que l'interface n'est pas saturée).
FQ_CODEL reste le réglage par défaut recommandé par systemd meme si y'a des précautions a prendre pour les basses vitesses (donc sur un serveur 10G devrait pas y avoir de souci).
Mais dans ton cas tu n'a pas "beaucoup de flux vers différentes destinations" du coup difficile a savoir.
En tout cas y'a trop de retransmissions c'est clairement visible mais dur a diagnostiquer car en plus UDP est bloqué donc on ne peut savoir si c'est un souci de saturation ou de TCP (taille buffers, latence, algo, etc).
Par exemple demander :
iperf3 -4 -c paris.testdebit.info -P 4 -R -V --get-server-output -u -b 230M -p 520x"
reste bloquer au lieu d'envoyer 4 flux UDP a 230 Mbps
ou c'est peut-être juste les switches ou routeurs juste apres ton serveur qui ne sont pas bons (https://fasterdata.es.net/network-tuning/router-switch-buffer-size-issues/).
sinon une bonne lecture: https://www.linuxjournal.com/content/queueing-linux-network-stack
-
Merci pour l'explication.
Je débloque l'UDP demain.
Je pense tester sans initcwnd 90 demain, mais comment savoir si c'est bien mis en place ?
Cela a peut-être plus d'impact pour les connexions TCP courtes.
A 8h47, j'ai basculé initcwnd de 10 à 90, uniquement pour le trafic IPv4
Concrètement, j'ai rajouté une ligne qui change la route par défaut avec initcwnd 90 en plus.
iface enp1s0f0 inet static
address 89.84.1.186
netmask 255.255.255.248
gateway 89.84.1.185
post-up /sbin/ip route change default via 89.84.1.185 dev enp1s0f0 initcwnd 90
A 15h03, j'ai basculé initcwnd de 10 à 90, pour le trafic IPv6: On a donc IPv4 et IPv6 qui sont tous les deux en initcwnd 90
iface enp1s0f0 inet6 static
address 2001:860:de01:1100::2
netmask 64
gateway 2001:860:de01:1100::1
post-up /sbin/ip -6 route change default via 2001:860:de01:1100::1 dev enp1s0f0 initcwnd 90
accept_ra 0
dns-nameservers 2001:860:b0ff:1::1 2001:860:b0ff:1::2
Demain matin je recommence les tests de différents algorithme de congestion TCP en gardant les optimisations actuelles.
- Aujourd'hui : Illinois, l'algorithme qui était souvent proposés pour des très haut débit (qdisc fq)
- Demain : Cubic l'algorithme par défaut de presque tous les Linux (qdisc fq)
- Après-demain : Cubic (test avec qdisc fq_codel)
- Les jours suivants : BBR sensé être l'algorithme miracle.
-
Mise à jour de ce matin 8h20.
Pas grand changement à signaler...
-
kgersen mes serveur n'ont pas deux cartes réseau 10 Gb/s.
- enp1s0f0 => Carte sur serveur paris.testdebit.info
- enp2s0f0 => Carte sur un serveur sans aucune optimisation, en l’occurrence fr.archive.ubuntu.com
Voici les stats sur paris.testdebit.info aprés une journée de trafic. C'est le serveur iPerf utilisé ici (qui est dans le groupe anycast bouygues.testdebit.info et bouygues.iperf.fr)
# cat /proc/sys/net/core/default_qdisc
fq
# tc -s qdisc show dev enp1s0f0 | grep Sent
Sent 13211459496692 bytes 891164247 pkt (dropped 128631, overlimits 0 requeues 599)
Sent 2443893935256 bytes 1732130454 pkt (dropped 19452, overlimits 0 requeues 126)
Sent 1118920704494 bytes 809363638 pkt (dropped 13210, overlimits 0 requeues 20)
Sent 1624253413379 bytes 1161309714 pkt (dropped 16431, overlimits 0 requeues 31)
Sent 1393148045189 bytes 1002149899 pkt (dropped 15490, overlimits 0 requeues 20)
Sent 1748422951877 bytes 1259229980 pkt (dropped 24527, overlimits 0 requeues 54)
Sent 2586109052255 bytes 1845078801 pkt (dropped 18241, overlimits 0 requeues 306)
Sent 1214571703559 bytes 883020716 pkt (dropped 8698, overlimits 0 requeues 29)
Sent 1082139684113 bytes 788815578 pkt (dropped 12582, overlimits 0 requeues 13)
Sent 550 bytes 5 pkt (dropped 0, overlimits 0 requeues 0)
Sent 590 bytes 5 pkt (dropped 0, overlimits 0 requeues 0)
Sent 770 bytes 7 pkt (dropped 0, overlimits 0 requeues 0)
Sent 920 bytes 8 pkt (dropped 0, overlimits 0 requeues 0)
Sent 990 bytes 9 pkt (dropped 0, overlimits 0 requeues 0)
Sent 990 bytes 9 pkt (dropped 0, overlimits 0 requeues 0)
Sent 880 bytes 8 pkt (dropped 0, overlimits 0 requeues 0)
Sent 880 bytes 8 pkt (dropped 0, overlimits 0 requeues 0)
# tc -s qdisc show dev enp1s0f0 | grep Sent | awk '{a=$2/1000/1000/1000;b=$4/1000/1000; printf("%.0f GB %d Mpackets\n",a,b);}'
13219 GB 896 Mpackets
2444 GB 1732 Mpackets
1120 GB 810 Mpackets
1624 GB 1161 Mpackets
1394 GB 1002 Mpackets
1750 GB 1260 Mpackets
2588 GB 1846 Mpackets
1216 GB 883 Mpackets
1083 GB 789 Mpackets
0 GB 0 Mpackets
0 GB 0 Mpackets
0 GB 0 Mpackets
0 GB 0 Mpackets
0 GB 0 Mpackets
0 GB 0 Mpackets
0 GB 0 Mpackets
0 GB 0 Mpackets
Stats aprés 24h :
$ cat /proc/sys/net/core/default_qdisc
fq_codel
$ tc -s qdisc show dev enp1s0f0 | grep Sent
Sent 13769832649936 bytes 1242503640 pkt (dropped 25, overlimits 0 requeues 2575775)
Sent 1658249576292 bytes 1187479491 pkt (dropped 0, overlimits 0 requeues 335167)
Sent 1866040237832 bytes 1341347339 pkt (dropped 16, overlimits 0 requeues 369608)
Sent 2533301600162 bytes 1802120947 pkt (dropped 4, overlimits 0 requeues 291038)
Sent 1218915561680 bytes 875466650 pkt (dropped 0, overlimits 0 requeues 260882)
Sent 1058722998695 bytes 758573962 pkt (dropped 1, overlimits 0 requeues 245917)
Sent 2368295995084 bytes 1679314523 pkt (dropped 4, overlimits 0 requeues 343351)
Sent 1410889478868 bytes 1006583537 pkt (dropped 0, overlimits 0 requeues 341817)
Sent 1655417195213 bytes 1181551728 pkt (dropped 0, overlimits 0 requeues 387995)
Sent 660 bytes 6 pkt (dropped 0, overlimits 0 requeues 0)
Sent 660 bytes 6 pkt (dropped 0, overlimits 0 requeues 0)
Sent 440 bytes 4 pkt (dropped 0, overlimits 0 requeues 0)
Sent 880 bytes 8 pkt (dropped 0, overlimits 0 requeues 0)
Sent 880 bytes 8 pkt (dropped 0, overlimits 0 requeues 0)
Sent 1030 bytes 9 pkt (dropped 0, overlimits 0 requeues 0)
Sent 660 bytes 6 pkt (dropped 0, overlimits 0 requeues 0)
Sent 900 bytes 8 pkt (dropped 0, overlimits 0 requeues 0)
$ tc -s qdisc show dev enp1s0f0 | grep Sent | awk '{a=$2/1000/1000/1000;b=$4/1000/1000; printf("%.0f GB %d Mpackets\n",a,b);}'
13770 GB 1242 Mpackets
1658 GB 1187 Mpackets
1866 GB 1341 Mpackets
2533 GB 1802 Mpackets
1219 GB 875 Mpackets
1059 GB 758 Mpackets
2368 GB 1679 Mpackets
1411 GB 1006 Mpackets
1655 GB 1181 Mpackets
0 GB 0 Mpackets
0 GB 0 Mpackets
0 GB 0 Mpackets
0 GB 0 Mpackets
0 GB 0 Mpackets
0 GB 0 Mpackets
0 GB 0 Mpackets
0 GB 0 Mpackets
-
Les évolutions du tcp_congestion_control :
- 17 janvier 9h32 Illinois => Cubic
- 20 janvier 8h12 Cubic => BBR
- 22 janvier 10h03 BBR => Illinois (on n'avais pas de tests mono-thread en Illinois)
Actuellement :
$ cat /proc/sys/net/ipv4/tcp_congestion_control
illinois
(https://lafibre.info/images/free_debit/202001_comparatif_bubic_bbr_1.png)
(https://lafibre.info/images/free_debit/202001_comparatif_bubic_bbr_2.png)
(https://lafibre.info/images/free_debit/202001_comparatif_bubic_bbr_3.png)
-
Quelques chiffres encadrant le changement de 10h03 :
22/01/2020 09:00:00 ; 2,19 ; 3,92 ; 5,74 ; 6,64
22/01/2020 09:10:00 ; 2,08 ; 1,94 ; 4,43 ; 5,52
22/01/2020 09:20:00 ; 1,77 ; 2,44 ; 4,09 ; 5,33
22/01/2020 09:30:00 ; 1,96 ; 2,19 ; 5,11 ; 4,27
22/01/2020 09:40:00 ; 2,37 ; 1,92 ; 5,48 ; 6,82
22/01/2020 09:50:00 ; 1,92 ; 2,10 ; 3,58 ; 3,12
22/01/2020 10:00:00 ; 2,11 ; 1,80 ; 5,51 ; 5,69
22/01/2020 10:10:00 ; 6,24 ; 6,05 ; 5,73 ; 5,94 <-- 1ère mesure après changement
22/01/2020 10:20:00 ; 6,22 ; 5,83 ; 5,67 ; 6,00
22/01/2020 10:30:00 ; 6,31 ; 6,07 ; 5,43 ; 5,50
22/01/2020 10:40:00 ; 6,26 ; 5,97 ; 5,65 ; 5,76
22/01/2020 10:50:00 ; 6,27 ; 6,00 ; 5,09 ; 5,08
22/01/2020 11:00:00 ; 6,18 ; 5,58 ; 5,31 ; 5,21
22/01/2020 11:10:00 ; 6,29 ; 5,89 ; 5,15 ; 5,62
22/01/2020 11:20:00 ; 6,15 ; 5,85 ; 4,92 ; 6,08
22/01/2020 11:30:00 ; 6,21 ; 5,87 ; 5,55 ; 5,62
22/01/2020 11:40:00 ; 6,07 ; 5,87 ; 4,09 ; 5,56
22/01/2020 12:10:00 ; 6,19 ; 5,93 ; 3,31 ; 4,59
22/01/2020 12:20:01 ; 6,15 ; 5,86 ; 4,20 ; 4,45
22/01/2020 12:30:00 ; 6,17 ; 5,84 ; 3,65 ; 5,21
-
C'est curieux l'inversement de BBR vs cubic en multi/mono.
A .cubic = loss-based = régit uniquement sur la perte de paquets. donc en mono devrait y a voir peu de perte de paquets pourtant cubic marche mal en mono.
B bbr = model-based = il tente de modéliser le réseau en analysant le RTT et la bande passante. en mono il s'adapte au mieux mais en multi considere qu'il y n'y pas assez de bande passante du coup réduit le debit de chaque threads ?
A. ca montre bien en tout cas le souci avec ce serveur et ses trop nombreuses retransmissions ?
Apres c'est peut-être le serveur qui est simplement trop chargé pour fournir un test a 10G exploitable ?
Au vue des graphes de Vivien:
Coté serveur, la charge est stable :
(https://lafibre.info/images/stats/202001_stats_bouygues_iperf_day.png) (https://lafibre.info/images/stats/202001_stats_bouygues_iperf_week.png)
Il est moyenne a plus de 1G donc mais manque peut-être de précision ? (j'ai 90% du temps un 'occupé' quand je tente un iperf3 sur ce serveur).
Tant qu'on a pas une mesure plus fine (prometheus par exemple) pour obtenir le crosstalk pendant les 20 secondes d'un IPerf3 de Breizh29 c'est délicat de conclure précisément.
Tu peux log en json tes serveurs IPerf3: "iperf3 -s -J --logfile /chemin/iperf3.json" ca permettrait de faire des stats sur le taux d'utilisation d'IPerf3 (et de faire des graphes sur le Retr par exemple). Si t'as les logs des autres services (apache et nperf?) avec les dates ca permet de 'calculer' le crosstalk.
Il serait bien de tester Goben sur ce serveur aussi pour voir si IPerf3 a une influence.
Je travaille a développer un "curl/wget vers /dev/null" multi-threadé ca permettra de comparer avec iperf3 et Goben.
l'histoire des 16 files tc disc mal reparties est suspicieuse aussi. Sur un petit serveur ou la carte réseau n'a que 2 files si je fais un iperf3 ca utilise la 1er puis le suivant la 2eme etc. Donc sur une journée en moyenne les 2 files ont a peu pres émit la meme quantité.
Sur ton serveur:
2444 GB 1732 Mpackets
1120 GB 810 Mpackets
1624 GB 1161 Mpackets
1394 GB 1002 Mpackets
1750 GB 1260 Mpackets
2588 GB 1846 Mpackets
1216 GB 883 Mpackets
1083 GB 789 Mpackets
T'as une file qui a émit 2.5 TB et une autre avec 1.1TB soit 2x moins. Je doute qu'un seul flux est occupé 1TB a lui seul ou alors c'est basé sur un hash destination ? T'as bien 'mq' en root sur tc disc ?
-
Mise à jour de ce matin 8h50.
Illinois fonctionne pas mal en monothread...
-
9h03 : initcwnd 90 supprimé.
Cela devrait un impact important sur le monothread.
C'est peut-être ça qui entraînait de nombreuses retransmissions.
Avant :
$ ip -4 route list
default via 89.84.1.185 dev enp1s0f0 initcwnd 90
89.84.1.184/29 dev enp1s0f0 proto kernel scope link src 89.84.1.186
89.84.1.220/30 dev enp1s0f0 proto kernel scope link src 89.84.1.222
$ ip -6 route list
::1 dev lo proto kernel metric 256 pref medium
2001:860:de01:1100::/64 dev enp1s0f0 proto kernel metric 256 pref medium
2001:860:deff:1000::/64 dev enp1s0f0 proto kernel metric 256 pref medium
fe80::/64 dev enp1s0f0 proto kernel metric 256 pref medium
default via 2001:860:de01:1100::1 dev enp1s0f0 metric 1024 initcwnd 90 pref medium
Maintenant :
$ ip -4 route list
default via 89.84.1.185 dev enp1s0f0 onlink
89.84.1.184/29 dev enp1s0f0 proto kernel scope link src 89.84.1.186
89.84.1.220/30 dev enp1s0f0 proto kernel scope link src 89.84.1.222
$ ip -6 route list
::1 dev lo proto kernel metric 256 pref medium
2001:860:de01:1100::/64 dev enp1s0f0 proto kernel metric 256 pref medium
2001:860:deff:1000::/64 dev enp1s0f0 proto kernel metric 256 pref medium
fe80::/64 dev enp1s0f0 proto kernel metric 256 pref medium
default via 2001:860:de01:1100::1 dev enp1s0f0 metric 1024 onlink pref medium
j'ai 90% du temps un 'occupé' quand je tente un iperf3 sur ce serveur
Il y a 10 ports iperf3 ouverts, pas uniquement le port par défaut.
UDP est ouvert si tu souhaites faire des tests.
-
Il y a 10 ports iperf3 ouverts, pas uniquement le port par défaut.
oui je comptais ces ports dans mes tentatives.
par exemple a l'instant, je tente 3 fois sur 3 ports différents. 3 échecs.
[~]$ iperf3 -4 -c paris.testdebit.info -P 4 -R -V --get-server-output -b 100M
iperf 3.7
iperf3: error - the server is busy running a test. try again later
[~]$ iperf3 -4 -c paris.testdebit.info -P 4 -R -V --get-server-output -b 100M -p 5207
iperf 3.7
iperf3: error - the server is busy running a test. try again later
[~]$ iperf3 -4 -c paris.testdebit.info -P 4 -R -V --get-server-output -b 100M -p 5204
iperf 3.7
iperf3: error - the server is busy running a test. try again later
Je testerais UDP plus tard.
-
Mise à jour de ce matin 8h20
-
et en upload, ça donne quoi?
-
On ne l'a pas (encore ?) inclus dans le périmètre, il n'est pas mesuré.
C'était moins un sujet vu la forte asymétrie DL/UL et qu'on s'intéressait aux débits entre 1 et 10 gbps.
-
La suppression de initcwnd 90 n'a eu aucun impact.
Les évolutions du tcp_congestion_control :
- 17 janvier 9h32 Illinois => Cubic
- 20 janvier 8h12 Cubic => BBR
- 22 janvier 10h03 BBR => Illinois (on n'avais pas de tests mono-thread en Illinois)
- 24 janvier 11h52 Illinois => Cubic
Actuellement :
$ cat /proc/sys/net/ipv4/tcp_congestion_control
cubic
Cubic semble clairement bien mieux que Illinois en multithread.
En monothread, Cubic semble un peu moins bon que Illinois, mais c'est à peine visible.
-
En monothread, Cubic semble un peu moins bon que Illinois, mais c'est à peine visible.
Pas si invisible que ça (j'aurais trouvé le changement sans que tu ne l'évoques).
Chiffres du matin :
24/01/2020 10:00:00 ; 6,15 ; 5,89 ; 4,17 ; 6,00
24/01/2020 10:10:00 ; 6,28 ; 5,82 ; 4,58 ; 5,01
24/01/2020 10:20:00 ; 6,30 ; 5,88 ; 5,22 ; 2,95
24/01/2020 10:30:01 ; 6,24 ; 5,90 ; 5,07 ; 5,22
24/01/2020 10:40:00 ; 6,27 ; 5,86 ; 5,32 ; 5,74
24/01/2020 10:50:00 ; 6,43 ; 5,89 ; 4,83 ; 5,71
24/01/2020 11:00:00 ; 6,22 ; 6,22 ; 5,04 ; 5,03
24/01/2020 11:10:00 ; 6,24 ; 5,89 ; 4,88 ; 5,94
24/01/2020 11:20:00 ; 6,08 ; 5,78 ; 4,16 ; 5,80
24/01/2020 11:30:01 ; 6,27 ; 6,03 ; 5,81 ; 5,42
24/01/2020 11:40:00 ; 6,25 ; 5,82 ; 5,19 ; 5,72
24/01/2020 11:50:00 ; 6,28 ; 5,79 ; 5,23 ; 5,69
24/01/2020 12:00:00 ; 6,41 ; 6,94 ; 1,51 ; 1,00
24/01/2020 12:10:00 ; 6,95 ; 6,84 ; 1,98 ; 1,32
24/01/2020 12:20:00 ; 4,16 ; 6,77 ; 0,34 ; 3,79
24/01/2020 12:30:00 ; 5,03 ; 7,05 ; 0,30 ; 1,38
24/01/2020 12:40:00 ; 6,22 ; 6,23 ; 2,24 ; 2,61
Je suis d'accord qu'étant sur un serveur à vocation de speedtest, il faut pouvoir monter autant que possible, donc cubic semble plus adapté qu'Illinois.
En revanche, s'il y a encore des marges de manoeuvre, une optimisation en cubic serait la bienvenue pour éviter de tomber si bas en période chargée, ou au moins plus tard dans la journée.
-
Je suis d’accord avec tes données Cubic semble plus pertinent que les autres.
Il a l'avantage également de la représentativité.
Je me demande par contre si les résultats pourraient être différent avec un Linux ou un Windows en client.
Je veux bien la mise à jour des graphiques demain matin, cela permettra de faire un résumé graphiques des principaux tests réalisés.
Tu as un Mac mini (i7 3,2 GHz) : Serait-il possible d'avoir la référence complète du CPU ?
-
Je me demande par contre si les résultats pourraient être différent avec un Linux ou un Windows en client.
J'ai envisagé un multiboot MacOS / Win / Linux (d'ailleurs, j'ai déjà une partition bootcamp : Win 10 sans virtualisation est possible)
Reste à voir pour un Linux.
En tous les cas, il faut passer un peu de temps d'optimisation... et je ne peux pas conserver la machine dans la durée sur un autre OS (je l'utilise, quand même...).
<HS>
J'avais pour projet d'acquérir/ monter un serveur (d'occasion, probablement) pour ça et d'autres choses. Idéalement, j'aurais voulu mettre à ESXi ou assimilé et monter plusieurs VMs, avec une carte 10G. Je l'aurais placé à proximité de ma baie. Tu aurais une idée pour profiter de 10G, idéalement au sein des machines virtuelles, sans y laisser 2 bras ?
</HS>
Je veux bien la mise à jour des graphiques demain matin, cela permettra de faire un résumé graphiques des principaux tests réalisés.
Sauf imprévu, ce sera comme d'hab.
Tu as un Mac mini (i7 3,2 GHz) : Serait-il possible d'avoir la référence complète du CPU ?
Je regarde ça asap et je reprécise.
EDIT : I7-8700B
-
darkmoon a un iPerf3 est lui aussi chez Free, il a un serveur Linux (1 Gb/s) qui utilise le même serveur.
Les résultats sont assez plats malgré toutes nos modifications (il a 8 connexion TCP en //)
On note une baisse de débit le dimanche soir, jour de la plus forte consommation de bande passante.
Voici ce que cela donne comme graphique : (merci darkmoon)
(https://lafibre.info/images/free_debit/202001_munin_iperf3_free_week.png)
-
A noter que je ne fais les tests (down & up) qu'en ipv6.
mtr -zwc5 -6 bouygues.iperf.fr
Start: 2020-01-24T14:49:09+0100
HOST: Freeze Loss% Snt Last Avg Best Wrst StDev
1. AS12322 2a01:e0a:1dx:xyzw::1 0.0% 5 1.1 1.1 1.0 1.3 0.1
2. AS12322 2a01:e02:1:f836:8917::ffff 0.0% 5 2.7 3.4 2.7 4.3 0.6
3. AS12322 2a01:e02:1:1735::ffff 80.0% 5 2.8 2.8 2.8 2.8 0.0
4. AS??? ??? 100.0 5 0.0 0.0 0.0 0.0 0.0
5. AS12322 2a01:e00:3f::5 0.0% 5 10.1 10.0 9.7 10.2 0.2
6. AS5410 2001:860:0:81::1 0.0% 5 9.7 9.7 9.5 10.0 0.2
7. AS5410 2001:860:bbee:b4::2 0.0% 5 9.8 10.0 9.8 10.4 0.2
8. AS5410 2001:860:bbe0:128::2 0.0% 5 11.1 10.8 10.3 11.2 0.4
9. AS5410 2001:860:deff:1000::2 0.0% 5 10.2 9.7 9.1 10.2 0.4
Un jour peut-être j'aurais de l'argent à dépenser dans du matos 10G :)
-
Thornhill, voici les valeur par défaut :
• net.ipv4.tcp_rmem=4096 131072 6291456
• net.ipv4.tcp_wmem=4096 16384 4194304
• net.core.rmem_max= 212992
• net.core.wmem_max= 212992
C'est étonnant que rmem_max ne soit pas aligné sur la valeur max de net.ipv4.tcp_rmem, non ?
Idem pour wmem_max qui n'est pas aligné sur la valeur max de net.ipv4.tcp_wmem
Il me semble que net.core.[rw]mem_max prend le pas sur la valeur max de net.ipv4.tcp_[rw]mem (contrairement à la valeur par défaut).
Si c'est vrai, ça voudrait dire que sur ton serveur, les buffers TCP ne peuvent pas dépasser 832Ko.
https://www.ibm.com/support/knowledgecenter/linuxonibm/liaag/wkvm/wkvm_c_tune_tcpip.htm (https://www.ibm.com/support/knowledgecenter/linuxonibm/liaag/wkvm/wkvm_c_tune_tcpip.htm)
net.ipv4.tcp_wmem
Similar to the net.ipv4.tcp_rmem this parameter consists of 3 values, a minimum, default, and maximum.
The minimum represents the smallest receive buffer size a newly created socket is entitled to as part of its creation. The minimum value defaults to 1 page or 4096 bytes.
The default value represents the initial size of a TCP sockets receive buffer. This value supersedes net.core.rmem_default used by other protocols. It is typically set lower than net.core.wmem_default. The default value for this setting is 16K bytes.
The maximum represents the largest receive buffer size for auto-tuned send buffers for TCP sockets. This value does not override net.core.rmem_max. The default value for this setting is somewhere between 64K bytes and 4M bytes based on the amount of memory available in the system.
The recommendation is to use the maximum value of 16M bytes or higher (kernel level dependent) especially for 10 Gigabit adapters.
La valeur optimisé pour des haut débit avec une forte latence serait ça ?
• net.ipv4.tcp_rmem=4096 131072 16777216
• net.ipv4.tcp_wmem=4096 87380 16777216
• net.core.rmem_max=16777216
• net.core.wmem_max=16777216
Je me demande si la valeur de 16 Mo peut être utilisée.
Il n'y a pas de win_scale_factor limité à 7 avec certains OS ?
Coté Mac le net.inet.tcp.win_scale_factor par défault est de 3 ou 5 selon les version de MacOS X :'(
-
Je viens de voir que ce soir, je n'ai pas de chiffres, car erreur "connection refused" sur tous les ports...
C'est pas un problème général, puisque j'ai des tests Ookla qui tournent en parallèle, et eux fonctionnent tout à fait bien.
Les pings vers paris.testdebit.info passent bien, eux aussi.
Je vais quand même essayer un reboot, sans trop y croire.
EDIT: pas mieux après reboot ; serveur iperf3 tombé ? problème apparemment survenu entre 18h50 et 19h
-
Pas spécialement de chiffres ce matin, puisque l'accès au serveur iperf3 n'est pas revenu depuis.
En revanche, je sais que c'est HS et je ne souhaite pas qu'on s'étende ici sur le sujet, mais je ne serais pas contre quelques pistes à ce sujet :
J'avais pour projet d'acquérir/monter un serveur (d'occasion, probablement) pour ça et d'autres choses. Idéalement, j'aurais voulu mettre à ESXi ou assimilé et monter plusieurs VMs, avec une carte 10G. Je l'aurais placé à proximité de ma baie. Tu aurais une idée pour profiter de 10G, idéalement au sein des machines virtuelles, sans y laisser 2 bras ?
Objectif: amateur passionné, quelques VMs d'expérimentation d'OS/réseau, creuser speedtest, Plex, ... y'a beaucoup de connaisseurs ici, donc si vous pouviez m'orienter vers des plans intéressants, compromis, ...
Merci.
-
Ooops, je n'avais pas regardé.
C'est un plantage inhabituel d'iPerf3.
Pourtant, j'ai :
Un fichier /etc/cron.d/iperf
# Auto restart on reboot
@reboot iperf /home/iperf/restart_iperf.sh
# Auto restart iPerf (for crash)
59 * * * * iperf /home/iperf/restart_iperf.sh
qui lance chaque heure /home/iperf/restart_iperf.sh
#!/bin/dash
/bin/sleep 15
/usr/bin/killall iperf3
/bin/sleep 0.1
/usr/bin/killall -9 iperf3
/bin/sleep 0.1
if [ `ps -C iperf3 | wc -l` = "1" ]
then
/usr/bin/iperf3 -s -p 5200 -D >/dev/null 2>&1
/usr/bin/iperf3 -s -p 5201 -D >/dev/null 2>&1
/usr/bin/iperf3 -s -p 5202 -D >/dev/null 2>&1
/usr/bin/iperf3 -s -p 5203 -D >/dev/null 2>&1
/usr/bin/iperf3 -s -p 5204 -D >/dev/null 2>&1
/usr/bin/iperf3 -s -p 5205 -D >/dev/null 2>&1
/usr/bin/iperf3 -s -p 5206 -D >/dev/null 2>&1
/usr/bin/iperf3 -s -p 5207 -D >/dev/null 2>&1
/usr/bin/iperf3 -s -p 5208 -D >/dev/null 2>&1
/usr/bin/iperf3 -s -p 5209 -D >/dev/null 2>&1
fi
Cela permet de tuer les process qui pourraient être bloqués.
Mais là un reboot a été nécessaire.
-
Objectif: amateur passionné, quelques VMs d'expérimentation d'OS/réseau, creuser speedtest, Plex, ... y'a beaucoup de connaisseurs ici, donc si vous pouviez m'orienter vers des plans intéressants, compromis, ...
Merci.
c'est quoi le budget ? ;D
si t'as déja une baie, pas la peine d'acheter un vrai 'serveur' matériel. En plus ca consomme.
Personnellement j'utilise un Intel NUC i3, €300 chez https://www.amazon.fr/Intel-Nuc-Kit-Nuc8I3Beh-Cartes/dp/B07JB2M5JS (y'a des modeles i5 ou i7 mais bien plus chers).
C'est vendu sans RAM et DD donc ajouter au moins 80€ pour cela.
Pour le 10G, un boitier thunderbolt3 RJ45 Sonnet a 200€ ( https://www.amazon.fr/SONNET-TECHNOLOGIES-SOLO10G-TB3-Adaptateur-Ethernet/dp/B07BZRK8R8 ).
Faut compter au moins 600€ tout compris donc. Ca prend peu de place , ca consomme peu, ca fait pas de bruit. Pour faire du 10G tu trouveras difficilement moins cher.
-
Merci pour ton retour.
Effectivement, j'avais déjà un vieux NUC avec un ESXi, mais sans TB3, si bien qu'impossible de rajouter une carte 10G. Et pas de NVMe non plus, donc pour réellement exploiter...
Sur un plus récent avec port TB3, on peut profiter de 10G sur les VM si on met un ESXi , ou faut oublier la virtualisation à ce niveau de débit ?
Si je veux disons 4/5 VM en parallèle (Linux, Win), avec pour certaines accès en mode bureau (RDP, VNC...), ça passe niveau proc, y'aura pas trop de throttling dans un si petit boitier ?
Merci encore, je vais creuser les modèles existants.
-
je n'ai pas testé la virtualisation. Docker avec le NAT qu'il introduit je tombe a 8.7 Gbps donc au dessus de Free :p
Apres on peut opti les VMs avec une connexion de pont plutot que du NAT (et les hyperviseurs ont peut-etre un meilleur NAT que celui de Docker)
voila ce que donne en charge un NUC i3 qui débite 10G, on a donc le cpu a 20%:
(https://i.imgur.com/Tlt0bn3.png)
le pas de monitoring est de 5 secondes d'ou l'effet 'triangle' quand on zoom sur 1 minute.
-
Mise à jour de ce matin 9h.
Note: Le passage de débit à 0 correspond à la période d'indisponibilité du serveur iPerf3.
-
@kgersen :
Sinon, je m'étais installé le binaire goben et voici le résultat vis à vis de ton serveur :
IPv4
./goben -hosts pox-4.nspeed.app -passiveClient
2020/01/26 09:22:34 goben version 0.3 runtime go1.11.2 GOMAXPROCS=12
2020/01/26 09:22:34 connections=1 defaultPort=:8080 listeners=[":8080"] hosts=["pox-4.nspeed.app"]
2020/01/26 09:22:34 reportInterval=2s totalDuration=10s
2020/01/26 09:22:34 client mode, tcp protocol
2020/01/26 09:22:34 open: opening tcp 0/1: pox-4.nspeed.app:8080
2020/01/26 09:22:34 handleConnectionClient: starting 0/1 195.154.113.23:8080
2020/01/26 09:22:34 handleConnectionClient: options sent: {2s 10s 50000 50000 false 0}
2020/01/26 09:22:34 clientReader: starting: 0/1 195.154.113.23:8080
2020/01/26 09:22:36 0/1 report clientReader rate: 888 Mbps 14584 rcv/s
2020/01/26 09:22:38 0/1 report clientReader rate: 926 Mbps 15071 rcv/s
2020/01/26 09:22:40 0/1 report clientReader rate: 934 Mbps 15237 rcv/s
2020/01/26 09:22:42 0/1 report clientReader rate: 941 Mbps 15387 rcv/s
2020/01/26 09:22:44 0/1 report clientReader rate: 941 Mbps 15453 rcv/s
2020/01/26 09:22:44 handleConnectionClient: 10s timer
2020/01/26 09:22:44 workLoop: 0/1 clientReader: read tcp 192.168.200.115:54675->195.154.113.23:8080: use of closed network connection
2020/01/26 09:22:44 0/1 average clientReader rate: 926 Mbps 15146 rcv/s
2020/01/26 09:22:44 clientReader: exiting: 0/1 195.154.113.23:8080
2020/01/26 09:22:44 195.154.113.23:8080 input:
941 ┤ ╭────────────────────
936 ┤ ╭─────────────╯
931 ┤ ╭──────────╯
925 ┤ ╭──────╯
920 ┤ ╭──╯
915 ┤ ╭─╯
909 ┤ ╭──╯
904 ┤ ╭─╯
899 ┤ ╭─╯
894 ┤ ╭──╯
888 ┼─╯
Input Mbps: 195.154.113.23:8080 Connection 0
2020/01/26 09:22:44 handleConnectionClient: closing: 0/1 195.154.113.23:8080
IPv6
./goben -hosts pox-6.nspeed.app -passiveClient
2020/01/26 09:24:45 goben version 0.3 runtime go1.11.2 GOMAXPROCS=12
2020/01/26 09:24:45 connections=1 defaultPort=:8080 listeners=[":8080"] hosts=["pox-6.nspeed.app"]
2020/01/26 09:24:45 reportInterval=2s totalDuration=10s
2020/01/26 09:24:45 client mode, tcp protocol
2020/01/26 09:24:45 open: opening tcp 0/1: pox-6.nspeed.app:8080
2020/01/26 09:24:45 handleConnectionClient: starting 0/1 [2001:bc8:2679:100::1]:8080
2020/01/26 09:24:45 handleConnectionClient: options sent: {2s 10s 50000 50000 false 0}
2020/01/26 09:24:45 clientReader: starting: 0/1 [2001:bc8:2679:100::1]:8080
2020/01/26 09:24:47 0/1 report clientReader rate: 883 Mbps 23878 rcv/s
2020/01/26 09:24:49 0/1 report clientReader rate: 928 Mbps 25232 rcv/s
2020/01/26 09:24:51 0/1 report clientReader rate: 928 Mbps 25225 rcv/s
2020/01/26 09:24:53 0/1 report clientReader rate: 928 Mbps 24986 rcv/s
2020/01/26 09:24:55 0/1 report clientReader rate: 928 Mbps 23796 rcv/s
2020/01/26 09:24:55 handleConnectionClient: 10s timer
2020/01/26 09:24:55 workLoop: 0/1 clientReader: read tcp [2a01:e0a:1fc:xxxxxxx]:54783->[2001:bc8:2679:100::1]:8080: use of closed network connection
2020/01/26 09:24:55 0/1 average clientReader rate: 919 Mbps 24623 rcv/s
2020/01/26 09:24:55 clientReader: exiting: 0/1 [2001:bc8:2679:100::1]:8080
2020/01/26 09:24:55 [2001:bc8:2679:100::1]:8080 input:
928 ┤ ╭────────────────────────────────────────────────────
924 ┤ ╭─╯
919 ┤ ╭─╯
915 ┤ ╭─╯
911 ┤ ╭╯
906 ┤ ╭─╯
902 ┤ ╭─╯
897 ┤ ╭╯
893 ┤ ╭─╯
888 ┤╭─╯
884 ┼╯
Input Mbps: [2001:bc8:2679:100::1]:8080 Connection 0
2020/01/26 09:24:55 handleConnectionClient: closing: 0/1 [2001:bc8:2679:100::1]:8080
La montée en débit est meilleure en IPv6, mais ce n'est qu'un seul test.
Et débit un peu plus faible en IPv6 au final ; Ça devrait pas être le contraire par rapport à IPv4 ? MSS pas bien optimisé ?
Merci de ton analyse.
-
Tes équipements te permettent de dépasser les 1 Gbps en IPv4 et en IPv6 alors que le serveur de kgersen est limité à 1 Gbps, du coup je pense que ce qu'on voit ici c'est le surcout de l'IPv6 au niveau du serveur. Son serveur ayant une connectivité native en IPv4 et en IPv6, la différence vient de la taille des entêtes qui est plus grosse en IPv6 qu'en IPv4, ce qui implique un débit utile légèrement plus faible.
Le comportement serait différent si ta connexion était limitée à 1 Gbps puisque dans ce cas ça serait le surcoût de faire de l'IPv4 dans de l'IPv6 qui serait plus visible.
-
a priori Goben a un meilleur comportement qu'IPerf3 non?
et oui c'est Goben sur un serveur 10G qu'il faudrait pour vraiment comparer mais je n'en ai pas sous la main.
-
@underground78 : bien vu, j'avais zappé cet aspect de la situation.
-
Je me demande si la valeur de 16 Mo peut être utilisée.
Il n'y a pas de win_scale_factor limité à 7 avec certains OS ?
Coté Mac le net.inet.tcp.win_scale_factor par défault est de 3 ou 5 selon les version de MacOS X :'(
Je me répond.
Avec un client où j'ai configuré la même Rwin max de 16 Mo, j'ai un scale factor de 9 (64k x 512) donc aucun problème (Rwin max possible de 32 768 Ko avec un scale factor de 9).
(https://lafibre.info/images/wireshark/202001_wireshark_tcp_syn_1.png)
(https://lafibre.info/images/wireshark/202001_wireshark_tcp_syn_2.png)
-
Mise à jour de ce matin 9h
(https://lafibre.info/images/free_debit/202001_free_tests_debit_1_thread.png)
(https://lafibre.info/images/free_debit/202001_free_tests_debit_16_thread.png)
(https://lafibre.info/images/free_debit/202001_free_tests_debit_1et16_thread.png)
-
J'ai ça actuellement :
# 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
Il me semble que net.core.[rw]mem_max prend le pas sur la valeur max de net.ipv4.tcp_[rw]mem (contrairement à la valeur par défaut).
Si c'est vrai, ça voudrait dire que sur ton serveur, les buffers TCP ne peuvent pas dépasser 832Ko.
https://www.ibm.com/support/knowledgecenter/linuxonibm/liaag/wkvm/wkvm_c_tune_tcpip.htm (https://www.ibm.com/support/knowledgecenter/linuxonibm/liaag/wkvm/wkvm_c_tune_tcpip.htm)
net.ipv4.tcp_wmem
Similar to the net.ipv4.tcp_rmem this parameter consists of 3 values, a minimum, default, and maximum.
The minimum represents the smallest receive buffer size a newly created socket is entitled to as part of its creation. The minimum value defaults to 1 page or 4096 bytes.
The default value represents the initial size of a TCP sockets receive buffer. This value supersedes net.core.rmem_default used by other protocols. It is typically set lower than net.core.wmem_default. The default value for this setting is 16K bytes.
The maximum represents the largest receive buffer size for auto-tuned send buffers for TCP sockets. This value does not override net.core.rmem_max. The default value for this setting is somewhere between 64K bytes and 4M bytes based on the amount of memory available in the system.
The recommendation is to use the maximum value of 16M bytes or higher (kernel level dependent) especially for 10 Gigabit adapters.
Autre explication : https://cloud.google.com/solutions/tcp-optimization-for-network-performance-in-gcp-and-hybrid?hl=fr
La taille de la fenêtre TCP est affectée par les 4 paramètres suivants :
• net.core.rmem_max
• net.core.wmem_max
• net.ipv4.tcp_rmem
• net.ipv4.tcp_wmem
Les deux premiers paramètres configurables affectent la taille maximale de fenêtre TCP pour les applications qui tentent de contrôler directement la taille de la fenêtre TCP, en limitant la requête des applications à ces valeurs seulement. Les deux autres paramètres configurables affectent la taille de fenêtre TCP pour les applications qui laissent la fonction de réglage automatique de Linux se charger de cette tâche.
-
y'a des bizarreries avec IPerf3 et Windows:
serveur: Linux IPerf3 3.7 avec
net.core.rmem_default = 212992
net.core.rmem_max = 212992
net.core.wmem_default = 212992
net.core.wmem_max = 212992
net.ipv4.tcp_rmem = 4096 131072 6291456
net.ipv4.tcp_wmem = 4096 16384 4194304
(donc les réglages par défaut d'archlinux)
client : Windows 10 pro fraichement installé et mis a jour.
Lien LAN entre les 2 a 10 Gbits, latence < 1ms donc.
Les deux sont en bare metal sans virtualization.
IPerf3 :
Windows -> Linux : 3 Gbps
Linux -> Windows : 8 Gbps
Goben:
Windows -> Linux : 9.4 Gbps
Linux -> Windows : 9.4 Gbps
Transfert HTTP avec serveur web maison (https://github.com/kgersen/go-httpbin) tournant dans le serveur Linux(mesures débit au dessus de HTTP)
avec Curl: Linux -> Windows : 9.15 Gbps
Avec Wget: Linux -> Windows : 5.28 Gbps
(je n'ai pas encore écrit la version avec un PUT pour tester dans l'autre sens)
Il faut ajouter l'option -w a IPerf3 pour gagner en débit mais elle plante quand on a atteint 2x le net.core.Xmem_max du serveur (soit 425984).
IPerf3 -w 425984:
Windows -> Linux : 7.3 Gbps
Linux -> Windows : 9.4 Gbps
IPerf3 -w 425985 (+1 du max*2) donc:
le serveur affiche:
iperf3: error - socket buffer size not set correctly
quel que ce soit le sens (-R ou pas).
Du coup sans modifier un serveur Linux de base, Windows 10 ne peut envoyer a 10Gbps avec IPerf3 (pas de souci avec Goben). Wget présente des limitations en reception aussi.A priori avec -w, le client iperf3 demande au serveur IPerf3 de changer le socket buffer size meme en reception.
questions/conclusion: doit-on modifier les réglages des OS pour faire fonctionner les applications "mal écrites ?" (iperf3, wget) ou arrêter d'utiliser ces applications pour ces débits la ?
-
Interessant.
Si Vivien est prêt à installer un serveur goben, j’essaierais bien d’adapter le script pour passer d’iperf3 à goben, pour comparer...
-
A noter que mes tests ne sont qu'en LAN (latence < 1ms) sur un lien ou absolument rien d'autre ne passe.
Via Internet avec de latence et d'autres traffics TCP ce n'est plus la meme histoire.
En LAN il semble naturel d'expecter qu'un monoflux puisse atteindre le max sans réglage aucun.
En WAN pas forcement ca va être plus une histoire de compromis. Il ne faut pas oublier que ces histoires de réglages de buffers consomment de la mémoire et peuvent impacter les flux temps réels a base de petits paquets.
-
un autre test:
- serveur go-httpbin modifié coté Windows
- curl coté Linux
curl de 10G:
curl -D - -o /dev/null http://192.168.99.1:8080/stream-bytes/10000000000
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0HTTP/1.1 200 OK
Access-Control-Allow-Credentials: true
Access-Control-Allow-Origin: *
Content-Length: 10000000000
Content-Type: application/octet-stream
Date: Mon, 27 Jan 2020 22:28:11 GMT
100 9536M 100 9536M 0 0 1127M 0 0:00:08 0:00:08 --:--:-- 1129M
1129M = 1129 MiB/s = 9.47 Gbps
Donc un pauvre bout de code en Go (simple boucle au dessus de net.http (https://golang.org/pkg/net/http/)) arrive a envoyer depuis Windows vers Linux a 10 Gbps la ou IPerf3 plafonne a 3 Gbps ?
-
iperf3 est compilé avec Cygwin, ça peut peut-être poser problème (en plus du soucis de taille de buffers avec la cygwin1.dll utilisée par Vivien).
Je ne sais pas si on pourrait le compiler avec Mingw par exemple.
je suppose que Go utilise Winsock plus directement.
-
J'ai archivé les graphiques réalisés :
(https://lafibre.info/images/free_debit/202001_free_tests_debit_1_thread.png)
(https://lafibre.info/images/free_debit/202001_free_tests_debit_16_thread.png)
(https://lafibre.info/images/free_debit/202001_free_tests_debit_1et16_thread.png)
Breizh29, il n'est pas nécessaire de mettre à jour les graphiques ce matin et demain matin.
On est passé à 8h22 en illinois pour 2 jours.
$ cat /proc/sys/net/ipv4/tcp_congestion_control
illinois
L'objectif: pouvoir mieux comparer les débits cubic / illinois en heure en cas de charge.
Le problème du week-end, c'est que la charge est plus importante et que l'on voit des débits plus faibles.
Je veut bien vendredi matin un graphique qui se limite du lundi 00h00 au vendredi matin. On aura donc 2 jours illinois encadré par une journée cubic avant et une journée cubic après.
-
Breizh29, il n'est pas nécessaire de mettre à jour les graphiques ce matin et demain matin.
D'autant que les relevés se sont arrêtés la nuit dernière à 3h20... et que je n'ai pas d'accès pour corriger pour le moment (tunnel VPN freebox qui ne monte pas, accès depuis l'app iOS de supervision OK, mais désactivation/réactivation serveur VPN inopérante. Par ailleurs, des flux sortants passent...). Bref je ne sais pas encore d'où vient le problème.
Et ce ne sera peut-être corrigé que ce soir...
EDIT: bon serveur VPN revenu (?) mais connexion ssh au mac impossible. Probablement planté.
Sinon, partant pour quelques expérimentations goben ?
-
Et à présent, incident quasi généralisé Free sur le sud finistère on dirait (cf. free-reseau.fr)
-
Bon, j'ai essayé de relancer le bouzin, mais à présent, j'ai "connection refused" sur tous les ports, de nouveau.
Tout va bien côté serveur ?
-
Même soucis ... depuis 16h30~17h plus rien
-
Reparti depuis un peu avant 20h40 environ.
-
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
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
# 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.
-
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 (https://github.com/ARCEP-dev/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.
-
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é)
-
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é.
-
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...
-
Tu as du changement sans changer la version que tu utilises ?
Lesquels ?
Au passage, tu utilises quelle version sur ton mac ?
-
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)
-
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 :
$ 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.
-
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.
-
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 :
$ 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 :
$ 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)
-
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.
-
iperf3 -4 -c paris.testdebit.info -p 9222 -R837 Mbits/sec
iperf3 -4 -c paris.testdebit.info -p 9222 -R --congestion=bbr943 Mbits/sec
par contre je viens de découvrir que si un client demande une congestion les tests suivants auront tous cette congestion:
tres visible avec -V:
test 1:
iperf3 -4 -c paris.testdebit.info -p 9222 -R -V
affiche: snd_tcp_congestion cubic
test 2:
iperf3 -4 -c paris.testdebit.info -p 9222 -R -V --congestion=bbr
affiche: snd_tcp_congestion bbr
test 3: le meme que le 1
iperf3 -4 -c paris.testdebit.info -p 9222 -R -V
affiche: snd_tcp_congestion bbr
et ce n'est pas lié a l'IP du client, j'ai fait un test avec 2 machines avec 2 IP différentes.
Du coup tu ne peux savoir la congestion sans -V...
bug ou feature d'iperf3? idéalement apres un test qui change la congestion il devrait remettre celle par défaut ...bon apres l'auteur d'IPerf3 a toujours dit que son programme était pas fait pour des tests sur serveurs publics.
au pire tu peux lancer ton serveur avec l'option -1 (=un test puis termine) dans une boucle sans fin, ca devrait reset l'algo a chaque fois.
-
Mon PC de test : Ubuntu 19.10
$ iperf3 -v
iperf 3.7 (cJSON 1.5.2)
Linux vivien1 5.3.0-29-generic #31-Ubuntu SMP Fri Jan 17 17:27:26 UTC 2020 x86_64
Optional features available: CPU affinity setting, IPv6 flow label, SCTP, TCP congestion algorithm setting, sendfile / zerocopy, socket pacing, authentication
$ cat /proc/sys/net/ipv4/tcp_congestion_control
cubic
$ cat /proc/sys/net/ipv4/tcp_available_congestion_control
reno cubic bbr
Voici les lignes de commandes passées dans l'ordre :
iperf3 -t 3 -c paris.testdebit.info -p 9222 -R -V
snd_tcp_congestion cubic
rcv_tcp_congestion cubic
iperf3 -t 3 -c paris.testdebit.info -p 9222 -R -V --congestion=bbr
snd_tcp_congestion bbr
rcv_tcp_congestion bbr
iperf3 -t 3 -c paris.testdebit.info -p 9222 -R -V
snd_tcp_congestion bbr
rcv_tcp_congestion cubic
iperf3 -t 3 -c paris.testdebit.info -p 9222 -R -V --congestion=cubic
snd_tcp_congestion cubic
rcv_tcp_congestion cubic
C'est donc un pb coté client et non coté serveur ?
-
Bonjour,
Pour info, je ne mets plus de graphique à jour depuis quelques jours, car :
- j'ai mis à jour le script pour intégrer la mesure de l'upload (mêmes modalités IPv4 / IPv6 / mono / multi)
- je suis en train de me frotter à gnuplot pour j'espère, à terme, automatiser autant que possible la création des graphiques
Pendant ce temps, les mesures se poursuivent...
-
Bonne idée d'automatiser la chose.
Note : Je suis intéressé par le fichier CSV avec les données depuis le début.
-
C'est donc un pb coté client et non coté serveur ?
Non côté serveur. Il ne reviens pas a l'algo par défaut.
Regarde ton 3eme test le serveur a utilisé l'algo du test d'avant au lieu de cubic.
-
Tu as raison.
J'ai également eu des cas où le port iPerf3 ne répondait plus après un appel avec un protocole de congestion non supporté.
Je redémarre les process iPerf3 toutes les heures, il faudrait peut-être que je le réalise toute les 30 min ? (plus on redémarre souvent, plus on prend le risque de couper un tests en cours)
-
Le plus propre serait probablement de faire ce que proposait kgersen :
au pire tu peux lancer ton serveur avec l'option -1 (=un test puis termine) dans une boucle sans fin, ca devrait reset l'algo a chaque fois.
-
Voici les anciens scripts (enfin toujours utilisés actuellement) :
sudo adduser iperf --disabled-login --gecos iperf
sudo nano /home/iperf/restart_iperf.sh
#!/bin/dash
/bin/sleep 15
/usr/bin/killall iperf3
/bin/sleep 0.1
/usr/bin/killall -9 iperf3
/bin/sleep 0.1
if [ `ps -C iperf3 | wc -l` = "1" ]
then
/usr/bin/iperf3 -s -p 9200 -D >/dev/null 2>&1
/usr/bin/iperf3 -s -p 9201 -D >/dev/null 2>&1
/usr/bin/iperf3 -s -p 9202 -D >/dev/null 2>&1
/usr/bin/iperf3 -s -p 9203 -D >/dev/null 2>&1
/usr/bin/iperf3 -s -p 9204 -D >/dev/null 2>&1
/usr/bin/iperf3 -s -p 9205 -D >/dev/null 2>&1
/usr/bin/iperf3 -s -p 9206 -D >/dev/null 2>&1
/usr/bin/iperf3 -s -p 9207 -D >/dev/null 2>&1
/usr/bin/iperf3 -s -p 9208 -D >/dev/null 2>&1
/usr/bin/iperf3 -s -p 9209 -D >/dev/null 2>&1
/usr/bin/iperf3 -s -p 9210 -D >/dev/null 2>&1
/usr/bin/iperf3 -s -p 9211 -D >/dev/null 2>&1
/usr/bin/iperf3 -s -p 9212 -D >/dev/null 2>&1
/usr/bin/iperf3 -s -p 9213 -D >/dev/null 2>&1
/usr/bin/iperf3 -s -p 9214 -D >/dev/null 2>&1
/usr/bin/iperf3 -s -p 9215 -D >/dev/null 2>&1
/usr/bin/iperf3 -s -p 9216 -D >/dev/null 2>&1
/usr/bin/iperf3 -s -p 9217 -D >/dev/null 2>&1
/usr/bin/iperf3 -s -p 9218 -D >/dev/null 2>&1
/usr/bin/iperf3 -s -p 9219 -D >/dev/null 2>&1
/usr/bin/iperf3 -s -p 9220 -D >/dev/null 2>&1
/usr/bin/iperf3 -s -p 9221 -D >/dev/null 2>&1
/usr/bin/iperf3 -s -p 9222 -D >/dev/null 2>&1
fi
sudo chmod +x /home/iperf/restart_iperf.sh
sudo nano /etc/cron.d/iperf
# Auto restart on reboot
@reboot iperf /home/iperf/restart_iperf.sh
# Auto restart iPerf (for crash)
59 * * * * iperf /home/iperf/restart_iperf.sh
-
Solution crade qui relance iperf3 après chaque fin de process :
sudo adduser iperf --disabled-login --gecos iperf
sudo nano /home/iperf/restart_iperf.sh
#!/bin/dash
/bin/sleep 15
/usr/bin/killall iperf3
/home/iperf/start_iperf.sh 9200 &
/home/iperf/start_iperf.sh 9201 &
/home/iperf/start_iperf.sh 9202 &
/home/iperf/start_iperf.sh 9203 &
/home/iperf/start_iperf.sh 9204 &
/home/iperf/start_iperf.sh 9205 &
/home/iperf/start_iperf.sh 9206 &
/home/iperf/start_iperf.sh 9207 &
/home/iperf/start_iperf.sh 9208 &
/home/iperf/start_iperf.sh 9209 &
/home/iperf/start_iperf.sh 9210 &
/home/iperf/start_iperf.sh 9211 &
/home/iperf/start_iperf.sh 9212 &
/home/iperf/start_iperf.sh 9213 &
/home/iperf/start_iperf.sh 9214 &
/home/iperf/start_iperf.sh 9215 &
/home/iperf/start_iperf.sh 9216 &
/home/iperf/start_iperf.sh 9217 &
/home/iperf/start_iperf.sh 9218 &
/home/iperf/start_iperf.sh 9219 &
/home/iperf/start_iperf.sh 9220 &
/home/iperf/start_iperf.sh 9221 &
/home/iperf/start_iperf.sh 9222 &sudo chmod +x /home/iperf/restart_iperf.sh
sudo nano /home/iperf/start_iperf.sh
#!/bin/dash
while true; do
/bin/sleep 0.1
/usr/bin/iperf3 -s -p $1 -1 >/dev/null 2>&1
donesudo chmod +x /home/iperf/start_iperf.sh
sudo nano /etc/cron.d/iperf
# Auto restart on reboot
@reboot iperf /home/iperf/restart_iperf.sh
# Auto restart iPerf (for crash)
59 * * * * iperf /home/iperf/restart_iperf.sh
kgersen tu n'aurais pas une solution plus propre avec SystemD ?
-
faut faire un service "template" et instancier pour chaque port.
Un unit systemd de type template a un '@' a la fin du nom du fichier avant le ".".
Le parametre du template est toujours %i ou (%I)( voir https://www.freedesktop.org/software/systemd/man/systemd.unit.html )
exemple:
#creer /etc/systemd/system/iperf3-server@.service avec dedans:
[Unit]
Description=iperf3 server on port %i
After=syslog.target network.target
[Service]
ExecStart=/usr/local/bin/iperf3 -s -1 -p %i
Restart=always
RuntimeMaxSec=3600
User=iperf
[Install]
WantedBy=multi-user.target
DefaultInstance=5201
# penser daemon-reload a chaque modif du fichier
sudo systemctl daemon-reload
Le "Restart=always" fait que le service est toujours redémarré soit parce qu'il a fini a cause de l'option -1 ou parce que au bout d'une heure (RuntimeMaxSec=3600) le système l’arrête.
# pour activer au boot il faut 'enable' les services (et "disable" donc pour les désactiver)
for p in $(seq 9200 9222); do sudo systemctl enable iperf3-server@$p ; done
# pour démarrer il faut 'start' les services (les services 'enable' vont start au boot tout seuls, la c'est pour lancer manuellement).
for p in $(seq 9200 9222); do sudo systemctl start iperf3-server@$p ; done
# et "stop" pour les arreter.
pour voir l"état et les logs ce sont les commandes usuelles de systemd. par exemple:
sudo systemctl status iperf3-server@*sudo journalctl -u iperf3-server@*
-
Vous avez regardé du côté de supervisord ? Ca fait exactement ce que vous voulez, avec les paramètres de timeout.
-
Pourquoi mettre un "RuntimeMaxSec" ?
-
Pourquoi mettre un "RuntimeMaxSec" ?
C'est Vivien qui veut relancer ses IPerf3 toutes les heures.
-
Ok, j'avais oublié que ça faisait parti du cahier des charges. :)
-
Merci kgersen, cela fonctionne parfaitement (sur mon PC)
Je met ça en prod en même temps que je supprime l'écoute sur les ports legacy dans quelques jours.
C'est Vivien qui veut relancer ses IPerf3 toutes les heures.
iPerf3 a tendance a se bloquer régulièrement. Comme expliqué, il n'est pas forcément conçu pour être serveur.
Le blocage va se faire avec 100% de cpu utilisé (1 cœur) ou 0%. De l'extérieur soit il répond qu'il est occupé comme si il y avait déjà un test en cours soit il ne répond plus rien du tout.
Bref, le redémarrage régulier est nécessaire et une fois par heure est un bon compromis (dans le passé, cela a varié entre une fois par jour et toutes les 10 minutes).
-
Bonsoir,
Mise en place d’un graphique avec mise à jour automatique sur le 1er post.
Utilisation d’un script gnuplot pour générer une image, rafraichie toutes les heures, qui reprend les données des 7 derniers jours.
A voir sur la durée, car j’ai toujours quelques soucis de stabilité après que le serveur iperf est tombé dans les choux, ou suite à un souci de connectivité temporaire de mon côté (ce qui induit des périodes plus ou moins longues pendant lesquelles je n’ai pas de données).
Je pense ajouter prochainement l’upload, sur le même principe.
-
gnuplot ... c'est les années 90 ca ;)
Tu pourrais pas mettre ca dans Chartjs ( https://www.chartjs.org/samples/latest/charts/line/basic.html ) ou dans Prometheus+Grafana (je ferais un tuto bientot)?
Je vais aussi développer un outil pour remplacer IPerf3 si vous avez des idées & demandes c'est le moment.
L'idée de base est de faire un "curl vers /dev/null" mais avec une interface web pour les non initiés (en gros speedtest+iperf mélangé).
-
gnuplot ... c'est les années 90 ca ;)
Bah c’est la décennie de mes études :P
Je n’ai jamais eu à utiliser ce genre d’outils que je ne connais pas, je voulais trouver vite et il me semblait toujours bénéficier d’une communauté suffisante pour trouver réponse à mes questions, donc...
Et puis ça fait une semaine que je m’y suis mis, avec juste quelques heures de dispo.
Donc les autres, par curiosité je regarderai, mais à moins que ce soit miraculeux, j’en resterai là. Et si comme son nom semble l’indiquer, il s’agit de scripter en js, alors très peu pour moi, je fais une allergie à ce truc (même pas envie d’appeler ça langage, sorry).
EDIT: j'ai regardé le 1er : ok, c'est sexy et dynamique, mais faut voir la souplesse de paramétrage, et puis surtout si c'est pour se taper du js, no thank you sir.
Pour le 2ème, ben oui, le système dans son ensemble a l'air bien fichu et intégré, mais... comment dire... ça semble pas beau le résultat graphique.
Alors donc, on attend ton goben avec front end, portable win / darwin / linux / ... hein ! :)
-
Ajout de l’upload.
En multithread, c’est stable mais pas au maximum de la ligne (j’atteins 570/575 au max sur Ookla). Peut-être une optimisation client et ou serveur ?
En monothread, c’est pas terrible... avec quelques pointes à des moments plutôt inattendus je trouve (soirée).
-
Félicitation pour le script gnuplot, je ne savais pas qu'on pouvait faire qq chose d'aussi propre et que tu pouvais le partager automatiquement sur dropbox.
Pour l'upload, c'est étonnant, car c'est un point fort d'iPerf3 : il est en mesure d'avoir de très bon débit dans un sens comme dans l'autre (avec les autres tests l'upload est bien plus complexe)
Tu nous partages la ligne de commande utilisée ?
Pourrais tu faire un iperf3 -s bouygues.testdebit.info -t 20 -i 1 pour que l'on regarde si le débit est stable et si il est pertinent de supprimer les premiéres secondes ?
-
Bonjour et merci Vivien.
En fait, gnuplot est très paramétrable et permet pas mal de trucs, surtout côté maths et sciences.
Ici, le partage n’est pas natif: en fait, afin de pouvoir superviser à distance depuis des réseaux type entreprise relativement restreints niveau droit, depuis le début j’ai tout positionné sur l’arbo dropbox.
Et du coup, j’y ai ajouté une arbo pour les graphiques et je partage la dernière version en permanence avec un lien direct sur le fichier image, sans fioritures autour.
Pour la syntaxe upload, c’est un copier-coller du download sans l’option -R.
-
Bah c’est la décennie de mes études :P
Je n’ai jamais eu à utiliser ce genre d’outils que je ne connais pas, je voulais trouver vite et il me semblait toujours bénéficier d’une communauté suffisante pour trouver réponse à mes questions, donc...
Et puis ça fait une semaine que je m’y suis mis, avec juste quelques heures de dispo.
Donc les autres, par curiosité je regarderai, mais à moins que ce soit miraculeux, j’en resterai là. Et si comme son nom semble l’indiquer, il s’agit de scripter en js, alors très peu pour moi, je fais une allergie à ce truc (même pas envie d’appeler ça langage, sorry).
EDIT: j'ai regardé le 1er : ok, c'est sexy et dynamique, mais faut voir la souplesse de paramétrage, et puis surtout si c'est pour se taper du js, no thank you sir.
Pour le 2ème, ben oui, le système dans son ensemble a l'air bien fichu et intégré, mais... comment dire... ça semble pas beau le résultat graphique.
Alors donc, on attend ton goben avec front end, portable win / darwin / linux / ... hein ! :)
j'ai rien contre Gnuplot j'ai utilisé aussi en son temps c'est juste que ton graphe est une image non interactive et difficile a lire. Si t'aime pas le js (moi non plus) tu peux générer des données pour tableur puis faire un graphe dans un tableur en ligne.
Le mieux c'est avec GDocs (G-Suite) et un feuille de tableur. Il y a une simple API REST aqui permet avec un curl de rajouter des lignes sur un tableur: https://developers.google.com/sheets/api/reference/rest/v4/spreadsheets.values/append
Si tu veux poste ici les données que tu envoies a gnuplot et je ferais le lien avec un tableur en ligne.
Si tu preferes faire toi meme tu peux démarrer en Python par exemple: https://developers.google.com/sheets/api/quickstart/python
-
Si tu veux poste ici les données que tu envoies a gnuplot et je ferais le lien avec un tableur en ligne.
OK, dans ce cas, je te fournirai en MP un lien vers le fichier csv de données et je te laisse oeuvrer pour la suite...
-
Pourrais tu faire un iperf3 -s bouygues.testdebit.info -t 20 -i 1 pour que l'on regarde si le débit est stable et si il est pertinent de supprimer les premiéres secondes ?
Tu veux dire un "iperf3 -c bouygues.testdebit.info -t 20 -i 1" ?
Si c'est bien le cas, voici ce que j'ai :
iperf3 -c bouygues.testdebit.info -t 20 -i 1
Connecting to host bouygues.testdebit.info, port 5201
[ 7] local 2a01:e0a:1fc:xxxxxxx port 52671 connected to 2001:860:deff:1000::2 port 5201
[ ID] Interval Transfer Bitrate
[ 7] 0.00-1.00 sec 19.5 MBytes 163 Mbits/sec
[ 7] 1.00-2.00 sec 15.6 MBytes 131 Mbits/sec
[ 7] 2.00-3.00 sec 15.9 MBytes 134 Mbits/sec
[ 7] 3.00-4.00 sec 11.3 MBytes 95.3 Mbits/sec
[ 7] 4.00-5.00 sec 18.4 MBytes 154 Mbits/sec
[ 7] 5.00-6.00 sec 16.3 MBytes 137 Mbits/sec
[ 7] 6.00-7.00 sec 17.2 MBytes 144 Mbits/sec
[ 7] 7.00-8.00 sec 11.9 MBytes 100 Mbits/sec
[ 7] 8.00-9.00 sec 11.6 MBytes 97.4 Mbits/sec
[ 7] 9.00-10.00 sec 19.9 MBytes 167 Mbits/sec
[ 7] 10.00-11.00 sec 12.4 MBytes 104 Mbits/sec
[ 7] 11.00-12.00 sec 2.66 MBytes 22.3 Mbits/sec
[ 7] 12.00-13.00 sec 8.41 MBytes 70.7 Mbits/sec
[ 7] 13.00-14.00 sec 13.1 MBytes 110 Mbits/sec
[ 7] 14.00-15.00 sec 2.62 MBytes 22.0 Mbits/sec
[ 7] 15.00-16.00 sec 9.66 MBytes 81.1 Mbits/sec
[ 7] 16.00-17.00 sec 10.2 MBytes 85.8 Mbits/sec
[ 7] 17.00-18.00 sec 11.3 MBytes 94.6 Mbits/sec
[ 7] 18.00-19.00 sec 3.51 MBytes 29.4 Mbits/sec
[ 7] 19.00-20.00 sec 11.0 MBytes 92.1 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate
[ 7] 0.00-20.00 sec 242 MBytes 102 Mbits/sec sender
[ 7] 0.00-20.01 sec 238 MBytes 99.9 Mbits/sec receiver
iperf Done.
-
OK, dans ce cas, je te fournirai en MP un lien vers le fichier csv de données et je te laisse oeuvrer pour la suite...
404 le lien :)
-
Tu veux dire un "iperf3 -c bouygues.testdebit.info -t 20 -i 1" ?
C'est impressionnant comment le débit up est instable et faible.
Il y a un vrai problème.
-
@Briezh29 toujours 404
@Vivien et les autres : j'ai séparé le projet d'un nouveau test dans https://lafibre.info/tester-son-debit/mesure-de-debit-nouveau-projet/
-
J’ai répondu à ta demande Dropbox.
Je ne comprends pas le 404: j’ai utilisé la même technique que pour les graphiques que je publie en post 1.
-
J’ai répondu à ta demande Dropbox.
Je ne comprends pas le 404: j’ai utilisé la même technique que pour les graphiques que je publie en post 1.
J'ai bien reçu le fichier via ma demande. oui c'est curieux mais j’avoue ne plus utiliser dropbox (j'ai du reset mon mot de passe tellement ca faisait longtemps ... ).
du coup ce fichier sera actualisé ou c'est juste une fois ?
-
Bah via une demande, il ne sera pas réactualisé, non.
Je réessaierai de t’envoyer un lien, y’a pas de raison puisque ça marche pour les images des graphiques...
-
Il y a un vrai problème.
Oui, mais où ?
Moi ? FAI ? autre ?
-
De mon côté :
perf3 -c bouygues.testdebit.info -t 20 -i 1
Connecting to host bouygues.testdebit.info, port 5201
[ 5] local 2a01:e0a:1d2:d8f0::xyzb port 36766 connected to 2001:860:deff:1000::2 port 5201
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 66.6 MBytes 558 Mbits/sec 5589 1.96 MBytes
[ 5] 1.00-2.00 sec 67.5 MBytes 566 Mbits/sec 9663 2.03 MBytes
[ 5] 2.00-3.00 sec 63.8 MBytes 535 Mbits/sec 8495 1.57 MBytes
[ 5] 3.00-4.00 sec 67.5 MBytes 566 Mbits/sec 4149 1.61 MBytes
[ 5] 4.00-5.00 sec 66.2 MBytes 555 Mbits/sec 8657 1.66 MBytes
[ 5] 5.00-6.00 sec 71.2 MBytes 598 Mbits/sec 3841 1.52 MBytes
[ 5] 6.00-7.00 sec 67.5 MBytes 566 Mbits/sec 5671 1.45 MBytes
[ 5] 7.00-8.00 sec 67.5 MBytes 566 Mbits/sec 2902 1001 KBytes
[ 5] 8.00-9.00 sec 67.5 MBytes 566 Mbits/sec 8688 1.54 MBytes
[ 5] 9.00-10.00 sec 67.5 MBytes 566 Mbits/sec 4491 1.14 MBytes
[ 5] 10.00-11.00 sec 66.2 MBytes 556 Mbits/sec 2471 2.20 MBytes
[ 5] 11.00-12.00 sec 70.0 MBytes 587 Mbits/sec 4959 964 KBytes
[ 5] 12.00-13.00 sec 66.2 MBytes 556 Mbits/sec 3696 2.26 MBytes
[ 5] 13.00-14.00 sec 70.0 MBytes 587 Mbits/sec 3885 1.88 MBytes
[ 5] 14.00-15.01 sec 67.5 MBytes 561 Mbits/sec 9621 1.59 MBytes
[ 5] 15.01-16.00 sec 67.5 MBytes 572 Mbits/sec 10308 1.81 MBytes
[ 5] 16.00-17.00 sec 67.5 MBytes 566 Mbits/sec 6166 1.41 MBytes
[ 5] 17.00-18.00 sec 67.5 MBytes 566 Mbits/sec 2273 1.61 MBytes
[ 5] 18.00-19.00 sec 67.5 MBytes 566 Mbits/sec 7242 1.05 MBytes
[ 5] 19.00-20.00 sec 67.5 MBytes 566 Mbits/sec 3519 1.56 MBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-20.00 sec 1.32 GBytes 566 Mbits/sec 116286 sender
[ 5] 0.00-20.01 sec 1.32 GBytes 566 Mbits/sec receiver
iperf Done.
-
Voila, c'est un résultat normal.
Breizh29, si tu le souhaites une capture Wireshark devrait permettre de savoir pourquoi le débit ne monte pas.
-
Oui, j’ai vu ça.
On est à des années-lumière de mon résultat.
Je vais installer wireshark et faire une capture.
-
Oui, j’ai vu ça.
On est à des années-lumière de mon résultat.
Je vais installer wireshark et faire une capture.
Tu n'es pas un cas isolé...
Voici ce que j'ai chez Free, avec une V6 en ZMD.
Sûr que ça vient de chez Free car chez Orange je n'avais pas du tout ça.
On est plusieurs à avoir ce résultat (cf d'autres topics).
Connecting to host bouygues.testdebit.info, port 5201
[ 5] local 192.168.10.2 port 48350 connected to 89.84.1.222 port 5201
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 16.7 MBytes 140 Mbits/sec 22 180 KBytes
[ 5] 1.00-2.00 sec 12.4 MBytes 104 Mbits/sec 6 175 KBytes
[ 5] 2.00-3.00 sec 11.8 MBytes 99.0 Mbits/sec 4 173 KBytes
[ 5] 3.00-4.00 sec 14.3 MBytes 120 Mbits/sec 0 229 KBytes
[ 5] 4.00-5.00 sec 16.2 MBytes 136 Mbits/sec 1 205 KBytes
[ 5] 5.00-6.00 sec 10.1 MBytes 84.4 Mbits/sec 10 150 KBytes
[ 5] 6.00-7.00 sec 9.94 MBytes 83.4 Mbits/sec 2 154 KBytes
[ 5] 7.00-8.00 sec 13.7 MBytes 115 Mbits/sec 0 212 KBytes
[ 5] 8.00-9.00 sec 16.3 MBytes 137 Mbits/sec 7 188 KBytes
[ 5] 9.00-10.00 sec 13.8 MBytes 116 Mbits/sec 7 175 KBytes
[ 5] 10.00-11.00 sec 13.0 MBytes 109 Mbits/sec 16 165 KBytes
[ 5] 11.00-12.00 sec 14.3 MBytes 120 Mbits/sec 0 222 KBytes
[ 5] 12.00-13.00 sec 17.7 MBytes 149 Mbits/sec 1 195 KBytes
[ 5] 13.00-14.00 sec 11.2 MBytes 93.8 Mbits/sec 3 136 KBytes
[ 5] 14.00-15.00 sec 12.4 MBytes 104 Mbits/sec 0 192 KBytes
[ 5] 15.00-16.00 sec 13.2 MBytes 111 Mbits/sec 10 181 KBytes
[ 5] 16.00-17.00 sec 12.1 MBytes 101 Mbits/sec 6 122 KBytes
[ 5] 17.00-18.00 sec 11.2 MBytes 93.8 Mbits/sec 0 178 KBytes
[ 5] 18.00-19.00 sec 11.2 MBytes 93.8 Mbits/sec 13 126 KBytes
[ 5] 19.00-20.00 sec 11.2 MBytes 93.8 Mbits/sec 0 182 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-20.00 sec 263 MBytes 110 Mbits/sec 108 sender
[ 5] 0.00-20.04 sec 261 MBytes 109 Mbits/sec receiver
En 4 flux
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-20.00 sec 158 MBytes 66.2 Mbits/sec 272 sender
[ 5] 0.00-20.01 sec 156 MBytes 65.5 Mbits/sec receiver
[ 7] 0.00-20.00 sec 141 MBytes 59.3 Mbits/sec 152 sender
[ 7] 0.00-20.01 sec 141 MBytes 59.0 Mbits/sec receiver
[ 9] 0.00-20.00 sec 123 MBytes 51.4 Mbits/sec 192 sender
[ 9] 0.00-20.01 sec 122 MBytes 51.2 Mbits/sec receiver
[ 11] 0.00-20.00 sec 154 MBytes 64.8 Mbits/sec 216 sender
[ 11] 0.00-20.01 sec 154 MBytes 64.5 Mbits/sec receiver
[SUM] 0.00-20.00 sec 576 MBytes 242 Mbits/sec 832 sender
[SUM] 0.00-20.01 sec 573 MBytes 240 Mbits/sec receiver
En 8 flux
[SUM] 0.00-20.00 sec 806 MBytes 338 Mbits/sec 1415 sender
[SUM] 0.00-20.01 sec 800 MBytes 335 Mbits/sec receiver
En 16 flux
[SUM] 0.00-20.00 sec 905 MBytes 380 Mbits/sec 3325 sender
[SUM] 0.00-20.01 sec 899 MBytes 377 Mbits/sec receiver
En 24 flux
[SUM] 0.00-20.00 sec 931 MBytes 390 Mbits/sec 6087 sender
[SUM] 0.00-20.01 sec 924 MBytes 387 Mbits/sec receiver
En 32 flux
[SUM] 0.00-20.00 sec 996 MBytes 418 Mbits/sec 8474 sender
[SUM] 0.00-20.01 sec 989 MBytes 415 Mbits/sec receiver
-
Cryptage, je vois un problème dans ton test : il est réalisé en IPv4 alors que ton FAI ne propose plus de désactiver IPv4 et que le serveur est IPv6.
Sais tu expliquer pourquoi le test s'est fait en IPv4 et serait-il possible de comparer avec l'IPv6 ?
-
J'ai fait la capture et j'ai un fichier de 856 Mo et quelques de capture (en filtrant ipv6 du serveur en source ou dest).
Qui n'en veut ? Vivien ?... ;D
-
Oui, je suis intéressé.
Tu as vérifié qu'il n'y avait pas trop de paquets perdus (non capturé par Wireshark) ?
-
@Vivien :
Pour l'IPv4 c'est normal, comme je fais du dual WAN je passe par un routeur derrière la Freebox mais je n'ai pas de solution efficace aujourd'hui en IPv6 pour le multihoming donc dans l'immédiat je n'ai que de l'IPv4.
Certes Free fournit de l'IPv6 natif (et encapsule IPv4) mais ça ne change rien sur le débit.
Ci-dessous les tests en IPv6 puis en IPv4, en étant connecté directement sur la Freebox.
Les débits sont toujours merdiques, comme depuis le début... (Free ne veut rien faire, "tout est normal").
IPv6 (1 flux) :
Connecting to host bouygues.testdebit.info, port 5201
[ 4] local 2a01:e0a:2d... port 49773 connected to 2001:860:deff:1000::2 port 5201
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-1.01 sec 6.12 MBytes 51.0 Mbits/sec
[ 4] 1.01-2.00 sec 8.88 MBytes 75.0 Mbits/sec
[ 4] 2.00-3.00 sec 8.38 MBytes 70.3 Mbits/sec
[ 4] 3.00-4.00 sec 5.00 MBytes 41.9 Mbits/sec
[ 4] 4.00-5.00 sec 8.62 MBytes 72.4 Mbits/sec
[ 4] 5.00-6.00 sec 13.1 MBytes 110 Mbits/sec
[ 4] 6.00-7.01 sec 7.00 MBytes 58.4 Mbits/sec
[ 4] 7.01-8.01 sec 9.50 MBytes 80.0 Mbits/sec
[ 4] 8.01-9.00 sec 8.75 MBytes 73.8 Mbits/sec
[ 4] 9.00-10.00 sec 13.0 MBytes 109 Mbits/sec
[ 4] 10.00-11.01 sec 6.75 MBytes 55.9 Mbits/sec
[ 4] 11.01-12.01 sec 8.38 MBytes 70.7 Mbits/sec
[ 4] 12.01-13.01 sec 11.6 MBytes 96.8 Mbits/sec
[ 4] 13.01-14.00 sec 7.00 MBytes 59.6 Mbits/sec
[ 4] 14.00-15.01 sec 11.8 MBytes 97.8 Mbits/sec
[ 4] 15.01-16.01 sec 11.4 MBytes 94.8 Mbits/sec
[ 4] 16.01-17.00 sec 6.88 MBytes 58.3 Mbits/sec
[ 4] 17.00-18.00 sec 11.5 MBytes 96.7 Mbits/sec
[ 4] 18.00-19.00 sec 7.62 MBytes 64.0 Mbits/sec
[ 4] 19.00-20.00 sec 10.1 MBytes 84.9 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-20.00 sec 181 MBytes 76.1 Mbits/sec sender
[ 4] 0.00-20.00 sec 181 MBytes 76.1 Mbits/sec receiver
IPv6 2 flux :
[SUM] 0.00-20.01 sec 281 MBytes 118 Mbits/sec sender
[SUM] 0.00-20.01 sec 281 MBytes 118 Mbits/sec receiver
IPv6 4 flux :
[SUM] 0.00-20.00 sec 470 MBytes 197 Mbits/sec sender
[SUM] 0.00-20.00 sec 469 MBytes 197 Mbits/sec receiver
IPv6 8 flux :
[SUM] 0.00-20.01 sec 651 MBytes 273 Mbits/sec sender
[SUM] 0.00-20.01 sec 650 MBytes 273 Mbits/sec receiver
IPv6 16 flux :
[SUM] 0.00-20.00 sec 798 MBytes 335 Mbits/sec sender
[SUM] 0.00-20.00 sec 795 MBytes 334 Mbits/sec receiver
IPv4 (1 flux) :
Connecting to host bouygues.testdebit.info, port 5201
[ 4] local 192.168.200.22 port 49876 connected to 89.84.1.222 port 5201
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-1.01 sec 3.50 MBytes 29.1 Mbits/sec
[ 4] 1.01-2.00 sec 8.88 MBytes 75.1 Mbits/sec
[ 4] 2.00-3.00 sec 12.8 MBytes 107 Mbits/sec
[ 4] 3.00-4.00 sec 7.00 MBytes 58.9 Mbits/sec
[ 4] 4.00-5.01 sec 5.62 MBytes 46.7 Mbits/sec
[ 4] 5.01-6.01 sec 9.50 MBytes 80.1 Mbits/sec
[ 4] 6.01-7.01 sec 10.9 MBytes 91.5 Mbits/sec
[ 4] 7.01-8.01 sec 10.4 MBytes 86.2 Mbits/sec
[ 4] 8.01-9.00 sec 5.88 MBytes 50.0 Mbits/sec
[ 4] 9.00-10.00 sec 9.00 MBytes 75.4 Mbits/sec
[ 4] 10.00-11.01 sec 8.25 MBytes 68.8 Mbits/sec
[ 4] 11.01-12.00 sec 10.8 MBytes 90.7 Mbits/sec
[ 4] 12.00-13.01 sec 6.88 MBytes 57.1 Mbits/sec
[ 4] 13.01-14.01 sec 7.50 MBytes 63.0 Mbits/sec
[ 4] 14.01-15.01 sec 8.38 MBytes 70.4 Mbits/sec
[ 4] 15.01-16.01 sec 8.12 MBytes 68.3 Mbits/sec
[ 4] 16.01-17.00 sec 9.25 MBytes 77.8 Mbits/sec
[ 4] 17.00-18.01 sec 5.50 MBytes 45.9 Mbits/sec
[ 4] 18.01-19.01 sec 6.62 MBytes 55.6 Mbits/sec
[ 4] 19.01-20.00 sec 10.2 MBytes 86.2 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-20.00 sec 165 MBytes 69.1 Mbits/sec sender
[ 4] 0.00-20.00 sec 165 MBytes 69.1 Mbits/sec receiver
IPv4 2 flux :
[SUM] 0.00-20.01 sec 270 MBytes 113 Mbits/sec sender
[SUM] 0.00-20.01 sec 270 MBytes 113 Mbits/sec receiver
IPv4 4 flux :
[SUM] 0.00-20.01 sec 495 MBytes 207 Mbits/sec sender
[SUM] 0.00-20.01 sec 494 MBytes 207 Mbits/sec receiver
IPv4 8 flux :
[SUM] 0.00-20.00 sec 657 MBytes 276 Mbits/sec sender
[SUM] 0.00-20.00 sec 656 MBytes 275 Mbits/sec receiver
IPv4 16 flux :
[SUM] 0.00-20.00 sec 818 MBytes 343 Mbits/sec sender
[SUM] 0.00-20.00 sec 815 MBytes 342 Mbits/sec receiver
Edit : je viens de faire le test en bbr et c'est juste hallucinant... :o
Par contre sous Windows que ce soit en cubic, ctcp, dctcp ou newreno ça ne change strictement rien... débit de merde en upload. :-\
Je ne sais pas ce qu'on peut en conclure... Saturation chez Free ?
1 flux :
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-20.00 sec 1.17 GBytes 503 Mbits/sec 89401 sender
[ 5] 0.00-20.04 sec 1.17 GBytes 501 Mbits/sec receiver
2 flux :
[SUM] 0.00-20.00 sec 1.26 GBytes 542 Mbits/sec 122231 sender
[SUM] 0.00-20.03 sec 1.26 GBytes 539 Mbits/sec receiver
Pour les abonnés Free qui ont le même genre de désagréments n'hésitez-pas à voter ici : https://dev.freebox.fr/bugs/task/29953
-
Edit 2 : pour les abonnés Free qui ont le même genre de désagréments n'hésitez-pas à voter ici : https://dev.freebox.fr/bugs/task/29953
Merci pour ce lien, je vais aller voir.
Tant que les freenautes se contenteront d'un test en ligne en connexions multiples, il n'y verront que du feu... :(
Edit : voilà j'ai voté!! :)
-
Moi ? FAI ? autre ?
ça vient visiblement de chez Free, confert les réponse au sujet 'test débit single/multiple'.
tous ceux qui ont testé de chez free ont un upload single merdique, les autres ça diminue un peu par rapport à une connexion multiple, mais ça reste potable
-
pour les abonnés Free qui ont le même genre de désagréments n'hésitez-pas à voter ici : https://dev.freebox.fr/bugs/task/29953
Comment ça se fait qu'elle n'est pas dans les tâches du 10/02/2020? https://dev.freebox.fr/bugs/proj9
ah au temps pour moi ça ressort quand tu classes par date mais ils ne le mettent pas sur la page principale 'liste des tâches'...y aurait il un loup? ;D
-
Je ne sais pas ce qu'on peut en conclure... Saturation chez Free ?
Je pense que c'est bridé sciemment. Dans un article (http://"https://freebox-news.com/tutoriel/test-debit-free") de freebox-news.com, il était dit qu'un débit up de 100 mbps était jugé acceptable pour ceux qui ont la fibre.... >:( :( heureusement que ce n'est pas le site officiel de FREE
Ainsi, dans des conditions habituelles d’utilisation, un débit est considéré comme satisfaisant avec la fibre autour de 100 Mbits/s. En ADSL, un débit satisfaisant est le plus souvent compris entre 7 Mbits/s et 10 Mbits/s. Dans l’autre sens, la vitesse de débit montant se situe habituellement entre 0,5 Mbits/s à 2 Mbits/s en ADSL. En effet, comme tous les FAI, Free privilégie le download, plus immédiatement visible pour les utilisateurs, à l’upload dont la rapidité n’est pas perçue comme essentielle dans les applications destinées grand public.
Archive de 2007 de 01.net : https://www.01net.com/actualites/free-bride-le-debit-montant-de-certains-abonnes-368160.html
Certains Freenautes assidus n'ont pas apprécié le cadeau de fin d'année de leur fournisseur d'accès. En effet, nombre d'abonnés dégroupés ont constaté ces dernières semaines une baisse du débit montant de leur ligne (upload), passant de 1 Mbit/s à environ 665 kbit/s. Une dégradation surtout pénalisante pour les grands consommateurs de bande passante, adeptes des gros transferts de fichiers, du peer to peer, mais aussi par exemple du service de vidéos personnelles de Free (TV Perso).Alerté via ses forums, le site Univers Freebox a sondé ses lecteurs et abouti à la conclusion que le problème était lié au mode de synchronisation Standard proposé sur la Freebox. Une hypothèse confirmée par Free : le mode Standard a bien été modifié sur certains types de lignes ' afin de garantir de meilleures performances au plus grand nombre de freenautes possibles ', a indiqué Xavier Niel, fondateur et directeur général délégué à la stratégie, à Univers Freebox.
Ils seraient coutumiers du fait...
-
Si c'était un bridage volontaire, une changement d'algorithme de congestion aurait autant d'effet ?
-
Si c'était un bridage volontaire, une changement d'algorithme de congestion aurait autant d'effet ?
Non.
-
Non.
si ce n'est pas volontaire, tant mieux, mais ça a été le cas par le passé. Du coup quel est le problème chez Free? sous-dimensionnement des tuyaux?
chez Orange je n'avais aucun problème d'upload
-
si ce n'est pas volontaire, tant mieux, mais ça a été le cas par le passé. Du coup quel est le problème chez Free? sous-dimensionnement des tuyaux?
chez Orange je n'avais aucun problème d'upload
C'est dur à dire parce que si en BBR on arrive à avoir plus c'est bien qu'on peut...
Probablement que c'est fait au détriment d'autres abonnés mais ça paraît bizarre.
Le sous-dimensionnement est une piste sérieuse.
Le fait que Free ignore ce problème ça commence à devenir lourd...
-
Le fait que Free ignore ce problème ça commence à devenir lourd...
effectivement, s'ils s'en foutent, ils cautionnent un peu quelque part...
-
J'ai fait la capture et j'ai un fichier de 856 Mo et quelques de capture (en filtrant ipv6 du serveur en source ou dest).
Qui n'en veut ? Vivien ?... ;D
L'analyse est dans un sujet à part : Tuto: Analyser les problèmes de débit avec Wireshark (https://lafibre.info/tcpip/analyser-avec-wireshark/)
Je demande en conclusion un test complémentaire :
Conclusion de cette capture :
Cela montre de façon quasiment certaine que l'endroit des buffers sont trop petits pour permettre d'avoir de bon débits sur une connexion TCP. Il faudrait, si c'est possible logiciellement, augmenter cette taille des buffers.
Les buffers qui posent problème sont toujours ceux à l'endroit où le débit est limité à 600 Mb/s. Cette limitation est probablement réalisée sur l'OLT, située dans le NRO, toutefois, il est possible que les buffers de la Freebox soient eaux aussi sollicités en débit montant : Le 10G-EPON (IEEE 802.3av) mis en place par Free limite le débit de l'arbre à 1244 Mb/s (débit partagé par tous les clients). Il est donc possible que le buffers trop petit soient au niveau de la Freebox, juste avant que le débit parte sur l'arbre avec une limitation physique à 1244 Mb/s, soit au niveau de l'OLT qui doit limiter le débit montant aux 600 Mb/s contractuel.
Comment savoir si c'est plutôt coté OLT ou coté Freebox que le débit est trop faible ?
Le test serait de faire un comparatif avec une connexion 1 Gb/s (connecter le PC sur port 1 Gb/s de la Freebox est suffisant).
Si le débit montant est nettement meilleur avec une connexion 1 Gb/s, la limitation est du coté Freebox.
Si le débit n'est pas meilleur, il est plus difficile de tirer une conclusion, mais le buffer trop petit est probablement coté OLT, là où est fait la limitation du débit montant. Dans le cas (possible également mais peu probable) où la limitation de débit à 600 Mb/s est réalisé coté Freebox, alors ce sera le buffer coté Freebox, au niveau de la limitation à 600 Mb/s)
-
Juste pour revenir sur le problème de débit UL 'bbr' vs 'cubic', j'aimerai aussi ajouter une petite constatation que j'ai fais aujourd'hui.
En faisant tourner un test DL en même temps qu'un test UL pendant quelques minutes, j'ai remarqué que soit l'UL, soit le DL est FORTEMENT impacté par le test, du genre de 550Mbps à 40Mbps pour l'UL, ou 880Mbps à 200Mbps en DL. C'est soit l'un, soit l'autre qui est impacté.
Sachant qu'en unitaire j'ai le max, je suis prèt à parier que ce n'est pas un problème de congestion du réseau chez Free, mais uniquement un problème local entre l'ONT et l'OLT. Je sens un problème de sous dimensionnement d'un buffer (ONT ou OLT) qui sature s'il y a UL et DL en parallèle (avec une priorité pour le DL). Module de chiffrement de l'ONT/OLT qui a un buffer trop petit ? Algorithme limitant le débit UL qui est mal fichu ? Mystère !
Ce serait limite marrant de poster vos résultats d'iperf avec UL/DL en même temps (2 iperf3).
Edit: mes 2 sessions en // à 1 seconde d'intervalle
[ 5] 1.00-2.00 sec 8.75 MBytes 73.4 Mbits/sec 2587 139 KBytes [ 5] 2.00-3.00 sec 76.9 MBytes 645 Mbits/sec
[ 5] 2.00-3.00 sec 6.25 MBytes 52.4 Mbits/sec 915 107 KBytes [ 5] 3.00-4.00 sec 89.4 MBytes 750 Mbits/sec
[ 5] 3.00-4.00 sec 6.25 MBytes 52.4 Mbits/sec 766 130 KBytes [ 5] 4.00-5.00 sec 87.8 MBytes 736 Mbits/sec
[ 5] 4.00-5.00 sec 15.0 MBytes 126 Mbits/sec 2141 814 KBytes [ 5] 5.00-6.00 sec 85.3 MBytes 716 Mbits/sec
[ 5] 5.00-6.00 sec 33.8 MBytes 283 Mbits/sec 6902 554 KBytes [ 5] 6.00-7.00 sec 52.6 MBytes 442 Mbits/sec
[ 5] 6.00-7.00 sec 16.2 MBytes 136 Mbits/sec 4572 167 KBytes [ 5] 7.00-8.00 sec 69.5 MBytes 583 Mbits/sec
[ 5] 7.00-8.00 sec 6.25 MBytes 52.4 Mbits/sec 1090 96.2 KBytes [ 5] 8.00-9.00 sec 88.3 MBytes 741 Mbits/sec
[ 5] 8.00-9.00 sec 5.00 MBytes 41.9 Mbits/sec 403 84.8 KBytes [ 5] 9.00-10.00 sec 99.9 MBytes 838 Mbits/sec
[ 5] 9.00-10.00 sec 6.25 MBytes 52.4 Mbits/sec 938 127 KBytes [ 5] 10.00-11.00 sec 97.7 MBytes 820 Mbits/sec
[ 5] 10.00-11.00 sec 6.25 MBytes 52.4 Mbits/sec 574 113 KBytes [ 5] 11.00-12.00 sec 90.7 MBytes 761 Mbits/sec
[ 5] 11.00-12.00 sec 6.25 MBytes 52.4 Mbits/sec 842 130 KBytes [ 5] 12.00-13.00 sec 88.4 MBytes 741 Mbits/sec
[ 5] 12.00-13.00 sec 6.25 MBytes 52.4 Mbits/sec 513 116 KBytes [ 5] 13.00-14.00 sec 90.3 MBytes 758 Mbits/sec
[ 5] 13.00-14.00 sec 5.00 MBytes 41.9 Mbits/sec 725 127 KBytes [ 5] 14.00-15.00 sec 95.7 MBytes 803 Mbits/sec
[ 5] 14.00-15.00 sec 5.00 MBytes 41.9 Mbits/sec 431 52.3 KBytes [ 5] 15.00-16.00 sec 100 MBytes 842 Mbits/sec
[ 5] 15.00-16.00 sec 31.2 MBytes 262 Mbits/sec 4807 622 KBytes [ 5] 16.00-17.00 sec 65.2 MBytes 547 Mbits/sec
[ 5] 16.00-17.00 sec 20.0 MBytes 168 Mbits/sec 6518 419 KBytes [ 5] 17.00-18.00 sec 67.9 MBytes 570 Mbits/sec
[ 5] 17.00-18.00 sec 12.5 MBytes 105 Mbits/sec 4304 243 KBytes [ 5] 18.00-19.00 sec 73.3 MBytes 615 Mbits/sec
[ 5] 18.00-19.00 sec 8.75 MBytes 73.4 Mbits/sec 2654 133 KBytes [ 5] 19.00-20.00 sec 83.4 MBytes 700 Mbits/sec
[ 5] 19.00-20.00 sec 5.00 MBytes 41.9 Mbits/sec 862 93.3 KBytes [ 5] 20.00-21.00 sec 94.0 MBytes 789 Mbits/sec
[ 5] 20.00-21.00 sec 5.00 MBytes 41.9 Mbits/sec 353 84.8 KBytes [ 5] 21.00-22.00 sec 102 MBytes 855 Mbits/sec
[ 5] 21.00-22.00 sec 5.00 MBytes 41.9 Mbits/sec 269 84.8 KBytes [ 5] 22.00-23.00 sec 103 MBytes 866 Mbits/sec
[ 5] 22.00-23.00 sec 5.00 MBytes 41.9 Mbits/sec 384 90.5 KBytes [ 5] 23.00-24.00 sec 102 MBytes 854 Mbits/sec
[ 5] 23.00-24.00 sec 5.00 MBytes 41.9 Mbits/sec 381 67.9 KBytes [ 5] 24.00-25.00 sec 101 MBytes 847 Mbits/sec
[ 5] 24.00-25.00 sec 13.8 MBytes 115 Mbits/sec 2535 591 KBytes [ 5] 25.00-26.00 sec 85.2 MBytes 715 Mbits/sec
[ 5] 25.00-26.00 sec 46.2 MBytes 388 Mbits/sec 4599 1.22 MBytes [ 5] 26.00-27.00 sec 38.1 MBytes 320 Mbits/sec
[ 5] 26.00-27.00 sec 46.2 MBytes 388 Mbits/sec 6075 772 KBytes [ 5] 27.00-28.00 sec 42.0 MBytes 352 Mbits/sec
[ 5] 27.00-28.00 sec 25.0 MBytes 210 Mbits/sec 6616 430 KBytes [ 5] 28.00-29.00 sec 66.2 MBytes 555 Mbits/sec
[ 5] 28.00-29.00 sec 13.8 MBytes 115 Mbits/sec 3786 161 KBytes [ 5] 29.00-30.00 sec 74.4 MBytes 624 Mbits/sec
[ 5] 29.00-30.00 sec 6.25 MBytes 52.4 Mbits/sec 1279 83.4 KBytes [ 5] 30.00-31.00 sec 87.1 MBytes 731 Mbits/sec
[ 5] 30.00-31.00 sec 5.00 MBytes 41.9 Mbits/sec 384 82.0 KBytes [ 5] 31.00-32.00 sec 85.9 MBytes 720 Mbits/sec
[ 5] 31.00-32.00 sec 5.00 MBytes 41.9 Mbits/sec 384 82.0 KBytes [ 5] 32.00-33.00 sec 99.2 MBytes 832 Mbits/sec
[ 5] 32.00-33.00 sec 5.00 MBytes 41.9 Mbits/sec 454 105 KBytes [ 5] 33.00-34.00 sec 101 MBytes 850 Mbits/sec
[ 5] 33.00-34.00 sec 5.00 MBytes 41.9 Mbits/sec 683 102 KBytes [ 5] 34.00-35.00 sec 99.6 MBytes 836 Mbits/sec
[ 5] 34.00-35.00 sec 5.00 MBytes 41.9 Mbits/sec 406 87.7 KBytes [ 5] 35.00-36.00 sec 102 MBytes 852 Mbits/sec
[ 5] 35.00-36.00 sec 5.00 MBytes 41.9 Mbits/sec 393 113 KBytes [ 5] 36.00-37.00 sec 103 MBytes 867 Mbits/sec
[ 5] 36.00-37.00 sec 5.00 MBytes 41.9 Mbits/sec 572 82.0 KBytes [ 5] 37.00-38.00 sec 101 MBytes 843 Mbits/sec
[ 5] 37.00-38.00 sec 5.00 MBytes 41.9 Mbits/sec 486 127 KBytes [ 5] 38.00-39.00 sec 100 MBytes 843 Mbits/sec
[ 5] 38.00-39.00 sec 5.00 MBytes 41.9 Mbits/sec 569 105 KBytes [ 5] 39.00-40.00 sec 102 MBytes 857 Mbits/sec
[ 5] 39.00-40.00 sec 3.75 MBytes 31.5 Mbits/sec 436 116 KBytes [ 5] 40.00-41.00 sec 103 MBytes 865 Mbits/sec
[ 5] 40.00-41.00 sec 6.25 MBytes 52.4 Mbits/sec 677 107 KBytes [ 5] 41.00-42.00 sec 94.9 MBytes 796 Mbits/sec
[ 5] 41.00-42.00 sec 6.25 MBytes 52.4 Mbits/sec 716 72.1 KBytes [ 5] 42.00-43.00 sec 90.2 MBytes 757 Mbits/sec
[ 5] 42.00-43.00 sec 5.00 MBytes 41.9 Mbits/sec 401 84.8 KBytes [ 5] 43.00-44.00 sec 95.3 MBytes 799 Mbits/sec
[ 5] 43.00-44.00 sec 5.00 MBytes 41.9 Mbits/sec 338 90.5 KBytes [ 5] 44.00-45.00 sec 101 MBytes 843 Mbits/sec
[ 5] 44.00-45.00 sec 5.00 MBytes 41.9 Mbits/sec 451 87.7 KBytes [ 5] 45.00-46.00 sec 101 MBytes 844 Mbits/sec
[ 5] 45.00-46.00 sec 5.00 MBytes 41.9 Mbits/sec 455 94.7 KBytes [ 5] 46.00-47.00 sec 103 MBytes 865 Mbits/sec
[ 5] 46.00-47.00 sec 5.00 MBytes 41.9 Mbits/sec 511 87.7 KBytes [ 5] 47.00-48.00 sec 102 MBytes 860 Mbits/sec
[ 5] 47.00-48.00 sec 3.75 MBytes 31.5 Mbits/sec 379 53.7 KBytes [ 5] 48.00-49.00 sec 102 MBytes 859 Mbits/sec
[ 5] 48.00-49.00 sec 5.00 MBytes 41.9 Mbits/sec 404 84.8 KBytes [ 5] 49.00-50.00 sec 103 MBytes 864 Mbits/sec
[ 5] 49.00-50.00 sec 6.25 MBytes 52.4 Mbits/sec 495 105 KBytes [ 5] 50.00-51.00 sec 101 MBytes 850 Mbits/sec
[ 5] 50.00-51.00 sec 5.00 MBytes 41.9 Mbits/sec 814 76.4 KBytes [ 5] 51.00-52.00 sec 97.1 MBytes 814 Mbits/sec
[ 5] 51.00-52.00 sec 6.25 MBytes 52.4 Mbits/sec 709 110 KBytes [ 5] 52.00-53.00 sec 91.8 MBytes 770 Mbits/sec
[ 5] 52.00-53.00 sec 5.00 MBytes 41.9 Mbits/sec 554 105 KBytes [ 5] 53.00-54.00 sec 92.7 MBytes 778 Mbits/sec
[ 5] 53.00-54.00 sec 5.00 MBytes 41.9 Mbits/sec 508 96.2 KBytes [ 5] 54.00-55.00 sec 103 MBytes 861 Mbits/sec
[ 5] 54.00-55.00 sec 23.8 MBytes 199 Mbits/sec 2460 851 KBytes [ 5] 55.00-56.00 sec 79.9 MBytes 670 Mbits/sec
[ 5] 55.00-56.00 sec 27.5 MBytes 231 Mbits/sec 5982 611 KBytes [ 5] 56.00-57.00 sec 64.8 MBytes 543 Mbits/sec
[ 5] 56.00-57.00 sec 27.5 MBytes 231 Mbits/sec 2207 288 KBytes [ 5] 57.00-58.00 sec 58.3 MBytes 489 Mbits/sec
[ 5] 57.00-58.00 sec 8.75 MBytes 73.4 Mbits/sec 2887 161 KBytes [ 5] 58.00-59.00 sec 74.1 MBytes 621 Mbits/sec
[ 5] 58.00-59.00 sec 6.25 MBytes 52.4 Mbits/sec 989 56.6 KBytes [ 5] 59.00-60.00 sec 94.3 MBytes 791 Mbits/sec
[ 5] 59.00-60.00 sec 5.00 MBytes 41.9 Mbits/sec 525 110 KBytes [ 5] 60.00-61.00 sec 93.2 MBytes 782 Mbits/sec
[ 5] 60.00-61.00 sec 6.25 MBytes 52.4 Mbits/sec 473 122 KBytes [ 5] 61.00-62.00 sec 89.4 MBytes 750 Mbits/sec
[ 5] 61.00-62.00 sec 5.00 MBytes 41.9 Mbits/sec 404 107 KBytes [ 5] 62.00-63.00 sec 81.0 MBytes 679 Mbits/sec
[ 5] 62.00-63.00 sec 5.00 MBytes 41.9 Mbits/sec 409 79.2 KBytes [ 5] 63.00-64.00 sec 103 MBytes 864 Mbits/sec
[ 5] 63.00-64.00 sec 5.00 MBytes 41.9 Mbits/sec 327 90.5 KBytes [ 5] 64.00-65.00 sec 102 MBytes 858 Mbits/sec
[ 5] 64.00-65.00 sec 5.00 MBytes 41.9 Mbits/sec 706 115 KBytes [ 5] 65.00-66.00 sec 98.5 MBytes 827 Mbits/sec
[ 5] 65.00-66.00 sec 7.50 MBytes 62.9 Mbits/sec 723 73.5 KBytes [ 5] 66.00-67.00 sec 91.5 MBytes 767 Mbits/sec
[ 5] 66.00-67.00 sec 18.8 MBytes 157 Mbits/sec 4212 419 KBytes [ 5] 67.00-68.00 sec 63.0 MBytes 529 Mbits/sec
[ 5] 67.00-68.00 sec 8.75 MBytes 73.4 Mbits/sec 2958 170 KBytes [ 5] 68.00-69.00 sec 75.0 MBytes 629 Mbits/sec
[ 5] 68.00-69.00 sec 6.25 MBytes 52.4 Mbits/sec 898 113 KBytes [ 5] 69.00-70.00 sec 95.6 MBytes 802 Mbits/sec
[ 5] 69.00-70.00 sec 5.00 MBytes 41.9 Mbits/sec 399 87.7 KBytes [ 5] 70.00-71.00 sec 103 MBytes 861 Mbits/sec
[ 5] 70.00-71.00 sec 6.25 MBytes 52.4 Mbits/sec 483 140 KBytes [ 5] 71.00-72.00 sec 81.9 MBytes 687 Mbits/sec
[ 5] 71.00-72.00 sec 6.25 MBytes 52.4 Mbits/sec 1056 150 KBytes [ 5] 72.00-73.00 sec 86.8 MBytes 728 Mbits/sec
[ 5] 72.00-73.00 sec 6.25 MBytes 52.4 Mbits/sec 894 65.0 KBytes [ 5] 73.00-74.00 sec 92.3 MBytes 775 Mbits/sec
[ 5] 73.00-74.00 sec 5.00 MBytes 41.9 Mbits/sec 438 122 KBytes [ 5] 74.00-75.00 sec 96.0 MBytes 805 Mbits/sec
[ 5] 74.00-75.00 sec 7.50 MBytes 62.9 Mbits/sec 1032 147 KBytes [ 5] 75.00-76.00 sec 90.2 MBytes 757 Mbits/sec
[ 5] 75.00-76.00 sec 6.25 MBytes 52.4 Mbits/sec 922 77.8 KBytes [ 5] 76.00-77.00 sec 89.4 MBytes 750 Mbits/sec
[ 5] 76.00-77.00 sec 25.0 MBytes 210 Mbits/sec 3254 670 KBytes [ 5] 77.00-78.00 sec 69.6 MBytes 584 Mbits/sec
[ 5] 77.00-78.00 sec 38.8 MBytes 325 Mbits/sec 2821 512 KBytes [ 5] 78.00-79.00 sec 57.2 MBytes 480 Mbits/sec
[ 5] 78.00-79.00 sec 18.8 MBytes 157 Mbits/sec 6661 294 KBytes [ 5] 79.00-80.00 sec 66.7 MBytes 560 Mbits/sec
[ 5] 79.00-80.00 sec 15.0 MBytes 126 Mbits/sec 4870 273 KBytes [ 5] 80.00-81.00 sec 75.1 MBytes 630 Mbits/sec
[ 5] 80.00-81.00 sec 12.5 MBytes 105 Mbits/sec 3524 243 KBytes [ 5] 81.00-82.00 sec 74.4 MBytes 624 Mbits/sec
[ 5] 81.00-82.00 sec 11.2 MBytes 94.4 Mbits/sec 3249 167 KBytes [ 5] 82.00-83.00 sec 64.1 MBytes 538 Mbits/sec
[ 5] 82.00-83.00 sec 6.25 MBytes 52.4 Mbits/sec 1053 102 KBytes [ 5] 83.00-84.00 sec 90.7 MBytes 761 Mbits/sec
[ 5] 83.00-84.00 sec 5.00 MBytes 41.9 Mbits/sec 341 63.6 KBytes [ 5] 84.00-85.00 sec 103 MBytes 867 Mbits/sec
[ 5] 84.00-85.00 sec 13.8 MBytes 115 Mbits/sec 625 1.12 MBytes [ 5] 85.00-86.00 sec 95.4 MBytes 800 Mbits/sec
-
Quand tu réalise simultanément de l'uplaod et du download il y en a un qui va limiter l'autre.
En TCP les accusés de réception sont nécessaire. Si tu sature le débit descendant, le débit montant va être bloqué faute d’acquittement et inversement. Bref le premier qui a la chance d'arriver au débit max va brider l'autre.
Bref, je ne recommande pas de faire des tests en laissant TCP choisir les débits. Des tests avec débit descendant et montant simultanés son possible si on fait attention d'imposer une limite haute de trafic de façon a laisser passer les acquittement dans l'autre sens (réserver 5% du débit maximum atteint quand tu fais un tests dans un test avec uniquement du descendant ou montant)
-
Et ceux qui n'ont pas de soucis d'upload aussi marqué ? Des plus gros buffers sur leurs équipements ?
-
Oui, il doit y avoir une différence de configuration sur des équipements ou un parc d'OLT qui n'est pas homogène.
-
Quand tu réalise simultanément de l'uplaod et du download il y en a un qui va limiter l'autre.
En TCP les accusés de réception sont nécessaire. Si tu sature le débit descendant, le débit montant va être bloqué faute d’acquittement et inversement. Bref le premier qui a la chance d'arriver au débit max va brider l'autre.
Bref, je ne recommande pas de faire des tests en laissant TCP choisir les débits. Des tests avec débit descendant et montant simultanés son possible si on fait attention d'imposer une limite haute de trafic de façon a laisser passer les acquittement dans l'autre sens (réserver 5% du débit maximum atteint quand tu fais un tests dans un test avec uniquement du descendant ou montant)
Je viens de remarquer aussi qu'en cubic les 2 (UL et DL) s'équilibrent, genre 200Mbps en UL et 300Mbps en DL. Mais clairement je ne sature pas le débit max donc les acquittement doivent arriver avec un peu plus de délais.
-
Vivien : est-ce que tu peux compléter mon ticket Free avec ton analyse ou au pire est-ce que tu m'autorises à le faire ?
Des fois que ca puisse permettre de faire remonter en interne...
-
Je demande en conclusion un test complémentaire :
J'ai refait 3 tests à quelques secondes d'intervalle
TEST1 : Liaison 10 Gbps
Connecting to host bouygues.testdebit.info, port 5201
[ 7] local 2a01:e0a:1fc:xxx port 65052 connected to 2001:860:deff:1000::2 port 5201
[ ID] Interval Transfer Bitrate
[ 7] 0.00-1.00 sec 8.68 MBytes 72.8 Mbits/sec
[ 7] 1.00-2.00 sec 13.3 MBytes 111 Mbits/sec
[ 7] 2.00-3.00 sec 14.9 MBytes 125 Mbits/sec
[ 7] 3.00-4.00 sec 12.2 MBytes 102 Mbits/sec
[ 7] 4.00-5.00 sec 19.5 MBytes 164 Mbits/sec
[ 7] 5.00-6.00 sec 28.2 MBytes 237 Mbits/sec
[ 7] 6.00-7.00 sec 37.1 MBytes 312 Mbits/sec
[ 7] 7.00-8.00 sec 45.9 MBytes 385 Mbits/sec
[ 7] 8.00-9.00 sec 55.0 MBytes 461 Mbits/sec
[ 7] 9.00-10.00 sec 63.7 MBytes 535 Mbits/sec
[ 7] 10.00-11.00 sec 46.5 MBytes 390 Mbits/sec
[ 7] 11.00-12.00 sec 12.7 MBytes 107 Mbits/sec
[ 7] 12.00-13.00 sec 22.4 MBytes 188 Mbits/sec
[ 7] 13.00-14.00 sec 10.2 MBytes 85.2 Mbits/sec
[ 7] 14.00-15.00 sec 17.8 MBytes 149 Mbits/sec
[ 7] 15.00-16.00 sec 26.5 MBytes 223 Mbits/sec
[ 7] 16.00-17.00 sec 35.5 MBytes 297 Mbits/sec
[ 7] 17.00-18.00 sec 44.4 MBytes 373 Mbits/sec
[ 7] 18.00-19.00 sec 53.4 MBytes 448 Mbits/sec
[ 7] 19.00-20.00 sec 62.0 MBytes 520 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate
[ 7] 0.00-20.00 sec 630 MBytes 264 Mbits/sec sender
[ 7] 0.00-20.01 sec 627 MBytes 263 Mbits/sec receiver
TEST 2 : Liaison 1 Gbps
Connecting to host bouygues.testdebit.info, port 9220
[ 7] local 2a01:e0a:1fc:xxx port 65192 connected to 2001:860:deff:1000::2 port 9220
[ ID] Interval Transfer Bitrate
[ 7] 0.00-1.00 sec 40.5 MBytes 340 Mbits/sec
[ 7] 1.00-2.00 sec 54.6 MBytes 458 Mbits/sec
[ 7] 2.00-3.00 sec 63.1 MBytes 529 Mbits/sec
[ 7] 3.00-4.00 sec 31.1 MBytes 261 Mbits/sec
[ 7] 4.00-5.00 sec 40.2 MBytes 337 Mbits/sec
[ 7] 5.00-6.00 sec 49.3 MBytes 413 Mbits/sec
[ 7] 6.00-7.00 sec 57.9 MBytes 486 Mbits/sec
[ 7] 7.00-8.00 sec 66.7 MBytes 560 Mbits/sec
[ 7] 8.00-9.00 sec 30.6 MBytes 256 Mbits/sec
[ 7] 9.00-10.00 sec 38.7 MBytes 326 Mbits/sec
[ 7] 10.00-11.00 sec 50.2 MBytes 421 Mbits/sec
[ 7] 11.00-12.00 sec 58.9 MBytes 494 Mbits/sec
[ 7] 12.00-13.00 sec 67.5 MBytes 566 Mbits/sec
[ 7] 13.00-14.00 sec 20.7 MBytes 173 Mbits/sec
[ 7] 14.00-15.00 sec 18.2 MBytes 152 Mbits/sec
[ 7] 15.00-16.00 sec 37.2 MBytes 312 Mbits/sec
[ 7] 16.00-17.00 sec 46.0 MBytes 386 Mbits/sec
[ 7] 17.00-18.00 sec 55.0 MBytes 461 Mbits/sec
[ 7] 18.00-19.00 sec 63.6 MBytes 534 Mbits/sec
[ 7] 19.00-20.00 sec 47.2 MBytes 396 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate
[ 7] 0.00-20.00 sec 937 MBytes 393 Mbits/sec sender
[ 7] 0.00-20.01 sec 933 MBytes 391 Mbits/sec receiver
TEST 3 : Liaison 10 Gbps
Connecting to host bouygues.testdebit.info, port 9220
[ 7] local 2a01:e0a:1fc:xxx port 65309 connected to 2001:860:deff:1000::2 port 9220
[ ID] Interval Transfer Bitrate
[ 7] 0.00-1.00 sec 18.1 MBytes 152 Mbits/sec
[ 7] 1.00-2.00 sec 27.6 MBytes 232 Mbits/sec
[ 7] 2.00-3.00 sec 31.9 MBytes 267 Mbits/sec
[ 7] 3.00-4.00 sec 3.08 MBytes 25.8 Mbits/sec
[ 7] 4.00-5.00 sec 11.7 MBytes 97.9 Mbits/sec
[ 7] 5.00-6.00 sec 9.01 MBytes 75.6 Mbits/sec
[ 7] 6.00-7.00 sec 8.79 MBytes 73.8 Mbits/sec
[ 7] 7.00-8.00 sec 15.7 MBytes 132 Mbits/sec
[ 7] 8.00-9.00 sec 24.3 MBytes 204 Mbits/sec
[ 7] 9.00-10.00 sec 33.0 MBytes 277 Mbits/sec
[ 7] 10.00-11.00 sec 42.2 MBytes 354 Mbits/sec
[ 7] 11.00-12.00 sec 51.3 MBytes 430 Mbits/sec
[ 7] 12.00-13.00 sec 59.9 MBytes 503 Mbits/sec
[ 7] 13.00-14.00 sec 68.0 MBytes 570 Mbits/sec
[ 7] 14.00-15.00 sec 10.7 MBytes 90.1 Mbits/sec
[ 7] 15.00-16.00 sec 17.0 MBytes 143 Mbits/sec
[ 7] 16.00-17.00 sec 26.1 MBytes 219 Mbits/sec
[ 7] 17.00-18.00 sec 34.6 MBytes 290 Mbits/sec
[ 7] 18.00-19.00 sec 43.4 MBytes 364 Mbits/sec
[ 7] 19.00-20.00 sec 52.8 MBytes 443 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate
[ 7] 0.00-20.00 sec 589 MBytes 247 Mbits/sec sender
[ 7] 0.00-20.01 sec 586 MBytes 246 Mbits/sec receiver
TEST 4 : Liaison 1 Gbps
Connecting to host bouygues.testdebit.info, port 9220
[ 7] local 2a01:e0a:1fc:xxx port 49185 connected to 2001:860:deff:1000::2 port 9220
[ ID] Interval Transfer Bitrate
[ 7] 0.00-1.00 sec 22.3 MBytes 187 Mbits/sec
[ 7] 1.00-2.00 sec 22.8 MBytes 191 Mbits/sec
[ 7] 2.00-3.00 sec 32.2 MBytes 270 Mbits/sec
[ 7] 3.00-4.00 sec 41.1 MBytes 345 Mbits/sec
[ 7] 4.00-5.00 sec 49.8 MBytes 418 Mbits/sec
[ 7] 5.00-6.00 sec 58.9 MBytes 494 Mbits/sec
[ 7] 6.00-7.00 sec 67.1 MBytes 563 Mbits/sec
[ 7] 7.00-8.00 sec 29.0 MBytes 243 Mbits/sec
[ 7] 8.00-9.00 sec 38.2 MBytes 320 Mbits/sec
[ 7] 9.00-10.00 sec 28.5 MBytes 239 Mbits/sec
[ 7] 10.00-11.00 sec 41.2 MBytes 345 Mbits/sec
[ 7] 11.00-12.00 sec 50.0 MBytes 419 Mbits/sec
[ 7] 12.00-13.00 sec 58.7 MBytes 493 Mbits/sec
[ 7] 13.00-14.00 sec 57.9 MBytes 485 Mbits/sec
[ 7] 14.00-15.00 sec 19.2 MBytes 161 Mbits/sec
[ 7] 15.00-16.00 sec 32.8 MBytes 275 Mbits/sec
[ 7] 16.00-17.00 sec 41.7 MBytes 350 Mbits/sec
[ 7] 17.00-18.00 sec 50.6 MBytes 424 Mbits/sec
[ 7] 18.00-19.00 sec 59.5 MBytes 499 Mbits/sec
[ 7] 19.00-20.00 sec 67.7 MBytes 568 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate
[ 7] 0.00-20.00 sec 869 MBytes 365 Mbits/sec sender
[ 7] 0.00-20.01 sec 866 MBytes 363 Mbits/sec receiver
Mieux en 1 Gbps, mais significatif pour une conclusion ?
-
Je penche pour le fait qu'en émettant moins vite, tu arrive à avoir moins de pertes qu'avec une ligne 10 Gb/s.
Mais vu les débits qui sont loins 'être optimaux, le pb de buffer est bien présent.
N'hésites pas a me faire une capture en 1 Gb/s.
Note: limite la durée à 10 seconde pour la capture, sinon ce sera un fichier trop gros.
-
De mon côté :
perf3 -c bouygues.testdebit.info -t 20 -i 1
Connecting to host bouygues.testdebit.info, port 5201
[ 5] local 2a01:e0a:1d2:d8f0::xyzb port 36766 connected to 2001:860:deff:1000::2 port 5201
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 66.6 MBytes 558 Mbits/sec 5589 1.96 MBytes
[ 5] 1.00-2.00 sec 67.5 MBytes 566 Mbits/sec 9663 2.03 MBytes
[ 5] 2.00-3.00 sec 63.8 MBytes 535 Mbits/sec 8495 1.57 MBytes
[ 5] 3.00-4.00 sec 67.5 MBytes 566 Mbits/sec 4149 1.61 MBytes
[ 5] 4.00-5.00 sec 66.2 MBytes 555 Mbits/sec 8657 1.66 MBytes
[ 5] 5.00-6.00 sec 71.2 MBytes 598 Mbits/sec 3841 1.52 MBytes
[ 5] 6.00-7.00 sec 67.5 MBytes 566 Mbits/sec 5671 1.45 MBytes
[ 5] 7.00-8.00 sec 67.5 MBytes 566 Mbits/sec 2902 1001 KBytes
[ 5] 8.00-9.00 sec 67.5 MBytes 566 Mbits/sec 8688 1.54 MBytes
[ 5] 9.00-10.00 sec 67.5 MBytes 566 Mbits/sec 4491 1.14 MBytes
[ 5] 10.00-11.00 sec 66.2 MBytes 556 Mbits/sec 2471 2.20 MBytes
[ 5] 11.00-12.00 sec 70.0 MBytes 587 Mbits/sec 4959 964 KBytes
[ 5] 12.00-13.00 sec 66.2 MBytes 556 Mbits/sec 3696 2.26 MBytes
[ 5] 13.00-14.00 sec 70.0 MBytes 587 Mbits/sec 3885 1.88 MBytes
[ 5] 14.00-15.01 sec 67.5 MBytes 561 Mbits/sec 9621 1.59 MBytes
[ 5] 15.01-16.00 sec 67.5 MBytes 572 Mbits/sec 10308 1.81 MBytes
[ 5] 16.00-17.00 sec 67.5 MBytes 566 Mbits/sec 6166 1.41 MBytes
[ 5] 17.00-18.00 sec 67.5 MBytes 566 Mbits/sec 2273 1.61 MBytes
[ 5] 18.00-19.00 sec 67.5 MBytes 566 Mbits/sec 7242 1.05 MBytes
[ 5] 19.00-20.00 sec 67.5 MBytes 566 Mbits/sec 3519 1.56 MBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-20.00 sec 1.32 GBytes 566 Mbits/sec 116286 sender
[ 5] 0.00-20.01 sec 1.32 GBytes 566 Mbits/sec receiver
iperf Done.
le nombre de Retr, 116286 est quand meme énorme. Trop important.
sur un ligne Bytel 1G/500M ca donne:
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-20.00 sec 1.16 GBytes 499 Mbits/sec 3 sender
[ 5] 0.00-20.01 sec 1.16 GBytes 498 Mbits/sec receiver
donc 3 Retr au lieu de 116286 ...
-
Même algo de congestion? Là où j'ai 3000 RETR en bbr mais 550Mbps, j'en ai 8 en cubic mais 200Mbprs.
-
Free fabrique ses propres olt non ?
-
Free fabrique ses propres olt non ?
Oui.
-
Même algo de congestion? Là où j'ai 3000 RETR en bbr mais 550Mbps, j'en ai 8 en cubic mais 200Mbprs.
oui en bbr depuis un pc Linux.
en cubic:
[ 5] 0.00-20.00 sec 1.18 GBytes 508 Mbits/sec 101 sender
[ 5] 0.00-20.01 sec 1.18 GBytes 507 Mbits/sec receiver
Ca reste un ordre de grandeur raisonnable comparé au 116286...
-
Clair il n'y a pas photo.
Les retry sont impressionnants chez Free...
-
Attention, avoir de trop gros buffers est aussi problématique. On en a palé plusieurs fois, cela bloque les usages simultanés.
Le dimensionnement doit être bien réalisé en prenant une valeur faible, mais pas trop de façon a ne pas exploser les buffers comme c'est le cas chez Free.
Il me semble que les buffers étaient bien optimisés chez Bouygues Telecom.
-
J'ai du mal a être convaincu par cette histoire de buffers.
@Breizh29: si tu test en limitant intentionnellement le débit a 500M par exemple, ca donne quoi ?
iperf3 -c bouygues.testdebit.info -t 20 -i 1 -V --get-server-output -b 500M
puis baisse par paliers de 50M ou 100M pour obtenir un test quasi parfait, genre:
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 35.8 MBytes 300 Mbits/sec 32 375 KBytes
[ 5] 1.00-2.00 sec 35.8 MBytes 300 Mbits/sec 1 375 KBytes
[ 5] 2.00-3.00 sec 35.8 MBytes 300 Mbits/sec 0 375 KBytes
[ 5] 3.00-4.00 sec 35.8 MBytes 300 Mbits/sec 0 375 KBytes
[ 5] 4.00-5.00 sec 35.8 MBytes 300 Mbits/sec 0 375 KBytes
[ 5] 5.00-6.00 sec 35.8 MBytes 300 Mbits/sec 0 375 KBytes
[ 5] 6.00-7.00 sec 35.8 MBytes 300 Mbits/sec 0 375 KBytes
[ 5] 7.00-8.00 sec 35.8 MBytes 300 Mbits/sec 0 375 KBytes
[ 5] 8.00-9.00 sec 35.9 MBytes 301 Mbits/sec 0 375 KBytes
[ 5] 9.00-10.00 sec 35.8 MBytes 300 Mbits/sec 0 375 KBytes
[ 5] 10.00-11.00 sec 35.8 MBytes 300 Mbits/sec 0 375 KBytes
[ 5] 11.00-12.00 sec 35.8 MBytes 300 Mbits/sec 0 375 KBytes
[ 5] 12.00-13.00 sec 35.8 MBytes 300 Mbits/sec 0 375 KBytes
[ 5] 13.00-14.00 sec 35.8 MBytes 300 Mbits/sec 0 375 KBytes
[ 5] 14.00-15.00 sec 35.8 MBytes 300 Mbits/sec 0 375 KBytes
[ 5] 15.00-16.00 sec 35.8 MBytes 300 Mbits/sec 0 375 KBytes
[ 5] 16.00-17.00 sec 35.8 MBytes 300 Mbits/sec 0 375 KBytes
[ 5] 17.00-18.00 sec 35.8 MBytes 300 Mbits/sec 0 375 KBytes
[ 5] 18.00-19.00 sec 35.9 MBytes 301 Mbits/sec 0 375 KBytes
[ 5] 19.00-20.00 sec 35.8 MBytes 300 Mbits/sec 0 375 KBytes
-
Test 2x en bbr, à partir de 200Mbps d'UL:
$ ./src/iperf3 -C bbr -c bouygues.testdebit.info -p 5206 -t 20 -i 1 -V --get-server-output -b 200M
iperf 3.7
Linux server 5.3.0-29-generic #31-Ubuntu SMP Fri Jan 17 17:27:26 UTC 2020 x86_64
Control connection MSS 1428
Time: Wed, 12 Feb 2020 10:31:52 GMT
Connecting to host bouygues.testdebit.info, port 5206
Cookie: obv5gnbu53y4qwgfhktymgteowtikiz22ftk
TCP MSS: 1428 (default)
Target Bitrate: 200000000
[ 5] local 2a01:e0a:369:x port 56630 connected to 2001:860:deff:1000::2 port 5206
Starting Test: protocol: TCP, 1 streams, 131072 byte blocks, omitting 0 seconds, 20 second test, tos 0
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 23.9 MBytes 201 Mbits/sec 3557 1.28 MBytes
[ 5] 1.00-2.00 sec 23.8 MBytes 199 Mbits/sec 3557 1.29 MBytes
[ 5] 2.00-3.00 sec 23.9 MBytes 200 Mbits/sec 3559 699 KBytes
[ 5] 3.00-4.00 sec 23.9 MBytes 200 Mbits/sec 3670 676 KBytes
[ 5] 4.00-5.00 sec 23.8 MBytes 199 Mbits/sec 3665 679 KBytes
[ 5] 5.00-6.00 sec 23.9 MBytes 200 Mbits/sec 3636 671 KBytes
[ 5] 6.00-7.00 sec 23.9 MBytes 200 Mbits/sec 3617 703 KBytes
[ 5] 7.00-8.00 sec 23.9 MBytes 200 Mbits/sec 3675 710 KBytes
[ 5] 8.00-9.00 sec 23.8 MBytes 199 Mbits/sec 3672 708 KBytes
[ 5] 9.00-10.00 sec 23.9 MBytes 200 Mbits/sec 3603 747 KBytes
[ 5] 10.00-11.00 sec 23.9 MBytes 200 Mbits/sec 3676 721 KBytes
[ 5] 11.00-12.00 sec 23.9 MBytes 200 Mbits/sec 3472 675 KBytes
[ 5] 12.00-13.00 sec 23.8 MBytes 199 Mbits/sec 1014 485 KBytes
[ 5] 13.00-14.00 sec 23.9 MBytes 200 Mbits/sec 0 483 KBytes
[ 5] 14.00-15.00 sec 23.9 MBytes 200 Mbits/sec 24 477 KBytes
[ 5] 15.00-16.00 sec 23.9 MBytes 200 Mbits/sec 95 555 KBytes
[ 5] 16.00-17.00 sec 23.8 MBytes 199 Mbits/sec 23 483 KBytes
[ 5] 17.00-18.00 sec 23.9 MBytes 200 Mbits/sec 8 480 KBytes
[ 5] 18.00-19.00 sec 23.9 MBytes 200 Mbits/sec 29 569 KBytes
[ 5] 19.00-20.00 sec 23.8 MBytes 199 Mbits/sec 54 410 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
Test Complete. Summary Results:
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-20.00 sec 477 MBytes 200 Mbits/sec 44606 sender
[ 5] 0.00-20.01 sec 477 MBytes 200 Mbits/sec receiver
CPU Utilization: local/sender 1.7% (0.1%u/1.7%s), remote/receiver 2.8% (0.6%u/2.3%s)
snd_tcp_congestion bbr
rcv_tcp_congestion bbr
Server output:
-----------------------------------------------------------
Server listening on 5206
-----------------------------------------------------------
Accepted connection from 2a01:e0a:369:x, port 56628
[ 5] local 2001:860:deff:1000::2 port 5206 connected to 2a01:e0a:369:x port 56630
[ ID] Interval Transfer Bitrate
[ 5] 0.00-1.00 sec 23.7 MBytes 198 Mbits/sec
[ 5] 1.00-2.00 sec 23.9 MBytes 200 Mbits/sec
[ 5] 2.00-3.00 sec 23.8 MBytes 199 Mbits/sec
[ 5] 3.00-4.00 sec 23.9 MBytes 200 Mbits/sec
[ 5] 4.00-5.00 sec 23.9 MBytes 200 Mbits/sec
[ 5] 5.00-6.00 sec 23.8 MBytes 199 Mbits/sec
[ 5] 6.00-7.00 sec 23.9 MBytes 200 Mbits/sec
[ 5] 7.00-8.00 sec 23.9 MBytes 200 Mbits/sec
[ 5] 8.00-9.00 sec 23.9 MBytes 200 Mbits/sec
[ 5] 9.00-10.00 sec 23.8 MBytes 200 Mbits/sec
[ 5] 10.00-11.00 sec 23.8 MBytes 200 Mbits/sec
[ 5] 11.00-12.00 sec 23.9 MBytes 200 Mbits/sec
[ 5] 12.00-13.00 sec 23.9 MBytes 200 Mbits/sec
[ 5] 13.00-14.00 sec 23.9 MBytes 200 Mbits/sec
[ 5] 14.00-15.00 sec 23.8 MBytes 200 Mbits/sec
[ 5] 15.00-16.00 sec 23.8 MBytes 200 Mbits/sec
[ 5] 16.00-17.00 sec 23.9 MBytes 200 Mbits/sec
[ 5] 17.00-18.00 sec 23.9 MBytes 200 Mbits/sec
[ 5] 18.00-19.00 sec 23.8 MBytes 200 Mbits/sec
[ 5] 19.00-20.00 sec 23.8 MBytes 200 Mbits/sec
[ 5] 20.00-20.01 sec 128 KBytes 186 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate
[ 5] 0.00-20.01 sec 477 MBytes 200 Mbits/sec receiver
iperf Done.
$ ./src/iperf3 -C bbr -c bouygues.testdebit.info -p 5206 -t 20 -i 1 -V --get-server-output -b 200M
iperf 3.7
Linux server 5.3.0-29-generic #31-Ubuntu SMP Fri Jan 17 17:27:26 UTC 2020 x86_64
Control connection MSS 1428
Time: Wed, 12 Feb 2020 10:34:03 GMT
Connecting to host bouygues.testdebit.info, port 5206
Cookie: tncjuoedsh6i2xoqb5gacvawrwhuegf5aoxd
TCP MSS: 1428 (default)
Target Bitrate: 200000000
[ 5] local 2a01:e0a:369:x port 56634 connected to 2001:860:deff:1000::2 port 5206
Starting Test: protocol: TCP, 1 streams, 131072 byte blocks, omitting 0 seconds, 20 second test, tos 0
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 23.8 MBytes 200 Mbits/sec 3170 633 KBytes
[ 5] 1.00-2.00 sec 23.9 MBytes 200 Mbits/sec 239 463 KBytes
[ 5] 2.00-3.00 sec 23.9 MBytes 200 Mbits/sec 0 477 KBytes
[ 5] 3.00-4.00 sec 23.8 MBytes 199 Mbits/sec 19 466 KBytes
[ 5] 4.00-5.00 sec 23.9 MBytes 200 Mbits/sec 134 477 KBytes
[ 5] 5.00-6.00 sec 23.9 MBytes 200 Mbits/sec 38 474 KBytes
[ 5] 6.00-7.00 sec 23.9 MBytes 200 Mbits/sec 0 477 KBytes
[ 5] 7.00-8.00 sec 23.8 MBytes 199 Mbits/sec 6 480 KBytes
[ 5] 8.00-9.00 sec 23.9 MBytes 200 Mbits/sec 5 483 KBytes
[ 5] 9.00-10.00 sec 23.9 MBytes 200 Mbits/sec 4 477 KBytes
[ 5] 10.00-11.00 sec 23.9 MBytes 200 Mbits/sec 31 491 KBytes
[ 5] 11.00-12.00 sec 23.8 MBytes 199 Mbits/sec 1 469 KBytes
[ 5] 12.00-13.00 sec 23.9 MBytes 200 Mbits/sec 12 142 KBytes
[ 5] 13.00-14.00 sec 23.9 MBytes 200 Mbits/sec 39 516 KBytes
[ 5] 14.00-15.00 sec 23.9 MBytes 200 Mbits/sec 39 471 KBytes
[ 5] 15.00-16.00 sec 23.8 MBytes 199 Mbits/sec 68 477 KBytes
[ 5] 16.00-17.00 sec 23.9 MBytes 200 Mbits/sec 0 477 KBytes
[ 5] 17.00-18.00 sec 23.9 MBytes 200 Mbits/sec 135 568 KBytes
[ 5] 18.00-19.00 sec 23.8 MBytes 199 Mbits/sec 74 502 KBytes
[ 5] 19.00-20.00 sec 23.9 MBytes 200 Mbits/sec 14 471 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
Test Complete. Summary Results:
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-20.00 sec 477 MBytes 200 Mbits/sec 4028 sender
[ 5] 0.00-20.01 sec 477 MBytes 200 Mbits/sec receiver
CPU Utilization: local/sender 1.7% (0.3%u/1.4%s), remote/receiver 1.2% (0.2%u/1.0%s)
snd_tcp_congestion bbr
rcv_tcp_congestion bbr
Server output:
-----------------------------------------------------------
Server listening on 5206
-----------------------------------------------------------
Accepted connection from 2a01:e0a:369:x, port 56632
[ 5] local 2001:860:deff:1000::2 port 5206 connected to 2a01:e0a:369:x port 56634
[ ID] Interval Transfer Bitrate
[ 5] 0.00-1.00 sec 23.7 MBytes 199 Mbits/sec
[ 5] 1.00-2.00 sec 23.9 MBytes 200 Mbits/sec
[ 5] 2.00-3.00 sec 23.8 MBytes 200 Mbits/sec
[ 5] 3.00-4.00 sec 23.8 MBytes 200 Mbits/sec
[ 5] 4.00-5.00 sec 23.9 MBytes 200 Mbits/sec
[ 5] 5.00-6.00 sec 23.9 MBytes 200 Mbits/sec
[ 5] 6.00-7.00 sec 23.8 MBytes 200 Mbits/sec
[ 5] 7.00-8.00 sec 23.8 MBytes 200 Mbits/sec
[ 5] 8.00-9.00 sec 23.9 MBytes 200 Mbits/sec
[ 5] 9.00-10.00 sec 23.9 MBytes 200 Mbits/sec
[ 5] 10.00-11.00 sec 23.8 MBytes 199 Mbits/sec
[ 5] 11.00-12.00 sec 23.9 MBytes 200 Mbits/sec
[ 5] 12.00-13.00 sec 23.8 MBytes 200 Mbits/sec
[ 5] 13.00-14.00 sec 23.9 MBytes 200 Mbits/sec
[ 5] 14.00-15.00 sec 23.8 MBytes 200 Mbits/sec
[ 5] 15.00-16.00 sec 23.9 MBytes 200 Mbits/sec
[ 5] 16.00-17.00 sec 23.9 MBytes 200 Mbits/sec
[ 5] 17.00-18.00 sec 23.7 MBytes 199 Mbits/sec
[ 5] 18.00-19.00 sec 23.9 MBytes 201 Mbits/sec
[ 5] 19.00-20.00 sec 23.9 MBytes 200 Mbits/sec
[ 5] 20.00-20.01 sec 128 KBytes 182 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate
[ 5] 0.00-20.01 sec 477 MBytes 200 Mbits/sec receiver
iperf Done.
-
c'est dingue ca.. :o ;D
-
Moi avec 500M c'est pas si crade :
iperf3 -c bouygues.testdebit.info -t 20 -i 1 -V --get-server-output -b 500M
iperf 3.6
Linux Freeze 5.4.18-xanmod10 #1.200206 SMP PREEMPT Thu Feb 6 17:08:08 -03 2020 x86_64
Control connection MSS 1428
Time: Wed, 12 Feb 2020 10:48:37 GMT
Connecting to host bouygues.testdebit.info, port 5201
Cookie: jaxczz6x5k62ajksm2u442z27hnehtx36mvd
TCP MSS: 1428 (default)
[ 5] local 2a01:e0a:1d2:zzzz port 53656 connected to 2001:860:deff:1000::2 port 5201
Starting Test: protocol: TCP, 1 streams, 131072 byte blocks, omitting 0 seconds, 20 second test, tos 0
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 59.6 MBytes 500 Mbits/sec 3417 1.83 MBytes
[ 5] 1.00-2.00 sec 59.6 MBytes 500 Mbits/sec 0 1.84 MBytes
[ 5] 2.00-3.00 sec 59.6 MBytes 500 Mbits/sec 0 1.82 MBytes
[ 5] 3.00-4.00 sec 59.5 MBytes 499 Mbits/sec 0 1.81 MBytes
[ 5] 4.00-5.00 sec 59.6 MBytes 500 Mbits/sec 0 1.82 MBytes
[ 5] 5.00-6.00 sec 59.6 MBytes 500 Mbits/sec 0 1.83 MBytes
[ 5] 6.00-7.00 sec 59.6 MBytes 500 Mbits/sec 0 1.81 MBytes
[ 5] 7.00-8.00 sec 59.6 MBytes 500 Mbits/sec 0 1.80 MBytes
[ 5] 8.00-9.00 sec 59.6 MBytes 501 Mbits/sec 0 1.84 MBytes
[ 5] 9.00-10.00 sec 59.6 MBytes 500 Mbits/sec 0 1.83 MBytes
[ 5] 10.00-11.00 sec 49.0 MBytes 411 Mbits/sec 1785 1.64 MBytes
[ 5] 11.00-12.00 sec 69.6 MBytes 584 Mbits/sec 4912 1.51 MBytes
[ 5] 12.00-13.00 sec 60.1 MBytes 504 Mbits/sec 2315 2.02 MBytes
[ 5] 13.00-14.00 sec 59.6 MBytes 501 Mbits/sec 0 2.02 MBytes
[ 5] 14.00-15.00 sec 59.6 MBytes 500 Mbits/sec 0 2.03 MBytes
[ 5] 15.00-16.00 sec 59.5 MBytes 499 Mbits/sec 37 1.53 MBytes
[ 5] 16.00-17.00 sec 59.6 MBytes 500 Mbits/sec 0 1.64 MBytes
[ 5] 17.00-18.00 sec 59.6 MBytes 500 Mbits/sec 0 1.62 MBytes
[ 5] 18.00-19.00 sec 59.6 MBytes 500 Mbits/sec 2 1.63 MBytes
[ 5] 19.00-20.00 sec 59.6 MBytes 500 Mbits/sec 0 1.60 MBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
Test Complete. Summary Results:
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-20.00 sec 1.16 GBytes 500 Mbits/sec 12468 sender
[ 5] 0.00-20.01 sec 1.16 GBytes 500 Mbits/sec receiver
CPU Utilization: local/sender 55.4% (0.1%u/55.3%s), remote/receiver 9.1% (1.7%u/7.4%s)
snd_tcp_congestion bbr
rcv_tcp_congestion cubic
Server output:
Accepted connection from 2a01:e0a:1d2:zzzz, port 53654
[ 19] local 2001:860:deff:1000::2 port 5201 connected to 2a01:e0a:1d2:zzzz port 53656
[ ID] Interval Transfer Bitrate
[ 19] 0.00-1.00 sec 59.0 MBytes 495 Mbits/sec
[ 19] 1.00-2.00 sec 59.6 MBytes 500 Mbits/sec
[ 19] 2.00-3.00 sec 59.6 MBytes 500 Mbits/sec
[ 19] 3.00-4.00 sec 59.6 MBytes 500 Mbits/sec
[ 19] 4.00-5.00 sec 59.6 MBytes 500 Mbits/sec
[ 19] 5.00-6.00 sec 59.6 MBytes 500 Mbits/sec
[ 19] 6.00-7.00 sec 59.6 MBytes 500 Mbits/sec
[ 19] 7.00-8.00 sec 59.6 MBytes 500 Mbits/sec
[ 19] 8.00-9.00 sec 59.6 MBytes 500 Mbits/sec
[ 19] 9.00-10.00 sec 59.6 MBytes 500 Mbits/sec
[ 19] 10.00-11.00 sec 47.1 MBytes 395 Mbits/sec
[ 19] 11.00-12.00 sec 69.5 MBytes 583 Mbits/sec
[ 19] 12.00-13.00 sec 62.2 MBytes 522 Mbits/sec
[ 19] 13.00-14.00 sec 59.6 MBytes 500 Mbits/sec
[ 19] 14.00-15.00 sec 59.5 MBytes 500 Mbits/sec
[ 19] 15.00-16.00 sec 59.7 MBytes 501 Mbits/sec
[ 19] 16.00-17.00 sec 59.6 MBytes 500 Mbits/sec
[ 19] 17.00-18.00 sec 59.6 MBytes 500 Mbits/sec
[ 19] 18.00-19.00 sec 59.7 MBytes 501 Mbits/sec
[ 19] 19.00-20.00 sec 59.6 MBytes 500 Mbits/sec
[ 19] 20.00-20.01 sec 607 KBytes 487 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate
[ 19] 0.00-20.01 sec 1.16 GBytes 500 Mbits/sec receiver
iperf Done.
-
500M BBR :
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 51.7 MBytes 434 Mbits/sec 4295 1.80 MBytes
[ 5] 1.00-2.00 sec 58.1 MBytes 488 Mbits/sec 3378 1.76 MBytes
[ 5] 2.00-3.00 sec 55.5 MBytes 466 Mbits/sec 4374 1.64 MBytes
[ 5] 3.00-4.00 sec 56.4 MBytes 473 Mbits/sec 3937 1.80 MBytes
[ 5] 4.00-5.00 sec 54.6 MBytes 458 Mbits/sec 3580 1.81 MBytes
[ 5] 5.00-6.00 sec 55.9 MBytes 469 Mbits/sec 3199 1.74 MBytes
[ 5] 6.00-7.00 sec 56.1 MBytes 471 Mbits/sec 3228 1.61 MBytes
[ 5] 7.00-8.00 sec 58.1 MBytes 488 Mbits/sec 3160 1.71 MBytes
[ 5] 8.00-9.00 sec 58.9 MBytes 494 Mbits/sec 3091 1.69 MBytes
[ 5] 9.00-10.00 sec 56.2 MBytes 472 Mbits/sec 2933 1.73 MBytes
[ 5] 10.00-11.00 sec 54.5 MBytes 457 Mbits/sec 4013 1.83 MBytes
[ 5] 11.00-12.00 sec 58.0 MBytes 487 Mbits/sec 3199 1.73 MBytes
[ 5] 12.00-13.00 sec 56.4 MBytes 473 Mbits/sec 3882 1.95 MBytes
[ 5] 13.00-14.00 sec 55.4 MBytes 465 Mbits/sec 4268 2.00 MBytes
[ 5] 14.00-15.00 sec 52.9 MBytes 444 Mbits/sec 4337 1.93 MBytes
[ 5] 15.00-16.00 sec 54.2 MBytes 455 Mbits/sec 5124 1.77 MBytes
[ 5] 16.00-17.00 sec 57.5 MBytes 482 Mbits/sec 3161 1.74 MBytes
[ 5] 17.00-18.00 sec 56.8 MBytes 476 Mbits/sec 3053 1.04 MBytes
[ 5] 18.00-19.00 sec 54.6 MBytes 458 Mbits/sec 3273 1.69 MBytes
[ 5] 19.00-20.00 sec 57.6 MBytes 483 Mbits/sec 3340 1.76 MBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
Test Complete. Summary Results:
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-20.00 sec 1.09 GBytes 470 Mbits/sec 72825 sender
[ 5] 0.00-20.04 sec 1.09 GBytes 468 Mbits/sec receiver
CPU Utilization: local/sender 5.8% (0.3%u/5.5%s), remote/receiver 0.7% (0.1%u/0.6%s)
snd_tcp_congestion bbr
rcv_tcp_congestion cubic
450M BBR :
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 53.7 MBytes 451 Mbits/sec 4350 1.86 MBytes
[ 5] 1.00-2.00 sec 53.6 MBytes 450 Mbits/sec 2620 1.77 MBytes
[ 5] 2.00-3.00 sec 53.6 MBytes 450 Mbits/sec 2486 1.73 MBytes
[ 5] 3.00-4.00 sec 53.6 MBytes 450 Mbits/sec 1300 1.52 MBytes
[ 5] 4.00-5.00 sec 53.6 MBytes 450 Mbits/sec 881 1.53 MBytes
[ 5] 5.00-6.00 sec 53.6 MBytes 450 Mbits/sec 948 1.55 MBytes
[ 5] 6.00-7.00 sec 53.6 MBytes 450 Mbits/sec 750 889 KBytes
[ 5] 7.00-8.00 sec 53.8 MBytes 451 Mbits/sec 1108 775 KBytes
[ 5] 8.00-9.00 sec 53.6 MBytes 450 Mbits/sec 737 1.56 MBytes
[ 5] 9.00-10.00 sec 53.6 MBytes 450 Mbits/sec 782 1.55 MBytes
[ 5] 10.00-11.00 sec 45.2 MBytes 380 Mbits/sec 1680 1.78 MBytes
[ 5] 11.00-12.00 sec 57.1 MBytes 479 Mbits/sec 3892 1.86 MBytes
[ 5] 12.00-13.00 sec 53.8 MBytes 451 Mbits/sec 3615 1.18 MBytes
[ 5] 13.00-14.00 sec 56.9 MBytes 477 Mbits/sec 3622 1.05 MBytes
[ 5] 14.00-15.00 sec 51.5 MBytes 432 Mbits/sec 4161 881 KBytes
[ 5] 15.00-16.00 sec 54.4 MBytes 456 Mbits/sec 4355 1.85 MBytes
[ 5] 16.00-17.00 sec 56.6 MBytes 475 Mbits/sec 3723 1.88 MBytes
[ 5] 17.00-18.00 sec 53.6 MBytes 450 Mbits/sec 3743 1.70 MBytes
[ 5] 18.00-19.00 sec 53.5 MBytes 449 Mbits/sec 1964 1.51 MBytes
[ 5] 19.00-20.00 sec 53.8 MBytes 451 Mbits/sec 2235 1.61 MBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
Test Complete. Summary Results:
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-20.00 sec 1.05 GBytes 450 Mbits/sec 48952 sender
[ 5] 0.00-20.04 sec 1.05 GBytes 448 Mbits/sec receiver
CPU Utilization: local/sender 6.9% (0.5%u/6.4%s), remote/receiver 2.1% (0.2%u/1.9%s)
snd_tcp_congestion bbr
rcv_tcp_congestion cubic
400M BBR :
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 47.7 MBytes 400 Mbits/sec 4887 1.88 MBytes
[ 5] 1.00-2.00 sec 47.6 MBytes 400 Mbits/sec 1587 1.47 MBytes
[ 5] 2.00-3.00 sec 47.8 MBytes 401 Mbits/sec 380 1.36 MBytes
[ 5] 3.00-4.00 sec 47.6 MBytes 400 Mbits/sec 166 1.39 MBytes
[ 5] 4.00-5.00 sec 47.8 MBytes 401 Mbits/sec 197 816 KBytes
[ 5] 5.00-6.00 sec 47.6 MBytes 400 Mbits/sec 190 1.41 MBytes
[ 5] 6.00-7.00 sec 47.8 MBytes 401 Mbits/sec 198 1.42 MBytes
[ 5] 7.00-8.00 sec 47.6 MBytes 400 Mbits/sec 230 1.26 MBytes
[ 5] 8.00-9.00 sec 47.8 MBytes 401 Mbits/sec 181 704 KBytes
[ 5] 9.00-10.00 sec 47.6 MBytes 399 Mbits/sec 412 1.41 MBytes
[ 5] 10.00-11.00 sec 44.0 MBytes 369 Mbits/sec 1786 1.75 MBytes
[ 5] 11.00-12.00 sec 51.4 MBytes 431 Mbits/sec 3318 1.84 MBytes
[ 5] 12.00-13.00 sec 47.8 MBytes 401 Mbits/sec 1799 1.70 MBytes
[ 5] 13.00-14.00 sec 47.6 MBytes 400 Mbits/sec 522 1.36 MBytes
[ 5] 14.00-15.00 sec 47.8 MBytes 401 Mbits/sec 265 641 KBytes
[ 5] 15.00-16.00 sec 47.6 MBytes 400 Mbits/sec 210 652 KBytes
[ 5] 16.00-17.00 sec 47.6 MBytes 400 Mbits/sec 220 1.41 MBytes
[ 5] 17.00-18.00 sec 47.8 MBytes 401 Mbits/sec 264 690 KBytes
[ 5] 18.00-19.00 sec 47.6 MBytes 400 Mbits/sec 216 686 KBytes
[ 5] 19.00-20.00 sec 47.8 MBytes 401 Mbits/sec 203 653 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
Test Complete. Summary Results:
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-20.00 sec 954 MBytes 400 Mbits/sec 17231 sender
[ 5] 0.00-20.04 sec 954 MBytes 399 Mbits/sec receiver
CPU Utilization: local/sender 8.0% (1.7%u/6.3%s), remote/receiver 0.2% (0.0%u/0.2%s)
snd_tcp_congestion bbr
rcv_tcp_congestion cubic
300M BBR :
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 35.8 MBytes 301 Mbits/sec 3614 1.99 MBytes
[ 5] 1.00-2.00 sec 35.8 MBytes 300 Mbits/sec 686 1.06 MBytes
[ 5] 2.00-3.00 sec 35.8 MBytes 300 Mbits/sec 12 1.09 MBytes
[ 5] 3.00-4.00 sec 35.8 MBytes 300 Mbits/sec 103 1.09 MBytes
[ 5] 4.00-5.00 sec 35.8 MBytes 300 Mbits/sec 29 1.09 MBytes
[ 5] 5.00-6.00 sec 35.8 MBytes 300 Mbits/sec 19 1.10 MBytes
[ 5] 6.00-7.00 sec 35.8 MBytes 300 Mbits/sec 88 1.07 MBytes
[ 5] 7.00-8.00 sec 35.8 MBytes 300 Mbits/sec 149 1.10 MBytes
[ 5] 8.00-9.00 sec 35.8 MBytes 300 Mbits/sec 31 1.03 MBytes
[ 5] 9.00-10.00 sec 35.9 MBytes 301 Mbits/sec 13 513 KBytes
[ 5] 10.00-11.00 sec 35.8 MBytes 300 Mbits/sec 1434 1.87 MBytes
[ 5] 11.00-12.00 sec 35.8 MBytes 300 Mbits/sec 1565 1.87 MBytes
[ 5] 12.00-13.00 sec 35.8 MBytes 300 Mbits/sec 437 1.09 MBytes
[ 5] 13.00-14.00 sec 35.8 MBytes 300 Mbits/sec 28 1.09 MBytes
[ 5] 14.00-15.00 sec 35.8 MBytes 300 Mbits/sec 38 1.12 MBytes
[ 5] 15.00-16.00 sec 35.8 MBytes 300 Mbits/sec 26 1.11 MBytes
[ 5] 16.00-17.00 sec 35.8 MBytes 300 Mbits/sec 57 1.08 MBytes
[ 5] 17.00-18.00 sec 35.8 MBytes 300 Mbits/sec 37 1.12 MBytes
[ 5] 18.00-19.00 sec 35.8 MBytes 300 Mbits/sec 38 1.11 MBytes
[ 5] 19.00-20.00 sec 35.9 MBytes 301 Mbits/sec 11 1.12 MBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
Test Complete. Summary Results:
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-20.00 sec 715 MBytes 300 Mbits/sec 8415 sender
[ 5] 0.00-20.04 sec 715 MBytes 299 Mbits/sec receiver
CPU Utilization: local/sender 7.5% (1.9%u/5.6%s), remote/receiver 3.1% (0.6%u/2.5%s)
snd_tcp_congestion bbr
rcv_tcp_congestion cubic
200M BBR :
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 23.8 MBytes 200 Mbits/sec 3351 2.75 MBytes
[ 5] 1.00-2.00 sec 23.9 MBytes 200 Mbits/sec 3615 2.76 MBytes
[ 5] 2.00-3.00 sec 23.9 MBytes 200 Mbits/sec 3771 2.80 MBytes
[ 5] 3.00-4.00 sec 23.9 MBytes 200 Mbits/sec 3883 2.76 MBytes
[ 5] 4.00-5.00 sec 23.8 MBytes 199 Mbits/sec 3557 2.74 MBytes
[ 5] 5.00-6.00 sec 23.9 MBytes 200 Mbits/sec 3646 2.75 MBytes
[ 5] 6.00-7.00 sec 23.9 MBytes 200 Mbits/sec 3760 2.73 MBytes
[ 5] 7.00-8.00 sec 23.9 MBytes 200 Mbits/sec 3695 2.57 MBytes
[ 5] 8.00-9.00 sec 23.8 MBytes 199 Mbits/sec 3924 2.58 MBytes
[ 5] 9.00-10.00 sec 23.9 MBytes 200 Mbits/sec 3729 2.63 MBytes
[ 5] 10.00-11.00 sec 23.9 MBytes 200 Mbits/sec 3547 2.59 MBytes
[ 5] 11.00-12.00 sec 23.8 MBytes 199 Mbits/sec 3901 2.58 MBytes
[ 5] 12.00-13.00 sec 23.9 MBytes 200 Mbits/sec 3751 2.62 MBytes
[ 5] 13.00-14.00 sec 23.9 MBytes 200 Mbits/sec 3741 2.59 MBytes
[ 5] 14.00-15.00 sec 23.9 MBytes 200 Mbits/sec 3825 2.59 MBytes
[ 5] 15.00-16.00 sec 23.8 MBytes 199 Mbits/sec 3771 2.59 MBytes
[ 5] 16.00-17.00 sec 23.9 MBytes 200 Mbits/sec 3700 2.58 MBytes
[ 5] 17.00-18.00 sec 23.9 MBytes 200 Mbits/sec 3529 2.57 MBytes
[ 5] 18.00-19.00 sec 23.9 MBytes 200 Mbits/sec 3582 2.60 MBytes
[ 5] 19.00-20.00 sec 23.8 MBytes 199 Mbits/sec 3854 2.57 MBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
Test Complete. Summary Results:
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-20.00 sec 477 MBytes 200 Mbits/sec 74132 sender
[ 5] 0.00-20.04 sec 476 MBytes 199 Mbits/sec receiver
CPU Utilization: local/sender 6.1% (0.0%u/6.1%s), remote/receiver 1.1% (0.1%u/1.0%s)
snd_tcp_congestion bbr
rcv_tcp_congestion cubic
-
500M Cubic :
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 20.6 MBytes 173 Mbits/sec 10 317 KBytes
[ 5] 1.00-2.00 sec 24.5 MBytes 206 Mbits/sec 0 356 KBytes
[ 5] 2.00-3.00 sec 27.6 MBytes 232 Mbits/sec 0 403 KBytes
[ 5] 3.00-4.00 sec 30.8 MBytes 258 Mbits/sec 0 448 KBytes
[ 5] 4.00-5.00 sec 33.9 MBytes 284 Mbits/sec 0 492 KBytes
[ 5] 5.00-6.00 sec 32.2 MBytes 271 Mbits/sec 1 389 KBytes
[ 5] 6.00-7.00 sec 30.2 MBytes 254 Mbits/sec 0 443 KBytes
[ 5] 7.00-8.00 sec 33.4 MBytes 280 Mbits/sec 0 478 KBytes
[ 5] 8.00-9.00 sec 35.6 MBytes 299 Mbits/sec 0 516 KBytes
[ 5] 9.00-10.00 sec 35.6 MBytes 299 Mbits/sec 4 402 KBytes
[ 5] 10.00-11.00 sec 31.4 MBytes 263 Mbits/sec 0 461 KBytes
[ 5] 11.00-12.00 sec 27.1 MBytes 228 Mbits/sec 5 361 KBytes
[ 5] 12.00-13.00 sec 27.9 MBytes 234 Mbits/sec 0 407 KBytes
[ 5] 13.00-14.00 sec 31.0 MBytes 260 Mbits/sec 0 454 KBytes
[ 5] 14.00-15.00 sec 34.0 MBytes 285 Mbits/sec 0 495 KBytes
[ 5] 15.00-16.00 sec 37.5 MBytes 315 Mbits/sec 0 542 KBytes
[ 5] 16.00-17.00 sec 40.5 MBytes 340 Mbits/sec 0 583 KBytes
[ 5] 17.00-18.00 sec 33.1 MBytes 278 Mbits/sec 1 472 KBytes
[ 5] 18.00-19.00 sec 36.0 MBytes 302 Mbits/sec 0 522 KBytes
[ 5] 19.00-20.00 sec 35.6 MBytes 299 Mbits/sec 19 395 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
Test Complete. Summary Results:
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-20.00 sec 639 MBytes 268 Mbits/sec 40 sender
[ 5] 0.00-20.04 sec 636 MBytes 266 Mbits/sec receiver
CPU Utilization: local/sender 5.5% (0.5%u/5.0%s), remote/receiver 5.6% (1.3%u/4.3%s)
snd_tcp_congestion cubic
rcv_tcp_congestion cubic
450M Cubic :
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 20.8 MBytes 175 Mbits/sec 0 631 KBytes
[ 5] 1.00-2.00 sec 35.1 MBytes 295 Mbits/sec 6 363 KBytes
[ 5] 2.00-3.00 sec 27.9 MBytes 234 Mbits/sec 0 409 KBytes
[ 5] 3.00-4.00 sec 31.5 MBytes 264 Mbits/sec 0 458 KBytes
[ 5] 4.00-5.00 sec 28.4 MBytes 238 Mbits/sec 3 372 KBytes
[ 5] 5.00-6.00 sec 28.6 MBytes 240 Mbits/sec 0 417 KBytes
[ 5] 6.00-7.00 sec 31.8 MBytes 266 Mbits/sec 0 457 KBytes
[ 5] 7.00-8.00 sec 24.6 MBytes 207 Mbits/sec 4 356 KBytes
[ 5] 8.00-9.00 sec 27.6 MBytes 232 Mbits/sec 0 402 KBytes
[ 5] 9.00-10.00 sec 30.5 MBytes 256 Mbits/sec 0 445 KBytes
[ 5] 10.00-11.00 sec 33.6 MBytes 282 Mbits/sec 0 491 KBytes
[ 5] 11.00-12.00 sec 29.9 MBytes 251 Mbits/sec 1 397 KBytes
[ 5] 12.00-13.00 sec 30.6 MBytes 257 Mbits/sec 0 444 KBytes
[ 5] 13.00-14.00 sec 33.5 MBytes 281 Mbits/sec 0 477 KBytes
[ 5] 14.00-15.00 sec 28.8 MBytes 241 Mbits/sec 3 372 KBytes
[ 5] 15.00-16.00 sec 28.6 MBytes 240 Mbits/sec 0 419 KBytes
[ 5] 16.00-17.00 sec 32.1 MBytes 269 Mbits/sec 0 467 KBytes
[ 5] 17.00-18.00 sec 34.9 MBytes 293 Mbits/sec 0 508 KBytes
[ 5] 18.00-19.00 sec 38.2 MBytes 321 Mbits/sec 0 553 KBytes
[ 5] 19.00-20.00 sec 37.1 MBytes 311 Mbits/sec 1 430 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
Test Complete. Summary Results:
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-20.00 sec 614 MBytes 258 Mbits/sec 18 sender
[ 5] 0.00-20.04 sec 612 MBytes 256 Mbits/sec receiver
CPU Utilization: local/sender 5.1% (0.6%u/4.5%s), remote/receiver 6.3% (1.4%u/4.9%s)
snd_tcp_congestion cubic
rcv_tcp_congestion cubic
400M Cubic :
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 27.1 MBytes 227 Mbits/sec 1 464 KBytes
[ 5] 1.00-2.00 sec 35.8 MBytes 300 Mbits/sec 0 529 KBytes
[ 5] 2.00-3.00 sec 38.2 MBytes 321 Mbits/sec 2 404 KBytes
[ 5] 3.00-4.00 sec 30.9 MBytes 259 Mbits/sec 0 448 KBytes
[ 5] 4.00-5.00 sec 33.9 MBytes 284 Mbits/sec 0 492 KBytes
[ 5] 5.00-6.00 sec 37.4 MBytes 314 Mbits/sec 0 536 KBytes
[ 5] 6.00-7.00 sec 37.2 MBytes 312 Mbits/sec 2 413 KBytes
[ 5] 7.00-8.00 sec 29.2 MBytes 245 Mbits/sec 20 332 KBytes
[ 5] 8.00-9.00 sec 25.8 MBytes 216 Mbits/sec 0 378 KBytes
[ 5] 9.00-10.00 sec 29.0 MBytes 243 Mbits/sec 0 424 KBytes
[ 5] 10.00-11.00 sec 32.6 MBytes 274 Mbits/sec 0 469 KBytes
[ 5] 11.00-12.00 sec 27.6 MBytes 232 Mbits/sec 2 380 KBytes
[ 5] 12.00-13.00 sec 29.2 MBytes 245 Mbits/sec 0 426 KBytes
[ 5] 13.00-14.00 sec 32.1 MBytes 269 Mbits/sec 0 464 KBytes
[ 5] 14.00-15.00 sec 34.9 MBytes 293 Mbits/sec 0 506 KBytes
[ 5] 15.00-16.00 sec 38.0 MBytes 319 Mbits/sec 0 550 KBytes
[ 5] 16.00-17.00 sec 32.1 MBytes 269 Mbits/sec 1 441 KBytes
[ 5] 17.00-18.00 sec 26.6 MBytes 223 Mbits/sec 4 349 KBytes
[ 5] 18.00-19.00 sec 27.2 MBytes 229 Mbits/sec 0 395 KBytes
[ 5] 19.00-20.00 sec 30.4 MBytes 255 Mbits/sec 0 443 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
Test Complete. Summary Results:
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-20.00 sec 635 MBytes 266 Mbits/sec 32 sender
[ 5] 0.00-20.04 sec 633 MBytes 265 Mbits/sec receiver
CPU Utilization: local/sender 5.3% (0.2%u/5.1%s), remote/receiver 0.3% (0.1%u/0.3%s)
snd_tcp_congestion cubic
rcv_tcp_congestion cubic
300M Cubic :
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 21.3 MBytes 179 Mbits/sec 0 614 KBytes
[ 5] 1.00-2.00 sec 37.2 MBytes 312 Mbits/sec 11 536 KBytes
[ 5] 2.00-3.00 sec 34.5 MBytes 289 Mbits/sec 2 417 KBytes
[ 5] 3.00-4.00 sec 31.6 MBytes 265 Mbits/sec 0 461 KBytes
[ 5] 4.00-5.00 sec 30.9 MBytes 259 Mbits/sec 1 363 KBytes
[ 5] 5.00-6.00 sec 28.5 MBytes 239 Mbits/sec 0 417 KBytes
[ 5] 6.00-7.00 sec 31.5 MBytes 264 Mbits/sec 0 452 KBytes
[ 5] 7.00-8.00 sec 33.9 MBytes 284 Mbits/sec 0 491 KBytes
[ 5] 8.00-9.00 sec 32.9 MBytes 276 Mbits/sec 8 389 KBytes
[ 5] 9.00-10.00 sec 30.2 MBytes 254 Mbits/sec 0 444 KBytes
[ 5] 10.00-11.00 sec 33.5 MBytes 281 Mbits/sec 0 479 KBytes
[ 5] 11.00-12.00 sec 36.0 MBytes 302 Mbits/sec 0 519 KBytes
[ 5] 12.00-13.00 sec 22.1 MBytes 186 Mbits/sec 5 294 KBytes
[ 5] 13.00-14.00 sec 23.0 MBytes 193 Mbits/sec 0 341 KBytes
[ 5] 14.00-15.00 sec 19.8 MBytes 166 Mbits/sec 7 281 KBytes
[ 5] 15.00-16.00 sec 22.4 MBytes 188 Mbits/sec 0 327 KBytes
[ 5] 16.00-17.00 sec 25.2 MBytes 212 Mbits/sec 0 370 KBytes
[ 5] 17.00-18.00 sec 28.5 MBytes 239 Mbits/sec 0 416 KBytes
[ 5] 18.00-19.00 sec 31.9 MBytes 267 Mbits/sec 0 462 KBytes
[ 5] 19.00-20.00 sec 31.5 MBytes 264 Mbits/sec 5 368 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
Test Complete. Summary Results:
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-20.00 sec 586 MBytes 246 Mbits/sec 39 sender
[ 5] 0.00-20.04 sec 584 MBytes 245 Mbits/sec receiver
CPU Utilization: local/sender 5.1% (0.5%u/4.6%s), remote/receiver 6.3% (1.1%u/5.2%s)
snd_tcp_congestion cubic
rcv_tcp_congestion cubic
200M Cubic :
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 21.8 MBytes 183 Mbits/sec 0 645 KBytes
[ 5] 1.00-2.00 sec 24.9 MBytes 209 Mbits/sec 20 263 KBytes
[ 5] 2.00-3.00 sec 20.8 MBytes 174 Mbits/sec 0 310 KBytes
[ 5] 3.00-4.00 sec 24.1 MBytes 202 Mbits/sec 0 354 KBytes
[ 5] 4.00-5.00 sec 27.6 MBytes 232 Mbits/sec 0 400 KBytes
[ 5] 5.00-6.00 sec 23.9 MBytes 200 Mbits/sec 0 420 KBytes
[ 5] 6.00-7.00 sec 23.9 MBytes 200 Mbits/sec 23 337 KBytes
[ 5] 7.00-8.00 sec 23.9 MBytes 200 Mbits/sec 0 373 KBytes
[ 5] 8.00-9.00 sec 23.8 MBytes 199 Mbits/sec 0 386 KBytes
[ 5] 9.00-10.00 sec 23.9 MBytes 200 Mbits/sec 0 404 KBytes
[ 5] 10.00-11.00 sec 23.9 MBytes 200 Mbits/sec 0 404 KBytes
[ 5] 11.00-12.00 sec 23.8 MBytes 199 Mbits/sec 0 404 KBytes
[ 5] 12.00-13.00 sec 23.9 MBytes 200 Mbits/sec 0 404 KBytes
[ 5] 13.00-14.00 sec 23.9 MBytes 200 Mbits/sec 0 404 KBytes
[ 5] 14.00-15.00 sec 23.9 MBytes 200 Mbits/sec 0 404 KBytes
[ 5] 15.00-16.00 sec 23.8 MBytes 199 Mbits/sec 0 443 KBytes
[ 5] 16.00-17.00 sec 23.9 MBytes 200 Mbits/sec 0 443 KBytes
[ 5] 17.00-18.00 sec 23.9 MBytes 200 Mbits/sec 4 345 KBytes
[ 5] 18.00-19.00 sec 23.9 MBytes 200 Mbits/sec 0 378 KBytes
[ 5] 19.00-20.00 sec 23.8 MBytes 199 Mbits/sec 0 387 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
Test Complete. Summary Results:
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-20.00 sec 477 MBytes 200 Mbits/sec 47 sender
[ 5] 0.00-20.04 sec 477 MBytes 200 Mbits/sec receiver
CPU Utilization: local/sender 5.6% (0.8%u/4.8%s), remote/receiver 5.8% (1.1%u/4.6%s)
snd_tcp_congestion cubic
rcv_tcp_congestion cubic
-
BBR permet un meilleur débit, mais au prix de nombreuses retransmissions de paquets.
Tes tests sont en BBR uniquement dans le sens montant :
snd_tcp_congestion bbr
rcv_tcp_congestion cubicIl est possible de forcer BBR sur le serveur en rajoutant l'option dans iPerf3
-
Tu veux dire le faire de ton côté ? Car depuis le client ce serait étonnant.
J'ai déjà utilisé le "-C bbr / -C cubic" dans mes tests et pour moi c'est la seule option possible.
-
L'argument --congestion=bbr permet de forcer le protocole, si il est dans la liste des protocoles supportés, ce qui est le cas sur les serveurs que je gére.
iperf3 -c bouygues.testdebit.info -p 9200 -R -V --congestion=bbr
Permet de faire un test descendant avec BBR coté serveur (et coté client mais le coté n'est pas important en descendant)
Il y a un bug qui va être résolut dans quelques jours :
Bug coté serveur : après avoir forcé algorithme d'évitement de congestion TCP particulier, celui-ci reste actif sur le port donné.
Pour revenir en fonctionnement nominal, il faut forcer l'algorithme proposé par défaut.
Voici les lignes de commandes passées dans l'ordre et leur effet :
iperf3 -t 3 -c paris.testdebit.info -p 9222 -R -V
snd_tcp_congestion cubic
rcv_tcp_congestion cubic
iperf3 -t 3 -c paris.testdebit.info -p 9222 -R -V --congestion=bbr
snd_tcp_congestion bbr
rcv_tcp_congestion bbr
iperf3 -t 3 -c paris.testdebit.info -p 9222 -R -V
snd_tcp_congestion bbr
rcv_tcp_congestion cubic
iperf3 -t 3 -c paris.testdebit.info -p 9222 -R -V --congestion=cubic
snd_tcp_congestion cubic
rcv_tcp_congestion cubic
-
Du coup t'as fait la modification côté serveur ? J'ai refait le test sans rien toucher et j'ai bien "bbr" dans les 2 sens.
C'est assez rigolo en reverse "-R" j'obtiens en Cubic les mêmes débits dégueulasses qu'avec du Cubic en upload (quand t'es pas en BBR côté serveur) :o
200M BBR :
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 23.8 MBytes 200 Mbits/sec 3551 2.53 MBytes
[ 5] 1.00-2.00 sec 23.9 MBytes 200 Mbits/sec 3815 1.25 MBytes
[ 5] 2.00-3.00 sec 23.9 MBytes 200 Mbits/sec 3920 1.19 MBytes
[ 5] 3.00-4.00 sec 23.9 MBytes 200 Mbits/sec 3771 1.20 MBytes
[ 5] 4.00-5.00 sec 23.8 MBytes 199 Mbits/sec 4184 1.22 MBytes
[ 5] 5.00-6.00 sec 23.9 MBytes 200 Mbits/sec 3952 1.17 MBytes
[ 5] 6.00-7.00 sec 23.9 MBytes 200 Mbits/sec 4094 1.43 MBytes
[ 5] 7.00-8.00 sec 23.8 MBytes 199 Mbits/sec 3967 1.41 MBytes
[ 5] 8.00-9.00 sec 23.9 MBytes 200 Mbits/sec 3957 1.21 MBytes
[ 5] 9.00-10.00 sec 23.9 MBytes 200 Mbits/sec 4045 1.20 MBytes
[ 5] 10.00-11.00 sec 23.9 MBytes 200 Mbits/sec 2203 823 KBytes
[ 5] 11.00-12.00 sec 23.8 MBytes 199 Mbits/sec 15 766 KBytes
[ 5] 12.00-13.00 sec 23.9 MBytes 200 Mbits/sec 21 769 KBytes
[ 5] 13.00-14.00 sec 23.9 MBytes 200 Mbits/sec 0 778 KBytes
[ 5] 14.00-15.00 sec 23.9 MBytes 200 Mbits/sec 0 778 KBytes
[ 5] 15.00-16.00 sec 23.8 MBytes 199 Mbits/sec 0 778 KBytes
[ 5] 16.00-17.00 sec 23.9 MBytes 200 Mbits/sec 22 778 KBytes
[ 5] 17.00-18.00 sec 23.9 MBytes 200 Mbits/sec 0 778 KBytes
[ 5] 18.00-19.00 sec 23.9 MBytes 200 Mbits/sec 0 778 KBytes
[ 5] 19.00-20.00 sec 23.8 MBytes 199 Mbits/sec 283 385 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
Test Complete. Summary Results:
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-20.00 sec 477 MBytes 200 Mbits/sec 41800 sender
[ 5] 0.00-20.04 sec 477 MBytes 200 Mbits/sec receiver
CPU Utilization: local/sender 6.2% (1.1%u/5.1%s), remote/receiver 2.4% (0.4%u/1.9%s)
snd_tcp_congestion bbr
rcv_tcp_congestion bbr
300M BBR :
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 35.8 MBytes 301 Mbits/sec 4214 2.01 MBytes
[ 5] 1.00-2.00 sec 35.8 MBytes 300 Mbits/sec 4133 2.01 MBytes
[ 5] 2.00-3.00 sec 35.8 MBytes 300 Mbits/sec 4209 2.01 MBytes
[ 5] 3.00-4.00 sec 35.8 MBytes 300 Mbits/sec 4261 2.01 MBytes
[ 5] 4.00-5.00 sec 35.8 MBytes 300 Mbits/sec 4054 2.01 MBytes
[ 5] 5.00-6.00 sec 35.8 MBytes 300 Mbits/sec 4244 2.01 MBytes
[ 5] 6.00-7.00 sec 35.8 MBytes 300 Mbits/sec 4182 2.01 MBytes
[ 5] 7.00-8.00 sec 35.8 MBytes 300 Mbits/sec 4048 2.01 MBytes
[ 5] 8.00-9.00 sec 35.8 MBytes 300 Mbits/sec 4157 2.01 MBytes
[ 5] 9.00-10.00 sec 35.9 MBytes 301 Mbits/sec 4098 2.01 MBytes
[ 5] 10.00-11.00 sec 35.8 MBytes 300 Mbits/sec 4216 1.99 MBytes
[ 5] 11.00-12.00 sec 35.8 MBytes 300 Mbits/sec 3969 2.01 MBytes
[ 5] 12.00-13.00 sec 35.8 MBytes 300 Mbits/sec 3450 2.01 MBytes
[ 5] 13.00-14.00 sec 35.8 MBytes 300 Mbits/sec 3228 2.01 MBytes
[ 5] 14.00-15.00 sec 35.8 MBytes 300 Mbits/sec 3397 2.00 MBytes
[ 5] 15.00-16.00 sec 35.8 MBytes 300 Mbits/sec 3220 1.99 MBytes
[ 5] 16.00-17.00 sec 35.8 MBytes 300 Mbits/sec 3477 2.01 MBytes
[ 5] 17.00-18.00 sec 35.8 MBytes 300 Mbits/sec 3300 2.01 MBytes
[ 5] 18.00-19.00 sec 35.8 MBytes 300 Mbits/sec 3567 2.01 MBytes
[ 5] 19.00-20.00 sec 35.9 MBytes 301 Mbits/sec 3242 2.01 MBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
Test Complete. Summary Results:
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-20.00 sec 715 MBytes 300 Mbits/sec 76666 sender
[ 5] 0.00-20.04 sec 715 MBytes 299 Mbits/sec receiver
CPU Utilization: local/sender 7.6% (2.5%u/5.1%s), remote/receiver 1.7% (0.2%u/1.5%s)
snd_tcp_congestion bbr
rcv_tcp_congestion bbr
400M BBR :
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 47.7 MBytes 400 Mbits/sec 6142 1.97 MBytes
[ 5] 1.00-2.00 sec 47.6 MBytes 400 Mbits/sec 2424 1008 KBytes
[ 5] 2.00-3.00 sec 47.8 MBytes 401 Mbits/sec 247 660 KBytes
[ 5] 3.00-4.00 sec 47.6 MBytes 400 Mbits/sec 264 1.43 MBytes
[ 5] 4.00-5.00 sec 47.8 MBytes 401 Mbits/sec 196 1.41 MBytes
[ 5] 5.00-6.00 sec 47.6 MBytes 399 Mbits/sec 620 1.71 MBytes
[ 5] 6.00-7.00 sec 47.8 MBytes 401 Mbits/sec 533 1.40 MBytes
[ 5] 7.00-8.00 sec 47.6 MBytes 400 Mbits/sec 322 645 KBytes
[ 5] 8.00-9.00 sec 47.8 MBytes 401 Mbits/sec 276 663 KBytes
[ 5] 9.00-10.00 sec 47.6 MBytes 400 Mbits/sec 283 1.45 MBytes
[ 5] 10.00-11.00 sec 44.9 MBytes 376 Mbits/sec 2063 1.94 MBytes
[ 5] 11.00-12.00 sec 50.5 MBytes 424 Mbits/sec 3287 1.76 MBytes
[ 5] 12.00-13.00 sec 47.8 MBytes 401 Mbits/sec 1409 641 KBytes
[ 5] 13.00-14.00 sec 47.6 MBytes 400 Mbits/sec 224 1.45 MBytes
[ 5] 14.00-15.00 sec 47.8 MBytes 401 Mbits/sec 285 1.40 MBytes
[ 5] 15.00-16.00 sec 47.6 MBytes 400 Mbits/sec 337 1.40 MBytes
[ 5] 16.00-17.00 sec 47.6 MBytes 400 Mbits/sec 218 1.12 MBytes
[ 5] 17.00-18.00 sec 47.8 MBytes 401 Mbits/sec 514 1.18 MBytes
[ 5] 18.00-19.00 sec 47.6 MBytes 400 Mbits/sec 300 1.36 MBytes
[ 5] 19.00-20.00 sec 47.8 MBytes 401 Mbits/sec 284 1.41 MBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
Test Complete. Summary Results:
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-20.00 sec 954 MBytes 400 Mbits/sec 20228 sender
[ 5] 0.00-20.04 sec 954 MBytes 399 Mbits/sec receiver
CPU Utilization: local/sender 7.6% (1.5%u/6.1%s), remote/receiver 4.4% (0.4%u/4.0%s)
snd_tcp_congestion bbr
rcv_tcp_congestion bbr
500M BBR :
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 48.8 MBytes 410 Mbits/sec 5134 1.83 MBytes
[ 5] 1.00-2.00 sec 53.9 MBytes 452 Mbits/sec 4026 2.09 MBytes
[ 5] 2.00-3.00 sec 51.2 MBytes 430 Mbits/sec 5251 2.00 MBytes
[ 5] 3.00-4.00 sec 55.6 MBytes 467 Mbits/sec 4600 1.70 MBytes
[ 5] 4.00-5.00 sec 54.4 MBytes 456 Mbits/sec 3488 1.62 MBytes
[ 5] 5.00-6.00 sec 54.4 MBytes 456 Mbits/sec 3578 1.73 MBytes
[ 5] 6.00-7.00 sec 53.9 MBytes 452 Mbits/sec 3253 1.59 MBytes
[ 5] 7.00-8.00 sec 53.5 MBytes 449 Mbits/sec 2833 1.57 MBytes
[ 5] 8.00-9.00 sec 54.6 MBytes 458 Mbits/sec 3822 1.77 MBytes
[ 5] 9.00-10.00 sec 56.2 MBytes 472 Mbits/sec 3617 1.86 MBytes
[ 5] 10.00-11.00 sec 56.5 MBytes 474 Mbits/sec 3580 1.80 MBytes
[ 5] 11.00-12.00 sec 55.4 MBytes 465 Mbits/sec 3695 1.69 MBytes
[ 5] 12.00-13.00 sec 57.9 MBytes 485 Mbits/sec 3313 1.63 MBytes
[ 5] 13.00-14.00 sec 57.9 MBytes 485 Mbits/sec 3282 1.69 MBytes
[ 5] 14.00-15.00 sec 57.6 MBytes 483 Mbits/sec 3104 1.85 MBytes
[ 5] 15.00-16.00 sec 54.6 MBytes 458 Mbits/sec 3579 1.84 MBytes
[ 5] 16.00-17.00 sec 54.5 MBytes 457 Mbits/sec 3615 1.81 MBytes
[ 5] 17.00-18.00 sec 56.6 MBytes 475 Mbits/sec 3104 1.73 MBytes
[ 5] 18.00-19.00 sec 53.4 MBytes 448 Mbits/sec 4521 1.91 MBytes
[ 5] 19.00-20.00 sec 55.4 MBytes 465 Mbits/sec 3380 1.73 MBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
Test Complete. Summary Results:
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-20.00 sec 1.07 GBytes 460 Mbits/sec 74775 sender
[ 5] 0.00-20.04 sec 1.07 GBytes 458 Mbits/sec receiver
CPU Utilization: local/sender 5.4% (0.7%u/4.7%s), remote/receiver 1.9% (0.0%u/1.9%s)
snd_tcp_congestion bbr
rcv_tcp_congestion bbr
-
200M Cubic :
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 21.5 MBytes 180 Mbits/sec 1 454 KBytes
[ 5] 1.00-2.00 sec 26.2 MBytes 220 Mbits/sec 39 346 KBytes
[ 5] 2.00-3.00 sec 23.9 MBytes 200 Mbits/sec 0 376 KBytes
[ 5] 3.00-4.00 sec 23.9 MBytes 200 Mbits/sec 0 387 KBytes
[ 5] 4.00-5.00 sec 23.8 MBytes 199 Mbits/sec 0 387 KBytes
[ 5] 5.00-6.00 sec 23.9 MBytes 200 Mbits/sec 0 387 KBytes
[ 5] 6.00-7.00 sec 23.9 MBytes 200 Mbits/sec 0 413 KBytes
[ 5] 7.00-8.00 sec 23.9 MBytes 200 Mbits/sec 0 413 KBytes
[ 5] 8.00-9.00 sec 23.8 MBytes 199 Mbits/sec 13 294 KBytes
[ 5] 9.00-10.00 sec 23.9 MBytes 200 Mbits/sec 0 339 KBytes
[ 5] 10.00-11.00 sec 23.9 MBytes 200 Mbits/sec 0 370 KBytes
[ 5] 11.00-12.00 sec 23.8 MBytes 199 Mbits/sec 0 378 KBytes
[ 5] 12.00-13.00 sec 23.9 MBytes 200 Mbits/sec 0 380 KBytes
[ 5] 13.00-14.00 sec 23.9 MBytes 200 Mbits/sec 0 383 KBytes
[ 5] 14.00-15.00 sec 23.9 MBytes 200 Mbits/sec 0 385 KBytes
[ 5] 15.00-16.00 sec 23.8 MBytes 199 Mbits/sec 0 386 KBytes
[ 5] 16.00-17.00 sec 23.9 MBytes 200 Mbits/sec 10 307 KBytes
[ 5] 17.00-18.00 sec 23.9 MBytes 200 Mbits/sec 0 345 KBytes
[ 5] 18.00-19.00 sec 19.8 MBytes 166 Mbits/sec 14 281 KBytes
[ 5] 19.00-20.00 sec 22.4 MBytes 188 Mbits/sec 0 329 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
Test Complete. Summary Results:
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-20.00 sec 471 MBytes 198 Mbits/sec 77 sender
[ 5] 0.00-20.04 sec 469 MBytes 196 Mbits/sec receiver
CPU Utilization: local/sender 5.5% (1.8%u/3.7%s), remote/receiver 4.8% (0.7%u/4.1%s)
snd_tcp_congestion cubic
rcv_tcp_congestion cubic
300M Cubic :
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 21.0 MBytes 176 Mbits/sec 0 590 KBytes
[ 5] 1.00-2.00 sec 25.4 MBytes 213 Mbits/sec 20 328 KBytes
[ 5] 2.00-3.00 sec 24.9 MBytes 209 Mbits/sec 0 372 KBytes
[ 5] 3.00-4.00 sec 28.4 MBytes 238 Mbits/sec 0 417 KBytes
[ 5] 4.00-5.00 sec 32.2 MBytes 271 Mbits/sec 0 464 KBytes
[ 5] 5.00-6.00 sec 33.1 MBytes 278 Mbits/sec 2 362 KBytes
[ 5] 6.00-7.00 sec 28.4 MBytes 238 Mbits/sec 0 419 KBytes
[ 5] 7.00-8.00 sec 31.8 MBytes 266 Mbits/sec 0 457 KBytes
[ 5] 8.00-9.00 sec 34.4 MBytes 288 Mbits/sec 0 499 KBytes
[ 5] 9.00-10.00 sec 37.6 MBytes 316 Mbits/sec 0 540 KBytes
[ 5] 10.00-11.00 sec 33.8 MBytes 283 Mbits/sec 12 426 KBytes
[ 5] 11.00-12.00 sec 23.2 MBytes 195 Mbits/sec 1 337 KBytes
[ 5] 12.00-13.00 sec 25.8 MBytes 216 Mbits/sec 0 379 KBytes
[ 5] 13.00-14.00 sec 29.0 MBytes 243 Mbits/sec 0 424 KBytes
[ 5] 14.00-15.00 sec 32.4 MBytes 272 Mbits/sec 0 467 KBytes
[ 5] 15.00-16.00 sec 35.4 MBytes 297 Mbits/sec 0 513 KBytes
[ 5] 16.00-17.00 sec 38.2 MBytes 321 Mbits/sec 0 554 KBytes
[ 5] 17.00-18.00 sec 33.5 MBytes 281 Mbits/sec 16 444 KBytes
[ 5] 18.00-19.00 sec 34.1 MBytes 286 Mbits/sec 0 496 KBytes
[ 5] 19.00-20.00 sec 37.4 MBytes 314 Mbits/sec 0 532 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
Test Complete. Summary Results:
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-20.00 sec 620 MBytes 260 Mbits/sec 51 sender
[ 5] 0.00-20.04 sec 618 MBytes 259 Mbits/sec receiver
CPU Utilization: local/sender 5.2% (0.5%u/4.7%s), remote/receiver 3.5% (0.7%u/2.8%s)
snd_tcp_congestion cubic
rcv_tcp_congestion cubic
400M Cubic :
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 21.0 MBytes 176 Mbits/sec 1 433 KBytes
[ 5] 1.00-2.00 sec 33.8 MBytes 283 Mbits/sec 0 501 KBytes
[ 5] 2.00-3.00 sec 33.9 MBytes 284 Mbits/sec 8 387 KBytes
[ 5] 3.00-4.00 sec 29.8 MBytes 250 Mbits/sec 0 434 KBytes
[ 5] 4.00-5.00 sec 33.1 MBytes 278 Mbits/sec 0 479 KBytes
[ 5] 5.00-6.00 sec 33.9 MBytes 284 Mbits/sec 1 375 KBytes
[ 5] 6.00-7.00 sec 29.0 MBytes 243 Mbits/sec 5 301 KBytes
[ 5] 7.00-8.00 sec 21.2 MBytes 178 Mbits/sec 37 243 KBytes
[ 5] 8.00-9.00 sec 19.5 MBytes 164 Mbits/sec 0 291 KBytes
[ 5] 9.00-10.00 sec 23.0 MBytes 193 Mbits/sec 0 337 KBytes
[ 5] 10.00-11.00 sec 25.9 MBytes 217 Mbits/sec 0 382 KBytes
[ 5] 11.00-12.00 sec 29.5 MBytes 247 Mbits/sec 0 428 KBytes
[ 5] 12.00-13.00 sec 32.6 MBytes 274 Mbits/sec 0 475 KBytes
[ 5] 13.00-14.00 sec 35.8 MBytes 300 Mbits/sec 0 516 KBytes
[ 5] 14.00-15.00 sec 38.6 MBytes 324 Mbits/sec 0 563 KBytes
[ 5] 15.00-16.00 sec 36.6 MBytes 307 Mbits/sec 3 447 KBytes
[ 5] 16.00-17.00 sec 34.5 MBytes 289 Mbits/sec 0 505 KBytes
[ 5] 17.00-18.00 sec 29.4 MBytes 246 Mbits/sec 12 393 KBytes
[ 5] 18.00-19.00 sec 30.4 MBytes 255 Mbits/sec 0 441 KBytes
[ 5] 19.00-20.00 sec 33.5 MBytes 281 Mbits/sec 0 488 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
Test Complete. Summary Results:
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-20.00 sec 605 MBytes 254 Mbits/sec 67 sender
[ 5] 0.00-20.04 sec 603 MBytes 252 Mbits/sec receiver
CPU Utilization: local/sender 5.2% (0.6%u/4.6%s), remote/receiver 6.5% (1.6%u/4.9%s)
snd_tcp_congestion cubic
rcv_tcp_congestion cubic
500M Cubic :
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 21.2 MBytes 178 Mbits/sec 1 419 KBytes
[ 5] 1.00-2.00 sec 32.8 MBytes 275 Mbits/sec 0 478 KBytes
[ 5] 2.00-3.00 sec 36.0 MBytes 302 Mbits/sec 0 522 KBytes
[ 5] 3.00-4.00 sec 38.9 MBytes 326 Mbits/sec 0 566 KBytes
[ 5] 4.00-5.00 sec 31.4 MBytes 263 Mbits/sec 3 460 KBytes
[ 5] 5.00-6.00 sec 30.5 MBytes 256 Mbits/sec 5 358 KBytes
[ 5] 6.00-7.00 sec 27.6 MBytes 232 Mbits/sec 0 404 KBytes
[ 5] 7.00-8.00 sec 30.9 MBytes 259 Mbits/sec 0 450 KBytes
[ 5] 8.00-9.00 sec 34.0 MBytes 285 Mbits/sec 0 495 KBytes
[ 5] 9.00-10.00 sec 37.4 MBytes 314 Mbits/sec 0 537 KBytes
[ 5] 10.00-11.00 sec 34.8 MBytes 292 Mbits/sec 1 419 KBytes
[ 5] 11.00-12.00 sec 32.5 MBytes 273 Mbits/sec 0 475 KBytes
[ 5] 12.00-13.00 sec 35.8 MBytes 300 Mbits/sec 0 515 KBytes
[ 5] 13.00-14.00 sec 31.8 MBytes 266 Mbits/sec 7 393 KBytes
[ 5] 14.00-15.00 sec 30.0 MBytes 252 Mbits/sec 0 437 KBytes
[ 5] 15.00-16.00 sec 31.2 MBytes 262 Mbits/sec 8 341 KBytes
[ 5] 16.00-17.00 sec 27.0 MBytes 226 Mbits/sec 0 396 KBytes
[ 5] 17.00-18.00 sec 23.9 MBytes 200 Mbits/sec 1 317 KBytes
[ 5] 18.00-19.00 sec 24.4 MBytes 204 Mbits/sec 0 352 KBytes
[ 5] 19.00-20.00 sec 27.1 MBytes 228 Mbits/sec 0 399 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
Test Complete. Summary Results:
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-20.00 sec 619 MBytes 260 Mbits/sec 26 sender
[ 5] 0.00-20.04 sec 617 MBytes 258 Mbits/sec receiver
CPU Utilization: local/sender 5.3% (0.8%u/4.4%s), remote/receiver 5.2% (1.0%u/4.2%s)
snd_tcp_congestion cubic
rcv_tcp_congestion cubic
-
Et les tests 500/900 en "-R".
500M BBR en Reverse :
[ ID] Interval Transfer Bitrate
[ 5] 0.00-1.00 sec 61.1 MBytes 512 Mbits/sec
[ 5] 1.00-2.00 sec 59.6 MBytes 500 Mbits/sec
[ 5] 2.00-3.00 sec 59.6 MBytes 500 Mbits/sec
[ 5] 3.00-4.00 sec 59.6 MBytes 500 Mbits/sec
[ 5] 4.00-5.00 sec 59.6 MBytes 500 Mbits/sec
[ 5] 5.00-6.00 sec 59.5 MBytes 499 Mbits/sec
[ 5] 6.00-7.00 sec 59.6 MBytes 500 Mbits/sec
[ 5] 7.00-8.00 sec 59.6 MBytes 500 Mbits/sec
[ 5] 8.00-9.00 sec 59.7 MBytes 501 Mbits/sec
[ 5] 9.00-10.00 sec 59.6 MBytes 500 Mbits/sec
[ 5] 10.00-11.00 sec 59.6 MBytes 500 Mbits/sec
[ 5] 11.00-12.00 sec 59.5 MBytes 499 Mbits/sec
[ 5] 12.00-13.00 sec 59.6 MBytes 500 Mbits/sec
[ 5] 13.00-14.00 sec 59.6 MBytes 500 Mbits/sec
[ 5] 14.00-15.00 sec 59.6 MBytes 500 Mbits/sec
[ 5] 15.00-16.00 sec 59.6 MBytes 500 Mbits/sec
[ 5] 16.00-17.00 sec 59.5 MBytes 499 Mbits/sec
[ 5] 17.00-18.00 sec 59.2 MBytes 496 Mbits/sec
[ 5] 18.00-19.00 sec 60.1 MBytes 504 Mbits/sec
[ 5] 19.00-20.00 sec 59.6 MBytes 500 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
Test Complete. Summary Results:
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-20.04 sec 1.17 GBytes 500 Mbits/sec 1383 sender
[ 5] 0.00-20.00 sec 1.17 GBytes 501 Mbits/sec receiver
CPU Utilization: local/receiver 18.0% (1.6%u/16.4%s), remote/sender 1.0% (0.1%u/0.9%s)
snd_tcp_congestion bbr
rcv_tcp_congestion bbr
900M BBR en Reverse :
[ ID] Interval Transfer Bitrate
[ 5] 0.00-1.00 sec 90.9 MBytes 762 Mbits/sec
[ 5] 1.00-2.00 sec 102 MBytes 854 Mbits/sec
[ 5] 2.00-3.00 sec 105 MBytes 882 Mbits/sec
[ 5] 3.00-4.00 sec 104 MBytes 871 Mbits/sec
[ 5] 4.00-5.00 sec 102 MBytes 858 Mbits/sec
[ 5] 5.00-6.00 sec 104 MBytes 874 Mbits/sec
[ 5] 6.00-7.00 sec 104 MBytes 869 Mbits/sec
[ 5] 7.00-8.00 sec 102 MBytes 854 Mbits/sec
[ 5] 8.00-9.00 sec 104 MBytes 873 Mbits/sec
[ 5] 9.00-10.00 sec 102 MBytes 858 Mbits/sec
[ 5] 10.00-11.00 sec 77.6 MBytes 651 Mbits/sec
[ 5] 11.00-12.00 sec 104 MBytes 873 Mbits/sec
[ 5] 12.00-13.00 sec 103 MBytes 867 Mbits/sec
[ 5] 13.00-14.00 sec 103 MBytes 865 Mbits/sec
[ 5] 14.00-15.00 sec 101 MBytes 849 Mbits/sec
[ 5] 15.00-16.00 sec 103 MBytes 865 Mbits/sec
[ 5] 16.00-17.00 sec 103 MBytes 860 Mbits/sec
[ 5] 17.00-18.00 sec 102 MBytes 855 Mbits/sec
[ 5] 18.00-19.00 sec 104 MBytes 876 Mbits/sec
[ 5] 19.00-20.00 sec 101 MBytes 845 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
Test Complete. Summary Results:
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-20.04 sec 1.98 GBytes 851 Mbits/sec 4274 sender
[ 5] 0.00-20.00 sec 1.97 GBytes 848 Mbits/sec receiver
CPU Utilization: local/receiver 17.9% (1.9%u/15.9%s), remote/sender 2.1% (0.1%u/2.0%s)
snd_tcp_congestion bbr
rcv_tcp_congestion bbr
500M Cubic en Reverse :
[ ID] Interval Transfer Bitrate
[ 5] 0.00-1.00 sec 36.2 MBytes 304 Mbits/sec
[ 5] 1.00-2.00 sec 33.5 MBytes 281 Mbits/sec
[ 5] 2.00-3.00 sec 20.7 MBytes 174 Mbits/sec
[ 5] 3.00-4.00 sec 11.5 MBytes 96.4 Mbits/sec
[ 5] 4.00-5.00 sec 12.0 MBytes 100 Mbits/sec
[ 5] 5.00-6.00 sec 10.8 MBytes 91.0 Mbits/sec
[ 5] 6.00-7.00 sec 12.7 MBytes 106 Mbits/sec
[ 5] 7.00-8.00 sec 14.7 MBytes 123 Mbits/sec
[ 5] 8.00-9.00 sec 14.0 MBytes 118 Mbits/sec
[ 5] 9.00-10.00 sec 13.2 MBytes 111 Mbits/sec
[ 5] 10.00-11.00 sec 12.4 MBytes 104 Mbits/sec
[ 5] 11.00-12.00 sec 10.2 MBytes 85.8 Mbits/sec
[ 5] 12.00-13.00 sec 12.3 MBytes 103 Mbits/sec
[ 5] 13.00-14.00 sec 12.2 MBytes 102 Mbits/sec
[ 5] 14.00-15.00 sec 13.2 MBytes 110 Mbits/sec
[ 5] 15.00-16.00 sec 11.3 MBytes 94.7 Mbits/sec
[ 5] 16.00-17.00 sec 15.1 MBytes 127 Mbits/sec
[ 5] 17.00-18.00 sec 12.0 MBytes 101 Mbits/sec
[ 5] 18.00-19.00 sec 8.15 MBytes 68.4 Mbits/sec
[ 5] 19.00-20.00 sec 9.09 MBytes 76.3 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
Test Complete. Summary Results:
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-20.04 sec 298 MBytes 125 Mbits/sec 45 sender
[ 5] 0.00-20.00 sec 295 MBytes 124 Mbits/sec receiver
CPU Utilization: local/receiver 8.1% (1.0%u/7.1%s), remote/sender 0.4% (0.0%u/0.4%s)
snd_tcp_congestion cubic
rcv_tcp_congestion cubic
900M Cubic en Reverse :
[ ID] Interval Transfer Bitrate
[ 5] 0.00-1.00 sec 53.7 MBytes 451 Mbits/sec
[ 5] 1.00-2.00 sec 33.3 MBytes 279 Mbits/sec
[ 5] 2.00-3.00 sec 19.1 MBytes 160 Mbits/sec
[ 5] 3.00-4.00 sec 11.7 MBytes 98.3 Mbits/sec
[ 5] 4.00-5.00 sec 6.98 MBytes 58.6 Mbits/sec
[ 5] 5.00-6.00 sec 11.0 MBytes 92.3 Mbits/sec
[ 5] 6.00-7.00 sec 11.1 MBytes 92.8 Mbits/sec
[ 5] 7.00-8.00 sec 11.3 MBytes 94.4 Mbits/sec
[ 5] 8.00-9.00 sec 15.5 MBytes 130 Mbits/sec
[ 5] 9.00-10.00 sec 14.5 MBytes 122 Mbits/sec
[ 5] 10.00-11.00 sec 14.6 MBytes 123 Mbits/sec
[ 5] 11.00-12.00 sec 15.2 MBytes 127 Mbits/sec
[ 5] 12.00-13.00 sec 15.5 MBytes 130 Mbits/sec
[ 5] 13.00-14.00 sec 12.8 MBytes 107 Mbits/sec
[ 5] 14.00-15.00 sec 10.6 MBytes 89.1 Mbits/sec
[ 5] 15.00-16.00 sec 14.1 MBytes 118 Mbits/sec
[ 5] 16.00-17.00 sec 12.2 MBytes 103 Mbits/sec
[ 5] 17.00-18.00 sec 8.76 MBytes 73.5 Mbits/sec
[ 5] 18.00-19.00 sec 7.94 MBytes 66.6 Mbits/sec
[ 5] 19.00-20.00 sec 12.0 MBytes 101 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
Test Complete. Summary Results:
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-20.04 sec 321 MBytes 134 Mbits/sec 148 sender
[ 5] 0.00-20.00 sec 312 MBytes 131 Mbits/sec receiver
CPU Utilization: local/receiver 8.2% (0.9%u/7.3%s), remote/sender 1.3% (0.2%u/1.1%s)
snd_tcp_congestion cubic
rcv_tcp_congestion cubic
-
J'ai bien reçu le fichier via ma demande. oui c'est curieux mais j’avoue ne plus utiliser dropbox (j'ai du reset mon mot de passe tellement ca faisait longtemps ... ).
du coup ce fichier sera actualisé ou c'est juste une fois ?
j'ai pu faire une rapide conversion vers grafana, ca donne ca: https://snapshot.raintank.io/dashboard/snapshot/montZGxtD7bsW2rLPCxlxqBMPLDg8s8v?orgId=2&fullscreen&panelId=2
c'est un snapshot donc pas temp réel mais c'est l'idée: c'est bien plus pratique pour explorer les données. On peut zoomer sur le graphe ou en haut a droite choisir une période. click sur les noms des courbes pour limiter l'afficher a une courbe (ctrl+click pour voir 2 courbes en meme temps), changer les couleurs, annoter, etc.
Pour faire ca de facon permanente tu devrais mettre en forme ton fichier csv pour qu'il soit aux normes internationales de mesures:
date au format "yyyy:mm:dd hh:mm:ss" et les nombres avec un point comme séparateur décimale et pas une virgule.
Le fichier devrait être au format:
date, debit, sens, proto, single-ou-multi
C'est a dire une date et une mesure par ligne suivi d'étiquettes (labels) qui permettent de regrouper/classer les mesures (les labels sont libres,on peut mettre des trucs plus jolis si on souhaite, comme "Download" plutot que "dl").
donc au lieu d'une ligne avec les 8 valeurs
2020/02/01 00:00:00 4.5 2.99 0.67 0.66 494 487 420 116
le mieux c'est 8 lignes du style:
2020/02/01 00:00:00 4.5,dl,ipv4,multi
2020/02/01 00:00:00 2.99,dl,ipv6,multi
2020/02/01 00:00:00 0.67,dl,ipv4,mono
2020/02/01 00:00:00 0.66,dl,ipv6,mono
2020/02/01 00:00:00 494,up,ipv4,multi
2020/02/01 00:00:00 487,up,ipv6,multi
2020/02/01 00:00:00 420,up,ipv4,mono
2020/02/01 00:00:00 116,up,ipv6,mono
bref tu vois l'idée. ces lignes peuvent être injectées dans prometheus par exemple pour faire ce genre de graphe en temps réel.
Vivien -> peut-être déplacer les nombreux tests dans un autre sujet ou séparer la sous-discussion sur la visu / graphe ?
-
Et les tests 500/900 en "-R".
C'est étonnant et bien différents des tests de Breizh29 :
(https://lafibre.info/images/free_debit/202001_comparatif_bubic_bbr_2.png)
-
Pour les abonnés Free qui ont le même genre de désagréments n'hésitez-pas à voter ici : https://dev.freebox.fr/bugs/task/29953
J'ai voté et laissé un commentaire mais ça ne ressort toujours pas quand on clique sur la liste des tâches, la dernière en date est du 10/02/2020. Il faut cliquer sur 'date d'ouverture' pour la voir apparaitre...
-
J'ai voté et laissé un commentaire mais ça ne ressort toujours pas quand on clique sur la liste des tâches, la dernière en date est du 10/02/2020. Il faut cliquer sur 'date d'ouverture' pour la voir apparaitre...
Comme souvent avec les problèmes de performance ils vont probablement laisser mourir et planquer le ticket...
-
j'ai pu faire une rapide conversion vers grafana ...
Merci pour ton POC.
Effectivement, ça a une IHM dynamique sympa.
Quand j'aurai à nouveau un peu plus de temps, je m'y plongerai peut-être.
-
Hello !
Je suis en train de migrer le script sur une VM Ubuntu, ne vous étonnez donc pas s'il y a des coupures dans les données et/ou la mise à jour des graphiques.
J'ai fait quelques essais cubic/bbr pour l'upload, c'est dingue ce truc.
En Cubic, peu de retries, mais un upload mono qui culmine entre 200 et 300 Mbits/s.
En BBR, un nombre gigantesque de retries, mais un mono qui semble stable à 560/570 Mbits/s.
En DL, rien de choquant pour le moment. On verra avec le temps.
-
Merci Breizh29.
J'ai exploité tes données pour comparer les protocole de congestion TCP : https://lafibre.info/tcpip/bbr/msg732168/#msg732168
Les données qu'on a en Illinois bougent beaucoup, cela serait intéressant de pouvoir le rendre disponible avec iPerf3.
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
# 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.
-
Tu test comment ? faut les droits de chaque coté: l'option -C change l'algo des 2 cotés quelque soit le sens du test. du coup essais avec 'sudo iperf3 ...' coté client
-
Mise à jour du 1er post.
On voit évidemment le bon de l'upload avec le passage en bbr.
En download, il y a, comme on l'avait déjà observé avec le mac, une perte de débit. A voir si certaines optimisations permettraient de le limiter ou de l'annuler.
D'autre part, il faudrait voir si, en testant avec bbr également côté serveur, cela impacte le résultat.
EDIT: jusqu'à présent, je m'étais contenté de spécifier bbr dans sysctl.conf. A partir de 11h40, j'ai ajouté -C bbr à l'appel iperf3, et les débits en DL ont également bondi (le gain semble donc important si les 2 parties s'entendent en bbr).
-
c'est une VM Linux dans MacOS ? avec quel hyperviseur (virtualbox, vmware, parallels, etc ?) et comment est configuré le réseau de la VM ?
si tu fais du NAT entre la VM et l'hote (config par défaut le plus souvent) tu risque de limité ton débit a cause du CPU. Une connexion de pont (bridge) sera en général plus performante.
-
c'est une VM Linux dans MacOS ? avec quel hyperviseur (virtualbox, vmware, parallels, etc ?) et comment est configuré le réseau de la VM ?
Non, j'ai acquis un NUC10 + Solo 10G (je connaissais déjà mais n'étais pas certain du résultat, mais avec ta confirmation, j'ai franchi le pas), installé un ESXi et monté une VM Ubuntu dessus.
J'ai conservé la conf réseau par défaut de l'ESXi (vSwitch donc bridge ?).
Ça marche bien.
Les hyperviseurs "de bureau" n'ont pas de driver 10G, à ma connaissance (en tout cas pas trouvé, peut-être pas bien cherché).
-
Les hyperviseurs "de bureau" n'ont pas de driver 10G, à ma connaissance (en tout cas pas trouvé, peut-être pas bien cherché).
Pour les hyperviseurs de bureau (type 2) il n'y a pas besoin de drivers c'est celui de l’hôte qui est utilisé.
-
OK, mais avec ceux que j'ai utilisés sous Mac (VMWare, Parallels), j'ai toujours été limité à une connexion 1 Gbps. Jamais pu aller à 10.
-
OK, mais avec ceux que j'ai utilisés sous Mac (VMWare, Parallels), j'ai toujours été limité à une connexion 1 Gbps. Jamais pu aller à 10.
ah sans doute une limitation sur Mac alors (VMXNET pas compatible peut-etre ?).
-
Les hyperviseurs type 2 n'utilisent pas le driver de l'hôte.
Sous VMware par exemple ça utilise quasi toujours une e1000/e1000e.
Pour utiliser du VMXNet3 il faut le forcer dans le fichier vmx.
Ceci étant on a beau avoir du e1000 dans la VM ce n'est pas pour autant qu'on est bridés à 1 Gbps (sauf si on transite par la carte physique).
Le mieux reste souvent la VMXNet3 surtout avec des débits un peu soutenus où on sollicite le CPU (plus optimisé).
-
Merci pour ces informations.
Sinon, je suis passé de paris.testdebit.info à Bouygues.testdebit.info car le premier a souvent (en tout cas chez moi) des problèmes de non-réponse, connectivité IPv6, ... (ou alors c'est moi qui le mets à genoux ;D - l'avenir nous le dira, si ça se répète... ).
Pour l'instant, ça se passe mieux.
-
Merci pour ces informations.
Sinon, je suis passé de paris.testdebit.info à Bouygues.testdebit.info car le premier a souvent (en tout cas chez moi) des problèmes de non-réponse, connectivité IPv6, ... (ou alors c'est moi qui le mets à genoux ;D - l'avenir nous le dira, si ça se répète... ).
Pour l'instant, ça se passe mieux.
vu ou tu es ca devrait être le meme non ?
bouygues.testdebit.info est une anycast vers:
paris.testdebit.info
lille.testdebit.info
lyon.testdebit.info
aix-marseille.testdebit.info
bordeaux.testdebit.info
ou alors peut-être que tu es routé sur Bordeaux ?
Tu peux éventuellement faire des tests pour voir laquelle a le meme ping ca donnera une indication.
-
Je crois que pour Free c'est toujours routé vers Paris.
-
Ah ben c’est vraiment étrange alors !
Je galérais depuis des heures avec paris.xxx et il a suffi que je passe sur bouygues.xxx pour que ça aille mieux tout de suite !
PS: mes soucis se concentraient sur l’ipv6, pas de souci en ipv4...
-
Tu peux éventuellement faire des tests pour voir laquelle a le meme ping ca donnera une indication.
Il suffit de charger http://bouygues.testdebit.info/, la page indique "Serveur haute performance hébergé sur xxxx".
-
Je confirme que dans les 2 cas, cela m'indique qu'il s'agit d'un serveur hébergé à Paris.
Alors comment expliquer ce que j'ai observé clairement ?
J'ai essayé une désactivation/réaction de la connexion réseau, et même un reboot du serveur (bon, là c'est merci à ma jeune fille - c'est irrésistible le bouton allumé en bleu d'un NUC-, mais ça a eu le mérite de prouver que ça ne venait pas de la VM, au moins...). Dans les deux cas, ça n'a rien amélioré.
Alors que dès que je suis passé de paris.xxx à bouygues.xxx, directement tout est allé mieux...
-
C'est étonnant que tu vois une différence entre paris.testdebit.info, bouygues.testdebit.info.
Les IP sont différentes mais, pour un client Free, c'est la même machine et si un port iPerf3 est utilisé avec paris.testdebit.info il sera inutilisable pour bouygues.testdebit.info.
Pour les machines virtuelles, ton système d’exploitation invité va voir une carte Intel 1 Gb/s, mais il est normalement possible de dépasser 1 Gb/s. Un test que tu peut réaliser, c'est un iPerf entre l’hôte et l'invité. Le débit devrait monter bien haut, probablement plus de 10 Gb/s.
Pour le protocole de congestion TCP, ce qui compte c'est le choix sur la machine qui émet les paquets. Peu importe le protocole sur la machine qui reçois les paquets.
-
C'est étonnant que tu vois une différence entre paris.testdebit.info, bouygues.testdebit.info.
Les IP sont différentes mais, pour un client Free, c'est la même machine et si un port iPerf3 est utilisé avec paris.testdebit.info il sera inutilisable pour bouygues.testdebit.info
Lorsque j’ai le problème, je n’ai pas de réponse du serveur avant un timeout probable.
Edt-ce qu’il ne pourrait pas y avoir un problème de routage, en l’occurrence en IPv6, sur le nom paris.xxx là où ce souci n’existe pas avec bouygues.xxx ?
-
Pour le protocole de congestion TCP, ce qui compte c'est le choix sur la machine qui émet les paquets. Peu importe le protocole sur la machine qui reçois les paquets.
Uniquement ?
Quand on est passé à bbr depuis le mac, les débits ont beaucoup baissé par rapport à cubic/illinois.
Alors que là, en l’activant depuis la VM Linux, au contraire, les débits ont largement monté.
J’imagine bien qu’il y a d’autres facteurs différenciants côté OS, mais tout de même...
-
Breizh29, serait-il possible d'indiquer ici chaque changement de configuration ?
Cela permet de savoir quel modification sur la courbe est liée à quelle modification.
C'est vraiment pratique pour exploiter les résultats.
Je suis aussi preneur du processeur de ton mac (tu me l'a donné, mais quand j'ai cherché, impossible de le retrouver)
Pour ton NUC10 + Solo 10G , je suis intéressé par :
- lscpu
- lspci (je n'ai jamais eu de Thunderbolt 3, je ne sais pas si cela apparaît dans un lspci)
- free -m
- lsb_release -a
- uname -a
- version iPerf3 utilisée
- les optimisation réalisées.
Exemple avec l'optimisation du coté serveur : Fichier /etc/sysctl.d/90-server-optimization.conf
# Reduce the swap
vm.swappiness = 1
# Disable the memorization of previous tests, in order to avoid that the server burns the tests following a limited performance
net.ipv4.tcp_no_metrics_save=1
# Increase TCP buffers
net.ipv4.tcp_rmem=4096 131072 16777216
net.ipv4.tcp_wmem=4096 87380 16777216
net.core.rmem_max=16777216
net.core.wmem_max=16777216
# Increase the queue within the Linux kernel where traffic is stored after reception from the NIC
net.core.netdev_max_backlog=4000
# Reduce the threshold where a DDOS impacts the server
net.ipv4.tcp_max_syn_backlog = 4096
# Increase number of incoming connections
net.core.somaxconn = 512
Enfin je te remercie pour tes tests qui intéressent beaucoup de monde (certains personnes ont tenté de comparer BBR et Cubic sur un réseau de test, sans aucune perte de paquets et ils étaient étonnés de ne pas voir de différences).
Un vrai réseau avec des vraies pertes et une latence non nulle est vraiment idéal pour comparer les algorithmes de congestion.
-
Breizh29, serait-il possible d'indiquer ici chaque changement de configuration ?
Déjà réalisé sur le post 1 - j'ai depuis rajouté des précisions eu égard à tes questions ci-dessous.
Je suis aussi preneur du processeur de ton mac (tu me l'a donné, mais quand j'ai cherché, impossible de le retrouver)
Tu veux pas le retenir celui-là ;)
C'est un i7 8700B
Pour ton NUC10 + Solo 10G , je suis intéressé par :
- lscpu
- lspci (je n'ai jamais eu de Thunderbolt 3, je ne sais pas si cela apparaît dans un lspci)
- free -m
- lsb_release -a
- uname -a
J'ai mis tout ça dans le fichier joint.
Note: je n'ai affecté "que" 4 vCPU (sur 12) à la VM, et 4 Go de RAM.
- version iPerf3 utilisée
version 3.6
- les optimisation réalisées.
Cf. post 1
-
Avec bbr depuis la VM Ubuntu, j'ai passé la soirée au-dessus des 7 Gb/s en multithread, et d'honorables 3,6 à 4 Gb/s en monothread 8)
C'est impressionnant !
Hâte de le mettre à l'épreuve du dimanche soir...
-
il est dans une VM sur ESXi donc on ne voit pas la partie TB3.
Son interface réseau 10G est un solo10G (contrôleur Aquantia AQC107 dedans) dans un port TB3, voila ce que donnerai un lspci -tv en barematel dessus:
+-1c.4-[02-6c]----00.0-[03-6c]--+-00.0-[04]----00.0 Intel Corporation JHL6340 Thunderbolt 3 NHI (C step) [Alpine Ridge 2C 2016]
| +-01.0-[05-6b]----00.0-[06-07]----01.0-[07]----00.0 Aquantia Corp. AQC107 NBase-T/IEEE 802.3bz Ethernet Controller [AQtion]
l'hyperviseur vmware présente l'interface comme un VMXNET3. En dessous c'est le driver d'Aquantia, "atlantic (https://github.com/torvalds/linux/tree/master/drivers/net/ethernet/aquantia/atlantic)" inclut dans le noyau linux, mais la version vmklinux pour ESXi (a moins qu'une version native existe?)
voici les détails complets de l'AQC107 vu du bus pci (sudo lspci -vv):
07:00.0 Ethernet controller: Aquantia Corp. AQC107 NBase-T/IEEE 802.3bz Ethernet Controller [AQtion] (rev 02)
Subsystem: Sonnet Technologies, Inc. AQC107 NBase-T/IEEE 802.3bz Ethernet Controller [AQtion]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
Interrupt: pin A routed to IRQ 18
Region 0: Memory at 90240000 (64-bit, non-prefetchable) [size=64K]
Region 2: Memory at 90250000 (64-bit, non-prefetchable) [size=4K]
Region 4: Memory at 90400000 (64-bit, non-prefetchable) [size=4M]
[virtual] Expansion ROM at 90200000 [disabled] [size=256K]
Capabilities: [40] Express (v2) Endpoint, MSI 00
DevCap: MaxPayload 512 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us
ExtTag+ AttnBtn- AttnInd- PwrInd- RBE+ FLReset+ SlotPowerLimit 0.000W
DevCtl: CorrErr- NonFatalErr- FatalErr- UnsupReq-
RlxdOrd+ ExtTag+ PhantFunc- AuxPwr- NoSnoop+ FLReset-
MaxPayload 128 bytes, MaxReadReq 512 bytes
DevSta: CorrErr- NonFatalErr- FatalErr- UnsupReq- AuxPwr+ TransPend-
LnkCap: Port #0, Speed 8GT/s, Width x4, ASPM L0s L1, Exit Latency L0s unlimited, L1 unlimited
ClockPM- Surprise- LLActRep- BwNot- ASPMOptComp+
LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- CommClk+
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 8GT/s (ok), Width x4 (ok)
TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
DevCap2: Completion Timeout: Not Supported, TimeoutDis+, LTR-, OBFF Not Supported
AtomicOpsCap: 32bit- 64bit- 128bitCAS-
DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR-, OBFF Disabled
AtomicOpsCtl: ReqEn-
LnkCtl2: Target Link Speed: 8GT/s, EnterCompliance- SpeedDis-
Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS-
Compliance De-emphasis: -6dB
LnkSta2: Current De-emphasis Level: -6dB, EqualizationComplete+, EqualizationPhase1+
EqualizationPhase2+, EqualizationPhase3+, LinkEqualizationRequest-
Capabilities: [80] Power Management version 3
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [90] MSI-X: Enable+ Count=32 Masked-
Vector table: BAR=2 offset=00000000
PBA: BAR=2 offset=00000200
Capabilities: [a0] MSI: Enable- Count=1/32 Maskable- 64bit+
Address: 0000000000000000 Data: 0000
Capabilities: [c0] Vital Product Data
pcilib: sysfs_read_vpd: read failed: Input/output error
Not readable
Capabilities: [100 v2] Advanced Error Reporting
UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- AdvNonFatalErr-
CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- AdvNonFatalErr+
AERCap: First Error Pointer: 00, ECRCGenCap+ ECRCGenEn- ECRCChkCap+ ECRCChkEn-
MultHdrRecCap- MultHdrRecEn- TLPPfxPres- HdrLogCap-
HeaderLog: 00000000 00000000 00000000 00000000
Capabilities: [150 v1] Vendor Specific Information: ID=0001 Rev=1 Len=024 <?>
Capabilities: [180 v1] Secondary PCI Express <?>
Kernel driver in use: atlantic
Kernel modules: atlantic
et l'offload supporté par ce driver (ethtool --show-offload ens8) (ca n'indique pas comment ESXi le configure).
Features for ens8:
rx-checksumming: on
tx-checksumming: on
tx-checksum-ipv4: off [fixed]
tx-checksum-ip-generic: on
tx-checksum-ipv6: off [fixed]
tx-checksum-fcoe-crc: off [fixed]
tx-checksum-sctp: off [fixed]
scatter-gather: on
tx-scatter-gather: on
tx-scatter-gather-fraglist: off [fixed]
tcp-segmentation-offload: on
tx-tcp-segmentation: on
tx-tcp-ecn-segmentation: off [fixed]
tx-tcp-mangleid-segmentation: off
tx-tcp6-segmentation: off [fixed]
generic-segmentation-offload: on
generic-receive-offload: on
large-receive-offload: off
rx-vlan-offload: on
tx-vlan-offload: on
ntuple-filters: on
receive-hashing: on
highdma: off [fixed]
rx-vlan-filter: on
vlan-challenged: off [fixed]
tx-lockless: off [fixed]
netns-local: off [fixed]
tx-gso-robust: off [fixed]
tx-fcoe-segmentation: off [fixed]
tx-gre-segmentation: off [fixed]
tx-gre-csum-segmentation: off [fixed]
tx-ipxip4-segmentation: off [fixed]
tx-ipxip6-segmentation: off [fixed]
tx-udp_tnl-segmentation: off [fixed]
tx-udp_tnl-csum-segmentation: off [fixed]
tx-gso-partial: on
tx-sctp-segmentation: off [fixed]
tx-esp-segmentation: off [fixed]
tx-udp-segmentation: on
fcoe-mtu: off [fixed]
tx-nocache-copy: off
loopback: off [fixed]
rx-fcs: off [fixed]
rx-all: off [fixed]
tx-vlan-stag-hw-insert: off [fixed]
rx-vlan-stag-hw-parse: off [fixed]
rx-vlan-stag-filter: off [fixed]
l2-fwd-offload: off [fixed]
hw-tc-offload: off [fixed]
esp-hw-offload: off [fixed]
esp-tx-csum-hw-offload: off [fixed]
rx-udp_tunnel-port-offload: off [fixed]
tls-hw-tx-offload: off [fixed]
tls-hw-rx-offload: off [fixed]
rx-gro-hw: off [fixed]
tls-hw-record: off [fixed]
-
Merci pour les info sur la première page, j'avais zappé.
C'est un i7 8700B
Le Core i7-8700B est un 6 cœurs / 12 threads 3,2 GHz en fréquence de base / 4,6 Ghz en boost.
Ce qui est impressionnant, c'est le TDP/PDT de 65 watts pour un processeur catégorisé "mobile"
Cela change de mon Core i5-8250U : 4 cœurs / 8 threads à 1,6 GHz en fréquence de base / 3,4 Ghz en boost en un TDP/PDT de 15 watts.
-
En dessous c'est le driver d'Aquantia, "atlantic (https://github.com/torvalds/linux/tree/master/drivers/net/ethernet/aquantia/atlantic)" inclut dans le noyau linux, mais la version vmklinux pour ESXi (a moins qu'une version native existe?)
Non, c'est bien celui-là que j'ai téléchargé séparément pour l'inclure dans une version custom de l'iso de l'ESXi.
C'est peu chiant, car il faut partir d'un clone de l'iso "officielle", retirer par ailleurs le driver ne1000 inclus et le remplacer par une autre version (car il n'est pas compatible avec le chip réseau intégré des nuc10 et fait planter l'installation).
Juste pour ça, je me suis déployé un vCenter dans une VM de mon ancien ESXi pour faire la manip (l'autre méthode est à base de Powershell...). Bon, ça me permet de découvrir, mais c'est sacrément chronophage...
-
J'ai amélioré ma gestion du timeout dans le script, car IPv6 est depuis ce midi encore dans les choux sur le serveur (en tout cas, depuis chez moi, ça "tombe dans le vide" en v6 là où je n'ai pas de problème en v4 - et j'ai encore validé que relance réseau ou reboot VM ne solutionnait pas).
Du coup, si je tombe en timeout dans un protocole, je ne poursuis pas les tests pour ce protocole.
PS: lors des soucis, ping et traceroute fonctionnent toujours.
PS2: revenu depuis 17h10. Vivien, tu as corrigé quelque chose ?
-
Je n'ai rien changé.
iPerf3 écoute de la même façon en IPv4 et en IPv6.
Je ne vois pas comment c'est possible que cela ne fonctionne pus en IPv6 alors que tu ping le serveur en IPv6 et que le service est fonctionnel en IPv4.
Cela serait possible de tester la disponibilité du serveur web quand tu as un problème ?
Fichier de 500 Ko en IPv4 : https://ipv4.bouygues.testdebit.info/500k/500k.jpg
Fichier de 500 Ko en IPv6 : https://ipv6.bouygues.testdebit.info/500k/500k.jpg
C'est une image jpeg de 500 000 octets qui s'affiche parfaitement dans un navigateur web.
-
C'est à nouveau KO chez moi depuis 18h40 (toujours uniquement en IPv6, je reprécise).
J'ai accès à tes 2 images.
-
Ça pourrait pas être une mesure de type "anti-DDoS" qui se déclencherait ?
-
Voici les limitations mises en place sur le serveur :
# cat /root/iptables-rules.sh
#!/bin/dash
# Limiter le nombre de sessions tcp par client (un client = une IPv4 ou un /64 en IPv6)
/sbin/iptables -A INPUT -p tcp --syn -m connlimit --connlimit-above 100 -m limit --limit 30/hour --limit-burst 1 -j LOG --log-prefix="drop-c-"
/sbin/iptables -A INPUT -p tcp --syn -m connlimit --connlimit-above 100 -j REJECT
/sbin/ip6tables -A INPUT -p tcp --syn -m connlimit --connlimit-above 100 --connlimit-mask 64 -m limit --limit 30/hour --limit-burst 1 -j LOG --log-prefix="drop-c-"
/sbin/ip6tables -A INPUT -p tcp --syn -m connlimit --connlimit-above 100 --connlimit-mask 64 -j REJECT
Je ne sais pas si Bouygues Telecom a une protection.
Maintenant je note que les connexions à Apache fonctionnent.
Deux cas :
- Si le système DDOS bloque les connexions sont bloqués sur tous les ports, Apache ne devrait pas répondre
- Si le système DDOS ne bloque que les connexions du port en question, tu devrait pouvoir utiliser un autre port TCP, sachant que iPerf3 écoute sur 22 ports.
Ton script teste bien les ports un à un ?
-
Ton script teste bien les ports un à un ?
Oui, mais en l'occurrence, lorsque ça merde sur un port en IPv6, ça fait la même chose sur tous les autres a priori...
-
Tu aurais moyen de tester depuis une autre IPv6 quand c'est bloqué, pour savoir si c'est ton IP qui est bloqué ou tout les connexion IPv6 ?
Je pense à ton mobile si tu es chez Bouygues Telecom ou Orange.
-
Je n’ai pas ça, mais du mac, qui se voit attribuer une autre IPv6, ça le ferait ? Même si c’est le même préfixe...
-
Ça pourrait être côté Free aussi non ? Des pics de trafic sur des ports bizarres qui provoqueraient des faux positifs ?
-
De nouveau OK depuis 19h20...
Je ne touche à rien !
-
Ce qui est étonnant, c'est que seul l'IPv6 est impacté.
Je ne sais pas si dans ton script il est simple d'inverser l'ordre des tests ipv4 et ipv6 pour voir si cela a un impact.
Sinon, il faudrait vraiment savoir savoir si tu es le seul impacté par le blocage de connexion ou si cela concerne tout le trafic IPv6 du serveur.
Tu pourrais aussi utiliser lille.testdebit.info, qui est moins chargé pour seulement 4ms de latence en +
-
Je ne sais pas si dans ton script il est simple d'inverser l'ordre des tests ipv4 et ipv6 pour voir si cela a un impact.
Ce n’est pas direct, mais possible si vraiment...
Actuellement, les tests sont faits dans cet ordre:
- DL IPv4 mono
- UL IPv4 mono
- DL IPv6 mono
- UL IPv6 mono
- DL IPv4 multi
- UL IPv4 multi
- DL IPv6 multi
- UL IPv6 multi
C’est la présentation dans le csv qui est différente ensuite.
-
BBR fait vraiment des merveilles... à se demander à quel prix pour les autres du coup ?
Cela se comporte-t-il comme si j'avais un gyrophare et que tout le monde s'écartait le long du chemin pour laisser passer mes paquets ?
Cf. https://lafibre.info/tcpip/bbr/msg732496/#msg732496 (1er graphique...)
Et quand même un truc que je ne comprends pas : si, pour que BBR soit efficace, il suffit qu'il soit installé sur la machine émettrice, pourquoi, dans les anciens tests avec le mac, alors qu'il était activé côté serveur, a-t-il plombé les débits DL par rapport à Cubic et Illinois ?
-
Les tests avec ton Mac sont en contradiction avec les test sous Ubuntu.
J'ai passé le week-end à lire de la doc sur BBR, c'est bien uniquement coté de celui qui émet les données.
Il est même possible de changer de Cubic à BBR en cours de connexion TCP.
Spotify a également fait des tests sur BBR
L'expérience
De nombreux changements de protocole Internet nécessitent des mises à jour coordonnées des clients et des serveurs (en vous regardant, IPv6!). BBR est différent, il ne doit être activé que du côté de l'expéditeur. Il peut même être activé après l'ouverture de la connexion TCP !
Pour cette expérience, nous avons configuré un sous-ensemble aléatoire d'utilisateurs pour inclure «bbr» dans le nom d'hôte de la demande audio en tant qu'indicateur, et ajouter quelques lignes à la configuration du serveur. Les autres requêtes sont traitées en utilisant la valeur par défaut, CUBIC.
Voici les graphiques plus lisibles pour ceux qui n'ont pas d'écran 4k avec en bonus la mention CUBIC / BBR :
(https://lafibre.info/images/free_debit/202002_comparatif_cubic_bbr_1.png)
(https://lafibre.info/images/free_debit/202002_comparatif_cubic_bbr_2.png)
-
C'est bien ce que je dis, je ne comprends pas cette différence entre les observations MacOS et celles d'Ubuntu.
C'est en contradiction avec ce que dit la littérature sur le sujet.
Et pourtant, je n'ai rien inventé de mes résultats ! Pourrait-il y avoir quand même, côté récipiendaire, un paramétrage qui n'a pas "convenu" à BBR ?
-
Vu que tu es sous Ubuntu, idéalement, cela serait intéressant de faire une courbe BBR et une courbe Cubic, afin de comparer les deux sur les mêmes tranche horaires.
Vu qu'il y a pas mal de courbes, peut-être arrêter de faire des tests en IPv4 et en IPv6, on a vu que cela change peu les résultats. Je serais d'avis de ne garder que les tests IPv6. Tant qu'à changer le protocole, je partirais sur le serveur de Lille, moins chargé que celui de Paris.
Pour iPerf3, cela serait bien de passer sur le version 3.7 => https://lafibre.info/iperf/installation-iperf3-7/
pour les optimisation TCP, je n'ai pas encore tout vérifié (il y a peut-être des bonnes idées que je devrait reprendre), mais je suis étonné par "net.ipv4.tcp_rmem = 4096 87380 134217728" la valeur par défaut, 87380 est inférieur à celle mise sur des OS récent.
Voici les valeurs que j'utilise coté serveur, avec la version par défaut indiquée :
# Reduce the swap
cat /proc/sys/vm/swappiness
1 (défaut : 60)
# Désactiver la mémorisation des tests précédents sur le serveur afin d’assurer une décorrélation des tests successifs et éviter que le serveur bride les tests suite à une performances limitée
cat /proc/sys/net/ipv4/tcp_no_metrics_save
1 (défaut : 0)
# Increase TCP buffers
cat /proc/sys/net/ipv4/tcp_rmem
4096 131072 16777216 (défaut : 4096 131072 6291456)
cat /proc/sys/net/ipv4/tcp_wmem
4096 87380 16777216 (défaut : 4096 16384 4194304)
cat /proc/sys/net/core/rmem_max
16777216 (défaut : 212992)
cat /proc/sys/net/core/wmem_max
16777216 (défaut : 212992)
# Increase the queue within the Linux kernel where traffic is stored after reception from the NIC
cat /proc/sys/net/core/netdev_max_backlog
4000 (défault : 1000)
# Reduce the threshold where a DDOS impacts the server
cat /proc/sys/net/ipv4/tcp_max_syn_backlog
4096 (défaut : 1024)
# Increase number of incoming connections
cat /proc/sys/net/core/somaxconn
512 (défaut : 128)
-
J'aurai un peu de boulot pour réorienter proprement vers ça. Je vois ça...
Pour les "optimisations", contrairement à MacOS, j'ai pris du tout fait "spécial 10 Gb" (pourtant récent il me semble) et n'ai pas eu le temps de creuser propriété par propriété.
Je suis tout à fait preneur de valeurs les plus adaptées possibles. N'hésite pas à me concocter une liste de valeurs que j'injecterai au moment de la bascule...
-
En complément, le trafic par serveur : (ce sont tous des serveurs 10 Gb/s)
https://paris.testdebit.info/
(https://lafibre.info/images/stats/202002_trafic_serveur_testdebit_paris.png)
https://lille.testdebit.info/
(https://lafibre.info/images/stats/202002_trafic_serveur_testdebit_lille.png)
https://lyon.testdebit.info/
(https://lafibre.info/images/stats/202002_trafic_serveur_testdebit_lyon.png)
https://aix-marseille.testdebit.info/
(https://lafibre.info/images/stats/202002_trafic_serveur_testdebit_aix.png)
https://bordeaux.testdebit.info/
(https://lafibre.info/images/stats/202002_trafic_serveur_testdebit_bordeaux.png)
-
C'est intéressant comme tests, on voit que le débit maximum peut être atteint en mono-thread dans les deux sens avec BBR.
-
En complément, le trafic par serveur : (ce sont tous des serveurs 10 Gb/s)
https://paris.testdebit.info/
(https://lafibre.info/images/stats/202002_trafic_serveur_testdebit_paris.png)
C'est "amusant" le gros pic du serveur Paris, juste avant le moment où j'ai eu impossibilité de faire des tests en IPv6...
Coïncidence ? ;)
Nan, ça n'existe pas...
-
Énigme du jour :
Cette nuit, entre 3h26 et 3h34, ma box a été déconnectée du réseau. Suffisant pour que la mesure de 3h30 saute.
Le mécanisme est reparti normalement à 3h40, si ce n'est que... toutes les mesures en IPv6 multithread échouent depuis. Uniquement IPv6 + multithread (c'est OK pour IPv6 monothread et pour IPv4 multithread) :o
Je précise que ça touche aussi bien le download que l'upload.
Le symptôme : la commande iperf3 ne produit pas de retour dans le temps habituellement imparti de 15s.
Je précise que, bien évidemment, je n'ai absolument pas touché au code, ni effectué aucune autre manip.
Si vous avez des idées sur la cause, et donc potentiellement une solution, je suis preneur, parce que là... :-\
EDIT -- TENTATIVES
9h20 : j'ai poussé le timeout à 20s, ça ne change rien. J'ai joué sur des changements de port, ça ne change rien non plus.
10h23 : reboot à distance de la box. Mesures de 10h30 : aucune amélioration ; même situation.
(sachant que jusqu'en fin d'après-midi, je suis à distance, et n'ai pas tous les accès pour effectuer des tests)
-
Là c'est mystérieux, mais la solutions permettra peut-être de comprendre les problèmes que tu as eu.
Cela serait possible d'avoir le retour complet donné par iPerf3 ?
Cela pourrait être une option du script d'archiver les retours (fichier en local portant la date et l'heure précise du test), de façon à pourvoir analyser un problème.
Au passage, je pense que cela serait intéressant de partager le script que tu as crée, pour que d'autres puissent l'utiliser.
Coté serveur de Paris, le graphique du débit utilisé est stable, autour de 1 Gb/s la nuit dernière.
Je note toutefois nombreuses requêtes entre 21h00 et 23h00 sur Apache (requête de petite taille).
Il y a également eu une sorte de slow DDOS entre 12h00 et 19h30 avec des connexions TCP ouvertes jusqu'au timeout sur Apache.
-
J'ai pu rajouter des logs.
Voici ce que j'ai à chaque fois (sortie intégrale de la commande iperf3 habituelle, coupée à 15s) :
Download
Connecting to host bouygues.testdebit.info, port 9212
Reverse mode, remote host bouygues.testdebit.info is sending
[ 5] local 2a01:e0a:1fc:xxx port 57196 connected to 2001:860:deff:1000::2 port 9212
[ 7] local 2a01:e0a:1fc:xxx port 57204 connected to 2001:860:deff:1000::2 port 9212
[ 9] local 2a01:e0a:1fc:xxx port 57212 connected to 2001:860:deff:1000::2 port 9212
[ ID] Interval Transfer Bitrate
[ 5] 0.00-1582113108.17 sec 0.00 Bytes 0.00 Gbits/sec
[ 7] 0.00-1582113108.17 sec 0.00 Bytes 0.00 Gbits/sec
[ 9] 0.00-1582113108.17 sec 0.00 Bytes 0.00 Gbits/sec
[SUM] 0.00-1582113108.17 sec 0.00 Bytes 0.00 Gbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate
[ 5] 0.00-1582113108.17 sec 0.00 Bytes 0.00 Gbits/sec sender
[ 5] 0.00-1582113108.17 sec 0.00 Bytes 0.00 Gbits/sec receiver
[ 7] 0.00-1582113108.17 sec 0.00 Bytes 0.00 Gbits/sec sender
[ 7] 0.00-1582113108.17 sec 0.00 Bytes 0.00 Gbits/sec receiver
[ 9] 0.00-1582113108.17 sec 0.00 Bytes 0.00 Gbits/sec sender
[ 9] 0.00-1582113108.17 sec 0.00 Bytes 0.00 Gbits/sec receiver
[SUM] 0.00-1582113108.17 sec 0.00 Bytes 0.00 Gbits/sec sender
[SUM] 0.00-1582113108.17 sec 0.00 Bytes 0.00 Gbits/sec receiver
Upload
Connecting to host bouygues.testdebit.info, port 9212
[ 5] local 2a01:e0a:1fc:xxx port 57350 connected to 2001:860:deff:1000::2 port 9212
[ 7] local 2a01:e0a:1fc:xxx port 57358 connected to 2001:860:deff:1000::2 port 9212
[ 9] local 2a01:e0a:1fc:xxx port 57366 connected to 2001:860:deff:1000::2 port 9212
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1582113158.23 sec 0.00 Bytes 0.00 Mbits/sec 2 5.58 KBytes
[ 7] 0.00-1582113158.23 sec 0.00 Bytes 0.00 Mbits/sec 2 5.58 KBytes
[ 9] 0.00-1582113158.23 sec 0.00 Bytes 0.00 Mbits/sec 2 5.58 KBytes
[SUM] 0.00-1582113158.23 sec 0.00 Bytes 0.00 Mbits/sec 6
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-1582113158.23 sec 0.00 Bytes 0.00 Mbits/sec 2 sender
[ 5] 0.00-1582113158.23 sec 0.00 Bytes 0.00 Mbits/sec receiver
[ 7] 0.00-1582113158.23 sec 0.00 Bytes 0.00 Mbits/sec 2 sender
[ 7] 0.00-1582113158.23 sec 0.00 Bytes 0.00 Mbits/sec receiver
[ 9] 0.00-1582113158.23 sec 0.00 Bytes 0.00 Mbits/sec 2 sender
[ 9] 0.00-1582113158.23 sec 0.00 Bytes 0.00 Mbits/sec receiver
[SUM] 0.00-1582113158.23 sec 0.00 Bytes 0.00 Mbits/sec 6 sender
[SUM] 0.00-1582113158.23 sec 0.00 Bytes 0.00 Mbits/sec receiver
-
Donc le process iPerf semble bien fonctionner.
Cela serait bien de faire une capture wireshark pour comprendre ce qu'il se passe.
-
Suggestion : cela donne quoi vers un autre serveur ?
(un iPerf3 lancé à la main si tu te connecte en SSH est suffisant)
-
J'étais en train de faire plusieurs fois des tests à la main.
- Sur Lille, IPv6 ne fonctionnait pas du tout, alors qu'IPv4 est OK.
- Sur Paris, j'ai reproduit le comportement évoqué jusqu'à présent, puis au bout de plusieurs tentatives, j'ai réussi un multithread, mais il était lent à réagir, très lent. Toujours aucun problème en IPv4.
Je penche pour un souci (côté Free ?) sur l'IPv6. A confirmer dans les heures à venir.
EDIT : à l'instant : je ping paris.xxx en IPv6, mais pas lille.xxx ; en IPv4, tous les pings sont OK
-
Bah voilà, en passant le timeout à 60s (* 4), ça passe, je retrouve tous mes résultats, avec des valeurs conformes à l'attendu (mesures "normales").
On est bien sur un souci de grosse lenteur (latence) du test en multithread IPv6.
-
EDIT : à l'instant : je ping paris.xxx en IPv6, mais pas lille.xxx ; en IPv4, tous les pings sont OK
Étonnant. Je ne note pas de pb, c'est toujours le cas ?
$ mtr -rwc100 lille.testdebit.info
Start: Wed Feb 19 15:58:23 2020
HOST: lafibre Loss% Snt Last Avg Best Wrst StDev
1.|-- bgp1.adeli.biz 0.0% 100 0.3 53.1 0.2 2651. 326.6
2.|-- 6-1-18.ear1.Paris1.Level3.net 0.0% 100 15.2 20.6 14.9 450.4 43.5
3.|-- lo-0-v6.ear3.Paris1.Level3.net 0.0% 100 14.7 14.8 14.6 15.5 0.0
4.|-- 2001:1900:5:2:2::4a52 0.0% 100 7.7 7.7 7.6 8.1 0.0
5.|-- 2001:860:bbee:42::2 0.0% 100 11.0 11.1 11.0 11.4 0.0
6.|-- 2001:860:bbe0:af::2 0.0% 100 11.4 11.5 11.4 11.7 0.0
7.|-- 2001:860:b212::3:2 0.0% 100 11.6 11.6 11.5 11.8 0.0
8.|-- 2001:860:de12:200::2 0.0% 100 10.9 10.9 10.8 11.0 0.0
$ mtr -rwc100 lille.testdebit.info
Start: Wed Feb 19 17:53:02 2020
HOST: lafibre Loss% Snt Last Avg Best Wrst StDev
1.|-- bgp1.adeli.biz 0.0% 100 0.3 111.3 0.2 2717. 472.0
2.|-- 6-1-18.ear1.Paris1.Level3.net 0.0% 100 15.1 18.1 14.9 218.5 20.5
3.|-- lo-0-v6.ear3.Paris1.Level3.net 0.0% 100 14.8 14.8 14.7 15.4 0.0
4.|-- 2001:1900:5:2:2::4a52 0.0% 100 7.6 7.6 7.5 8.1 0.0
5.|-- 2001:860:bbee:42::2 0.0% 100 11.1 11.1 11.0 11.6 0.0
6.|-- 2001:860:bbe0:af::2 0.0% 100 11.5 11.5 11.4 11.7 0.0
7.|-- 2001:860:b212::3:2 0.0% 100 11.6 11.6 11.5 11.8 0.0
8.|-- 2001:860:de12:200::2 0.0% 100 10.9 10.9 10.8 11.0 0.0
-
Oui, toujours.
Pas de problème pour paris.xxx mais pas de retour pour lille.xxxx
EDIT : revenu !
-
Bon, c'est clairement un problème de la VM Linux.
Depuis le mac, je ping les 2 IPv6 sans souci.
Depuis la VM, ça pingait sur paris mais pas sur Lille.
J'ai désactivé / réactivé la connexion réseau, et là ça ping sur Lille (d'où mon "revenu !"), mais plus sur Paris (sic).
Je deviens fou. Je vais me changer les idées... ::)
EDIT: j'ai refait des tests à tête reposée sur la VM: je confirme bien que ça ping sur lille, mais pas paris... et les tests iperf3, eux, tournent.
-
Je suis toujours en train de modifier mes scripts pour tester et ainsi comparer les algos de gestion de la congestion TCP.
@Vivien
A ce jour, quels sont les algos qui peuvent être spécifiés ?
cubic et bbr, j'ai fait lors de tests, c'est OK. A part ça ? illinois, toujours pas ? reno, autre ?
Je suis également toujours preneur, en préalable, de paramètres de la stack TCP à injecter avant de lancer les mesures enregistrées (sysctl.conf...).
Merci.
-
Je suis toujours en train de modifier mes scripts pour tester et ainsi comparer les algos de gestion de la congestion TCP.
@Vivien
A ce jour, quels sont les algos qui peuvent être spécifiés ?
cubic et bbr, j'ai fait lors de tests, c'est OK. A part ça ? illinois, toujours pas ? reno, autre ?
Je suis également toujours preneur, en préalable, de paramètres de la stack TCP à injecter avant de lancer les mesures enregistrées (sysctl.conf...).
Merci.
En fait c'est toi qui congestionne le reseau! :o
-
Et ouai, à moi seul, je fais tomber Free... 8)
-
Seul reno cubic bbr sont disponibles.
Pour avoir plus il faut trouver l'origine de mon problème :
$ 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
# 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.
Optimisations réseau et swappiness :
nano /etc/sysctl.d/90-server-optimization.conf
# Reduce the swap
vm.swappiness = 1
# Disable the memorization of previous tests, in order to avoid that the server burns the tests following a limited performance
net.ipv4.tcp_no_metrics_save=1
# Increase TCP buffers
net.ipv4.tcp_rmem=4096 131072 16777216
net.ipv4.tcp_wmem=4096 87380 16777216
net.core.rmem_max=16777216
net.core.wmem_max=16777216
# Increase the queue within the Linux kernel where traffic is stored after reception from the NIC
net.core.netdev_max_backlog=4000
# Reduce the threshold where a DDOS impacts the server
net.ipv4.tcp_max_syn_backlog = 4096
# Increase number of incoming connections
net.core.somaxconn = 512
Voici la configuration mise en place sur mes serveurs :
nano /etc/modules-load.d/tcp_allowed_congestion_control.conf
# TCP congestion control protocol
# cat /proc/sys/net/ipv4/tcp_allowed_congestion_control
tcp_bbr
-
Bonjour
Je m'intéresse aussi au sujet BBR et si je peux émettre un avis c'est que tester dans dans conditions "trop clean" ne montrera pas l'impact de tel ou tel protocole de congestion sur un autre.
Pour voir un impact
- Refaire le test sur un serveur lointain - voir très lointain (US par ex).
- Ou injecter de la perte de paquet (0,5% ou 1% suffit) pendant le test (en UL avec Netem par exemple).
La diff entre BBR et les autres sera énorme.
-
Bonsoir,
Voici comme promis un graphique comparant les débits en téléchargement Cubic / BBR, en monothread / multithread, sur une semaine de mesures.
(https://lafibre.info/images/free_debit/202002_comparatif_bbr_cubic_big.png)
-
Merci, c'est très impressionnant.
C'est du beau travail.
C'est uniquement de l'IPv6 ou uniquement de l'IPv4 ?
La configuration n'a pas changé, excepté le passage à 8 Go sur la VM ?
Client : VM sur ESXi 4vCPU sur un Core i7-10710U @1.1 GHz avec 8 Go de ram (sur 32 Go de l’hôte)
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.
OS invité : Ubuntu 19.10 (Kernel Linux 5.3) et iPerf 3.6
A noter que les opérateurs vont être consultés prochainement sur le choix de l'algorithme de congestion TCP pour la campagne de test Arcep mobile 2020 (le résultats de la campagne 2019 est sur https://www.monreseaumobile.fr/ )
On est nombreux à pouvoir te remercier, je sais que au vu de tes résultats, certains opérateurs ont lancé des campagnes de test.
Tu partagerais tes scripts de mesure et de génération du graphique ?
-
C'est uniquement de l'IPv6 ou uniquement de l'IPv4 ?
Uniquement de l'IPv6 (cf. fin du titre du graphique).
De toute façon, a priori, ce serait similaire en IPv4, avec un débit légèrement moindre en général.
La configuration n'a pas changé, excepté le passage à 8 Go sur la VM ?
Il y a eu un changement par rapport à ce tu reprends: iPerf passé en 3.7 (cf. 1er post).
Par ailleurs, je corrige un truc: depuis le début, c'est un ESXi 6.7u3 et non u2.
A noter que les opérateurs vont être consultés prochainement sur le choix de l'algorithme de congestion TCP pour la campagne de test Arcep mobile 2020 (le résultats de la campagne 2019 est sur https://www.monreseaumobile.fr/ )
On est nombreux à pouvoir te remercier, je sais que au vu de tes résultats, certains opérateurs ont lancé des campagnes de test.
Content si ça peut faire avancer le schmilblick (et prêt à d'autres tests, dans la limite de mes compétences...) ;)
Ce serait bien si les OS comme Windows ou MacOS pouvaient intégrer l'algorithme BBR (que ce soit la version 1 ici testée, ou la proche version 2, a priori un peu moins forte en débit, mais moins agressive sur les retries).
Et j'aimerais aussi comprendre pourquoi, que ce soit sous Windows ou dans une moindre mesure MacOS, je suis assez en dessous des résultats obtenus sous Linux, et comment améliorer cela...
Tu partagerais tes scripts de mesure et de génération du graphique ?
Oui, ça pourrait le faire, mais il me faut régler quelques détails et je ne suis pas spécialiste Shell/bash, donc indulgence avec ma façon de coder (surtout que le script a évolué en fonction des orientations prises, il n'a pas été pensé totalement générique depuis le début) !
-
Uniquement de l'IPv6 (cf. fin du titre du graphique).
De toute façon, a priori, ce serait similaire en IPv4, avec un débit légèrement moindre en général.
Il y a eu un changement par rapport à ce tu reprends: iPerf passé en 3.7 (cf. 1er post).
Par ailleurs, je corrige un truc: depuis le début, c'est un ESXi 6.7u3 et non u2.
Content si ça peut faire avancer le schmilblick (et prêt à d'autres tests, dans la limite de mes compétences...) ;)
Ce serait bien si les OS comme Windows ou MacOS pouvaient intégrer l'algorithme BBR (que ce soit la version 1 ici testée, ou la proche version 2, a priori un peu moins forte en débit, mais moins agressive sur les retries).
Et j'aimerais aussi comprendre pourquoi, que ce soit sous Windows ou dans une moindre mesure MacOS, je suis assez en dessous des résultats obtenus sous Linux, et comment améliorer cela...
Oui, ça pourrait le faire, mais il me faut régler quelques détails et je ne suis pas spécialiste Shell/bash, donc indulgence avec ma façon de coder (surtout que le script a évolué en fonction des orientations prises, il n'a pas été pensé totalement générique depuis le début) !
Salut Breizh29, j'ai installé une VM Debian 10 Buster sur mon ESXi 6.7u3, je serai intéressé par ton script si tu es d'accord de le partager, afin de voir si mon débit est proche du tien dans les mêmes conditions.
-
Je prépare ça et je te fais signe.
-
Graphique mise en forme pour être plus lisible sur ceux qui ont de faibles résolution d'écran :
(https://lafibre.info/images/free_debit/202002_comparatif_bbr_cubic.png)
-
Vivien, ces tests comparatifs ont été réalisés sur Lille.testdebit.info comme tu le suggérais (contrairement aux précédents, faits sur paris.testdebit.info)
-
J'ai mis à jour le graphique.
Si vous voyez afficher "paris.testdebit.info" comme mire, c'est qu'il faut vider le cache de votre navigateur.
-
Hello,
J'ai également mis en place de mon côté des tests automatisés; je communiquerai ici les résultats après quelques heures de fonctionnement.
@Vivien, j'ai également pris lille comme serveur iPerf, tu penses que ça va tenir?
-
Oui, si il n'y a pas deux tests en simultané à 8 Gb/s.
Idéalement il faudrait upgrder le serveur pour être sur qu'il ne limite pas le débit. J'esère que cela sera lancé quand Bouygues Telecom lancera une offre à 10 Gb/s.
Un serveur Scaleway à 10 Gb/s arrive dans les prochains jours. Il sera par défaut avec l'algorithme de congestion TCP BBR.
-
Tu as lancé à quelle heure ?
Déjà je verrai si mes stats se cassent la figure ;)
Je me suis mis sur les 00 / 10 / 20 / ...
Si tu te mets sur les 05 / 15 /25 / ... , on limitera le risque. Sinon, passer sur Bordeaux, Aix, voire Paris (il tenait bien, même quand j'y étais !)
Ps: en tout cas, entre 12h et 12h30, je suis quasiment au taquet à 7,98 Gbits/s
-
Un serveur Scaleway à 10 Gb/s arrive dans les prochains jours. Il sera par défaut avec l'algorithme de congestion TCP BBR.
Public ?
Mis à dispo par Online ? / Loué par tes soins / l’arcep ?
-
Serveur public, grâce aux bonnes relations de @elkaimelie
Ce sera par contre une grosse VM qui utilise Proxmox que je pourrais utiliser, une solution de virtualisation libre basée sur l'hyperviseur Linux KVM.
Il sera intéressant de voir si Proxmox ne dégrade pas les performances.
J'ai eu une mauvaise expérience avec VMWare il y a quelques années, ce qui explique que les autres serveurs que j'exploite je n'ai pas de virtualisation.
-
Pour le moment j'ai quelques résultats de cet ordre là:
7,67G 4,28G 570M 569M
4,36G 4,03G 572M 548M
2,45G 3,87G 557M 564M
3,67G 3,71G 550M 550M
2,39G 3,25G 569M 498M
2,05G 3,41G 570M 566M
J'ai mis un Observium dessus, pour avoir des moyennes de débits en + des graph GNUplot.
-
Par contre j'ai mis un crontab toutes les 5 minutes, mais j'ignore le temps que met le script à faire les tests...
-
Rester à 10 minutes serait mieux...
Cela dépend du délai de réponse du serveur (il peut tomber en timeout avant de retenter), de la durée des sleep (je me suis aperçu que j'avais oublié d'en enlever suite à factorisation de code).
Bref, de 5s en 5s, au final, ça peut durer 3/4 minutes.
Donc toutes les 10 minutes, c'est suffisant à mon avis.
Et comme je le disais, plutôt 5 / 15 / 25 / 35 / 45 / 55 de chaque heure (ou changer de serveur).
PS: bon, sinon côté résultat, ce n'est pas très stable. Mais tu as quand même atteint les 7,67 Gb/s, ce qui tend à prouver que ta ligne (physiquement) ou ton installation ne sont pas en cause.
-
J'ai update ma crontab; je verrais pour changer de serveur si je pollue tes résultats.
-
Je conseille même 20 minutes (3 tests par heure) si possible lancé aléatoirement dans le créneau de 20 minutes.
Exemple de lancement qui lance un test aléatoirement entre la première minute (60sec) car souvent plus chargée et la 18ème minute (1020+60 seconde) :
*/20 * * * * sleep $[ ( $RANDOM % 1020 ) + 60 ]s ; /home/script.sh >>/home/log/log.log 2>&1
Il est bon de ne pas dépasser 8 seconde par test, on a vu qu'on ne gagnait rien à faire plus long que ça (8 secondes dont 4 pour la montée en débit) :
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>
-
Voici la charge moyenne du serveur de Lille :
La montée Breizh29 la semaine 8, ce sont les tests de Breizh29.
-
J'ai re-changé ma crontab avec ton exemple Vivien; du coup wait & see les 1er résultats...
Déjà depuis fin de matinée je suis à + de 200 Go consommés...
-
Alors la crontab ne fonctionne plus...
*/20 * * * * iperf sleep $[ ( $RANDOM % 1020 ) + 60 ]s ; /srv/package-speediPerf-linux2/speediPerf-linux2.sh >>/srv/iperf.log 2>&1
Des idées?
-
Y'a un iperf qui traine en trop au début de la commande, non ?
(ça doit commencer par le sleep...)
*/20 * * * * sleep $[ ( $RANDOM % 1020 ) + 60 ]s ; /srv/package-speediPerf-linux2/speediPerf-linux2.sh >>/srv/iperf.log 2>&1
-
Ah oui lol j'avais même pas fait gaffe.
# iPerf3 every 10 mins
*/20 * * * * sleep $[ ( $RANDOM % 1020 ) + 60 ]s ; iperf /srv/package-speediPerf-linux2/speediPerf-linux2.sh >>/srv/iperf.log 2>&1Comme ça c'est mieux? Je veux lancer le .sh avec l'utilisateur iperf en fait
-
Dans la crontab, avec la commande crontab -e c'est celle de l'utilisateur actif.
Pou un autre utilisateur :
sudo nano /etc/cron.d/iperf
# iPerf3 every 10 mins
*/20 * * * * iperf sleep $[ ( $RANDOM % 1020 ) + 60 ]s ; iperf /srv/package-speediPerf-linux2/speediPerf-linux2.sh >>/srv/iperf.log 2>&1
(là il faut bien rajouter iperf devant)
-
J'ai appliqué me crontab que tu m'as indiqué Vivien, mais je n'ai pas de résultat.
Le script ne se lance pas.
Je n'arrive qu'à le faire fonctionner via /etc/crontab:
# iPerf3 every 10 mins
*/10 * * * * iperf /srv/package-speediPerf-linux2/speediPerf-linux2.sh >>/srv/iperf.log 2>&1
Je ne comprend pas trop
-
Droits +x pour l'user iperf ?
Des variables ENV utilisés dans le .sh ?
-
Tu as pensé à redémarrer pour prendre en compte la présence du script dans /etc/cron.d/ ?
-
Droits +x pour l'user iperf ?
Des variables ENV utilisés dans le .sh ?
J'ai bien appliqué les droits nécessaires à l'utilisateur iperf.
Tu as pensé à redémarrer pour prendre en compte la présence du script dans /etc/cron.d/ ?
... Non, bon je fais ça, merci ! ;D
-
Hello,
Je post ici des résultats intermédiaires sur la semaine.
Je trouve que les graphs parlent d'eux même ^^
-
Intéressant les données d'upload.
En download, cela a baissé, tu sais pourquoi ?
-
En upload, j’ai la même chose à peu près il me semble (je n’ai pas publié les graphiques).
Ce qui m’étonne en down, c’est la quasi absence de différence entre mono et multi en bbr.
-
L'upload est très constant, RAS
Par contre les chutes de débit correspondent au soir, à chaque fois, pour remonter tranquillement dans la nuit...
J'ai moins de 1 Gbps en mono le soir...
-
Cela descend de plus en plus, surement à cause du télétravail.
-
A défaut de t’aider pour ton débit, tu feras involontairement une étude de l’impact du covid-19 sur la bande passante de Free ;D
+ Qui de BBR ou Cubic s’en sort le mieux ? ;)
-
Je pense arrêter les tests demain matin.
On reprendra + tard...
-
Oui, si il n'y a pas deux tests en simultané à 8 Gb/s.
Idéalement il faudrait upgrder le serveur pour être sur qu'il ne limite pas le débit. J'esère que cela sera lancé quand Bouygues Telecom lancera une offre à 10 Gb/s.
Un serveur Scaleway à 10 Gb/s arrive dans les prochains jours. Il sera par défaut avec l'algorithme de congestion TCP BBR.
Il est là : https://scaleway.testdebit.info/
Version IPv4 only : https://ipv4.scaleway.testdebit.info/
Version IPv6 only : https://ipv6.scaleway.testdebit.info/
Je suis preneur de vos retours ! C'est bien un serveur 10 Gb/s.
L’intérêt, par rapport aux différents serveurs 10 Gb/s de Bouygues Telecom, ce que l'on ne passe pas par le peering Free <=> Bouygues Telecom qui sature visiblement chaque soir.
Il écoute en http / https, du port TCP 1 au ports TCP 9199 avec des fichiers de toutes les tailles, de 1 octets jusqu’à 10 Go.
iPerf3, version 3.7, écoute sur les ports 9200 à 9222.
Pour windows / MacOS où il n'est pas possible de sélectionner l'algorithme de congestion TCP, c'est BBR qui est utilisé sur ce serveur par défaut.
Sous Linux, il est possible de forcer Cubic avec l'option --congestion=cubic
Exemple :
iperf3 -c scaleway.testdebit.info -p 9222 -R -V --congestion=cubic
Les changements par rapport aux serveurs Bouygues Telecom sont très limités :
- Ce n'est pas un serveur physique, mais une VM Ubuntu 18.04 avec Kernel HWE avec un hote Proxmox. Elle a 8 vCPU et 16 Go de RAM. Chez Bouygues c'est du dédié (même OS, même configuration soft)
- BBR est par défaut Cubic en option (c'est l'inverse sur les différents servuers Bouygues Telecom)
- Le script de lancement d'iPerf3 tue iPerf3 est le nouveau avec systemd : iPerf3 est relancé après chaque test. (merci kgersen, ce sera mis en place chez Bouygues quand je supprime les ports iPerf3 legacy)
-
OK, c’est noté, on va voir ça...
-
Je ne sais pas si c'est la bonne période pour "saturer" nos 8G, autant préserver la BP pour les télétravailleurs?
Qu'en pensez-vous?
-
J'avais coupé dès le départ mes mesures.
Mais faire quelques tests ne changera rien, globalement. On pourra attendre pour réaliser des mesures régulières...
PS: on "sature" 8s par période de 10/20 minutes...
-
J'ai mis en place la nouvelle conf vers le serveur de Scaleway.
On verra la différence :)
(https://lafibre.info/images/free_debit/202003_comparatif_bbr_cubic_big.png)
-
Pour comparer avec Breizh29 : La plus grosse différence, c'est le débit BBR de Breizh29 est bien meilleur en multi-thread qu'en mono-thread.
Pour toi DamienC, il y a peu de différences, BBR est a peine meilleur en multi-connexion vs mono.
On confirme par contre le fait que BBR est vraiment bon comme algo de congestion TCP.
Bonsoir,
Voici comme promis un graphique comparant les débits en téléchargement Cubic / BBR, en monothread / multithread, sur une semaine de mesures.
(https://lafibre.info/images/free_debit/202002_comparatif_bbr_cubic_big.png)
-
Vu qu'ils sont dans le même département, c'est plus lié à une saturation locale pour DamienC ?
-
Bon, j'ai laissé tourner en soirée et nuit ; je coupe ce matin.
Premières impressions : moins haut que d'habitude en soirée (-1 Gb/s environ ; mais c'est peut-être dû à l'effet covid), et très très légèrement moins haut en nuit profonde (là, je ne pense pas qu'on puisse conclure quoi que ce soit).
Quelques chiffres :
19/03/2020 20:20:01 ; ; 6,44 ; ; 4,79 ; ; 582 ; ; 579
19/03/2020 20:30:01 ; ; 6,78 ; ; 5,33 ; ; 585 ; ; 579
19/03/2020 20:40:01 ; ; 6,55 ; ; 4,07 ; ; 588 ; ; 582
19/03/2020 20:50:01 ; ; 6,76 ; ; 4,83 ; ; 586 ; ; 579
19/03/2020 21:00:01 ; ; 6,33 ; ; 3,68 ; ; 589 ; ; 579
19/03/2020 21:10:01 ; ; 5,99 ; ; 4,49 ; ; 580 ; ; 579
19/03/2020 21:20:01 ; ; 6,12 ; ; 4,03 ; ; 589 ; ; 577
19/03/2020 21:30:01 ; ; 6,42 ; ; 4,13 ; ; 586 ; ; 585
19/03/2020 21:40:01 ; ; 6,47 ; ; 3,75 ; ; 582 ; ; 579
19/03/2020 21:50:01 ; ; 5,49 ; ; 4,30 ; ; 577 ; ; 577
19/03/2020 22:00:01 ; ; 6,08 ; ; 3,64 ; ; 585 ; ; 574
19/03/2020 22:10:01 ; ; 6,62 ; ; 4,87 ; ; 583 ; ; 579
19/03/2020 22:20:01 ; ; 6,06 ; ; 4,43 ; ; 583 ; ; 579
19/03/2020 22:30:01 ; ; 6,66 ; ; 4,97 ; ; 581 ; ; 579
19/03/2020 22:40:01 ; ; 6,32 ; ; 4,65 ; ; 579 ; ; 577
19/03/2020 22:50:01 ; ; 6,74 ; ; 4,13 ; ; 586 ; ; 574
19/03/2020 23:00:01 ; ; 6,14 ; ; 3,70 ; ; 581 ; ; 582
19/03/2020 23:10:01 ; ; 6,74 ; ; 3,23 ; ; 581 ; ; 577
19/03/2020 23:20:01 ; ; 6,82 ; ; 4,09 ; ; 573 ; ; 577
19/03/2020 23:30:02 ; ; 6,97 ; ; 5,58 ; ; 587 ; ; 579
19/03/2020 23:40:01 ; ; 6,75 ; ; 4,84 ; ; 580 ; ; 579
19/03/2020 23:50:01 ; ; 6,91 ; ; 3,74 ; ; 584 ; ; 579
20/03/2020 00:00:01 ; ; 6,87 ; ; 4,92 ; ; 580 ; ; 582
20/03/2020 00:10:01 ; ; 7,16 ; ; 5,93 ; ; 579 ; ; 579
20/03/2020 00:20:01 ; ; 7,22 ; ; 2,82 ; ; 584 ; ; 577
20/03/2020 00:30:01 ; ; 7,32 ; ; 6,38 ; ; 580 ; ; 577
20/03/2020 00:40:01 ; ; 7,24 ; ; 3,87 ; ; 581 ; ; 579
20/03/2020 00:50:01 ; ; 7,48 ; ; 6,26 ; ; 580 ; ; 577
20/03/2020 01:00:01 ; ; 7,52 ; ; 4,06 ; ; 585 ; ; 577
20/03/2020 01:10:01 ; ; 7,71 ; ; 6,65 ; ; 578 ; ; 579
20/03/2020 01:20:01 ; ; 7,49 ; ; 4,72 ; ; 586 ; ; 577
20/03/2020 01:30:01 ; ; 7,65 ; ; 6,19 ; ; 584 ; ; 577
20/03/2020 01:40:01 ; ; 7,72 ; ; 4,94 ; ; 583 ; ; 579
20/03/2020 01:50:01 ; ; 7,91 ; ; 6,29 ; ; 577 ; ; 577
20/03/2020 02:00:01 ; ; 7,88 ; ; 3,16 ; ; 581 ; ; 582
20/03/2020 02:10:01 ; ; 7,92 ; ; 6,67 ; ; 586 ; ; 577
20/03/2020 02:20:01 ; ; 7,84 ; ; 4,03 ; ; 583 ; ; 579
20/03/2020 02:30:01 ; ; 7,94 ; ; 3,76 ; ; 578 ; ; 579
20/03/2020 02:40:01 ; ; 7,83 ; ; 3,68 ; ; 584 ; ; 577
20/03/2020 02:50:01 ; ; 8,01 ; ; 6,78 ; ; 581 ; ; 579
20/03/2020 03:00:01 ; ; 7,15 ; ; 4,79 ; ; 585 ; ; 582
20/03/2020 03:10:01 ; ; 7,97 ; ; 6,50 ; ; 581 ; ; 577
20/03/2020 03:20:01 ; ; 7,92 ; ; 4,14 ; ; 589 ; ; 579
20/03/2020 03:30:01 ; ; 7,91 ; ; 6,43 ; ; 583 ; ; 577
20/03/2020 03:40:01 ; ; 7,91 ; ; 4,95 ; ; 584 ; ; 577
20/03/2020 03:50:01 ; ; 7,87 ; ; 6,67 ; ; 585 ; ; 582
20/03/2020 04:00:01 ; ; 7,89 ; ; 3,91 ; ; 587 ; ; 577
20/03/2020 04:10:01 ; ; 7,94 ; ; 6,35 ; ; 578 ; ; 577
20/03/2020 04:20:01 ; ; 7,88 ; ; 4,93 ; ; 581 ; ; 574
20/03/2020 04:30:01 ; ; 7,93 ; ; 6,75 ; ; 585 ; ; 574
20/03/2020 04:40:01 ; ; 7,87 ; ; 4,05 ; ; 583 ; ; 574
20/03/2020 04:50:01 ; ; 7,98 ; ; 6,82 ; ; 582 ; ; 579
20/03/2020 05:00:01 ; ; 7,89 ; ; 4,51 ; ; 584 ; ; 579
20/03/2020 05:10:01 ; ; 7,97 ; ; 6,71 ; ; 587 ; ; 577
20/03/2020 05:20:01 ; ; 7,92 ; ; 4,06 ; ; 585 ; ; 585
20/03/2020 05:30:01 ; ; 7,92 ; ; 6,74 ; ; 585 ; ; 579
20/03/2020 05:40:01 ; ; 7,82 ; ; 3,83 ; ; 585 ; ; 574
20/03/2020 05:50:01 ; ; 7,96 ; ; 6,51 ; ; 581 ; ; 582
20/03/2020 06:00:01 ; ; 7,81 ; ; 3,68 ; ; 583 ; ; 577
20/03/2020 06:10:01 ; ; 7,91 ; ; 6,67 ; ; 582 ; ; 579
20/03/2020 06:20:01 ; ; 7,92 ; ; 3,89 ; ; 580 ; ; 574
20/03/2020 06:30:01 ; ; 7,99 ; ; 6,82 ; ; 585 ; ; 579
20/03/2020 06:40:01 ; ; 7,92 ; ; 3,95 ; ; 582 ; ; 577
20/03/2020 06:50:01 ; ; 7,76 ; ; 6,78 ; ; 578 ; ; 577
20/03/2020 07:00:01 ; ; 7,86 ; ; 6,33 ; ; 587 ; ; 582
20/03/2020 07:10:01 ; ; 7,86 ; ; 6,76 ; ; 584 ; ; 577
20/03/2020 07:20:01 ; ; 7,91 ; ; 5,09 ; ; 583 ; ; 574
20/03/2020 07:30:01 ; ; 7,95 ; ; 6,75 ; ; 582 ; ; 579
20/03/2020 07:40:01 ; ; 7,94 ; ; 5,11 ; ; 589 ; ; 577
20/03/2020 07:50:02 ; ; 8,00 ; ; 6,84 ; ; 584 ; ; 579
20/03/2020 08:00:02 ; ; 7,81 ; ; 4,14 ; ; 586 ; ; 577
-
De mon côté j'observe une amélioration:
20/03/2020 00:40:01 ; ; 6,17 ; ; 3,15 ; ; 574 ; ; 569
20/03/2020 01:00:01 ; ; 6,42 ; ; 3,39 ; ; 575 ; ; 571
20/03/2020 01:20:01 ; ; 6,48 ; ; 3,82 ; ; 573 ; ; 571
20/03/2020 01:40:01 ; ; 6,74 ; ; 3,84 ; ; 574 ; ; 571
20/03/2020 02:00:01 ; ; 6,90 ; ; 4,09 ; ; 573 ; ; 569
20/03/2020 02:20:01 ; ; 6,82 ; ; 4,11 ; ; 576 ; ; 571
20/03/2020 02:40:01 ; ; 7,08 ; ; 3,94 ; ; 576 ; ; 569
20/03/2020 03:00:01 ; ; 7,34 ; ; 4,24 ; ; 576 ; ; 569
20/03/2020 03:20:01 ; ; 7,53 ; ; 4,95 ; ; 574 ; ; 569
20/03/2020 03:40:01 ; ; 7,47 ; ; 4,31 ; ; 578 ; ; 566
20/03/2020 04:00:01 ; ; 7,37 ; ; 5,14 ; ; 578 ; ; 569
20/03/2020 04:20:01 ; ; 7,60 ; ; 5,73 ; ; 575 ; ; 569
20/03/2020 04:40:01 ; ; 7,36 ; ; 5,20 ; ; 575 ; ; 569
20/03/2020 05:00:01 ; ; 7,43 ; ; 5,92 ; ; 574 ; ; 569
20/03/2020 05:20:01 ; ; 7,04 ; ; 5,70 ; ; 575 ; ; 569
20/03/2020 05:40:01 ; ; 6,77 ; ; 5,35 ; ; 576 ; ; 571
20/03/2020 06:00:01 ; ; 7,55 ; ; 5,10 ; ; 577 ; ; 571
20/03/2020 06:20:01 ; ; 7,21 ; ; 5,74 ; ; 574 ; ; 569
20/03/2020 06:40:01 ; ; 7,38 ; ; 5,51 ; ; 574 ; ; 569
20/03/2020 07:00:02 ; ; 7,57 ; ; 5,95 ; ; 575 ; ; 571
20/03/2020 07:20:01 ; ; 7,30 ; ; 5,11 ; ; 577 ; ; 571
20/03/2020 07:40:01 ; ; 7,31 ; ; 4,74 ; ; 580 ; ; 569
20/03/2020 08:00:01 ; ; 7,47 ; ; 4,18 ; ; 575 ; ; 569
20/03/2020 08:20:01 ; ; 6,80 ; ; 3,88 ; ; 574 ; ; 571
20/03/2020 08:40:01 ; ; 6,52 ; ; 3,53 ; ; 575 ; ; 566
20/03/2020 09:00:01 ; ; 6,28 ; ; 3,08 ; ; 574 ; ; 569
-
Hello, je post ici l'évolution depuis le passage du serveur iPerf de Lille (interco Bouygues) vers celui de Scaleway (interco Free).
C'est bien mieux, mais pas encore au maximum. Je me demande si ma configuration n'est pas en cause...
-
Breizh29, voici un nouveau serveur pour faire des tests Cubic / BBR avec ton Mac :
- Serveur Cubic : paris.testdebit.info
- Serveur BBR : paris-bbr.testdebit.info
Les deux serveurs sont tous les deux à Nanterre sur le réseau Bouygues Telecom.
La configuration hardware et software est identique excepté BBR / Cubic.
Ils écoutent tous les deux avec iPerf3.7 sur les ports 9200 à 9222.
-
OK, je verrai ça quand j'aurai davantage de temps.
Idéalement, il me faut remettre à niveau la version macOS que j'avais laissée de côté lors du passage Linux + l'adapter (serveurs différents en fonction de l'algo) pour pouvoir faire un comparatif.
-
Hello,
Je poste le graphique pour cette période.
Je note une amélioration du débit sur le cubic mono
Sinon, pas mal de fluctuation, mais ça reste dans la norme j'ai envie de dire
-
Bonjour,
J'ai repris les tests depuis MacOS en utilisant les 2 serveurs paris et paris-bbr.
A première vue, on retrouve les mêmes comportements que lors des tests initiaux : MacOS semble, au moins en l'état de ma configuration TCP, ne pas être à l'aise avec bbr.
Les graphiques arriveront prochainement.
Je vais à nouveau chercher s'il y a moyen d'améliorer cela via le paramétrage de l'OS, mais je n'ai vu que peu d'éléments dans la littérature d'internet, jusqu'à présent...
-
C'est étonnant que sur une même connexion, le comportement est différents pour un flux descendant.
Les timestamps TCP sont bien activés avec MacOS ? (c'est un champ optionnel de TCP)
Les Timestamps permetent au serveur d'avoir une vue précise de la latence, et vu que BBR mise tout sur les variations de latence, (contre les pertes de paquets pour les autres protocoles de congestion TCP) sa désactivation pourrait réduire les débits.
-
Après un peu plus de 30h de tests, ce que j'observe (en DL IPv6) :
- En 1er, et avec de l'avance, multithread cubic
- En 2ème, quasi ex-aequo, monothread cubic et bbr
- En dernier, stable, mais bas : multithread bbr
Peut-être y a-t-il trop de parallélisme pour que MacOS gère bien tous les échanges bbr (retries...) ? Je pourrais essayer de baisser le niveau de 16 à 8 par exemple ?
En tout cas, bbr ne s'en sort pas mieux que cubic, même en monothread.
PS: @Vivien, pour ce qui est des timestamps, apparemment cela correspond à la rfc1323, et l'entrée correspondante (net.inet.tcp.rfc1323) n'est plus présente dans les dernières versions de MacOS (automatiquement activé désormais ?)
-
Au passage, il y a eu un retour de free concernant les lenteurs, surtout en up, si on n'est pas bbr ? De mémoire un bug avait été ouvert sur leur tracker, mais je ne le retrouve pas.
-
Le ticket : https://dev.freebox.fr/bugs/task/29953 mais rien n'a bougé depuis que le problème a prétendument été transmis au réseau.
-
Ah, merci bien.
-
En ce moment je pense qu'ils ont malheureusement autre chose à traiter :(.
J'essayerai de relancer quand la situation sera plus saine.
-
Dernier relevé MacOS page précédente à comparer avec celui ci-dessous, pour une période proche, sur Linux...
-
Voilà qui plie l'affaire :
https://dev.freebox.fr/bugs/task/29953
Autant dire que c'est fini pour nous...
Quand on appelle la hotline "non non tout va bien votre débit est conforme".
Foutage de gueule... >:(
Sans une entrée chez Free on n'arrivera jamais à faire prendre en charge ce problème.
-
Y'a jamais eu de vrai retour sur leurs décos optiques très fréquent parfois en zone non p2p, donc pour ce genre de problème... On est pas sorti...
-
Perso il me reste 4 mois d'engagement, je verrai après ce que je fais car je vais passer à 45 € au lieu de 20...
-
@Vivien :
Pour l'IPv4 c'est normal, comme je fais du dual WAN je passe par un routeur derrière la Freebox mais je n'ai pas de solution efficace aujourd'hui en IPv6 pour le multihoming donc dans l'immédiat je n'ai que de l'IPv4.
Certes Free fournit de l'IPv6 natif (et encapsule IPv4) mais ça ne change rien sur le débit.
Ci-dessous les tests en IPv6 puis en IPv4, en étant connecté directement sur la Freebox.
Les débits sont toujours merdiques, comme depuis le début... (Free ne veut rien faire, "tout est normal").
IPv6 (1 flux) :
Connecting to host bouygues.testdebit.info, port 5201
[ 4] local 2a01:e0a:2d... port 49773 connected to 2001:860:deff:1000::2 port 5201
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-1.01 sec 6.12 MBytes 51.0 Mbits/sec
[ 4] 1.01-2.00 sec 8.88 MBytes 75.0 Mbits/sec
[ 4] 2.00-3.00 sec 8.38 MBytes 70.3 Mbits/sec
[ 4] 3.00-4.00 sec 5.00 MBytes 41.9 Mbits/sec
[ 4] 4.00-5.00 sec 8.62 MBytes 72.4 Mbits/sec
[ 4] 5.00-6.00 sec 13.1 MBytes 110 Mbits/sec
[ 4] 6.00-7.01 sec 7.00 MBytes 58.4 Mbits/sec
[ 4] 7.01-8.01 sec 9.50 MBytes 80.0 Mbits/sec
[ 4] 8.01-9.00 sec 8.75 MBytes 73.8 Mbits/sec
[ 4] 9.00-10.00 sec 13.0 MBytes 109 Mbits/sec
[ 4] 10.00-11.01 sec 6.75 MBytes 55.9 Mbits/sec
[ 4] 11.01-12.01 sec 8.38 MBytes 70.7 Mbits/sec
[ 4] 12.01-13.01 sec 11.6 MBytes 96.8 Mbits/sec
[ 4] 13.01-14.00 sec 7.00 MBytes 59.6 Mbits/sec
[ 4] 14.00-15.01 sec 11.8 MBytes 97.8 Mbits/sec
[ 4] 15.01-16.01 sec 11.4 MBytes 94.8 Mbits/sec
[ 4] 16.01-17.00 sec 6.88 MBytes 58.3 Mbits/sec
[ 4] 17.00-18.00 sec 11.5 MBytes 96.7 Mbits/sec
[ 4] 18.00-19.00 sec 7.62 MBytes 64.0 Mbits/sec
[ 4] 19.00-20.00 sec 10.1 MBytes 84.9 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-20.00 sec 181 MBytes 76.1 Mbits/sec sender
[ 4] 0.00-20.00 sec 181 MBytes 76.1 Mbits/sec receiver
IPv6 2 flux :
[SUM] 0.00-20.01 sec 281 MBytes 118 Mbits/sec sender
[SUM] 0.00-20.01 sec 281 MBytes 118 Mbits/sec receiver
IPv6 4 flux :
[SUM] 0.00-20.00 sec 470 MBytes 197 Mbits/sec sender
[SUM] 0.00-20.00 sec 469 MBytes 197 Mbits/sec receiver
IPv6 8 flux :
[SUM] 0.00-20.01 sec 651 MBytes 273 Mbits/sec sender
[SUM] 0.00-20.01 sec 650 MBytes 273 Mbits/sec receiver
IPv6 16 flux :
[SUM] 0.00-20.00 sec 798 MBytes 335 Mbits/sec sender
[SUM] 0.00-20.00 sec 795 MBytes 334 Mbits/sec receiver
IPv4 (1 flux) :
Connecting to host bouygues.testdebit.info, port 5201
[ 4] local 192.168.200.22 port 49876 connected to 89.84.1.222 port 5201
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-1.01 sec 3.50 MBytes 29.1 Mbits/sec
[ 4] 1.01-2.00 sec 8.88 MBytes 75.1 Mbits/sec
[ 4] 2.00-3.00 sec 12.8 MBytes 107 Mbits/sec
[ 4] 3.00-4.00 sec 7.00 MBytes 58.9 Mbits/sec
[ 4] 4.00-5.01 sec 5.62 MBytes 46.7 Mbits/sec
[ 4] 5.01-6.01 sec 9.50 MBytes 80.1 Mbits/sec
[ 4] 6.01-7.01 sec 10.9 MBytes 91.5 Mbits/sec
[ 4] 7.01-8.01 sec 10.4 MBytes 86.2 Mbits/sec
[ 4] 8.01-9.00 sec 5.88 MBytes 50.0 Mbits/sec
[ 4] 9.00-10.00 sec 9.00 MBytes 75.4 Mbits/sec
[ 4] 10.00-11.01 sec 8.25 MBytes 68.8 Mbits/sec
[ 4] 11.01-12.00 sec 10.8 MBytes 90.7 Mbits/sec
[ 4] 12.00-13.01 sec 6.88 MBytes 57.1 Mbits/sec
[ 4] 13.01-14.01 sec 7.50 MBytes 63.0 Mbits/sec
[ 4] 14.01-15.01 sec 8.38 MBytes 70.4 Mbits/sec
[ 4] 15.01-16.01 sec 8.12 MBytes 68.3 Mbits/sec
[ 4] 16.01-17.00 sec 9.25 MBytes 77.8 Mbits/sec
[ 4] 17.00-18.01 sec 5.50 MBytes 45.9 Mbits/sec
[ 4] 18.01-19.01 sec 6.62 MBytes 55.6 Mbits/sec
[ 4] 19.01-20.00 sec 10.2 MBytes 86.2 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-20.00 sec 165 MBytes 69.1 Mbits/sec sender
[ 4] 0.00-20.00 sec 165 MBytes 69.1 Mbits/sec receiver
IPv4 2 flux :
[SUM] 0.00-20.01 sec 270 MBytes 113 Mbits/sec sender
[SUM] 0.00-20.01 sec 270 MBytes 113 Mbits/sec receiver
IPv4 4 flux :
[SUM] 0.00-20.01 sec 495 MBytes 207 Mbits/sec sender
[SUM] 0.00-20.01 sec 494 MBytes 207 Mbits/sec receiver
IPv4 8 flux :
[SUM] 0.00-20.00 sec 657 MBytes 276 Mbits/sec sender
[SUM] 0.00-20.00 sec 656 MBytes 275 Mbits/sec receiver
IPv4 16 flux :
[SUM] 0.00-20.00 sec 818 MBytes 343 Mbits/sec sender
[SUM] 0.00-20.00 sec 815 MBytes 342 Mbits/sec receiver
Edit : je viens de faire le test en bbr et c'est juste hallucinant... :o
Par contre sous Windows que ce soit en cubic, ctcp, dctcp ou newreno ça ne change strictement rien... débit de merde en upload. :-\
Je ne sais pas ce qu'on peut en conclure... Saturation chez Free ?
1 flux :
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-20.00 sec 1.17 GBytes 503 Mbits/sec 89401 sender
[ 5] 0.00-20.04 sec 1.17 GBytes 501 Mbits/sec receiver
2 flux :
[SUM] 0.00-20.00 sec 1.26 GBytes 542 Mbits/sec 122231 sender
[SUM] 0.00-20.03 sec 1.26 GBytes 539 Mbits/sec receiver
Pour les abonnés Free qui ont le même genre de désagréments n'hésitez-pas à voter ici : https://dev.freebox.fr/bugs/task/29953
J'ai refait ce soir quelques tests en Cubic par simple curiosité... et il semblerait qu'il se soit passé quelque chose chez Free pour moi !
Serveur bouygues.testdebit.info :
1 flux :
[ 5] 0.00-10.00 sec 326 MBytes 273 Mbits/sec 41 sender
[ 5] 0.00-10.04 sec 323 MBytes 270 Mbits/sec receiver
2 flux :
[SUM] 0.00-10.00 sec 479 MBytes 402 Mbits/sec 65 sender
[SUM] 0.00-10.02 sec 475 MBytes 397 Mbits/sec receiver
4 flux :
[SUM] 0.00-10.00 sec 500 MBytes 419 Mbits/sec 303 sender
[SUM] 0.00-10.01 sec 494 MBytes 414 Mbits/sec receiver
8 flux :
[SUM] 0.00-10.00 sec 586 MBytes 492 Mbits/sec 354 sender
[SUM] 0.00-10.01 sec 579 MBytes 485 Mbits/sec receiver
16 flux :
[SUM] 0.00-10.00 sec 627 MBytes 526 Mbits/sec 967 sender
[SUM] 0.00-10.01 sec 620 MBytes 519 Mbits/sec receiver
Serveur ping.online.net
1 flux :
[ 5] 0.00-10.00 sec 309 MBytes 259 Mbits/sec 135 sender
[ 5] 0.00-10.00 sec 306 MBytes 257 Mbits/sec receiver
2 flux :
[SUM] 0.00-10.00 sec 451 MBytes 379 Mbits/sec 200 sender
[SUM] 0.00-10.00 sec 447 MBytes 375 Mbits/sec receiver
4 flux :
[SUM] 0.00-10.00 sec 498 MBytes 418 Mbits/sec 256 sender
[SUM] 0.00-10.00 sec 493 MBytes 414 Mbits/sec receiver
8 flux :
[SUM] 0.00-10.00 sec 563 MBytes 472 Mbits/sec 554 sender
[SUM] 0.00-10.00 sec 556 MBytes 466 Mbits/sec receiver
16 flux :
[SUM] 0.00-10.00 sec 617 MBytes 517 Mbits/sec 1124 sender
[SUM] 0.00-10.00 sec 608 MBytes 510 Mbits/sec receiver
- Speedtest : 850 / 430 (moyenne sur 2 tests via 2 serveurs Massy + Orange).
- nPerf : 860 / 465 (moyenne sur 2 tests via 2 serveurs Orange + SFR)
- Envoi vers un VPS dont je dispose : 35 Mo/s en moyenne (contre 5-6 Mo/s avant !). Le même test en BBR donne du 48 Mo/s (contre 30-32 Mo/s avant).
On n'est toujours pas au niveau de BBR en Cubic mais ça ressemble clairement plus à ce que certains ont et surtout on voit que l'amélioration est globale, y compris en BBR !
Je ne sais pas ce qui a été fait ni même si c'est permanent mais la différence est juste énorme.
-
reponse de (Thibaut Freebox)
Bonjour
Ce n'est pas un problème logiciel, j'ai transmis au réseau.
Je ferme donc la tâche.
(ce type de remontée se fait directement au SAV : il faut préciser le problème et demander au conseiller de le transmettre à son support).
Cdt
a par changer le matos dans les PM je voit se qu'il pourrait faire d'autre ::)
-
Le problème pourrait avoir plein de causes, y compris logicielles.
-
a par changer le matos dans les PM je voit se qu'il pourrait faire d'autre ::)
Une mise à jour / changement de config de leurs équipements ?
-
Une mise à jour / changement de config de leurs équipements ?
Il n'y a pas eu de mise à jour de la Freebox (Revolution) depuis donc la réponse est sans doute là effectivement. :D
-
Peux être que ta collecte est moins saturée dans ton coin ?
-
Une saturation de collecte dans le sens montant c'est quand même un peu improbable...
-
Surtout que c'était constant quelle que soit l'heure...
Non clairement il y a eu quelque chose de fait côté Free y'a pas d'autres explications possibles.
-
Tiens, merci underground d'avoir remonté ce sujet sur un autre thread que je suis.
Je viens de faire des tests upload bbr/cubic et effectivement je remarque du bien mieux en cubic vs il y a quelques jours à peine.
Maintenant je depasse les 400Mbps en cubic (toujours environ 600Mbps en bbr) sur un thread.
Par contre j'ai plus de retry en cubic maintenant.
Du coup je ne sais pas si c'est lié à une modif chez Free, ou un petit tweak sur l'algo cubic sur le nouveau kernel 5.5 de mon serveur (reboot il y a peu qui fait passer le kernel de 5.4 à 5.5).
-
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).
(https://lafibre.info/images/free_debit/202001_comparatif_bubic_bbr_1.png)
(https://lafibre.info/images/free_debit/202001_comparatif_bubic_bbr_2.png)
(https://lafibre.info/images/free_debit/202001_comparatif_bubic_bbr_3.png)
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 :
(https://lafibre.info/images/free_debit/202001_free_tests_debit_multithread.png)
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
(https://lafibre.info/images/free_debit/202001_free_tests_debit_1_thread.png)
(https://lafibre.info/images/free_debit/202001_free_tests_debit_16_thread.png)
(https://lafibre.info/images/free_debit/202001_free_tests_debit_1et16_thread.png)
- 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é client
La 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).
Passer 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
(https://lafibre.info/images/free_debit/202002_comparatif_cubic_bbr_1.png)
(https://lafibre.info/images/free_debit/202002_comparatif_cubic_bbr_2.png)
Hello,
Très intéressant tes tests, alors globalement, tu obtiens de meilleurs débits en ipv4 ou ipv6 ?
J'utilise une Delta S que je souhaite mettre en mode bridge en IPv4 Full Stack avec un routeur pfSense, la box et le routeur sont raccordés en fibre 10gbit (monomode SC/APC), les PC sont raccordés au routeur via un switch.
WAN <------> Freebox Delta S (ipv4 f/stack) <--------> Routeur <----> Switch <-------> PCs
Dois-je modifier/activer les Jumbo frames pour avoir un mtu de 16000 ? ou est-ce inutile ? si oui, dois-je modifier le MTU sur le routeur, les switch, et les PCs ?
Merci.