Auteur Sujet: Debit limité à 250Mbps par session TCP en CUBIC ? (Lu 2460 fois)

hwti · « **le:** 17 juin 2022 à 11:42:07 »

Sur bouygues.testdebit.info (CUBIC), je ne dépasse pas 30Mo/s sur une session TCP.
Même chose pour ping.online.net (CUBIC).

Sur paris.testdebit.info (BBR), scaleway.testdebit.info (BBR), appliwave.testdebit.info (BBR), aucun soucis.

Code: [Sélectionner]

     Job|       Read| Write| Time|target
   Job 0| 237.8 Mbps| 0 bps| 8.00|get http://bouygues.testdebit.info/1G.iso
 Average| 237.8 Mbps| 0 bps| 8.00|

Code: [Sélectionner]

     Job|       Read| Write| Time|target
   Job 0| 249.2 Mbps| 0 bps| 8.00|get http://bouygues.testdebit.info/1G.iso
   Job 1| 228.9 Mbps| 0 bps| 8.00|get http://bouygues.testdebit.info/1G.iso
   Job 2| 201.1 Mbps| 0 bps| 8.00|get http://bouygues.testdebit.info/1G.iso
   Job 3| 252.2 Mbps| 0 bps| 8.00|get http://bouygues.testdebit.info/1G.iso
 Average| 931.4 Mbps| 0 bps| 8.00|

iperf sur le serveur BBR :

Code: [Sélectionner]

~  ᐅ iperf3 -c paris.testdebit.info -p 9200 -R
Connecting to host paris.testdebit.info, port 9200
Reverse mode, remote host paris.testdebit.info is sending
[  5] local 2a01:cb00:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx port 37752 connected to 2001:860:de01:1101::2 port 9200
[ ID] Interval           Transfer     Bitrate
[  5]   0.00-1.00   sec   107 MBytes   898 Mbits/sec                  
[  5]   1.00-2.00   sec   111 MBytes   928 Mbits/sec                  
[  5]   2.00-3.00   sec   111 MBytes   928 Mbits/sec                  
[  5]   3.00-4.00   sec   111 MBytes   928 Mbits/sec                  
[  5]   4.00-5.00   sec   111 MBytes   929 Mbits/sec                  
[  5]   5.00-6.00   sec   111 MBytes   929 Mbits/sec                  
[  5]   6.00-7.00   sec   111 MBytes   928 Mbits/sec                  
[  5]   7.00-8.00   sec   111 MBytes   928 Mbits/sec                  
[  5]   8.00-9.00   sec   111 MBytes   929 Mbits/sec                  
[  5]   9.00-10.00  sec   111 MBytes   928 Mbits/sec                  
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec  1.08 GBytes   931 Mbits/sec  174             sender
[  5]   0.00-10.00  sec  1.08 GBytes   925 Mbits/sec                  receiver

iperf en forçant en CUBIC :

Code: [Sélectionner]

~  ᐅ iperf3 -c paris.testdebit.info -p 9201 -C cubic -R
Connecting to host paris.testdebit.info, port 9201
Reverse mode, remote host paris.testdebit.info is sending
[  5] local 2a01:cb00:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx port 58866 connected to 2001:860:de01:1101::2 port 9201
[ ID] Interval           Transfer     Bitrate
[  5]   0.00-1.00   sec  59.0 MBytes   495 Mbits/sec                  
[  5]   1.00-2.00   sec  32.3 MBytes   271 Mbits/sec                  
[  5]   2.00-3.00   sec  36.0 MBytes   302 Mbits/sec                  
[  5]   3.00-4.00   sec  35.1 MBytes   294 Mbits/sec                  
[  5]   4.00-5.00   sec  29.8 MBytes   250 Mbits/sec                  
[  5]   5.00-6.00   sec  27.2 MBytes   229 Mbits/sec                  
[  5]   6.00-7.00   sec  31.1 MBytes   261 Mbits/sec                  
[  5]   7.00-8.00   sec  27.3 MBytes   229 Mbits/sec                  
[  5]   8.00-9.00   sec  21.9 MBytes   184 Mbits/sec                  
[  5]   9.00-10.00  sec  17.7 MBytes   148 Mbits/sec                  
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec   321 MBytes   269 Mbits/sec   58             sender
[  5]   0.00-10.00  sec   317 MBytes   266 Mbits/sec                  receiver

Le nombre de retransmissions semble limité, donc ça ne ressemble pas à de la perte de paquets.
D'ailleurs un iperf en UDP montre très peu de pertes :

