Alors clairement je ne viens pas me plaindre. Je partage juste mes tests et je demande si vous y voyez un petit soucis pour du lundi matin.
Je ne suis pas à l'aise avec ces histoires de CUBIC et BBR. Je pense que ce qui m'intéressera sera plutôt les résultats de ce soir à 21-22h.

Juste que le script dit que j'ai des pertes en période creuse donc... à voir si c'est normal. Chez Sosh le script ne disait rien de tout ça mais c'était 300/300Mbit/s donc des débits plus faibles. Forcément ça doit être plus facile de les tenirs sans encombrement.

J'ai toujours été un peu sceptique sur ces histoires de BBR vs CUBIC, car de mon expérience, à certains moments, c'est sur un serveur censé être BBR que le téléchargement est le plus rapide, et à d'autres, c'est sur un serveur censé être CUBIC.

Je remarque que tu as une meilleure latence en CUBIC qu'en BBR, alors qu'en toute logique, ce devrait être l'inverse si le réseau est saturé.

Là, ce lundi matin de Pentecôte, on n'est vraiment pas à un moment où le réseau devrait être saturé, et pourtant j'ai le même résultat que toi (à partir d'une VM Ubuntu sur ma frebox Delta) :

[checkFtthFree v0.12]                         Linux 5.4.0-148-generic (aarch64)
-------------------------- 2023-05-29 09:25:18 +0000 --------------------------
Paramétrage réseau actuel du système:
  net.core.default_qdisc: fq_codel
  net.core.rmem_max: 212992
  net.core.wmem_max: 212992
  net.ipv4.tcp_adv_win_scale: 1
  net.ipv4.tcp_congestion_control: cubic
  net.ipv4.tcp_mem: 22245       29662   44490
  net.ipv4.tcp_no_metrics_save: 0
  net.ipv4.tcp_rmem: 4096       131072  6291456
  net.ipv4.tcp_sack: 1
  net.ipv4.tcp_timestamps: 1
  net.ipv4.tcp_window_scaling: 1
  net.ipv4.tcp_wmem: 4096       16384   4194304
  => Latence TCP max pour une réception à 1 Gbps: 27 ms
  => Latence TCP max pour une émission à 700 Mbps: 35 ms

Test TCP local (IPv4): téléchargement depuis la Freebox
  --> Latence: 0.71 ms                  [gigue: 0.04 ms]
  --> Débit: 188.27 Mo/s (1.51 Gbps)    [fluctuation: 0.41%]

Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [BBR]
  --> Latence: 3.73 ms                  [gigue: 0.26 ms]
  --> Débit: 220.29 Mo/s (1.76 Gbps)    [fluctuation: 0.83%]

Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [CUBIC]
  --> Latence: 3.32 ms                  [gigue: 0.31 ms]
  --> Débit: 46.12 Mo/s (368.95 Mbps)   [fluctuation: 7.34%]

[!] La connexion aux serveurs de test semble affectée par une perte de paquets prononcée
      (ratio débit CUBIC/BBR: 20.94%)
-------------------------- 2023-05-29 09:25:55 +0000 --------------------------


Les mêmes, en IPV6. Paradoxalement, la latence en IPv6 est moins bonne qu'en IPv4.

Là, ce lundi matin de Pentecôte, on n'est vraiment pas à un moment où le réseau devrait être saturé, et pourtant j'ai le même résultat que toi (à partir d'une VM Ubuntu sur ma frebox Delta) :

Ça dépends vraiment de la localisation. Vous êtes situés ou ? De mon côté en banlieue lyonnaise, je ne constate pas :

PS D:\Temp> .\checkFtthFree.exe -6 -I -F

[checkFtthFree v0.12]                           Windows 10 Build 22621 (64-bit)
-------------------------- 2023-05-29 12:01:41 +0200 --------------------------
Paramétrage réseau actuel du système:
  AutoTuningLevelLocal: Normal
  CongestionProvider: BBR2
  EcnCapability: Disabled
  NetworkCategory: Private
  ScalingHeuristics: Disabled
  Timestamps: Allowed
  => Latence TCP max pour une réception à 1 Gbps: 141 ms

Test TCP Internet (IPv6): téléchargement depuis l'AS 12876 (Scaleway) [BBR]
  --> Latence: 7.87 ms                  [gigue: 0.30 ms]
  --> Débit: 289.67 Mo/s (2.32 Gbps)    [fluctuation: 1.85%]

Test TCP Internet (IPv6): téléchargement depuis l'AS 12876 (Scaleway) [CUBIC]
  --> Latence: 7.15 ms                  [gigue: 0.38 ms]
  --> Débit: 292.60 Mo/s (2.34 Gbps)    [fluctuation: 0.04%]
-------------------------- 2023-05-29 12:02:09 +0200 --------------------------


Ça dépends vraiment de la localisation. Vous êtes situés ou ? De mon côté en banlieue lyonnaise, je ne constate pas :

C'est indiqué dans mon profil, aux Ulis, au sud de Paris, à quelques kilomètres d'où habite underground78. Donc ce n'est pas vraiment régional.

La majorité du streaming (en tout cas dans le sens où tu l'entends, à savoir Youtube, Netflix et consorts) est en TCP. Google utilise BBR mais Netflix fait à priori du Cubic.

Netflix c'est du BBR, j'avais vu un article us sur le sujet et 'Netflix se félicitait de l' utilisation de BBR pour désengorger le réseau.

2,6 Gbps au lieu de 6 Gbps c'est saturé.

Cela créé des perte de paquets que Cubic gère en ralentissant le débit. BBR est concu pour ignorer les pertes de paquet.

Tout le principe est la:

Cubic date d'une époque ou une perte de paquet avait du sens donc il fallait "agir" dessus en ralentissant le flux TCP. Le souci est qu'il ralenti jusqu'a quasi plus de perte de paquet donc souvent s'effondre s'il lutte pour la BP avec d'autres flux qui ne ralentissent pas.
BBR est plus récent et conçu pour les réseaux modernes, hétérogenes, (wifi,mobile,ec) ou une perte de paquet n'implique pas forcement qu'on doit changer son comportement.

Dans vos tests la, on est en fixe a fixe , sur de la fibre de bout en bout donc si dans un cas on a 2,6Gbp  et dans l'autre 6Gbps avec 16 ou 32 flux en temps y'a clairement une indication de perte de paquets, forte.

Il peut y avoir plusieurs causes a une perte d'un paquet mais a ce niveau la c'est le plus souvent une saturation quelque part qui fait que de paquets sont rejetés / ignorés. Ca peut être un souci d'interco a un endroit (y'a un cas avec Bytel et Orange je crois) mais bref en tout cas le responsable c'est le FAI et son réseau.