La Fibre
Fournisseurs d'accès à Internet fixe en France métropolitaine => Free => 
Débits fibre Free => Discussion démarrée par: ouno le 17 novembre 2021 à 19:54:58
-
Bonsoir,
Ce midi un technicien est venu installer la fibre chez mes parents (migration ADSL --> fibre sur une Freebox Revolution inchangée).
Les débits vers Internet ont bien augmenté, mais plafonnent tout de même à environ 250 / 300 Mbps dans les 2 sens.
D'après ce que j'ai compris, les débits en FTTH chez Free devraient être bien au-dessus, même si ce n'est pas la dernière Freebox.
J'ai donc effectué quelques tests de débit afin de déterminer où ça coinçait. L'architecture est très basique:
PTO <--- fibre ---> ONU <--> Freebox Revolution <--- RJ45 ---> serveur de test
J'ai commencé par valider le lien 1Gbps RJ45 entre la Freebox et le serveur de test:
user@server:~$ curl -o /dev/null http://192.168.1.254:8095/fixed/1G
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 1024M 100 1024M 0 0 111M 0 0:00:09 0:00:09 --:--:-- 111M
On voit que cela monte bien à environ 111Mo/s, tout semble ok de ce côté.
J'ai donc enchainé avec un test de téléchargement depuis internet:
user@server:~$ curl -o /dev/null http://scaleway.testdebit.info/1G/1G.iso
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 953M 100 953M 0 0 28.9M 0 0:00:32 0:00:32 --:--:-- 29.7M
Là on voit que le débit est bien en-dessous, avec une moyenne à 29Mo/s.
Pourtant ce test de débit est réputé très fiable, d'ailleurs lorsque je fais le même test depuis ma propre connexion FTTH (chez Orange) je suis à 112Mo/s.
Du coup je me demande s'il n'y aurait pas un souci au niveau de la box ou de l'installation FTTH...
Merci à tous ceux qui prendront le temps de me lire et éventuellement éclairer ma lanterne !
P.S: J'ai fait tous les tests de débit plusieurs fois afin de m'assurer de la stabilité des résultats
-
Lors du test de débit, quel est l'utilisation des différents cœurs logiques CPU ?
Quel résultat en démarrage mode sans échec ?
-
Quel est le type de config du pc de test ? Anti virus ?
Jarretière fibre entre la box et pto avec connecteur bleu côté box (ONU) ?
-
https://lafibre.info/1gb-free/probleme-de-debit-30mos/msg897301/#msg897301 (https://lafibre.info/1gb-free/probleme-de-debit-30mos/msg897301/#msg897301)
Ce n'est pas ce problème dont il est question dans le lien ci-dessus ?
Parce que si c'est ça, en cherchant bien je pense que tu n'es pas le seul et qu'il doit y en avoir plein le forum. Mais les box révolution de doivent plus courir les rues en FTTH.
-
Hello,
Peux-tu tester avec un iperf3 avec -P4 (4 threads) et expliciter les tests IPv4 et IPv6 ?
-
Essaye en ENVOI (sans le -R) avec l'option "-C bbr". Normalement ça doit bien changer. A comparer avec la valeur par défaut "-C cubic" sur la plupart des distribs Linux. J'aimerai aussi savoir s'il y a des serveurs qui envoient en BBR.
-
J'aimerai aussi savoir s'il y a des serveurs qui envoient en BBR.
scaleway.testdebit.info est en BBR de mémoire.
Les débits sont constants toute la journée ? Il faudrait voir si c'est mieux tôt le matin notamment.
-
Test avec un ubuntu récent en live usb. Apparemment il n'y a pas l'algo bbr dans ton os.
Il y a 2-3 ans j'étais aussi limité à 200 Mbps en envoi par session tcp. Puis j'ai découvert qu'en bbr ça passait à fond. Puis passage 1 an chez orange (à fond tout le temps avec n'importe quel algo) , puis retour chez free avec du mieux (400 Mbps en cubic par défaut, le max en bbr). Et aujourd'hui toujours chez free c'est quasi max en cubic (et toujours mieux en bbr). Bref faut croire qu'il y a de l'upgrade progressivement.
-
Ça c'est bizarre mais ce n'est pas la première fois qu'on a ce genre de témoignages. Si le débit baisse en soirée, ça orienterait clairement sur une saturation locale du réseau de Free mais là je ne sais pas trop qu'en penser.
-
A savoir:
:~$ cat /proc/sys/net/ipv4/tcp_congestion_control
bbr
:~$ cat /proc/sys/net/ipv4/tcp_available_congestion_control
reno cubic bbr
Tu fais le echo qui va bien dans tcp_congestion_control si tu veux tester manuellement.
-
Après sur le NAS la puissance du processeur pourrait être limitante non ?
-
combien de fois , on va vous dire que l'ONU V2 bride les connections !!!!!!!!!!!!!!!!
(https://lafibre.info/index.php?action=dlattach;topic=47268.0;attach=103041;image)
c'est bien celui là comme boitier que tu as ?
voir mon post : https://lafibre.info/1gb-free/probleme-de-debit-30mos/ merci
-
Après je le répète mais j'ai eu le même genre de souci et le passage en bbr a tout changé ma fois. Et pourtant je ne passais pas par la freebox mais directement sur l'ONT v1.
-
Par ailleurs tout le monde n'a pas le problème, je suis sur un ONU v1 avec une Freebox Révolution et si j'ai eu des périodes problématiques ce n'est plus le cas aujourd'hui.
-
Par ailleurs tout le monde n'a pas le problème, je suis sur un ONU v1 avec une Freebox Révolution et si j'ai eu des périodes problématiques ce n'est plus le cas aujourd'hui.
+1 (j'ai plus de problème aujourd'hui)
-
J'aurais tendance à mettre les problèmes de débit sur des saturations mais va savoir...
-
Oui c'est bizarre...
-
Oui c'est bizarre...
[Humour foireux...]
D'une manière générale, on peut constater la super efficacité de l'ONU... Alors, pourquoi est-ce que ceux de Free dérogeraient à la règle, je vous le demande? ;)
Désolé pour ce sourire (torve?) au Xème degré en ce début de week-end...
[/Humour foireux...]
-
J'en profite pour poser une question: est-ce que c'est normal d'avoir un ping qui prend +15ms dès le premier hop avec le FTTH de Free, ou bien c'est aussi un effet de bord de l'ONU ?
Quand je compare le ping sur www.free.fr depuis ma connexion FTTH Orange (Rennes) et depuis la connexion FTTH Free de mes parents (Nantes) on passe quasiment du simple au double:
Orange:
user@ftth_orange_rennes:~$ ping www.free.fr
PING www.free.fr (212.27.48.10) 56(84) bytes of data.
[...]
--- www.free.fr ping statistics ---
10 packets transmitted, 10 received, 0% packet loss
rtt min/avg/max/mdev = 7.797/7.962/8.352/0.209 ms
Free:
user@ftth_free_nantes:~$ ping www.free.fr
PING www.free.fr (212.27.48.10) 56(84) bytes of data.
[...]
--- www.free.fr ping statistics ---
10 packets transmitted, 10 received, 0% packet loss
rtt min/avg/max/mdev = 14.967/15.799/19.349/1.201 ms
Il suffit de passer par "le chemin des écoliers" pour l'un, et pas pour l'autre pour qu'il y ait cette différence...
J'ai déjà vu à certaines occasion le signal entre Nantes et Paris "intra-Free" faire le tour via Bordeaux -Toulouse et Marseille pour remonter sur Päris. Cela arrive rarement, mais cela arrive! C'est toute la problématique du réseau Free qui n'est pas du tout maillé, et si un itinéraire direct coince pour une raison ou pour une autre, on "fait le tour" de la France!
-
J'en profite pour poser une question: est-ce que c'est normal d'avoir un ping qui prend +15ms dès le premier hop avec le FTTH de Free, ou bien c'est aussi un effet de bord de l'ONU ?
Quand je compare le ping sur www.free.fr depuis ma connexion FTTH Orange (Rennes) et depuis la connexion FTTH Free de mes parents (Nantes) on passe quasiment du simple au double:
Orange:
user@ftth_orange_rennes:~$ ping www.free.fr
PING www.free.fr (212.27.48.10) 56(84) bytes of data.
[...]
--- www.free.fr ping statistics ---
10 packets transmitted, 10 received, 0% packet loss
rtt min/avg/max/mdev = 7.797/7.962/8.352/0.209 ms
Free:
user@ftth_free_nantes:~$ ping www.free.fr
PING www.free.fr (212.27.48.10) 56(84) bytes of data.
[...]
--- www.free.fr ping statistics ---
10 packets transmitted, 10 received, 0% packet loss
rtt min/avg/max/mdev = 14.967/15.799/19.349/1.201 ms
C'est normal en ipv4 car c'est tunnelisé a Paris. Donc 15ms montre simplement votre éloignement avec la capitale.
En ipv6 le premier saut est plus proche mais ça ne représente pas nécessairement une meilleure qualité, ça revient au même.
-
Il suffit que le chemin soit moins direct chez Free pour expliquer la différence mais avec le tunnel en IPv4, l'absence de reverse dns en IPv6 (sans parler de l'utilisation possible de SRv6) il est devenu très difficile de comprendre par où passe le trafic. :(
-
Vous vous focalisez tous sur l’ONU, mais c’est à priori un équipement L2, donc tout ce qu’il voit c’est des trames Ethernet, qu’il y ait de l’IP à l’intérieur ou même un autre protocole il ne le voit même pas. Et du coup il voit encore moins si c’est du TCP ou de l’UDP encapsulé dans de l’IP.
Pour moi clairement, Free fait du trafic shaping sur son réseau sur les sessions TCP sur certains de ses routeurs (sans doute en fonction de leur charge).
-
Vous vous focalisez tous sur l’ONU, mais c’est à priori un équipement L2, donc tout ce qu’il voit c’est des trames Ethernet, qu’il y ait de l’IP à l’intérieur ou même un autre protocole il ne le voit même pas. Et du coup il voit encore moins si c’est du TCP ou de l’UDP encapsulé dans de l’IP.
Pour moi clairement, Free fait du trafic shaping sur son réseau sur les sessions TCP sur certains de ses routeurs (sans doute en fonction de leur charge).
Si l'on est optimiste, une montée en gamme du matos et/ou de la liaison en question sera réalisée tôt ou tard. C'est ce qui pourrait expliquer la disparition des problèmes, au bout d'un "certain temps"...
La technique de Free sur ses capacités réseau serait non pas du "Just in Time", mais du "Afterwards"... Ce qui explique aussi la notation "très mitigée" des pros du réseau qui interviennent ici sur le réseau Free! ;) ;) ;)
-
Juste une info...
Cet après-midi, j'étais chez un freenaute avec une Freebox Revo (R2) avec fibre et ONU V1...
L'Appli Speedtest en liaison Ethernet donne 882Mb en Down et 668Mb en Up...
La fibre est en service depuis 18 mois...
-
Juste une info...
Cet après-midi, j'étais chez un freenaute avec une Freebox Revo (R2) avec fibre et ONU V1...
L'Appli Speedtest en liaison Ethernet donne 882Mb en Down et 668Mb en Up...
La fibre est en service depuis 18 mois...
C'est ce que j'avais à l'époque où j'avais encore une révolution R1 avec ONU v1 (up moins élevé vu que c'était encore 600 méga à ce moment là) avant de passer à la Delta.
-
Vous vous focalisez tous sur l’ONU, mais c’est à priori un équipement L2, donc tout ce qu’il voit c’est des trames Ethernet, qu’il y ait de l’IP à l’intérieur ou même un autre protocole il ne le voit même pas. Et du coup il voit encore moins si c’est du TCP ou de l’UDP encapsulé dans de l’IP.
Pour moi clairement, Free fait du trafic shaping sur son réseau sur les sessions TCP sur certains de ses routeurs (sans doute en fonction de leur charge).
Très très peu probable, car ceux qui avaient le problème et sont passés en Freebox Pop ne l'avaient plus! Il faudrait une sacrée coïncidence pour que Free ait upgradé les équipements juste au moment où la Pop a été mise en service...
Je miserais plutôt sur certaines séries d'ONU V2 avec des soucis d'électronique, avec des chips "essoufflés"...
-
Pour ma part c'est un ONU V1...
Et là, c'est le drame ::)
-
Pour ma part c'est un ONU V1...
Cela invaliderait donc les dires des hystériques de la gâchette qui mettent les ONU V2 au pilori... ;)
On verra cela à la fin de la semaine, quand mon raccordement sera effectif, avec je pense un ONU V2 avec ma Fbx V6 R2...
Accessoirement, on peut éventuellement en revenir à un paramétrage "polynésien" (à lagon!) des bécanes de test.
Pour le petit test que j'ai fait cet après-midi, c'est simple: Application Speedtest sur l'ordi, qui m'a trouvé un serveur sur Lausanne, et vogue la galère!
Les BBR et autres douceurs des coupeurs d'octets en 24 (!), cela finit par friser la proctologie sur hyménoptère... (Restons politiquement corrects!) ;) ;) ;)
-
Sinon plus sérieusement en discutant au boulot avec des gars développant de l'asic, paraîtrait que la stratégie consistant à droper tout les paquets une fois la fifo pleine est une vieille stratégie qui ne fonctionne pas top avec tcp. Depuis les contrôleurs ethernet sont capables de droper 1 paquet de temps en temps à partir d'une certaine limite, ce qui semble mieux accepté.
Vu l'âge des ONU avec leur même chipset BCM55030, possible que le passage du 8Gbps vers 1Gbps se passe avec pertes et fracas et que l'algo TCP cubic n'aime vraiment pas ma perte de plusieurs paquets consécutifs (contre un paquet de temps en temps, de plus en plus souvent). Et que le passage sur delta/pop le passage 8Gbps vers 1Gbps se fasse par un algo soft au niveau CPU (un linux plus intelligent) et du coup un drop de temps en temps plutôt que dropper pleins de paquets d'un coup.
-
Personnellement j'imagine plutôt un problème qui touche une série d'un des composants utilisés dans la fabrication des ONU (SFP, chipset ?), que ce soit les derniers ONU v1 fabriqués ou les ONU v2.
En fait je demandais juste si tu lançais plusieurs flux en parallèle lors de ton test ou pas, rien à voir avec une configuration exotique de ta pile réseau.
Etant donné que le problème de base se traduit par un débit limité pour chaque connexion TCP, un test ne sert pas à grand chose s'il est réalisé avec plusieurs connexions en parallèle.
Et si je demande cela c'est parce que j'ai remarqué que le client léger est configuré en multi-connexions par défaut (je ne sais pas ce que fait le client lourd par défaut):
Je pourrai répondre dans quelques jours, les tests de type Speedtest en client léger n'ont pas été fait chez moi...
Lorsque je vais être raccordé, je ne manquerai pas de faire des tests de download (donc en simple flux) depuis les sites qui vont bien.
Si je constate ce genre d'anomalie, passage à une box sans ONU, je ne manquerai pas de faire les mêmes tests de download avec l'ancienne box, puis avec la nouvelle dans la même journée, cela devrait logiquement trouver une réponse aux interrogations qui sont "en vol"...
Dans un cas comme dans l'autre, je viendrai poster les résultats ici.
Bonne journée à toutes et à tous!
-
Oh. Un problème équivalent de passage de 10G à 1G. Traffic policing configuré comme simple queue et drop -> 250Mbps par session TCP (alors que le serveur est à 10G).
https://community.cisco.com/t5/switching/performance-issue-10gb-s-to-1gb-s-6880-x-6800-ia-15-2-1-sy0a/td-p/2619050
-
Oh. Un problème équivalent de passage de 10G à 1G. Traffic policing configuré comme simple queue et drop -> 250Mbps par session TCP (alors que le serveur est à 10G).
https://community.cisco.com/t5/switching/performance-issue-10gb-s-to-1gb-s-6880-x-6800-ia-15-2-1-sy0a/td-p/2619050
Kika récupéré le code de Cisco pour le goinfrer dans les ONU? Muuuhhh??? ;)
-
Oui je parlais du test que tu venais de faire chez un freenaute avec une Freebox Revo (R2) avec fibre et ONU V1.
En fait il faudrait juste savoir quelle est la conf par défaut du client lourd Speedtest, si c'est la même que le client léger (multi-connexion) alors on ne peut rien déduire du résultat.
Super, merci bonne journée à toi!
Je viens d'être fibré (Techos parti à 19h15...).
J'ai fait quelques tests sur Mon Windows 10 / 64 et ma Revo avec son Onu V2:
Speedtest appli légère:
Bouygues Meudon:
Down: 863Mb/s, Up: 367Mb/s, Latence: 12ms
Orange Puteaux:
Down: 74Mb/s (!!!), Up: 687Mb/s, Latence: 12ms
Test avec un simple download HTTP d'un fichier de 10Gb depuis Scaleway.testdebit.info: 10 Gb à la vitesse moyenne de 340Mb/s
Voilà les données du soir...
Bonne soirée
-
Tests de ce matin... Avec toutes les réserves que l'on peut faire sur un Speedtest dans un navigateur...
Tests réalisés à 2mn d'intervalle, sur le serveur qui offrait à cette heure les meilleurs résultats, à savoir lafibre.info à Massy.
Ce que je peux dire est que dans la même tanche horaire, les tests vont de "satisfaisant" à "passable"...
En passant, selon Nperf, mon adresse IP est localisée à Poissy. Ce doit être la rançon de la localisation par IPV4!
-
Cela est tout à fait dans la fourchette de valeurs que l'on a lorsqu'on est touché par le bug limitant le débit par connexion TCP, hormis l'upload qui est quand même un peu au-dessus en général (comparable au download).
Même pour ces tests, je suis extrêmement prudent sur l’interprétation, car pour avoir fait une série de test sur différents serveurs hier soir et ce matin de bonne heure, les résultats peuvent être qualifiés de "folkloriques", car variant du simple au quadruple, aussi bien en Down qu'en UP.
La seule vérité est effectivement le service rendu...
Là, en dehors d'utilisations qui se rapprochent beaucoup du professionnel, les besoins n'ont pas exagérément grimpé vers le giga... J'inclus dans ce type d'utilisation le télé-travail (pas taper!) et l'hébergement de services avec des sauvegardes dans le cloud...
Il est clair que si d'avenir, j'ai des besoins qui dépassent ces valeurs, je passerai à une box autre, avec beaucoup de retenue, la Révo restant la box la plus polyvalente et la mieux réussie à ce niveau de prix!
-
Hmm, 270 Mbps en BBR un samedi, c'est vraiment étrange quand même...
Tu obtiens quoi si tu fais un curl/wget/nspeed (mono-connexion) sur http://bouygues.testdebit.info/1G.iso et http://paris.testdebit.info/1G.iso ?
-
Hmm, 270 Mbps en BBR un samedi, c'est vraiment étrange quand même...
Tu obtiens quoi si tu fais un curl/wget/nspeed (mono-connexion) sur http://bouygues.testdebit.info/1G.iso et http://paris.testdebit.info/1G.iso ?
Je ne vais pas investiguer beaucoup plus, en sachant que quoi que l'on constate, et s'il existe vraiment un "loup", je crains que rien ne soit jamais fait par l'opérateur, pour des box soit d'entrée de gamme ou vieillissantes, vu que la solution est toute trouvée: passer à une autre box, sans ONU...
Avec un peu de recul, c'est quelque part une façon comme une autre de pousser les abonnés à "autre chose", s'il en ont vraiment le besoin!
M'enfin, ce n'est que mon humble avis, hein! ;)
-
Euh, j'ai une Révolution avec un ONU v1 et je n'observe pas le même comportement que toi. Après je peux comprendre que ça ne t'intéresse pas de creuser plus que ça.
-
Euh, j'ai une Révolution avec un ONU v1 et je n'observe pas le même comportement que toi. Après je peux comprendre que ça ne t'intéresse pas de creuser plus que ça.
Je sais, mon beau-fère a une revo avec un ONU V1, et n'a pas apparemment ce souci.
Le tout est de savoir si Free fera quelque chose! Et là, connaissant la gestion de la maison à base de porte monnaie en peau de hérisson retournée, j'ai comme un doute!
Je suis peut-être déformé par plus de 20 ans de Free, quelque part, en ayant toujours fait la part des choses et en ayant toujours apprécié à sa juste valeur ce qu'a apporté cet opérateur dans le monde ex-tranquille des télécoms hexagonales... ;)
-
Fais le test en mode sans échec, ton matos est peut-être limite.
Monitore aussi ton CPU pendant le test de débit (boot normal et en mode sans échec): tu verras peut-être une différence notable.
Pour rappel:
https://www.youtube.com/watch?v=hnpx8jnRhOM
-
Je confirme le problème avec une Freebox Revolution R2 et un ONU v2, les débits testés avec iPerf3 plafonnent souvent à ~260Mbps.
iperf3 -6 -c paris.testdebit.info -p9238 -P1 -R
Connecting to host paris.testdebit.info, port 9238
Reverse mode, remote host paris.testdebit.info is sending
[ 5] local 2a01:e0a::1 port 57122 connected to 2001:860:de01:1101::2 port 9238
[ ID] Interval Transfer Bitrate
[ 5] 0.00-1.00 sec 30.8 MBytes 258 Mbits/sec
[ 5] 1.00-2.00 sec 31.0 MBytes 260 Mbits/sec
[ 5] 2.00-3.00 sec 30.7 MBytes 258 Mbits/sec
[ 5] 3.00-4.00 sec 31.2 MBytes 262 Mbits/sec
[ 5] 4.00-5.00 sec 31.3 MBytes 263 Mbits/sec
[ 5] 5.00-6.00 sec 31.0 MBytes 260 Mbits/sec
[ 5] 6.00-7.00 sec 31.4 MBytes 263 Mbits/sec
[ 5] 7.00-8.00 sec 30.9 MBytes 259 Mbits/sec
[ 5] 8.00-9.00 sec 31.6 MBytes 265 Mbits/sec
[ 5] 9.00-10.00 sec 31.3 MBytes 263 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.06 sec 314 MBytes 262 Mbits/sec 33131 sender
[ 5] 0.00-10.00 sec 311 MBytes 261 Mbits/sec receiver
iperf Done.
Par contre j'ai remarqué que parfois les débits montaient à ~900Mbps, ce qui est déjà beaucoup mieux :
iperf3 -6 -c paris.testdebit.info -p9238 -P1 -R
Connecting to host paris.testdebit.info, port 9238
Reverse mode, remote host paris.testdebit.info is sending
[ 5] local 2a01:e0a::1 port 45490 connected to 2001:860:de01:1101::2 port 9238
[ ID] Interval Transfer Bitrate
[ 5] 0.00-1.00 sec 106 MBytes 889 Mbits/sec
[ 5] 1.00-2.00 sec 108 MBytes 908 Mbits/sec
[ 5] 2.00-3.00 sec 109 MBytes 917 Mbits/sec
[ 5] 3.00-4.00 sec 107 MBytes 900 Mbits/sec
[ 5] 4.00-5.00 sec 109 MBytes 912 Mbits/sec
[ 5] 5.00-6.00 sec 109 MBytes 914 Mbits/sec
[ 5] 6.00-7.00 sec 109 MBytes 915 Mbits/sec
[ 5] 7.00-8.00 sec 109 MBytes 918 Mbits/sec
[ 5] 8.00-9.00 sec 109 MBytes 914 Mbits/sec
[ 5] 9.00-10.00 sec 109 MBytes 911 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.07 sec 1.07 GBytes 913 Mbits/sec 16407 sender
[ 5] 0.00-10.00 sec 1.06 GBytes 910 Mbits/sec receiver
iperf Done.
Les deux tests ci-dessus ont été faits à moins de 3 minutes d'interval dans exactement les mêmes conditions.
Ça ressemble à une réduction de performances (throttling) de l'ONU probablement due à l'échauffement. Je testerai en déportant l'ONU qui est actuellement posé sur le Freebox Server dans un meuble (donc oui, ça chauffe). L'étape suivante consistera à carrément ouvrir le boitier de l'ONU pour favoriser la dissipation thermique.
-
L'ONU, même "à jeun" a ce comportement... Pas besoin qu'il chauffe, le mien est à la distance max de la box (autant que le permet le DAC qui fait la liaison!). Et il n'a pas de "vapeurs" particulières! ;) ;) ;)
-
Qu'est-ce qui expliquerait alors que parfois ça monte à 900Mbps ?
-
Qu'est-ce qui expliquerait alors que parfois ça monte à 900Mbps ?
Cela ne monte jamais à 900 Mégas avec une unique connexion TCP... Lorsqu'un speedtest est fait par défaut, c'est en multi-connexions...
Si tu fais 3 ou 4 downloads en simultané, tu peux monter à plus de 900Mégas...
-
Bonjour à tous !
Puis-je vous demander un avis sur les débits constatés sur une ligne fibre Free récemment installée (Fbx révolution + boitier fibre) ?
Je suis étonné par le débit généralement constaté en téléchargement quotidien (2 ou 3 Mo/s), alors que des débits corrects sont tout à fait atteignables :
1. Torrent (installateur Ubuntu)
- Client QTorrent Windows : 65 Mo/s (OK)
- Client intégré Freebox : 6 Mo/s (....)
2. testdebit.info (Firefox)
- env. 450 Mbits/s up/down (OK)
- fichier 1G indépendants : 3 ou 4 Mo/s max, SAUF le serveur Appliwave 40Gbits/s, ou j'obtiens env. 40 Mo/s
Des débits satisfaisants sont donc tout à fait atteignables avec le navigateur.
Comment se fait-il que je n'atteigne jamais plus de 2 ou 3 Mo/s sur tous les autres fichiers que je peux tenter, ISO Windows depuis leur site, ISO de toutes les distrib linux auxquelles j'ai pu penser, et autres téléchargements quotidiens? Est-ce que ce sont les débits constatés en navigation générale par tout le monde ?
Merci pour votre avis éclairé !
-
La Freebox Révolution n'est pas très puissante et n'a pas un disque dur très rapide donc pour cette partie ce n'est pas vraiment étonnant.
Pour ce qui concerne ta machine, pourrais-tu tester avec l'outil checkBugOnuFree (https://github.com/oounoo/checkBugOnuFree/releases/latest/download/checkBugOnuFree.exe) (cf. ce sujet (https://lafibre.info/1gb-free/freebox-v6-onu-recent-gt-30-mos-max-par-session-tcp/msg908515/#msg908515)) ?
-
Alors ça c'est intéressant, il y aurait donc un cas de Freebox v6 + ONU v2 qui arriverait à faire plus de 30Mo/s en mono-session TCP...
piwi, est-ce que tu aurais la possibilité de lancer le script de diag checkBugOnuFree sur ton système ?
Salut ouno,
Désolé pour la réponse tardive, j'ai fait 3 tests depuis la même machine avec checkBugOnuFree.pl, voici les résultats :
$ ./checkBugOnuFree.pl -bILU
[checkBugOnuFree v0.9] Linux 4.4.59+ (x86_64)
--------------------------- 2021-12-28 13:40:46 GMT ---------------------------
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: 189882 253177 379764
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
Test TCP Internet (AS12876-BBR)...
--> Latence: 2.74 ms
--> Débit: 31.13 Mio/s (249.00 Mibps)
Test TCP Internet (AS12876-CUBIC)...
--> Latence: 3.15 ms
--> Débit: 8.62 Mio/s (68.97 Mibps)
--------------------------- 2021-12-28 13:41:34 GMT ---------------------------
$ ./checkBugOnuFree.pl -bILU
[checkBugOnuFree v0.9] Linux 4.4.59+ (x86_64)
--------------------------- 2021-12-28 14:40:15 GMT ---------------------------
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: 189882 253177 379764
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
Test TCP Internet (AS12876-BBR)...
--> Latence: 3.27 ms
--> Débit: 55.92 Mio/s (447.33 Mibps)
Test TCP Internet (AS12876-CUBIC)...
--> Latence: 2.54 ms
--> Débit: 8.57 Mio/s (68.56 Mibps)
--------------------------- 2021-12-28 14:41:03 GMT ---------------------------
./checkBugOnuFree.pl -bILU
[checkBugOnuFree v0.9] Linux 4.4.59+ (x86_64)
--------------------------- 2021-12-28 14:41:35 GMT ---------------------------
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: 189882 253177 379764
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
Test TCP Internet (AS12876-BBR)...
--> Latence: 2.90 ms
--> Débit: 106.28 Mio/s (850.23 Mibps)
Test TCP Internet (AS12876-CUBIC)...
--> Latence: 3.08 ms
--> Débit: 8.68 Mio/s (69.44 Mibps)
--------------------------- 2021-12-28 14:42:23 GMT ---------------------------
Malgré l'ONU v2, il arrive que les débits montent quasiment au maximum.
-
Effectivement c'est curieux, c'est bien ce modèle que tu as ?
Oui, c'est bien celui-là.
Cet ONU v2 a été installé récemment ?
Il a été installé début décembre.
Tu as désactivé le test local donc je ne peux pas en être sûr juste en lisant les résultats, mais je suppose que toute la puissance CPU de ton système était disponible au moment de tes différents tests ?
Le processeur est une brouette sans roue (Intel Atom, oui monsieur). Il n'y a pas besoin d'un monstre pour atteindre 1Gbps.
-
Sympa ces graphs ouno ;)
D'un côté tu as une relation de débauche et tromperie avec MST à la clé.
De l'autre c'est la relation parfaite où les 2 ne vont pas voir ailleurs car ils se comblent mutuellement jusqu'à la fin des temps.
-
Au final, aux heures où ils utilisent la connexion, on peut pas dire qu'ils ont des performances vraiment meilleures que quand ils avaient l'ADSL (à part quand ils ont la chance de tomber sur un serveur qui utilise l'algo BBR peut-être ::) ).
Pourtant, ça représente la majeure partie des usages des utilisateurs, selon Free.
[Free] ajoute que son réseau « a été optimisé pour un usage à plusieurs connexions (multithread), cas d’usage des abonnés mobiles » et cite « les services comme Wetransfer, iCloud, Netflix ou Youtube et quasiment tous les sites web dont celui de http://arcep.fr utilisent entre 2 et 200 connexions TCP associées à 1 à 10 connexions UDP QUIC pour le contenu vidéo ».
[...]
L'opérateur termine en indiquant que « le protocole de mesure de l'ARCEP ne reflète pas les usages réels des abonnés mobile et les débits des abonnés Free Mobile. Les prochaines campagnes de test devront évoluer pour être plus proches des réalités terrain ». Espérons également que l'entreprise prendra le temps d'indiquer sur ses cartes de couverture quels sont les débits auxquels ses clients peuvent prétendre, zone par zone.
https://www.nextinpact.com/lebrief/48940/debits-5g-pour-free-mobile-probleme-cest-protocole-mesure-arcep
Les commentaires sont également savoureux :
Non. S'il y a une différence, c'est qu'il y a des pertes de paquets, et Cubic croit que c'est à cause de la congestion, alors que non, les pertes sont dues à la radio.
Free relie peut-être ses NROs à son coeur en 5G ? 8)
-
Euh, tout ce que tu cites concerne les abonnés mobiles et non FTTH, je crois que c'est HS là ?
Cela concerne surtout BBR vs Cubic, qui semble impacter les réseaux fixes et mobiles de l'opérateur.
-
Euh, tout ce que tu cites concerne les abonnés mobiles et non FTTH, je crois que c'est HS là ?
Oui mais on observe les mêmes problèmes sur le réseau fixe. Alors que beaucoup pensaient que c'était limité au réseau mobile (saturation radio pourquoi pas), ça semble plus global.
Sachant que Free et Free Mobile ont une énorme partie d'architecture réseau en commun.
-
Cela concerne surtout BBR vs Cubic, qui semble impacter les réseaux fixes et mobiles de l'opérateur.
Et encore, même dans certaines zones, il n'y a quasiment pas de différence entre BBR et cubic sur le mobile (comme sur le fixe).
-
Oui je comprends bien, mais par exemple quand tu dis "Pourtant, ça représente la majeure partie des usages des utilisateurs, selon Free.", en citant un article où Free ne parle que du cas d'usage des abonnés mobiles, j'ai du mal à voir le lien avec le cas d'usage en FTTH.
Les cas d'usages, dont parle Free, c'est tous les grands services, comme YouTube, iCloud, Netflix les réseaux sociaux ... (cf la citation)
Ils ne le précisent pas, mais c'est pas spécifique au mobile, les gens accèdent autant à ces services sur le wifi chez eux, que sur le réseau cellulaire.
Free ne se justifie pas de ces mêmes problématiques côté FTTH, car l'ARCEP ne s'y intéresse tout simplement pas.
-
Moi ce que je lis c'est ceci:
Ensuite sont cités des services majeurs considérés par Free, qui se trouvent effectivement être tous implémentés en multi-session.
Mais cela n'indique pas pour autant que Free considère aussi le cas d'usage FTTH comme systématiquement multi-session.
C'est bien dommage si c'est le cas.
Ce que j'indique, c'est que le cas d'usages mobile considérés par Free, sont également présents sur le fixe.
[...] « les services comme Wetransfer, iCloud, Netflix ou Youtube et quasiment tous les sites web [...]
Free ne l'indique pas (puisqu'on ne lui a pas posé la question), mais en étant réaliste, on peut tout à fait deviner que le trafic correspondant à Netflix et Youtube soit supérieur sur le fixe, que sur le mobile. C'est simplement du bon sens.