Code: [Sélectionner]

~  ᐅ iperf3 -c bouygues.testdebit.info -p 9203 -u -b 900M -R
Connecting to host bouygues.testdebit.info, port 9203
Reverse mode, remote host bouygues.testdebit.info is sending
[  5] local 2a01:cb00:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx port 47834 connected to 2001:860:de01:1100::2 port 9203
[ ID] Interval           Transfer     Bitrate         Jitter    Lost/Total Datagrams
[  5]   0.00-1.00   sec   107 MBytes   899 Mbits/sec  0.022 ms  103/78791 (0.13%)  
[  5]   1.00-2.00   sec   107 MBytes   900 Mbits/sec  0.022 ms  22/78783 (0.028%)  
[  5]   2.00-3.00   sec   107 MBytes   900 Mbits/sec  0.021 ms  21/78782 (0.027%)  
[  5]   3.00-4.00   sec   107 MBytes   900 Mbits/sec  0.023 ms  19/78782 (0.024%)  
[  5]   4.00-5.00   sec   107 MBytes   900 Mbits/sec  0.008 ms  28/78793 (0.036%)  
[  5]   5.00-6.00   sec   107 MBytes   900 Mbits/sec  0.011 ms  17/78779 (0.022%)  
[  5]   6.00-7.00   sec   107 MBytes   900 Mbits/sec  0.008 ms  21/78786 (0.027%)  
[  5]   7.00-8.00   sec   107 MBytes   900 Mbits/sec  0.021 ms  18/78761 (0.023%)  
[  5]   8.00-9.00   sec   107 MBytes   900 Mbits/sec  0.012 ms  17/78797 (0.022%)  
[  5]   9.00-10.00  sec   107 MBytes   900 Mbits/sec  0.008 ms  21/78786 (0.027%)  
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Jitter    Lost/Total Datagrams
[  5]   0.00-10.00  sec  1.05 GBytes   900 Mbits/sec  0.000 ms  0/788101 (0%)  sender
[SUM]  0.0-10.0 sec  1 datagrams received out-of-order
[  5]   0.00-10.00  sec  1.05 GBytes   900 Mbits/sec  0.008 ms  287/787840 (0.036%)  receiver

ouno · « **Réponse #1 le:** 17 juin 2022 à 13:40:06 »

Bizarre effectivement, de mon côté aucun souci depuis une connexion FTTH Orange.

Tu as les mêmes résultats en IPv4 ?

Pour comparaison voilà les résultats du test UDP en IPv4 sur ma ligne (avec un Omit à 1s pour ignorer le faux packet loss initial dû à iPerf3):

Code: [Sélectionner]

$ iperf3 -c bouygues.testdebit.info -p 9203 -u -b 900M -R -O 1
Connecting to host bouygues.testdebit.info, port 9203
Reverse mode, remote host bouygues.testdebit.info is sending
[  5] local 192.168.1.3 port 47245 connected to 89.84.1.186 port 9203
[ ID] Interval           Transfer     Bitrate         Jitter    Lost/Total Datagrams
[  5]   0.00-1.00   sec   107 MBytes   901 Mbits/sec  0.009 ms  2801/80594 (3.5%)  (omitted)
[  5]   0.00-1.00   sec   107 MBytes   900 Mbits/sec  0.010 ms  0/77689 (0%)
[  5]   1.00-2.00   sec   107 MBytes   900 Mbits/sec  0.009 ms  0/77692 (0%)
[  5]   2.00-3.00   sec   107 MBytes   900 Mbits/sec  0.052 ms  0/77691 (0%)
[  5]   3.00-4.00   sec   107 MBytes   900 Mbits/sec  0.010 ms  0/77698 (0%)
[  5]   4.00-5.00   sec   107 MBytes   900 Mbits/sec  0.010 ms  0/77691 (0%)
[  5]   5.00-6.00   sec   107 MBytes   900 Mbits/sec  0.010 ms  0/77694 (0%)
[  5]   6.00-7.00   sec   107 MBytes   900 Mbits/sec  0.010 ms  0/77693 (0%)
[  5]   7.00-8.00   sec   107 MBytes   900 Mbits/sec  0.056 ms  0/77690 (0%)
[  5]   8.00-9.00   sec   107 MBytes   900 Mbits/sec  0.009 ms  0/77698 (0%)
[  5]   9.00-10.00  sec   107 MBytes   900 Mbits/sec  0.051 ms  0/77698 (0%)
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Jitter    Lost/Total Datagrams
[  5]   0.00-10.04  sec  1.05 GBytes   900 Mbits/sec  0.000 ms  0/777477 (0%)  sender
[  5]   0.00-10.00  sec  1.05 GBytes   900 Mbits/sec  0.051 ms  0/776934 (0%)  receiver

