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

Breizh29 · « **Réponse #48 le:** 09 janvier 2020 à 23:03:33 »

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.

kgersen · « **Réponse #49 le:** 09 janvier 2020 à 23:27:20 »

Citation de: Breizh29 le 09 janvier 2020 à 23:03:33

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.

kgersen · « **Réponse #50 le:** 10 janvier 2020 à 01:25:41 »

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:

Code: [Sélectionner]

goben -hosts pox-4.nspeed.app -passiveClient

test download en IPv6 :

Code: [Sélectionner]

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

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.

Breizh29 · « **Réponse #51 le:** 10 janvier 2020 à 08:31:19 »

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...

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

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)

Breizh29 · « **Réponse #53 le:** 10 janvier 2020 à 09:25:22 »

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 !

Sans doute plus de données jusqu'à ce soir.

esver · « **Réponse #54 le:** 10 janvier 2020 à 11:03:48 »

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) :

Code: [Sélectionner]

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

kgersen · « **Réponse #55 le:** 10 janvier 2020 à 12:38:19 »

Citation de: Breizh29 le 10 janvier 2020 à 08:31:19

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 ...

Breizh29 · « **Réponse #56 le:** 10 janvier 2020 à 12:45:33 »

Citation de: kgersen le 10 janvier 2020 à 12:38:19

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 · « **Réponse #57 le:** 10 janvier 2020 à 13:13:52 »

Citation de: kgersen le 10 janvier 2020 à 12:38:19

@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.

kgersen · « **Réponse #58 le:** 10 janvier 2020 à 13:19:58 »

Citation de: esver le 10 janvier 2020 à 13:13:52

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

esver · « **Réponse #59 le:** 10 janvier 2020 à 13:27:07 »

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.