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. edit du 01/03/2025: malheureusement il n'y a plus de serveur de test de débit HTTP utilisant l'algorithme CUBIC disponible publiquement, cette fonctionnalité est donc désactivée pour l'instant.
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>]
--all-ipv (-2) : Effectue tous les tests en double, une fois en IPv4 et une fois en IPv6
--ipv6 (-6) : Effectue les tests Internet en IPv6 (IPv4 par défaut)
--alternate-srv (-a) : Change de serveur pour les tests Internet (utilise Appliwave au lieu de Scaleway)
--all-srv (-A) : Effectue les tests Internet en double, une fois avec chaque serveur
--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...
-
Bonjour
J'ai un problème sur mon nouveau PC (https://www.dell.com/fr-fr/shop/gaming-and-games/alienware-m18-r2-gaming-laptop/spd/alienware-m18-r2-laptop/nawm18r203).
Bien que raccordé en éthernet à ma Révolution, l'envoi vers internet se passe d'une manière catastrophique, tant pour mes courriels que lorsque je dépose sur un Cloud. Je suis revenu en ADSL bas débit !
(https://rehost.diberie.com/Picture/Get/f/303750)
(mais étonnement, des tests vers DégroupTest ou Speedtest ne font pas apparaitre le problème.
J'ai lancé checkFtthFree -u mais visiblement il ne fait pas apparaitre le problème :
[checkFtthFree v0.15] Windows 11 Build 22631 (64-bit)
-------------------------- 2024-08-01 09:23:12 +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 Internet (IPv4): envoi vers l'AS 12876 (Scaleway) [CUBIC]
--> Latence: 12.07 ms [gigue: 0.46 ms]
--> Débit: 70.69 Mo/s (565.55 Mbps) [fluctuation: 12.69%]
-------------------------- 2024-08-01 09:23:30 +0200 --------------------------
C'est donc clairement un paramétrage quelque part sur ce nouveau PC en W11 famille.
Quelqu'un aurait une idée ?
Merci !
Nb 1 : sur la même Révolution un autre PC est raccordé et celui-ci ne rencontre pas de problème.
Nb 2 : ce nouveau PC vient en remplacement d'un PC qui au même endroit fonctionnait très bien.
-
Bon, en revenant de déjeuner, j'ai refait un test : le problème qui m'agace depuis 2 semaines a disparu... :o :o
Va comprendre Charles ! ???
-
Bon, en revenant de déjeuner, j'ai refait un test : le problème qui m'agace depuis 2 semaines a disparu... :o :o
Va comprendre Charles ! ???
Si tu constates la même chose en Wi-Fi : problème logiciel.
Si non : ne jamais exclure la possibilité que ce soit le câble en cause ! https://x.com/SwiftOnSecurity/status/959163780784680961
(Et je le sais, car ça m'est arrivé récemment : câble de 25 mètres qui s'est dégradé jusqu'à ne plus synchroniser qu'en 100 Mbps)
-
Si tu constates la même chose en Wi-Fi : problème logiciel.
Si non : ne jamais exclure la possibilité que ce soit le câble en cause ! https://x.com/SwiftOnSecurity/status/959163780784680961
(Et je le sais, car ça m'est arrivé récemment : câble de 25 mètres qui s'est dégradé jusqu'à ne plus synchroniser qu'en 100 Mbps)
En fait, ce matin, j'ai manipulé la prise éthernet banchée sur le PC (un petit cable de 50cm relié à la prise murale).
Mais je trouve étonnant de ne pas avoir de problème pour recevoir mais en avoir pour envoyer.
Et puis les tests Dégrouptest et Speedtest étaient corrects.
Bref croisons les doigts...
-
Pour info, étant donné que les serveurs de test Bouygues ont été arrêtés (cf ce message (https://lafibre.info/tester-son-debit/curl-linux/msg1083016/#msg1083016) de vivien), il n'y a plus que les serveurs par défaut (Scaleway) qui fonctionnent.
Les paramètres -a et -A qui permettaient de tester avec des serveurs alternatifs Bouygues ne sont donc plus fonctionnels. Je ferai une mise à jour du logiciel pour supprimer ces options...
-
Si tu constates la même chose en Wi-Fi : problème logiciel.
Si non : ne jamais exclure la possibilité que ce soit le câble en cause ! https://x.com/SwiftOnSecurity/status/959163780784680961
(Et je le sais, car ça m'est arrivé récemment : câble de 25 mètres qui s'est dégradé jusqu'à ne plus synchroniser qu'en 100 Mbps)
Bon, après 1 mois de fonctionnement normal, le problème est réapparu. >:( >:(
J'ai testé un autre câble est le problème est identique.
Et en fait, mon PC n'a aucun problème pour transférer des fichiers sur un autre PC du réseau => ce n'est donc pas un problème matériel.
Le problème est bien la gestion logiciel d'envoi de données vers internet.
Que ce soit via l'envoi de courriels ou de fichiers vers un serveur de dépôt.
Le gestionnaire de tâche indique qu'il n'y a alors qu'une application qui utilise des capacités réseaux, celle-ci plafonnant à 0.1Mbit/s :-\
-
A tout fin utile, un test Iperf donne :
(https://rehost.diberie.com/Picture/Get/f/311883)
-
Bon, le problème se précise : lorsque je dépose sur des sites comme Grosfichiers ou WeTransfer, je n'ai aucun problème => le problème vient donc de la communication avec les serveurs de Free (pour les courriels et le site transfert.free.fr) de mon nouveau PC.
-
Pour que ça serve à d'autres :
Les services des cartes réseau d'Intel de la série Killer sont mal conçus, c'est de notoriété public (vu les avis sur le net). >:(
Dans les applications, j'ai trouvé Killer Intelligence Center.
Je l'ai désinstallé mais le problème a persisté après le reboot.
Dans les processus actifs j'ai alors constaté qu'il y avait encore Killer Analytics Service et Killer Network Service en fonctionnement.
En ouvrant l'emplacement de fichier dans le gestionnaire de tâche, j'ai constaté que ces services sont considérés comme des drivers (répertoire C:\Windows\System32\drivers\RivetNetworks\Killer. Performant le pilote, à faire rouler la voiture à 2km/h sur un circuit de F1 ! :-\
Ces processus ne pouvant pas être désinstallés dans les applications (car non cités), le répertoire ne pouvant pas être renommé (car utilisé par une application en cours), j'ai créé un sous-répertoire C:\Windows\System32\drivers\RivetNetworks\Killer\provisoire et j'y ai déplacé tous les fichiers se trouvant dans C:\Windows\System32\drivers\RivetNetworks\Killer.
Après un reboot, le problème a disparu. 8)
-
Cool ton programme Ouno; merci :)
[checkFtthFree v0.15] Windows 10 Build 19045 (64-bit)
-------------------------- 2024-09-20 04:39:56 +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.03 ms]
--> Débit: 1.19 Go/s (9.49 Gbps) [fluctuation: 0.05%]
Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [BBR]
--> Latence: 13.91 ms [gigue: 0.21 ms]
--> Débit: 902.40 Mo/s (7.22 Gbps) [fluctuation: 6.08%]
Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [CUBIC]
--> Latence: 13.56 ms [gigue: 0.38 ms]
--> Débit: 994.73 Mo/s (7.96 Gbps) [fluctuation: 0.29%]
-------------------------- 2024-09-20 04:40:38 +0200 --------------------------
Appuyer sur Entrée pour quitter...
-
Merci, j'ai rarement vu des débits aussi élevés en mono-connexion !
C'est même surprenant d'obtenir 994.73 Mo/s (7.96 Gbps) avec une connexion 8Gbps sachant que checkFtthFree mesure le débit utile, et d'autant plus en IPv4 puisque chez Free l'IPv4 est encapsulé dans l'IPv6 :o
-
Effectivement, c'est même mieux que du Orange pro 8Gb/s.
Le réseau Free doit bien évolué !
-
le mtu en IPv4 est a 1500 aussi grace au mtu sortant de la freebox qui est plus grand que 1500 a dessein.
et cf l'heure du test...
la 'line rate' du 10G EPON est 8,7 Gbps
on compte -6% pour le débit utile (ip,tcp) ca fait 8,178 Gbps maxi possible.
-
Désolé pour l'heure du test; je travaille de nuit, et j'ai parcouru le forum et en particulier ce post en rentrant du boulot...
Je ferais un autre test à des horaires plus chargés si j'y songe ;)
Voilà; effectivement les débits ne sont plus les mêmes :
[checkFtthFree v0.15] Windows 10 Build 19045 (64-bit)
-------------------------- 2024-09-21 09:02:36 +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.46 ms [gigue: 0.06 ms]
--> Débit: 1.18 Go/s (9.43 Gbps) [fluctuation: 0.12%]
Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [BBR]
--> Latence: 13.85 ms [gigue: 0.37 ms]
--> Débit: 691.75 Mo/s (5.53 Gbps) [fluctuation: 7.29%]
Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [CUBIC]
--> Latence: 13.17 ms [gigue: 0.53 ms]
--> Débit: 680.50 Mo/s (5.44 Gbps) [fluctuation: 8.38%]
-------------------------- 2024-09-21 09:03:17 +0200 --------------------------
-
le mtu en IPv4 est a 1500 aussi grace au mtu sortant de la freebox qui est plus grand que 1500 a dessein.
D'accord, mais même si la charge utile par paquet reste identique, cela n'empêche pas qu'il y a deux en-têtes au lieu d'un par paquet à faire passer dans les tuyaux en plus de la charge utile, et donc bien une perte d'efficacité non ?
la 'line rate' du 10G EPON est 8,7 Gbps
on compte -6% pour le débit utile (ip,tcp) ca fait 8,178 Gbps maxi possible.
Si je comprends bien, dans sa communication Free indique du 8 Gbps mais en fait il n'y a pas de bridage particulier, c'est simplement le débit max du 10G EPON (8,7 Gbps) qui est fourni à abonné ?
Et donc le débit utile TCP obtenu par le client final (94% * 8,7 Gbps) serait en fait supérieur au débit brut annoncé par Free (8 Gbps)...
-
Voilà; effectivement les débits ne sont plus les mêmes :
[checkFtthFree v0.15] Windows 10 Build 19045 (64-bit)
-------------------------- 2024-09-21 09:02:36 +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.46 ms [gigue: 0.06 ms]
--> Débit: 1.18 Go/s (9.43 Gbps) [fluctuation: 0.12%]
Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [BBR]
--> Latence: 13.85 ms [gigue: 0.37 ms]
--> Débit: 691.75 Mo/s (5.53 Gbps) [fluctuation: 7.29%]
Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [CUBIC]
--> Latence: 13.17 ms [gigue: 0.53 ms]
--> Débit: 680.50 Mo/s (5.44 Gbps) [fluctuation: 8.38%]
-------------------------- 2024-09-21 09:03:17 +0200 --------------------------
Ca reste très correct !
L'idéal est de faire un test autour de 22h, d'expérience c'est souvent là qu'il est le plus chargé.
Mais j'imagine que dans ton cas ce n'est pas vraiment possible.
-
D'accord, mais même si la charge utile par paquet reste identique, cela n'empêche pas qu'il y a deux en-têtes au lieu d'un par paquet à faire passer dans les tuyaux en plus de la charge utile, et donc bien une perte d'efficacité non ?
Si je comprends bien, dans sa communication Free indique du 8 Gbps mais en fait il n'y a pas de bridage particulier, c'est simplement le débit max du 10G EPON (8,7 Gbps) qui est fourni à abonné ?
Et donc le débit utile TCP obtenu par le client final (94% * 8,7 Gbps) serait en fait supérieur au débit brut annoncé par Free (8 Gbps)...
oui je pensais que tu parlais de la perte d'efficacité classique des tunnels du a la mtu plus basse et/ou le fait de fragmenter en ipv4.
Je pense qu'ils annoncent "8 Gbps" pile, parce que commercialement c'est plus propre. 8,1 par exemple cela fera bizarre.
-
Hello,
Je mets ma contribution un test le matin et un le soir sur le secteur de Nancy.
Matin :
(https://image.noelshack.com/fichiers/2024/41/3/1728501754-checkftth-matin.jpg)
Soir :
(https://image.noelshack.com/fichiers/2024/41/3/1728501754-checkftth-soir.jpg)
-
Joli score ! :)
J'ai l'impression que globalement le réseau de collecte de Free s'est bien amélioré depuis environ un an.
On voit beaucoup moins de personnes vraiment pénalisées par les saturations aux heures de pointe, et on voit plus de bons scores comme celui-là.
-
Nouvelle version 0.16:
- Ajout du support de l'analyse de configuration réseau macOS (pour déterminer le débit max théorique en fonction du paramétrage réseau et de la latence)
- Retrait des paramètres de ligne de commande "-a" / "--alternate-srv" et "-A" / "--all-srv" (les serveurs de test chez Bouygues ne sont plus fonctionnels)
-
Nouvelle version 0.16:
- Ajout du support de l'analyse de configuration réseau macOS (pour déterminer le débit max théorique en fonction du paramétrage réseau et de la latence)
- Retrait des paramètres de ligne de commande "-a" / "--alternate-srv" et "-A" / "--all-srv" (les serveurs de test chez Bouygues ne sont plus fonctionnels)
Salut @ouno
C'est moi ou checkFtthFree est limité à 2.5 Gbps ?
-
C'est moi ou checkFtthFree est limité à 2.5 Gbps ?
Je n'ai pas l'impression que tu ais activité le mot "mono-connexion" côté Speedtest.net. Du coup tu compares la vitesse de téléchargement avec une seule connexion versus plusieurs.
-
Firefox/single
-
Du coup c'est bien cohérent.
-
Nouvelle version 0.17, qui ne contient que des ajouts pour Windows:
- affichage de nouvelles infos réseau:
. LinkSpeed: vitesse du lien réseau
. PcieLinkSpeed: vitesse de l'interface PCI Express utilisée par la carte réseau (taux de transfert par ligne)
. PcieLinkWidth: largeur de l'interface PCI Express utilisée par la carte réseau (nombre de lignes)
. PhysicalMediaType: type de media réseau (filaire, wifi...) - contrôle du taux de transfert de l'interface PCI Express utilisée par la carte réseau:
affichage d'un warning si le taux de transfert de l'interface PCI Express est insuffisant pour atteindre le débit max du lien réseau
Ces ajouts devraient faciliter les investigations lors de problèmes de perf sous Windows.
-
Nouvelle version 0.17, qui ne contient que des ajouts pour Windows:
- affichage de nouvelles infos réseau:
. LinkSpeed: vitesse du lien réseau
. PcieLinkSpeed: vitesse de l'interface PCI Express utilisée par la carte réseau (taux de transfert par ligne)
. PcieLinkWidth: largeur de l'interface PCI Express utilisée par la carte réseau (nombre de de lignes)
. PhysicalMediaType: type de media réseau (filaire, wifi...) - contrôle du taux de transfert de l'interface PCI Express utilisée par la carte réseau:
affichage d'un warning si le taux de transfert de l'interface PCI Express est insuffisant pour atteindre le débit max du lien réseau
Ces ajouts devraient faciliter les investigations lors de problèmes de perf sous Windows.
ah cool ca, j'avais tenté d'ajouter cela a nspeed l'année derniere mais suite a une maj de Windows 11 il fallait être administrateur pour avoir ces infos (ca marchait sous W10 et les versions de W11 d'avant la maj).
Je n'avait pas retenté depuis mais si ca fonctionne a nouveau c'est bon a savoir.
Pour Linux j'avais regardé il faut être root pour avoir ces infos.
Pour Mac je n'ai pas regardé encore.
-
ah cool ca, j'avais tenté d'ajouter cela a nspeed l'année derniere mais suite a une maj de Windows 11 il fallait être administrateur pour avoir ces infos (ca marchait sous W10 et les versions de W11 d'avant la maj).
Je n'avait pas retenté depuis mais si ca fonctionne a nouveau c'est bon a savoir.
Ah malheureusement je n'ai pas testé avec un Win11 récent.
Il y a des chances que cela ne fonctionne pas d'après ton message, je suis preneur d'un retour sous Win11 à jour du coup...
Pour Linux j'avais regardé il faut être root pour avoir ces infos.
Oui c'est ce que j'ai vu aussi, c'est dommage. C'est ce qui m'a découragé d'implémenter la même chose pour Linux d'ailleurs.
-
Ah malheureusement je n'ai pas testé avec un Win11 récent.
Il y a des chances que cela ne fonctionne pas d'après ton message, je suis preneur d'un retour sous Win11 à jour du coup...
Si ca fonctionne tel quel sur Win11 a jour. Je pense qu'ils sont revenu en arrière a un moment, je ne saurais dire quand.
[checkFtthFree v0.17] Windows 11 Build 22631 (64-bit)
-------------------------- 2024-11-20 16:40:34 +0100 --------------------------
Paramétrage réseau actuel du système:
AutoTuningLevelLocal: Normal
CongestionProvider: BBR2
EcnCapability: Disabled
LinkSpeed: 10 Gbps
NetworkCategory: Private
PcieLinkSpeed: 5.0 GT/s
PcieLinkWidth: 4
PhysicalMediaType: 802.3
ScalingHeuristics: Disabled
Timestamps: Allowed
=> Latence TCP max pour une réception à 1 Gbps: 141 ms
Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [BBR]
--> Latence: 3.51 ms [gigue: 1.05 ms]
--> Débit: 757.74 Mo/s (6.06 Gbps) [fluctuation: 1.07%]
Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [CUBIC]
--> Latence: 2.99 ms [gigue: 0.16 ms]
--> Débit: 728.55 Mo/s (5.83 Gbps) [fluctuation: 0.50%]
-
Bonne nouvelle, merci pour le test :)
J'en ai profité pour faire une nouvelle version 0.18, qui ajoute sous Windows l'affichage d'infos concernant le pilote réseau utilisé (nom, version, fournisseur, date), ce qui peut aussi être pratique pour le dépannage.
-
Sympa les ajouts ^^
[checkFtthFree v0.18] Windows 10 Build 19045 (64-bit)
-------------------------- 2024-11-22 00:28:33 +0100 --------------------------
Paramétrage réseau actuel du système:
AutoTuningLevelLocal: Normal
CongestionProvider: CUBIC
DriverDescription: ASUS XG-C100F 10G SFP+ Network Adapter
DriverVersion: 3.1.10.0 (Marvell, 2024-04-23)
EcnCapability: Disabled
LinkSpeed: 10 Gbps
NetworkCategory: Private
PcieLinkSpeed: 8.0 GT/s
PcieLinkWidth: 4
PhysicalMediaType: 802.3
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.35 ms [gigue: 0.01 ms]
--> Débit: 1.19 Go/s (9.49 Gbps) [fluctuation: 0.07%]
Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [BBR]
--> Latence: 6.86 ms [gigue: 0.18 ms]
--> Débit: 838.29 Mo/s (6.71 Gbps) [fluctuation: 3.34%]
Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [CUBIC]
--> Latence: 6.04 ms [gigue: 0.23 ms]
--> Débit: 781.72 Mo/s (6.25 Gbps) [fluctuation: 4.05%]
-------------------------- 2024-11-22 00:29:13 +0100 --------------------------
-
Oui merci ! Je confirme sur W11
[checkFtthFree v0.18] Windows 11 Build 26100 (64-bit)
-------------------------- 2024-11-22 12:49:03 +0100 --------------------------
Paramétrage réseau actuel du système:
AutoTuningLevelLocal: Normal
CongestionProvider: CUBIC
DriverDescription: Intel(R) 82599 10 Gigabit Network Connection
DriverVersion: 4.1.254.0 (Intel, 2024-02-08)
EcnCapability: Disabled
LinkSpeed: 10 Gbps
NetworkCategory: Private
PcieLinkSpeed: 5.0 GT/s
PcieLinkWidth: 4
PhysicalMediaType: 802.3
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.79 ms [gigue: 0.26 ms]
--> Débit: 1.17 Go/s (9.33 Gbps) [fluctuation: 3.11%]
Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [BBR]
--> Latence: 9.02 ms [gigue: 0.33 ms]
--> Débit: 295.58 Mo/s (2.36 Gbps) [fluctuation: 3.89%]
Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [CUBIC]
--> Latence: 8.78 ms [gigue: 0.22 ms]
--> Débit: 288.39 Mo/s (2.31 Gbps) [fluctuation: 4.42%]
-------------------------- 2024-11-22 12:49:47 +0100 --------------------------
J'ai toujours ce blocage à 2.5 Gbps.... c'est lié à mon PC ?
-
Je comprend pas !!!!
[checkFtthFree v0.18] Windows 11 Build 27754 (64-bit)
-------------------------- 2024-11-22 15:07:45 +0100 --------------------------
Paramétrage réseau actuel du système:
AutoTuningLevelLocal: Normal
CongestionProvider: CUBIC
DriverDescription: Intel(R) 82599 10 Gigabit Network Connection
DriverVersion: 4.1.254.0 (Intel, 2024-02-08)
EcnCapability: Disabled
LinkSpeed: 10 Gbps
NetworkCategory: Private
PcieLinkSpeed: 5.0 GT/s
PcieLinkWidth: 4
PhysicalMediaType: 802.3
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.53 ms [gigue: 0.20 ms]
--> Débit: 856.54 Mo/s (6.85 Gbps) [fluctuation: 7.92%]
Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [BBR]
--> Latence: 8.41 ms [gigue: 0.27 ms]
--> Débit: 275.05 Mo/s (2.20 Gbps) [fluctuation: 5.05%]
Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [CUBIC]
--> Latence: 7.85 ms [gigue: 1.23 ms]
--> Débit: 287.94 Mo/s (2.30 Gbps) [fluctuation: 6.91%]
-------------------------- 2024-11-22 15:08:27 +0100 --------------------------
-
@SaniO
Tu es sur l'Ultra ou la Delta ?
-
@SaniO
Tu es sur l'Ultra ou la Delta ?
Je suis sur la Delta
-
Merci, j'obtenai les mêmes resultats sur la Delta... mais l'Ultra semble ---bridé--- me concernant !
Je regrette tellement la Delta ---au passage ! ;)
-
ça dépend les heures ou on fait le test je sais que en heure de pointe entre 20h / 21h je suis plutôt dans les 400 mo/s.
La actuellement :
[checkFtthFree v0.18] Windows 10 Build 19045 (64-bit)
-------------------------- 2024-11-22 17:50:15 +0100 --------------------------
Paramétrage réseau actuel du système:
AutoTuningLevelLocal: Normal
CongestionProvider: CUBIC
DriverDescription: ASUS XG-C100F 10G SFP+ Network Adapter
DriverVersion: 3.1.10.0 (Marvell, 2024-04-23)
EcnCapability: Disabled
LinkSpeed: 10 Gbps
NetworkCategory: Private
PcieLinkSpeed: 8.0 GT/s
PcieLinkWidth: 4
PhysicalMediaType: 802.3
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.28 ms [gigue: 0.10 ms]
--> Débit: 1.19 Go/s (9.49 Gbps) [fluctuation: 0.03%]
Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [BBR]
--> Latence: 6.73 ms [gigue: 0.20 ms]
--> Débit: 543.72 Mo/s (4.35 Gbps) [fluctuation: 7.40%]
Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [CUBIC]
--> Latence: 6.10 ms [gigue: 0.23 ms]
--> Débit: 568.34 Mo/s (4.55 Gbps) [fluctuation: 2.68%]
-------------------------- 2024-11-22 17:50:56 +0100 --------------------------
-
Merci, tu es en ZMD ?
ZTD sur ancienne infra P2P... §
-
Nouvelle version v0.19, qui ne contient encore que des améliorations pour Windows:
- optimisation du code de récupération de la configuration réseau
- ajout de certains paramètres de l'interface réseau dans l'affichage de la configuration réseau (paramètres utiles pour les investigations lors de problèmes de perf)
- ajout de préfixes pour organiser/différencier les différents types de paramètres réseau affichés
- prise en compte de l'overhead PCI Express lors de la vérification du taux de transfert max
- ajout du contrôle des compteurs d'erreur de l'interface réseau avec affichage d'avertissement en cas d'augmentation lors des tests
-
J'ai toujours ce blocage à 2.5 Gbps.... c'est lié à mon PC ?
Etrange en effet, surtout si ça fonctionnait bien avant de changer de box...
J'imagine que tu n'as qu'une machine connectée en 10G pour tester ?
J'ai ajouté des contrôles sur les compteurs d'erreur de l'interface réseau dans la version 0.19, tu peux toujours essayer pour voir si ça remonte quelque chose mais j'y crois pas trop vu que ça marchait bien avec l'autre box ???
-
J'imagine que tu n'as qu'une machine connectée en 10G pour tester ?
J'en ai une autre :
[checkFtthFree v0.19] Windows 11 Build 22631 (64-bit)
-------------------------- 2024-11-23 08:23:14 +0100 --------------------------
Configuration réseau du système:
Adapter.Driver: ASUS XG-C100C 10G PCI-E Network Adapter
Adapter.DriverVersion: 3.1.7.0 (Marvell, 2022-06-02)
Adapter.EEE: Disabled
Adapter.FlowControl: Rx & Tx Enabled
Adapter.IPChecksumOffloadIPv4: Rx & Tx Enabled
Adapter.InterruptModeration: Enabled
Adapter.JumboPacket: Disabled
Adapter.LinkSpeed: 10 Gbps
Adapter.LsoV1IPv4: Enabled
Adapter.LsoV2: Enabled
Adapter.PcieLinkSpeed: 5.0 GT/s
Adapter.PcieLinkWidth: 2
Adapter.PhysicalMediaType: 802.3
Adapter.ReceiveBuffers: 512
Adapter.Rsc: Enabled
Adapter.SpeedDuplex: Auto Negotiation
Adapter.TCPUDPChecksumOffload: Rx & Tx Enabled
Adapter.TransmitBuffers: 2048
NetProfile.NetworkCategory: Private
Tcp.AutoTuningLevelLocal: Normal
Tcp.CongestionProvider: CUBIC
Tcp.EcnCapability: Disabled
Tcp.ScalingHeuristics: Disabled
Tcp.Timestamps: Allowed
[!] La carte réseau utilise actuellement une interface PCI Express avec un taux de transfert ne permettant pas d'atteindre le débit maximum du lien réseau
=> Latence TCP max pour une réception à 1 Gbps: 141 ms
Test TCP local (IPv4): téléchargement depuis la Freebox
--> Latence: 1.13 ms [gigue: 0.33 ms]
--> Débit: 747.15 Mo/s (5.98 Gbps) [fluctuation: 1.29%]
Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [BBR]
--> Latence: 9.36 ms [gigue: 0.58 ms]
--> Débit: 294.17 Mo/s (2.35 Gbps) [fluctuation: 6.07%]
Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [CUBIC]
--> Latence: 8.25 ms [gigue: 1.45 ms]
--> Débit: 284.71 Mo/s (2.28 Gbps) [fluctuation: 4.07%]
[!] Le compteur "CoalescingExceptions" de l'interface réseau a été incrémenté de 777485 pendant les tests.
-------------------------- 2024-11-23 08:24:00 +0100 --------------------------
Pas mieux !
-
Merci pour ce test, il montre bien l'intérêt des fonctionnalités que j'ai ajoutées dernièrement à checkFtthFree :)
Je vais détailler un peu du coup:
Configuration réseau du système:
Adapter.LinkSpeed: 10 Gbps
Adapter.PcieLinkSpeed: 5.0 GT/s
Adapter.PcieLinkWidth: 2
[!] La carte réseau utilise actuellement une interface PCI Express avec un taux de transfert ne permettant pas d'atteindre le débit maximum du lien réseau
Test TCP local (IPv4): téléchargement depuis la Freebox
--> Latence: 1.13 ms [gigue: 0.33 ms]
--> Débit: 747.15 Mo/s (5.98 Gbps) [fluctuation: 1.29%]
Ici on voit que la carte monte bien le lien à 10 Gbps, par contre elle est connectée à un slot PCI Express Gen 2 (5 GT/s) x2, donc limitée à 8 Gbps de bande passante utile max théorique, d'où l'avertissement de checkFtthFree.
Après ce n'est pas vraiment gênant pour le lien WAN qui est de toutes manières limité à 8 Gbps, mais ça explique sans doute le débit LAN bien en-dessous de 10 Gbps.
Configuration réseau du système:
Adapter.Driver: ASUS XG-C100C 10G PCI-E Network Adapter
Adapter.DriverVersion: 3.1.7.0 (Marvell, 2022-06-02)
Si jamais un pilote plus récent est disponible, ça peut valoir le coup d'essayer de le mettre à jour.
Mais bon cela ne concerne que ta deuxième machine, il faudrait voir ce que donne checkFtthFree v0.19 sur la première...
-
Merci !
Ce serait top d'avoir un point de comparaison avec quelqu'un d'autre qui a une Ultra.
[checkFtthFree v0.19] Windows 11 Build 26100 (64-bit)
-------------------------- 2024-11-23 09:07:54 +0100 --------------------------
Configuration réseau du système:
Adapter.Driver: Intel(R) 82599 10 Gigabit Network Connection
Adapter.DriverVersion: 4.1.254.0 (Intel, 2024-02-08)
"\x{0082}" does not map to cp850 at script/checkFtthFree.pl line 446, <STDIN> line 1.
Adapter.FlowControl: Rx et Tx activ\x{0082}es
"\x{0082}" does not map to cp850 at script/checkFtthFree.pl line 446, <STDIN> line 1.
Adapter.IPChecksumOffloadIPv4: Rx et Tx activ\x{0082}es
"\x{0082}" does not map to cp850 at script/checkFtthFree.pl line 446, <STDIN> line 1.
Adapter.InterruptModeration: Activ\x{0082}(e)
"\x{0082}" does not map to cp850 at script/checkFtthFree.pl line 446, <STDIN> line 1.
"\x{0082}" does not map to cp850 at script/checkFtthFree.pl line 446, <STDIN> line 1.
Adapter.JumboPacket: D\x{0082}sactiv\x{0082}(e)
Adapter.LinkSpeed: 10 Gbps
"\x{0082}" does not map to cp850 at script/checkFtthFree.pl line 446, <STDIN> line 1.
Adapter.LsoV2: Activ\x{0082}(e)
Adapter.PcieLinkSpeed: 5.0 GT/s
Adapter.PcieLinkWidth: 4
Adapter.PhysicalMediaType: 802.3
Adapter.ReceiveBuffers: 512
"\x{0082}" does not map to cp850 at script/checkFtthFree.pl line 446, <STDIN> line 1.
Adapter.SpeedDuplex: N\x{0082}gociation automatique
"\x{0082}" does not map to cp850 at script/checkFtthFree.pl line 446, <STDIN> line 1.
Adapter.TCPChecksumOffload: Rx et Tx activ\x{0082}es
Adapter.TransmitBuffers: 512
NetProfile.NetworkCategory: Private
Tcp.AutoTuningLevelLocal: Normal
Tcp.CongestionProvider: CUBIC
Tcp.EcnCapability: Disabled
Tcp.ScalingHeuristics: Disabled
Tcp.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.05 ms]
--> Débit: 1.16 Go/s (9.30 Gbps) [fluctuation: 1.79%]
Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [BBR]
--> Latence: 8.17 ms [gigue: 0.36 ms]
--> Débit: 293.11 Mo/s (2.34 Gbps) [fluctuation: 3.48%]
Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [CUBIC]
--> Latence: 7.65 ms [gigue: 0.40 ms]
--> Débit: 299.31 Mo/s (2.39 Gbps) [fluctuation: 2.50%]
[!] Le compteur "ReceivedDiscardedPackets" de l'interface réseau a été incrémenté de 21076 pendant les tests.
-------------------------- 2024-11-23 09:08:36 +0100 --------------------------
-
J'ai augmenté le tampon !
[checkFtthFree v0.19] Windows 11 Build 26120 (64-bit)
-------------------------- 2024-11-23 10:18:37 +0100 --------------------------
Configuration réseau du système:
Adapter.Driver: Intel(R) 82599 10 Gigabit Network Connection
Adapter.DriverVersion: 4.1.254.0 (Intel, 2024-02-08)
"\x{0082}" does not map to cp850 at script/checkFtthFree.pl line 446, <STDIN> line 1.
Adapter.FlowControl: Rx et Tx activ\x{0082}es
"\x{0082}" does not map to cp850 at script/checkFtthFree.pl line 446, <STDIN> line 1.
Adapter.IPChecksumOffloadIPv4: Rx et Tx activ\x{0082}es
"\x{0082}" does not map to cp850 at script/checkFtthFree.pl line 446, <STDIN> line 1.
Adapter.InterruptModeration: Activ\x{0082}(e)
"\x{0082}" does not map to cp850 at script/checkFtthFree.pl line 446, <STDIN> line 1.
"\x{0082}" does not map to cp850 at script/checkFtthFree.pl line 446, <STDIN> line 1.
Adapter.JumboPacket: D\x{0082}sactiv\x{0082}(e)
Adapter.LinkSpeed: 10 Gbps
"\x{0082}" does not map to cp850 at script/checkFtthFree.pl line 446, <STDIN> line 1.
Adapter.LsoV2: Activ\x{0082}(e)
Adapter.PcieLinkSpeed: 5.0 GT/s
Adapter.PcieLinkWidth: 4
Adapter.PhysicalMediaType: 802.3
Adapter.ReceiveBuffers: 2048
"\x{0082}" does not map to cp850 at script/checkFtthFree.pl line 446, <STDIN> line 1.
Adapter.SpeedDuplex: N\x{0082}gociation automatique
"\x{0082}" does not map to cp850 at script/checkFtthFree.pl line 446, <STDIN> line 1.
Adapter.TCPChecksumOffload: Rx et Tx activ\x{0082}es
Adapter.TransmitBuffers: 2048
NetProfile.NetworkCategory: Private
Tcp.AutoTuningLevelLocal: Normal
Tcp.CongestionProvider: CUBIC
Tcp.EcnCapability: Disabled
Tcp.ScalingHeuristics: Disabled
Tcp.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.42 ms [gigue: 0.34 ms]
--> Débit: 1.13 Go/s (9.08 Gbps) [fluctuation: 2.54%]
Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [BBR]
--> Latence: 8.24 ms [gigue: 0.33 ms]
--> Débit: 291.73 Mo/s (2.33 Gbps) [fluctuation: 6.23%]
Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [CUBIC]
--> Latence: 7.84 ms [gigue: 0.29 ms]
--> Débit: 295.85 Mo/s (2.37 Gbps) [fluctuation: 2.71%]
[!] Le compteur "ReceivedDiscardedPackets" de l'interface réseau a été incrémenté de 64580 pendant les tests.
-------------------------- 2024-11-23 10:19:20 +0100 --------------------------
-
J'ai éléminé, le commutateur en me branchant directement PC/Ultra même si je suis sûr que le problème n'est pas en local (entre 600 et 700 Mo/s avec une transfère de fichier) "on est pas au max au passage derrière le M.2"
Pour moi, l'Ultra est incapable de délivrer plus de 2.5Gbps WAN/LAN à un machine derrière le port SFP+... A croire que le port SFP+ est limité/couplé au commutateur RJ45 2.5 Gbps !
Y a forcément une astuce de la part de Free car j'obtient des vitesses proche de 7/8Gbps en utilisant Ookla/ Nperf sur le PC (multi/serveur)....
Y a t il une personne avec une Ultra qui peut faire le test SVP ?
-
Désolé j'ai oublié une conversion d'encodage, d'où les messages "... does not map to cp850 ..." qui rendent le truc illisible... :-\
C'est corrigé à partir de la version 0.20.
Sinon sur ta première machine on voit qu'il y a pas mal de paquets rejetés pendant les tests:
[!] Le compteur "ReceivedDiscardedPackets" de l'interface réseau a été incrémenté de 64580 pendant les tests.
Mais on ne sait pas si c'est au cours d'un test en particulier ou tous. Ca pourrait très bien être uniquement au cours du test LAN...
Je me rends compte qu'il serait bien mieux d'avoir la vérification des compteurs d'interface entre chaque test, du coup c'est ce que je vais ajouter dans la version 0.21.
-
Y a t il une personne avec une Ultra qui peut faire le test SVP ?
Chez moi cela fonctionne à peu près correctement :
[checkFtthFree v0.21] Windows 11 Build 22631 (64-bit)
-------------------------- 2024-11-23 18:20:19 +0100 --------------------------
Configuration réseau du système:
Adapter.Driver: ASUS XG-C100C 10G PCI-E Network Adapter
Adapter.DriverVersion: 3.1.10.0 (Marvell, 2024-04-23)
Adapter.EEE: Disabled
Adapter.FlowControl: Rx & Tx Enabled
Adapter.IPChecksumOffloadIPv4: Rx & Tx Enabled
Adapter.InterruptModeration: Enabled
Adapter.JumboPacket: Disabled
Adapter.LinkSpeed: 10 Gbps
Adapter.LsoV1IPv4: Enabled
Adapter.LsoV2: Enabled
Adapter.PcieLinkSpeed: 8.0 GT/s
Adapter.PcieLinkWidth: 2
Adapter.PhysicalMediaType: 802.3
Adapter.ReceiveBuffers: 2048
Adapter.Rsc: Enabled
Adapter.SpeedDuplex: Auto Negotiation
Adapter.TCPUDPChecksumOffload: Rx & Tx Enabled
Adapter.TransmitBuffers: 2048
NetProfile.NetworkCategory: Private
Tcp.AutoTuningLevelLocal: Normal
Tcp.CongestionProvider: BBR2
Tcp.EcnCapability: Disabled
Tcp.ScalingHeuristics: Disabled
Tcp.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.40 ms [gigue: 0.02 ms]
--> Débit: 1.19 Go/s (9.49 Gbps) [fluctuation: 0.04%]
[!] Le compteur "CoalescingExceptions" de l'interface réseau a été incrémenté de 29036 pendant le test.
Test TCP Internet (IPv6): téléchargement depuis l'AS 12876 (Scaleway) [BBR]
--> Latence: 7.81 ms [gigue: 0.41 ms]
--> Débit: 795.77 Mo/s (6.37 Gbps) [fluctuation: 5.69%]
[!] Le compteur "CoalescingExceptions" de l'interface réseau a été incrémenté de 30269 pendant le test.
Test TCP Internet (IPv6): téléchargement depuis l'AS 12876 (Scaleway) [CUBIC]
--> Latence: 7.01 ms [gigue: 0.29 ms]
--> Débit: 854.03 Mo/s (6.83 Gbps) [fluctuation: 3.05%]
[!] Le compteur "CoalescingExceptions" de l'interface réseau a été incrémenté de 24630 pendant le test.
-------------------------- 2024-11-23 18:20:47 +0100 --------------------------
[Edit 18:20, test effectué avec la nouvelle version 0.21]
-
Nouvelle version v0.21: contrôle des compteurs d'erreur d'interface entre chaque test sous Windows
@Fuzy Si jamais tu peux refaire un test avec cette version ça permettra peut-être d'y voir un peu plus clair...
-
Configuration réseau du système:
Adapter.Driver: ASUS XG-C100C 10G PCI-E Network Adapter
Adapter.DriverVersion: 3.1.10.0 (Marvell, 2024-04-23)
(...)
[!] Le compteur "CoalescingExceptions" de l'interface réseau a été incrémenté de 30269 pendant le test.
Intéressant, le compteur "CoalescingExceptions" est incrémenté, comme sur la deuxième machine de Fuzy qui a la même carte réseau.
Du coup peut-être que c'est "habituel" d'avoir des coalescing exceptions avec une ASUS XG-C100C.
De mon côté je viens de refaire plusieurs fois le test avec une Broadcom NetXtreme E-Series et tous les compteurs d'erreur restent bien à 0.
-
J'ai désactivé ça dans les options du pilote. J'ai bien sûr plus d'increment du compteur. Mais les débits semblent identiques.
Dans le doute, j'ai réactivé, comme tout fonctionne avec, je change rien :)
-
D'après la doc Microsoft (https://learn.microsoft.com/fr-fr/windows/win32/fwp/wmi/netadaptercimprov/msft-netadapter-rscstatistics):
CoalescingExceptions: Nombre total de cas où un paquet entrant est jugé inéligible pour la fusion
Donc rien à voir avec de véritables erreurs en fait. Le pilote réseau peut très bien faire des choix de fusion selon le type de paquet, le contexte etc.
Je vais ignorer ce compteur dans la prochaine version car cela induit en erreur.
-
Nouvelle version v0.22:
- abandon de la surveillance du compteur d'interface réseau "CoalescingExceptions" sous Windows (compteur non significatif)
- ajout des recommandations automatiques pour les cas où les compteurs d'erreurs de l'interface réseau sont incrémentés pendant les tests sous Windows
- affichage des paramètres de configuration de la mémoire tampon de l'interface réseau sur les systèmes BSD/macOS
-
Merci @darkmoon
@ouno
[checkFtthFree v0.22] Windows 11 Build 26120 (64-bit)
-------------------------- 2024-11-23 21:55:09 +0100 --------------------------
Configuration réseau du système:
Adapter.Driver: Intel(R) 82599 10 Gigabit Network Connection
Adapter.DriverVersion: 4.1.254.0 (Intel, 2024-02-08)
Adapter.FlowControl: Rx et Tx activées
Adapter.IPChecksumOffloadIPv4: Rx et Tx activées
Adapter.InterruptModeration: Activé(e)
Adapter.JumboPacket: Désactivé(e)
Adapter.LinkSpeed: 10 Gbps
Adapter.LsoV2: Activé(e)
Adapter.PcieLinkSpeed: 5.0 GT/s
Adapter.PcieLinkWidth: 4
Adapter.PhysicalMediaType: 802.3
Adapter.ReceiveBuffers: 2048
Adapter.SpeedDuplex: Négociation automatique
Adapter.TCPChecksumOffload: Rx et Tx activées
Adapter.TransmitBuffers: 2048
NetProfile.NetworkCategory: Private
Tcp.AutoTuningLevelLocal: Normal
Tcp.CongestionProvider: CUBIC
Tcp.EcnCapability: Disabled
Tcp.ScalingHeuristics: Disabled
Tcp.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.73 ms [gigue: 0.33 ms]
--> Débit: 1.18 Go/s (9.45 Gbps) [fluctuation: 0.78%]
[!] Le compteur "ReceivedDiscardedPackets" de l'interface réseau a été incrémenté de 122 pendant le test.
Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [BBR]
--> Latence: 25.14 ms [gigue: 12.14 ms]
--> Débit: 70.66 Mo/s (565.29 Mbps) [fluctuation: 39.94%]
[!] Le compteur "ReceivedDiscardedPackets" de l'interface réseau a été incrémenté de 1685 pendant le test.
Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [CUBIC]
--> Latence: 21.90 ms [gigue: 13.22 ms]
--> Débit: 26.31 Mo/s (210.51 Mbps) [fluctuation: 19.64%]
[!] La connexion aux serveurs de test semble affectée par une perte de paquets prononcée
(ratio débit CUBIC/BBR: 37.24%)
-------------------------- 2024-11-23 21:55:59 +0100 --------------------------
-
J'ai bien peur que tu sois dans une zone où le réseau de collecte de Free sature aux heures de pointe (ou alors tu as d'autres téléchargements en même temps qui saturent ta connexion ?).
Du coup il faudrait attendre une heure plus calme pour avoir des données significatives (en dehors du créneau 21h-23h au moins je pense).
Mais c'est quand même étonnant que tu aies autant de paquets rejetés au niveau de l'interface réseau sur le test WAN BBR, surtout à 500 Mbps seulement...
-
C'est claire !
Rien de mon côté, juste une web radio...
JOUE35 est en état critique, bizarre tout le monde est dans les bars a cet heure là un samedi soir sur Rennes !
[checkFtthFree v0.22] Windows 11 Build 26120 (64-bit)
-------------------------- 2024-11-23 22:13:31 +0100 --------------------------
Configuration réseau du système:
Adapter.Driver: Intel(R) 82599 10 Gigabit Network Connection
Adapter.DriverVersion: 4.1.254.0 (Intel, 2024-02-08)
Adapter.FlowControl: Rx et Tx activées
Adapter.IPChecksumOffloadIPv4: Rx et Tx activées
Adapter.InterruptModeration: Activé(e)
Adapter.JumboPacket: Désactivé(e)
Adapter.LinkSpeed: 10 Gbps
Adapter.LsoV2: Activé(e)
Adapter.PcieLinkSpeed: 5.0 GT/s
Adapter.PcieLinkWidth: 4
Adapter.PhysicalMediaType: 802.3
Adapter.ReceiveBuffers: 2048
Adapter.SpeedDuplex: Négociation automatique
Adapter.TCPChecksumOffload: Rx et Tx activées
Adapter.TransmitBuffers: 2048
NetProfile.NetworkCategory: Private
Tcp.AutoTuningLevelLocal: Normal
Tcp.CongestionProvider: CUBIC
Tcp.EcnCapability: Disabled
Tcp.ScalingHeuristics: Disabled
Tcp.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.62 ms [gigue: 0.27 ms]
--> Débit: 1.18 Go/s (9.41 Gbps) [fluctuation: 1.25%]
[!] Le compteur "ReceivedDiscardedPackets" de l'interface réseau a été incrémenté de 128 pendant le test.
Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [BBR]
--> Latence: 24.72 ms [gigue: 12.69 ms]
--> Débit: 310.25 Mo/s (2.48 Gbps) [fluctuation: 2.19%]
[!] Le compteur "ReceivedDiscardedPackets" de l'interface réseau a été incrémenté de 15273 pendant le test.
Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [CUBIC]
--> Latence: 25.64 ms [gigue: 10.91 ms]
--> Débit: 289.29 Mo/s (2.31 Gbps) [fluctuation: 3.47%]
[!] Le compteur "ReceivedDiscardedPackets" de l'interface réseau a été incrémenté de 25973 pendant le test.
-------------------------- 2024-11-23 22:14:17 +0100 --------------------------
Le voisin à fini son telechargement LoL..... par contre la latence...
-
Tu peux essayer de passer ton ReceiveBuffers à 4096 pour voir si ça te permet d'éviter ces paquets rejetés ?
-
@darkmoon, ça me rassure que tu sois a peut près bon derrière l'Ultra !
[checkFtthFree v0.22] Windows 11 Build 26120 (64-bit)
-------------------------- 2024-11-23 22:49:19 +0100 --------------------------
Configuration réseau du système:
Adapter.Driver: Intel(R) 82599 10 Gigabit Network Connection
Adapter.DriverVersion: 4.1.254.0 (Intel, 2024-02-08)
Adapter.FlowControl: Rx et Tx activées
Adapter.IPChecksumOffloadIPv4: Rx et Tx activées
Adapter.InterruptModeration: Activé(e)
Adapter.JumboPacket: Désactivé(e)
Adapter.LinkSpeed: 10 Gbps
Adapter.LsoV2: Activé(e)
Adapter.PcieLinkSpeed: 5.0 GT/s
Adapter.PcieLinkWidth: 4
Adapter.PhysicalMediaType: 802.3
Adapter.ReceiveBuffers: 2048
Adapter.SpeedDuplex: Négociation automatique
Adapter.TCPChecksumOffload: Rx et Tx activées
Adapter.TransmitBuffers: 2048
NetProfile.NetworkCategory: Private
Tcp.AutoTuningLevelLocal: Normal
Tcp.CongestionProvider: CUBIC
Tcp.EcnCapability: Disabled
Tcp.ScalingHeuristics: Disabled
Tcp.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.85 ms [gigue: 0.37 ms]
--> Débit: 1.06 Go/s (8.49 Gbps) [fluctuation: 5.19%]
[!] Le compteur "ReceivedDiscardedPackets" de l'interface réseau a été incrémenté de 349 pendant le test.
Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [BBR]
--> Latence: 10.97 ms [gigue: 2.62 ms]
--> Débit: 259.65 Mo/s (2.08 Gbps) [fluctuation: 21.09%]
[!] Le compteur "ReceivedDiscardedPackets" de l'interface réseau a été incrémenté de 23003 pendant le test.
Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [CUBIC]
--> Latence: 9.21 ms [gigue: 2.35 ms]
--> Débit: 248.84 Mo/s (1.99 Gbps) [fluctuation: 11.21%]
[!] Le compteur "ReceivedDiscardedPackets" de l'interface réseau a été incrémenté de 18779 pendant le test.
-------------------------- 2024-11-23 22:50:05 +0100 --------------------------
@ouno
Tu penses que c'est lié a la machine ou il y a une bidouille au NRO concernant la limitation à 2.5Gbps ?
Je me tâte à la remonter (PC) en retirant "tous" nvme secondaire et PCI....à part la carte 10Gbps...
-
Tu peux essayer de passer ton ReceiveBuffers à 4096 pour voir si ça te permet d'éviter ces paquets rejetés ?
[checkFtthFree v0.22] Windows 11 Build 26120 (64-bit)
-------------------------- 2024-11-23 22:57:39 +0100 --------------------------
Configuration réseau du système:
Adapter.Driver: Intel(R) 82599 10 Gigabit Network Connection
Adapter.DriverVersion: 4.1.254.0 (Intel, 2024-02-08)
Adapter.FlowControl: Rx et Tx activées
Adapter.IPChecksumOffloadIPv4: Rx et Tx activées
Adapter.InterruptModeration: Activé(e)
Adapter.JumboPacket: Désactivé(e)
Adapter.LinkSpeed: 10 Gbps
Adapter.LsoV2: Activé(e)
Adapter.PcieLinkSpeed: 5.0 GT/s
Adapter.PcieLinkWidth: 4
Adapter.PhysicalMediaType: 802.3
Adapter.ReceiveBuffers: 4096
Adapter.SpeedDuplex: Négociation automatique
Adapter.TCPChecksumOffload: Rx et Tx activées
Adapter.TransmitBuffers: 2048
NetProfile.NetworkCategory: Private
Tcp.AutoTuningLevelLocal: Normal
Tcp.CongestionProvider: CUBIC
Tcp.EcnCapability: Disabled
Tcp.ScalingHeuristics: Disabled
Tcp.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.07 ms [gigue: 1.70 ms]
--> Débit: 1.18 Go/s (9.45 Gbps) [fluctuation: 0.71%]
[!] Le compteur "ReceivedDiscardedPackets" de l'interface réseau a été incrémenté de 412 pendant le test.
Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [BBR]
--> Latence: 9.44 ms [gigue: 1.53 ms]
--> Débit: 305.38 Mo/s (2.44 Gbps) [fluctuation: 2.95%]
[!] Le compteur "ReceivedDiscardedPackets" de l'interface réseau a été incrémenté de 10839 pendant le test.
Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [CUBIC]
--> Latence: 9.13 ms [gigue: 1.39 ms]
--> Débit: 294.20 Mo/s (2.35 Gbps) [fluctuation: 2.65%]
[!] Le compteur "ReceivedDiscardedPackets" de l'interface réseau a été incrémenté de 7783 pendant le test.
-------------------------- 2024-11-23 22:58:25 +0100 --------------------------
-
On dirait que cela a amélioré les choses (paquets rejetés divisé par 2 à peu près sur les tests WAN), mais c'est peut-être un hasard sur un seul test, il faudrait faire plusieurs tests pour confirmer.
Dans tous les cas il reste quand même des paquets rejetés, ce qui n'est pas normal avec un ReceiveBuffers à 4096 sauf si la machine est pas assez puissante ou chargée par ailleurs...
Tu as surveillé la conso CPU pendant les tests ?
@ouno
Tu penses que c'est lié a la machine ou il y a une bidouille au NRO concernant la limitation à 2.5Gbps ?
Je me tâte à la remonter (PC) en retirant "tous" nvme secondaire et PCI....à par la carte 10Gbps...
J'ai l'impression qu'il y a quelque chose sur la machine qui fait que les buffers de réception au niveau de l'interface saturent dans certaines conditions (paquets réordonnés ? pare-feu qui consomme trop de ressources ? ...)
Mais c'est peut-être indépendant du problème de saturation à 2,5 Gbps que tu rencontres. Surtout qu'en multi-connexions tu arrives bien à dépasser 2,5 Gbps sur cette machine je crois ?
-
Je te confirme !
[checkFtthFree v0.22] Windows 11 Build 26120 (64-bit)
-------------------------- 2024-11-23 23:26:52 +0100 --------------------------
Configuration réseau du système:
Adapter.Driver: Intel(R) 82599 10 Gigabit Network Connection
Adapter.DriverVersion: 4.1.254.0 (Intel, 2024-02-08)
Adapter.FlowControl: Rx et Tx activées
Adapter.IPChecksumOffloadIPv4: Rx et Tx activées
Adapter.InterruptModeration: Activé(e)
Adapter.JumboPacket: Désactivé(e)
Adapter.LinkSpeed: 10 Gbps
Adapter.LsoV2: Activé(e)
Adapter.PcieLinkSpeed: 5.0 GT/s
Adapter.PcieLinkWidth: 4
Adapter.PhysicalMediaType: 802.3
Adapter.ReceiveBuffers: 4096
Adapter.SpeedDuplex: Négociation automatique
Adapter.TCPChecksumOffload: Rx et Tx activées
Adapter.TransmitBuffers: 2048
NetProfile.NetworkCategory: Private
Tcp.AutoTuningLevelLocal: Normal
Tcp.CongestionProvider: CUBIC
Tcp.EcnCapability: Disabled
Tcp.ScalingHeuristics: Disabled
Tcp.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.87 ms [gigue: 0.32 ms]
--> Débit: 1.19 Go/s (9.49 Gbps) [fluctuation: 0.03%]
Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [BBR]
--> Latence: 8.49 ms [gigue: 0.55 ms]
--> Débit: 293.35 Mo/s (2.35 Gbps) [fluctuation: 3.14%]
[!] Le compteur "ReceivedDiscardedPackets" de l'interface réseau a été incrémenté de 4381 pendant le test.
Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [CUBIC]
--> Latence: 8.00 ms [gigue: 0.33 ms]
--> Débit: 296.66 Mo/s (2.37 Gbps) [fluctuation: 2.41%]
[!] Le compteur "ReceivedDiscardedPackets" de l'interface réseau a été incrémenté de 4208 pendant le test.
[checkFtthFree v0.22] Windows 11 Build 26120 (64-bit)
-------------------------- 2024-11-23 23:28:16 +0100 --------------------------
Configuration réseau du système:
Adapter.Driver: Intel(R) 82599 10 Gigabit Network Connection
Adapter.DriverVersion: 4.1.254.0 (Intel, 2024-02-08)
Adapter.FlowControl: Rx et Tx activées
Adapter.IPChecksumOffloadIPv4: Rx et Tx activées
Adapter.InterruptModeration: Activé(e)
Adapter.JumboPacket: Désactivé(e)
Adapter.LinkSpeed: 10 Gbps
Adapter.LsoV2: Activé(e)
Adapter.PcieLinkSpeed: 5.0 GT/s
Adapter.PcieLinkWidth: 4
Adapter.PhysicalMediaType: 802.3
Adapter.ReceiveBuffers: 4096
Adapter.SpeedDuplex: Négociation automatique
Adapter.TCPChecksumOffload: Rx et Tx activées
Adapter.TransmitBuffers: 2048
NetProfile.NetworkCategory: Private
Tcp.AutoTuningLevelLocal: Normal
Tcp.CongestionProvider: CUBIC
Tcp.EcnCapability: Disabled
Tcp.ScalingHeuristics: Disabled
Tcp.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.71 ms [gigue: 0.29 ms]
--> Débit: 1.18 Go/s (9.47 Gbps) [fluctuation: 0.28%]
[!] Le compteur "ReceivedDiscardedPackets" de l'interface réseau a été incrémenté de 436 pendant le test.
Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [BBR]
--> Latence: 8.27 ms [gigue: 0.46 ms]
--> Débit: 285.25 Mo/s (2.28 Gbps) [fluctuation: 5.01%]
[!] Le compteur "ReceivedDiscardedPackets" de l'interface réseau a été incrémenté de 9220 pendant le test.
Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [CUBIC]
--> Latence: 7.98 ms [gigue: 0.52 ms]
--> Débit: 280.05 Mo/s (2.24 Gbps) [fluctuation: 5.01%]
[!] Le compteur "ReceivedDiscardedPackets" de l'interface réseau a été incrémenté de 5805 pendant le test.
-------------------------- 2024-11-23 23:29:02 +0100 --------------------------
[checkFtthFree v0.22] Windows 11 Build 26120 (64-bit)
-------------------------- 2024-11-23 23:29:27 +0100 --------------------------
Configuration réseau du système:
Adapter.Driver: Intel(R) 82599 10 Gigabit Network Connection
Adapter.DriverVersion: 4.1.254.0 (Intel, 2024-02-08)
Adapter.FlowControl: Rx et Tx activées
Adapter.IPChecksumOffloadIPv4: Rx et Tx activées
Adapter.InterruptModeration: Activé(e)
Adapter.JumboPacket: Désactivé(e)
Adapter.LinkSpeed: 10 Gbps
Adapter.LsoV2: Activé(e)
Adapter.PcieLinkSpeed: 5.0 GT/s
Adapter.PcieLinkWidth: 4
Adapter.PhysicalMediaType: 802.3
Adapter.ReceiveBuffers: 4096
Adapter.SpeedDuplex: Négociation automatique
Adapter.TCPChecksumOffload: Rx et Tx activées
Adapter.TransmitBuffers: 2048
NetProfile.NetworkCategory: Private
Tcp.AutoTuningLevelLocal: Normal
Tcp.CongestionProvider: CUBIC
Tcp.EcnCapability: Disabled
Tcp.ScalingHeuristics: Disabled
Tcp.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.95 ms [gigue: 0.31 ms]
--> Débit: 1.18 Go/s (9.44 Gbps) [fluctuation: 0.30%]
[!] Le compteur "ReceivedDiscardedPackets" de l'interface réseau a été incrémenté de 604 pendant le test.
Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [BBR]
--> Latence: 8.10 ms [gigue: 0.34 ms]
--> Débit: 279.69 Mo/s (2.24 Gbps) [fluctuation: 5.06%]
[!] Le compteur "ReceivedDiscardedPackets" de l'interface réseau a été incrémenté de 13300 pendant le test.
Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [CUBIC]
--> Latence: 8.17 ms [gigue: 0.18 ms]
--> Débit: 291.02 Mo/s (2.33 Gbps) [fluctuation: 1.76%]
[!] Le compteur "ReceivedDiscardedPackets" de l'interface réseau a été incrémenté de 2625 pendant le test.
-------------------------- 2024-11-23 23:30:13 +0100 --------------------------
-
les ReceiveBuffers a 512 ou 1024 suffisent largement sur Windows. je n'ai jamais constaté d'impact en les changeant.
essaie en IPv6 (option -6 de checkFtthFree) pour voir y'a peut-être un limitation/saturation sur le routeur de tunnel coté Free.
essaie aussi avec nspeed pour voir si en mono avec un autre serveur ca limite aussi a 2G:
wget -OutFile nspeed.exe https://dl.nspeed.app/nspeed-client/preview/nspeed_windows_amd64_v1/nspeed.exe
./nspeed.exe -cpu -color from https://dl.nspeed.app/aw
-
essaie aussi avec nspeed pour voir si en mono avec un autre serveur ca limite aussi a 2G:
./nspeed.exe -cpu -color from https://dl.nspeed.app/aw
reading commands from https://dl.nspeed.app/aw
running jobs of 'download mono' (0)...
| c0| c1| c2| c3| c4| c5| c6| c7| c8| c9|c10|c11| jobs | threads|
| 14| 6| 29| 9| 27| 0| 17| 4| 10| 5| 31| 0| 10 | 8 |
| 13| 16| 20| 9| 13| 11| 17| 6| 11| 6| 39| 2| 10 | 8 |
| 16| 3| 11| 0| 12| 6| 14| 0| 14| 6| 48| 2| 10 | 8 |
| 20| 3| 13| 8| 9| 3| 9| 2| 6| 2| 30| 0| 10 | 8 |
| 19| 5| 8| 0| 11| 2| 11| 0| 17| 0| 34| 2| 10 | 8 |
| 21| 11| 5| 3| 11| 11| 11| 5| 9| 8| 36| 2| 10 | 8 |
| 14| 11| 13| 8| 16| 3| 17| 5| 2| 9| 54| 0| 10 | 8 |
| 23| 11| 6| 5| 8| 3| 2| 3| 5| 3| 38| 2| 10 | 8 |
running jobs of 'upload mono' (1)...
| 13| 2| 16| 6| 25| 0| 12| 19| 9| 6| 8| 8| 9 | 8 |
| 11| 9| 18| 11| 17| 6| 14| 6| 9| 5| 17| 13| 9 | 8 |
| 5| 2| 13| 3| 17| 2| 6| 9| 16| 9| 2| 2| 9 | 8 |
| 8| 5| 11| 3| 26| 2| 6| 9| 3| 2| 22| 5| 9 | 8 |
| 9| 8| 5| 3| 19| 2| 9| 0| 14| 3| 9| 9| 9 | 8 |
| 12| 9| 8| 5| 20| 0| 5| 2| 6| 5| 22| 9| 9 | 8 |
| 15| 5| 13| 6| 20| 0| 8| 6| 6| 8| 19| 3| 9 | 8 |
| 17| 5| 9| 0| 19| 2| 15| 8| 9| 2| 8| 9| 9 | 8 |
running jobs of 'download multi' (2)...
| 33| 3| 13| 13| 17| 8| 34| 2| 12| 9| 17| 8| 8 | 17 |
| 36| 2| 19| 9| 39| 3| 25| 3| 18| 8| 15| 0| 8 | 17 |
| 28| 0| 20| 19| 38| 2| 35| 2| 14| 11| 24| 5| 8 | 17 |
| 36| 3| 27| 23| 33| 3| 48| 8| 17| 8| 28| 5| 8 | 17 |
| 39| 2| 23| 19| 25| 3| 38| 2| 17| 6| 27| 8| 8 | 17 |
| 39| 5| 23| 19| 28| 3| 23| 5| 14| 16| 34| 8| 8 | 17 |
| 34| 3| 23| 14| 27| 3| 41| 2| 14| 8| 20| 0| 8 | 17 |
| 22| 3| 22| 8| 28| 3| 38| 6| 11| 9| 24| 3| 8 | 17 |
running jobs of 'upload multi' (3)...
| 16| 3| 11| 8| 11| 8| 19| 3| 25| 3| 20| 18| 4 | 17 |
| 15| 9| 14| 9| 9| 3| 20| 3| 17| 2| 17| 14| 4 | 17 |
| 15| 11| 16| 6| 9| 3| 17| 2| 17| 2| 16| 8| 4 | 17 |
| 8| 12| 8| 12| 14| 9| 17| 0| 17| 0| 9| 11| 4 | 17 |
| 6| 3| 11| 9| 5| 5| 17| 0| 9| 2| 23| 11| 4 | 17 |
| 19| 17| 31| 17| 22| 9| 22| 5| 17| 6| 16| 11| 4 | 17 |
| 17| 9| 28| 33| 14| 16| 16| 8| 20| 3| 22| 17| 4 | 17 |
| 9| 11| 12| 12| 11| 9| 25| 5| 25| 2| 22| 17| 4 | 17 |
batch download mono:
Id| Read speed| Write speed| Time| Bytes read| Bytes written|command
#0| 2.2 Gbps| 0 bps| 8.00| 2.2 GB| 0 B|get http://appliwave.testdebit.info/10G/10G.iso (IPv6 - 10.238 ms - HTTP/1.1 - )
batch upload mono:
Id| Read speed| Write speed| Time| Bytes read| Bytes written|command
#1| 0 bps| 3.2 Gbps| 8.00| 0 B| 3.2 GB|post http://appliwave.testdebit.info/ul/ 10.7 GB (IPv6 - 8.468 ms - - )
batch download multi:
Id| Read speed| Write speed| Time| Bytes read| Bytes written|command
#2| 6.0 Gbps| 0 bps| 8.00| 6.0 GB| 0 B|4 x get http://appliwave.testdebit.info/10G/10G.iso (IPv6 - 9.156 ms - HTTP/1.1 - )
batch upload multi:
Id| Read speed| Write speed| Time| Bytes read| Bytes written|command
#3| 0 bps| 5.6 Gbps| 8.00| 0 B| 5.6 GB|4 x post http://appliwave.testdebit.info/ul/ 10.7 GB (IPv6 - 8.268 ms - - )
[checkFtthFree v0.22] Windows 11 Build 26120 (64-bit)
-------------------------- 2024-11-24 11:37:58 +0100 --------------------------
Configuration réseau du système:
Adapter.Driver: Intel(R) 82599 10 Gigabit Network Connection
Adapter.DriverVersion: 4.1.254.0 (Intel, 2024-02-08)
Adapter.FlowControl: Rx et Tx activées
Adapter.IPChecksumOffloadIPv4: Rx et Tx activées
Adapter.InterruptModeration: Activé(e)
Adapter.JumboPacket: Désactivé(e)
Adapter.LinkSpeed: 10 Gbps
Adapter.LsoV2: Activé(e)
Adapter.PcieLinkSpeed: 5.0 GT/s
Adapter.PcieLinkWidth: 4
Adapter.PhysicalMediaType: 802.3
Adapter.ReceiveBuffers: 4096
Adapter.SpeedDuplex: Négociation automatique
Adapter.TCPChecksumOffload: Rx et Tx activées
Adapter.TransmitBuffers: 2048
NetProfile.NetworkCategory: Private
Tcp.AutoTuningLevelLocal: Normal
Tcp.CongestionProvider: CUBIC
Tcp.EcnCapability: Disabled
Tcp.ScalingHeuristics: Disabled
Tcp.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.75 ms [gigue: 0.26 ms]
--> Débit: 1.18 Go/s (9.43 Gbps) [fluctuation: 0.95%]
[!] Le compteur "ReceivedDiscardedPackets" de l'interface réseau a été incrémenté de 176 pendant le test.
Test TCP Internet (IPv6): téléchargement depuis l'AS 12876 (Scaleway) [BBR]
--> Latence: 8.58 ms [gigue: 1.06 ms]
--> Débit: 284.12 Mo/s (2.27 Gbps) [fluctuation: 6.01%]
[!] Le compteur "ReceivedDiscardedPackets" de l'interface réseau a été incrémenté de 7208 pendant le test.
Test TCP Internet (IPv6): téléchargement depuis l'AS 12876 (Scaleway) [CUBIC]
--> Latence: 7.95 ms [gigue: 0.29 ms]
--> Débit: 294.53 Mo/s (2.36 Gbps) [fluctuation: 0.87%]
[!] Le compteur "ReceivedDiscardedPackets" de l'interface réseau a été incrémenté de 1761 pendant le test.
-------------------------- 2024-11-24 11:38:42 +0100 --------------------------
-
curieux ton cas.
"Windows 11 Build 26120" c'est la version 24H2 Insiders ca non ? ca peut venir de la (ou pas ;D )
sinon tente de couper le firewall pendant un test. via l'interface de sécu ou en terminal admin:
Set-NetFirewallProfile -Profile Domain,Public,Private -Enabled Falsepour le remettre
Set-NetFirewallProfile -Profile Domain,Public,Private -Enabled True
-
Yep j'ai fais le test sur canari et Dev au cas ou !
[checkFtthFree v0.22] Windows 11 Build 26100 (64-bit)
-------------------------- 2024-11-24 15:18:46 +0100 --------------------------
Configuration réseau du système:
Adapter.Driver: Intel(R) 82599 10 Gigabit Network Connection
Adapter.DriverVersion: 4.1.254.0 (Intel, 2024-02-08)
Adapter.FlowControl: Rx et Tx activées
Adapter.IPChecksumOffloadIPv4: Rx et Tx activées
Adapter.InterruptModeration: Activé(e)
Adapter.JumboPacket: Désactivé(e)
Adapter.LinkSpeed: 10 Gbps
Adapter.LsoV2: Activé(e)
Adapter.PcieLinkSpeed: 5.0 GT/s
Adapter.PcieLinkWidth: 4
Adapter.PhysicalMediaType: 802.3
Adapter.ReceiveBuffers: 512
Adapter.SpeedDuplex: Négociation automatique
Adapter.TCPChecksumOffload: Rx et Tx activées
Adapter.TransmitBuffers: 512
NetProfile.NetworkCategory: Private
Tcp.AutoTuningLevelLocal: Normal
Tcp.CongestionProvider: CUBIC
Tcp.EcnCapability: Disabled
Tcp.ScalingHeuristics: Disabled
Tcp.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.74 ms [gigue: 0.23 ms]
--> Débit: 1.18 Go/s (9.45 Gbps) [fluctuation: 0.50%]
[!] Le compteur "ReceivedDiscardedPackets" de l'interface réseau a été incrémenté de 1809 pendant le test.
Test TCP Internet (IPv6): téléchargement depuis l'AS 12876 (Scaleway) [BBR]
--> Latence: 14.74 ms [gigue: 7.30 ms]
--> Débit: 206.31 Mo/s (1.65 Gbps) [fluctuation: 13.36%]
[!] Le compteur "ReceivedDiscardedPackets" de l'interface réseau a été incrémenté de 22905 pendant le test.
Test TCP Internet (IPv6): téléchargement depuis l'AS 12876 (Scaleway) [CUBIC]
--> Latence: 20.68 ms [gigue: 10.45 ms]
--> Débit: 186.03 Mo/s (1.49 Gbps) [fluctuation: 18.81%]
[!] Le compteur "ReceivedDiscardedPackets" de l'interface réseau a été incrémenté de 69681 pendant le test.
-------------------------- 2024-11-24 15:19:31 +0100 --------------------------
/nspeed.exe -cpu -color from https://dl.nspeed.app/aw
reading commands from https://dl.nspeed.app/aw
running jobs of 'download mono' (0)...
| c0| c1| c2| c3| c4| c5| c6| c7| c8| c9|c10|c11| jobs | threads|
| 18| 12| 46| 6| 15| 13| 14| 8| 20| 6| 14| 28| 10 | 8 |
| 9| 3| 53| 2| 25| 8| 16| 6| 9| 8| 9| 3| 10 | 8 |
| 14| 5| 46| 2| 5| 5| 22| 0| 14| 0| 3| 5| 10 | 8 |
| 9| 11| 39| 2| 30| 16| 8| 8| 16| 3| 6| 9| 10 | 8 |
| 11| 15| 52| 3| 15| 11| 14| 5| 17| 5| 12| 8| 10 | 8 |
| 17| 5| 42| 3| 17| 6| 12| 11| 11| 2| 20| 5| 10 | 8 |
| 17| 8| 32| 0| 23| 11| 14| 8| 11| 3| 8| 0| 10 | 8 |
| 6| 0| 34| 2| 8| 6| 17| 2| 12| 2| 11| 0| 10 | 5 |
running jobs of 'upload mono' (1)...
| 8| 8| 14| 2| 6| 0| 2| 0| 16| 2| 19| 3| 9 | 8 |
| 22| 3| 13| 16| 19| 9| 17| 6| 19| 3| 13| 5| 9 | 8 |
| 5| 3| 20| 5| 15| 8| 16| 5| 17| 2| 12| 2| 9 | 8 |
| 9| 2| 31| 3| 11| 3| 2| 2| 14| 0| 9| 5| 9 | 8 |
| 2| 5| 31| 3| 17| 14| 14| 3| 22| 6| 12| 5| 9 | 8 |
| 13| 3| 10| 0| 6| 8| 6| 6| 19| 2| 20| 0| 9 | 8 |
| 6| 6| 13| 0| 11| 3| 9| 8| 20| 0| 22| 0| 9 | 8 |
| 3| 2| 23| 2| 15| 6| 12| 3| 18| 2| 12| 3| 9 | 8 |
running jobs of 'download multi' (2)...
| 3| 3| 42| 3| 24| 6| 46| 2| 11| 5| 31| 5| 8 | 17 |
| 9| 5| 44| 5| 17| 6| 45| 3| 16| 3| 23| 8| 8 | 17 |
| 14| 8| 36| 0| 13| 0| 39| 0| 6| 0| 19| 2| 8 | 17 |
| 8| 6| 44| 6| 13| 8| 52| 3| 20| 3| 31| 3| 8 | 17 |
| 18| 6| 39| 0| 16| 3| 31| 0| 8| 5| 28| 3| 8 | 17 |
| 16| 5| 49| 5| 12| 0| 45| 0| 9| 3| 36| 2| 8 | 17 |
| 15| 6| 48| 3| 17| 5| 51| 3| 19| 3| 32| 6| 8 | 17 |
| 20| 6| 46| 2| 17| 2| 53| 0| 9| 3| 27| 2| 8 | 17 |
running jobs of 'upload multi' (3)...
| 9| 2| 17| 8| 13| 3| 22| 5| 13| 11| 13| 22| 4 | 17 |
| 12| 2| 14| 0| 19| 6| 25| 2| 13| 3| 11| 3| 4 | 17 |
| 15| 0| 9| 8| 20| 3| 27| 0| 8| 3| 6| 2| 4 | 17 |
| 15| 3| 8| 3| 22| 2| 22| 0| 14| 2| 11| 6| 4 | 17 |
| 11| 0| 17| 11| 16| 0| 15| 0| 6| 2| 8| 6| 4 | 17 |
| 15| 2| 20| 3| 9| 0| 23| 0| 13| 6| 9| 6| 4 | 17 |
| 16| 0| 17| 2| 17| 3| 36| 2| 17| 6| 13| 5| 4 | 17 |
| 11| 5| 9| 2| 23| 5| 28| 3| 8| 3| 11| 0| 4 | 17 |
batch download mono:
Id| Read speed| Write speed| Time| Bytes read| Bytes written|command
#0| 2.1 Gbps| 0 bps| 8.00| 2.1 GB| 0 B|get http://appliwave.testdebit.info/10G/10G.iso (IPv6 - 9.713 ms - HTTP/1.1 - )
batch upload mono:
Id| Read speed| Write speed| Time| Bytes read| Bytes written|command
#1| 0 bps| 4.7 Gbps| 8.00| 0 B| 4.7 GB|post http://appliwave.testdebit.info/ul/ 10.7 GB (IPv6 - 8.495 ms - - )
batch download multi:
Id| Read speed| Write speed| Time| Bytes read| Bytes written|command
#2| 5.1 Gbps| 0 bps| 8.00| 5.1 GB| 0 B|4 x get http://appliwave.testdebit.info/10G/10G.iso (IPv6 - 8.20 ms - HTTP/1.1 - )
batch upload multi:
Id| Read speed| Write speed| Time| Bytes read| Bytes written|command
#3| 0 bps| 7.0 Gbps| 8.00| 0 B| 7.0 GB|4 x post http://appliwave.testdebit.info/ul/ 10.7 GB (IPv6 - 8.93 ms - - )
-
Nouvelle version 0.23, qui se concentre essentiellement sur les systèmes autres que Windows cette fois-ci, et qui apporte notamment la surveillance automatique des compteurs d'erreurs réseau sous Linux (à venir pour les systèmes BSD et macOS...):
- [Linux] Prise en compte de la surveillance des compteurs d'erreurs lors des tests:
- compteurs liés à l'interface réseau (rx|tx_errors, rx|tx_dropped, collisions...)
- compteurs liés au mécanisme softnet du noyau (rx_softnet_dropped et rx_softnet_squeezed) - [Linux / NetBSD / OpenBSD] Affichage de nouveaux paramètres de configuration réseau:
- Linux: net.core.netdev_budget, net.core.netdev_budget_usecs, net.core.netdev_max_backlog, net.ipv4.tcp_dsack, net.ipv4.tcp_ecn
- NetBSD: net.inet.tcp.timestamps, net.inet.tcp.congctl.available, net.inet.tcp.congctl.selected
- OpenBSD: net.inet.tcp.reasslimit, net.inet.tcp.sack, net.inet.tcp.ecn - [Linux / *BSD / macOS] Affichage de nouvelles informations concernant l'interface réseau utilisée:
- nom de l'interface (link_dev) et MTU associé (link_mtu)
- Linux seulement: discipline (link_qdisc) et taille (link_qlen) de la file d'attente d'envoi, avec détection des agrégats de liens (bonding) pour afficher les paramètres du lien actif en plus de l'agrégat - Amélioration des recommandations lorsque des erreurs réseau sont détectées pendant les tests (paramètre -s|--suggestion)
-
Y a forcément une bidouille... par rapport à cette limitation.. Je vais passer les fêtes de fin d'année et m'engager vers un autre FAI, histoire de voir si l'herbe est plus verte !
-
Tu peux essayer avec un linux en live usb ?
Ça permettra de voir si le souci vient de windows.
-
Configuration réseau du système:
Adapter.ReceiveBuffers: 512
[!] Le compteur "ReceivedDiscardedPackets" de l'interface réseau a été incrémenté de 69681 pendant le test.
Là on voit bien que le fait d'être redescendu à 512 en ReceiveBuffers fait exploser les paquets rejetés...
Tu as regardé s'il n'y avait pas de pilote plus à jour que celui-ci pour ta carte réseau ? ou plus adapté à ce modèle précis ? (pilotes du fabriquant de la puce VS pilotes de l'assembleur de la carte complète...)
Il y a peut-être un truc bien particulier qui est mal géré par ce pilote, ou qui entre en conflit avec autre chose sur ta machine.
Tu n'as pas un anti-virus avec une couche de protection réseau qui traine quelque part, ou bien un accélérateur de connexion ADSL qui se transforme en ralentisseur de connexion FTTH ?
Tu pourrais tester en désactivant une par une certaines fonctionnalités au niveau des paramètres avancés de la carte réseau, par exemple le RSC, l'interrupt moderation, le RSS...
Tant qu'il y a des paquets rejetés par l'interface c'est difficile de mettre en cause la connexion ou la box, même si c'est quand même bizarre effectivement que tu n'aies pas eu ce problème avec la Delta.
Tu n'as rien changé niveau matos ou logiciel de ton côté en même temps ?
-
j'ai une version plus ancienne du même pilote que lui et pas de souci:
[checkFtthFree v0.23] Windows 11 Build 22631 (64-bit)
...
Adapter.Driver: Intel(R) 82599 10 Gigabit Network Connection
Adapter.DriverVersion: 4.1.239.0 (Intel, 2021-03-13)
bon apres je ne suis pas chez Free...
et mon Windows 11 est a jour mais n'est pas en 24H2 il est en 23H2.
Intel n'a pas de pilote officiel Windows 11 pour ce contrôleur, que Windows 10.
j'ai mis a jour mon pilote en 4.1.254.0 (pilote Windows 10 dans Windows 11) comme lui et avec les tampons a défaut (512): j'ai les mêmes résultats qu'avant (environ 6Gbps).
(j'ai bien un message "[!] Le compteur "ReceivedDiscardedPackets" de l'interface réseau a été incrémenté de 54248 pendant le test." avec les tampons a 512. Si je règle a 4096 le tampon, je n'ai plus ce message mais le meme débit max).
Windows 11 24H2 est peut être la raison ici (ou pas).
d'ou +1 a la reco de darkmoon de tester avec un Linux live usb.
-
Il me semble que je sois sur la même version W11 que vous sur la 2eme machine :
[checkFtthFree v0.19] Windows 11 Build 22631 (64-bit)
-------------------------- 2024-11-26 07:18:10 +0100 --------------------------
Configuration réseau du système:
Adapter.Driver: ASUS XG-C100C 10G PCI-E Network Adapter
Adapter.DriverVersion: 3.1.7.0 (Marvell, 2022-06-02)
Adapter.EEE: Disabled
Adapter.FlowControl: Rx & Tx Enabled
Adapter.IPChecksumOffloadIPv4: Rx & Tx Enabled
Adapter.InterruptModeration: Enabled
Adapter.JumboPacket: Disabled
Adapter.LinkSpeed: 10 Gbps
Adapter.LsoV1IPv4: Enabled
Adapter.LsoV2: Enabled
Adapter.PcieLinkSpeed: 5.0 GT/s
Adapter.PcieLinkWidth: 2
Adapter.PhysicalMediaType: 802.3
Adapter.ReceiveBuffers: 512
Adapter.Rsc: Enabled
Adapter.SpeedDuplex: Auto Negotiation
Adapter.TCPUDPChecksumOffload: Rx & Tx Enabled
Adapter.TransmitBuffers: 2048
NetProfile.NetworkCategory: Private
Tcp.AutoTuningLevelLocal: Normal
Tcp.CongestionProvider: CUBIC
Tcp.EcnCapability: Disabled
Tcp.ScalingHeuristics: Disabled
Tcp.Timestamps: Allowed
[!] La carte réseau utilise actuellement une interface PCI Express avec un taux de transfert ne permettant pas d'atteindre le débit maximum du lien réseau
=> Latence TCP max pour une réception à 1 Gbps: 141 ms
Test TCP local (IPv4): téléchargement depuis la Freebox
--> Latence: 0.94 ms [gigue: 0.30 ms]
--> Débit: 739.80 Mo/s (5.92 Gbps) [fluctuation: 0.92%]
Test TCP Internet (IPv6): téléchargement depuis l'AS 12876 (Scaleway) [BBR]
--> Latence: 8.51 ms [gigue: 0.09 ms]
--> Débit: 288.73 Mo/s (2.31 Gbps) [fluctuation: 4.30%]
Test TCP Internet (IPv6): téléchargement depuis l'AS 12876 (Scaleway) [CUBIC]
--> Latence: 8.04 ms [gigue: 0.45 ms]
--> Débit: 287.04 Mo/s (2.30 Gbps) [fluctuation: 3.08%]
[!] Le compteur "CoalescingExceptions" de l'interface réseau a été incrémenté de 478673 pendant les tests.
-------------------------- 2024-11-26 07:18:51 +0100 --------------------------
Donc...
Je ferais le test sous en direct usb, pour voir !
-
Ah intéressant ton retour kgersen, ça permet effectivement d'écarter pas mal de pistes.
j'ai mis a jour mon pilote en 4.1.254.0 (pilote Windows 10 dans Windows 11) comme lui et avec les tampons a défaut (512): j'ai les mêmes résultats qu'avant (environ 6Gbps).
j'ai bien un message "[!] Le compteur "ReceivedDiscardedPackets" de l'interface réseau a été incrémenté de 54248 pendant le test." avec les tampons a 512. Si je règle a 4096 le tampon, je n'ai plus ce message mais le meme débit max
Même en mono-connexion Cubic WAN ?
Cela voudrait donc dire que la perte de paquets que cela génère n'est pas suffisante pour empêcher un débit de 6 Gbps au moins, et que le test de Fuzy serait bien significatif...
Pour résumer Fuzy arrivait à monter largement au dessus de 2,5 Gbps en mono-connexion WAN chez Free avec la box Delta (cf ce test (https://lafibre.info/1gb-free/checkftthfree-test-de-debit-tcp-mono-connexion-freeboxcubicbbr/msg1038233/) par exemple).
Par contre maintenant avec la Ultra ça sature à 2,5 Gbps max en mono-connexion WAN, en testant avec 2 machines différentes (pas de souci par contre pour atteindre 10 Gbps en mono-connexion sur le test local).
Et d'un autre côté on a des gens avec la Ultra qui n'ont aucun souci pour dépasser 2,5 Gbps en mono-connexion WAN, par exemple Darkmoon ici (https://lafibre.info/1gb-free/checkftthfree-test-de-debit-tcp-mono-connexion-freeboxcubicbbr/msg1096122/#msg1096122)
Très étrange quand même...
Fuzy, quand tu fais tes tests est-ce que tu te connectes en direct à la Ultra ou bien tu passes par un switch ?
-
Fuzy, quand tu fais tes tests est-ce que tu te connectes en direct à la Ultra ou bien tu passes par un switch ?
J'ai testé ça :
- Ultra/monomode/switch/DAC/PC
- Ultra/DAC/switch/monomode/PC
- Ultra/monomode/PC
Edit—-
-
Ok donc tu as déjà testé pas mal de choses de ce côté là aussi...
Est-ce que tu penses que tu aurais moyen de lancer nspeed en mode serveur et rendre le port d'écoute accessible depuis l'extérieur le temps de faire quelques tests ? Si tu arrives à faire ça je pourrai lancer un upload depuis une connexion 8 Gbps en surveillant les métriques TCP de la connexion pour (peut-être) avoir plus d'info.
En tout cas les symptômes me font drôlement penser au fameux bug qu'il y avait eu chez Free avec l'ONU v2 (https://lafibre.info/1gb-free/freebox-v6-onu-recent-gt-30-mos-max-par-session-tcp/), juste avec une limite multipliée par 10 (~300 Mo/s max par connexion dans ton cas au lieu de ~30 Mo/s max par connexion avec l'ONU v2 à sa sortie). Le fait que la limite soit aussi stable et indépendante de l'algo de congestion pose question...
-
Je vais faire le test sous Linux histoire d’écarter Windows.
Est-ce que tu penses que tu aurais moyen de lancer nspeed en mode serveur et rendre le port d'écoute accessible depuis l'extérieur le temps de faire quelques tests ? Si tu arrives à faire ça je pourrai lancer un upload depuis une connexion 8 Gbps en surveillant les métriques TCP de la connexion pour (peut-être) avoir plus d'info.
Un peu trop néophyte pour te faire ça… mais je peux essayer !
-
Si ca fonctionne tel quel sur Win11 a jour. Je pense qu'ils sont revenu en arrière a un moment, je ne saurais dire quand.
[checkFtthFree v0.17] Windows 11 Build 22631 (64-bit)
-------------------------- 2024-11-20 16:40:34 +0100 --------------------------
Paramétrage réseau actuel du système:
AutoTuningLevelLocal: Normal
CongestionProvider: BBR2
EcnCapability: Disabled
LinkSpeed: 10 Gbps
NetworkCategory: Private
PcieLinkSpeed: 5.0 GT/s
PcieLinkWidth: 4
PhysicalMediaType: 802.3
ScalingHeuristics: Disabled
Timestamps: Allowed
=> Latence TCP max pour une réception à 1 Gbps: 141 ms
Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [BBR]
--> Latence: 3.51 ms [gigue: 1.05 ms]
--> Débit: 757.74 Mo/s (6.06 Gbps) [fluctuation: 1.07%]
Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [CUBIC]
--> Latence: 2.99 ms [gigue: 0.16 ms]
--> Débit: 728.55 Mo/s (5.83 Gbps) [fluctuation: 0.50%]
Ca fonctionne bien BBR2 sur windows 11 maintenant ?
Je perdais en upload quand je l'utilisais,
-
Ca fonctionne bien BBR2 sur windows 11 maintenant ?
Je perdais en upload quand je l'utilisais,
je n'ai pas vu de différence avec Orange en tout cas:
bbr2:
.\nspeed.exe put http://appliwave.testdebit.info/ 10G
running jobs of '#0' (0)...
batch #0:
Id| Read speed| Write speed| Time| Bytes read| Bytes written|command
#0| 0 bps| 7.9 Gbps| 8.00| 0 B| 7.9 GB|put http://appliwave.testdebit.info/ 10.7 GB (IPv6 - 4.584 ms - - )
cubic:
.\nspeed.exe put http://appliwave.testdebit.info/ 10G
running jobs of '#0' (0)...
batch #0:
Id| Read speed| Write speed| Time| Bytes read| Bytes written|command
#0| 0 bps| 7.9 Gbps| 8.00| 0 B| 7.9 GB|put http://appliwave.testdebit.info/ 10.7 GB (IPv6 - 5.9 ms - - )
avec checkFtthFree je ne depasse pas 5 Gbps en upload, bbr2 ou cubic, mais c'est a cause du serveur scaleway.testdebit.info (5Gbps avec nspeed aussi).
-
Je confirme ne pas avoir de souci, en tout cas pas ceux de Fuzy.
Les serveurs BBR semblent plus chargés que les CUBIC, j'ai systématiquement un meilleur débit en Cubic depuis quelques temps.
[checkFtthFree v0.23] Windows 11 Build 22631 (64-bit)
-------------------------- 2024-11-26 17:44:35 +0100 --------------------------
Configuration réseau du système:
Adapter.Driver: ASUS XG-C100C 10G PCI-E Network Adapter
Adapter.DriverVersion: 3.1.10.0 (Marvell, 2024-04-23)
Adapter.EEE: Disabled
Adapter.FlowControl: Rx & Tx Enabled
Adapter.IPChecksumOffloadIPv4: Rx & Tx Enabled
Adapter.InterruptModeration: Enabled
Adapter.JumboPacket: Disabled
Adapter.LinkSpeed: 10 Gbps
Adapter.LsoV1IPv4: Enabled
Adapter.LsoV2: Enabled
Adapter.PcieLinkSpeed: 8.0 GT/s
Adapter.PcieLinkWidth: 2
Adapter.PhysicalMediaType: 802.3
Adapter.ReceiveBuffers: 2048
Adapter.Rsc: Enabled
Adapter.SpeedDuplex: Auto Negotiation
Adapter.TCPUDPChecksumOffload: Rx & Tx Enabled
Adapter.TransmitBuffers: 2048
NetProfile.NetworkCategory: Private
Tcp.AutoTuningLevelLocal: Normal
Tcp.CongestionProvider: BBR2
Tcp.EcnCapability: Disabled
Tcp.ScalingHeuristics: Disabled
Tcp.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: 9.93 ms [gigue: 0.73 ms]
--> Débit: 823.99 Mo/s (6.59 Gbps) [fluctuation: 1.59%]
Test TCP Internet (IPv6): téléchargement depuis l'AS 12876 (Scaleway) [CUBIC]
--> Latence: 9.39 ms [gigue: 1.02 ms]
--> Débit: 899.67 Mo/s (7.20 Gbps) [fluctuation: 2.82%]
-------------------------- 2024-11-26 17:45:03 +0100 --------------------------
@Fuzy, essaye de mettre les derniers pilotes 3.1.10 (https://www.marvell.com/content/dam/marvell/en/drivers/Marvell_AQtion_Win_v3.1.10.0%20.zip).
-
J'ai fait le test sous linux mais impossible d'executer le test en entier :
[checkFtthFree v0.23] Linux 6.8.0-31-generic (x86_64)
-------------------------- 2024-11-26 18:15:53 +0000 --------------------------
Configuration réseau du système:
link_dev: enp4s0
link_mtu: 1500
link_qdisc: mq
link_qlen: 1000
net.core.default_qdisc: pfifo_fast
net.core.netdev_budget: 300
net.core.netdev_budget_usecs: 2000
net.core.netdev_max_backlog: 1000
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_dsack: 1
net.ipv4.tcp_ecn: 2
net.ipv4.tcp_mem: 573168 764226 1146336
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.63 ms [gigue: 0.26 ms]
--> Débit: 1.18 Go/s (9.42 Gbps) [fluctuation: 0.00%]
[!] Le compteur "rx_dropped" de l'interface réseau a été incrémenté de 4 pendant le test.
Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [BBR]
--> Latence: 9.14 ms [gigue: 0.50 ms]
--> Débit: 268.73 Mo/s (2.15 Gbps) [fluctuation: 1.51%]
[!] Le compteur "rx_dropped" de l'interface réseau a été incrémenté de 4 pendant le test.
Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [CUBIC]
--> Latence: 8.64 ms [gigue: 0.74 ms]
Derrière CUBIC ça tombe...
@darkmoon, je vais test ce driver derrière l'autre PC, mais j'y crois pas
-
Comment ça "ça tombe" ? :D
Ca retourne directement à la console sans afficher quoi que ce soit d'autre ?
D'après le test BBR on dirait bien qu'il y a le même souci de saturation entre 2 Gbps et 2,5 Gbps sous Linux...
-
Comment ça "ça tombe" ? :D
La console se ferme d'elle même, impossible de finir le test...
D'après le test BBR on dirait bien qu'il y a le même souci de saturation entre 2 Gbps et 2,5 Gbps sous Linux...
Oui, on peut écarter W11 !
Avec le dernier Driver @darkmoon :
[checkFtthFree v0.23] Windows 11 Build 22631 (64-bit)
-------------------------- 2024-11-26 19:48:47 +0100 --------------------------
Configuration réseau du système:
Adapter.Driver: ASUS XG-C100C 10G PCI-E Network Adapter
Adapter.DriverVersion: 3.1.10.0 (Marvell, 2024-04-23)
Adapter.EEE: Disabled
Adapter.FlowControl: Rx & Tx Enabled
Adapter.IPChecksumOffloadIPv4: Rx & Tx Enabled
Adapter.InterruptModeration: Enabled
Adapter.JumboPacket: Disabled
Adapter.LinkSpeed: 10 Gbps
Adapter.LsoV1IPv4: Enabled
Adapter.LsoV2: Enabled
Adapter.PcieLinkSpeed: 5.0 GT/s
Adapter.PcieLinkWidth: 2
Adapter.PhysicalMediaType: 802.3
Adapter.ReceiveBuffers: 512
Adapter.Rsc: Enabled
Adapter.SpeedDuplex: Auto Negotiation
Adapter.TCPUDPChecksumOffload: Rx & Tx Enabled
Adapter.TransmitBuffers: 2048
NetProfile.NetworkCategory: Private
Tcp.AutoTuningLevelLocal: Normal
Tcp.CongestionProvider: CUBIC
Tcp.EcnCapability: Disabled
Tcp.ScalingHeuristics: Disabled
Tcp.Timestamps: Allowed
[!] La carte réseau utilise actuellement une interface PCI Express avec un taux de transfert ne permettant pas d'atteindre le débit maximum du lien réseau
=> Latence TCP max pour une réception à 1 Gbps: 141 ms
Test TCP local (IPv4): téléchargement depuis la Freebox
--> Latence: 1.19 ms [gigue: 0.26 ms]
--> Débit: 744.39 Mo/s (5.96 Gbps) [fluctuation: 4.07%]
Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [BBR]
--> Latence: 9.79 ms [gigue: 1.06 ms]
--> Débit: 291.40 Mo/s (2.33 Gbps) [fluctuation: 5.60%]
Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [CUBIC]
--> Latence: 8.92 ms [gigue: 0.53 ms]
--> Débit: 292.48 Mo/s (2.34 Gbps) [fluctuation: 8.33%]
-------------------------- 2024-11-26 19:49:31 +0100 --------------------------
Merci @ouno, ton exe est vraiment utile !
-
Hmm,
La box est peut-être défectueuse, c'est quand même étonnant. Ca ne peut pas venir de l'adaptateur SFP+ car tu as le maximum en local. D'ailleurs, tu as lequel ? Celui fourni par Free ?
Bon après, tu es bridé par ton port PCIe, mais tu devrais avoir les 5Gbits au moins.
T'es encore en Cubic, essaye de passer en BBR (via powershell) :
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
-
Y a un moment ou il faut se rendre à l'évidence ! La limitation est en Amont...
[checkFtthFree v0.22] Windows 11 Build 26100 (64-bit)
-------------------------- 2024-11-26 19:20:47 +0100 --------------------------
Configuration réseau du système:
Adapter.Driver: Intel(R) 82599 10 Gigabit Network Connection
Adapter.DriverVersion: 4.1.254.0 (Intel, 2024-02-08)
Adapter.FlowControl: Rx et Tx activées
Adapter.IPChecksumOffloadIPv4: Rx et Tx activées
Adapter.InterruptModeration: Activé(e)
Adapter.JumboPacket: Désactivé(e)
Adapter.LinkSpeed: 10 Gbps
Adapter.LsoV2: Activé(e)
Adapter.PcieLinkSpeed: 5.0 GT/s
Adapter.PcieLinkWidth: 4
Adapter.PhysicalMediaType: 802.3
Adapter.ReceiveBuffers: 512
Adapter.SpeedDuplex: Négociation automatique
Adapter.TCPChecksumOffload: Rx et Tx activées
Adapter.TransmitBuffers: 512
NetProfile.NetworkCategory: Private
Tcp.AutoTuningLevelLocal: Normal
Tcp.CongestionProvider: BBR2
Tcp.EcnCapability: Disabled
Tcp.ScalingHeuristics: Disabled
Tcp.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.03 ms [gigue: 0.31 ms]
--> Débit: 1.18 Go/s (9.41 Gbps) [fluctuation: 0.72%]
[!] Le compteur "ReceivedDiscardedPackets" de l'interface réseau a été incrémenté de 1525 pendant le test.
Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [BBR]
--> Latence: 9.41 ms [gigue: 1.04 ms]
--> Débit: 279.28 Mo/s (2.23 Gbps) [fluctuation: 4.03%]
[!] Le compteur "ReceivedDiscardedPackets" de l'interface réseau a été incrémenté de 41057 pendant le test.
Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [CUBIC]
--> Latence: 8.97 ms [gigue: 1.57 ms]
--> Débit: 279.84 Mo/s (2.24 Gbps) [fluctuation: 4.63%]
[!] Le compteur "ReceivedDiscardedPackets" de l'interface réseau a été incrémenté de 43732 pendant le test.
-------------------------- 2024-11-26 19:21:30 +0100 --------------------------
-
Si c'était si flagrant à Rennes, ça aurait râlé un peu plus que ça (je ne dis pas que vous êtes connus pour ça, mais un peu ;))
Il faudrait demander un échange, mais comment le justifier…
C'est marrant, je n'ai pas le même, le mien est un Hisense.
-
Ahah ! Je sais pas si les Rennais sont connus pour ça, c’est sans doute du coup un cas isolé me concernant.
Dans le principe, je voulais être sûr que cela ne venait pas de mon installation, dans ce sens je n’ai plus de doute.
En effet, ça va être compliqué de l’expliquer au service client et je ne compte pas prendre le risque, le dernier ticket m’a valu un écrasement de ligne qui a duré presque un mois.
Concernant le SFP, vous pensez qu’il est possible de le changer moi même ?
-
La console se ferme d'elle même, impossible de finir le test...
Ah mais ça c'est normal, je suppose que tu as lancé le script directement depuis l'interface graphique en double-cliquant dessus ? Dans ce cas la fenêtre se referme automatiquement une fois que le programme se termine.
Sous Windows j'ai ajouté une pause à la fin du programme en demandant d'appuyer sur Entrée pour quitter, car les gens sont habitués à lancer les programmes comme ça directement depuis l'interface graphique. Mais sous Linux ce type de programme se lance plutôt depuis un terminal, et du coup c'est plus embêtant qu'autre chose d'avoir à appuyer sur Entrée à chaque fois à la fin du programme, donc je n'ai pas mis cette pause automatique à la fin du programme.
Merci @ouno, ton exe est vraiment utile !
Tant mieux si ça sert ! Même si pour l'instant malheureusement ça n'a pas permis de résoudre ton problème...
Si c'était si flagrant à Rennes, ça aurait râlé un peu plus que ça (je ne dis pas que vous êtes connus pour ça, mais un peu ;))
Honnêtement je pense que pour la plupart des gens ça passe relativement inaperçu une limite à 300 Mo/s par connexion TCP. Surtout que la plupart des outils de test de débit sont en multi-connexion...
-
Ok merci !
Oui ça a du sens, si je n’avais pas eu la delta avant, je n’aurais pas vraiment remarqué cette limitation.
Je ne sais pas si cela est intentionnel, il faudrait plus de retour que seulement le mien…
Par contre, du coup ça pique d’avoir un débit de pop sur une offre ultra !
Malheureusement, y a pas grand chose à faire dans mon cas, si vous avez une idée ?
-
c'est clairement un souci apres la freebox, la collecte est saturée ne permettant pas a un flux mono connexion de dépasser 2G ?
bbr2/cubic coté client Windows n'influe que sur l'upload pas le download.
du coup en bbr2, t'as combien en upload mono:
./checkFtthFree.exe -FIu(ou avec nspeed cf précedemment).
-
du coup en bbr2, t'as combien en upload mono:
[checkFtthFree v0.23] Windows 11 Build 26100 (64-bit)
-------------------------- 2024-11-27 17:18:08 +0100 --------------------------
Configuration réseau du système:
Adapter.Driver: Intel(R) 82599 10 Gigabit Network Connection
Adapter.DriverVersion: 4.1.254.0 (Intel, 2024-02-08)
Adapter.FlowControl: Rx et Tx activées
Adapter.IPChecksumOffloadIPv4: Rx et Tx activées
Adapter.InterruptModeration: Activé(e)
Adapter.JumboPacket: Désactivé(e)
Adapter.LinkSpeed: 10 Gbps
Adapter.LsoV2: Activé(e)
Adapter.PcieLinkSpeed: 5.0 GT/s
Adapter.PcieLinkWidth: 4
Adapter.PhysicalMediaType: 802.3
Adapter.ReceiveBuffers: 512
Adapter.SpeedDuplex: Négociation automatique
Adapter.TCPChecksumOffload: Rx et Tx activées
Adapter.TransmitBuffers: 512
NetProfile.NetworkCategory: Private
Tcp.AutoTuningLevelLocal: Normal
Tcp.CongestionProvider: BBR2
Tcp.EcnCapability: Disabled
Tcp.ScalingHeuristics: Disabled
Tcp.Timestamps: Allowed
=> Latence TCP max pour une réception à 1 Gbps: 141 ms
Test TCP Internet (IPv4): envoi vers l'AS 12876 (Scaleway) [BBR2]
--> Latence: 9.28 ms [gigue: 0.23 ms]
--> Débit: 325.97 Mo/s (2.61 Gbps) [fluctuation: 11.26%]
-------------------------- 2024-11-27 17:18:25 +0100 --------------------------
-
au moins c'est cohérent ;D bien que t'avais 3.2 Gbps avec nspeed non:
batch upload mono:
Id| Read speed| Write speed| Time| Bytes read| Bytes written|command
#1| 0 bps| 3.2 Gbps| 8.00| 0 B| 3.2 GB|post http://appliwave.testdebit.info/ul/ 10.7 GB (IPv6 - 8.468 ms - - )
-
batch upload mono:
Id| Read speed| Write speed| Time| Bytes read| Bytes written|command
#1| 0 bps| 3.7 Gbps| 8.00| 0 B| 3.7 GB|post http://appliwave.testdebit.info/ul/ 10.7 GB (IPv6 - 8.958 ms - - )
Oui !
-
On fait quoi maintenant ;) :o
-
pas grand chose le probleme est sur la collecte au dela de la freebox. Faudrait tester chez un voisin proche pour confirmer.
-
::) je me vois mal faire du porte à porte avec ma tour sous le bras dans le quartier !
Même en changeant de FAI, je risque d'avoir le même problème ?
-
la collecte est saturée ne permettant pas a un flux mono connexion de dépasser 2G ?
Je pense pas que ce soit ça vu que la limite est hyper stable et infranchissable, quelle que soit l'heure de la journée. Et le débit en CUBIC est quasi identique à celui en BBR.
Ca ressemble plus au style de problème qui avait touché les ONU v2 à l'époque et qui avait été corrigé par Free par une mise à jour.
Donc peut-être l'ONU interne de la box / SFP 10G-EPON, ou un composant sur le réseau de collecte...
-
au moins c'est cohérent ;D bien que t'avais 3.2 Gbps avec nspeed non:
Et même encore plus ici:
batch upload mono:
Id| Read speed| Write speed| Time| Bytes read| Bytes written|command
#1| 0 bps| 4.7 Gbps| 8.00| 0 B| 4.7 GB|post http://appliwave.testdebit.info/ul/ 10.7 GB (IPv6 - 8.495 ms - - )
(le serveur appliwave est plus performant pour les tests d'upload)
-
Je pense pas que ce soit ça vu que la limite est hyper stable et infranchissable, quelle que soit l'heure de la journée. Et le débit en CUBIC est quasi identique à celui en BBR.
Ca ressemble plus au style de problème qui avait touché les ONU v2 à l'époque et qui avait été corrigé par Free par une mise à jour.
Donc peut-être l'ONU interne de la box / SFP 10G-EPON, ou un composant sur le réseau de collecte...
j'avoue je suis perplexe ;D.
"limite est stable et infranchissable" pour une latence donnée ou pas ?
tu peux tester avec un serveur dans l'Est ?
.\nspeed.exe get http://rbx.proof.ovh.net/files/10Gb.dat
-
Nouvelle version v0.24, qui ne contient que des ajouts pour les systèmes Linux / *BSD / macOS:
- [Linux] Prise en charge de la vérification du taux de transfert de l'interface PCI Express par rapport à la vitesse du lien réseau
- [*BSD/macOS] Prise en charge du contrôle des compteurs d'erreurs sur l'interface réseau pendant les tests
- [Linux/*BSD/macOS] Beaucoup de nouveaux paramètres et infos réseau affichés (liste complète sur la page de release (https://github.com/Yaribz/checkFtthFree/releases/tag/v0.24))
-
Done !
running jobs of '#0' (0)...
batch #0:
Id| Read speed| Write speed| Time| Bytes read| Bytes written|command
#0| 865.8 Mbps| 0 bps| 7.95| 860.1 MB| 0 B|get https://rbx.proof.ovh.net/files/10Gb.dat (IPv6 - 13.48 ms - HTTP/1.1 - TLS 1.2)
-
hum ca ressemble quand meme a une histoire de taille de buffers quelque part... (a moins que le peering entre Free et OVH soit hyper saturé...).
-
J'en ai fait 2 de suite ce soir !
running jobs of '#0' (0)...
batch #0:
Id| Read speed| Write speed| Time| Bytes read| Bytes written|command
#0| 1.1 Gbps| 0 bps| 7.95| 1.1 GB| 0 B|get https://rbx.proof.ovh.net/files/10Gb.dat (IPv6 - 1.712 ms - HTTP/1.1 - TLS 1.2)
running jobs of '#0' (0)...
batch #0:
Id| Read speed| Write speed| Time| Bytes read| Bytes written|command
#0| 844.3 Mbps| 0 bps| 7.97| 840.8 MB| 0 B|get https://rbx.proof.ovh.net/files/10Gb.dat (IPv6 - 11.237 ms - HTTP/1.1 - TLS 1.2)
-
Pour information, j'ai essayé de lancer 2 téléchargements en même temps sur le 2 machines derrière l'Ultra (serveurs pouvant cogner 400 Mo/s*2).... limité définitevement à "300 Mo/s" max entre les 2 machines...
C'est encore moins bien que l'offre pop avec ses 5G partagés.
::)
-
Pour information, j'ai essayé de lancer 2 téléchargements en même temps sur le 2 machines derrière l'Ultra (serveurs pouvant cogner 400 Mo/s*2).... limité définitevement à "300 Mo/s" max entre les 2 machines...
C'est encore moins bien que l'offre pop avec ses 5G partagés.
::)
Il me semblait qu'en multi-connexions sur 1 seule machine tu arrivais bien au max de la ligne. Et là avec 2 machines différentes qui téléchargent depuis le net en même temps (donc avec au moins 2 connexions en simultané) tu n'arrives à avoir que 300Mo/s au total ?
-
Oui c’est ça !
-
Nouvelle version v0.25: corrige la non reconnaissance des vitesses de lien réseau ayant une virgule
-
Je viens de faire, outil sympa :
Configuration réseau du système:
dev.link_speed: 8.0 GT/s PCIe
dev.link_width: 4
intf.dev: enp4s0
intf.mtu: 1500
intf.qdisc: mq
intf.qlen: 1000
link.duplex: full
link.speed: 10000
net.core.default_qdisc: fq_codel
net.core.netdev_budget: 300
net.core.netdev_budget_usecs: 2000
net.core.netdev_max_backlog: 1000
net.core.rmem_max: 7340032
net.core.wmem_max: 7340032
net.ipv4.tcp_adv_win_scale: 1
net.ipv4.tcp_congestion_control: cubic
net.ipv4.tcp_dsack: 1
net.ipv4.tcp_ecn: 2
net.ipv4.tcp_mem: 381795 509060 763590
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.00 ms [gigue: 0.22 ms]
--> Débit: 1.18 Go/s (9.40 Gbps) [fluctuation: 0.13%]
Test TCP Internet (IPv6): téléchargement depuis l'AS 12876 (Scaleway) [BBR]
--> Latence: 9.74 ms [gigue: 0.42 ms]
--> Débit: 401.80 Mo/s (3.21 Gbps) [fluctuation: 0.83%]
[!] Le compteur "rx_softnet_squeezed" du noyau a été incrémenté de 18 pendant le test.
Test TCP Internet (IPv6): téléchargement depuis l'AS 12876 (Scaleway) [CUBIC]
--> Latence: 9.02 ms [gigue: 0.16 ms]
--> Débit: 421.71 Mo/s (3.37 Gbps) [fluctuation: 1.55%]
[!] Le compteur "rx_softnet_squeezed" du noyau a été incrémenté de 91 pendant le test.
-------------------------- 2024-12-28 22:27:00 +0100 --------------------------
J'ai pas vu de possibilité de test l'upload, ce qui serait bien (c'est sur l'upload que j'ai un problème en ce moment sur l'Ultra :P )
-
Je viens de faire, outil sympa :
Merci !
[!] Le compteur "rx_softnet_squeezed" du noyau a été incrémenté de 18 pendant le test.
[!] Le compteur "rx_softnet_squeezed" du noyau a été incrémenté de 91 pendant le test.
Apparemment ton système n'a pas pu traiter toutes les interruptions logicielles réseau à la volée lors des transferts. Quel processeur as-tu et est-ce que le système était chargé par ailleurs pendant le test ?
Il est possible que tu puisses gagner un peu en performance en allouant plus de temps pour le traitement des interruptions logicielles par cycle d'interrogation NAPI (utiliser le paramètre --suggestions ou -s lors du lancement de checkFtthFree pour avoir les suggestions automatiques qui expliquent comment faire).
J'ai pas vu de possibilité de test l'upload, ce qui serait bien (c'est sur l'upload que j'ai un problème en ce moment sur l'Ultra :P )
La fonctionnalité de test d'upload est bien présente dans checkFtthFree, il suffit d'ajouter le paramètre de ligne de commande --upload ou -u (voir premier message de ce sujet pour toutes les options disponibles, ou utiliser le paramètre --help ou -h).
-
Merci !
Apparemment ton système n'a pas pu traiter toutes les interruptions logicielles réseau à la volée lors des transferts. Quel processeur as-tu et est-ce que le système était chargé par ailleurs pendant le test ?
Il est possible que tu puisses gagner un peu en performance en allouant plus de temps pour le traitement des interruptions logicielles par cycle d'interrogation NAPI (utiliser le paramètre --suggestions ou -s lors du lancement de checkFtthFree pour avoir les suggestions automatiques qui expliquent comment faire).
La fonctionnalité de test d'upload est bien présente dans checkFtthFree, il suffit d'ajouter le paramètre de ligne de commande --upload ou -u (voir premier message de ce sujet pour toutes les options disponibles, ou utiliser le paramètre --help ou -h).
Passes par PowerShell et essayes ça si le .exe est sur le bureau !
.\desktop/CheckFtthFree.exe -u
-
Passes par PowerShell et essayes ça si le .exe est sur le bureau !
.\desktop/CheckFtthFree.exe -u
Il est sous Linux ;)
-
Je reviens dans ce fil de discussion suite à un déménagement à Rennes et un passage au SFP+ :
[checkFtthFree v0.25] Windows 11 Build 26100 (64-bit)
-------------------------- 2025-01-05 01:51:36 +0100 --------------------------
Configuration réseau du système:
Adapter.Driver: Intel(R) Ethernet Server Adapter X520-1
Adapter.DriverVersion: 4.1.254.0 (Intel, 2024-02-08)
Adapter.FlowControl: Rx & Tx Enabled
Adapter.IPChecksumOffloadIPv4: Rx & Tx Enabled
Adapter.InterruptModeration: Enabled
Adapter.JumboPacket: Disabled
Adapter.LinkSpeed: 10 Gbps
Adapter.LsoV2: Enabled
Adapter.PcieLinkSpeed: 5.0 GT/s
Adapter.PcieLinkWidth: 4
Adapter.PhysicalMediaType: 802.3
Adapter.ReceiveBuffers: 512
Adapter.SpeedDuplex: Auto Negotiation
Adapter.TCPChecksumOffload: Rx & Tx Enabled
Adapter.TransmitBuffers: 512
NetProfile.NetworkCategory: Private
Tcp.AutoTuningLevelLocal: Normal
Tcp.CongestionProvider: CUBIC
Tcp.EcnCapability: Disabled
Tcp.ScalingHeuristics: Disabled
Tcp.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.39 ms [gigue: 0.02 ms]
--> Débit: 1.17 Go/s (9.35 Gbps) [fluctuation: 1.06%]
[!] Le compteur "ReceivedDiscardedPackets" de l'interface réseau a été incrémenté de 309 pendant le test.
Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [BBR]
--> Latence: 8.15 ms [gigue: 0.23 ms]
--> Débit: 237.85 Mo/s (1.90 Gbps) [fluctuation: 23.18%]
[!] Le compteur "ReceivedDiscardedPackets" de l'interface réseau a été incrémenté de 4695 pendant le test.
Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [CUBIC]
--> Latence: 7.52 ms [gigue: 0.19 ms]
--> Débit: 274.81 Mo/s (2.20 Gbps) [fluctuation: 17.04%]
-------------------------- 2025-01-05 01:52:21 +0100 --------------------------
et ipv6
Test TCP local (IPv4): téléchargement depuis la Freebox
--> Latence: 0.38 ms [gigue: 0.01 ms]
--> Débit: 1.14 Go/s (9.13 Gbps) [fluctuation: 2.37%]
[!] Le compteur "ReceivedDiscardedPackets" de l'interface réseau a été incrémenté de 786 pendant le test.
Test TCP Internet (IPv6): téléchargement depuis l'AS 12876 (Scaleway) [BBR]
--> Latence: 8.11 ms [gigue: 0.33 ms]
--> Débit: 624.92 Mo/s (5.00 Gbps) [fluctuation: 12.64%]
[!] Le compteur "ReceivedDiscardedPackets" de l'interface réseau a été incrémenté de 32163 pendant le test.
Test TCP Internet (IPv6): téléchargement depuis l'AS 12876 (Scaleway) [CUBIC]
--> Latence: 7.57 ms [gigue: 0.14 ms]
--> Débit: 768.02 Mo/s (6.14 Gbps) [fluctuation: 3.63%]
[!] Le compteur "ReceivedDiscardedPackets" de l'interface réseau a été incrémenté de 3006 pendant le test.
C'est sur une Delta (R1). C'est pas fou fou ! Mais je ne sais pas si je devrais tenir compte des avertissements concernant "ReceivedDiscardedPackets".
Même à cette heure-ci, nPerf refuse de dépasser 2 Gbps (que ça soit via Chrome/Firefox/l'appli Windows). Quant à Fast.com, ça monte à 8 Gbps pour redescendre très vite à 5-6.
-
C'est sur une Delta (R1). C'est pas fou fou ! Mais je ne sais pas si je devrais tenir compte des avertissements concernant "ReceivedDiscardedPackets".
C'est pas trop mal quand même pour du mono-connexion. Après ce n'est pas normal effectivement d'avoir le compteur ReceivedDiscardedPackets qui augmente autant pendant les tests.
Cela veut dire que l'interface réseau reçoit des paquets réseau valides qu'elle rejette quand même, en général faute de place dans la mémoire tampon pour les stocker: le système d'exploitation ne vient pas lire cette mémoire tampon assez vite.
Quel processeur as-tu ? Si le processeur est censé pouvoir gérer des transferts multi-gigagbit mono-connexion sans problème il faudrait d'abord regarder côté applications parasites installées qui viendraient pourrir les perfs réseau.
Sinon tu peux essayer d'augmenter la mémoire tampon de réception associée à l'interface (paramètre "Receive Buffers" ou "Mémoire tampon de réception" selon les pilotes), en la passant de 512 à 1024, voire 2048.
-
C'est un PC construit moi-même : carte-mère B550 Taichi, CPU AMD 5800X (pas 3D), 32 Go de DDR4 3200. Normalement ça ne devrait pas avoir de problèmes avec le 10 Gbps. Après, cette installation de Windows date un peu, elle a été mise à niveau vers 11 il y a un mois... j'ai pas mal de trucs installés. Rien qui, a ma connaissance, s'amuse à filtrer la pile réseau.
Avec tampons réglés sur 1024 :
Test TCP local (IPv4): téléchargement depuis la Freebox
--> Latence: 0.39 ms [gigue: 0.03 ms]
--> Débit: 1.07 Go/s (8.56 Gbps) [fluctuation: 0.34%]
[!] Le compteur "ReceivedDiscardedPackets" de l'interface réseau a été incrémenté de 294 pendant le test.
Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [BBR]
--> Latence: 8.18 ms [gigue: 0.33 ms]
--> Débit: 242.63 Mo/s (1.94 Gbps) [fluctuation: 19.82%]
Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [CUBIC]
--> Latence: 7.47 ms [gigue: 0.37 ms]
--> Débit: 252.71 Mo/s (2.02 Gbps) [fluctuation: 21.77%]
[!] Le compteur "ReceivedDiscardedPackets" de l'interface réseau a été incrémenté de 5161 pendant le test.
Test TCP local (IPv4): téléchargement depuis la Freebox
--> Latence: 0.38 ms [gigue: 0.04 ms]
--> Débit: 1.03 Go/s (8.21 Gbps) [fluctuation: 1.55%]
Test TCP Internet (IPv6): téléchargement depuis l'AS 12876 (Scaleway) [BBR]
--> Latence: 8.19 ms [gigue: 0.40 ms]
--> Débit: 557.75 Mo/s (4.46 Gbps) [fluctuation: 9.49%]
[!] Le compteur "ReceivedDiscardedPackets" de l'interface réseau a été incrémenté de 10487 pendant le test.
Test TCP Internet (IPv6): téléchargement depuis l'AS 12876 (Scaleway) [CUBIC]
--> Latence: 7.46 ms [gigue: 0.12 ms]
--> Débit: 685.87 Mo/s (5.49 Gbps) [fluctuation: 2.51%]
[!] Le compteur "ReceivedDiscardedPackets" de l'interface réseau a été incrémenté de 9905 pendant le test.
C'est légèrement mieux. Pas d'amélioration avec 2048.
Je constate que Fast.com écrit sur mon SSD système presque aussi vite que ce qu'il télécharge, donc la limite se situe peut-être bien là aussi... pour ce qui est de nPerf, le serveur anycast-FR 100 Gb/s Free refuse toujours de dépasser environ ~2 Gbps.
(https://i.imgur.com/7NdWDuR.png)
Étrange de voir 13% de packet loss... c'est pareil sur Chrome. la « latence chargée » est de 13 ms. Smartphone à côté de la box : 1,2 Gb/s, 0.5% de pertes.
Après, l'important pour moi, c'est que les 80 € de matériel que j'ai dépensés ne soient pas défectueux. Ça n'est pas le cas, il y a juste un léger ralentissement côté système. Après ça, que ça atteigne 2 Gbps ou 5, la différence devient beaucoup moins importante que celle entre le Wi-Fi de la Delta R1 et le Gbps garanti par un câble :)
DEUXIÈME EDIT :
Très peu d'amélioration en mode sans échec. D'ailleurs, checkFtthFree.exe n'y arrivait pas à faire un téléchargement local à plus de 1,5 Gb/s (!) et continuait à indiquer des "ReceivedDiscardedPackets".
Par contre, après redémarrage de la box, ce que je n'avais PAS fait après premier branchement du SFP...
(https://i.imgur.com/LMHxtzy.png)
Test TCP local (IPv4): téléchargement depuis la Freebox
--> Latence: 0.40 ms [gigue: 0.13 ms]
--> Débit: 1.08 Go/s (8.60 Gbps) [fluctuation: 2.31%]
[!] Le compteur "ReceivedDiscardedPackets" de l'interface réseau a été incrémenté de 71 pendant le test.
Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [BBR]
--> Latence: 8.10 ms [gigue: 0.12 ms]
--> Débit: 580.16 Mo/s (4.64 Gbps) [fluctuation: 6.25%]
[!] Le compteur "ReceivedDiscardedPackets" de l'interface réseau a été incrémenté de 16449 pendant le test.
Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [CUBIC]
--> Latence: 7.48 ms [gigue: 0.12 ms]
--> Débit: 642.61 Mo/s (5.14 Gbps) [fluctuation: 4.46%]
[!] Le compteur "ReceivedDiscardedPackets" de l'interface réseau a été incrémenté de 1876 pendant le test.
Test TCP local (IPv4): téléchargement depuis la Freebox
--> Latence: 0.38 ms [gigue: 0.03 ms]
--> Débit: 1.15 Go/s (9.19 Gbps) [fluctuation: 3.96%]
[!] Le compteur "ReceivedDiscardedPackets" de l'interface réseau a été incrémenté de 87 pendant le test.
Test TCP Internet (IPv6): téléchargement depuis l'AS 12876 (Scaleway) [BBR]
--> Latence: 8.11 ms [gigue: 0.16 ms]
--> Débit: 603.82 Mo/s (4.83 Gbps) [fluctuation: 7.58%]
[!] Le compteur "ReceivedDiscardedPackets" de l'interface réseau a été incrémenté de 5442 pendant le test.
Test TCP Internet (IPv6): téléchargement depuis l'AS 12876 (Scaleway) [CUBIC]
--> Latence: 7.48 ms [gigue: 0.11 ms]
--> Débit: 667.02 Mo/s (5.34 Gbps) [fluctuation: 5.24%]
[!] Le compteur "ReceivedDiscardedPackets" de l'interface réseau a été incrémenté de 1329 pendant le test.
Mystère résolu...?
-
C'est un PC construit moi-même : carte-mère B550 Taichi, CPU AMD 5800X (pas 3D), 32 Go de DDR4 3200. Normalement ça ne devrait pas avoir de problèmes avec le 10 Gbps.
Oui effectivement.
Avec tampons réglés sur 1024 :
C'est légèrement mieux.
J'ai même l'impression que ce n'est pas mieux du tout ? C'est bizarre, c'est comme si cela n'avait eu aucun effet.
Est-ce que tu peux mettre la sortie complète de checkFtthFree (avec les paramètres réseau affichés au début) pour comparer ?
après redémarrage de la box, ce que je n'avais PAS fait après premier branchement du SFP...
Mystère résolu...?
Oui visiblement il y avait un souci niveau box, mais c'est quand même bizarre que tu continues d'avoir des paquets rejetés par ton interface réseau ???
-
Est-ce que tu peux mettre la sortie complète de checkFtthFree (avec les paramètres réseau affichés au début) pour comparer ?
Oui visiblement il y avait un souci niveau box, mais c'est quand même bizarre que tu continues d'avoir des paquets rejetés par ton interface réseau ???
Hop :
[checkFtthFree v0.25] Windows 11 Build 26100 (64-bit)
-------------------------- 2025-01-05 16:27:54 +0100 --------------------------
Configuration réseau du système:
Adapter.Driver: Intel(R) Ethernet Server Adapter X520-1
Adapter.DriverVersion: 4.1.254.0 (Intel, 2024-02-08)
Adapter.FlowControl: Rx & Tx Enabled
Adapter.IPChecksumOffloadIPv4: Rx & Tx Enabled
Adapter.InterruptModeration: Enabled
Adapter.JumboPacket: Disabled
Adapter.LinkSpeed: 10 Gbps
Adapter.LsoV2: Enabled
Adapter.PcieLinkSpeed: 5.0 GT/s
Adapter.PcieLinkWidth: 4
Adapter.PhysicalMediaType: 802.3
Adapter.ReceiveBuffers: 2048
Adapter.SpeedDuplex: Auto Negotiation
Adapter.TCPChecksumOffload: Rx & Tx Enabled
Adapter.TransmitBuffers: 2048
NetProfile.NetworkCategory: Private
Tcp.AutoTuningLevelLocal: Normal
Tcp.CongestionProvider: CUBIC
Tcp.EcnCapability: Disabled
Tcp.ScalingHeuristics: Disabled
Tcp.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.39 ms [gigue: 0.02 ms]
--> Débit: 1.07 Go/s (8.53 Gbps) [fluctuation: 0.94%]
[!] Le compteur "ReceivedDiscardedPackets" de l'interface réseau a été incrémenté de 150 pendant le test.
Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [BBR]
--> Latence: 8.04 ms [gigue: 0.17 ms]
--> Débit: 628.15 Mo/s (5.03 Gbps) [fluctuation: 7.39%]
[!] Le compteur "ReceivedDiscardedPackets" de l'interface réseau a été incrémenté de 10242 pendant le test.
Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [CUBIC]
--> Latence: 7.48 ms [gigue: 0.17 ms]
--> Débit: 539.13 Mo/s (4.31 Gbps) [fluctuation: 7.75%]
[!] Le compteur "ReceivedDiscardedPackets" de l'interface réseau a été incrémenté de 1395 pendant le test.
-------------------------- 2025-01-05 16:28:36 +0100 --------------------------
Oui... après le fait que ça soit une quantité très faible ne m'interpelle pas ? Il y avait quelqu'un qui avait de « véritables » problèmes (impossible pour lui d'atteindre le Gbps), et il était à, genre, 4 millions de paquets rejetés... 10 000, à côté, ça semble normal ?
Voici le matériel acheté : https://www.amazon.fr/dp/B0BTSJLGN3 (carte réseau) & https://www.amazon.fr/dp/B0BLC9NLH1 (câble de 20 mètres)
-
Hop :
Oui... après le fait que ça soit une quantité très faible ne m'interpelle pas ? Il y avait quelqu'un qui avait de « véritables » problèmes (impossible pour lui d'atteindre le Gbps), et il était à, genre, 4 millions de paquets rejetés... 10 000, à côté, ça semble normal ?
Si tu parles de Pikabois qui avait des valeurs de plusieurs dizaines de milliards, je pense que c'était un bug lié au pilote ancien qu'il utilisait. Depuis qu'il l'a mis à jour le compteur reste à 0 (mais cela n'a pas arrangé son débit, son problème était en fait lié à l'utilisation de cFosSpeed).
Je ne dirais pas qu'un compteur de paquets rejetés qui augmente de 10 000 pendant un test de 10 secondes est "normal". C'est effectivement tout à fait acceptable dans ton cas car cela ne t'empêche pas de monter à plus de 5 Gbps en débit Internet mono-connexion, ce qui est déjà très bien (et au final ce qui compte c'est bien le débit obtenu). Mais pour moi une machine avec le CPU que tu as ne devrait perdre aucun paquet localement à 10 Gbps si elle n'est pas trop sollicitée par ailleurs.
Après je n'ai pas d'expérience avec les cartes Intel X520, il faudrait peut-être avoir le retour d'autres personnes qui ont la même carte...
Ci dessous un exemple de test réalisé sur une machine sous Windows de puissance comparable à la tienne avec une carte Mellanox ConnectX-4. Le compteur reste à 0 avec un débit de plus de 8 Gbps:
[checkFtthFree v0.25] Windows 10 Build 19045 (64-bit)
-------------------------- 2025-01-05 17:55:40 +0100 --------------------------
Configuration réseau du système:
Adapter.Driver: Mellanox ConnectX-4 Lx Ethernet Adapter
Adapter.DriverVersion: 24.10.26603.0 (Mellanox Technologies Ltd., 2024-10-10)
Adapter.FlowControl: Disabled
Adapter.IPChecksumOffloadIPv4: Rx & Tx Enabled
Adapter.InterruptModeration: Enabled
Adapter.JumboPacket: Disabled
Adapter.LinkSpeed: 10 Gbps
Adapter.LsoV2: Enabled
Adapter.PcieLinkSpeed: 8.0 GT/s
Adapter.PcieLinkWidth: 8
Adapter.PhysicalMediaType: 802.3
Adapter.ReceiveBuffers: 2048
Adapter.Rsc: Enabled
Adapter.TCPUDPChecksumOffload: Rx & Tx Enabled
Adapter.TransmitBuffers: 2048
NetProfile.NetworkCategory: Public
Tcp.AutoTuningLevelLocal: Normal
Tcp.CongestionProvider: CUBIC
Tcp.EcnCapability: Disabled
Tcp.ScalingHeuristics: Disabled
Tcp.Timestamps: Disabled
=> Latence TCP max pour une réception à 1 Gbps: 141 ms
Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [BBR]
--> Latence: 9.14 ms [gigue: 0.35 ms]
--> Débit: 973.13 Mo/s (7.79 Gbps) [fluctuation: 2.58%]
Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [CUBIC]
--> Latence: 8.64 ms [gigue: 0.67 ms]
--> Débit: 1.01 Go/s (8.11 Gbps) [fluctuation: 0.93%]
-------------------------- 2025-01-05 17:56:09 +0100 --------------------------
-
J'ai testé avec une clé USB Ubuntu et :
1) j'atteinds bien le maximum absolu en téléchargement local, alors que Windows n'y était pas tout à fait
2) nperf se rapproche très près des 8 Gbps au lieu de plafonner autour de 5 et quelques
3) Scaleway reste autour de 5 peu importe ipv4 ou ipv6, et ce malgré l'heure tardive
C'est donc bien un problème logiciel sur mon installation Windows, ce qui me rassure grandement. Être plafonné autour de 5 n'est pas un drame et me convient parfaitement. J'aurai l'occasion d'y remédier lors de ma prochaine mise à niveau matérielle !
Merci pour tes éclairages et ton superbe outil.
-
Être plafonné autour de 5 n'est pas un drame et me convient parfaitement. J'aurai l'occasion d'y remédier lors de ma prochaine mise à niveau matérielle !
Oui entièrement d'accord.
Merci pour tes éclairages et ton superbe outil.
Merci à toi !
-
Bon, il y a anguille sous roche avec la box...
Le débit max finit par redescendre à 2-2,5 Gbps maximum via nPerf, comme au tout début. De même, les 13% de pertes de paquets reviennent sur ces tests.
Si je lance des tests simultanés en Wi-Fi avec mon téléphone et ordinateur portable au même moment, ça pénalise le test nPerf via SFP, qui descend vers 1 Gbps; logiquement, ça ne devrait pas arriver. C'est la même chose sous Windows ou sous Linux.
Redémarrage de la box => Windows et Linux retrouvent un débit proche du 8 Gbps, sans pertes de paquets sur nPerf.
Il y a donc un rouage (sûrement logiciel) côté Delta qui se grippe au bout de quelques heures ou jours... Je vais faire un rapport sur leur bug tracker.
EDIT : c'est fait, et j'ai aussi eu l'occasion de produire cette image très parlante aujourd'hui...
(https://i.imgur.com/tTqxfZR.png)
-
Le mystère s'épaissit : le simple fait de débrancher puis rebrancher la jarretière fibre (celle qui vous relie à Internet) sans redémarrer la Freebox résout le problème...
(https://i.imgur.com/BnjPwUi.png)
-
C'est marrant ce premier saut derrière l'Ultra... ?
PS C:\Users\yo_pi> tracert 8.8.8.8
Détermination de l’itinéraire vers dns.google [8.8.8.8]
avec un maximum de 30 sauts :
1 <1 ms <1 ms <1 ms 192.168.1.254
2 7 ms 7 ms 7 ms strasbourg-9k-1-lo10.intf.routers.proxad.net [194.149.162.246]
3 7 ms 7 ms 7 ms rennes-9k-1-lo10.intf.routers.proxad.net [194.149.162.250]
4 9 ms 8 ms 8 ms prs-b17-link.ip.twelve99.net [213.248.91.224]
5 7 ms 8 ms 7 ms prs-bb2-link.ip.twelve99.net [62.115.136.224]
6 8 ms 8 ms 7 ms prs-b3-link.ip.twelve99.net [62.115.118.63]
7 9 ms 8 ms 8 ms google-ic-344096.ip.twelve99-cust.net [62.115.174.29]
8 8 ms 7 ms 7 ms 216.239.40.73
9 7 ms 8 ms 8 ms 142.251.253.37
10 8 ms 8 ms 7 ms dns.google [8.8.8.8]
Itinéraire déterminé.
PS C:\Users\yo_pi> tracert 1.1.1.1
Détermination de l’itinéraire vers one.one.one.one [1.1.1.1]
avec un maximum de 30 sauts :
1 <1 ms <1 ms <1 ms 192.168.1.254
2 7 ms 6 ms 7 ms amsterdam-9k-1-lo10.intf.routers.proxad.net [194.149.162.248]
3 7 ms 7 ms 7 ms rennes-9k-1-lo10.intf.routers.proxad.net [194.149.162.250]
4 8 ms 7 ms 9 ms prs-b17-link.ip.twelve99.net [213.248.91.224]
5 10 ms 7 ms 7 ms 62.115.136.36
6 8 ms 9 ms 29 ms cloudflare-ic-363840.ip.twelve99-cust.net [213.248.73.69]
7 8 ms 8 ms 12 ms 141.101.67.91
8 7 ms 7 ms 7 ms one.one.one.one [1.1.1.1]
Itinéraire déterminé.
PS C:\Users\yo_pi> tracert 8.8.4.4
Détermination de l’itinéraire vers dns.google [8.8.4.4]
avec un maximum de 30 sauts :
1 <1 ms <1 ms <1 ms 192.168.1.254
2 15 ms 7 ms 7 ms strasbourg-9k-1-lo10.intf.routers.proxad.net [194.149.162.246]
3 8 ms 8 ms 7 ms rennes-9k-1-lo10.intf.routers.proxad.net [194.149.162.250]
4 9 ms 9 ms 9 ms prs-b17-link.ip.twelve99.net [213.248.91.224]
5 8 ms 7 ms 8 ms prs-bb2-link.ip.twelve99.net [62.115.136.224]
6 8 ms 8 ms 8 ms prs-b3-link.ip.twelve99.net [62.115.118.63]
7 8 ms 14 ms 8 ms google-ic-344096.ip.twelve99-cust.net [62.115.174.29]
8 8 ms 8 ms 9 ms 216.239.40.75
9 9 ms 8 ms 9 ms 142.250.234.43
10 8 ms 8 ms 7 ms dns.google [8.8.4.4]
Itinéraire déterminé.
PS C:\Users\yo_pi> tracert 1.0.0.1
Détermination de l’itinéraire vers one.one.one.one [1.0.0.1]
avec un maximum de 30 sauts :
1 <1 ms <1 ms <1 ms 192.168.1.254
2 7 ms 7 ms 7 ms strasbourg-9k-1-lo10.intf.routers.proxad.net [194.149.162.246]
3 7 ms 7 ms 7 ms rennes-9k-1-lo10.intf.routers.proxad.net [194.149.162.250]
4 11 ms 10 ms 9 ms prs-b17-link.ip.twelve99.net [213.248.91.224]
5 8 ms 7 ms 7 ms 62.115.136.36
6 11 ms 8 ms 12 ms cloudflare-ic-363840.ip.twelve99-cust.net [213.248.73.69]
7 16 ms 44 ms 33 ms 141.101.67.95
8 7 ms 7 ms 8 ms one.one.one.one [1.0.0.1]
Itinéraire déterminé.
PS C:\Users\yo_pi> tracert 9.9.9.9
Détermination de l’itinéraire vers dns9.quad9.net [9.9.9.9]
avec un maximum de 30 sauts :
1 <1 ms <1 ms <1 ms 192.168.1.254
2 7 ms 7 ms 8 ms amsterdam-9k-1-lo10.intf.routers.proxad.net [194.149.162.248]
3 8 ms * 7 ms station1.multimania.isdnet.net [194.149.174.98]
4 9 ms 7 ms 7 ms pch1.par.franceix.net [37.49.236.92]
5 7 ms 7 ms 7 ms dns9.quad9.net [9.9.9.9]
Itinéraire déterminé.
PS C:\Users\yo_pi> tracert 80.67.169.12
Détermination de l’itinéraire vers ns0.fdn.org [80.67.169.12]
avec un maximum de 30 sauts :
1 <1 ms <1 ms <1 ms 192.168.1.254
2 10 ms 7 ms 7 ms amsterdam-9k-1-lo10.intf.routers.proxad.net [194.149.162.248]
3 * * * Délai d’attente de la demande dépassé.
4 8 ms 7 ms 7 ms gandi.par.franceix.net [37.49.236.154]
5 7 ms 8 ms 7 ms 173.246.102.33
6 8 ms 8 ms 8 ms vodka.gitoyen.net [80.67.168.7]
7 8 ms 8 ms 8 ms fdn-pa3-gw1.gitoyen.net [80.67.168.145]
8 8 ms 8 ms 7 ms ns0.fdn.org [80.67.169.12]
Itinéraire déterminé.
PS C:\Users\yo_pi> tracert 208.67.222.222
Détermination de l’itinéraire vers resolver1.opendns.com [208.67.222.222]
avec un maximum de 30 sauts :
1 <1 ms <1 ms <1 ms 192.168.1.254
2 7 ms 7 ms 7 ms amsterdam-9k-1-lo10.intf.routers.proxad.net [194.149.162.248]
3 * * * Délai d’attente de la demande dépassé.
4 8 ms 7 ms 8 ms ae2.mpr1.cdg11.fr.zip.zayo.com [64.125.14.37]
5 144 ms 144 ms 143 ms ae22.cr1.cdg12.fr.eth.zayo.com [64.125.24.246]
6 148 ms 150 ms 148 ms 64.125.35.198.IPYX-145641-003-ZYO.zip.zayo.com [64.125.35.198]
7 315 ms 314 ms 317 ms 203.208.154.69
8 312 ms 313 ms 313 ms 203.208.158.10
9 321 ms 320 ms 321 ms 203.208.171.190
10 332 ms 332 ms 332 ms 203.208.178.17
11 329 ms 329 ms 329 ms ix-be-5.ecore1.hk2-hongkong.as6453.net [180.87.169.8]
12 * 336 ms * if-ae-46-2.tcore1.hk2-hongkong.as6453.net [116.0.67.4]
13 336 ms 336 ms * if-ae-28-3.tcore2.tv2-tokyo.as6453.net [116.0.67.111]
14 * 335 ms 336 ms if-bundle-56-2.qcore2.tv2-tokyo.as6453.net [209.58.61.99]
15 337 ms 337 ms 336 ms if-ae-1-2.thar1.e14-osaka.as6453.net [180.87.181.46]
16 336 ms 336 ms 336 ms resolver1.opendns.com [208.67.222.222]
LoL OpenDNS.... !!!!
-
Le mystère s'épaissit : le simple fait de débrancher puis rebrancher la jarretière fibre (celle qui vous relie à Internet) sans redémarrer la Freebox résout le problème...
(https://i.imgur.com/BnjPwUi.png)
C'est comme si une flopée de peers bouffait la bande passante, et après le redémarrage de la box, ayant perdu leurs "copains", plus de bande passante bouffée, le test peut repartir plein pot, puis éventuellement se re-casser la figure ensuite?
-
Je te confirme qu'il n'y a aucune utilisation de la bande passante avant ou après... et oui, ça finit par se « re-brider » à 2 Gbps 13% PL éventuellement.
Ça ressemble très fort à un défaut logiciel côté box mais c'est difficile de l'affirmer avec certitude.
Voici le ticket que j'ai ouvert chez Free, mais sans réponse pertinente, malheureusement : https://dev.freebox.fr/bugs/task/39973
-
C'est marrant ce premier saut derrière l'Ultra... ?
Très certainement un routeur avec plusieurs interfaces, le reverse DNS est probablement pas très pertinent.
-
Je te confirme qu'il n'y a aucune utilisation de la bande passante avant ou après... et oui, ça finit par se « re-brider » à 2 Gbps 13% PL éventuellement.
Ça ressemble très fort à un défaut logiciel côté box mais c'est difficile de l'affirmer avec certitude.
Voici le ticket que j'ai ouvert chez Free, mais sans réponse pertinente, malheureusement : https://dev.freebox.fr/bugs/task/39973
La logique voudrait qu'un défaut logiciel côté box impacterait tous les utilisateurs, non? Des gens qui font des Speedtests sur Delta et Ultra, il y en a tout de même quelques paquets!
-
Très certainement un routeur avec plusieurs interfaces, le reverse DNS est probablement pas très pertinent.
Clair que les reverse IPV4 et leurs mises à jour (au moins chez Free), faut plus trop se focaliser dessus!
-
Bonjour,
Je mets ma modeste contribution pour le même problème de lenteur sur ma freebox server en SFP+ avec la même carte X520-1
Je n'ai pas encore essayé de débrancher la jarretière et non plus fait le test sous linux, je ferai cela prochainement.
Une question SVP quelle est le test qui indique "mon historique" avec entre autres "les drapeaux français" ?
Je mets ici une copie de mon test sous checkFtthFree.exe
Ah oui je n'ai pas indiqué qu'avant le 22/01/2025 j'étais à Down 7244 Mbps et Up 429 Mbps (photo jointe)
Merci de m'avoir lu
[checkFtthFree v0.25] Windows 11 Build 26100 (64-bit)
-------------------------- 2025-01-31 17:57:11 +0100 --------------------------
Configuration réseau du système:
Adapter.Driver: Intel(R) Ethernet Server Adapter X520-1
Adapter.DriverVersion: 4.1.254.0 (Intel, 2024-02-08)
Adapter.FlowControl: Rx et Tx activées
Adapter.IPChecksumOffloadIPv4: Rx et Tx activées
Adapter.InterruptModeration: Activé(e)
Adapter.JumboPacket: Désactivé(e)
Adapter.LinkSpeed: 10 Gbps
Adapter.LsoV2: Activé(e)
Adapter.PcieLinkSpeed: 5.0 GT/s
Adapter.PcieLinkWidth: 4
Adapter.PhysicalMediaType: 802.3
Adapter.ReceiveBuffers: 2048
Adapter.SpeedDuplex: Négociation automatique
Adapter.TCPChecksumOffload: Rx et Tx activées
Adapter.TransmitBuffers: 2048
NetProfile.NetworkCategory: Private
Tcp.AutoTuningLevelLocal: Normal
Tcp.CongestionProvider: CUBIC
Tcp.EcnCapability: Disabled
Tcp.ScalingHeuristics: Disabled
Tcp.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.33 ms [gigue: 0.67 ms]
--> Débit: 1.14 Go/s (9.12 Gbps) [fluctuation: 0.75%]
Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [BBR]
--> Latence: 17.52 ms [gigue: 1.20 ms]
--> Débit: 320.26 Mo/s (2.56 Gbps) [fluctuation: 26.96%]
[!] Le compteur "ReceivedDiscardedPackets" de l'interface réseau a été incrémenté de 62958 pendant le test.
Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [CUBIC]
--> Latence: 16.70 ms [gigue: 0.58 ms]
--> Débit: 378.67 Mo/s (3.03 Gbps) [fluctuation: 8.32%]
[!] Le compteur "ReceivedDiscardedPackets" de l'interface réseau a été incrémenté de 313 pendant le test.
-------------------------- 2025-01-31 17:57:52 +0100 --------------------------(http://)
-
Il faudrait trouver la cause de tous ces paquets rejetés sur les tests WAN...
-
Bonjour,
Moi je veux bien faire tous les tests que vous souhaitez mais va falloir m'en dire plus, je ne suis pas un spécialiste réseaux je me débrouille simplement, je lis j'essaye les divers tests que d'autres postes.
Donc j'écoute si vous voulez m'en dire plus ?
Cordialement.
Franck
PS : J'ai trouvé sur le bug tracker de free un post qui relate les mêmes problèmes (depuis la mise à jour 4.8.17.1) que l'on a pour info : https://dev.freebox.fr/bugs/task/39973
-
C'est moi qui ai écrit ce ticket. Ce problème n'est pas (encore ?) revenu pour moi après la màj 4.8.18, et ce après 8 jours.
-
Bonjour MaxLebled
Ok et tant mieux pour toi alors ...
Oui la mise à jour 4.8.18 est tombée mais pour moi elle n'a rien changé malheureusement.
Je ne sais pas si certains ont tenté une réinitialisation d'usine ou de sécurité ...
J'ai bien envie d'essayer mais ce qui est long c'est de remettre tous les paramètres... sachant que je suis presque sûr que ca va rien faire de spécial.
Et ce qui me gêne le plus c'est les gels d'images sur la TV pour ma part ou comme hier blocage complet de la TV est obligé de débrancher la box car même en utilisant la touche Free cela ne donne rien, j'avais eu ce souci aussi en 2023 avec ensuite la baisse du débit aussi ...
J'ai essayé de débrancher la fibre derrière la box server mais cela pour mon compte n'a rien donné. Dommage !
Question MaxLebled c'est quelle application que tu utilises pour sortir ton historique avec les petits drapeaux ?
Bonne journée
-
C'est l'historique sur nPerf.com (il faut créer un compte)
-
Ok merci
ca doit être sur le navigateur car j'utilise l'application et sur l'historique j'ai pas cette présentation que je trouve sympa.
Voilà je viens de me connecter sur le site du coup j'ai retrouvé de vieux tests ...
Merci
A+
-
Test TCP local (IPv4): téléchargement depuis la Freebox
--> Latence: 0.33 ms [gigue: 0.67 ms]
--> Débit: 1.14 Go/s (9.12 Gbps) [fluctuation: 0.75%]
Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [BBR]
--> Latence: 17.52 ms [gigue: 1.20 ms]
--> Débit: 320.26 Mo/s (2.56 Gbps) [fluctuation: 26.96%]
[!] Le compteur "ReceivedDiscardedPackets" de l'interface réseau a été incrémenté de 62958 pendant le test.
Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [CUBIC]
--> Latence: 16.70 ms [gigue: 0.58 ms]
--> Débit: 378.67 Mo/s (3.03 Gbps) [fluctuation: 8.32%]
[!] Le compteur "ReceivedDiscardedPackets" de l'interface réseau a été incrémenté de 313 pendant le test.
-------------------------- 2025-01-31 17:57:52 +0100 --------------------------
Tu sembles limité comme moi en mono serveur ...
-
Juste pour être sur, tu as la même limitation que moi sur Rennes en mono connexion ? 3 Go/s max ...
-
Juste pour être sur, tu as la même limitation que moi sur Rennes en mono connexion ? 3 Go/s max ...
En mono-connexion, je ne sais pas. En tout cas ça va faire 20 jours que la 4.8.18 est sortie, et depuis cette version je n'ai plus ce problème de « bridage ». nPerf carbure toujours à 6 Gbps ou plus sans problème, checkFtthFree également.
Sur speedtest.net, ByTel CUBIC mono = 2300/200, ByTel BBR mono = 4200/210
-
En mono-connexion, je ne sais pas. En tout cas ça va faire 20 jours que la 4.8.18 est sortie, et depuis cette version je n'ai plus ce problème de « bridage ». nPerf carbure toujours à 6 Gbps ou plus sans problème, checkFtthFree également.
Sur speedtest.net, ByTel CUBIC mono = 2300/200, ByTel BBR mono = 4200/210
Ok ! Tu es avec la delta, je n’avais ce bridage non plus avec, seulement avec l’ultra !
-
Freebox Ultra mode bridge, Linux, firewall Mikrotik
[checkFtthFree v0.24] Linux 6.12.12-amd64 (x86_64)
-------------------------- 2025-02-14 00:15:13 +0100 --------------------------
Configuration réseau du système:
intf.dev: xxxxxxx
intf.dma-sg: on
intf.driver: 802.1Q VLAN Support 1.8
intf.firmware-version: N/A
intf.mtu: 1500
intf.offload: -cksum_rx | +cksum_tx | +tso | +gso | +gro | -lro
intf.qdisc: noqueue
intf.qlen: 1000
link.autoneg: on
link.duplex: Full
link.port: FIBRE
link.speed: 10000Mb/s
net.core.default_qdisc: fq
net.core.netdev_budget: 300
net.core.netdev_budget_usecs: 8000
net.core.netdev_max_backlog: 1000
net.core.rmem_max: 212992
net.core.wmem_max: 212992
net.ipv4.tcp_adv_win_scale: 1
net.ipv4.tcp_congestion_control: bbr
net.ipv4.tcp_dsack: 1
net.ipv4.tcp_ecn: 2
net.ipv4.tcp_mem: 187686 250248 375372
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.68 ms [gigue: 0.08 ms]
--> Débit: 416.01 Mo/s (3.33 Gbps) [fluctuation: 0.88%]
[!] Le compteur "rx_softnet_squeezed" du noyau a été incrémenté de 2 pendant le test.
Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [BBR]
--> Latence: 3.17 ms [gigue: 0.52 ms]
--> Débit: 629.52 Mo/s (5.04 Gbps) [fluctuation: 4.70%]
Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [CUBIC]
--> Latence: 2.32 ms [gigue: 0.23 ms]
--> Débit: 696.78 Mo/s (5.57 Gbps) [fluctuation: 0.44%]
-------------------------- 2025-02-14 00:15:50 +0100 --------------------------
-
[!] Le compteur "rx_softnet_squeezed" du noyau a été incrémenté de 2 pendant le test.
Cela indique qu'à un moment pendant le transfert le système de gestion des interruptions logicielles réseau n'a pas pu traiter tous les paquets en un cycle, et qu'il a dû repousser leur traitement au cycle suivant.
Si cela se produit fréquemment il est possible que tu puisses améliorer les perfs en ajustant les paramètres netdev_budget sur ton système (tu peux utiliser l'option -s|--suggestions en lançant checkFtthFree pour activer les conseils automatiques qui donneront plus de détails).
Cela pourrait expliquer que tu aies eu un test de débit local moins rapide que les tests WAN. Ou alors peut-être que ton système et/ou la Freebox étaient chargés par ailleurs au moment de ce test ?
Sinon je vois que dans ton cas l'affichage de la configuration réseau par checkFtthFree n'est pas optimal car tu utilises une interface virtuelle de VLAN.
J'ai corrigé cela dans la version 0.26 que je viens de publier, qui devrait correctement identifier l'interface physique sous-jacente pour extraire plus d'infos.
-
Bonjour ouno
Je post mon rapport du programme chechftthfree.exe V0.26 en mode s.
J'ai augmenté au maximum le receiveBuffers en Received mais il ne m'indique rien d'autre pour mon soucis de receivedDiscardedPackets ... le drivers est à jour du 08/02/2024.
Si tu as d'autres trucs ou avis je suis preneur.
Cordialement.
Franck
[checkFtthFree v0.26] Windows 11 Build 26100 (64-bit)
-------------------------- 2025-02-14 14:03:45 +0100 --------------------------
Configuration réseau du système:
Adapter.Driver: Intel(R) Ethernet Server Adapter X520-1
Adapter.DriverVersion: 4.1.254.0 (Intel, 2024-02-08)
Adapter.FlowControl: Rx et Tx activées
Adapter.IPChecksumOffloadIPv4: Rx et Tx activées
Adapter.InterruptModeration: Activé(e)
Adapter.JumboPacket: Désactivé(e)
Adapter.LinkSpeed: 10 Gbps
Adapter.LsoV2: Activé(e)
Adapter.PcieLinkSpeed: 5.0 GT/s
Adapter.PcieLinkWidth: 4
Adapter.PhysicalMediaType: 802.3
Adapter.ReceiveBuffers: 4096
Adapter.SpeedDuplex: 10 Gbit/s Duplex intégral
Adapter.TCPChecksumOffload: Rx et Tx activées
Adapter.TransmitBuffers: 2048
NetProfile.NetworkCategory: Private
Tcp.AutoTuningLevelLocal: Normal
Tcp.CongestionProvider: CUBIC
Tcp.EcnCapability: Disabled
Tcp.ScalingHeuristics: Disabled
Tcp.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.31 ms [gigue: 0.04 ms]
--> Débit: 1.16 Go/s (9.25 Gbps) [fluctuation: 0.43%]
Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [BBR]
--> Latence: 16.64 ms [gigue: 0.32 ms]
--> Débit: 417.03 Mo/s (3.34 Gbps) [fluctuation: 1.77%]
[!] Le compteur "ReceivedDiscardedPackets" de l'interface réseau a été incrémenté de 5959 pendant le test.
Recommandations:
- augmenter la taille de la mémoire tampon de réception de l'interface réseau
- vérifier qu'il n'existe pas un pilote plus récent ou plus adapté pour la carte réseau
Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [CUBIC]
--> Latence: 16.07 ms [gigue: 0.11 ms]
--> Débit: 328.58 Mo/s (2.63 Gbps) [fluctuation: 4.71%]
[!] Le compteur "ReceivedDiscardedPackets" de l'interface réseau a été incrémenté de 15143 pendant le test.
Recommandations:
- augmenter la taille de la mémoire tampon de réception de l'interface réseau
- vérifier qu'il n'existe pas un pilote plus récent ou plus adapté pour la carte réseau
-------------------------- 2025-02-14 14:04:27 +0100 --------------------------
-
Bonjour ouno
Je post mon rapport du programme chechftthfree.exe V0.26 en mode s.
J'ai augmenté au maximum le receiveBuffers en Received mais il ne m'indique rien d'autre pour mon soucis de receivedDiscardedPackets ... le drivers est à jour du 08/02/2024.
Si tu as d'autres trucs ou avis je suis preneur.
Cordialement.
Franck
Bonjour,
Normalement ce compteur indique que des paquets ont été refusés par ton interface réseau alors qu'ils étaient pourtant valides (somme de contrôle OK etc.).
Cela est en général dû à une saturation de la mémoire tampon de réception associée à l'interface, dans le cas où le système ne parvient pas à traiter les paquets reçus suffisament vite pour vider cette mémoire tampon au fur et à mesure.
Mais il peut y avoir d'autres raisons, qui dépendent en plus des pilotes réseau, du firmware etc.
Certains constructeurs comme Mellanox/NVIDIA fournissent des outils qui permettent d'extraire des compteurs d'erreur plus spécifiques sur les interfaces, je ne sais pas si c'est le cas d'Intel.
En tout cas tu es la quatrième personne qui remonte ce problème avec une carte réseau Intel sous Windows:
- Fuzy (https://lafibre.info/1gb-free/checkftthfree-test-de-debit-tcp-mono-connexion-freeboxcubicbbr/msg1096167/#msg1096167)
- kgersen (https://lafibre.info/1gb-free/checkftthfree-test-de-debit-tcp-mono-connexion-freeboxcubicbbr/msg1096398/#msg1096398)
- MaxLeBled (https://lafibre.info/1gb-free/checkftthfree-test-de-debit-tcp-mono-connexion-freeboxcubicbbr/msg1101322/#msg1101322) (même carte et même driver que toi)
A ce stade on pourrait se poser la question d'un bug côté pilote réseau Intel pour Windows: le compteur serait incrémenté par erreur sous certaines conditions et il faudrait simplement l'ignorer...
Mais ça serait quand même étonnant que ce bug passe inaperçu, ou alors personne ne consulte les compteurs d'erreur d'interface sous Windows ? ???
-
En mono-connexion, je ne sais pas. En tout cas ça va faire 20 jours que la 4.8.18 est sortie, et depuis cette version je n'ai plus ce problème de « bridage ». nPerf carbure toujours à 6 Gbps ou plus sans problème, checkFtthFree également.
Bon, le problème est revenu... mais j'ai de nouveaux éléments.
Regardez-moi ça :
(https://i.imgur.com/uHx5XD9.png)
Le problème n'apparaît qu'en ipv4 !!!
J'ai cru, à tort, que nPerf utilisait forcément l'ipv6 vu qu'il l'affiche.
Ceci dit, ça n'explique toujours pas pourquoi un simple débranchage et rebranchage immédiat de la jarretière PTO derrière la box, sans rien redémarrer quoi que ce soit (la box, le PC, les logiciels en execution, etc.), règle immédiatement ce problème.
-
Est-ce que ça pourrait avoir un impact sur le end-point du tunnel qui porte l'IPv4 chez Free ?
-
Chez nous, on a beau redémarrer électriquement le Server Delta, on reste bloqué à 3 Gbps à l'infini.
-
Bonsoir Frederic.moreau
J'ai essayé les deux commande iperf3 mais cela m'indique sur les 2 connection timed out
>iperf3 -R -c ipv6.gooze.eu -p 9200
iperf3: error - unable to connect to server - server may have stopped running or use a different port, firewall issue, etc.: Connection timed out
Donc je ne sais pas trop quoi faire.
Mon iperf3 doit fonctionner car cela marche avec :
>iperf3 -p 5200 -c ping6.online.net
Connecting to host ping6.online.net, port 5200
[ 5] local 2a01:e0a:1b2:fbe0:ce9:caf4:c4a2:5750 port 53443 connected to 2001:bc8:0:1::49 port 5200
[ ID] Interval Transfer Bitrate
[ 5] 0.00-1.01 sec 28.9 MBytes 240 Mbits/sec
[ 5] 1.01-2.00 sec 33.9 MBytes 286 Mbits/sec
[ 5] 2.00-3.01 sec 37.4 MBytes 311 Mbits/sec
[ 5] 3.01-4.01 sec 39.2 MBytes 331 Mbits/sec
[ 5] 4.01-5.00 sec 40.4 MBytes 341 Mbits/sec
[ 5] 5.00-6.01 sec 43.9 MBytes 364 Mbits/sec
[ 5] 6.01-7.01 sec 47.6 MBytes 401 Mbits/sec
[ 5] 7.01-8.00 sec 52.2 MBytes 440 Mbits/sec
[ 5] 8.00-9.01 sec 56.0 MBytes 465 Mbits/sec
[ 5] 9.01-10.01 sec 56.0 MBytes 472 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate
[ 5] 0.00-10.01 sec 436 MBytes 365 Mbits/sec sender
[ 5] 0.00-10.05 sec 435 MBytes 363 Mbits/sec receiver
iperf Done.
Cordialement.
Franck
-
Bonsoir Frederic.moreau
Il faut rajouter -R à ton iperf3 pour mesurer le débit descendant.
Oui, désolé, j'ai mis fin au protocole de test après discussion avec des membres du forum, comprenant et admettant mes erreurs de méthodologie. Lire le post :
https://lafibre.info/1gb-free/serveurs-ipv4-et-ipv6-freebox-delta/
Je pense que tous ceux qui comme moi ont investi dans une archi entièrement 10Gbit/s vont avoir des difficultés à comprendre que l'offre de Free sur l'Ultra et la Delta n'est tout simplement pas au rendez-vous en raison d'un limite de la technologie. C'est dur à avaler, mais pour moi c'est acté. Je regarde passer mes torrents montants à 2Mo/s comme un chat devant un aquarium et j'en reste là.
Faire un test iperf3 n'est pas pertinent, par exemple à l'instant je sors 6,58 Gbit/s descendant en IPv6 télé allumée et serveur de torrent actif avec politique de filtrage :
iperf3 -R -c ipv6.scaleway.testdebit.info -p 9202
Connecting to host ipv6.scaleway.testdebit.info, port 9202
Reverse mode, remote host ipv6.scaleway.testdebit.info is sending
[ 5] local 2a01:xxxxxxxxxxxx port 38594 connected to 2001:bc8:3::7 port 9202
[ ID] Interval Transfer Bitrate
[ 5] 0.00-1.00 sec 692 MBytes 5.80 Gbits/sec
[ 5] 1.00-2.00 sec 672 MBytes 5.64 Gbits/sec
[ 5] 2.00-3.00 sec 794 MBytes 6.66 Gbits/sec
[ 5] 3.00-4.00 sec 806 MBytes 6.76 Gbits/sec
[ 5] 4.00-5.00 sec 848 MBytes 7.12 Gbits/sec
[ 5] 5.00-6.00 sec 824 MBytes 6.91 Gbits/sec
[ 5] 6.00-7.00 sec 799 MBytes 6.70 Gbits/sec
[ 5] 7.00-8.00 sec 785 MBytes 6.59 Gbits/sec
[ 5] 8.00-9.00 sec 810 MBytes 6.80 Gbits/sec
[ 5] 9.00-10.00 sec 814 MBytes 6.83 Gbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.03 sec 7.68 GBytes 6.58 Gbits/sec 36 sender
[ 5] 0.00-10.00 sec 7.67 GBytes 6.58 Gbits/sec receiver
iperf Done.
En débit montant j'ai une vitesse légèrement moins bonne :
iperf3 -c ipv6.scaleway.testdebit.info -p 9202
Connecting to host ipv6.scaleway.testdebit.info, port 9202
[ 5] local 2a01:xxxxxxxxxxxxxxxxx port 34350 connected to 2001:bc8:3::7 port 9202
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 269 MBytes 2.26 Gbits/sec 63 1.53 MBytes
[ 5] 1.00-2.00 sec 501 MBytes 4.20 Gbits/sec 31 1.75 MBytes
[ 5] 2.00-3.00 sec 648 MBytes 5.44 Gbits/sec 0 1.99 MBytes
[ 5] 3.00-4.00 sec 780 MBytes 6.54 Gbits/sec 0 2.26 MBytes
[ 5] 4.00-5.00 sec 878 MBytes 7.37 Gbits/sec 0 2.53 MBytes
[ 5] 5.00-6.00 sec 841 MBytes 7.05 Gbits/sec 0 2.72 MBytes
[ 5] 6.00-7.00 sec 859 MBytes 7.20 Gbits/sec 0 2.90 MBytes
[ 5] 7.00-8.00 sec 635 MBytes 5.33 Gbits/sec 472 1.60 MBytes
[ 5] 8.00-9.00 sec 566 MBytes 4.75 Gbits/sec 0 1.83 MBytes
[ 5] 9.00-10.00 sec 666 MBytes 5.59 Gbits/sec 0 2.08 MBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 6.49 GBytes 5.57 Gbits/sec 566 sender
[ 5] 0.00-10.04 sec 6.49 GBytes 5.55 Gbits/sec receiver
iperf Done.
Cette vitesse est à l'instant t, depuis un host source vers un host cible, et elle dépend de nombreux critères. Et cela ne changera rien au fait que mon torrent est à 2Mo/s montant.
J'avais une Delta qui marchait très bien. Je l'ai changé en Ultra sans avantage réel et je paye 50€/mois. J'en reste là.
Tout ce qu'on peut dire de scientifique à ce stade, c'est que les firewall Mikrotik 2004 peuvent encaisser du 7Gbit/s et le filtrer en temps réel avec de l'inter-vlan à la même vitesse, ce qui est remarquable. Mais cela arrive tellement rarement que cela ne justifie pas l'investissement, en tout cas pour un particulier.
-
Merci pour ta réponse,
Je te réponds aussi ici ...
ok pour la fin du test iperf pour toi.
Ok pour rajouter un -R à mon test iperf3 ... je ne peux pas le faire de suite, car j'explique madame regarde la TV et dès que ma vitesse en test dépasse les 2 ou 2.2 Gbps la TV freeze pendant la durée du ou des tests ... donc là je vais me faire allumer si je lancer un truc ...
et ok mais comme je te disais sur l'autre post cela n'explique pas (pour un néophyte comme moi) notre problème de débit diminué sur plusieurs personnes de divers départements.
et j'ai même un test fait de plusieurs heures ou ma courbe de download est constant sur 3 à 3.2 Gbps (courbe sur la freebox ou sur le pc)
Cordialement.
Franck
-
Salut Franck,
Juste une supposition : je ne constate aucun ralentissement avec ma box en mode bridge et un laptop sous Linux. Attention que comme je suis sous LInux sur un vrai système d'exploitation, avec aucun port ouvert et sans firewall intégré (inutile puisque je n'ai aucun port ouvert et je suis sur réseau local derrière un vrai firewall), rien ne ralentit mes mesures. Je n'utilise jamais Windows pour un tas de raisons, la première et la principale étant que cela ne fonctionne pas bien. Tout cela me permet de mesurer la vitesse réelle sur le réseau.
Donc cela vaudrait peut-être le coup que quelqu'un affecté par le problème de baisse des débits fasse un test iperf3 en mode Bridge. Le mode Bridge signifie que la box est directement reliée à Internet sans firewall (généralement on installe son propre firewall).
1) Tu fais un premier test iperf3 en mode firewallé pour établir les 3Gbit/s.
2) Puis tu reboote ta box en mode bridge pour un deuxième test iperf3. Pour que cela soit pertinent, il faut également couper le firewall de ton laptop. Attention que dès que tu reçois l'IP de ta box, tu es en direct sur le NET, sans firewall, donc totalement à poil sur un système vieillot et dépassé, Windows. Le mode bridge va couper la télé.
3) Une fois le test effectué en quelques secondes, tu repasses en mode firewall et tu rebootes ta box.
Si tu obtiens des mesures différentes, c'est le firewall de la box ou le firewall de Windows qui sont en cause.
Bien entendu, si vous avez établi que des Freebox en mode bridge sont affectées par le problème de débit, c'est inutile de faire ce test. Je n'ai pas eu le temps de lire les 30 pages du poste pour vérifier si vous aviez écarté l'hypothèse du mode bridge de la freebox.
-
Ok Frederic,
Au niveau linux je ne connais pas assez, au moment ou on a eu le problème de baisse de débit, j'avais fait une clef avec un linux live juste pour être sûr et j'ai lancé un test checkftthfree.exe mais la box en mode routeur et cela n'avait rien donné de plus la baisse était toujours là. Je n'ai pas pu faire de copie d'écran car comme dit sous linux ... quand on ne connait pas il faut chercher pas mal ... autant sous Windows je me débrouille mais ailleurs pas trop.
Alors je suppose que le firewall de la box que tu parles c'est la coche sur la partie IPV6 car je n'ai pas vu ailleurs ou alors j'ai oublié.
Et pour le firewall de l'ordinateur j'avais aussi réinstallé le pc sous Windows 23H2 et 24H2 sans rien dessus même sans antivirus ni firewall pour le test et rien de plus tout était aussi bridé à 3.0 3.2 Gbps depuis la fameuse date du 28/01/2025.
Mais je pourrai ré essayer pour voir ce que cela donne, c'est un peu long à faire mais pourquoi pas.
Cordialement.
Franck
-
Effectivement booter sur une clé Linux Live offre les mêmes avantages et c'est très sécurisé.
Ma box est en mode bridge, comme montre cette copie d'écran.
Et je vous garantis que je n'ai aucun problème de débit.
Je suis étonné que personne n'ai testé en mode bridge, essayez de vérifier avant de vous lancer dans ce test simple.
Donc toujours dans l'hypothèse où le mode bridge ne serait pas affecté :
1) Booter sur une Linux live, par exemple la Debian
https://cdimage.debian.org/cdimage/weekly-live-builds/amd64/iso-hybrid/debian-live-testing-amd64-gnome.iso
A la connexion, tape "sudo apt install iperf3" pour installer iperf3.
2) Faire un premier test iperf3 en mode routeur.
3) Passer la box en mode bridge. Aller à https://mafreebox.freebox.fr
Paramètres de la Freebox/mode réseau. Choisir Bridge.
Rebooter la box et faire un deuxième test.
Normalement tu ne cours aucun risque, mais il faut juste avoir conscience que tu es en direct sur le Net.
4) Repasser en mode routeur et rebooter la box.
-
ok c'est noté merci
Là pendant la pub j'ai pu faire un test iperf (windows 11) en ipv6 (avec firewall) et le deuxième (sans firewall mais sans rebooter la box)
>iperf3 -p 5200 -c ping6.online.net -R
Connecting to host ping6.online.net, port 5200
Reverse mode, remote host ping6.online.net is sending
[ 5] local 2xxxxx port 63520 connected to xxxxxx port 5200
[ ID] Interval Transfer Bitrate
[ 5] 0.00-1.00 sec 347 MBytes 2.90 Gbits/sec
[ 5] 1.00-2.01 sec 439 MBytes 3.67 Gbits/sec
[ 5] 2.01-3.01 sec 430 MBytes 3.59 Gbits/sec
[ 5] 3.01-4.00 sec 420 MBytes 3.56 Gbits/sec
[ 5] 4.00-5.01 sec 444 MBytes 3.69 Gbits/sec
[ 5] 5.01-6.01 sec 432 MBytes 3.60 Gbits/sec
[ 5] 6.01-7.01 sec 425 MBytes 3.60 Gbits/sec
[ 5] 7.01-8.01 sec 453 MBytes 3.78 Gbits/sec
[ 5] 8.01-9.00 sec 400 MBytes 3.39 Gbits/sec
[ 5] 9.00-10.01 sec 435 MBytes 3.62 Gbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.05 sec 4.21 GBytes 3.60 Gbits/sec 303312 sender
[ 5] 0.00-10.01 sec 4.13 GBytes 3.54 Gbits/sec receiver
iperf Done.
>iperf3 -p 5200 -c ping6.online.net -R
Connecting to host ping6.online.net, port 5200
Reverse mode, remote host ping6.online.net is sending
[ 5] local 2xxxxx port 65123 connected to xxxxxxx port 5200
[ ID] Interval Transfer Bitrate
[ 5] 0.00-1.01 sec 372 MBytes 3.10 Gbits/sec
[ 5] 1.01-2.01 sec 407 MBytes 3.39 Gbits/sec
[ 5] 2.01-3.00 sec 419 MBytes 3.54 Gbits/sec
[ 5] 3.00-4.01 sec 430 MBytes 3.58 Gbits/sec
[ 5] 4.01-5.00 sec 398 MBytes 3.38 Gbits/sec
[ 5] 5.00-6.01 sec 460 MBytes 3.83 Gbits/sec
[ 5] 6.01-7.02 sec 414 MBytes 3.45 Gbits/sec
[ 5] 7.02-8.01 sec 403 MBytes 3.42 Gbits/sec
[ 5] 8.01-9.01 sec 435 MBytes 3.63 Gbits/sec
[ 5] 9.01-10.00 sec 423 MBytes 3.59 Gbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.06 sec 4.15 GBytes 3.54 Gbits/sec 303261 sender
[ 5] 0.00-10.00 sec 4.06 GBytes 3.49 Gbits/sec receiver
iperf Done.
au cas ou ca donne des indications, en tout ca la TV a freeze tout le long du test.
-
Désactiver ton firewall de l'ordinateur ne sert à rien si c'est le firewall de la Freebox qui pose problème. Il faut faire un test en mode bridge, donc en désactivant le firewall de la box (en fait il n'est pas désactivé, tous les ports sont redirigés). Et quand je dis "il faut", je n'ai pas vérifié en lisant les 30 pages si quelqu'un avait eu l'idée de passer en mode bridge.
Je pose la question au forum : vous avez testé en mode bridge ? Un test effectué à l'instant en mode bridge :
iperf3 -p 5200 -c ping6.online.net -R
Connecting to host ping6.online.net, port 5200
Reverse mode, remote host ping6.online.net is sending
[ 5] local 2a01:xxxxxxxxxxxxxxxxxxxxxxx port 45670 connected to 2001:bc8:0:1::49 port 5200
[ ID] Interval Transfer Bitrate
[ 5] 0.00-1.00 sec 744 MBytes 6.23 Gbits/sec
[ 5] 1.00-2.00 sec 738 MBytes 6.19 Gbits/sec
[ 5] 2.00-3.00 sec 748 MBytes 6.28 Gbits/sec
[ 5] 3.00-4.00 sec 752 MBytes 6.31 Gbits/sec
[ 5] 4.00-5.00 sec 776 MBytes 6.51 Gbits/sec
[ 5] 5.00-6.00 sec 753 MBytes 6.31 Gbits/sec
[ 5] 6.00-7.00 sec 782 MBytes 6.56 Gbits/sec
[ 5] 7.00-8.00 sec 744 MBytes 6.24 Gbits/sec
[ 5] 8.00-9.00 sec 771 MBytes 6.46 Gbits/sec
[ 5] 9.00-10.00 sec 783 MBytes 6.57 Gbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.04 sec 7.44 GBytes 6.37 Gbits/sec 1 sender
[ 5] 0.00-10.00 sec 7.41 GBytes 6.37 Gbits/sec receiver
iperf Done.
iperf3 -p 5200 -c ping6.online.net
Connecting to host ping6.online.net, port 5200
[ 5] local 2a01:xxxxxxxxxxxxxxxxxxxxxx port 53482 connected to 2001:bc8:0:1::49 port 5200
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 268 MBytes 2.25 Gbits/sec 123 1.57 MBytes
[ 5] 1.00-2.00 sec 449 MBytes 3.77 Gbits/sec 79 1.77 MBytes
[ 5] 2.00-3.00 sec 792 MBytes 6.65 Gbits/sec 44 1.45 MBytes
[ 5] 3.00-4.00 sec 664 MBytes 5.57 Gbits/sec 0 1.76 MBytes
[ 5] 4.00-5.00 sec 801 MBytes 6.72 Gbits/sec 0 2.06 MBytes
[ 5] 5.00-6.00 sec 878 MBytes 7.37 Gbits/sec 0 2.34 MBytes
[ 5] 6.00-7.00 sec 885 MBytes 7.42 Gbits/sec 0 2.60 MBytes
[ 5] 7.00-8.00 sec 886 MBytes 7.43 Gbits/sec 0 2.84 MBytes
[ 5] 8.00-9.00 sec 882 MBytes 7.40 Gbits/sec 0 3.06 MBytes
[ 5] 9.00-10.00 sec 888 MBytes 7.44 Gbits/sec 0 3.26 MBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 7.22 GBytes 6.20 Gbits/sec 246 sender
[ 5] 0.00-10.04 sec 7.22 GBytes 6.18 Gbits/sec receiver
iperf Done.
-
Peut etre que je ne sais pas trop comment ca fonctionne ... c'est certain mais je parlais du firewall de la box mais en décochant et en faisant appliquer mais sans redemarrer la box (juste appliquer et ok)
la partie "configuration ipv6" et désactiver le firewall dans onglet Général
ok pour le mode bridge mais là pas possible (pour les raisons dites avant)
-
Pour basculer en mode routeur=>bridge ou bridge=>routeur, il faut obligatoirement rebooter la box. C'est sans risque on peut basculer d'un mode à l'autre sans perte de données. Seule la télé et le télphone vont cesser de fonctionner. Mais dès que tu repasses en mode routeur tout revient à l'origine.
Le forum : vous avez effectué ce test simple ? A mon avis cela a déjà était fait.
Perso, je vous dis bonsoir et je vais me coucher.
-
Bonjour du dimanche,
Voilà quelques tests faits, pour faire avancer ou pas ... en routeur en Bridge avec firewall et en Bridge avec firewall sans firewall en rebootant la freebox delta entre chaque tests.
Test fait Freebox Server Delta - en mode ROUTEUR ipv6 avec firewall
iperf3 -R -c ipv6.scaleway.testdebit.info -p 9202
Connecting to host ipv6.scaleway.testdebit.info, port 9202
Reverse mode, remote host ipv6.scaleway.testdebit.info is sending
[ 5] local 2xxxxx port 58711 connected to 2001xxxx port 9202
[ ID] Interval Transfer Bitrate
[ 5] 0.00-1.01 sec 350 MBytes 2.92 Gbits/sec
[ 5] 1.01-2.02 sec 409 MBytes 3.40 Gbits/sec
[ 5] 2.02-3.01 sec 393 MBytes 3.32 Gbits/sec
[ 5] 3.01-4.02 sec 423 MBytes 3.52 Gbits/sec
[ 5] 4.02-5.01 sec 393 MBytes 3.32 Gbits/sec
[ 5] 5.01-6.01 sec 392 MBytes 3.27 Gbits/sec
[ 5] 6.01-7.00 sec 392 MBytes 3.32 Gbits/sec
[ 5] 7.00-8.01 sec 386 MBytes 3.22 Gbits/sec
[ 5] 8.01-9.00 sec 400 MBytes 3.38 Gbits/sec
[ 5] 9.00-10.01 sec 424 MBytes 3.53 Gbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.06 sec 3.88 GBytes 3.31 Gbits/sec 85656 sender
[ 5] 0.00-10.01 sec 3.87 GBytes 3.32 Gbits/sec receiver
iperf Done.
Test fait Freebox Server Delta - en mode BRIDGE ipv6 avec firewall
iperf3 -R -c ipv6.scaleway.testdebit.info -p 9202
Connecting to host ipv6.scaleway.testdebit.info, port 9202
Reverse mode, remote host ipv6.scaleway.testdebit.info is sending
[ 5] local 2xxxx port 57793 connected to 2001xxxx port 9202
[ ID] Interval Transfer Bitrate
[ 5] 0.00-1.01 sec 303 MBytes 2.52 Gbits/sec
[ 5] 1.01-2.01 sec 423 MBytes 3.53 Gbits/sec
[ 5] 2.01-3.01 sec 423 MBytes 3.57 Gbits/sec
[ 5] 3.01-4.00 sec 417 MBytes 3.52 Gbits/sec
[ 5] 4.00-5.01 sec 468 MBytes 3.90 Gbits/sec
[ 5] 5.01-6.00 sec 455 MBytes 3.84 Gbits/sec
[ 5] 6.00-7.01 sec 453 MBytes 3.77 Gbits/sec
[ 5] 7.01-8.02 sec 441 MBytes 3.67 Gbits/sec
[ 5] 8.02-9.01 sec 447 MBytes 3.77 Gbits/sec
[ 5] 9.01-10.00 sec 459 MBytes 3.89 Gbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.05 sec 4.20 GBytes 3.59 Gbits/sec 74410 sender
[ 5] 0.00-10.00 sec 4.19 GBytes 3.60 Gbits/sec receiver
iperf Done.
Test fait Freebox Server Delta - en mode BRIDGE ipv6 SANS Firewall
iperf3 -R -c ipv6.scaleway.testdebit.info -p 9202
Connecting to host ipv6.scaleway.testdebit.info, port 9202
Reverse mode, remote host ipv6.scaleway.testdebit.info is sending
[ 5] local 2xxxxxx port 63520 connected to 2001xxxxx port 9202
[ ID] Interval Transfer Bitrate
[ 5] 0.00-1.01 sec 301 MBytes 2.51 Gbits/sec
[ 5] 1.01-2.01 sec 431 MBytes 3.58 Gbits/sec
[ 5] 2.01-3.00 sec 413 MBytes 3.49 Gbits/sec
[ 5] 3.00-4.01 sec 443 MBytes 3.68 Gbits/sec
[ 5] 4.01-5.00 sec 415 MBytes 3.51 Gbits/sec
[ 5] 5.00-6.01 sec 439 MBytes 3.65 Gbits/sec
[ 5] 6.01-7.00 sec 409 MBytes 3.46 Gbits/sec
[ 5] 7.00-8.01 sec 422 MBytes 3.51 Gbits/sec
[ 5] 8.01-9.01 sec 449 MBytes 3.79 Gbits/sec
[ 5] 9.01-10.02 sec 441 MBytes 3.67 Gbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.06 sec 4.08 GBytes 3.48 Gbits/sec 79428 sender
[ 5] 0.00-10.02 sec 4.06 GBytes 3.49 Gbits/sec receiver
iperf Done.
Tiens pendant que j'étais en forme de bonne heure un petit test Checkfttpfree.exe en v 0.26
Test TCP local (IPv4): téléchargement depuis la Freebox
--> Latence: 0.34 ms [gigue: 0.06 ms]
--> Débit: 1.15 Go/s (9.23 Gbps) [fluctuation: 0.66%]
Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [BBR]
--> Latence: 16.69 ms [gigue: 0.14 ms]
--> Débit: 411.67 Mo/s (3.29 Gbps) [fluctuation: 4.33%]
[!] Le compteur "ReceivedDiscardedPackets" de l'interface réseau a été incrémenté de 3664 pendant le test.
Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [CUBIC]
--> Latence: 16.22 ms [gigue: 0.31 ms]
--> Débit: 376.73 Mo/s (3.01 Gbps) [fluctuation: 4.90%]
[!] Le compteur "ReceivedDiscardedPackets" de l'interface réseau a été incrémenté de 5142 pendant le test.
-------------------------- 2025-02-16 09:47:39 +0100 --------------------------
Le local est ok 9.23 Gbps et le distant en IPV4 à 3.29 et 3.01 Gbps
9.34 Gbps " " " en IPV6 à 3.47 et 3.66 Gbps
mais toujours des "ReceivedDiscardedPackets"
Je ne comprends pas tout mais là je pense que les tests en mode routeur ou bridge et avec et sans firewall sont similaires, les variations paraissent normales et logiques je pense mais je ne suis toujours pas spécialiste réseaux.
Cordialement.
Franck
-
De mon point de vue, je ne pense pas que le mode bridge puisse améliorer quoi que se soit. Et tes tests viennent de le démontrer.
La limitation est sûrement en amont.
-
Merci Darkmoon
C'est un peu ce que je pensais mais je ne suis qu'un initié et non un féru de réseaux ... et bon ça ne me coute rien de faire divers tests et je ne vais pas dire que j'aime cela mais j'aime essayer de comprendre ou pas ... lol
Cordialement et bon dimanche
Franck
-
Merci pour le test ;) Le bridge n'a aucun impact.
Je vois que j'ai bien de la chance d'avoir 6Gbit/s dans les deux sens sur ma Freebox Ultra.
Il y a effectivement un problème quelque part.
-
Bonjour,
Merci de vos confirmations.
J'espère que le post sur le Bug Tracker de "Nbanba" va faire avancer les choses un peu plus rapidement car cela commence à faire long (depuis fin janvier).
https://dev.freebox.fr/bugs/task/40060 (https://dev.freebox.fr/bugs/task/40060)
Cordialement.
Franck
-
Bonjour à tous.
Un formulaire vient de sortir par Free pour déclarer le problème de limitation à 3 ou 4 Gbps.
Vous le trouverez sur le post de Nbanba (qui nous a bien aidé)
https://lafibre.info/1gb-free/test-svp-suspicion-de-limitation-a-4gps-des-freebox-delta-ultra/ (https://lafibre.info/1gb-free/test-svp-suspicion-de-limitation-a-4gps-des-freebox-delta-ultra/)
Merci de le remplir pour j'espère sortir de ce problème.
Cordialement.
Franck
-
Bonjour à tous.
Un formulaire vient de sortir par Free pour déclarer le problème de limitation à 3 ou 4 Gbps.
Vous le trouverez sur le post de Nbanba (qui nous a bien aidé)
https://lafibre.info/1gb-free/test-svp-suspicion-de-limitation-a-4gps-des-freebox-delta-ultra/ (https://lafibre.info/1gb-free/test-svp-suspicion-de-limitation-a-4gps-des-freebox-delta-ultra/)
Merci de le remplir pour j'espère sortir de ce problème.
Cordialement.
Franck
Formulaire envoyé également, pour ma part j'éspère juste obtenir mieux ;) !
-
Bonjour Fuzy et vous tous,
Oui je l'espère aussi pour toi et pour nous tous.
Par contre ayant remplis le formulaire dès sa sortie, je m'aperçois que celui à changer (quand j'ai cliqué par hasard dessus tout à l'heure) il est plus complet mais demande des informations genre OLT que je ne sais où trouver sur une Freebox Delta... Si quelqu'un à l'info c'est volontiers.
Cordialement.
Franck
PS : apparemment Free est en ligne sur le formulaire car la question OLT a disparu.
-
Bonjour Fuzy et vous tous,
Oui je l'espère aussi pour toi et pour nous tous.
Par contre ayant remplis le formulaire dès sa sortie, je m'aperçois que celui à changer (quand j'ai cliqué par hasard dessus tout à l'heure) il est plus complet mais demande des informations genre OLT que je ne sais où trouver sur une Freebox Delta... Si quelqu'un à l'info c'est volontiers.
Cordialement.
Franck
PS : apparemment Free est en ligne sur le formulaire car la question OLT a disparu.
Oui j'ai vu ça également, je ne comprenais pas trop la question également car nous n'avons pas accès au matériel en amont de la Freebox... Dans le doute j'ai mis la référence SFP car c'est la seule différence matériel que j'ai avec les personnes qui perfoment des tests mono à 6/8 Gbps :
-
pour info, je ne pense pas que ping.online.net/ping6.online.net soit encore CUBIC.
quand on fait un iperf3 -V ... avec eux, ca indique BBR.
par ailleurs le serveur scaleway.testdebit.info (serveur 10 Gbps) me semble insuffisant pour des bons tests.
derriere une ligne Orange 8G, je n'obtiens rarement 8G alors que j'obtiens tout le temps 8G avec ping6.online.net (qui lui est un serveur 100Gbps).
-
pour info, je ne pense pas que ping.online.net/ping6.online.net soit encore CUBIC.
Ah oui effectivement tu as raison, les flux HTTP descendants provenant de ping.online.net/ping6.online.net présentent bien les caractéristiques d'un flux BBR, notamment avec les intervalles de RTT probe bien visibles.
Merci pour l'info.
C'est bien dommage, je ne sais pas depuis quand c'est le cas mais ça veut dire qu'en fait actuellement checkFtthFree ne teste plus les performances en CUBIC, faute de serveur de test disponible.
Il va falloir que je modifie checkFtthFree car actuellement c'est trompeur :-\
j'obtiens tout le temps 8G avec ping6.online.net (qui lui est un serveur 100Gbps).
Du coup entre ping.online.net qui est en BBR et non en CUBIC, avec une connexion 100G et non 10G d'après ce que tu indiques, et les serveurs HTTP bouygues qui ont été supprimés, la page testdebit.info (https://testdebit.info/) n'est vraiment plus à jour:
-
Du coup entre ping.online.net qui est en BBR et non en CUBIC, avec une connexion 100G et non 10G d'après ce que tu indiques, et les serveurs HTTP bouygues qui ont été supprimés, la page testdebit.info (https://testdebit.info/) n'est vraiment plus à jour:
non plus trop. ;D
-
Bonjour
En bas de la page, il est écrit:
To add / remove a public iPerf3 server, please report them to @lafibreinfo
Ce ne serait pas le compte X de @Vivien ?
Cordialement
nbanba
-
Nouvelle version v0.27
Changements majeurs:
- Suppression du test CUBIC
Le serveur Scaleway qui était indiqué comme utilisant l'algorithme CUBIC était en fait passé en BBR depuis quelque temps. Les résultats "CUBIC" des tests checkFtthFree réalisés récemment étaient donc trompeurs car ils utilisaient en fait l'algorithme BBR. Malheureusement il n'y a plus de serveur de test de débit HTTP CUBIC disponible permettant des tests à 8 Gbps. Par défaut checkFtthFree effectue donc maintenant un seul test Internet, en utilisant le serveur Scaleway BBR 100 Gbps. La fonctionnalité d'évaluation de la perte de paquets basée sur la comparaison des débits CUBIC/BBR n'est plus active. - Réintroduction des modes serveur de test alternatif (paramètres --alternate-srv|-a et --all-srv|-A)
Le paramètre --alternate-srv|-a permet d'effectuer le test Internet en utilisant le serveur Appliwave BBR 40 Gbps à la place du serveur Scaleway 100 Gbps. Le paramètre --all-srv|-A permet d'effectuer les tests sur les deux serveurs, d'abord en utilisant le serveur Scaleway puis en utilisant le serveur Appliwave - Ajout du mode multi-version IP
Le nouveau paramètre --all-ipv|-2 permet d'effectuer tous les tests en double, une fois en IPv4 puis une autre fois en IPv6. Lorsque les deux paramètres --all-srv|-A et --all-ipv|-2 sont utilisés conjointement, cela permet donc d'effectuer un total de 6 tests automatiquement: IPv4 local, IPv6 local, IPv4 Scaleway, IPv6 Scaleway, IPv4 Appliwave et IPv6 Appliwave. - Ajout de la détection des tests de débit qui semblent limités par le paramétrage de la mémoire tampon TCP du système
Jusqu'à présent checkFtthFree remontait des avertissements concernant le paramétrage de la mémoire tampon TCP du système uniquement lorsque cette configuration pouvait empêcher un débit Internet de 1 Gbps. Dorénavant checkFtthFree analyse les résultats de chaque test pour détecter si le transfert pourrait avoir été limité par la configuration du système, même si le débit obtenu est supérieur à 1 Gbps.
-
Est-ce que chez vous aussi le test local avec la Freebox est beaucoup plus lent en IPv6 qu'en IPv4 ?
Vous pouvez lancer checkFtthFree avec les paramètres -f -2 (ou -f2 en regroupant les paramètres ce qui revient au même) pour faire le test.
Sur une Freebox Revolution la différence est flagrante:
-------------------------- 2025-03-01 08:54:55 +0100 --------------------------
Test TCP local (IPv4): téléchargement depuis la Freebox
--> Latence: 1.76 ms [gigue: 0.03 ms]
--> Débit: 117.16 Mo/s (937.28 Mbps) [fluctuation: 0.66%]
Test TCP local (IPv6): téléchargement depuis la Freebox
--> Latence: 1.80 ms [gigue: 0.06 ms]
--> Débit: 59.02 Mo/s (472.18 Mbps) [fluctuation: 0.44%]
-------------------------- 2025-03-01 08:55:20 +0100 --------------------------
Je suppose que c'est un problème lié à cette version de Freebox qui est assez ancienne maintenant.
Mais si c'est généralisé je retirerai le test local IPv6 qui n'a pas d'intérêt du coup.
-
Est-ce que chez vous aussi le test local avec la Freebox est beaucoup plus lent en IPv6 qu'en IPv4 ?
;)
[checkFtthFree v0.27] Windows 11 Build 26100 (64-bit)
-------------------------- 2025-03-01 10:53:43 +0100 --------------------------
Configuration réseau du système:
Adapter.Driver: Intel(R) 82599 10 Gigabit Network Connection
Adapter.DriverVersion: 4.1.254.0 (Intel, 2024-02-08)
Adapter.FlowControl: Rx et Tx activées
Adapter.IPChecksumOffloadIPv4: Rx et Tx activées
Adapter.InterruptModeration: Activé(e)
Adapter.JumboPacket: Désactivé(e)
Adapter.LinkSpeed: 10 Gbps
Adapter.LsoV2: Activé(e)
Adapter.PcieLinkSpeed: 5.0 GT/s
Adapter.PcieLinkWidth: 4
Adapter.PhysicalMediaType: 802.3
Adapter.ReceiveBuffers: 512
Adapter.SpeedDuplex: Négociation automatique
Adapter.TCPChecksumOffload: Rx et Tx activées
Adapter.TransmitBuffers: 512
NetProfile.NetworkCategory: Private
Tcp.AutoTuningLevelLocal: Normal
Tcp.CongestionProvider: CUBIC
Tcp.EcnCapability: Disabled
Tcp.ScalingHeuristics: Disabled
Tcp.Timestamps: Allowed
=> Latence max pour une réception TCP à 1 Gbps: 141 ms
Test TCP local (IPv4): téléchargement depuis la Freebox
--> Latence: 0.84 ms [gigue: 0.38 ms]
--> Débit: 1.18 Go/s (9.46 Gbps) [fluctuation: 0.13%]
[!] Le compteur "ReceivedDiscardedPackets" de l'interface réseau a été incrémenté de 2006 pendant le test.
Test TCP local (IPv6): téléchargement depuis la Freebox
--> Latence: 0.89 ms [gigue: 0.22 ms]
--> Débit: 1.16 Go/s (9.29 Gbps) [fluctuation: 0.97%]
[!] Le compteur "ReceivedDiscardedPackets" de l'interface réseau a été incrémenté de 2661 pendant le test.
Test TCP Internet (IPv4): téléchargement depuis le serveur Scaleway [BBR]
--> Latence: 7.95 ms [gigue: 0.46 ms]
--> Débit: 289.56 Mo/s (2.32 Gbps) [fluctuation: 3.14%]
[!] Le compteur "ReceivedDiscardedPackets" de l'interface réseau a été incrémenté de 28697 pendant le test.
Test TCP Internet (IPv6): téléchargement depuis le serveur Scaleway [BBR]
--> Latence: 7.73 ms [gigue: 0.39 ms]
--> Débit: 278.57 Mo/s (2.23 Gbps) [fluctuation: 3.51%]
[!] Le compteur "ReceivedDiscardedPackets" de l'interface réseau a été incrémenté de 38249 pendant le test.
-------------------------- 2025-03-01 10:54:39 +0100 --------------------------
------------------------------------------------------------------------------------------------------
[checkFtthFree v0.27] Windows 11 Build 26100 (64-bit)
-------------------------- 2025-03-01 11:01:30 +0100 --------------------------
Configuration réseau du système:
Adapter.Driver: ASUS XG-C100C 10G PCI-E Network Adapter
Adapter.DriverVersion: 2.2.2.0 (Marvell, 2020-04-30)
Adapter.EEE: Disabled
Adapter.FlowControl: Rx & Tx Enabled
Adapter.IPChecksumOffloadIPv4: Rx & Tx Enabled
Adapter.InterruptModeration: Enabled
Adapter.JumboPacket: Disabled
Adapter.LinkSpeed: 10 Gbps
Adapter.LsoV1IPv4: Enabled
Adapter.LsoV2: Enabled
Adapter.PcieLinkSpeed: 8.0 GT/s
Adapter.PcieLinkWidth: 4
Adapter.PhysicalMediaType: 802.3
Adapter.ReceiveBuffers: 512
Adapter.Rsc: Enabled
Adapter.TCPUDPChecksumOffload: Rx & Tx Enabled
Adapter.TransmitBuffers: 2048
NetProfile.NetworkCategory: Private
Tcp.AutoTuningLevelLocal: Normal
Tcp.CongestionProvider: CUBIC
Tcp.EcnCapability: Disabled
Tcp.ScalingHeuristics: Disabled
Tcp.Timestamps: Allowed
=> Latence max pour une réception TCP à 1 Gbps: 141 ms
Test TCP local (IPv4): téléchargement depuis la Freebox
--> Latence: 0.97 ms [gigue: 0.36 ms]
--> Débit: 1.16 Go/s (9.31 Gbps) [fluctuation: 0.11%]
Test TCP local (IPv6): téléchargement depuis la Freebox
--> Latence: 0.53 ms [gigue: 0.25 ms]
--> Débit: 1.11 Go/s (8.86 Gbps) [fluctuation: 4.96%]
Test TCP Internet (IPv4): téléchargement depuis le serveur Scaleway [BBR]
--> Latence: 8.08 ms [gigue: 0.74 ms]
--> Débit: 289.70 Mo/s (2.32 Gbps) [fluctuation: 5.09%]
Test TCP Internet (IPv6): téléchargement depuis le serveur Scaleway [BBR]
--> Latence: 8.04 ms [gigue: 0.39 ms]
--> Débit: 289.83 Mo/s (2.32 Gbps) [fluctuation: 2.76%]
-------------------------- 2025-03-01 11:02:32 +0100 --------------------------
-
D'après ton retour le problème de perf du test local en IPv6 ne semble pas toucher les autres modèles de Freebox.
Du coup je laisse comme ça, merci !
-
Est-ce que chez vous aussi le test local avec la Freebox est beaucoup plus lent en IPv6 qu'en IPv4 ?
De mémoire, c'est une limitation connue des Freebox Révolution et Mini 4k. Il me semble qu'il y a l'explication technique quelque part sur le forum mais je la retrouve pas.