vivien · « **Réponse #2 le:** 17 juin 2022 à 14:23:13 »

Tu dois avoir des pertes de paquets.

Regarde les graphiques qui sont dans le fichier 202205_debit_fichier_250mio_10sec.ods

Le débit d'une connexion avec des pertes de paquets est très limité avec Cubic alors que cela ne gêne pas BBR.

Un exemple :
conditions du test :
- Latence aller-retour de 16ms
- Perte de paquet de 1%
- Débit moyen calculé sur un fichier de250 Mio
=> Débit BBR : 821 Mb/s
=> Débit Cubic : 26 Mb/s

Citation de: vivien le 15 mai 2022 à 18:00:52

Pour ces tests, le client et le serveur (tous les deux avec Ubuntu 22.04 server) sont connectés directement par un lien de 1 Gb/s Ethernet. Le client et le serveur sont l'un contre l'autre. Je simule latence, perte de paquets et utilise différent protocoles (http1.1 vs http2 et Cubic vs BBR). Le fichier téléchargé est un fichier de 250 Mio et le test s’arrête après 10 secondes.

Je mixte toutes ces combinaisons de tests :
- Je test avec les protocoles suivants : HTTP1.1 ; HTTP/2
- Je test avec les pertes de paquets suivantes: 0,000% ; 0,005% ; 0,01% ; 0,02% ; 0,05% ; 0,1% ; 0,2% ; 0,5% ; 1% ; 2% ; 5% ; 10%
- Je teste avec les latences suivantes : 0ms ; 1ms ; 2ms ; 4ms ; 8ms ; 16ms ; 32ms ; 64ms ; 128ms ; 256ms ; 512ms ; 1024ms
- Je test avec les protocoles d'évitement de la congestion suivant :Cubic ; BBR

Voici les données brutes de mes 53 830 tests : 202205_debit_fichier_250mio_10sec.ods

Je reviendrais vers vous avec des graphiques analysant les données plus tard (spoiler : les débits s'effondrent avec Cubic quand il y a des pertes de paquets)

Je n'ai pas publié ces graphiques car l'Arcep va communiquer sur le sujet jeudi 30 juin, de 15h à 16h30, lors d'une conférence de presse pour présenter son rapport annuel sur l’état d’internet en France.

Plusieurs points seront à l’ordre du jour :
• La mesure de la qualité d’internet
• L’interconnexion de données
• La transition vers IPv6
• La neutralité d’internet
• Les régulation des plateformes « gatekeepers »
• L’empreinte environnementale du numérique

ouno · « **Réponse #3 le:** 17 juin 2022 à 14:45:10 »

Citation de: vivien le 17 juin 2022 à 14:23:13

Tu dois avoir des pertes de paquets.

D'après son test en UDP il a effectivement un tout petit peu de perte de paquets: 0.026 % (en omettant la première seconde qui n'est pas significative)
Mais ça me paraît trop faible pour expliquer un passage de 925 Mbits/sec à 266 Mbits/sec, non ?

kgersen · « **Réponse #4 le:** 17 juin 2022 à 14:51:58 »

idem pas de souci depuis Orange FTTH Pro sur Paris.

hwti · « **Réponse #5 le:** 17 juin 2022 à 16:39:59 »

J'ai le même comportement en IPv4, et je ne sais pas depuis combien de temps.
Même à un débit plus faible (100Mbps) par exemple, j'ai toujours environ 0,03% de pertes.

En ce moment je suis repassé sur la Livebox, il faudrait que je compare avec le G-010S-A (SFP).

Le peu de pertes me semblait insuffisant pour justifier une telle limitation de débit, et les tests de Vivien semblent le confirmer.
Mais ça dépend peut-être de leur répartition statistique.

