La latence a priori vers les serveurs Scaleway, les mêmes sur lesquels tu constates un débit différent, et une perte de paquets. Et cela dépend peut-être des serveurs, donc ce serait bien dans le script de pouvoir changer les serveurs. Dans le script .pl, cela doit être possible dans le code.
Pour rappel, Scaleway, ce n'est pas le réseau de Free.

P.S : en fait, dans le code perl, ce ne sont pas tous des serveurs Scaleway, et ce ne sont pas les mêmes en IPV4 et IPv6, ce qui peut expliquer certaines différences :

Internet => { IPv4 => { download => { 12876 => { BBR => ['ipv4.scaleway.testdebit.info',80,'/10G.iso',10,30],
                                                                   CUBIC => ['ping.online.net',80,'/10000Mo.dat',10,30] },
                                                        5410 => { BBR => ['ipv4.paris.testdebit.info',80,'/10G.iso',10,30],
                                                                  CUBIC => ['ipv4.bouygues.testdebit.info',80,'/10G.iso',10,30] } },


P.S : en fait, dans le code perl, ce ne sont pas tous des serveurs Scaleway, et ce ne sont pas les mêmes en IPV4 et IPv6, ce qui peut expliquer certaines différences :

Code: [Sélectionner]

Internet => { IPv4 => { download => { 12876 => { BBR => ['ipv4.scaleway.testdebit.info',80,'/10G.iso',10,30],
                                                                   CUBIC => ['ping.online.net',80,'/10000Mo.dat',10,30] },
                                                        5410 => { BBR => ['ipv4.paris.testdebit.info',80,'/10G.iso',10,30],
                                                                  CUBIC => ['ipv4.bouygues.testdebit.info',80,'/10G.iso',10,30] } },


Ce sont bien les serveurs hébergés chez Scaleway qui sont utilisés par défaut, il faut utiliser l'option "--alternate-srv" pour utiliser ceux sur le réseau de Bouygues Telecom.

Par contre dans les deux cas les serveurs Cubic et BBR ne sont pas forcément exactement au même endroit dans avoir des différences de ping n'est pas surprenant.

Par contre dans les deux cas les serveurs Cubic et BBR ne sont pas forcément exactement au même endroit dans avoir des différences de ping n'est pas surprenant.

Mais en tout cas, dans les deux cas, la latence n'est pas élevée, elle est normale selon la distance.

Les pertes de paquet peuvent avoir d'autres origines, comme un routeur défectueux, ou un serveur défectueux.

Mais en tout cas, dans les deux cas, la latence n'est pas élevée, elle est normale selon la distance.

Les pertes de paquet peuvent avoir d'autres origines, comme un routeur défectueux, ou un serveur défectueux.

Oui même directement chez l'abonné.

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.

Il faut que les deux serveurs de test soient situés au même endroit physiquement (ou idéalement le même serveur, comme avec iPerf3 qui permet de choisir l'algo de gestion de la congestion pour le test), sinon il y a d'autres éléments qui changent entre les deux tests et on compare d'autres choses que simplement l'algo de congestion.
D'autre part, si la connexion est saine et ne présente pas de perte de paquets, le débit CUBIC sera en général effectivement légèrement plus élevé sur des téléchargements de plus de 10 secondes car l'algo BBR réduit volontairement le débit un bref instant toutes les 10 secondes pour mettre à jour le RTT min. mesuré de la connexion.
Par contre, dès qu'il y a un tout petit peu de perte de paquets, BBR sera normalement plus performant.

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

De quelles latences parles-tu ? Si c'est les 3.82 ms contre 3.35 ms pour Ozwel ou les 3.73 ms contre 3.32 ms pour toi, je ne suis pas sûr que ce soit vraiment significatif. Cela est plus lié à la config des serveurs je suppose.
De plus checkFtthFree effectue les mesures de latence hors charge, avant les tests de débit. Donc il n'y a pas réellement de raison que la latence soit meilleure avec l'un qu'avec l'autre...

ce serait bien dans le script de pouvoir changer les serveurs. Dans le script .pl, cela doit être possible dans le code.

C'est le cas, je t'invite à consulter l'aide du script (soit via le paramètre --help ou -h, soit en première page de ce sujet):
--alternate-srv (-a) : Change de serveurs pour les tests Internet (utilise l'AS 5410 "Bouygues Telecom" à la place de l'AS 12876 "Scaleway")
Il est aussi possible de forcer l'utilisation d'IPv6 (les tests sont en IPv4 par défaut):
--ipv6 (-6) : Effectue les tests Internet en IPv6 (IPv4 par défaut)

Et donc sur les serveurs Bouygues Telecom (option -a), pas de perte de paquets significative, mais quand même 14.6%...

$ ./checkFtthFree.pl -a
...
[checkFtthFree v0.12]                         Linux 5.4.0-148-generic (aarch64)
-------------------------- 2023-05-29 13:33:47 +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.02 ms]
  --> Débit: 199.28 Mo/s (1.59 Gbps)    [fluctuation: 1.13%]

Test TCP Internet (IPv4): téléchargement depuis l'AS 5410 (Bouygues Telecom) [BBR]
  --> Latence: 3.64 ms                  [gigue: 0.26 ms]
  --> Débit: 210.70 Mo/s (1.69 Gbps)    [fluctuation: 2.50%]

Test TCP Internet (IPv4): téléchargement depuis l'AS 5410 (Bouygues Telecom) [CUBIC]
  --> Latence: 3.89 ms                  [gigue: 0.26 ms]
  --> Débit: 30.85 Mo/s (246.79 Mbps)   [fluctuation: 11.45%]

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