La Fibre
Fournisseurs d'accès à Internet fixe en France métropolitaine => Free => 
Débits fibre Free => Discussion démarrée par: ouno le 06 mars 2023 à 20:02:56
-
Bonjour,
checkFtthFree est un programme open-source qui analyse la configuration réseau du système et effectue des tests TCP de latence et de débit mono-connexion. L'objectif est d'évaluer la qualité d'une connexion FTTH et de détecter d'éventuels problèmes de configuration ou dysfonctionnements. Pour ce faire, le programme compare les débits TCP obtenus en mono-connexion via un algorithme de gestion de la congestion basé sur la perte de paquets (Cubic) à ceux obtenus via un algorithme plus agressif (BBR). A l’issue des tests, divers indicateurs sont fournis tels que les débits TCP moyens, les fluctuations de débit, les latences TCP moyennes, la gigue et le ratio de débit Cubic/BBR si pertinent.
Ce programme n'utilise pas le système de stockage local et est beaucoup moins gourmand en ressources que les tests s'effectuant dans les navigateurs.
Cependant, ce programme n'a pas pour but d'évaluer les performances maximales de la connexion atteignables en multipliant le nombre de transferts en parallèle pour compenser la perte de paquets (d'autres programmes font ça très bien...).
checkFtthFree est dispo ici sous licence AGPLv3:
- checkFtthFree.exe (https://github.com/Yaribz/checkFtthFree/releases/latest/download/checkFtthFree.exe) (exécutable Windows: il suffit de double-cliquer dessus pour le lancer avec les paramètres par défaut)
- checkFtthFree.pl (https://github.com/Yaribz/checkFtthFree/releases/latest/download/checkFtthFree.pl) (script Perl pour autres systèmes: "perl checkFtthFree.pl" ou "./checkFtthFree.pl")
Usage:
checkFtthFree.pl [<options>]
--ipv6 (-6) : Effectue les tests Internet en IPv6 (IPv4 par défaut)
--alternate-srv (-a) : Change de serveurs pour les tests Internet (utilise l'AS 5410 "Bouygues Telecom" à la place de l'AS 12876 "Scaleway")
--all-srv (-A) : Effectue les tests Internet en double, une fois avec chaque AS (le débit le plus élevé est retenu pour le calcul de ratio Cubic/BBR)
--binary-units (-b) : Utilise les préfixes binaires pour le système d'unités de débit
--check-update (-c) : Effectue seulement la vérification de disponibilité de nouvelle version
--skip-check-update (-C) : Désactive la vérification de disponibilité de nouvelle version
--extended-test (-e) : Effectue des tests plus longs (multiplie par 2 la durée max des tests)
--freebox (-f) : Effectue seulement les tests locaux à partir de la Freebox (pas de test Internet)
--skip-freebox (-F) : Désactive les tests locaux à partir de la Freebox (tests Internet uniquement, empêche la détection de certains problèmes)
--help (-h) : Affiche l'aide
--skip-intro (-I) : Désactive le message d'introduction et démarre immédiatement les tests
--latency (-l) : Effectue seulement les tests de latence (pas de test de débit)
--skip-latency (-L) : Désactive les tests de latence (tests de débit uniquement, empêche la détection de certains problèmes)
--net-conf (-n) : Effectue seulement la lecture de la configuration réseau
--skip-net-conf (-N) : Désactive la lecture de la configuration réseau (empêche la détection de certains problèmes)
--quiet (-q) : Mode silencieux: désactive les messages d'analyse et d'avertissement
--suggestions (-s) : Affiche des suggestions pour résoudre des problèmes de configuration réseau ou compléter les tests si besoin
--upload (-u) : Effectue un test de débit montant au lieu de descendant (EXPERIMENTAL)
--version (-v) : Affiche la version
Exemple d'exécution sur une ligne FTTH Free affectée par une congestion aux heures de pointe:
[checkFtthFree v0.10] Linux 3.2.40 (armv7l)
-------------------------- 2023-03-06 19:38:45 +0100 --------------------------
Paramétrage réseau actuel du système:
net.core.rmem_max: 6291456
net.core.wmem_max: 4194304
net.ipv4.tcp_adv_win_scale: 1
net.ipv4.tcp_congestion_control: cubic
net.ipv4.tcp_mem: 24384 32512 48768
net.ipv4.tcp_no_metrics_save: 0
net.ipv4.tcp_rmem: 4096 87380 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: téléchargement depuis la Freebox
--> Latence: 1.74 ms [gigue: 0.03 ms]
--> Débit: 117.51 Mo/s (940.10 Mbps) [fluctuation: 0.35%]
Test TCP Internet: téléchargement depuis l'AS 12876 (Scaleway) [BBR]
--> Latence: 16.83 ms [gigue: 0.50 ms]
--> Débit: 100.48 Mo/s (803.85 Mbps) [fluctuation: 0.72%]
Test TCP Internet: téléchargement depuis l'AS 12876 (Scaleway) [CUBIC]
--> Latence: 16.62 ms [gigue: 0.13 ms]
--> Débit: 22.41 Mo/s (179.26 Mbps) [fluctuation: 17.90%]
[!] La connexion aux serveurs de test semble affectée par une perte de paquets prononcée
(ratio débit CUBIC/BBR: 22.30%)
-------------------------- 2023-03-06 19:39:23 +0100 --------------------------
-
merci :D
[checkFtthFree v0.10] Linux 5.10.0-21-amd64 (x86_64)
-------------------------- 2023-03-07 08:59:39 +0100 --------------------------
Paramétrage réseau actuel du système:
net.core.default_qdisc: pfifo_fast
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: 10077 13437 20154
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: téléchargement depuis la Freebox
--> Latence: 1.03 ms [gigue: 0.08 ms]
--> Débit: 117.47 Mo/s (939.73 Mbps) [fluctuation: 0.35%]
Test TCP Internet: téléchargement depuis l'AS 12876 (Scaleway) [BBR]
--> Latence: 9.31 ms [gigue: 0.82 ms]
--> Débit: 104.10 Mo/s (832.77 Mbps) [fluctuation: 4.32%]
Test TCP Internet: téléchargement depuis l'AS 12876 (Scaleway) [CUBIC]
--> Latence: 11.12 ms [gigue: 2.20 ms]
--> Débit: 10.37 Mo/s (82.98 Mbps) [fluctuation: 33.07%]
[!] La connexion aux serveurs de test semble affectée par une forte perte de paquets
(ratio débit CUBIC/BBR: 9.96%)
-------------------------- 2023-03-07 09:00:17 +0100 --------------------------
9h c'est une heure de pointe ? ;D
Test TCP local: téléchargement depuis la Freebox
--> Latence: 1.04 ms [gigue: 0.09 ms]
--> Débit: 117.46 Mo/s (939.68 Mbps) [fluctuation: 0.49%]
Test TCP Internet: téléchargement depuis l'AS 5410 (Bouygues Telecom) [BBR]
--> Latence: 9.26 ms [gigue: 0.57 ms]
--> Débit: 108.58 Mo/s (868.66 Mbps) [fluctuation: 1.25%]
Test TCP Internet: téléchargement depuis l'AS 5410 (Bouygues Telecom) [CUBIC]
--> Latence: 9.00 ms [gigue: 0.30 ms]
--> Débit: 107.85 Mo/s (862.81 Mbps) [fluctuation: 1.96%]
-------------------------- 2023-03-07 09:02:38 +0100 --------------------------
et Bouygues pas de soucis ???
-
Là, il semble bien que l'on ait un exemple type d'un serveur pour lequel la connectivité n'est pas sympa...
La liaison client et la trajectoire vers un serveur via un transit Free - Bouygues est sympa, mais en restant dans "l'espace Iliad" c'est pas terrible. A ce sujet, il me semble avoir déjà lu qu'effectivement les "tuyaux" entre Scaleway et Free, bof...
-
9h c'est une heure de pointe ? ;D
Bizarre effectivement, je viens de tester avec la connexion FTTH Free de mes parents et c'est pas terrible non plus en CUBIC depuis Scaleway à 9h30:
Test TCP Internet: téléchargement depuis l'AS 12876 (Scaleway) [BBR]
--> Latence: 16.89 ms [gigue: 0.51 ms]
--> Débit: 101.61 Mo/s (812.87 Mbps) [fluctuation: 1.97%]
Test TCP Internet: téléchargement depuis l'AS 12876 (Scaleway) [CUBIC]
--> Latence: 16.76 ms [gigue: 0.10 ms]
--> Débit: 35.37 Mo/s (282.95 Mbps) [fluctuation: 37.54%]
[!] La connexion aux serveurs de test semble affectée par une perte de paquets prononcée
(ratio débit CUBIC/BBR: 34.81%)
Et pourtant quand je fais le test avec ma connexion FTTH Orange juste après il n'y a aucun souci, 117.68 Mo/s pour les deux algos, donc c'est pas le serveur Scaleway CUBIC qui a un problème...
-
Et pourtant quand je fais le test avec ma connexion FTTH Orange juste après il n'y a aucun souci, 117.68 Mo/s pour les deux algos, donc c'est pas le serveur Scaleway CUBIC qui a un problème...
On pourrait en déduire que les rapports entre les "frères ennemis"? d'Iliad ne sont peut-être pas au beau fixe, et que le "pont-levis" entre l'infra Free et l'infra Scaleway ne se lève pas toujours comme il faudrait, ou il y a une herse à l'entrée? ;)
-
Hello. Testé en moins de 5 minutes. Super outils merci @ouno !
Cela dit, j'ajouterai peut-être un petit truc en plus: différencier l'IPv4 et l'IPv6.
Si ça se trouve, la route IPv4 est plus ou moins encombré vs l'IPv6.
-
C'est quel serveur Scaleway Cubic ?
-
j'ai refais un test 10 minutes après et c'était bon sur scaleway, en upload bon aussi les 2 (entre 68 et 72Mo/s)
-
j'ai refais un test 10 minutes après et c'était bon sur scaleway, en upload bon aussi les 2 (entre 68 et 72Mo/s)
Donc se méfier des observations instantanée...
Dans l'industrie on sait pertinemment que les observations instantanées doivent être multipliées pour en tirer un enseignement valable. Si le serveur à l'autre bout est fortement sollicité, clair qu'il ne peut pas être au four et au moulin. Quand à savoir pourquoi ce type de machine pourrait être sur-sollicité, mystère? C'est un peu le revers de l'ensemble des tests qui peuvent être faits. Si la répétition est là, on peut en tirer des conclusions, sinon, sur du "one shot", c'est la tribu des "ifopa"! ;)
-
Hello. Testé en moins de 5 minutes. Super outils merci @ouno !
Cela dit, j'ajouterai peut-être un petit truc en plus: différencier l'IPv4 et l'IPv6.
Si ça se trouve, la route IPv4 est plus ou moins encombré vs l'IPv6.
Merci !
C'est ajouté dans la version 0.11: option --ipv6 (ou -6) pour faire les tests Internet en Ipv6.
C'est quel serveur Scaleway Cubic ?
ping.online.net
Il y a plusieurs serveurs de test Scaleway HTTP en CUBIC ?
j'ai refais un test 10 minutes après et c'était bon sur scaleway, en upload bon aussi les 2 (entre 68 et 72Mo/s)
Oui selon les connexions les résultats des tests en CUBIC peuvent être plus ou moins irréguliers, car plus sensibles aux pertes de paquets... (surtout si celles-ci se produisent au début du transfert, pendant la phase de slow-start TCP, même si le programme ignore les 2 premières secondes automatiquement pour le calcul de débit nominal). Après peut-être que le serveur est surchargé par moments ?
Je ne sais pas si je regarde au bon endroit sur la weather map Scaleway (https://netmap.scaleway.com/), mais l'interco Scaleway/Free n'a vraiment pas l'air surchargée en tout cas:
-
Merci pour la MaJ de ton petit prog
[checkFtthFree v0.11] Windows 10 Build 22621 (64-bit)
-------------------------- 2023-03-08 21:02:13 +0100 --------------------------
Paramétrage réseau actuel du système:
AutoTuningLevelLocal: Normal
CongestionProvider: CUBIC
EcnCapability: Disabled
NetworkCategory: Public
ScalingHeuristics: Disabled
Timestamps: Allowed
=> Latence TCP max pour une réception à 1 Gbps: 141 ms
Test TCP local (IPv4): téléchargement depuis la Freebox
--> Latence: 0.36 ms [gigue: 0.02 ms]
--> Débit: 109.76 Mo/s (878.09 Mbps) [fluctuation: 5.64%]
Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [BBR]
--> Latence: 2.88 ms [gigue: 0.22 ms]
--> Débit: 118.59 Mo/s (948.72 Mbps) [fluctuation: 0.11%]
Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [CUBIC]
--> Latence: 2.38 ms [gigue: 0.15 ms]
--> Débit: 118.65 Mo/s (949.18 Mbps) [fluctuation: 0.06%]
-------------------------- 2023-03-08 21:02:56 +0100 --------------------------
-
ping de fou et meilleur débit sur internet qu'en local ... tu habites dans le data center ? ;D
-
ping de fou et meilleur débit sur internet qu'en local ... tu habites dans le data center ? ;D
Non, même pas, une simple connexion Free comme il y en a plein d'autres :D
-
meilleur débit sur internet qu'en local ...
Ca c'est la Freebox qui ne suit pas. Selon les modèles et les services qui tournent en même temps dessus les résultats du test de débit local ne sont pas forcément très précis...
Mais les derniers modèles de Freebox sont capables de servir au moins à 1.09 Go/s (8.70 Gbps) sur le service de test de débit local d'après ce que j'ai vu.
-
Ca c'est la Freebox qui ne suit pas. Selon les modèles et les services qui tournent en même temps dessus les résultats du test de débit local ne sont pas forcément très précis...
Mais les derniers modèles de Freebox sont capables de servir au moins à 1.09 Go/s (8.70 Gbps) sur le service de test de débit local d'après ce que j'ai vu.
C'est une Delta :) dernier modèle du coup, je suppose.
-
Non, même pas, une simple connexion Free comme il y en a plein d'autres :D
C'est vrai que c'est souvent les personnes qui ont des soucis qu'on entend le plus sur les forums, cela dit je pense que le fait d'être situé aussi près des serveurs de test permet d'éviter une partie des problèmes potentiels...
Je serais curieux de voir ce que donne un traceroute vers ping.online.net depuis ta connexion ?
C'est une Delta :) dernier modèle du coup, je suppose.
Ah oui effectivement, du coup je sais pas trop quel est le point commun des Freebox qui donnent un résultat un peu moins précis sur le test local comme ça, peut-être un service particulier activé dessus...
-
C'est vrai que c'est souvent les personnes qui ont des soucis qu'on entend le plus sur les forums, cela dit je pense que le fait d'être situé aussi près des serveurs de test permet d'éviter une partie des problèmes potentiels...
Je serais curieux de voir ce que donne un traceroute vers ping.online.net depuis ta connexion ?
Ah oui effectivement, du coup je sais pas trop quel est le point commun des Freebox qui donnent un résultat un peu moins précis sur le test local comme ça, peut-être un service particulier activé dessus...
Il y avait 2 smartphones en wifi et la TV, ça doit jouer un peu.
-
Bizarre effectivement, je viens de tester avec la connexion FTTH Free de mes parents et c'est pas terrible non plus en CUBIC depuis Scaleway à 9h30:
Et pourtant quand je fais le test avec ma connexion FTTH Orange juste après il n'y a aucun souci, 117.68 Mo/s pour les deux algos, donc c'est pas le serveur Scaleway CUBIC qui a un problème...
Je confirme en toute transparence : ... Bizarre !
[checkFtthFree v0.11] Windows 10 Build 22621 (64-bit)
-------------------------- 2023-03-09 19:46:28 +0100 --------------------------
Paramétrage réseau actuel du système:
AutoTuningLevelLocal: Normal
CongestionProvider: CUBIC
EcnCapability: Disabled
NetworkCategory: Public
ScalingHeuristics: Disabled
Timestamps: Allowed
=> Latence TCP max pour une réception à 1 Gbps: 141 ms
Test TCP local (IPv4): téléchargement depuis la Freebox
--> Latence: 1.12 ms [gigue: 0.10 ms]
--> Débit: 1.19 Go/s (9.50 Gbps) [fluctuation: 0.82%]
Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [BBR]
--> Latence: 8.79 ms [gigue: 0.49 ms]
--> Débit: 409.84 Mo/s (3.28 Gbps) [fluctuation: 11.38%]
Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [CUBIC]
--> Latence: 8.54 ms [gigue: 0.35 ms]
--> Débit: 33.28 Mo/s (266.27 Mbps) [fluctuation: 10.49%]
[!] La connexion aux serveurs de test semble affectée par une forte perte de paquets
(ratio débit CUBIC/BBR: 8.12%)
-------------------------- 2023-03-09 19:47:09 +0100 --------------------------
-
Je confirme en toute transparence : ... Bizarre !
Là on commence déjà à se rapprocher de l'heure de pointe, il faudrait refaire le test très tôt le matin pour comparer.
-
Là on commence déjà à se rapprocher de l'heure de pointe, il faudrait refaire le test très tôt le matin pour comparer.
[checkFtthFree v0.11] Windows 10 Build 22621 (64-bit)
-------------------------- 2023-03-10 06:36:32 +0100 --------------------------
Paramétrage réseau actuel du système:
AutoTuningLevelLocal: Normal
CongestionProvider: CUBIC
EcnCapability: Disabled
NetworkCategory: Private,Private
ScalingHeuristics: Disabled
Timestamps: Allowed
=> Latence TCP max pour une réception à 1 Gbps: 141 ms
Test TCP local (IPv4): téléchargement depuis la Freebox
--> Latence: 1.11 ms [gigue: 0.17 ms]
--> Débit: 1.18 Go/s (9.46 Gbps) [fluctuation: 1.24%]
Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [BBR]
--> Latence: 9.03 ms [gigue: 0.40 ms]
--> Débit: 596.13 Mo/s (4.77 Gbps) [fluctuation: 16.60%]
Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [CUBIC]
--> Latence: 8.36 ms [gigue: 0.25 ms]
--> Débit: 139.58 Mo/s (1.12 Gbps) [fluctuation: 52.10%]
[!] La connexion aux serveurs de test semble affectée par une perte de paquets prononcée
(ratio débit CUBIC/BBR: 23.41%)
-------------------------- 2023-03-10 06:37:14 +0100 --------------------------
-
Bonjour, idem chez moi
[checkFtthFree v0.11] Windows 10 Build 19045 (64-bit)
-------------------------- 2023-03-10 08:37:18 +0100 --------------------------
Paramétrage réseau actuel du système:
AutoTuningLevelLocal: Normal
CongestionProvider: CUBIC
EcnCapability: Disabled
NetworkCategory: Private
ScalingHeuristics: Disabled
Timestamps: Disabled
=> Latence TCP max pour une réception à 1 Gbps: 141 ms
Test TCP local (IPv4): téléchargement depuis la Freebox
--> Latence: 0.54 ms [gigue: 0.04 ms]
--> Débit: 117.32 Mo/s (938.56 Mbps) [fluctuation: 0.80%]
Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [BBR]
--> Latence: 12.31 ms [gigue: 0.24 ms]
--> Débit: 101.54 Mo/s (812.31 Mbps) [fluctuation: 1.92%]
Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [CUBIC]
--> Latence: 11.74 ms [gigue: 0.88 ms]
--> Débit: 18.30 Mo/s (146.43 Mbps) [fluctuation: 30.89%]
[!] La connexion aux serveurs de test semble affectée par une perte de paquets prononcée
(ratio débit CUBIC/BBR: 18.03%)
-
un petit windows et un ptit linux
[checkFtthFree v0.11] Windows 10 Build 19045 (64-bit)
-------------------------- 2023-03-10 08:56:13 +0100 --------------------------
Paramétrage réseau actuel du système:
AutoTuningLevelLocal: Normal
CongestionProvider: CUBIC
EcnCapability: Disabled
NetworkCategory: Public
ScalingHeuristics: Disabled
Timestamps: Disabled
=> Latence TCP max pour une réception à 1 Gbps: 141 ms
Test TCP local (IPv4): téléchargement depuis la Freebox
--> Latence: 1.06 ms [gigue: 0.08 ms]
--> Débit: 118.14 Mo/s (945.10 Mbps) [fluctuation: 0.54%]
Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [BBR]
--> Latence: 9.03 ms [gigue: 0.25 ms]
--> Débit: 107.58 Mo/s (860.67 Mbps) [fluctuation: 4.12%]
Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [CUBIC]
--> Latence: 8.72 ms [gigue: 0.31 ms]
--> Débit: 110.50 Mo/s (883.98 Mbps) [fluctuation: 0.38%]
-------------------------- 2023-03-10 08:56:59 +0100 --------------------------
[checkFtthFree v0.11] Linux 5.10.0-21-amd64 (x86_64)
-------------------------- 2023-03-10 08:57:51 +0100 --------------------------
Paramétrage réseau actuel du système:
net.core.default_qdisc: pfifo_fast
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: 10077 13437 20154
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.77 ms [gigue: 0.05 ms]
--> Débit: 116.01 Mo/s (928.11 Mbps) [fluctuation: 2.21%]
Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [BBR]
--> Latence: 9.14 ms [gigue: 0.44 ms]
--> Débit: 106.40 Mo/s (851.22 Mbps) [fluctuation: 5.11%]
Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [CUBIC]
--> Latence: 9.06 ms [gigue: 0.65 ms]
--> Débit: 109.67 Mo/s (877.33 Mbps) [fluctuation: 0.44%]
-------------------------- 2023-03-10 08:58:29 +0100 --------------------------
marrant cette différence de latence max ... 141 contre 27 :o
-
-------------------------- 2023-03-09 19:46:28 +0100 --------------------------
--> Débit: 33.28 Mo/s (266.27 Mbps) [fluctuation: 10.49%]
(ratio débit CUBIC/BBR: 8.12%)
-------------------------- 2023-03-10 06:36:32 +0100 --------------------------
--> Débit: 139.58 Mo/s (1.12 Gbps) [fluctuation: 52.10%]
(ratio débit CUBIC/BBR: 23.41%)
Si les résultats sont reproductibles (et si la connexion n'est pas utilisée par ailleurs pendant les tests...) ça ressemble à de la congestion en heures de pointe dans ton cas.
Bonjour, idem chez moi
Oui sur ma ligne Free aussi c'est à peu près pareil ce matin: ratio CUBIC/BBR très variable, même en changeant de serveur (paramètre -a)
Et pourtant aucun souci depuis ma ligne Orange au même moment, donc le serveur de test Scaleway Cubic n'est pas en cause...:
-------------------------- 2023-03-10 08:53:14 +0100 --------------------------
Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [BBR]
--> Latence: 8.00 ms [gigue: 0.11 ms]
--> Débit: 117.68 Mo/s (941.47 Mbps) [fluctuation: 0.00%]
Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [CUBIC]
--> Latence: 7.99 ms [gigue: 0.17 ms]
--> Débit: 117.68 Mo/s (941.48 Mbps) [fluctuation: 0.00%]
-------------------------- 2023-03-10 08:53:39 +0100 --------------------------
-
un petit windows et un ptit linux
marrant cette différence de latence max ... 141 contre 27 :o
C'est parce que Windows et Linux n'ont pas la même configuration de buffer max TCP, c'est configurable via des paramètres système.
-
Si les résultats sont reproductibles (et si la connexion n'est pas utilisée par ailleurs pendant les tests...) ça ressemble à de la congestion en heures de pointe dans ton cas.
6h plus tard !
[checkFtthFree v0.11] Windows 10 Build 22621 (64-bit)
-------------------------- 2023-03-10 12:39:03 +0100 --------------------------
Paramétrage réseau actuel du système:
AutoTuningLevelLocal: Normal
CongestionProvider: CUBIC
EcnCapability: Disabled
NetworkCategory: Private,Private
ScalingHeuristics: Disabled
Timestamps: Allowed
=> Latence TCP max pour une réception à 1 Gbps: 141 ms
Test TCP local (IPv4): téléchargement depuis la Freebox
--> Latence: 1.06 ms [gigue: 0.13 ms]
--> Débit: 1.04 Go/s (8.30 Gbps) [fluctuation: 3.25%]
Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [BBR]
--> Latence: 8.83 ms [gigue: 0.27 ms]
--> Débit: 449.37 Mo/s (3.59 Gbps) [fluctuation: 12.70%]
Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [CUBIC]
--> Latence: 8.33 ms [gigue: 0.22 ms]
--> Débit: 40.68 Mo/s (325.47 Mbps) [fluctuation: 24.71%]
[!] La connexion aux serveurs de test semble affectée par une forte perte de paquets
(ratio débit CUBIC/BBR: 9.05%)
-------------------------- 2023-03-10 12:39:44 +0100 --------------------------
-
Pas mieux que ce matin
-------------------------- 2023-03-10 14:12:52 +0100 --------------------------
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: 190200 253603 380400
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 Internet (IPv4): téléchargement depuis l'AS 5410 (Bouygues Telecom) [BBR]
--> Latence: 12.35 ms [gigue: 0.41 ms]
--> Débit: 103.63 Mo/s (829.07 Mbps) [fluctuation: 1.41%]
Test TCP Internet (IPv4): téléchargement depuis l'AS 5410 (Bouygues Telecom) [CUBIC]
--> Latence: 12.68 ms [gigue: 0.24 ms]
--> Débit: 10.31 Mo/s (82.48 Mbps) [fluctuation: 21.36%]
[!] La connexion aux serveurs de test semble affectée par une forte perte de paquets
(ratio débit CUBIC/BBR: 9.95%)
-------------------------- 2023-03-10 14:13:17 +0100 --------------------------
-
Je serais curieux de voir ce que donne un traceroute vers ping.online.net depuis ta connexion ?
Myck205, est-ce que tu aurais la possibilité de faire un traceroute vers ping.online.net depuis ta connexion pour essayer de comprendre d'où viennent les différences de perfs ?
-
Bizarrement j'ai un débit assez bas sur le test local :
Test TCP local (IPv4): téléchargement depuis la Freebox
--> Latence: 0.83 ms [gigue: 0.05 ms]
--> Débit: 67.06 Mo/s (536.52 Mbps) [fluctuation: 2.84%]
Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [BBR]
--> Latence: 3.53 ms [gigue: 0.19 ms]
--> Débit: 109.95 Mo/s (879.63 Mbps) [fluctuation: 0.64%]
Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [CUBIC]
--> Latence: 3.03 ms [gigue: 0.30 ms]
--> Débit: 110.45 Mo/s (883.57 Mbps) [fluctuation: 0.53%]
Je reproduis le problème avec un "wget" mais ça m'étonne parce qu'il me semble que ce n'était pas le cas avant. Je me demande s'il n'y aurait pas eu une régression.
J'ai une erreur en IPv6 que je n'explique pas non plus :
Test TCP Internet (IPv6): téléchargement depuis l'AS 12876 (Scaleway) [BBR]
--> Latence: 3.58 ms [gigue: 0.21 ms]
[!] Echec de téléchargement de "http://ipv6.scaleway.testdebit.info:80/10G.iso" (Could not connect to 'ipv6.scaleway.testdebit.info:80': IO::Socket::INET: Bad hostname 'ipv6.scaleway.testdebit.info')
[!] Echec du test de débitPourtant le nom de domaine est correct :
> nslookup ipv6.scaleway.testdebit.info
Serveur : UnKnown
Address: 192.168.0.254
Nom : ipv6.scaleway.testdebit.info
Address: 2001:bc8:3::7
J'ai aussi un bien meilleur débit en CUBIC qu'en BBR depuis ByTel...
Test TCP local (IPv4): téléchargement depuis la Freebox
--> Latence: 0.81 ms [gigue: 0.05 ms]
--> Débit: 68.67 Mo/s (549.39 Mbps) [fluctuation: 1.40%]
Test TCP Internet (IPv4): téléchargement depuis l'AS 5410 (Bouygues Telecom) [BBR]
--> Latence: 3.85 ms [gigue: 0.36 ms]
--> Débit: 16.99 Mo/s (135.94 Mbps) [fluctuation: 43.44%]
Test TCP Internet (IPv4): téléchargement depuis l'AS 5410 (Bouygues Telecom) [CUBIC]
--> Latence: 3.51 ms [gigue: 0.21 ms]
--> Débit: 102.86 Mo/s (822.84 Mbps) [fluctuation: 4.46%]
Edit : j'ai relancé un test avec ByTel et là j'ai un bon débit partout y compris en local... ???
Test TCP local (IPv4): téléchargement depuis la Freebox
--> Latence: 0.82 ms [gigue: 1.45 ms]
--> Débit: 115.84 Mo/s (926.75 Mbps) [fluctuation: 3.75%]
Test TCP Internet (IPv4): téléchargement depuis l'AS 5410 (Bouygues Telecom) [BBR]
--> Latence: 3.44 ms [gigue: 0.26 ms]
--> Débit: 110.16 Mo/s (881.28 Mbps) [fluctuation: 1.23%]
Test TCP Internet (IPv4): téléchargement depuis l'AS 5410 (Bouygues Telecom) [CUBIC]
--> Latence: 3.47 ms [gigue: 0.10 ms]
--> Débit: 109.73 Mo/s (877.86 Mbps) [fluctuation: 1.21%]
-
Myck205, est-ce que tu aurais la possibilité de faire un traceroute vers ping.online.net depuis ta connexion pour essayer de comprendre d'où viennent les différences de perfs ?
Je ferai ça dans la soirée, je ne suis pas chez moi.
-
Bizarrement j'ai un débit assez bas sur le test local :
Je reproduis le problème avec un "wget" mais ça m'étonne parce qu'il me semble que ce n'était pas le cas avant. Je me demande s'il n'y aurait pas eu une régression.
Oui je me souviens que tu avais déjà le problème en 2021, et tu avais aussi reproduit avec wget (cf ce message (https://lafibre.info/1gb-free/freebox-v6-onu-recent-gt-30-mos-max-par-session-tcp/msg909626/#msg909626)).
Certaines Freebox ne donnent pas des résultats précis/stables pour le test local, je ne sais pas trop pourquoi ??? (mais ce n'est pas lié à checkFtthFree puisque comme tu l'indiques c'est reproductibe avec un simple wget).
J'ai une erreur en IPv6 que je n'explique pas non plus :
[!] Echec de téléchargement de "http://ipv6.scaleway.testdebit.info:80/10G.iso" (Could not connect to 'ipv6.scaleway.testdebit.info:80': IO::Socket::INET: Bad hostname 'ipv6.scaleway.testdebit.info')
[!] Echec du test de débit
Alors ça je pense que c'est parce qu'il te manque le module Perl IO::Socket::IP, qui est le module qui remplace IO::Socket::INET et qui apporte la gestion de l'IPv6.
Je pensais que toutes les distribs incluaient ce module par défaut depuis longtemps mais a priori non.
Est-ce que tu peux me dire ce que renvoie la commande suivante sur ton système pour vérifier que c'est bien ça ? perl -MIO::Socket::IP -e 'print $IO::Socket::IP::VERSION'
Je vais faire une nouvelle version pour améliorer la détection du support IPv6 et mettre des messages explicites...
J'ai aussi un bien meilleur débit en CUBIC qu'en BBR depuis ByTel...
Edit : j'ai relancé un test avec ByTel et là j'ai un bon débit partout y compris en local... ???
Etonnant, là je n'ai pas trop d'explication si ce n'est que peut-être le serveur de test était surchargé au moment du premier test BBR ?
En tout cas je n'ai jamais vu une telle différence en faveur du Cubic sur tous les tests que j'ai pu réaliser...
Ou alors peut-être que ta Freebox a des coups de fatigue par moments, si ça coïncide avec les moments où les tests de débit locaux sont bas aussi ?
-
Oui je me souviens que tu avais déjà le problème en 2021, et tu avais aussi reproduit avec wget (cf ce message (https://lafibre.info/1gb-free/freebox-v6-onu-recent-gt-30-mos-max-par-session-tcp/msg909626/#msg909626)).
Certaines Freebox ne donnent pas des résultats précis/stables pour le test local, je ne sais pas trop pourquoi ??? (mais ce n'est pas lié à checkFtthFree puisque comme tu l'indiques c'est reproductibe avec un simple wget).
J'avais complètement oublié... :-[ Ce qui est sûr c'est que j'ai une Freebox Révolution qui n'est plus toute jeune...
Alors ça je pense que c'est parce qu'il te manque le module Perl IO::Socket::IP, qui est le module qui remplace IO::Socket::INET et qui apporte la gestion de l'IPv6.
Je pensais que toutes les distribs incluaient ce module par défaut depuis longtemps mais a priori non.
Est-ce que tu peux me dire ce que renvoie la commande suivante sur ton système pour vérifier que c'est bien ça ? perl -MIO::Socket::IP -e 'print $IO::Socket::IP::VERSION'
Je vais faire une nouvelle version pour améliorer la détection du support IPv6 et mettre des messages explicites...
J'utilise la version exécutable pour Windows, je pensais que les bibliothèques Perl étaient empaquetées avec. Je n'ai pas l'impression d'avoir l'exécutable Perl dans le PATH en tout cas.
Etonnant, là je n'ai pas trop d'explication si ce n'est que peut-être le serveur de test était surchargé au moment du premier test BBR ?
En tout cas je n'ai jamais vu une telle différence en faveur du Cubic sur tous les tests que j'ai pu réaliser...
Ou alors peut-être que ta Freebox a des coups de fatigue par moments, si ça coïncide avec les moments où les tests de débit locaux sont bas aussi ?
Visiblement c'est indépendant du résultat local ou alors ça change vite :
Test TCP local (IPv4): téléchargement depuis la Freebox
--> Latence: 0.79 ms [gigue: 0.04 ms]
--> Débit: 107.74 Mo/s (861.92 Mbps) [fluctuation: 10.76%]
Test TCP Internet (IPv4): téléchargement depuis l'AS 5410 (Bouygues Telecom) [BBR]
--> Latence: 3.90 ms [gigue: 0.52 ms]
--> Débit: 46.50 Mo/s (371.99 Mbps) [fluctuation: 27.52%]
Test TCP Internet (IPv4): téléchargement depuis l'AS 5410 (Bouygues Telecom) [CUBIC]
--> Latence: 3.41 ms [gigue: 0.11 ms]
--> Débit: 102.98 Mo/s (823.80 Mbps) [fluctuation: 3.94%]
-
J'utilise la version exécutable pour Windows, je pensais que les bibliothèques Perl étaient empaquetées avec.
Tout à fait tu as raison, je sais pas pourquoi j'étais persuadé que tu lançais les tests sous Linux.
Dans ce cas effectivement c'est sûrement un oubli de ma part dans la génération de l'exécutable Windows, je vais faire une nouvelle version qui devrait régler le problème.
edit: c'est fait, la version 0.12 devrait régler le souci avec l'IPv6 sous Windows
Visiblement c'est indépendant du résultat local ou alors ça change vite :
Ah oui c'est reproductible facilement de ton côté en plus à ce que je vois, bizarre ???
En tout cas je n'arrive pas à reproduire depuis ma connexion Free, ce matin mon ratio Cubic/BBR sur les serveurs Bouygues est entre 20% et 50%, jamais de débit plus élevé en Cubic qu'en BBR...
-
Je ferai ça dans la soirée, je ne suis pas chez moi.
Ca marche merci !
-
Tout à fait tu as raison, je sais pas pourquoi j'étais persuadé que tu lançais les tests sous Linux.
Dans ce cas effectivement c'est sûrement un oubli de ma part dans la génération de l'exécutable Windows, je vais faire une nouvelle version qui devrait régler le problème.
edit: c'est fait, la version 0.12 devrait régler le souci avec l'IPv6 sous Windows
Je confirme, c'est bien résolu avec la version 0.12. Merci ! :)
Ah oui c'est reproductible facilement de ton côté en plus à ce que je vois, bizarre ???
En tout cas je n'arrive pas à reproduire depuis ma connexion Free, ce matin mon ratio Cubic/BBR sur les serveurs Bouygues est entre 20% et 50%, jamais de débit plus élevé en Cubic qu'en BBR...
Là je n'ai plus ce comportement (même résultat en IPv6) donc c'est peut-être un souci assez ponctuel lié au serveur :
Test TCP Internet (IPv4): téléchargement depuis l'AS 5410 (Bouygues Telecom) [BBR]
--> Latence: 3.46 ms [gigue: 0.60 ms]
--> Débit: 110.25 Mo/s (882.04 Mbps) [fluctuation: 1.11%]
Test TCP Internet (IPv4): téléchargement depuis l'AS 5410 (Bouygues Telecom) [CUBIC]
--> Latence: 3.48 ms [gigue: 0.25 ms]
--> Débit: 110.43 Mo/s (883.45 Mbps) [fluctuation: 0.41%]
-
Merci ouno, c'est parfait en ipv6 dorénavant
[checkFtthFree v0.12] Windows 10 Build 22621 (64-bit)
-------------------------- 2023-03-11 14:01:38 +0100 --------------------------
Paramétrage réseau actuel du système:
AutoTuningLevelLocal: Normal
CongestionProvider: CUBIC
EcnCapability: Disabled
NetworkCategory: Private
ScalingHeuristics: Disabled
Timestamps: Allowed
=> Latence TCP max pour une réception à 1 Gbps: 141 ms
Test TCP local (IPv4): téléchargement depuis la Freebox
--> Latence: 0.50 ms [gigue: 0.13 ms]
--> Débit: 294.47 Mo/s (2.36 Gbps) [fluctuation: 1.47%]
Test TCP Internet (IPv6): téléchargement depuis l'AS 12876 (Scaleway) [BBR]
--> Latence: 8.51 ms [gigue: 1.60 ms]
--> Débit: 284.02 Mo/s (2.27 Gbps) [fluctuation: 1.98%]
Test TCP Internet (IPv6): téléchargement depuis l'AS 12876 (Scaleway) [CUBIC]
--> Latence: 7.70 ms [gigue: 0.34 ms]
--> Débit: 291.45 Mo/s (2.33 Gbps) [fluctuation: 0.74%]
-------------------------- 2023-03-11 14:02:21 +0100 --------------------------
-
Merci ouno, c'est parfait en ipv6 dorénavant
Test TCP local (IPv4): téléchargement depuis la Freebox
--> Latence: 0.50 ms [gigue: 0.13 ms]
--> Débit: 294.47 Mo/s (2.36 Gbps) [fluctuation: 1.47%]
Test TCP Internet (IPv6): téléchargement depuis l'AS 12876 (Scaleway) [BBR]
--> Latence: 8.51 ms [gigue: 1.60 ms]
--> Débit: 284.02 Mo/s (2.27 Gbps) [fluctuation: 1.98%]
Test TCP Internet (IPv6): téléchargement depuis l'AS 12876 (Scaleway) [CUBIC]
--> Latence: 7.70 ms [gigue: 0.34 ms]
--> Débit: 291.45 Mo/s (2.33 Gbps) [fluctuation: 0.74%]
Pas mal du tout pour du mono-connexion en Cubic :)
Et ça reste comme ça le soir aussi après 21h ?
-
En tout cas, à 19h, c'est pareil. J'ai même plus en cubic qu'en bbr ... Je pensais pas ça possible.
Je referais le test en soirée, on verra bien.
-
On est sur environ 1% de variation, je pense qu'on peut appeler ça du bruit. :)
-
C'est pas faux !
-
Ca marche merci !
Résultat :
-
Résultat :
Merci !
J'avais oublié que toute la partie jusqu'à Paris n'était pas visible dans le traceroute chez Free, du coup forcément mon traceroute ressemble beaucoup, mis à part la grosse différence de latence au premier hop visible après la box...
traceroute to ping.online.net (62.210.18.40), 30 hops max, 60 byte packets
1 192.168.1.254 (192.168.1.254) 0.295 ms 0.274 ms 0.521 ms
2 194.149.169.158 (194.149.169.158) 15.490 ms 15.512 ms 15.515 ms
3 194.149.174.48 (194.149.174.48) 15.861 ms 16.334 ms 16.437 ms
4 195.154.3.209 (195.154.3.209) 15.649 ms 15.662 ms 15.664 ms
5 62.210.0.158 (62.210.0.158) 16.253 ms 16.259 ms 16.253 ms
6 51.158.1.35 (51.158.1.35) 16.373 ms 17.096 ms 17.040 ms
7 45x-s44-2-a9k1.dc3.poneytelecom.eu (195.154.1.105) 16.992 ms 23.148 ms 23.448 ms
8 ping.online.net (62.210.18.40) 15.408 ms 15.405 ms 15.393 ms
-
à l'instant :
-
Très utile comme outil, merci ! :)
-
Très utile comme outil, merci ! :)
Merci !
CongestionProvider: BBR2
Je ne savais pas que Microsoft avait implémenté BBR dans ses derniers builds, intéressant ! :)
-
Pas mal du tout pour du mono-connexion en Cubic :)
Et ça reste comme ça le soir aussi après 21h ?
Pas eu le temps de tester avant, mais voilà ce que ça donne après 21h. C'est moins bon, mais ça reste potable ;)
-
Ok, allo docteur ? je crois que j’ai un problème non ? (V6 + ONU V1)
[checkFtthFree v0.12] Linux 5.15.94 (x86_64)
-------------------------- 2023-03-19 21:05:06 +0100 --------------------------
Paramétrage réseau actuel du système:
net.core.default_qdisc: pfifo_fast
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: 45024 60034 90048
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: 1.50 ms [gigue: 0.38 ms]
--> Débit: 116.91 Mo/s (935.29 Mbps) [fluctuation: 0.51%]
Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [BBR]
--> Latence: 16.94 ms [gigue: 40.28 ms]
--> Débit: 1.07 Mo/s (8.58 Mbps) [fluctuation: 9.82%]
Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [CUBIC]
--> Latence: 15.22 ms [gigue: 0.20 ms]
--> Débit: 1.08 Mo/s (8.65 Mbps) [fluctuation: 2.19%]
-------------------------- 2023-03-19 21:05:44 +0100 --------------------------
-
Ok, allo docteur ? je crois que j’ai un problème non ? (V6 + ONU V1)
Oui effectivement, et avec les serveurs Bouygues ça donne quoi ? (paramètre -a)
(et ton réglage de fuseau horaire n'a pas l'air bon non plus ;) )
-
Oui effectivement, et avec les serveurs Bouygues ça donne quoi ? (paramètre -a)
(et ton réglage de fuseau horaire n'a pas l'air bon non plus ;) )
Salut, c’est pareil avec Bouygues...
-
bonjour merci pour ce programme je teste ca
Test TCP local (IPv4): téléchargement depuis la Freebox
--> Latence: 0.49 ms [gigue: 0.02 ms]
--> Débit: 359.05 Mo/s (2.87 Gbps) [fluctuation: 1.53%]
Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [BBR]
--> Latence: 3.40 ms [gigue: 0.31 ms]
--> Débit: 348.68 Mo/s (2.79 Gbps) [fluctuation: 1.65%]
Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [CUBIC]
--> Latence: 2.54 ms [gigue: 0.18 ms]
--> Débit: 55.46 Mo/s (443.72 Mbps) [fluctuation: 7.51%]
[!] La connexion aux serveurs de test semble affectée par une perte de paquets prononcée
(ratio débit CUBIC/BBR: 15.91%)
-------------------------- 2023-03-19 21:31:26 +0100 --------------------------
-
bonjour merci pour ce programme je teste ca
Test TCP local (IPv4): téléchargement depuis la Freebox
--> Latence: 0.49 ms [gigue: 0.02 ms]
--> Débit: 359.05 Mo/s (2.87 Gbps) [fluctuation: 1.53%]
Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [BBR]
--> Latence: 3.40 ms [gigue: 0.31 ms]
--> Débit: 348.68 Mo/s (2.79 Gbps) [fluctuation: 1.65%]
Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [CUBIC]
--> Latence: 2.54 ms [gigue: 0.18 ms]
--> Débit: 55.46 Mo/s (443.72 Mbps) [fluctuation: 7.51%]
[!] La connexion aux serveurs de test semble affectée par une perte de paquets prononcée
(ratio débit CUBIC/BBR: 15.91%)
-------------------------- 2023-03-19 21:31:26 +0100 --------------------------
PC qui semble avoir du mal à suivre.
-
j'ai testé avec ma carte 5gb c'est mon autre pc plus 5700g .
max charge cpu 40% je pense pas mais j'essaierai avec mon 3900x demain
ca 32 go de ram nvme rtx 3080 etc ca sert pas pour le réseau mais pour dire c'est pas un vieux truc de 2000 lol
edit test ce matin avec les 2 pc :
et c'est surement pas car il est faible ou je ne sais pas quoi lol
SiSoftware Sandra
ID
Host Name : yussef961
Workgroup : WORKGROUP
Computer
Model : GigaByte B550 GAMING X B550 MB
Serial Number : Default*******
Chassis : OEM Desktop
Mainboard : GigaByte B550 GAMING X
Serial Number : Default*******
BIOS : AMI (OEM) F15 01/12/2023
TPM - Trusted Platform Module : AMD 2.0 2018 (24PCR 64Ses 2Obj)
System Memory
Total Memory : 32GB DDR4
Processors
Processor : AMD Ryzen 9 3900X 12-Core Processor (4M 12C 24T 3.8GHz/3.8GHz, 1.8GHz IMC, 12x 512kB L2, 4x 16MB L3)
Socket/Slot : AM4 (PGA1331)
Chipset
Memory Controller : AMD F19 (Ryzen3/TR3 Matisse) Host Bridge 18x 100MHz (1.8GHz), 2x 8GB DDR4 3.6GHz 128-bit
Memory Module(s)
Memory Module : G Skill Intl/SK Hynix F4-3600C16-16GTZNC 16GB DIMM DDR4 2Rx8 PC4-28800U DDR4-3604 XMP (15-15-15-36 4-51-16-3)
Memory Module : G Skill Intl/SK Hynix F4-3600C16-16GTZNC 16GB DIMM DDR4 2Rx8 PC4-28800U DDR4-3604 XMP (15-15-15-36 4-51-16-3)
Video System
Monitor/Panel : UMC SHARP
(3840x2160, 72.3")
Monitor/Panel : (Standard monitor types) Generic Monitor (1600x1200)
Video Adapter : Microsoft Remote Display Adapter (3840S 30C SM6.6 1.81GHz, 16GB DDR6 256-bit, PCIe 4.0 x16)
Graphics Processor
OpenCL : AMD Radeon RX 6800 (7680S 60C SM2.0 1.81GHz, 16GB DDR6 256-bit)
D3D 11 : AMD Radeon RX 6800 (3840S 30C SM12.1 1.81GHz, 16GB DDR6 256-bit)
OpenGL : AMD Radeon RX 6800 (120C SM4.60 1.81GHz, 31.7GB)
Storage Devices
Disk : Samsung SSD 850 PRO 512GB (512.1GB, SATA600, SSD, SED)
Disk : Samsung SSD 970 EVO Plus 1TB (1TB, PCIe3x4/NVMe, SED)
Disk : WDC WDS250G2X0C-00L350 (250GB, PCIe3x4/NVMe)
Disk : asmedia ASMT1153e (USB3)
Optical : HL-DT-ST BD-RE BH10LS30 (SATA150, BD-RE, DVD+-RW, CD-RW)
Logical Storage Devices
SSD games 512gb (B:) : 477GB (NTFS, 4kB) @ Samsung SSD 850 PRO 512GB (512.1GB, SATA600, SSD, SED)
Hard Disk (F:) : 512MB (FAT32, 4kB) @ Samsung SSD 970 EVO Plus 1TB (1TB, PCIe3x4/NVMe, SED)
SSD games 1tb (A:) : 931GB (NTFS, 4kB) @ Samsung SSD 970 EVO Plus 1TB (1TB, PCIe3x4/NVMe, SED)
Hard Disk (C:) : 232GB (NTFS, 4kB) @ WDC WDS250G2X0C-00L350 (250GB, PCIe3x4/NVMe)
Hard Disk : 625MB (NTFS, 4kB) @ WDC WDS250G2X0C-00L350 (250GB, PCIe3x4/NVMe)
Hard Disk : 96MB (FAT32, 1kB) @ WDC WDS250G2X0C-00L350 (250GB, PCIe3x4/NVMe)
Removable Drive (P:) : N/A @ asmedia ASMT1153e (USB3)
Optical Drive (E:) : N/A @ HL-DT-ST BD-RE BH10LS30 (SATA150, BD-RE, DVD+-RW, CD-RW)
Storage System
Storage Pool : Primordial (1.6TB)
Peripherals
LPC Hub Controller : Gigabyte FCH LPC Bridge
Audio Device : AMD Navi 21 HDMI Audio [Radeon RX 6800/6800 XT / 6900 XT]
Disk Controller : Samsung SSD 970 EVO Plus 1TB
Disk Controller : ASMedia ASM1062 Serial ATA Controller
Disk Controller : Sandisk WD Black 2018/PC SN720 NVMe SSD
USB Controller : ASMedia ASM1042A USB 3.0 Host Controller
USB Controller : Gigabyte F19 (Ryzen3/TR3 Starship) USB 3.0 Host Controller
SMBus/i2c Controller : AMD SB900 SMBus
Printers and Faxes
Printer : Remote Desktop Easy Print (600x600, Colour)
Printer : Remote Desktop Easy Print (600x600, Colour)
Printer : Remote Desktop Easy Print (600x600)
Printer : Remote Desktop Easy Print (300x300, Colour)
Printer : Remote Desktop Easy Print (600x600, Colour)
Printer : Send to Microsoft OneNote 16 Driver (1200x1200, Colour)
Printer : Microsoft Print To PDF (600x600, Colour)
Printer : Microsoft IPP Class Driver (600x600)
Biometrics
Voice : Analog NUI Voice Virtual Sensor (Voice)
Facial Features : Windows Hello Face Sensor (Facial Features)
Peripherals
Media Player : Samsung SSD 850 PRO 512GB (476.81GB)
Network Services
Network Adapter : ASUS XG-C100C 10G PCI-E Network Adapter (Ethernet)
Operating System
Windows System : Microsoft Windows 11 Professional 10.0.22621
Platform Compliance : x64
Virtual Machine
Hypervisor : Microsoft HyperV 10.0.22621.1413
-
en local un des deux ne dépasse pas 400Mo/s déjà :D
-
oui celui du haut c'est lié a la carte reseau, j'ai pas voulu mettre de carte 10gbit/s pour pouvoir avoir une carte graphique plus large au cas ou un jour.. (mettre a jour ma rtx 3080 j'attend la prochaine generation)
donc j'ai un adaptateur usb c -> ethernet 5gbit.
et j'arrive au max a 3.1
le pc du dessous a une carte 10gbit/s lui (dont j'ai mis les spec)
lui il est insoupsonable de toute facon ca change rien pour le premier si il est capable de 3gbit il est capable pour le reste
config du premier au dessus
gigabyte aorus elite v2 b550
5700g
rtx 3080
32 go ram etc
-
Ok, allo docteur ? je crois que j’ai un problème non ? (V6 + ONU V1)
[checkFtthFree v0.12] Linux 5.15.94 (x86_64)
-------------------------- 2023-03-19 21:05:06 +0100 --------------------------
Paramétrage réseau actuel du système:
net.core.default_qdisc: pfifo_fast
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: 45024 60034 90048
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: 1.50 ms [gigue: 0.38 ms]
--> Débit: 116.91 Mo/s (935.29 Mbps) [fluctuation: 0.51%]
Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [BBR]
--> Latence: 16.94 ms [gigue: 40.28 ms]
--> Débit: 1.07 Mo/s (8.58 Mbps) [fluctuation: 9.82%]
Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [CUBIC]
--> Latence: 15.22 ms [gigue: 0.20 ms]
--> Débit: 1.08 Mo/s (8.65 Mbps) [fluctuation: 2.19%]
-------------------------- 2023-03-19 21:05:44 +0100 --------------------------
Mon ONU est un F-MDCONU3A, il est donc bugué ? ou j'ai un pb de config ?
Pour info, depuis une box OVH:
[checkFtthFree v0.12] Linux 5.15.0-60-generic (x86_64)
-------------------------- 2023-03-20 13:03:43 +0100 --------------------------
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: 43788 58384 87576
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 Internet (IPv4): téléchargement depuis l'AS 5410 (Bouygues Telecom) [BBR]
--> Latence: 17.53 ms [gigue: 2.38 ms]
--> Débit: 72.83 Mo/s (582.66 Mbps) [fluctuation: 34.73%]
Test TCP Internet (IPv4): téléchargement depuis l'AS 5410 (Bouygues Telecom) [CUBIC]
--> Latence: 19.16 ms [gigue: 3.02 ms]
--> Débit: 17.92 Mo/s (143.38 Mbps) [fluctuation: 4.32%]
[!] La connexion aux serveurs de test semble affectée par une perte de paquets prononcée
(ratio débit CUBIC/BBR: 24.61%)
-------------------------- 2023-03-20 13:04:10 +0100 --------------------------
-
vu le nombre de probleme avec CUBIC vs BBR ca serait pas plutot cubic le probleme la?
-
Cubic fonctionne très bien, mieux que BBR sur réseau sans perte.
Plus BBR sera utilisé sur un réseau en tension et plus les performances de Cubic tomberont mais aussi celles de la plupart des algorithmes.
-
je fais confiance au spécialiste un domaine que je ne connais pas pas mais c'était question innocente vu on est beaucoup à avoir des perte ici
des algo de compression tcp c'est ça ?
-
Pour faire simple,
La machine qui reçoit gère la quantité/flux de données qu'elle voudrait traiter et en informe la machine qui émet.
La machine qui émet tient compte de ce paramètre et de la congestion qu'elle croit détecter sur le réseau. Et elle essaie d'émettre à la plus faible de ces valeurs.
Les algorithmes cités ici concernent cette gestion et détection de la congestion.
-
ah oua merci ca ressemble au handshake pour le debit max de connection un peu non?
on imagine pas la complexité derriere "internet", j'ai pourtant bien etudié osi, les paquets trames etc, on apprend toujours des truc lol
-
Ok, allo docteur ? je crois que j’ai un problème non ? (V6 + ONU V1)
[checkFtthFree v0.12] Linux 5.15.94 (x86_64)
-------------------------- 2023-03-19 21:05:06 +0100 --------------------------
Paramétrage réseau actuel du système:
net.core.default_qdisc: pfifo_fast
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: 45024 60034 90048
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: 1.50 ms [gigue: 0.38 ms]
--> Débit: 116.91 Mo/s (935.29 Mbps) [fluctuation: 0.51%]
Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [BBR]
--> Latence: 16.94 ms [gigue: 40.28 ms]
--> Débit: 1.07 Mo/s (8.58 Mbps) [fluctuation: 9.82%]
Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [CUBIC]
--> Latence: 15.22 ms [gigue: 0.20 ms]
--> Débit: 1.08 Mo/s (8.65 Mbps) [fluctuation: 2.19%]
-------------------------- 2023-03-19 21:05:44 +0100 --------------------------
Bon, je me réponds à moi-même, tout penaud, car c’était du à un switch Netgear GS108Ev3 (dernier fw 2.06.17) qui foutait la zone dans le LAN.
Curieusement le débit local avec la Freebox était bon, mais celui-ci s’écroulait dès qu’un autre PC lançait un dowlnoad (qui restait pourri à 8Mbps) sur le net en parallèle.
Le on/off alim du switch ne réglait pas le problème, seul le factory reset par le bouton a permis de retrouver le débit ! ... bug bug bug.
Il y avait quelques erreurs CRC dans la console du switch mais rien côté Freebox.
voila!, voila!
-
Bonsoir,
Merci pour la maj du soft et pour moi :
[checkFtthFree v0.12] Windows 10 Build 19042 (64-bit)
-------------------------- 2023-03-22 21:32:00 +0100 --------------------------
Paramétrage réseau actuel du système:
AutoTuningLevelLocal: Normal
CongestionProvider: CUBIC
EcnCapability: Disabled
NetworkCategory: Public
ScalingHeuristics: Disabled
Timestamps: Disabled
=> Latence TCP max pour une réception à 1 Gbps: 141 ms
Test TCP local (IPv4): téléchargement depuis la Freebox
--> Latence: 0.42 ms [gigue: 0.02 ms]
--> Débit: 295.04 Mo/s (2.36 Gbps) [fluctuation: 0.27%]
Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [BBR]
--> Latence: 6.56 ms [gigue: 0.30 ms]
--> Débit: 200.19 Mo/s (1.60 Gbps) [fluctuation: 16.96%]
Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [CUBIC]
--> Latence: 5.90 ms [gigue: 0.27 ms]
--> Débit: 8.07 Mo/s (64.54 Mbps) [fluctuation: 17.74%]
[!] La connexion aux serveurs de test semble affectée par une forte perte de paquets
(ratio débit CUBIC/BBR: 4.03%)
-------------------------- 2023-03-22 21:32:42 +0100 --------------------------
:-X :-X
-
Pas mal de lignes affectées par de la perte de paquets aux heures de pointe j'ai l'impression ???
Après ceux qui n'ont pas de souci ne postent pas forcément donc difficile de savoir vraiment la proportion...
-
oui quand je vois beaucoup de resultat comme ca et ca parait plus plausible que "ton pc ne suit pas"
-
je pense jamais à tester le soir :(
ce matin j'ai fais fumer la fibre ! Diablo IV béta télécharger sur le PC + PS5, 160Go en 30 minutes ;D
sur le PC toujours mon SSD QLC qui a du mal, donc 80Mo/s maxi (entre 40 et 80Mo/s ça bougeait pas mal) mais sur la PS5 j'étais à 110Mo/s :o
j'essaye d'y penser ce soir à faire un test, 1 fois sur 3 le matin j'ai un mauvais résultat CUBIC
-
je vais tester pour voir merci du retour
bon temps total 5 min
il a bloqué aussi a 25%? je pensais c'etait ma carte reseau qui surchauffait mais 2 fois et jai du faire pause et resume
https://www.youtube.com/watch?v=Ibipq4nC4Vo
pour ceux que ca interesse lol
-
j'ai pas fait gaffe si ça a bloqué à un moment, j'ai lancé et je faisais autre chose ;D
mais 20 minutes sur le PC et 10 minutes sur la PS5 ;D
326MB/s :o moi ça dépassait pas 80MB/s ;D
-
oui bon et encore en mettant des wget en parallete j'arrive a 8gb/s lol
j'ai freebox delta sfp+ <-> crs305 10gb sfp+ <-> module sfp+ 10gbase T <-> cable cat 7 <-> carte 10gb assus 10gbit voila
-
bon on sait que Battle.net télécharge en BBR et pas Cubic vu les vitesses ;D (enfaites j'en sais rien ;D)
-
lol j'ai aucune idee je laisse les specialiste tcp / ip j'ai vu ca en cours de reseau au cnam mais suis pas specialiste
ya t'il un truc de pas normal ici svp?
-
lol j'ai aucune idee je laisse les specialiste tcp / ip j'ai vu ca en cours de reseau au cnam mais suis pas specialiste
ya t'il un truc de pas normal ici svp?
Je ne sais pas perso j'ai Timestamps: Disabled mais bon je ne sais pas trop pourquoi et si c'est bénéfique ou non ^^
-
[checkFtthFree v0.12] Windows 10 Build 22621 (64-bit)
-------------------------- 2023-03-23 18:19:57 +0100 --------------------------
Paramétrage réseau actuel du système:
AutoTuningLevelLocal: Normal
CongestionProvider: CUBIC
EcnCapability: Disabled
NetworkCategory: Private
ScalingHeuristics: Disabled
Timestamps: Allowed
=> Latence TCP max pour une réception à 1 Gbps: 141 ms
Test TCP local (IPv4): téléchargement depuis la Freebox
--> Latence: 0.66 ms [gigue: 0.30 ms]
--> Débit: 64.81 Mo/s (518.51 Mbps) [fluctuation: 1.28%]
Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [BBR]
--> Latence: 8.49 ms [gigue: 0.26 ms]
--> Débit: 109.69 Mo/s (877.54 Mbps) [fluctuation: 2.60%]
Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [CUBIC]
--> Latence: 7.73 ms [gigue: 0.73 ms]
--> Débit: 101.71 Mo/s (813.71 Mbps) [fluctuation: 11.44%]
[!] Débit local dégradé (le matériel utilisé pour les tests ne permet pas de vérifier complètement les capacités de la connexion FTTH)
-------------------------- 2023-03-23 18:20:41 +0100 --------------------------
mince en local ça foire complet :o
-
mince en local ça foire complet :o
Oui, ça semble arriver régulièrement avec les Freebox V6 et Mini 4k : https://lafibre.info/1gb-free/freebox-v6-onu-recent-gt-30-mos-max-par-session-tcp/msg909626/#msg909626.
-
quand je test avec mon autre PC sur la même freebox je n'ai pas le soucis ???
je pense que ça vient du PC, j'ai un SSD 860 QVO qui rame en écriture, peut être le test local télécharge "en vrai", l'autre est plus vieux mais a un SSD de meilleur qualité
mais toute la soirée j'ai eu le même résultat, pas mieux que 70Mo/s en local mais plus de 100Mo/s BBR et Cubic
-
Si vous êtes sous Windows vous pouvez lancer le gestionnaire de tâches et aller dans l'onglet performance pour voir le taux d'occupation du SSD.
-
quand je test avec mon autre PC sur la même freebox je n'ai pas le soucis ???
Bizarre... Quels OS sur les 2 PC ?
je pense que ça vient du PC, j'ai un SSD 860 QVO qui rame en écriture, peut être le test local télécharge "en vrai"
Non, l'outil n'utilise jamais le système de stockage lors des tests...
D'ailleurs le problème a été reproduit chez plusieurs personnes avec un simple wget qui redirige vers /dev/null (ou "NUL" sous Windows).
-
vu le nombre de gens ici qui ont un probleme avec le test en cubic vs bbr ca viendrait pas soit de l'outil (je ne pense pas) soit plutot des serveurs, ou alors peering etc? (pas sur ce soit le mot exact pour ca)
un peu comme free a l'epoque avec youtube ou ca laggait comme pas possible le soir
-
Le test CUBIC vs BBR sert justement à mettre en évidence un souci de saturation quelque part (soit dans le réseau de collecte de Free, soit au niveau des interconnexions avec le reste d'Internet).
-
Bizarre... Quels OS sur les 2 PC ?
Non, l'outil n'utilise jamais le système de stockage lors des tests...
D'ailleurs le problème a été reproduit chez plusieurs personnes avec un simple wget qui redirige vers /dev/null (ou "NUL" sous Windows).
le vieux (i5 2500k) sans soucis Windows 10 (les tests que j'ai posté ici régulièrement) et le plus récent Windows 11 (ryzen 3700x)
je ne sais plus si les 2 sont reliés en direct ou si yen a un des deux qui passent pas un switch mais bizarre en local ça rame et BBR Cubic ça va bien ;D
Build 19045 (64-bit) pour windows 10 (sur il est relié en direct, car mon switch est éteint la journée et il est connecté)
Build 22621 (64-bit) pour Windows 11 (me semble qu'il est en direct à vérifier)
mais ma PS5 est sur le switch et elle télécharge à 110Mo/s donc pas de soucis avec le switch
-
Le test CUBIC vs BBR sert justement à mettre en évidence un souci de saturation quelque part (soit dans le réseau de collecte de Free, soit au niveau des interconnexions avec le reste d'Internet).
ah tres bien oui j'ai quand meme remarqué que un de mes coeurs est a 100% il est peut etre mal optimise niveau des threads
et un 3900x a une frequence single core elevé (quasiement comme un 9900k) donc pas le soucis qu'aurais un thread ripper ou un cpu xeon par exemple
"http://ping.online.net:80/10000Mo.dat"
j'ai vu que le logiciel testait ca. ya moyen en ligne de commande a la manno de choisir compression cubic ou bbr?
-
le vieux (i5 2500k) sans soucis Windows 10 (les tests que j'ai posté ici régulièrement) et le plus récent Windows 11 (ryzen 3700x)
je ne sais plus si les 2 sont reliés en direct ou si yen a un des deux qui passent pas un switch mais bizarre en local ça rame et BBR Cubic ça va bien ;D
Build 19045 (64-bit) pour windows 10 (sur il est relié en direct, car mon switch est éteint la journée et il est connecté)
Build 22621 (64-bit) pour Windows 11 (me semble qu'il est en direct à vérifier)
mais ma PS5 est sur le switch et elle télécharge à 110Mo/s donc pas de soucis avec le switch
Bizarre bizarre... Et quand tu lances un téléchargement manuel de http://212.27.38.253:8095/fixed/10G depuis ton Windows 11 ?
-
je me suis permis d'essayer aussi ca peut aider?
-
je me suis permis d'essayer aussi ca peut aider?
Pas vraiment non, puisque tu n'as pas le même souci que YoNeLFR pour le téléchargement local...
-
ah oui my bad en local ya une difference avec 192.168.1.254/gen/10G ? j'avais que 8gb avec
-
Bizarre bizarre... Et quand tu lances un téléchargement manuel de http://212.27.38.253:8095/fixed/10G depuis ton Windows 11 ?
64Mo/s et SSD à 100%
bon je vais le changer ;D
-
Chez moi Windows a souvent des soucis en local pour les vitesses de plusieurs Gbps.
checkFtthFree, curl et meme nspeed ont ce probleme.
J'ai fait quelque tests avec nspeed sur une machine Windows 11 (cpu 32 cores Ryzen 9 3950x) vs une machine Linux bien moins puissante (cpu 4 cores Intel i3-8109U)
Windows: curl et nspeed max 6.8 Gbps environ avec un core a 100%, checkFtthFree 5.35 Gbps
Linux: curl et nspeed 9,4 Gbps (max de l'interface 10G) et un core a 60%, checkFtthFree 8.75 Gbps
Si on regarde les compteurs de lecture (visible avec l'option -verbose sur nspeed).
Windows:
RCount=360196
RSize=29809
Linux:
RCount=270676
RSize=39668
Windows utilise un plus petit tampon (27k vs 39k) donc plus d'itérations de lecture (380k contre 270k) donc saturation d'un core de cpu ? c'est la seule explication que je vois pour le moment mais j'en suis pas certain non plus...(et franchement l'écart n'est pas énorme).
checkFtthFree et curl donnent des comportement similaires mais je n'ai pas accès aux compteurs.
pour checkFttFree, il serait bien d'ajouter si possible la valeur de ces compteurs de lecture (nombre d'appels du callback et taille moyenne du morceaux reçus) pour voir si c'est bien de la que le problème vient. Eventuellement aussi la mesure de la charge cpu pendant le test.
Pour être complet, voici les mêmes tests avec checkFtthFree:
sur le Linux:
Test TCP local (IPv4): téléchargement depuis la Freebox
--> Latence: 1.22 ms [gigue: 0.23 ms]
--> Débit: 1.08 Go/s (8.66 Gbps) [fluctuation: 6.96%]
bien qu'on atteigne pas 9,4 Gbps de moyenne on atteint bien le max a un moment (monitoring de nspeed pendant checkFtthFree):
(https://i.imgur.com/glpNNZA.png)
pour référence, même machine, même condition avec curl ou nspeed (on constate une stabilité plus grande et moins d'utilisation cpu qu'avec checkFtthFree):
(https://i.imgur.com/Re2qeTr.png)
(commande = curl -o /dev/null http://212.27.38.253:8095/fixed/10G)
ps: ces graphes mesurent le débit directement au niveau de l'interface dont sans l'overhead des couches IP+TCP+HTTP (10Gbps sur le graphe ~= 9,4 Gbps au niveau des applications donc).
pour référence les infos du Linux:
Paramétrage réseau actuel du système:
net.core.default_qdisc: fq_codel
net.core.rmem_max: 134217728
net.core.wmem_max: 134217728
net.ipv4.tcp_adv_win_scale: 1
net.ipv4.tcp_congestion_control: bbr
net.ipv4.tcp_mem: 92367 123159 184734
net.ipv4.tcp_no_metrics_save: 0
net.ipv4.tcp_rmem: 4096 87380 134217728
net.ipv4.tcp_sack: 1
net.ipv4.tcp_timestamps: 1
net.ipv4.tcp_window_scaling: 1
net.ipv4.tcp_wmem: 4096 65536 134217728
=> Latence TCP max pour une réception à 1 Gbps: 566 ms
=> Latence TCP max pour une émission à 700 Mbps: 1131 ms
Sur le Windows:
[checkFtthFree v0.12] Windows 10 Build 22624 (64-bit)
-------------------------- 2023-03-24 18:15:33 +0100 --------------------------
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 local (IPv4): téléchargement depuis la Freebox
--> Latence: 0.48 ms [gigue: 0.02 ms]
--> Débit: 669.07 Mo/s (5.35 Gbps) [fluctuation: 2.68%]
-------------------------- 2023-03-24 18:15:51 +0100 --------------------------
-
interessant : idee pour ceux qui ne savent pas ou n'y ont pas pensé :
dans le windows store on peut installer ubuntu directement tres facilement depuis windows , attention a wsl 2 etc mais la maj est facile de toute facon
-
Bonsoir,
Enième résultat toujours la même chose.
[checkFtthFree v0.12] Windows 10 Build 19042 (64-bit)
-------------------------- 2023-03-24 22:29:07 +0100 --------------------------
Paramétrage réseau actuel du système:
AutoTuningLevelLocal: Normal
CongestionProvider: CUBIC
EcnCapability: Disabled
NetworkCategory: Public
ScalingHeuristics: Disabled
Timestamps: Disabled
=> Latence TCP max pour une réception à 1 Gbps: 141 ms
Test TCP local (IPv4): téléchargement depuis la Freebox
--> Latence: 0.39 ms [gigue: 0.05 ms]
--> Débit: 295.40 Mo/s (2.36 Gbps) [fluctuation: 0.42%]
Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [BBR]
--> Latence: 6.70 ms [gigue: 0.26 ms]
--> Débit: 263.06 Mo/s (2.10 Gbps) [fluctuation: 7.65%]
Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [CUBIC]
--> Latence: 6.11 ms [gigue: 0.27 ms]
--> Débit: 9.42 Mo/s (75.37 Mbps) [fluctuation: 17.05%]
[!] La connexion aux serveurs de test semble affectée par une forte perte de paquets
(ratio débit CUBIC/BBR: 3.58%)
-------------------------- 2023-03-24 22:29:49 +0100 --------------------------
-
Chez moi Windows a souvent des soucis en local pour les vitesses de plusieurs Gbps.
checkFtthFree, curl et meme nspeed ont ce probleme.
J'ai fait quelque tests avec nspeed sur une machine Windows 11 (cpu 32 cores Ryzen 9 3950x) vs une machine Linux bien moins puissante (cpu 4 cores Intel i3-8109U)
Très intéressant, merci pour ces tests ! Pour ma part, n'ayant pas de réseau local >1Gbps je ne peux pas vraiment tester...
Cela ne m'étonne pas trop pour checkFtthFree, c'est vraiment un script tout simple qui a juste pour objectif de comparer des débits mono-connexion Internet Cubic / BBR pour évaluer la perte de paquets.
Je n'ai pas cherché à l’optimiser plus que ça car les perfs étaient largement suffisantes pour l'usage prévu, le test de débit local ne servant justement qu'à s'assurer que le système de test n'est pas limitant au niveau des débits obtenus sur Internet.
Je serais curieux de voir ce que ça donne avec un autre script que j'ai fait qui est bien plus optimisé (normalement :D ), mais je veux encore ajouter pas mal de choses avant de le publier et pour l'instant j'ai pas le temps de bosser dessus malheureusement...
Windows utilise un plus petit tampon (27k vs 39k) donc plus d'itérations de lecture (380k contre 270k) donc saturation d'un core de cpu ? c'est la seule explication que je vois pour le moment mais j'en suis pas certain non plus...(et franchement l'écart n'est pas énorme).
Est-ce que tu as la gestion automatique des interruptions et/ou le LRO d'activés au niveau du driver de la carte ?
Dans mon cas j'ai remarqué que d'un test à l'autre, sans rien changer au niveau conf et paramètres de test, Windows pouvait décider de vider le tampon de réception dès que possible en permanence pour la connexion TCP (=> énormément de petits I/O) ou alors au contraire économiser les I/O et laisser le tampon se remplir un peu. Du coup pour un même test avec exactement le même débit moyen tu peux avoir 2-3% de conso CPU ou alors 40-50%... Bref, pas très représentatif au final.
pour checkFttFree, il serait bien d'ajouter si possible la valeur de ces compteurs de lecture (nombre d'appels du callback et taille moyenne du morceaux reçus) pour voir si c'est bien de la que le problème vient. Eventuellement aussi la mesure de la charge cpu pendant le test.
En fait pour checkFtthFree je voulais vraiment un truc très simple, qui fonctionne tout seul avec un simple double-click sous Windows, et qui donne surtout les débits mono-connexion Internet et les infos d'estimation de perte de paquets grâce à la comparaison Cubic/BBR (en vérifiant quand même au passage que le système de test et sa conf ne sont pas en cause).
Les options et métriques dont tu parles sont incluses dans l'autre script que j'ai fait, qui est bien plus complet même si pas assez encore assez à mon goût...
-
intéressant le 3950x par contre a pas du tout 32 cœur c'est un 16/32 32 threads donc
sinon on pourrait avoir le code source stp ?
-
64Mo/s et SSD à 100%
bon je vais le changer ;D
Du coup tu as exactement le même débit en manuel qu'avec checkFtthFree à l'unité près si je comprends bien, donc a priori c'est pas le système de stockage qui est en cause puisque checkFtthFree ne l'utilise pas pour les tests.
Je penche plus pour une particularité de la conf réseau de ton système Windows 11...
sinon on pourrait avoir le code source stp ?
Je ne sais pas si tu parles de checkFtthFree, mais si c'est le cas les sources sont dans le script Perl lui-même (2ème lien du premier message de ce sujet).
-
parfait merci bien nickel oui de l executable
-
Du coup tu as exactement le même débit en manuel qu'avec checkFtthFree à l'unité près si je comprends bien, donc a priori c'est pas le système de stockage qui est en cause puisque checkFtthFree ne l'utilise pas pour les tests.
Je penche plus pour une particularité de la conf réseau de ton système Windows 11...
Je ne sais pas si tu parles de checkFtthFree, mais si c'est le cas les sources sont dans le script Perl lui-même (2ème lien du premier message de ce sujet).
ok merci ;D
tant que ça télécharge normalement par internet ce n'est pas bien grave
j'ai essayé par le switch, en direct sur la freebox pas moyen de dépasser 65Mo/s
même résultat avec 192.168.1.254/gen/10G (qui n'utilise pas le SSD d'ailleurs même par Firefox)
mais quand je test un fichier internet nickel ;D
-
ok merci ;D
tant que ça télécharge normalement par internet ce n'est pas bien grave
j'ai essayé par le switch, en direct sur la freebox pas moyen de dépasser 65Mo/s
même résultat avec 192.168.1.254/gen/10G (qui n'utilise pas le SSD d'ailleurs même par Firefox)
mais quand je test un fichier internet nickel ;D
De et vers l'interne de la box, les débits ne sont jamais top. Les I/O du /dev/null ne semble pas avoir une priorité de fou... Et pour les "vieilles" box genre Revo ou Mini 4K, cela se sent!
Ne pas oublier que ces box sont taillées pour faire transiter des trucs entre le WAN et le LAN (et vice-versa), mais pour gérer des trucs en interne, pas glop! ;)
-
De et vers l'interne de la box, les débits ne sont jamais top. Les I/O du /dev/null ne semble pas avoir une priorité de fou... Et pour les "vieilles" box genre Revo ou Mini 4K, cela se sent!
Ne pas oublier que ces box sont taillées pour faire transiter des trucs entre le WAN et le LAN (et vice-versa), mais pour gérer des trucs en interne, pas glop! ;)
Sauf que dans son cas il a systématiquement le souci avec sa machine sous Windows 11, et jamais avec sa machine sous Windows 10, c'est bien là que se situe la bizarrerie.
-
oui exact mon vieux windows 10 je suis à +100Mo/s local/bbr/cubic mais le plus récent windows 11 65Mo/s en local et +100Mo/s bbr/cubic ;D
-
ca pourrait pas etre lié a des pilotes differents? chipset carte mere et carte reseau?
-
ca pourrait pas etre lié a des pilotes differents? chipset carte mere et carte reseau?
Tout à fait, la mise à jour des drivers vers W11 n'est pas une réussite totale chez bien des constructeurs!
Même chez les "grands" constructeurs, cela arrive... Vraiment petit à petit, même sur du matériel dit "pro". La réinvention de la roue, façon Microsoft!
M$ n'avait pas trop déconné depuis W7, et malgré les soubresauts de W8 et sa "soeur", qui ont servi de banc d'essai à W10, les grosses déconnes s'étaient calmées... Mais il ne faut pas perdre de vue que M$ est une entreprise à pognon, et la pression marketing pousse aux conneries. C'est ainsi, il ne faut jamais l'oublier, et tout le monde dérouille peu ou prou!
-
oui un des pire moment c'etait windows vista, pas fini etc car microsoft avait voulu faire un nouveau sgf, ils ont retropedalé trop compliqué sont resté sur ntfs et ont du coup sorti un truc a la va vite
-
oui un des pire moment c'etait windows vista, pas fini etc car microsoft avait voulu faire un nouveau sgf, ils ont retropedalé trop compliqué sont resté sur ntfs et ont du coup sorti un truc a la va vite
Pour W11, il semble que ce soit un peu différent. A force de se faire reprocher les gouffres de sécurité, ils ont essayé de bétonner, et c'est là que cela coince avec pas mal de drivers, qui avaient tendance à "baver" au niveau mémoire...
-
même soucis sur le windows 11 du boulot en wifi :o (chez moi)
65Mo/s en local mais 90Mo/s sur BBR ;D
[checkFtthFree v0.12] Windows 10 Build 22621 (64-bit)
-------------------------- 2023-04-04 09:10:51 +0200 --------------------------
Paramétrage réseau actuel du système:
AutoTuningLevelLocal: Normal
CongestionProvider: CUBIC
EcnCapability: Disabled
NetworkCategory: Public
ScalingHeuristics: Disabled
Timestamps: Allowed
=> Latence TCP max pour une réception à 1 Gbps: 141 ms
Test TCP local (IPv4): téléchargement depuis la Freebox
--> Latence: 2.47 ms [gigue: 0.44 ms]
--> Débit: 63.65 Mo/s (509.19 Mbps) [fluctuation: 7.30%]
Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [BBR]
--> Latence: 10.74 ms [gigue: 0.46 ms]
--> Débit: 91.33 Mo/s (730.63 Mbps) [fluctuation: 3.59%]
Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [CUBIC]
--> Latence: 10.46 ms [gigue: 0.52 ms]
--> Débit: 69.46 Mo/s (555.72 Mbps) [fluctuation: 3.41%]
[!] Débit local dégradé (le matériel utilisé pour les tests ne permet pas de vérifier complètement les capacités de la connexion FTTH)
-------------------------- 2023-04-04 09:11:35 +0200 --------------------------
[checkFtthFree v0.12] Windows 10 Build 22621 (64-bit)
-------------------------- 2023-04-04 11:52:24 +0200 --------------------------
Paramétrage réseau actuel du système:
AutoTuningLevelLocal: Normal
CongestionProvider: CUBIC
EcnCapability: Disabled
NetworkCategory: Public
ScalingHeuristics: Disabled
Timestamps: Allowed
=> Latence TCP max pour une réception à 1 Gbps: 141 ms
Test TCP local (IPv4): téléchargement depuis la Freebox
--> Latence: 2.30 ms [gigue: 0.46 ms]
--> Débit: 75.39 Mo/s (603.12 Mbps) [fluctuation: 6.15%]
Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [BBR]
--> Latence: 10.63 ms [gigue: 0.48 ms]
--> Débit: 93.69 Mo/s (749.48 Mbps) [fluctuation: 0.29%]
Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [CUBIC]
--> Latence: 10.58 ms [gigue: 0.83 ms]
--> Débit: 81.38 Mo/s (651.06 Mbps) [fluctuation: 1.23%]
-------------------------- 2023-04-04 11:53:06 +0200 --------------------------
75Mo/s mieux en wifi qu'en ethernet :o
[checkFtthFree v0.12] Windows 10 Build 19045 (64-bit)
-------------------------- 2023-04-04 15:00:58 +0200 --------------------------
Paramétrage réseau actuel du système:
AutoTuningLevelLocal: Normal
CongestionProvider: CUBIC
EcnCapability: Disabled
NetworkCategory: Public
ScalingHeuristics: Disabled
Timestamps: Disabled
=> Latence TCP max pour une réception à 1 Gbps: 141 ms
Test TCP local (IPv4): téléchargement depuis la Freebox
--> Latence: 1.04 ms [gigue: 0.05 ms]
--> Débit: 114.49 Mo/s (915.92 Mbps) [fluctuation: 5.03%]
Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [BBR]
--> Latence: 8.93 ms [gigue: 0.37 ms]
--> Débit: 107.87 Mo/s (862.94 Mbps) [fluctuation: 1.88%]
Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [CUBIC]
--> Latence: 8.67 ms [gigue: 0.17 ms]
--> Débit: 110.70 Mo/s (885.63 Mbps) [fluctuation: 0.18%]
-------------------------- 2023-04-04 15:01:44 +0200 --------------------------
et le vieux pc windows 10 nickel ::)
-
Avec des yeux d'enfant, c'est quoi le problème de Free avec Cubic ...?
-
Avec des yeux d'enfant, c'est quoi le problème de Free avec Cubic ...?
Très mauvaise langue une fois de plus je serai: On dira que certains auraient quelque part une furieuse tendance à se "tirlipoter le chilipinpon"? (Elle n'est pas de moi, bien sûr! Mais l'intention grinçante y est, na!) ;)
-
Avec des yeux d'enfant, c'est quoi le problème de Free avec Cubic ...?
C'est juste révélateur des saturations pouvant exister dans le réseau de collecte de Free ou au niveau des interconnexions avec le reste d'Internet.
-
c'est exact mais dans certains cas c'est coté client c'est ca? donc etre sur que tout est bon de notre coté avant d'executer le logiciel...
-
c'est exact mais dans certains cas c'est coté client c'est ca? donc etre sur que tout est bon de notre coté avant d'executer le logiciel...
A mon avis si tu as un résultat mauvais Cubic et bon en BBR c'est rarement côté client. Quoi qu'il en soit l'outil checkFtthFree affiche aussi le débit local donc permet de lever pas mal de problème côté client.
-
Bonjour,
quelqu'un a t'il essayé ces parametres sur son Windows, je ne sais pas si ca apporte quelque chose de mieux :
netsh int tcp set supplemental Template=Internet CongestionProvider=bbr2
netsh int tcp set supplemental Template=Datacenter CongestionProvider=bbr2
netsh int tcp set supplemental Template=Compat CongestionProvider=bbr2
netsh int tcp set supplemental Template=DatacenterCustom CongestionProvider=bbr2
netsh int tcp set supplemental Template=InternetCustom CongestionProvider=bbr2
Get-NetTCPSetting | Select SettingName, CongestionProvider
https://stackoverflow.com/questions/60159716/how-to-enable-tcp-bbr-on-windows
chez moi la dernière commande qui affiche le réglage me donne ceci :
PS C:\> Get-NetTCPSetting | Select SettingName, CongestionProvider
SettingName CongestionProvider
----------- ------------------
Automatic
InternetCustom CUBIC
DatacenterCustom CUBIC
Compat NewReno
Datacenter CUBIC
Internet CUBIC
PS C:\>
Donc je suis en CUBIC pas defaut. J'ai vu une video youtube ou une personne faisait un test en CUBIC puis en BBR, au final l'écart de performance était vraiment très négligeable...
-
L'algo de congestion sert coté émetteur uniquement donc ne servira a rien quand on télécharge.
Et si on veut quand meme le changer, il n'est pas nécessaire de modifier les 5 templates, seul le template 'Internet' suffit.
-
L'impression d'une grosse saturation depuis chez moi (Vannes, 56) ce soir...
[checkFtthFree v0.12] Windows 10 Build 19045 (64-bit)
-------------------------- 2023-05-10 21:33:23 +0200 --------------------------
Paramétrage réseau actuel du système:
AutoTuningLevelLocal: Normal
CongestionProvider: CUBIC
EcnCapability: Disabled
NetworkCategory: Private
ScalingHeuristics: Disabled
Timestamps: Disabled
=> Latence TCP max pour une réception à 1 Gbps: 141 ms
Test TCP local (IPv4): téléchargement depuis la Freebox
--> Latence: 0.44 ms [gigue: 0.09 ms]
--> Débit: 117.59 Mo/s (940.74 Mbps) [fluctuation: 0.26%]
Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [BBR]
--> Latence: 17.58 ms [gigue: 0.24 ms]
--> Débit: 116.76 Mo/s (934.06 Mbps) [fluctuation: 1.54%]
Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [CUBIC]
--> Latence: 17.15 ms [gigue: 0.15 ms]
--> Débit: 12.59 Mo/s (100.75 Mbps) [fluctuation: 41.79%]
[!] La connexion aux serveurs de test semble affectée par une perte de paquets prononcée
(ratio débit CUBIC/BBR: 10.79%)-------------------------- 2023-05-10 21:34:03 +0200 --------------------------
Lors de mes précédents tests, ce ratio avait plutôt l'habitude de tourner vers 50-60%.
-
Hello
Même sensation ce soir. Le problème est pour joindre les services google (130 ms mini)
[checkFtthFree v0.12] Windows 10 Build 22621 (64-bit)
-------------------------- 2023-05-10 22:15:55 +0200 --------------------------
Paramétrage réseau actuel du système:
AutoTuningLevelLocal: Normal
CongestionProvider: CUBIC
EcnCapability: Disabled
NetworkCategory: Private
ScalingHeuristics: Disabled
Timestamps: Allowed
=> Latence TCP max pour une réception à 1 Gbps: 141 ms
Test TCP local (IPv4): téléchargement depuis la Freebox
--> Latence: 0.51 ms [gigue: 0.03 ms]
--> Débit: 141.94 Mo/s (1.14 Gbps) [fluctuation: 3.16%]
Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [BBR]
--> Latence: 6.12 ms [gigue: 0.21 ms]
--> Débit: 197.88 Mo/s (1.58 Gbps) [fluctuation: 4.35%]
Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [CUBIC]
--> Latence: 5.46 ms [gigue: 0.15 ms]
--> Débit: 27.71 Mo/s (221.67 Mbps) [fluctuation: 15.27%]
[!] La connexion aux serveurs de test semble affectée par une perte de paquets prononcée
(ratio débit CUBIC/BBR: 14.00%)
-------------------------- 2023-05-10 22:16:36 +0200 --------------------------
J'ai un réseau local en 10G et le pc utilisé est en 2.5G.
Mon routeur ubiquiti m'indique de forte pertes de paquets ce soir.
(https://mycloud.h3ms.fr/s/fwSRFbgypDi5zod/preview)
Le débit au global est bon (sur testdedebit.info j'obtiens 2gbps)
Qué passa? ^^'
-
J'ai remarqué ça aussi, je pense qu'il y a effectivement un souci généralisé au niveau de l'interconnexion entre Google et Free.
-
Sauf que c'est pas la première fois qu'on le remarque ...
-
C'est un souci à l'interco, Underground à raison.
Détermination de l’itinéraire vers google.fr [216.58.215.35]
avec un maximum de 30 sauts :
1 <1 ms <1 ms * 10.0.0.1
2 5 ms 5 ms 5 ms 194.149.169.81
3 5 ms 5 ms 5 ms arl95-1-v904.intf.nra.proxad.net [78.254.247.133]
4 * 122 ms 121 ms 72.14.220.92
5 * 123 ms 121 ms 108.170.231.95
6 125 ms 128 ms 126 ms 72.14.237.93
7 125 ms 124 ms 122 ms par21s17-in-f3.1e100.net [216.58.215.35]
-
que le soir ou toute la journée ?
C:\Users\YoNeL>tracert google.fr
Détermination de l’itinéraire vers google.fr [2a00:1450:4007:80b::2003]
avec un maximum de 30 sauts :
1 <1 ms <1 ms <1 ms 2a01:::1
2 4 ms 1 ms 1 ms 2a01:::ffff
3 * * * Délai d’attente de la demande dépassé.
4 * * * Délai d’attente de la demande dépassé.
5 * * * Délai d’attente de la demande dépassé.
6 * * * Délai d’attente de la demande dépassé.
7 7 ms 8 ms 7 ms google-ic344096-prs-b3.ip.twelve99-cust.net [2001:2000:3080:1b2c::2]
8 8 ms 8 ms 8 ms 2a00:1450:80cf::1
9 8 ms 8 ms 7 ms 2001:4860:0:1::7004
10 8 ms * 17 ms 2001:4860:0:1::4943
11 8 ms 8 ms 8 ms par10s40-in-x03.1e100.net [2a00:1450:4007:80b::2003]
Itinéraire déterminé.
C:\Users\YoNeL>tracert 216.58.215.35
Détermination de l’itinéraire vers par21s17-in-f3.1e100.net [216.58.215.35]
avec un maximum de 30 sauts :
1 <1 ms <1 ms <1 ms 192.168.1.254
2 8 ms 8 ms 8 ms station11.multimania.isdnet.net [194.149.174.108]
3 8 ms 8 ms 9 ms station17.multimania.isdnet.net [194.149.174.114]
4 8 ms 7 ms 8 ms 72.14.220.92
5 8 ms 8 ms 8 ms 108.170.231.95
6 9 ms 9 ms 9 ms 72.14.237.93
7 9 ms 8 ms 8 ms par21s17-in-f3.1e100.net [216.58.215.35]
Itinéraire déterminé.
je ne sais pas si c'est lié mais un soir j'ai stream vers youtube, et mon stream n'existe pas dans youtube studio ??? d'habitude aucun soucis
-
Bonjour à tous,
Passage récent de Sosh à Free Pop :)
Voici le résultat du script un lundi matin à 9h50, donc à priori au moment où le réseau est assez peu saturé.
[checkFtthFree v0.12] Windows 10 Build 19045 (64-bit)
-------------------------- 2023-05-29 09:52:52 +0200 --------------------------
Paramétrage réseau actuel du système:
AutoTuningLevelLocal: Normal
CongestionProvider: CUBIC
EcnCapability: Disabled
NetworkCategory: Private
ScalingHeuristics: Disabled
Timestamps: Disabled
=> Latence TCP max pour une réception à 1 Gbps: 141 ms
Test TCP local (IPv4): téléchargement depuis la Freebox
--> Latence: 0.84 ms [gigue: 0.21 ms]
--> Débit: 294.04 Mo/s (2.35 Gbps) [fluctuation: 0.39%]
Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [BBR]
--> Latence: 3.82 ms [gigue: 0.36 ms]
--> Débit: 294.56 Mo/s (2.36 Gbps) [fluctuation: 1.08%]
Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [CUBIC]
--> Latence: 3.35 ms [gigue: 0.18 ms]
--> Débit: 69.82 Mo/s (558.55 Mbps) [fluctuation: 4.49%]
[!] La connexion aux serveurs de test semble affectée par une perte de paquets prononcée
(ratio débit CUBIC/BBR: 23.70%)
-------------------------- 2023-05-29 09:53:40 +0200 --------------------------
Appuyer sur Entrée pour quitter...
Je passe de 2,35Gbps à 558Mbps de BBR à CUBIC. Pas terrible non ?
Curieux de voir ce soir à 21h...
Autre chose, comment savoir si "sur le terrain" (Youtube, Netflix, VM AWS, etc.) c'est CUBIC ou BBR qui est utilisé ? Si CUBIC n'est jamais utilisé je ne vois pas du coup pourquoi s'embêter si le résultat est mauvais. Je concède ne rien y connaitre en protocoles de contrôle de congestion.
-
Bonjour à tous,
Passage récent de Sosh à Free Pop :)
Voici le résultat du script un lundi matin à 9h50, donc à priori au moment où le réseau est assez peu saturé.
Je passe de 2,35Gbps à 558Mbps de BBR à CUBIC. Pas terrible non ?
Curieux de voir ce soir à 21h...
Autre chose, comment savoir si "sur le terrain" (Youtube, Netflix, VM AWS, etc.) c'est CUBIC ou BBR qui est utilisé ? Si CUBIC n'est jamais utilisé je ne vois pas du coup pourquoi s'embêter si le résultat est mauvais. Je concède ne rien y connaitre en protocoles de contrôle de congestion.
Sauf erreur de ma part, tout ce qui est streaming serait en UDP, qui ne garantit pas l'intégrité de la transmission... Les tests sur TCP, auraient alors une signification très biaisée, mais seraient peut-être le signe avant-coureur de pertes de flux potentielles sur le streaming, mais serait-ce sensiblement ressenti?
-
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.
-
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.
-
C'est effectivement un peu bizarre d'avoir une différence aussi marquée dans la matinée. C'est reproductible sur plusieurs tests ? Si oui, on peut imaginer une saturation locale liée à un incident ou à une maintenance qui réduit les capacités disponibles.
-
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.
Merci, effectivement avec de l'UDP, difficile de s'assurer que le "produit" est bien transporté et arrivé à bon port... Lundi de pentecôte = neurones ensommeillés pour ma part! ;)
-
C'est effectivement un peu bizarre d'avoir une différence aussi marquée dans la matinée. C'est reproductible sur plusieurs tests ? Si oui, on peut imaginer une saturation locale liée à un incident ou à une maintenance qui réduit les capacités disponibles.
Reproducible oui. Je renterai ce soir en heure de pointe puis dans les prochains jours pour voir si ça évolue.
-
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 --------------------------
-
Je viens de faire deux tests avec l'application nPerf dernière version, sur mon PC windows. J'ai bien un meilleur débit download sur BBR (Appliwave), ~6 Gb/s, que sur Cubic (Hivane), 2.6 Gb/s, mais à ces débits là, je ne pense pas que l'on puisse parler de saturation...
-
Les mêmes, en IPV6. Paradoxalement, la latence en IPv6 est moins bonne qu'en IPv4.
-
Attention, checkFtthFree fait un test mono-thread alors que nPerf est en multithread (au moins par défaut). Le fait d'avoir plusieurs threads tend à cacher l'impact des saturations.
-
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 --------------------------
-
Je ne vois rien non plus avec ma Freebox Revolution, pourtant je dois être relié au même PoP qu'Alain qui a des débits inférieurs au mien en CUBIC alors qu'il a une Freebox Delta.
-
Ç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.
-
Attention, checkFtthFree fait un test mono-thread alors que nPerf est en multithread (au moins par défaut). Le fait d'avoir plusieurs threads tend à cacher l'impact des saturations.
Oui, mais quand même, cela montre qu'un lundi matin de Pentecôte, il n'y a pas vraiment de saturation du réseau Free. Cette histoire est plus compliquée que simplement une meilleure efficacité de BBR vs CUBIC en cas de saturation.
-
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.
-
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.
Je sortais ça d'un document mentionné récemment par Vivien (https://lafibre.info/qos-mobile/protocole-qos-arcep-2023/msg1011765/?topicseen#msg1011765) mais ça date de 2020 donc ça a effectivement pu changer.
Edit : Début 2023, Vivien semblait toujours penser que c'était du Cubic : https://lafibre.info/tcpip/bbr/msg999673/#msg999673.
-
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.
-
Mais donc la latence est meilleure en Cubic qu'en BBR... Tout ce que tu peux dire c'est que tu constates un meilleur débit en BBR qu'en Cubic, pas qu'il y a une saturation.
-
Mais donc la latence est meilleure en Cubic qu'en BBR... Tout ce que tu peux dire c'est que tu constates un meilleur débit en BBR qu'en Cubic, pas qu'il y a une saturation.
La latence de quoi ? mesuré comment ?
tu peux avoir un lien Terre-Lune avec plusieurs secondes de latence et aucune perte de paquet parce que il n'est pas saturé.
tu peux avoir un lien sur 1 metre avec 0,01 ms de latence mais un paquet sur deux est perdu car complétement saturé.
-
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] } },
-
Je sortais ça d'un document mentionné récemment par Vivien (https://lafibre.info/qos-mobile/protocole-qos-arcep-2023/msg1011765/?topicseen#msg1011765) mais ça date de 2020 donc ça a effectivement pu changer.
Edit : Début 2023, Vivien semblait toujours penser que c'était du Cubic : https://lafibre.info/tcpip/bbr/msg999673/#msg999673.
Il se trompait déjà en 2020.
-
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] } },
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.
-
Il se trompait déjà en 2020.
Cela semble en effet se confirmer ici, en notant que BBR n'est pas un protocole fair, et pompe le débit des autres.
https://www.compiralabs.com/post/netflix-is-killing-my-other-streaming-services
-
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.
-
Cela semble en effet se confirmer ici, en notant que BBR n'est pas un protocole fair, et pompe le débit des autres.
https://www.compiralabs.com/post/netflix-is-killing-my-other-streaming-services
C'était effectivement l'article sur lequel j'étais tombé. Et j'en avais trouvé un autre, où Netflix s'exprimait avec chiffre à la clé, sur les bénéfices de ce protocole sur leur réseau.
-
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é.
-
Oui, cela peut être aussi la box, ou un équipement interne. Là, je pense que le fait que deux tests dans des régions différentes, avec du matériel différent, exclue cette hypothèse comme d'autres (routeurs régional défectueux, serveur défectueux). J'ai toujours pensé une particularité plus subtile du réseau Free qui se révélait dans ces tests. On sait aussi que les tests de débit chez Free montent moins haut en général par thread chez Free que chez ses concurrents, indépendamment du protocole BBR ou Cubic.
Il n'y a aucune raison qu'il y ait une saturation générale un lundi matin de Pentecôte.
P.S : en ce qui me concerne, le test que j'ai montré était je le rappelle sur une VM sur la Freebox, donc aucun autre matériel concerné que la Freebox.
-
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)
-
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...
Oui, je parlais de celle-là. Normalement, quand on constate une saturation sur le chemin, je suppose que tu testes bien la latence sur les mêmes serveurs ?, on observe que la latence augmente. Là, déjà rien que qu'avec une latence de 3-4 ms, normale en région parisienne, on peu dire qu'il n'y a pas d'augmentation de latence qui indiquerait une saturation quelconque.
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")
Exact, j'avais pourtant fait -h, mais pas remarqué cette option.
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)
Alors là, j'ai fait le test, en IPv6, pas de perte de paquets prononcée, en IPv4 oui... Mais les valeurs me paraissent pas très éloignées, 14.7 et 17.9%, et dans les deux quand même assez éloignées de la normale.
$ ./checkFtthFree.pl -6
...
[checkFtthFree v0.12] Linux 5.4.0-148-generic (aarch64)
-------------------------- 2023-05-29 13:16:55 +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.72 ms [gigue: 0.04 ms]
--> Débit: 197.11 Mo/s (1.58 Gbps) [fluctuation: 0.92%]
Test TCP Internet (IPv6): téléchargement depuis l'AS 12876 (Scaleway) [BBR]
--> Latence: 3.98 ms [gigue: 0.34 ms]
--> Débit: 218.85 Mo/s (1.75 Gbps) [fluctuation: 0.96%]
Test TCP Internet (IPv6): téléchargement depuis l'AS 12876 (Scaleway) [CUBIC]
--> Latence: 3.38 ms [gigue: 0.19 ms]
--> Débit: 32.23 Mo/s (257.84 Mbps) [fluctuation: 3.63%]
[!] La connexion aux serveurs de test semble affectée par une perte de paquets prononcée
(ratio débit CUBIC/BBR: 14.73%)
-------------------------- 2023-05-29 13:17:33 +0000 --------------------------
$ ./checkFtthFree.pl
...
[checkFtthFree v0.12] Linux 5.4.0-148-generic (aarch64)
-------------------------- 2023-05-29 13:17:44 +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.67 ms [gigue: 0.01 ms]
--> Débit: 199.00 Mo/s (1.59 Gbps) [fluctuation: 1.03%]
Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [BBR]
--> Latence: 3.77 ms [gigue: 0.21 ms]
--> Débit: 215.92 Mo/s (1.73 Gbps) [fluctuation: 6.86%]
Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [CUBIC]
--> Latence: 3.31 ms [gigue: 0.23 ms]
--> Débit: 38.61 Mo/s (308.89 Mbps) [fluctuation: 13.78%]
[!] La connexion aux serveurs de test semble affectée par une perte de paquets prononcée
(ratio débit CUBIC/BBR: 17.88%)
-------------------------- 2023-05-29 13:18:22 +0000 --------------------------
-
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 --------------------------
-
faisons avec iperf3 pour lever tout doute:
memes machines de chaque coté:
CAS 1
------
PC chez Free (freepro en l'occurence) - serveur chez Scaleway
BBR: 6,6 Gbps
iperf3 -c scaleway.testdebit.info -p 9239 -R -C bbr
...
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.04 sec 7.77 GBytes 6.64 Gbits/sec 254306 sender
[ 5] 0.00-10.00 sec 7.75 GBytes 6.66 Gbits/sec receiver
CUBIC: 1 Gbps
iperf3 -c scaleway.testdebit.info -p 9239 -R -C cubic
....
[ 5] 0.00-10.04 sec 1.21 GBytes 1.04 Gbits/sec 184 sender
[ 5] 0.00-10.00 sec 1.20 GBytes 1.03 Gbits/sec receiver
on remarquera le nombre élevé de retransmissions en bbr, 254k contre 184 en cubic montrant bien les pertes de paquets.
résultats similaires et conformes a checkftthfree
résultats similaire en utilisant paris.testdebit.info (Bytel).
On peut se dire c'est la faute des serveurs chez Scaleway ET chez Bytel ? aucun autre FAI que Free n'a d'offre au delà de 2Gbps donc difficile de comparer. Mais on peut avec une VM dans un DC:
CAS 2
------
VM chez GCP (c'est gratuit si vous voulez tester vous meme)
BBR: 4.7 Gbps
$ iperf3 -c scaleway.testdebit.info -p 9239 -R -C bbr
...[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.04 sec 5.54 GBytes 4.74 Gbits/sec 1 sender
[ 5] 0.00-10.00 sec 5.53 GBytes 4.75 Gbits/sec receiver
CUBIC: 4.6 Gbps
$ iperf3 -c scaleway.testdebit.info -p 9239 -R -C cubic
...
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.04 sec 5.35 GBytes 4.58 Gbits/sec 21 sender
[ 5] 0.00-10.00 sec 5.34 GBytes 4.59 Gbits/sec receiver
donc en pratique, aucune différence. pour sur le lien n'est absolument pas saturé.
Dans les 2 cas, c'est du peering direct il n'y a pas d'AS intermédiaire dans les traceroute.
Y'a donc bien un souci avec Free et a priori avec JN (freepro) aussi ... donc cette perte de paquets serait dans la partie FTTH (commune a Free et Freepro) ?
Donc soit c'est les freebox qui ont un souci a haut débit (>1Gbps) soit le réseau de collecte de Free est saturé ou perd des paquets. Dans les 2 cas y'a clairement un problème chez Free.
-
Mais donc il y a très peu de raison que ce soit une saturation du réseau Free, ou même de ses interconnexions, un lundi de pentecôte en milieu d'après-midi... Ce que confirment les chiffres de latence, les tests Nperf, un test ookla en mono-connexion sur le serveur Milkywan, et un test Netflix, voir ci-dessous.
Il y en a des particularités sur le réseau Free, comme d'utiliser du 10G-EPON (le seul), un tunnel IPv6 pour encapsuler l'IPv4 avec 4rd remontant à Paris (le seul)... Et probablement d'autres qui pourraient être à l'origine du problème.
-
C'est de l'IPv6 dans mes tests.
Mais donc il y a très peu de raison que ce soit une saturation du réseau Free, ou même de ses interconnexions, un lundi de pentecôte en milieu d'après-midi... Ce que confirment les chiffres de latence, les tests Nperf, un test ookla en mono-connexion sur le serveur Milkywan, et un test Netflix, voir ci-dessous.
Je ne vois pas ce que confirme la latence ou tes tests vis a vis d'une saturation... ou meme un lundi de pentecote. surtout un lundi de pentecote, un réseau GP est plus sollicité en journée.
-
En ce moment, tout le monde est en voiture à rentrer, ou dans la nature, vu le temps qu'il fait.
-
N'oubliez pas que c'est un jour férié pas comme les autres, la fameuse "journée de solidarité" (qui est travaillée, selon vos conventions / entreprises).
-
Ce qui m'étonne le plus c'est que j'ai un meilleur débit qu'Alain en Cubic alors qu'on est vraiment géographiquement très proches :
[checkFtthFree v0.12] Windows 10 Build 19045 (64-bit)
-------------------------- 2023-05-29 16:27:41 +0200 --------------------------
Paramétrage réseau actuel du système:
AutoTuningLevelLocal: Normal
CongestionProvider: CUBIC
EcnCapability: Disabled
NetworkCategory: Private
ScalingHeuristics: Disabled
Timestamps: Disabled
=> Latence TCP max pour une réception à 1 Gbps: 141 ms
Test TCP local (IPv4): téléchargement depuis la Freebox
--> Latence: 0.77 ms [gigue: 0.18 ms]
--> Débit: 117.34 Mo/s (938.71 Mbps) [fluctuation: 0.89%]
Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [BBR]
--> Latence: 3.57 ms [gigue: 0.44 ms]
--> Débit: 110.63 Mo/s (885.03 Mbps) [fluctuation: 0.41%]
Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [CUBIC]
--> Latence: 3.14 ms [gigue: 0.22 ms]
--> Débit: 110.67 Mo/s (885.37 Mbps) [fluctuation: 0.21%]
-------------------------- 2023-05-29 16:28:23 +0200 --------------------------
Il y a forcément des "frontières" au niveau de la collecte donc ça veut pas forcément dire grand chose mais en tout cas c'est très localisé.
-
hypothese: collecte en agrégation de liens physiques de N x 1 Gbps plutôt que liens directement en 10Gbps ou 100Gbps comme font les autres FAI.
-
hypothese: collecte en agrégation de liens physiques de N x 1 Gbps plutôt que liens directement en 10Gbps ou 100Gbps comme font les autres FAI.
Impossible. Enfin faux.
Heureusement que c'est qu'une hypothèse 😅🤣
-
Déjà, pour atteindre 10 Gb/s, il faudrait 10 liens 1 Gb, donc 10 ports. Cela fait trop de ports et de SFP, alors qu'un port SFP+ et un module SFP+ ne coûte plus grand chose. Peu crédible.
-
Déjà, pour atteindre 10 Gb/s, il faudrait 10 liens 1 Gb, donc 10 ports. Cela fait trop de ports et de SFP, alors qu'un port SFP+ et un module SFP+ ne coûte plus grand chose. Peu crédible.
Et si c'est de la collecte, il faut soit 10 fibres inter sites, soit des tiroirs dwdm de chaque côté (et des optiques qui coûtent très cher) pour par une ou 2 fibres, dans les 2 cas c'est économiquement pas viable et stupide.
-
je suppose que tu testes bien la latence sur les mêmes serveurs ?
Ou bien sûr, l'outil teste la latence avec le serveur qui va servir au test de débit qui est fait juste après (le but étant de s'assurer que la configuration de la mémoire tampon TCP n'est pas le facteur limitant pour le test, et pour cela il faut connaître la latence...).
Alors là, j'ai fait le test, en IPv6, pas de perte de paquets prononcée, en IPv4 oui... Mais les valeurs me paraissent pas très éloignées, 14.7 et 17.9%, et dans les deux quand même assez éloignées de la normale.
Je ne comprends pas très bien pourquoi tu indiques qu'en IPv6 tu n'as pas de perte de paquets prononcée ? D'après tes résultats juste en dessous:
$ ./checkFtthFree.pl -6
...
[!] La connexion aux serveurs de test semble affectée par une perte de paquets prononcée
(ratio débit CUBIC/BBR: 14.73%)
Et donc sur les serveurs Bouygues Telecom (option -a), pas de perte de paquets significative, mais quand même 14.6%...
Pareil pour Bouygues, d'après tes résultats:
$ ./checkFtthFree.pl -a
...
[!] La connexion aux serveurs de test semble affectée par une perte de paquets prononcée
(ratio débit CUBIC/BBR: 14.64%)
-
Effectivement, tu as raison, j'avais mal lu.
P.S : J'ai fait un traceroute MTR sur le premier serveur utilisé. Je n'ai aucune perte de paquet. Bien sûr, c'est de l'ICMP et pas du TCP, mais je pense que s'il y avait une saturation, il devrait y avoir des pertes de paquets aussi en ICMP.
$ mtr -zwc100 ipv4.scaleway.testdebit.info
Start: 2023-05-29T20:43:28+0000
HOST: ubuntu-box Loss% Snt Last Avg Best Wrst StDev
1. AS??? 192.168.0.254 0.0% 100 0.3 0.3 0.2 0.4 0.0
2. AS??? 194.149.169.81 1.0% 100 3.2 3.1 2.4 4.4 0.4
3. AS??? 194.149.174.48 0.0% 100 3.1 3.3 2.5 4.2 0.3
4. AS12876 195.154.3.209 0.0% 100 2.6 3.0 2.4 4.0 0.3
5. AS12876 62.210.0.150 0.0% 100 3.3 3.0 2.4 4.1 0.4
6. AS12876 51.158.1.43 0.0% 100 2.9 3.2 2.7 3.9 0.3
7. AS12876 45x-s44-2-a9k2.dc3.poneytelecom.eu 3.0% 100 3.5 3.8 2.9 9.0 1.0
8. AS12876 hopus.jesuisfrancobelge.eu 0.0% 100 3.0 2.9 2.4 4.1 0.3
-
Ce qui m'étonne le plus c'est que j'ai un meilleur débit qu'Alain en Cubic alors qu'on est vraiment géographiquement très proches :
Lorsque tu fais les tests en IPv6 tu as les mêmes résultats ?
Est-ce que vous avez comparé vos traceroute respectifs vers ping6.online.net et ipv6.bouygues.testdebit.info ?
-
En ce qui me concerne :
$ mtr -6 -zwc10 ping6.online.net
Start: 2023-05-29T20:51:06+0000
HOST: ubuntu-box Loss% Snt Last Avg Best Wrst StDev
1. AS12322 2a01:e0a:21b:96a0::1 0.0% 10 0.3 0.3 0.3 0.4 0.0
2. AS12322 2a01:e00:206f:f836:8bdf::ffff 0.0% 10 2.6 2.3 1.7 3.3 0.5
3. AS12322 2a01:e00:206f:1700::ffff 0.0% 10 1.6 1.9 1.6 2.2 0.2
4. AS12322 2a01:e00:206f::2 40.0% 10 1.5 1.9 1.5 2.5 0.3
5. AS12322 2a01:e00:2d::a 0.0% 10 3.0 2.5 2.3 3.0 0.2
6. AS12322 2a01:e00:6004::5 80.0% 10 3.4 3.4 3.3 3.4 0.1
7. AS??? ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
8. AS12876 2001:bc8:0:2::24 0.0% 10 3.6 3.1 2.7 3.6 0.3
9. AS12876 2001:bc8:0:1::45 0.0% 10 3.1 3.3 2.9 3.7 0.3
10. AS12876 2001:bc8:0:1::b6 0.0% 10 3.1 3.4 2.9 4.1 0.4
11. AS12876 ping6.online.net 0.0% 10 2.5 2.7 2.3 3.1 0.3
$ mtr -6 -zwc10 ipv6.bouygues.testdebit.info
Start: 2023-05-29T20:52:03+0000
HOST: ubuntu-box Loss% Snt Last Avg Best Wrst StDev
1. AS12322 2a01:e0a:21b:96a0::1 0.0% 10 0.4 0.4 0.3 0.4 0.0
2. AS12322 2a01:e00:206f:f836:8bdf::ffff 0.0% 10 2.1 2.3 1.8 3.4 0.5
3. AS12322 2a01:e00:206f:1700::ffff 0.0% 10 2.2 1.9 1.5 2.3 0.3
4. AS12322 2a01:e00:206f::2 50.0% 10 2.3 2.1 1.5 2.4 0.4
5. AS??? ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
6. AS12322 2a01:e00:6004::5 60.0% 10 3.1 3.3 2.8 3.8 0.4
7. AS5410 2001:860:0:81::1 0.0% 10 2.7 2.6 2.2 2.9 0.3
8. AS5410 2001:860:bbee:b4::2 0.0% 10 3.7 3.4 3.0 3.7 0.2
9. AS5410 2001:860:bbe0:128::2 0.0% 10 3.6 3.9 3.5 4.2 0.2
-
Je ne vois pas de différence en IPv6 et quand je passe sur les serveurs de ByTel plutôt que Scaleway.
Pour les traceroutes, sans reverse DNS et avec certains sauts qui ne répondent pas, je ne sais pas trop ce qu'on peut conclure.
|------------------------------------------------------------------------------------------|
| WinMTR statistics |
| Host - % | Sent | Recv | Best | Avrg | Wrst | Last |
|------------------------------------------------|------|------|------|------|------|------|
| 2a01:e0a:xxxx:xxxx::1 - 0 | 130 | 130 | 0 | 0 | 8 | 0 |
| 2a01:e00:2d:f836:392::ffff - 0 | 130 | 130 | 1 | 2 | 9 | 2 |
| 2a01:e00:2d:1700::ffff - 5 | 111 | 106 | 1 | 2 | 16 | 16 |
| Request timed out. - 100 | 26 | 0 | 0 | 0 | 0 | 0 |
| 2a01:e00:6004::5 - 50 | 44 | 22 | 0 | 2 | 4 | 4 |
| 2001:bc8:0:2::11 - 17 | 78 | 65 | 0 | 2 | 13 | 2 |
| 2001:bc8:0:2::26 - 10 | 94 | 85 | 0 | 3 | 14 | 2 |
| 2001:bc8:0:1::3b - 0 | 130 | 130 | 2 | 3 | 10 | 3 |
| 2001:bc8:0:1::b6 - 1 | 126 | 125 | 2 | 4 | 13 | 7 |
| ping6.online.net - 0 | 129 | 129 | 2 | 3 | 10 | 3 |
|________________________________________________|______|______|______|______|______|______|
|------------------------------------------------------------------------------------------|
| WinMTR statistics |
| Host - % | Sent | Recv | Best | Avrg | Wrst | Last |
|------------------------------------------------|------|------|------|------|------|------|
| 2a01:e0a:xxxx:xxxx::1 - 0 | 107 | 107 | 0 | 0 | 4 | 0 |
| 2a01:e00:2d:f836:392::ffff - 0 | 107 | 107 | 1 | 2 | 8 | 2 |
| 2a01:e00:2d:1700::ffff - 20 | 61 | 49 | 0 | 2 | 14 | 2 |
| Request timed out. - 100 | 21 | 0 | 0 | 0 | 0 | 0 |
| 2a01:e00:6004::5 - 44 | 39 | 22 | 0 | 3 | 11 | 11 |
| 2001:860:0:81::1 - 0 | 107 | 107 | 2 | 2 | 3 | 3 |
| 2001:860:bbee:b4::2 - 0 | 107 | 107 | 2 | 2 | 4 | 2 |
| 2001:860:bbe0:128::2 - 0 | 107 | 107 | 3 | 3 | 5 | 4 |
| 2001:860:de01:1100::2 - 0 | 107 | 107 | 2 | 2 | 7 | 3 |
|________________________________________________|______|______|______|______|______|______|
-
Pour les traceroutes, sans reverse DNS et avec certains sauts qui ne répondent pas, je ne sais pas trop ce qu'on peut conclure.
C'est sûr que ça serait mieux avec les reverses, mais on peut quand même constater que malgré votre proximité géographique les traceroutes ne se rejoignent qu'au 5-6ème hop (alain_p ayant un hop de plus...):
6. AS12322 2a01:e00:6004::5
Il n'est donc pas si étonnant qu'il puisse y avoir des différences de comportement entre vos 2 lignes (par exemple si l'un des équipements traversés dans le cas de alain_p a une conf en shallow buffers et pas dans ton cas...).
-
Le truc c'est qu'on sait pas trop ce qu'il se passe à mon 4e hop (qui pourra être commun) et combien de hops sont liés à des équipements directement dans le NRO.
-
Le truc c'est qu'on sait pas trop ce qu'il se passe à mon 4e hop (qui pourra être commun) et combien de hops sont liés à des équipements directement dans le NRO.
Vous êtes géographiquement proches, mais clairement pas connecté à la même infra de collecte. Alain a un hop de plus que toi et vous avez un first hop différent.
Il y a peu de chances que vous soyez sur le même OLT (d'une part par la distance géographique, d'autre part parce que chez free, il me semble que les OLT sont L3, et on voit que le first hop est différent sur vos traceroutes). J'émet l'hypothèse que vous n'êtes pas non plus raccordés au même routeur de collecte (peut-être même pas sur le même NRO?), et que le sien est daisy chained avec le tien (i.e. il passe par le tien avant d'atteindre le core network de free).
-
Ce qui est "marrant" c'est que si je monte le VPN je n'ai plus aucune perte de paquet selon le script et un débit plus élevé en CUBIC (1Gbps au lieu de 600Mbps soit presque le double).
Avec VPN :
Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [BBR]
--> Latence: 45.52 ms [gigue: 7.80 ms]
[!] Latence élevée pour une connexion FTTH
--> Débit: 131.18 Mo/s (1.05 Gbps) [fluctuation: 1.44%]
Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [CUBIC]
--> Latence: 43.72 ms [gigue: 6.51 ms]
[!] Latence élevée pour une connexion FTTH
--> Débit: 133.01 Mo/s (1.06 Gbps) [fluctuation: 2.82%]
Sans VPN (même heure, mêmes serveurs) :
Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [BBR]
--> Latence: 3.42 ms [gigue: 0.22 ms]
--> Débit: 289.40 Mo/s (2.32 Gbps) [fluctuation: 2.54%]
Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [CUBIC]
--> Latence: 2.96 ms [gigue: 0.37 ms]
--> Débit: 69.51 Mo/s (556.09 Mbps) [fluctuation: 8.73%]
[!] La connexion aux serveurs de test semble affectée par une perte de paquets prononcée
(ratio débit CUBIC/BBR: 24.02%)
Donc j'aurais du mal à mettre le réseau de collecte en cause sur ce coup... ça sent plus le problème de saturation sur un peering non ?
-
Note que le VPN empêche les équipements réseau d'inspecter le traffic, donc les "optimisations" réalisées dans le but de limiter la congestion (random early drop pas si random que ca?) ne sont pas nécessairement appliquées. Si ces optimisations existent, bien évidemment.
-
Vous êtes géographiquement proches, mais clairement pas connecté à la même infra de collecte. Alain a un hop de plus que toi et vous avez un first hop différent.
Il y a peu de chances que vous soyez sur le même OLT (d'une part par la distance géographique, d'autre part parce que chez free, il me semble que les OLT sont L3, et on voit que le first hop est différent sur vos traceroutes). J'émet l'hypothèse que vous n'êtes pas non plus raccordés au même routeur de collecte (peut-être même pas sur le même NRO?), et que le sien est daisy chained avec le tien (i.e. il passe par le tien avant d'atteindre le core network de free).
Pardon, j'ai pas été clair. Il est certain que nous ne sommes pas sur le même NRO mais j'aurais tendance à penser qu'on est tous les deux reliés au PoP de Massy. Je ne pense pas qu'il y a un chaînage entre nos deux NRO mais c'est dur à dire.
-
Oui, vu comme cela, on aurait tendance à penser que le problème est au NRO. Mais en ce cas, il est très commun, puisqu'il concerne des personnes un peu partout en France, comme Ozwell du côté de Lyon, kgersen etc...
-
Je ne suis pas à Lyon mais sur Paris ;D (couronne).
-
Oui, mes excuses, c'était darkmoon qui est en région lyonnaise.
-
Ce qui est "marrant" c'est que si je monte le VPN je n'ai plus aucune perte de paquet selon le script et un débit plus élevé en CUBIC (1Gbps au lieu de 600Mbps soit presque le double).
Ce n'est pas si étonnant car lorsque tu utilises un VPN tu encapsules le trafic réseau, donc tu rajoutes une couche (sûrement UDP) sous le flux TCP qui peut masquer/gérer les pertes de paquets à sa sauce.
Pour moi un test en TCP CUBIC encapsulé dans un VPN n'est pas probant...
Donc j'aurais du mal à mettre le réseau de collecte en cause sur ce coup... ça sent plus le problème de saturation sur un peering non ?
Pour pouvoir mettre en cause un problème de peering plutôt qu'un problème de collecte il faudrait que tu trouves un serveur de test qui fonctionne aussi bien en CUBIC qu'en BBR depuis ta connexion.
Personnellement je n'en ai pas trouvé depuis la connexion FTTH Free à laquelle j'ai accès.
-
Bonjour,
Toujours bien présent les "problèmes"
-------------------------- 2023-10-06 11:26:22 +0200 --------------------------
Paramétrage réseau actuel du système:
AutoTuningLevelLocal: Normal
CongestionProvider: CUBIC
EcnCapability: Disabled
NetworkCategory: Private
ScalingHeuristics: Disabled
Timestamps: Disabled
=> Latence TCP max pour une réception à 1 Gbps: 141 ms
Test TCP local (IPv4): téléchargement depuis la Freebox
--> Latence: 0.42 ms [gigue: 0.12 ms]
--> Débit: 293.72 Mo/s (2.35 Gbps) [fluctuation: 1.15%]
Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [BBR]
--> Latence: 6.51 ms [gigue: 0.38 ms]
--> Débit: 293.22 Mo/s (2.35 Gbps) [fluctuation: 1.91%]
Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [CUBIC]
--> Latence: 6.12 ms [gigue: 0.33 ms]
--> Débit: 35.40 Mo/s (283.23 Mbps) [fluctuation: 14.61%]
-
Pour information je viens de publier une nouvelle version (0.13) qui ajoute l'option "--all-srv" (-A). Cette option permet d'effectuer les tests de débit avec les serveurs de test provenant des deux AS (Scaleway et Bouygues). Dans ce mode les tests de débit sont donc effectués deux fois (une fois avec chaque AS, séquentiellement), et le débit le plus élevé pour chaque CCA est retenu pour la calcul de ratio Cubic/BBR.
Ce mode est utile lorsqu'on cherche à objectiver des saturation de collecte plutôt que des saturations de peering/transit.
-
Un lien pour télécharger cette nouvelle version stp
Merci pour ce petit script en tout cas.
-
Un lien pour télécharger cette nouvelle version stp
Merci pour ce petit script en tout cas.
En fait les liens ne changent pas, ce sont toujours les mêmes que ceux du premier message (qui pointent automatiquement vers la release "latest" de GitHub):
- checkFtthFree.exe (https://github.com/Yaribz/checkFtthFree/releases/latest/download/checkFtthFree.exe) (exécutable Windows)
- checkFtthFree.pl (https://github.com/Yaribz/checkFtthFree/releases/latest/download/checkFtthFree.pl) (script Perl pour autres systèmes)
-
Pour information je viens de publier une nouvelle version (0.13) qui ajoute l'option "--all-srv" (-A). Cette option permet d'effectuer les tests de débit avec les serveurs de test provenant des deux AS (Scaleway et Bouygues). Dans ce mode les tests de débit sont donc effectués deux fois (une fois avec chaque AS, séquentiellement), et le débit le plus élevé pour chaque CCA est retenu pour la calcul de ratio Cubic/BBR.
Ce mode est utile lorsqu'on cherche à objectiver des saturation de collecte plutôt que des saturations de peering/transit.
Merci pour cette maj et voici un résultat :)
-------------------------- 2023-10-09 22:53:29 +0200 --------------------------
Paramétrage réseau actuel du système:
AutoTuningLevelLocal: Normal
CongestionProvider: CUBIC
EcnCapability: Disabled
NetworkCategory: Private
ScalingHeuristics: Disabled
Timestamps: Disabled
=> Latence TCP max pour une réception à 1 Gbps: 141 ms
Test TCP local (IPv4): téléchargement depuis la Freebox
--> Latence: 0.49 ms [gigue: 0.13 ms]
--> Débit: 294.74 Mo/s (2.36 Gbps) [fluctuation: 0.82%]
Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [BBR]
--> Latence: 6.99 ms [gigue: 0.29 ms]
--> Débit: 250.32 Mo/s (2.00 Gbps) [fluctuation: 10.50%]
Test TCP Internet (IPv4): téléchargement depuis l'AS 5410 (Bouygues Telecom) [BBR]
--> Latence: 6.44 ms [gigue: 0.27 ms]
--> Débit: 255.70 Mo/s (2.05 Gbps) [fluctuation: 4.71%]
Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [CUBIC]
--> Latence: 5.89 ms [gigue: 0.20 ms]
--> Débit: 9.47 Mo/s (75.77 Mbps) [fluctuation: 15.59%]
Test TCP Internet (IPv4): téléchargement depuis l'AS 5410 (Bouygues Telecom) [CUBIC]
--> Latence: 6.15 ms [gigue: 0.22 ms]
--> Débit: 9.11 Mo/s (72.90 Mbps) [fluctuation: 24.37%]
[!] La connexion aux serveurs de test semble affectée par une forte perte de paquets
(ratio débit CUBIC/BBR: 3.70%)
-
Merci pour cet outil fort utile (connexion sous SQM cake)
[checkFtthFree v0.13] Windows 10 Build 22621 (64-bit)
-------------------------- 2023-10-09 22:57:02 +0200 --------------------------
Paramétrage réseau actuel du système:
AutoTuningLevelLocal: Normal
CongestionProvider: CUBIC
EcnCapability: Enabled
NetworkCategory: Private
ScalingHeuristics: Disabled
Timestamps: Allowed
=> Latence TCP max pour une réception à 1 Gbps: 141 ms
Test TCP local (IPv4): téléchargement depuis la Freebox
[!] Echec du test de latence
En cas d'absence de Freebox, le paramètre --skip-freebox (-F) peut être utilisé pour désactiver le test local
Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [BBR]
--> Latence: 5.63 ms [gigue: 0.19 ms]
--> Débit: 109.94 Mo/s (879.48 Mbps) [fluctuation: 0.06%]
Test TCP Internet (IPv4): téléchargement depuis l'AS 5410 (Bouygues Telecom) [BBR]
--> Latence: 4.80 ms [gigue: 0.27 ms]
--> Débit: 109.30 Mo/s (874.38 Mbps) [fluctuation: 0.50%]
Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [CUBIC]
--> Latence: 5.01 ms [gigue: 0.22 ms]
--> Débit: 109.83 Mo/s (878.61 Mbps) [fluctuation: 0.15%]
Test TCP Internet (IPv4): téléchargement depuis l'AS 5410 (Bouygues Telecom) [CUBIC]
--> Latence: 4.54 ms [gigue: 0.34 ms]
--> Débit: 109.79 Mo/s (878.28 Mbps) [fluctuation: 0.12%]
-------------------------- 2023-10-09 22:57:59 +0200 --------------------------
-
-------------------------- 2023-10-09 23:41:40 +0200 --------------------------
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: 190200 253603 380400
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.59 ms [gigue: 0.02 ms]
--> Débit: 116.48 Mo/s (931.82 Mbps) [fluctuation: 1.52%]
Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [BBR]
--> Latence: 12.70 ms [gigue: 0.40 ms]
--> Débit: 101.46 Mo/s (811.64 Mbps) [fluctuation: 5.59%]
Test TCP Internet (IPv4): téléchargement depuis l'AS 5410 (Bouygues Telecom) [BBR]
--> Latence: 12.45 ms [gigue: 0.23 ms]
--> Débit: 103.45 Mo/s (827.56 Mbps) [fluctuation: 0.86%]
Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [CUBIC]
--> Latence: 12.50 ms [gigue: 1.08 ms]
--> Débit: 66.90 Mo/s (535.17 Mbps) [fluctuation: 9.22%]
Test TCP Internet (IPv4): téléchargement depuis l'AS 5410 (Bouygues Telecom) [CUBIC]
--> Latence: 12.40 ms [gigue: 0.28 ms]
--> Débit: 87.64 Mo/s (701.08 Mbps) [fluctuation: 22.45%]
-------------------------- 2023-10-09 23:42:43 +0200 --------------------------
-
Merci pour cette maj et voici un résultat :)
Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [CUBIC]
--> Latence: 5.89 ms [gigue: 0.20 ms]
--> Débit: 9.47 Mo/s (75.77 Mbps) [fluctuation: 15.59%]
Test TCP Internet (IPv4): téléchargement depuis l'AS 5410 (Bouygues Telecom) [CUBIC]
--> Latence: 6.15 ms [gigue: 0.22 ms]
--> Débit: 9.11 Mo/s (72.90 Mbps) [fluctuation: 24.37%]
[!] La connexion aux serveurs de test semble affectée par une forte perte de paquets
(ratio débit CUBIC/BBR: 3.70%)
Effectivement cela ne s'arrange pas tes débits Cubic...
De mon côté au contraire hier soir en heure de pointe c'était beaucoup mieux que d'habitude depuis la connexion Free FTTH à laquelle j'ai accès:
Test TCP local (IPv4): téléchargement depuis la Freebox
--> Latence: 1.74 ms [gigue: 0.03 ms]
--> Débit: 116.47 Mo/s (931.77 Mbps) [fluctuation: 0.35%]
Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [BBR]
--> Latence: 16.98 ms [gigue: 0.32 ms]
--> Débit: 101.25 Mo/s (810.00 Mbps) [fluctuation: 1.23%]
Test TCP Internet (IPv4): téléchargement depuis l'AS 5410 (Bouygues Telecom) [BBR]
--> Latence: 17.08 ms [gigue: 0.28 ms]
--> Débit: 102.94 Mo/s (823.49 Mbps) [fluctuation: 1.48%]
Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [CUBIC]
--> Latence: 16.79 ms [gigue: 0.16 ms]
--> Débit: 76.50 Mo/s (611.98 Mbps) [fluctuation: 5.03%]
Test TCP Internet (IPv4): téléchargement depuis l'AS 5410 (Bouygues Telecom) [CUBIC]
--> Latence: 16.95 ms [gigue: 0.26 ms]
--> Débit: 98.85 Mo/s (790.78 Mbps) [fluctuation: 3.27%]
A voir si c'était juste un hasard ou si cela se confirme d'ici quelques jours...
-
Visiblement SFR n'est pas exempt de défauts alors qu'on n'est pas en heure de pointe :
Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [BBR]
--> Latence: 12.71 ms [gigue: 1.39 ms]
--> Débit: 55.52 Mo/s (444.13 Mbps) [fluctuation: 1.17%]
Test TCP Internet (IPv4): téléchargement depuis l'AS 5410 (Bouygues Telecom) [BBR]
--> Latence: 11.83 ms [gigue: 1.51 ms]
--> Débit: 55.38 Mo/s (443.01 Mbps) [fluctuation: 1.42%]
Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [CUBIC]
--> Latence: 11.90 ms [gigue: 1.65 ms]
--> Débit: 6.46 Mo/s (51.70 Mbps) [fluctuation: 10.59%]
Test TCP Internet (IPv4): téléchargement depuis l'AS 5410 (Bouygues Telecom) [CUBIC]
--> Latence: 11.64 ms [gigue: 1.72 ms]
--> Débit: 7.55 Mo/s (60.38 Mbps) [fluctuation: 13.18%]
[!] La connexion aux serveurs de test semble affectée par une perte de paquets prononcée
(ratio débit CUBIC/BBR: 13.59%)
-
[checkFtthFree v0.13] Windows 10 Build 19045 (64-bit)
-------------------------- 2023-10-10 11:14:47 +0200 --------------------------
Paramétrage réseau actuel du système:
AutoTuningLevelLocal: Normal
CongestionProvider: CUBIC
EcnCapability: Disabled
NetworkCategory: Private
ScalingHeuristics: Disabled
Timestamps: Disabled
=> Latence TCP max pour une réception à 1 Gbps: 141 ms
Test TCP local (IPv4): téléchargement depuis la Freebox
--> Latence: 1.11 ms [gigue: 0.07 ms]
--> Débit: 108.91 Mo/s (871.32 Mbps) [fluctuation: 8.30%]
Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [BBR]
--> Latence: 8.89 ms [gigue: 0.29 ms]
--> Débit: 107.48 Mo/s (859.88 Mbps) [fluctuation: 2.56%]
Test TCP Internet (IPv4): téléchargement depuis l'AS 5410 (Bouygues Telecom) [BBR]
--> Latence: 9.30 ms [gigue: 0.29 ms]
--> Débit: 109.04 Mo/s (872.35 Mbps) [fluctuation: 2.31%]
Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [CUBIC]
--> Latence: 8.59 ms [gigue: 0.29 ms]
--> Débit: 110.71 Mo/s (885.72 Mbps) [fluctuation: 0.30%]
Test TCP Internet (IPv4): téléchargement depuis l'AS 5410 (Bouygues Telecom) [CUBIC]
--> Latence: 8.78 ms [gigue: 0.26 ms]
--> Débit: 105.76 Mo/s (846.06 Mbps) [fluctuation: 5.35%]
-------------------------- 2023-10-10 11:15:59 +0200 --------------------------
[checkFtthFree v0.13] Linux 6.1.0-12-amd64 (x86_64)
-------------------------- 2023-10-10 11:17:44 +0200 --------------------------
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: 9867 13159 19734
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: 1.04 ms [gigue: 0.14 ms]
--> Débit: 117.45 Mo/s (939.62 Mbps) [fluctuation: 0.27%]
Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [BBR]
--> Latence: 9.41 ms [gigue: 0.44 ms]
--> Débit: 107.84 Mo/s (862.76 Mbps) [fluctuation: 0.64%]
Test TCP Internet (IPv4): téléchargement depuis l'AS 5410 (Bouygues Telecom) [BBR]
--> Latence: 8.98 ms [gigue: 0.38 ms]
--> Débit: 109.47 Mo/s (875.73 Mbps) [fluctuation: 0.99%]
Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [CUBIC]
--> Latence: 8.93 ms [gigue: 0.38 ms]
--> Débit: 109.86 Mo/s (878.90 Mbps) [fluctuation: 0.02%]
Test TCP Internet (IPv4): téléchargement depuis l'AS 5410 (Bouygues Telecom) [CUBIC]
--> Latence: 9.32 ms [gigue: 0.35 ms]
--> Débit: 109.75 Mo/s (878.00 Mbps) [fluctuation: 0.24%]
-------------------------- 2023-10-10 11:18:47 +0200 --------------------------
ouf l'honneur est sauf ;D
-
[checkFtthFree v0.13] Windows 10 Build 19045 (64-bit)
-------------------------- 2023-10-10 11:14:47 +0200 --------------------------
Paramétrage réseau actuel du système:
AutoTuningLevelLocal: Normal
CongestionProvider: CUBIC
EcnCapability: Disabled
NetworkCategory: Private
ScalingHeuristics: Disabled
Timestamps: Disabled
=> Latence TCP max pour une réception à 1 Gbps: 141 ms
Test TCP local (IPv4): téléchargement depuis la Freebox
--> Latence: 1.11 ms [gigue: 0.07 ms]
--> Débit: 108.91 Mo/s (871.32 Mbps) [fluctuation: 8.30%]
Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [BBR]
--> Latence: 8.89 ms [gigue: 0.29 ms]
--> Débit: 107.48 Mo/s (859.88 Mbps) [fluctuation: 2.56%]
Test TCP Internet (IPv4): téléchargement depuis l'AS 5410 (Bouygues Telecom) [BBR]
--> Latence: 9.30 ms [gigue: 0.29 ms]
--> Débit: 109.04 Mo/s (872.35 Mbps) [fluctuation: 2.31%]
Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [CUBIC]
--> Latence: 8.59 ms [gigue: 0.29 ms]
--> Débit: 110.71 Mo/s (885.72 Mbps) [fluctuation: 0.30%]
Test TCP Internet (IPv4): téléchargement depuis l'AS 5410 (Bouygues Telecom) [CUBIC]
--> Latence: 8.78 ms [gigue: 0.26 ms]
--> Débit: 105.76 Mo/s (846.06 Mbps) [fluctuation: 5.35%]
-------------------------- 2023-10-10 11:15:59 +0200 --------------------------
[checkFtthFree v0.13] Linux 6.1.0-12-amd64 (x86_64)
-------------------------- 2023-10-10 11:17:44 +0200 --------------------------
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: 9867 13159 19734
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: 1.04 ms [gigue: 0.14 ms]
--> Débit: 117.45 Mo/s (939.62 Mbps) [fluctuation: 0.27%]
Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [BBR]
--> Latence: 9.41 ms [gigue: 0.44 ms]
--> Débit: 107.84 Mo/s (862.76 Mbps) [fluctuation: 0.64%]
Test TCP Internet (IPv4): téléchargement depuis l'AS 5410 (Bouygues Telecom) [BBR]
--> Latence: 8.98 ms [gigue: 0.38 ms]
--> Débit: 109.47 Mo/s (875.73 Mbps) [fluctuation: 0.99%]
Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [CUBIC]
--> Latence: 8.93 ms [gigue: 0.38 ms]
--> Débit: 109.86 Mo/s (878.90 Mbps) [fluctuation: 0.02%]
Test TCP Internet (IPv4): téléchargement depuis l'AS 5410 (Bouygues Telecom) [CUBIC]
--> Latence: 9.32 ms [gigue: 0.35 ms]
--> Débit: 109.75 Mo/s (878.00 Mbps) [fluctuation: 0.24%]
-------------------------- 2023-10-10 11:18:47 +0200 --------------------------
ouf l'honneur est sauf ;D
Toi aussi, tu fais partie des quelques dizaines de personnes qui ont un bon débit en Cubic chez Free ! (C'est ce que certains pensent)
Bienvenue au club ! (J'en fais partie)
-
c'est sur des connexions < 1Gbps.
y'a t'il des gens chez Free ET avec une Delta ET le port 10G utilisé qui ont un bon Cubic ? (et qui ont 9,4 Gbps au test local aussi).
-
Ça ne devrait pas être très glorieux comme chez les autres opérateurs proposant du 8Gbs
-
y'a t'il des gens chez Free ET avec une Delta ET le port 10G utilisé qui ont un bon Cubic ? (et qui ont 9,4 Gbps au test local aussi).
Tout ça en même temps je sais pas, mais ici (https://lafibre.info/1gb-free/checkftthfree-test-de-debit-tcp-mono-connexion-freeboxcubicbbr/msg1006883/#msg1006883) par exemple il y a Fooo qui a du 2,77 Gbps en Cubic mono-connexion, ce qui est pas mal déjà.
Et ici (https://lafibre.info/1gb-free/checkftthfree-test-de-debit-tcp-mono-connexion-freeboxcubicbbr/msg1006302/#msg1006302) il y a Fuzy qui fait du 9,5 Gbps en test local avec la Freebox.
-
Toi aussi, tu fais partie des quelques dizaines de personnes qui ont un bon débit en Cubic chez Free ! (C'est ce que certains pensent)
Bienvenue au club ! (J'en fais partie)
mise à part le soucis qu'on a eu en Rhône Alpes 1 soir, j'ai pas à me plaindre ;D
-
Même à 15H c'est pas fou
-------------------------- 2023-10-10 15:03:03 +0200 --------------------------
Paramétrage réseau actuel du système:
AutoTuningLevelLocal: Normal
CongestionProvider: CUBIC
EcnCapability: Disabled
NetworkCategory: Private
ScalingHeuristics: Disabled
Timestamps: Disabled
=> Latence TCP max pour une réception à 1 Gbps: 141 ms
Test TCP local (IPv4): téléchargement depuis la Freebox
--> Latence: 0.82 ms [gigue: 0.21 ms]
--> Débit: 294.54 Mo/s (2.36 Gbps) [fluctuation: 0.92%]
Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [BBR]
--> Latence: 6.94 ms [gigue: 0.34 ms]
--> Débit: 290.38 Mo/s (2.32 Gbps) [fluctuation: 1.93%]
Test TCP Internet (IPv4): téléchargement depuis l'AS 5410 (Bouygues Telecom) [BBR]
--> Latence: 6.92 ms [gigue: 0.43 ms]
--> Débit: 297.24 Mo/s (2.38 Gbps) [fluctuation: 0.75%]
Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [CUBIC]
--> Latence: 6.24 ms [gigue: 0.31 ms]
--> Débit: 24.87 Mo/s (198.98 Mbps) [fluctuation: 21.56%]
Test TCP Internet (IPv4): téléchargement depuis l'AS 5410 (Bouygues Telecom) [CUBIC]
--> Latence: 6.76 ms [gigue: 0.14 ms]
--> Débit: 21.34 Mo/s (170.74 Mbps) [fluctuation: 14.15%]
[!] La connexion aux serveurs de test semble affectée par une forte perte de paquets
(ratio débit CUBIC/BBR: 8.37%)
-------------------------- 2023-10-10 15:04:11 +0200 --------------------------
-
RAS de mon coté (banlieue Lyonnaise) :
[checkFtthFree v0.13] Windows 10 Build 22621 (64-bit)
-------------------------- 2023-10-10 17:19:55 +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: 8.03 ms [gigue: 0.28 ms]
--> Débit: 289.68 Mo/s (2.32 Gbps) [fluctuation: 2.41%]
Test TCP Internet (IPv6): téléchargement depuis l'AS 5410 (Bouygues Telecom) [BBR]
--> Latence: 7.97 ms [gigue: 0.26 ms]
--> Débit: 291.78 Mo/s (2.33 Gbps) [fluctuation: 0.52%]
Test TCP Internet (IPv6): téléchargement depuis l'AS 12876 (Scaleway) [CUBIC]
--> Latence: 7.14 ms [gigue: 0.21 ms]
--> Débit: 277.67 Mo/s (2.22 Gbps) [fluctuation: 3.73%]
Test TCP Internet (IPv6): téléchargement depuis l'AS 5410 (Bouygues Telecom) [CUBIC]
--> Latence: 7.69 ms [gigue: 0.37 ms]
--> Débit: 292.61 Mo/s (2.34 Gbps) [fluctuation: 0.05%]
-------------------------- 2023-10-10 17:20:51 +0200 --------------------------
Je retesterais ce soir vers 21h.
-
ce soir je vais voir de suite, je dois télécharger Forza, 118Go ...
je sais pas si c'est en cubic ou bbr ;D
-
ce soir je vais voir de suite, je dois télécharger Forza, 118Go ...
je sais pas si c'est en cubic ou bbr ;D
Je suis en train de le DL via Steam, 45Mo/s en moyenne
Un gros service comme Steam,ça doit être du BBR.
-
C'est du multi connexion Steam non ?
-
depuis le MS Store c'est la misère ;D
Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [BBR]
--> Latence: 8.55 ms [gigue: 0.19 ms]
--> Débit: 109.59 Mo/s (876.71 Mbps) [fluctuation: 1.53%]
Test TCP Internet (IPv4): téléchargement depuis l'AS 5410 (Bouygues Telecom) [BBR]
--> Latence: 8.52 ms [gigue: 0.29 ms]
--> Débit: 109.78 Mo/s (878.23 Mbps) [fluctuation: 2.12%]
Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [CUBIC]
--> Latence: 8.16 ms [gigue: 0.28 ms]
--> Débit: 110.38 Mo/s (883.02 Mbps) [fluctuation: 0.47%]
Test TCP Internet (IPv4): téléchargement depuis l'AS 5410 (Bouygues Telecom) [CUBIC]
--> Latence: 8.13 ms [gigue: 0.39 ms]
--> Débit: 109.76 Mo/s (878.09 Mbps) [fluctuation: 1.31%]
pourtant ça va la :D
-
C'est du multi connexion Steam non ?
Aucune idée. avec la décompression en parallèle, ça doit pas aider.
Mais d'habitude ça tourne plus dans les 100 Mo/s.
Après c'est jour de sortie du titre, ça doit expliquer la moyenne.
-
pour suivre en détail ce qui se passe: lancer le "moniteur de ressource" (dans la recherche Windows ou resmon en ligne de commande)
dans le moniteur, onglet 'réseau', puis en bas "connexions TCP". Sur la barre d'entête des colonnes (commençant par "processus, pid, etc"), click droit puis choisir "sélectionner des colonnes", cocher envoi, reception et total octets/s puis arranger au besoin la largeur des colonnes et trier par réception en clickant sur cette colonne (click une ou deux fois pour trier du plus gros au plus petit).
Tu verras si c'est mono ou multi. Avec Steam je monte a 1,5 Gbps environ sur une dizaine de connexions , mais cette limitation est du a mon cpu qui décompresse en meme temps.
(https://i.imgur.com/DswSZH8.png)
-
Comme toi sur Rennes @ouno
Test TCP local (IPv4): téléchargement depuis la Freebox
--> Latence: 0.40 ms [gigue: 0.05 ms]
--> Débit: 1.19 Go/s (9.50 Gbps) [fluctuation: 0.73%]
Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [BBR]
--> Latence: 8.13 ms [gigue: 0.27 ms]
--> Débit: 567.37 Mo/s (4.54 Gbps) [fluctuation: 8.24%]
Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [CUBIC]
--> Latence: 8.05 ms [gigue: 0.86 ms]
--> Débit: 36.59 Mo/s (292.73 Mbps) [fluctuation: 18.73%]
Mais bon je dois faire partie des quelques dizaines de personnes qui ont un mauvais débit en Cubic chez Free ! (C'est ce que certains pensent) LoL
Effectivement le DL steam c'est pas du cubic...
-
A côté de Vannes, test effectué à 19h35... (gigabit ethernet)
Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [BBR]
--> Latence: 18.00 ms [gigue: 0.40 ms]
--> Débit: 111.25 Mo/s (889.98 Mbps) [fluctuation: 6.09%]
Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [CUBIC]
--> Latence: 17.16 ms [gigue: 0.31 ms]
--> Débit: 2.11 Mo/s (16.89 Mbps) [fluctuation: 16.60%]
[!] La connexion aux serveurs de test semble affectée par une forte perte de paquets
(ratio débit CUBIC/BBR: 1.90%)
Ça m'a fait rigoler :D par contre :
• Sur Bytel, BBR/CUBIC atteignent tous deux le gigabit
• En faisant le test en IPV6 (paramètre -6), Scaleway passe à 816.13 Mbps en CUBIC. Différence vérifiée et constatée plusieurs fois.
-
A côté de Vannes, test effectué à 19h35... (gigabit ethernet)
(ratio débit CUBIC/BBR: 1.90%)
Ça m'a fait rigoler :D
Ah oui joli score effectivement :D
par contre :
• Sur Bytel, BBR/CUBIC atteignent tous deux le gigabit
• En faisant le test en IPV6 (paramètre -6), Scaleway passe à 816.13 Mbps en CUBIC. Différence vérifiée et constatée plusieurs fois.
Etonnant tout ça... Donc en gros depuis ta ligne il y aurait un gros souci d'interco Free/Scaleway en IPv4 seulement, bizarre...
-
L'interconnexion entre Free et Scaleway ne sature pas, c'est facile à vérifier sur https://netmap.scaleway.com/.
Peut-être un routage par un chemin différent moins saturé ?
-
Pour info je crois que le serveur de test Bouygues Cubic vient de retomber... (relancé)
-
Effectivement le DL steam c'est pas du cubic...
non c'est juste que le DL steam c'est multi connexion donc pas comparable avec les mono connexion d' ici. Si t'as 300Mbps a 500Mbps en mono cubic ca permet a Steam de monter a 3 Gbps ou meme plus. On ne sait pas si Steam est cubic ou bbr mais c'est moins gênant pour du multi. Le plus souvent c'est le cpu qui limite Steam.
L'interconnexion entre Free et Scaleway ne sature pas, c'est facile à vérifier sur https://netmap.scaleway.com/.
Peut-être un routage par un chemin différent moins saturé ?
Apres meme depuis Bytel le serveur chez Online a tendance a fluctuer beaucoup : https://dl.nspeed.app/bctests/bytel-online.html
En gros ca passe a fond ou en moyenne a 500Mbps... y'a pas trop de demi mesure :p a croire que le chemin a des liens a 1Gbps par moment et des liens 10Gbps a d'autres ? je ne sais pas si la netmap indique grand chose si une session tcp peut être limitée par l'archi d'interco. ou c'est juste le serveur qui fluctue ...
Pour info je crois que le serveur de test Bouygues Cubic vient de retomber... (relancé)
il est re retomber :p
-
Steam je comprend pas comment il fonctionne
ça télécharge à donf et puis d'un coup il se mets à te défoncer le SSD (utiliser à 100%) et tout rame ;D
tu vérifie la vitesse et le SSD se tourne les pouce à 50Mo/s mais 100% d'utilisation ... alors qu'en benchmark j'arrive bien à 3000Mo/s large en écriture et lecture (mini 650Mo/s en écriture quand le cache est blindé)
il ferai mieux de télécharger puis de décompresser ... en ADSL il peut faire les 2 mais en fibre on perd un temps de ouf
120Go sur PS5 je mets meme pas 30 minutes mais sur le PC (Steam, parce Ubi, EA je n'ai pas ce soucis) je mets 1h :(
forcémént si ça télécharge des zip qu'ils faut extraire c'est long, ils ont qu'a télécharger le jeu non compressé et hop ;D
J'ai bien mis 1h pour Forza aussi depuis le MS Store, la vitesse très fluctuante, donc peut être qu'il faut pareil, télécharge, décompresse ... pour ça que je n'achete plus aucun jeu sur Steam, et MS ça sera pareil ;D
-
Apres meme depuis Bytel le serveur chez Online a tendance a fluctuer beaucoup : https://dl.nspeed.app/bctests/bytel-online.html
En gros ca passe a fond ou en moyenne a 500Mbps... y'a pas trop de demi mesure :p a croire que le chemin a des liens a 1Gbps par moment et des liens 10Gbps a d'autres ? je ne sais pas si la netmap indique grand chose si une session tcp peut être limitée par l'archi d'interco. ou c'est juste le serveur qui fluctue ...
Est-ce que tu aurais moyen de refaire la série de 6 tests mono-connexion Cubic en fixant le port source, pour que le quadruplet (ip source, ip destination, port source, port destination) soit le même pour tous les tests ?
-
Est-ce que tu aurais moyen de refaire la série de 6 tests mono-connexion Cubic en fixant le port source, pour que le quadruplet (ip source, ip destination, port source, port destination) soit le même pour tous les tests ?
hum tu penses qu'il y a peut-être un bonding/multichannel au niveau 3 et pas 2 donc avec le quad comme critère d'aiguillage quelque part ?
Intéressant a tester, je vais voir pour le port source si c'est possible de le changer. Les trois autres sont déjà les mêmes (sauf si round robin dns mais ce n'est pas le cas ici) .
(et voir l'impact du NAT sur le quad en IPv4 donc plus probant en IPv6).
(pour info dans le html, vers la fin il y a le json qui contient des infos donc les ports sources).
-
hum tu penses qu'il y a peut-être un bonding/multichannel au niveau 3 et pas 2 donc avec le quad comme critère d'aiguillage quelque part ?
Disons que d'expérience c'est ce qui me vient à l'esprit quand je vois des résultats comme ceux de tes tests Cubic au-dessus (plus ou moins aléatoire entre différentes sessions TCP, mais constant pour une session TCP donnée).
Intéressant a tester, je vais voir pour le port source si c'est possible de le changer.
Sinon au pire juste un curl --local-port pourrait suffire je pense, vu que le résultat c'est soit 6-7 Gbps soit < 1Gbps.
-
Disons que d'expérience c'est ce qui me vient à l'esprit quand je vois des résultats comme ceux de tes tests Cubic au-dessus (plus ou moins aléatoire entre différentes sessions TCP, mais constant pour une session TCP donnée).
Sinon au pire juste un curl --local-port pourrait suffire je pense, vu que le résultat c'est soit 6-7 Gbps soit < 1Gbps.
Suivant les OS c'est plus compliqué a cause de TIME_WAIT, il faut attendre ou utiliser SO_REUSEADDR.
Sur Windows quitter le process dégage les ports , pas sur Linux donc on doit attendre entre 2 curl.
j'ai refais un test a 18h: https://dl.nspeed.app/bctests/online.html
Il y a 2 contre exemples (le 1er et le 3eme).
Je doute que ce soit un probleme de port donc mais je vais quand même ajouter l'option a nspeed vu que curl l'a.
-
j'ai refais un test a 18h: https://dl.nspeed.app/bctests/online.html
Il y a 2 contre exemples (le 1er et le 3eme).
Je doute que ce soit un probleme de port donc mais je vais quand même ajouter l'option a nspeed vu que curl l'a.
Ah oui effectivement là c'est différent sur ces résultats, on voit que ça change au sein d'une même session.
Du coup j'imagine que ça doit juste dépendre du moment où les pertes de paquets se font...
-
oui mais c'est brutal quand même :p
-
Steam je comprend pas comment il fonctionne
ça télécharge à donf et puis d'un coup il se mets à te défoncer le SSD (utiliser à 100%) et tout rame ;D
Steam fait de la compression au niveau des téléchargements. C'est un gain de bande passante phénoménal.
Sur Forza Motorsports c'est un gain de 15,6% (https://steamdb.info/depot/2440511/), mais j'ai déjà vu ce chiffre grimper jusqu'à 60%.
Ils ont aussi récemment fait du gros travail pour améliorer le processus qui "delta-ise" les mises à jour. En gros avant, si un développeur utilisait une manière d'empaqueter ses fichiers pas idéale, un petit changement de rien du tout sur un gros fichier monolithique (ce qui est très commun) pouvait déclencher une mise à jour de dizaines de Go. Ils ont essayé d'expliquer aux développeurs comment faire pour éviter ça, l'avantage d'utiliser des systèmes de build/cooking qui sont deterministes... mais la pédagogie n'a pas assez porté ses fruits. Donc il y a un ingénieur chez Valve qui a revu le système côté serveur et qui fait presque du brute force de ce côté là pour éviter ça. Par contre ce qui reste inévitable c'est la charge I/O à faire ce processus en sens inverse après le téléchargement de la mise à jour.
-
oui je sais bien que ça économise, en ADSL c'était le bienvenue mais en fibre je m'en tape ! ça me fait perdre du temps ;D
-
Alors moi je fais rien comme tout le monde :
Test TCP local (IPv4): téléchargement depuis la Freebox
--> Latence: 0.45 ms [gigue: 0.37 ms]
--> Débit: 179.81 Mo/s (1.44 Gbps) [fluctuation: 1.87%]
Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [BBR]
--> Latence: 17.96 ms [gigue: 0.26 ms]
--> Débit: 260.47 Mo/s (2.08 Gbps) [fluctuation: 12.86%]
Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [CUBIC]
--> Latence: 17.19 ms [gigue: 0.30 ms]
--> Débit: 295.61 Mo/s (2.36 Gbps) [fluctuation: 0.89%]
Sur les tests de débit avec Firefox, que ce soit sur nPerf ou Seedtest je suis toujours a 2gbits constant, peu importe l'heure du jour ou de la nuit.
Bizarre aussi le débit si faible en local sur la Freebox ? C'est la pop qui n'arrive pas à suivre ?
Je me demande si ma carte réseau c'est pas un peu de la merde du coup ... Les tests sont réalisés avec un très bon PC, sans softs bizarre ni rien ...
C'est juste pour ma curiosité, parcequ'au fond 2gbits constant ça me va très bien.
-
moi aussi sur un PC j'ai le test local qui est moins rapide, alors que sur internet je n'ai aucun soucis ;D
et sur un autre PC le test local fonctionne très bien ??? donc pas de soucis de box (j'ai pris le même câble réseau pour tester)
-
Steam fait de la compression au niveau des téléchargements. C'est un gain de bande passante phénoménal.
Qu'on compresse des ISO ok mais le reste...
-
Pour info j'ai publié la version 0.14 il y a quelques jours qui apporte juste la compatibilité FreeBSD en ce qui concerne la lecture/analyse automatique de la configuration réseau (la partie test de débit était déjà compatible, tout comme sur NetBSD et OpenBSD).
-
Sur les tests de débit avec Firefox, que ce soit sur nPerf ou Seedtest je suis toujours a 2gbits constant, peu importe l'heure du jour ou de la nuit.
Visiblement tu as eu 2,36 Gbps en mono-connexion Cubic, c'est pas mal pour du 2,5 Gbps quand même.
Bizarre aussi le débit si faible en local sur la Freebox ? C'est la pop qui n'arrive pas à suivre ?
Il y a certains cas où la Freebox n'est pas super fiable en ce qui concerne le test de débit local oui, et cela dépend aussi des services utilisés pendant le test (flux télé etc.).
-
En passant par Wireguard avec une conf NordLynx ça semble ok !
-
Nouvelle version mineure v0.15, uniquement pour corriger l'affichage de la version de Windows pour Windows 11 (Windows 11 était affiché en tant que Windows 10 dans l'entête, seul le numéro de build permettait de faire la différence).
Aucune modif de fonctionnalité.
-
En passant par Wireguard avec une conf NordLynx ça semble ok !
J'avais pas fait gaffe mais impressionnant la différence entre les deux quand même...
Mis à part le test Cubic sans VPN, globalement super perfs pour du mono-connexion :)
A cette vitesse ça doit commencer à bien tirer sur le CPU le chiffrement pour le VPN...