En tout cas, le test de ouno confirme que normalement il ne devrait y avoir aucune perte (mais j'ai des souvenirs de légères pertes en UDP sans que ça pose de problème, peut-être avec un autre serveur et/ou avec SFR).

Fuli10 · « **Réponse #6 le:** 17 juin 2022 à 21:34:08 »

C'est louche.
En -R c'est le serveur qui envoie la patate. La modification-C bbr ou cubic cela concerne ton PC. T'aurais pas plutôt un problème entre ton scheduler/power management et le fait d'utiliser cubic?
Fait plutôt le test en upload (sans le -R) avec les 2 modes cubic/bbr.
Chez Free en tout cas j'avais une énorme différence (plus trop avant que je change pour Orange).

hwti · « **Réponse #7 le:** 17 juin 2022 à 22:54:00 »

Le problème est reproduit avec deux PC, Linux et Windows, et les 0,03% de pertes de paquets en réception UDP sont visibles même à débit plus faible.
En upload, il n'y a aucune perte de paquet en UDP, donc cubic et bbr donnent exactement le même résultat, 600Mbps.

Le "-C" concerne les deux directions, iperf3 transmet le réglage au serveur qui l'applique.
Avec "-V" il affiche "snd_tcp_congestion" et "rcv_tcp_congestion".
Le problème est exactement le même avec bouygues.testdebit.info (cubic par défaut) et paris.testdebit.info + "-C cubic".

vivien · « **Réponse #8 le:** 18 juin 2022 à 07:19:30 »

Tu est à quelle latence des serveurs Cubic testés ?

Tu as vu dans mon tableur que pour voir l'impact d'une perte de débit il faut la latence et les pertes de paquets.

A très faible latence une perte à peu / pas d’impact.

hwti · « **Réponse #9 le:** 18 juin 2022 à 11:31:18 »

La latence est faible, je note quand même un peu plus de pics en IPv6 (mais ce n'est pas énorme non plus).

IPv6 :

Code: [Sélectionner]

--- bouygues.testdebit.info ping statistics ---
50 packets transmitted, 50 received, 0% packet loss, time 49076ms
rtt min/avg/max/mdev = 4.415/5.883/13.269/1.651 ms

IPv4 :

Code: [Sélectionner]

---  ping statistics ---
50 packets transmitted, 50 received, 0% packet loss, time 49078ms
rtt min/avg/max/mdev = 4.017/4.557/6.493/0.408 ms

hwti · « **Réponse #10 le:** 28 juin 2022 à 23:09:26 »

Retour à la normale (suite à la mise à jour de la Livebox ?).
Le débit est à nouveau maximal y compris en CUBIC, et il n'y a plus de pertes sur un iperf en UDP (à part pendant la première seconde).

Code: [Sélectionner]

~ ᐅ iperf3 -c bouygues.testdebit.info -p 9203 -u -b 900M -R
Connecting to host bouygues.testdebit.info, port 9203
Reverse mode, remote host bouygues.testdebit.info is sending
[  5] local 2a01:cb00:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx port 52144 connected to 2001:860:de01:1100::2 port 9203
[ ID] Interval           Transfer     Bitrate         Jitter    Lost/Total Datagrams
[  5]   0.00-1.00   sec   107 MBytes   899 Mbits/sec  0.061 ms  78/78814 (0.099%)  
[  5]   1.00-2.00   sec   107 MBytes   900 Mbits/sec  0.046 ms  0/78782 (0%)  
[  5]   2.00-3.00   sec   107 MBytes   900 Mbits/sec  0.037 ms  0/78782 (0%)  
[  5]   3.00-4.00   sec   107 MBytes   900 Mbits/sec  0.025 ms  0/78793 (0%)  
[  5]   4.00-5.00   sec   107 MBytes   900 Mbits/sec  0.026 ms  0/78777 (0%)  
[  5]   5.00-6.00   sec   107 MBytes   900 Mbits/sec  0.052 ms  0/78770 (0%)  
[  5]   6.00-7.00   sec   107 MBytes   900 Mbits/sec  0.041 ms  0/78788 (0%)  
[  5]   7.00-8.00   sec   107 MBytes   900 Mbits/sec  0.008 ms  0/78785 (0%)  
[  5]   8.00-9.00   sec   107 MBytes   900 Mbits/sec  0.022 ms  0/78763 (0%)  
[  5]   9.00-10.00  sec   107 MBytes   900 Mbits/sec  0.047 ms  0/78790 (0%)  
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Jitter    Lost/Total Datagrams
[  5]   0.00-10.00  sec  1.05 GBytes   900 Mbits/sec  0.000 ms  0/788155 (0%)  sender
[SUM]  0.0-10.0 sec  1 datagrams received out-of-order
[  5]   0.00-10.00  sec  1.05 GBytes   900 Mbits/sec  0.047 ms  78/787844 (0.0099%)  receiver