La Fibre
Fournisseurs d'accès à Internet fixe en France métropolitaine => Free => 
Débits fibre Free => Discussion démarrée par: ouno le 02 décembre 2021 à 22:04:26
-
Bonjour,
EDIT: un correctif a été déployé le 31/03/2022 pour régler le problème, qui semble effectivement résolu d'après les premiers retours. Le reste de ce fil de discussion est donc obsolète.
Il existe manifestement un problème qui touche beaucoup de personnes en FTTH utilisant une Freebox v6 (Révolution ou Mini 4k) avec un boîtier ONU v2.
Le symptôme principal est la limitation systématique du débit pour chaque connexion TCP à environ 30Mo/s, quelle que soit l'heure.
A noter que le protocole UDP est beaucoup moins impacté, ce qui permet par exemple d'avoir des débits normaux lorsqu'on passe par un VPN (basé sur UDP).
A noter aussi que lorsqu'on utilise plusieurs connexions TCP en parallèle, les débits s'additionnent quasiment, ce qui permet d'obternir un débit normal (à 1Gbps) à partir de 4 connexions environ.
Quelques témoignages parmi beaucoup d'autres, rien que sur ce forum:
- BRAINSHOOTZ: Probleme de debit 30mo/s (https://lafibre.info/1gb-free/probleme-de-debit-30mos/)
- Minoru: Débit très faible après déménagement (https://lafibre.info/1gb-free/debit-tres-faible-apres-demenagement/msg906775/#msg906775)
- rphx (https://lafibre.info/1gb-free/debit-tres-faible-apres-demenagement/msg907327/#msg907327)
Mais on en trouve aussi ailleurs, par exemple:
- rapport de bug sur Dev Freebox: FS#35674 - Bridé a 30Mo/s mono connexion (https://dev.freebox.fr/bugs/task/35674)
- fil de discussion sur TooSurToo Freebox: Free 1 Gb - Téléchargement bloqué à 30 Mo/s (https://freebox.toosurtoo.com/forum/viewtopic.php?t=26219)
De plus je pense que beaucoup de personnes sont impactées mais ne s'en rendent pas forcément compte: soit elles n'ont pas réellement besoin de ce débit et ne se préoccupent pas de tester leur connexion tant que cela fonctionne suffisamment bien pour elles (ce qui est tout à fait compréhensible), soit les applications TCP qu'elles emploient (aussi bien pour leurs usages classiques que pour leurs tests de connexion) utilisent plusieurs connexions en parallèle, ce qui masque le problème.
D'après les retours de différentes personnes impactées:
- changer de Freebox en restant sur le même modèle avec boîtier ONU ne résout pas le problème
- changer de modèle de Freebox pour passer sur un modèle qui ne nécessite pas de boîtier ONU résout le problème
- déménager avec un changement de boîtier ONU peut faire venir le problème alors qu'on n'était pas touché jusqu'à présent
- échanger le boîtier ONU v2 par un boîtier ONU v1 fait disparaître le problème (il faut pour cela être très insistant auprès du support pour qu'ils acceptent de faire venir un technicien pour réaliser l'opération)
Tout cela fait un peu penser à un problème de gestion de la congestion lorsque certaines versions d'ONU sont utilisées, avec une perte de paquets supérieure à celle qui serait attendue.
Comme le fait remarquer Fuli10 ici (https://lafibre.info/1gb-free/debits-ftth-faibles-freebox-revolution/msg904781/#msg904781), peut-être un problème de ce type (https://community.cisco.com/t5/switching/performance-issue-10gb-s-to-1gb-s-6880-x-6800-ia-15-2-1-sy0a/td-p/2619050) par exemple ?
Malheureusement il semble très compliqué d'avoir un retour officiel sur ce sujet, ou même une confirmation de la bonne prise en compte du problème...
-
Et un test en BBR ?
-
Et un test en BBR ?
scaleway.testdebit.info est en BBR.
Est-ce que les tests sont en IPv4 ou en IPv6 ? Une différence possible serait la sortie du tunnel IPv4 qui n'est plus la même suite au changement d'IP.
-
Salut
Actuellement chez sosh avec un débit de 300/300 avec un routeur asus. C'est suffisant pour mon utilisation de tous les jours mais j'ai pris l'offre à 9.99 € de la Freebox pour l’offre TV. On est 4 à la maison avec 2 ados qui sont de gros consommateurs de bande passante.
Je me dis si j’ai du 300 mini cela ne me dérange pas cependant en dessous risque d’être problématique pour moi avec les 2 gamers de l’étage.
Ma question est la suivante, si j’installe un VPN en UCP sur l’asus et je fais passer les datas par celui-ci. J’aurai un débit normal limité par le fournisseur du vpn bien sur ou je me trompe.
Ou le plus sage est la prudence et d’envoyer une lettre en A/R ?
Merci de vous retours
-
merci pour ce retour rapide.
-
En ce qui concerne le problème dont il est question ici, la limite de débit est appliquée pour chaque connexion TCP indépendamment, donc cela ne va pas vous pénaliser du tout que vous ayez d'autres personnes qui utilisent la ligne.
Au contraire, cela va masquer un peu le problème en augmentant le nombre de connexions TCP simultanées.
Bref, on va dire que plus il y a d'utilisateurs sur la ligne, moins le problème est perceptible. Aucun intérêt pour vous d'annuler le passage chez Free si 250 Mbps max pour chaque connexion TCP vous convient.
Un truc qui finit par me chagriner avec ce fameux ONU...
Comment est-ce qu'il fonctionne?
Est-ce un simple transfert de flux binaire entre 2 médias SFP+ 10G d'un côté et SFP 1G de l'autre, ou est-ce que tout est décapsulé dans l'ONU et réencapsulé entre les 2 médias en gérant séparément TCP et UDP (et/ou autres?)?
Si on est dans le second cas, le problème est vraiment au niveau de l'ONU, mais si on est dans le premier cas, le problème est au niveau du firmware de la box, avec éventuellement une limitation voulue. depuis une certaine version de Firmware...
Si un "sachant" peut m'éclairer là dessus...
Dès que j'aurai le temps, je me déplacerai pour aller sur une box V6 R2 qui est sur un ONU V1 depuis Juin 2020...
-
Je ne vois pas pourquoi un ONU irait gérer de la couche 4, pas du tout son rôle.
Qu'il ait un problème de conception et que ça impacte un certain type de trafic, peut-être possible.
-
Le problème est plus dans la "façon de perdre des paquets" et son impact sur tcp.
L'algorithme de congestion de tcp réagit en fonction du nombre de paquet perdu dans le temps pour forcer l'emetteur à emetre des paquets plus ou moins rapidement afin d'éviter d'avantage de pertes de paquets.
Par exemple si le serveur émet 100Ko en 1ms et que le récepteur annonce avoir reçu 1/10 ème des paquets, n'importe quel algorithme de TCP va ajuster le débit pour envoyer 10Ko en 1ms, et en fonction du retour du récepteur cela devrait rester dans ces débits là.
Le problème c'est qu'il y a "perte de paquets" et "perte de paquets". Avec la bonne "perte de paquets", l'algorithme TCP detecte la perte et ajuste le débit, alors qu'avec la mauvaise "perte de paquets", l'algorithme detecte la perte et ajuste le débit. Sauf qu'avec la mauvaise perte de paquets et le mauvais algorithme, l'ajustement est trop fort et me débit est fortement réduit.
Apparemment suivant les algorithmes de congestion, certains sont plus ou moins sensibles à ces pertes. Le problème c'est qu'entre comment est géré la transition 8Gb->1Gb dans certains ONU, et les algorithmes TCP cubic (majoritaire, y compris sous windows), ça marche pas top.
UDP n'ayant pas d'algorithmique de congestion (sauf home made), le débit sera toujours maximum.
-
Pour UDP, bien sûr qu'il ne faut pas regarder la vitesse d'envoi sinon elle sera toujours max, il faut comparer la quantité envoyée et reçue en face. Iperf sait faire ça par exemple. Et dans mes souvenirs des tests publiés ici, UDP ne souffrait pas d'autant de problème, donc pas sûr que la perte explique tout.
-
C'est ce que veut dire Fuli, UDP continue à envoyer sans se poser de question donc le débit reçu (et non envoyé qui n'a pas de sens) n'est pas impacté par d'éventuels problèmes de gestion des buffers.
-
Concernant les tests UDP, ce sont bien sûr les débits effectifs côté destinataire qui ont été pris en compte à chaque fois.
Cf par exemple les résultats des tests UDP ici (https://lafibre.info/1gb-free/freebox-v6-onu-recent-gt-30-mos-max-par-session-tcp/msg907352/#msg907352) (section "3. Pour aller plus loin"), où les débits de chaque côté sont indiqués dans les résultats de commande et seul le débit côté destinataire est pris en compte dans le calcul du débit effectif.
Bonjour,
Doute levé! J'ai pu réaliser ce matin un speedtest depuis la machine en question, une V6 R2 avec ONU V1, en mono thread sur le serveur Bouygues de Meudon...
Le résultat est sans appel:
Les 2 machines sont à 35km de distance... ET passent toutes 2 par le même backbone Free (Montbéliard)...
Alors que depuis chez moi, avec une V6 R2 et ONU V2, débit limité au grand max 275Mbits depuis le navigateur...
-
Je suis pas sûr de comprendre, c'est la même ligne ? Si non, alors on le savait déjà...
-
Je suis pas sûr de comprendre, c'est la même ligne ? Si non, alors on le savait déjà...
J'avais un doute, et ce dernier est levé!
J'ai modifié le post... Les 2 box identiques (V6R2), sauf l'ONU, l'un en V1 (de Juin 2020) et l'autre en V2 sont à 35km de distance, et passe par les mêmes chemins pour arriver chez Bouygues (le point commun des 2 parcours est Montbéliard, à 70km des 2 box)...
-
Pour que le test soit vraiment définitif, il faudrait pouvoir échanger les ONU.
-
Pour que le test soit vraiment définitif, il faudrait pouvoir échanger les ONU.
Tu m'as mis un doute dans l'esprit...
Lorsque j'ai fait les test sur les 2 machines au travers des 2 box, il s'avère que les box n'étaient pas à la même version de firmware...
Celle avec l'ONU V1 était en V4.4.0 et la mienne en ONU V2 en 4.5.3...
Du coup, j'ai forcé le redémarrage de la box distante (j'ai la main dessus...) et elle a récupéré le même firmware que la mienne.
Et j'ai refait le test sur le serveur Bouygues de Meudon en thread unique... Pas de changement.
On élimine donc un éventuel problème de firmware.
Les machines depuis lesquels sont réalisés les Speedtest sont des machines récentes et puissantes
Le fait d'échanger l'ONU sur une seule config si c'était possible n'apporterait à mon humble avis aucun lever de doute complémentaire...
Il me semble que cela a été tenté par l'intervenant qui possédait un ancien V1, et que la connexion a été impossible...
A ve sujet, je me suis laissé dire par un techos, que lors de la première connexion, la mac de la box serait en quelque sort "clonée/hashée" au niveau de l'ONU... Ce qui expliquerait le non fonctionnement avec l'ancien ONU V1 sur la nouvelle connexion lors de l'essai... Mais là, je suis largement dans mon domaine d'incompétence!!! ;)
-
Le symptôme principal est la limitation systématique du débit pour chaque connexion TCP à environ 30Mo/s, quelle que soit l'heure.
A noter que le protocole UDP est beaucoup moins impacté, ce qui permet par exemple d'avoir des débits normaux lorsqu'on passe par un VPN (basé sur UDP).
Bah ça ressemble à un bête « soucis » de fenêtre TCP quand on est à plusieurs centaines de bornes de son destinataire. L’UDP y a pas de fenêtre ni de « contrôle de flux » du coup plein pot
-
Doute levé!
Je sais pas quel doute tu lèves tu es pas dans les conditions de ouno. On sait toujours pas la route entre ses deux extrémités de tests ni la route retour s’il arrive à l’avoir. En TCP la distance (le RTT) impacte le débit.
-
Je sais pas quel doute tu lèves tu es pas dans les conditions de ouno. On sait toujours pas la route entre ses deux extrémités de tests ni la route retour s’il arrive à l’avoir. En TCP la distance (le RTT) impacte le débit.
Lorsque le chemin utilisé est le même sur 95% du parcours, cela limite les écarts...
Le premier routeur rencontré depuis les 2 itinéraires est celui de Montbéliard à moins de 70km des 2 box ( toutes 2 dans le 70), et la probabilité de différenciation des itinéraires entre Montbéliard et Paris-Meudon me semble infime!
Le 1/4 de centième de poil de c...l, pas sûr que ce soit nécessaire, étant données les différences constatées entre les 2 tests...
Le doute que j'ai voulu lever est que le problème ne vient pas du firmware de la box, et que le problème est bien lié à l'ONU...
Ensuite, le tout est de savoir si Free fera quelque chose, ou pas! Ceci s'il a la possibilité de le faire, sans être obligé de "rappeler" les ONU en question...
En passant, pour mon compte, si j'ai à souffrir de ce type d'anomalie dans les temps qui viennent, la solution sera simple: Passer à une box sans ONU... Entre une V6 et une PoP, le tarif mensuel est pour moi le même, à 2€ près, et si j'intègre le différentiel sur le mobile, j'aurais limite tout intérêt à faire la bascule! Ceci en minimisant les contraintes de changer mes petites habitudes... ;)
-
J'ai downloadé l'exe qui va bien.
Dès que ma TV ne sera plus utilisée, je lance le test depuis Windows...
Et je ferai le même test sur la machine distante avec l'ONU V1, dans les mêmes conditions... Mais cela attendra je pense demain matin, lorsque les utilisations des 2 côtés sont plus "tranquilles"!
En ce qui concerne l'Upload Sppedtest, j'ai pu constater que les débits constatés semblent à "géométrie variable" sur le même serveur entre 2 Speedtests, y compris sur le serveur Bouygues de Meudon.
Je ne sais pas si d'autres ont constaté ce genre de fluctuation, qui peuvent se produire à quelques minutes d'intervalle.
-
Bonjour, Je viens de faire ton test sur la machine avec ONU V1 de Juin 2020 et sur ma machine V2...
Les copies d'écran jointes
Bonne suite!
-
Bonjour,
je pense être impacté par le même problème. Abonné Free FTTH depuis mai 2018 (Freebox Mini 4K + ONU v1), j'ai constaté des problèmes de débits immédiatement après mon déménagement début novembre 2021, ayant entrainé le remplacement de mon ONU par un v2 (mais ni de ma Freebox, ni des matériels connectés à cette dernière).
J'ai exécuté 3 fois de suite le script perl de diagnostic, depuis un Intel NUC sous Ubuntu server et connecté en Ethernet :
CheckBugOnuFree (v0.3)
---------------
Programme de comparaison du débit local / internet en mono-session TCP
Ce programme permet d'évaluer la possibilité que la connexion FTTH soit
affectée par le bug d'ONU Free. La Freebox est utilisée pour tester le débit
local, ce programme ne fonctionne donc que si la connexion Internet est gérée
par une Freebox.
Vérifier que rien d'autre ne consomme de la bande passante sur le réseau
(ordinateurs, Freebox player, télévision...), ni du CPU sur le système de test
(mises à jour automatiques, antivirus...)
Appuyer sur Entrée pour continuer (ou Ctrl-C pour annuler)...
Test de débit local...
--> 111.94 Mo/s
Test de débit Internet...
--> 40.00 Mo/s
La connexion POURRAIT être affectée par le bug d'ONU Free (débit internet légèrement supérieur au débit habituel pour les connexions affectées).
=> VERIFIER QUE RIEN D'AUTRE NE CONSOMME DE LA BANDE PASSANTE ET RELANCER LE TEST POUR CONFIRMER LE DEBIT INTERNET
CheckBugOnuFree (v0.3)
---------------
Programme de comparaison du débit local / internet en mono-session TCP
Ce programme permet d'évaluer la possibilité que la connexion FTTH soit
affectée par le bug d'ONU Free. La Freebox est utilisée pour tester le débit
local, ce programme ne fonctionne donc que si la connexion Internet est gérée
par une Freebox.
Vérifier que rien d'autre ne consomme de la bande passante sur le réseau
(ordinateurs, Freebox player, télévision...), ni du CPU sur le système de test
(mises à jour automatiques, antivirus...)
Appuyer sur Entrée pour continuer (ou Ctrl-C pour annuler)...
Test de débit local...
--> 111.94 Mo/s
Test de débit Internet...
--> 35.44 Mo/s
/!\ La connexion semble affectée par le bug d'ONU Free /!\
CheckBugOnuFree (v0.3)
---------------
Programme de comparaison du débit local / internet en mono-session TCP
Ce programme permet d'évaluer la possibilité que la connexion FTTH soit
affectée par le bug d'ONU Free. La Freebox est utilisée pour tester le débit
local, ce programme ne fonctionne donc que si la connexion Internet est gérée
par une Freebox.
Vérifier que rien d'autre ne consomme de la bande passante sur le réseau
(ordinateurs, Freebox player, télévision...), ni du CPU sur le système de test
(mises à jour automatiques, antivirus...)
Appuyer sur Entrée pour continuer (ou Ctrl-C pour annuler)...
Test de débit local...
--> 111.90 Mo/s
Test de débit Internet...
--> 42.67 Mo/s
La connexion POURRAIT être affectée par le bug d'ONU Free (débit internet légèrement supérieur au débit habituel pour les connexions affectées).
=> VERIFIER QUE RIEN D'AUTRE NE CONSOMME DE LA BANDE PASSANTE ET RELANCER LE TEST POUR CONFIRMER LE DEBIT INTERNET
-
J'ai accès à distance à un NAS Syno derrière une Box Revolution fibrée. La seule référence d'ONU que j'arrive à voir à distance est : F-MDCONU3A. Je ne sais pas si ça vous parle.
La différence entre un téléchargement avec Cubic et BBR est juste flagrante. Ça confirme tous les tests effectués sur le réseau mobile également...
Cubic IPv4
# curl -o /dev/null https://ipv4.bouygues.testdebit.info/1G.iso
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 953M 100 953M 0 0 7189k 0 0:02:15 0:02:15 --:--:-- 5875k
Cubic IPv6
# curl -o /dev/null https://ipv6.bouygues.testdebit.info/1G.iso
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 953M 100 953M 0 0 8187k 0 0:01:59 0:01:59 --:--:-- 5561k
BBR IPv4
# curl -o /dev/null https://ipv4.appliwave.testdebit.info/1G.iso
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 953M 100 953M 0 0 82.2M 0 0:00:11 0:00:11 --:--:-- 84.6M
BBR IPv6
# curl -o /dev/null https://ipv6.appliwave.testdebit.info/1G.iso
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 953M 100 953M 0 0 78.0M 0 0:00:12 0:00:12 --:--:-- 79.7M
-
Impressionnant :o
-
Est-ce que tu as essayé le script de test CheckBugOnuFree ? (il tourne sans problème sur NAS Syno)
Ah je n'avais pas vu la version Linux en Perl. Il faut installer le paquet Perl sur le Syno il ne l'était pas de base.
# ./checkBugOnuFree.pl
CheckBugOnuFree (v0.3)
---------------
Programme de comparaison du débit local / internet en mono-session TCP
Ce programme permet d'évaluer la possibilité que la connexion FTTH soit
affectée par le bug d'ONU Free. La Freebox est utilisée pour tester le débit
local, ce programme ne fonctionne donc que si la connexion Internet est gérée
par une Freebox.
Vérifier que rien d'autre ne consomme de la bande passante sur le réseau
(ordinateurs, Freebox player, télévision...), ni du CPU sur le système de test
(mises à jour automatiques, antivirus...)
Appuyer sur Entrée pour continuer (ou Ctrl-C pour annuler)...
Test de débit local...
--> 110.18 Mo/s
Test de débit Internet...
--> 86.89 Mo/s
La connexion n'est pas affectée par le bug d'ONU Free (débit internet normal).
Le serveur utilisé dans le script est BBR (scaleway.testdebit.info)
-
Non aucune idée de la période de mise en service, j'essaierai d'avoir des infos.
-
Quand j'ai parlé de Cubic/BBR je ne sous-entendais pas que c'est lié à l'ONU. Juste pour faire le lien avec le réseau mobile.
-
Regarde sur le forum plein de sujets en parle. Il y a un gros débat sur mon/multi thread sur les tests de téléchargements. Notamment dans l'étude de l'Arcep. Et la différence entre Cubic et BBR donne les mêmes constatations.
-
Pour la différence Cubic/BBR, il est bien connu que BBR n'est pas "juste" avec les flux Cubic donc s'il y a une saturation quelque part, ton flux BBR qui est encore rare de nos jours va pouvoir "prendre ses aises" au détriment des autres abonnés.
Conclusion, quand tu as une différence entre Cubic et BBR c'est généralement qu'il y a une saturation (souvent locale, c'est à peu près acquis quand la cible est chez Bouygues par exemple puisque les interconnexions avec Free sont connues pour ne pas saturer).
-
Pour information j'ai mis à jour le script de test (v0.4): j'ai ajusté les seuils de détection et ajouté le test en Cubic pour détecter ce nouveau bug (en supposant que ce soit bien un autre bug lié à certaines versions de boîtier ONU)
- checkBugOnuFree.pl (https://github.com/oounoo/checkBugOnuFree/releases/latest/download/checkBugOnuFree.pl) (pour Linux, ou Windows avec Perl installé)
- checkBugOnuFree.exe (https://github.com/oounoo/checkBugOnuFree/releases/latest/download/checkBugOnuFree.exe) (pour Windows)
Il serait intéressant que des gens en FTTH chez Free sans boîtier ONU fasse aussi le test du coup, pour s'assurer que ce deuxième problème est bien un problème qui n'arrive que lorsqu'on a un boîtier ONU.
J'ai ré-itéré mes 3 tests consécutifs, avec la même configuration matérielle et logicielle :
CheckBugOnuFree (v0.4)
---------------
Programme de diagnostique de connexion FTTH Free avec boîtier ONU
Ce programme permet d'évaluer la possibilité que la connexion FTTH soit affectée
par un dysfonctionnement du boîtier ONU Free. La Freebox est utilisée pour
tester le débit local, ce programme ne fonctionne donc que si la connexion
Internet est gérée par une Freebox.
Avant de continuer, veuillez vérifier que rien d'autre ne consomme de la bande
passante sur le réseau (ordinateurs, Freebox player, télévision...), ni du CPU
sur le système de test (mises à jour automatiques, antivirus...).
Appuyer sur Entrée pour continuer (ou Ctrl-C pour annuler)...
Test de débit local (vérification de la fiabilité du système de test)...
--> 111.91 Mo/s
Test de débit Internet (BBR)...
--> 36.84 Mo/s
/!\ La connexion semble affectée par un dysfonctionnement du boîtier ONU Free.
(ONU v2 ou ONU v1 récent)
CheckBugOnuFree (v0.4)
---------------
Programme de diagnostique de connexion FTTH Free avec boîtier ONU
Ce programme permet d'évaluer la possibilité que la connexion FTTH soit affectée
par un dysfonctionnement du boîtier ONU Free. La Freebox est utilisée pour
tester le débit local, ce programme ne fonctionne donc que si la connexion
Internet est gérée par une Freebox.
Avant de continuer, veuillez vérifier que rien d'autre ne consomme de la bande
passante sur le réseau (ordinateurs, Freebox player, télévision...), ni du CPU
sur le système de test (mises à jour automatiques, antivirus...).
Appuyer sur Entrée pour continuer (ou Ctrl-C pour annuler)...
Test de débit local (vérification de la fiabilité du système de test)...
--> 111.91 Mo/s
Test de débit Internet (BBR)...
--> 37.27 Mo/s
/!\ La connexion semble affectée par un dysfonctionnement du boîtier ONU Free.
(ONU v2 ou ONU v1 récent)
CheckBugOnuFree (v0.4)
---------------
Programme de diagnostique de connexion FTTH Free avec boîtier ONU
Ce programme permet d'évaluer la possibilité que la connexion FTTH soit affectée
par un dysfonctionnement du boîtier ONU Free. La Freebox est utilisée pour
tester le débit local, ce programme ne fonctionne donc que si la connexion
Internet est gérée par une Freebox.
Avant de continuer, veuillez vérifier que rien d'autre ne consomme de la bande
passante sur le réseau (ordinateurs, Freebox player, télévision...), ni du CPU
sur le système de test (mises à jour automatiques, antivirus...).
Appuyer sur Entrée pour continuer (ou Ctrl-C pour annuler)...
Test de débit local (vérification de la fiabilité du système de test)...
--> 111.90 Mo/s
Test de débit Internet (BBR)...
--> 40.63 Mo/s
/!\ La connexion semble affectée par un dysfonctionnement du boîtier ONU Free.
(ONU v2 ou ONU v1 récent)
-
- concernant le problème de FloBaoti: un ratio x10 entre ses débits Cubic et BBR (même en supposant qu'il y ait une saturation quelque part sur le trajet, cela me paraît énorme ?)
Si la saturation est majeure, ça me choque pas forcément plus que ça.
-
Pour information j'ai mis à jour le script de test (v0.4): j'ai ajusté les seuils de détection et ajouté le test en Cubic pour détecter ce nouveau bug (en supposant que ce soit bien un autre bug lié à certaines versions de boîtier ONU)
- checkBugOnuFree.pl (https://github.com/oounoo/checkBugOnuFree/releases/latest/download/checkBugOnuFree.pl) (pour Linux, ou Windows avec Perl installé)
- checkBugOnuFree.exe (https://github.com/oounoo/checkBugOnuFree/releases/latest/download/checkBugOnuFree.exe) (pour Windows)
Il serait intéressant que des gens en FTTH chez Free sans boîtier ONU fasse aussi le test du coup, pour s'assurer que ce deuxième problème est bien un problème qui n'arrive que lorsqu'on a un boîtier ONU.
Voici un test avec une Delta (lien box/PC en 1G).
-
Cet après-midi, j'ai participé au raccordement fibre d'un voisin avec une Box Mini 4K et ONU V2. Après raccordement OK, test sommaire avec un Speedtest en connexion unique depuis le navigateur: Limitation à environ 270Mbits, alors que le UP est OK...
Je ferai un test avec ton soft dès que possible...
Bonne soirée.
-
23h je ne sais pas si on peut encore parler d'heure de pointe.
-
Merci !
Cela confirmerait que sans boîtier ONU on ne trouve pas ce gros écart BBR / Cubic, même en période de pointe.
Par contre il serait intéressant de voir si tu obtiens un débit Internet qui se rapproche de ton débit local lorsque tu fais le test en heure creuse.
J'ai un PC assez vieux (q6600/8gddr2, et disques à l'ancienne en Raid 0). Mais via speedtest, que ce soit cubic/bbr/mono/multi, ça donne toujours entre 900/950 méga.
Et via wifi de la box et smartphone POCO F3
-
Il y a un truc bizarre chez moi :
[checkBugOnuFree v0.6] [Windows 10 Build 19043 (64-bit)] [2021-12-13 22:33:49 GMT]
Test de débit local (vérification de la fiabilité du système de test)...
--> 74.51 Mo/s
Test de débit Internet (AS12876-BBR)...
--> 112.73 Mo/s
Test de débit Internet (AS12876-Cubic)...
--> 110.91 Mo/s
C'est reproductible sur plusieurs lancements.
-
En fait le script de test n'utilise pas le stockage, et le premier test en local montre que le système que tu utilises pour les tests est tout à fait capable de dépasser les 900Mbps en mono-session TCP.
Mais je doute qu'il aille beaucoup plus haut.
-
Ben tous les tests sont faits dans la foulée, du coup je ne vois pas trop pourquoi seul le test local serait impacté.
-
Je ne savais pas vraiment non plus à vrai dire, mais a priori c'en est pas si loin ?
google(heure de pointe sur internet) (https://www.google.com/search?q=heure+de+pointe+sur+internet) donne ce lien (https://www.presse-citron.net/la-video-sur-internet-a-aussi-son-prime-time-et-il-menace-celui-de-la-television/) en premier résultat chez moi (j'avoue j'ai pas creusé plus):
Ce n'est peut-être pas l'heure la plus chargée, mais sans doute suffisamment pour impacter un peu si un lien est sous-taillé ?
J'ai posté à 23h, mais le test a été réalisé à 16h...
En passant, il y a un moment où il ne faut pas tout mélanger...
Il est clair que l'ONU V2 a un souci! Je pense qu'il ne faut pas mélanger ton utilitaire qui est conçu au départ pour lever le doute!
Avec tous les problèmes divers et (a)variés qui peuvent survenir lors de tels tests, il y aura toujours des cas particuliers, et pouvoir essayer de résoudre 100% des cas est une illusion.
J'ai la faiblesse de croire que ces tests pourront amener Free à faire quelque chose, sinon on est dans la "beauté du geste"! ;) ;) ;)
-
Quand on parlait de 23h on parlait du test de Myck205 qui a été effectué à 22h56.
Je suis bien d'accord, mais c'est important aussi d'être sûr du programme utilisé pour les tests.
Donc quand il y a des résultats étranges comme celui-ci (débit internet plus élevé qu'un débit local), c'est normal d'essayer de comprendre la cause parce que si c'est un défaut dans le programme de test je voudrais le corriger.
D'autre part, suite à de nouveaux tests que j'ai faits sous Windows je commence à penser qu'il y a plusieurs problèmes imbriqués...
Pour moi la seule chose qui pourrait éventuellement faire bouger les choses (et encore) serait une preuve véritable.
Par exemple quelqu'un qui arrive à tester en changeant juste l'ONU (ou le SFP) et qui obtient des débits normaux suite au changement.
Je vais être bref... Même avec une "preuve", est-ce que l'opérateur bougera? Dubitatif je reste! Car quelle proportion d'abonnés ressent réellement le problème? Quelques pouillèmes?
-
Oui je comprends bien, quand je disais que la Freebox était peut-être chargée je parlais de la charge CPU (pas charge de bande passante, qui impacterait tous les débits).
Pour moi il y a deux possibilités:
- soit c'est ta Freebox qui n'arrive pas à générer les données pour le test assez vite
- soit c'est ton pc qui ralentit le premier téléchargement
Le problème n'est pas systématique et peut être reproduit avec juste un wget :
[checkBugOnuFree v0.7] Windows 10 Build 19043 (64-bit)
--------------------------- 2021-12-14 18:32:25 GMT ---------------------------
Test de débit local (vérification de la fiabilité du système de test)...
--> 76.83 Mo/s
Test de débit Internet (AS12876-BBR)...
--> 112.42 Mo/s
Test de débit Internet (AS12876-Cubic)...
--> 112.95 Mo/s
[checkBugOnuFree v0.7] Windows 10 Build 19043 (64-bit)
--------------------------- 2021-12-14 18:34:06 GMT ---------------------------
Test de débit local (vérification de la fiabilité du système de test)...
--> 112.30 Mo/s
Test de débit Internet (AS12876-BBR)...
--> 112.87 Mo/s
Test de débit Internet (AS12876-Cubic)...
--> 113.04 Mo/s
Je ne sais pas trop ce qu'il se passe, j'essayerai de redémarrer la box...
-
Pour moi la seule chose qui pourrait éventuellement faire bouger les choses (et encore) serait une preuve véritable.
eventuellement ?
oui enfin, autant jouer au loto hein ;)
-
Tu es sûr que la box télé n'est pas allumée ? Je constate que le débit local descend entre 85 Mo/s et 93 Mo/s dans mon cas si la télé est allumée...
Elle n'est même pas branchée. ;) Par ailleurs il ne s'écoule que quelques secondes entre mes tests qui passe d'environ 110 Mo/s à environ 70 Mo/s. J'ai l'impression qu'il y a environ une chance sur deux pour que le débit soit nominale.
Edit : J'ai oublié de préciser que j'ai redémarré la box entre temps, sans que ça change quoi que ce soit.
-
Dans mon cas, j'avais youtube qui tournait sur le player.
-
Ma mère va très prochainement basculer sur la fibre, je pourrais transmettre quelques tests, Freebox revo R2, à voir quel ONU.
-
Test effectué avec l'ONU en photo sur une toute récente connexion Free fibre avec V6 R2 et portable Lenovo en i5 2.4Ghz, 4 méga de RAM.
-
Merci pour ce retour, très intéressant !
Donc déjà on voit que c'est un ONU v1, comme celui qui a été déployé chez mes parents le mois dernier.
Est-ce que Free mettrait en pause le déploiement des v2 au vu des problèmes rencontrés ? Après ça peut aussi être juste une histoire de fin de stock local...
Comme on pouvait s'y attendre, cet ONU n'est pas impacté par le bug des ONU v2 (limités à 30Mo/s par session TCP).
Par contre le débit local n'est pas très élevé (86 Mo/s au lieu des habituels > 110 Mo/s), peut-être un souci sur le lien local ou utilisation du wifi pour les tests ?
Mais ce que je remarque surtout, c'est que les débits Internet sont relativement corrects malgré l'heure du test (à 18h le réseau Free commence déjà à être bien encombré d'après mes tests). Je suppose que cette ligne est située à Paris. D'après la latence qui est très bonne, la ligne est très bien située et n'a pas à parcourir beaucoup de liens/équipements pour sortir. Cela semble indiquer que la congestion se situe bien sur le réseau Free, mais en aval...
Pour le débit local, c'est en ethernet en direct sur la box. Je pense plus à une limitation du pc, il reste pas très puissant, j'étais sur batterie. Sur speedtest en multi, ça sort en moyenne 870 mb/s.
Test fait chez ma mère, raccordé au même NRA/NRO (dans le 77) que chez moi, il y a pas de saturation quelques soit l'heure.
-
Bonjour,
Je suis chez les grands parents avec une freebox et onu V2
-
Merci pour ce retour qui confirme encore une fois cette fameuse limite à 30 Mo/s par session TCP avec les ONU v2...
Il me semble qu'il y avait eu un contre-exemple il n'y a pas si longtemps. Est-ce qu'on avait pu avoir plus de tests finalement ?
-
Si jamais tu avais la possibilité de lancer checkBugOnuFree entre 21h30 et 22h30 je serais curieux quand même de voir le résultat (je suppose que chez ta mère ça va être compliqué mais chez toi avec la Delta peut-être ?).
Je l'ai fait la dernière fois, les résultats sont identiques à toutes heures.
-
Ah oui c'est vrai tu avais fait le test vers 23h j'avais oublié.
J'en avais fait d'autres plus tôt suite à une remarque de l'heure de test. Le résultat étant similaire, je ne l'avais pas poster, mais je pourrais le faire la prochaine fois.
-
Test à 19h et à 21H :
-
Bonjour tout le monde,
Nouveau témoignage à charge du boîtier ONU v2.
J'ai fais déménager ma ligne depuis une ZTD (Asnières-Sur-Seine) vers une ZMD (Bezons) et en dehors de l'ONU (qui fut une surprise pour moi), rien n'a changé dans la chaîne (mini 4k en bridge => pfsense => lan).
La moyenne était d'environs ~800mbps à mon ancienne adresse et maintenant je plafonne à ~500mbps.
(https://i.imgur.com/vUpdFTg.png)
Le NRO (http://francois04.free.fr/nav.php?niv=4&nom=e00-100d-1700-dad8-Z&nom0=e00-100d-1700&type=Z) ne semble pas être saturé non plus.
-
Je suis justement entrain de debug ce problème de débit sur mon lan (et semblerait provenir de mon setup pfSense, que j'ai reset entre temps).
Concernant l'ONU, je vais contacter le 3244 pour voir ce qu'il serait possible de faire. Mais au vu de la galère que fut mon setup en ZMD, et maintenant cet ONU ... ils me poussent très sérieusement à regarder la concurrence.
Au pire un passage à la Pop, à voir.
Pour la console, fort probable que ce soit la font ou la config du term.
Ne travaillant qu'en anglais, les accents ne m'ont jamais sautés au yeux.
-
Nouveau speedtest (depuis pfsense) en milieu de journée, pas très glorieux
⇒ ssh admin@pfsense.home.cloud -C "speedtest --server 45446"
Password for admin@pfsense.home.cloud:
Retrieving speedtest.net configuration...
Testing from Free SAS (82.65.XX.XXX)...
Retrieving speedtest.net server list...
Retrieving information for the selected server...
Hosted by LaFibre.info BBR-IPv4 (Palaiseau) [17.37 km]: 4.982 ms
Testing download speed................................................................................
Download: 348.58 Mbit/s
Testing upload speed...
Upload: 571.83 Mbit/s
Puis exec du script depuis un RPI sur le même switch que pfsense :
[checkBugOnuFree v0.9] Linux 5.4.0-1042-raspi (aarch64)
--------------------------- 2022-01-10 12:46:09 GMT ---------------------------
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: 21675 28900 43350
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
Test TCP local (Freebox)...
--> Latence: 0.85 ms
--> Débit: 75.72 Mo/s (605.77 Mbps)
Test TCP Internet (AS12876-BBR)...
--> Latence: 2.80 ms
--> Débit: 32.27 Mo/s (258.13 Mbps)
[!] La connexion semble affectée par un dysfonctionnement de boîtier ONU Free.
--------------------------- 2022-01-10 12:46:57 GMT ---------------------------
Là où je pensais potentiellement avoir des tests biaisés à cause du souci de débit LAN ... Le débit WAN ayant été coupé en deux depuis hier m'assure que ce n'est pas le cas.
-
Faut toujours pondérer un test unique avec plusieurs, faits à plusieurs moments de la journée, pour éliminer d'éventuelles saturation du ou des serveurs...
En la matière, j'ai pu me rendre compte qu'il n'y a pas UN serveur de référence, qui assure le max 24/24, mais que selon le moment de la journée, tel ou tel serveur de "test" est plus ou moins chargé, ainsi que l'éventuel peering pour y arriver...
-
C'est le cas déjà je te rassure. Orange, SFR, et autres serveurs indépendants, je ne dépasse pas les ~300mbps.
On retentera l'opération en fin de journée, mais au vu du nombre de lignes actives le NRO j'ai mes doutes.
-
C'est le cas déjà je te rassure. Orange, SFR, et autres serveurs indépendants, je ne dépasse pas les ~300mbps.
On retentera l'opération en fin de journée, mais au vu du nombre de lignes actives le NRO j'ai mes doutes.
En cours de journée, avec l'application w10 speedtest en multi connexions, il m'arrive d'avoir des difficultés sur certains serveurs à avoir un UP maxi...
Quand aux tests avec la même appli en down, c'est selon le serveur. En général, Bouygues Meudon BBR donne les meilleurs résultats depuis une connexion Free...
Pour le down, il est clair que les tests faits avec l'utilitaire d'ouno révèlent bien le problème de limitation en mono connexion et l'ONU V2. C'est ce que j'obtiens avec ma Revo et ONU V2.
Dans quelques jours/semaines, je serai avec une POP, donc plus d'ONU... Je quitte la Révo, après presque 10 ans... Et avoir vécu auparavant le modem ADSL Free et ses 2048/512, la Freebox V3 (Catastrophe ADSL!), puis V4, puis V5... ;) ;) ;)
-
Je me tâte à partir sur une Pop aussi pour me débarrasser de cette ONU. Mais d'un autre côté, mon but étant de me séparer de la box tout court ...
Vu comment ça a l'air impossible en ZMD Free, un revirement de FAI est envisagé aussi.
Il faudrait que je test de façon plus poussé sur le Nano G d'Ubiquiti pourrait faire le taff. Mais c'est très "hit or miss" de mes lectures sur le forum.
-
Je me tâte à partir sur une Pop aussi pour me débarrasser de cette ONU. Mais d'un autre côté, mon but étant de me séparer de la box tout court ...
Vu comment ça a l'air impossible en ZMD Free, un revirement de FAI est envisagé aussi.
Il faudrait que je test de façon plus poussé sur le Nano G d'Ubiquiti pourrait faire le taff. Mais c'est très "hit or miss" de mes lectures sur le forum.
Sinon, il y a le mode bridge, qui vous permet de mettre votre routeur derrière, la box ne sert alors que de modem, et vous permet de gérer votre LAN "aux petits ognons" avec votre routeur...
Si vous êtes en ZMD et sur un RIP, pouvez-vous envisager un opérateur "alternatif", genre K-Net qui ne vous délivrerait que de l'internet et vous permettrait d'utiliser votre routeur?
-
Je suis déjà en bridge, mais avoir une box qui consomme et chauffe juste pour faire passe-plat… C'est ni écologique ni vraiment pratique.
Et ça permettrait de finir avec du matériel inadéquat, preuve avec notre chère ONU v2 :)
Les FAI alternatif pourraient être une solution, j'ai déjà regardé l'offre d'OVH par exemple. Mais très difficile d'avoir des retours sur ce genre de solutions.
-
Je suis déjà en bridge, mais avoir une box qui consomme et chauffe juste pour faire passe-plat… C'est ni écologique ni vraiment pratique.
Et ça permettrait de finir avec du matériel inadéquat, preuve avec notre chère ONU v2 :)
Les FAI alternatif pourraient être une solution, j'ai déjà regardé l'offre d'OVH par exemple. Mais très difficile d'avoir des retours sur ce genre de solutions.
Faut déjà que l'opérateur soit présent et sur la fibre, et dans le NRO qui te dessert... Tu peux regarder les sujets sur ces FAI alternatifs...
En passant, il est clair que Révo ou Mini4K au niveau conso, c'est pas le genre portion congrue... Et je ne parle pas de la Revo R1, qui pétait en permanence les 85 / 90° CPU en permanence!
-
Je suis déjà en bridge, mais avoir une box qui consomme et chauffe juste pour faire passe-plat… C'est ni écologique ni vraiment pratique.
Et ça permettrait de finir avec du matériel inadéquat, preuve avec notre chère ONU v2 :)
Les FAI alternatif pourraient être une solution, j'ai déjà regardé l'offre d'OVH par exemple. Mais très difficile d'avoir des retours sur ce genre de solutions.
Sinon, si tu veux une offre uniquement internet sur laquelle tu mets ton propre équipement , il y a Milkywan.
https://eligibilite.milkywan.fr/ (https://eligibilite.milkywan.fr/)
https://lafibre.info/milkywan/ftth-milkywan/ (https://lafibre.info/milkywan/ftth-milkywan/)
https://lafibre.info/milkywan/ftth-xdsl-milkywan-retours-dexperience-dabonnes/ (https://lafibre.info/milkywan/ftth-xdsl-milkywan-retours-dexperience-dabonnes/)
-
Je viens de passer chez Free, avec un ONU v2, et la sentence de checkBugOnuFree est sans appel:
- 300Mbits/s en download par connexion TCP
- 1Gbits/s en download multi-TCP
Par contre, en upload je suis à 700Mbits/s, je croyais que la limite était à 600Mbits/s (Freebox Revolution, RIP Anjou-Fibre) ???
-
Non, en UP, c'est bien 700... Que ce soit sur un RIP ou ailleurs, Free ne semble utiliser que ses matos, donc le débit up devrait être le même partout, peut-être excepté sur ce qui reste d'installations en PtoP...
-
Il faudrait que je test de façon plus poussé sur le Nano G d'Ubiquiti pourrait faire le taff. Mais c'est très "hit or miss" de mes lectures sur le forum.
raté, c'est du 10G-EPON chez Free, rien n'existe pour remplacer l'ONU.
-
raté, c'est du 10G-EPON chez Free, rien n'existe pour remplacer l'ONU.
D'où le pourquoi de la Delta ou de la Pop en bridge, cette dernière étant moins énergivore...
En passant, sur Bezons, les alternatifs sur la fibre... Pas beaucoup de candidats?!?
-
D'où le pourquoi de la Delta ou de la Pop en bridge, cette dernière étant moins énergivore...
En passant, sur Bezons, les alternatifs sur la fibre... Pas beaucoup de candidats?!?
étant donné qu'il souhaite virer la box, lui proposer de prendre une autre box me semble plutôt inapproprié...
Une offre bouygues/sosh/sfr/milkywan serait bien plus adapté à son besoin.
-
étant donné qu'il souhaite virer la box, lui proposer de prendre une autre box me semble plutôt inapproprié...
Une offre bouygues/sosh/sfr/milkywan serait bien plus adapté à son besoin.
Si les autres opérateurs permettent un bridge qui fonctionne nickel ou de remplacer la box par un routeur et ceci de façon fiable et pérenne, pourquoi pas?
Il m'a semblé voir ici ou là, quelques interventions où cela n'était pas évident... Mais j'ai du mal lire et/ou mal comprendre, ou je suis partial? Allez savoir! ;)
-
Si les autres opérateurs permettent un bridge qui fonctionne nickel ou de remplacer la box par un routeur et ceci de façon fiable et pérenne, pourquoi pas?
Il m'a semblé voir ici ou là, quelques interventions où cela n'était pas évident... Mais j'ai du mal lire et/ou mal comprendre, ou je suis partial? Allez savoir! ;)
Pour Bouygues, c'est une requête DHCP sur un vlan, pour orange, c'est du PPPoE, avec un identifiant/mdp à rentrer (pour peu que tu n'aies pas besoin d'IPv6).
-
Choux blanc comme dit fansat, rien dans mon coin de ce que j'ai pu voir niveau ligne de proximité.
Passé à une Pop serait déjà un bon pas en avant, plus d'ONU et conso moindre. Mais payer premium juste pour ça me fait assez mal (surtout que mon Netgate SG-2440 gère pas plus que du 1gbps).
En passant, il est clair que Révo ou Mini4K au niveau conso, c'est pas le genre portion congrue... Et je ne parle pas de la Revo R1, qui pétait en permanence les 85 / 90° CPU en permanence!
Elle est à 80°c en permanence la petite 4K, en même temps elle en sandwich entre l'ONU et un UI Poe 8 Lite ...
-
Pour Bouygues, c'est une requête DHCP sur un vlan, pour orange, c'est du PPPoE, avec un identifiant/mdp à rentrer (pour peu que tu n'aies pas besoin d'IPv6).
On doit pouvoir effectivement obtenir ça et là des "choses", mais c'est la pérennité qui semble poser problème...
A condition que Bouygues, au bout d'une "certain temps" ne déclare pas "la box obsolète", alosr que c'est un routeur qui est au bout...
Chez Orange, il semble que ce soit de moins en moins d'actualité, le PPPoE semblant "disparaître" petit à petit...
Il semblerait que les opérateurs "normalisent" peu à peu vers du très grand public façon Michu, et cherchent à limiter au max d'éventuels remontées SAV en "restreignant les ébats"...
La tendance serait de plus en plus à classer les utilisateurs "exigeants" dans une catégorie "semi-pro", je crains avec les tarifs allant avec!
La question se posera peut-être un jour chez Free. Pour l'instant, cet opérateur permet le bridge, mais annonce clairement la couleur sur le site d'assistance GP (interprétation personnelle): "Bridge = Dém...de-toi!
Chez Free Pro, ce n'est pas de la soie, car apparemment, toujours pas de Bridge! Free encore une fois à l'opposé de ses concurrents... :-\ :-\ :-\
-
Les box obligatoires et les forfait fourre-tout… La grande hantise des gens dans mon genre, qui sont suffisamment versé en réseau pour vouloir gérer leur propre routeur et qui n'en on cure d'avoir la TV ou la VoIP ...
On leurs (les FAI) coûterait moins cher, mais on nous fait payer premium ce genre de feature. Et encore, virer les options TV ou VoIP semble juste impossible.
-
Les box obligatoires et les forfait fourre-tout… La grande hantise des gens dans mon genre, qui sont suffisamment versé en réseau pour vouloir gérer leur propre routeur et qui n'en on cure d'avoir la TV ou la VoIP ...
On leurs (les FAI) coûterait moins cher, mais on nous fait payer premium ce genre de feature. Et encore, virer les options TV ou VoIP semble juste impossible.
Nous vivons dans une société faite par le pognon et pour le pognon... Être dedans et en dehors, pas évident, on devient ce qui s'appelle un "marginal"! ;) :( :-\
-
Les box obligatoires et les forfait fourre-tout… La grande hantise des gens dans mon genre, qui sont suffisamment versé en réseau pour vouloir gérer leur propre routeur et qui n'en on cure d'avoir la TV ou la VoIP ...
On leurs (les FAI) coûterait moins cher, mais on nous fait payer premium ce genre de feature. Et encore, virer les options TV ou VoIP semble juste impossible.
Bof, la tv fait baisser la facture car tva plus faible et la voip ne coûte rien. Ce qui coûte cher c'est le service client et le réseau. Et la plupart des gens veulent la télévison.
-
Bonjour,
Après plusieurs appels chez Free, il est "impossible" de changer un ONU V2 par un v1.
Globalement on m'envoi chier...
-
Nous vivons dans une société faite par le pognon et pour le pognon...
ben si preferes ne pas avoir de pogon, je te file mon metamask et tu m'envoies tout ce que t'as ? Et tu verras tu seras bien mieux apres sans un kopek ;)
-
Bonjour,
Après plusieurs appels chez Free, il est "impossible" de changer un ONU V2 par un v1.
Globalement on m'envoi chier...
Pas trop étonnant, à se douter qu'ils ne gardent pas de vieux stock même s'ils acceptaient un échange :-\
Je vais appeler et négocier la Pop au prix de mon abo actuel (toujours à l'ancien tarif de 29.99e) à mon avis.
-
Pas trop étonnant, à se douter qu'ils ne gardent pas de vieux stock même s'ils acceptaient un échange :-\
Je vais appeler et négocier la Pop au prix de mon abo actuel (toujours à l'ancien tarif de 29.99e) à mon avis.
Ils m'ont dit je cite:
Il est impossible de remplacer le onu V2 par un V1 car il n'y a que les v2 pour les nouveaux abonnement
puis nous avons des onu V2 et V1 mais si je vous envois un technicien il aura un des deux model au hasard on peut pas savoir
Je vais essayé la pop sinon mais bon mon abo est à 9E99 donc j'ai du mal à y croire.
Dans le doute j'ai essayé de bypassé l'onu en faisant arriver la fibre directement dans la box, mais malheureusement cela ne fonctionne pas.
J'ai même essayé de mettre mon SFP orange à la place, j'arrive jusque l'étape 4 mais pas plus.
J'envisage de faire sauter la freebox + onu. Faut que je cherche.
Bref première expérience free, je risque pas de l'oublier....
-
Pourtant les v1 et v2 sont physiquement différent ...
Les numéro de série (faisant preuve d'identifiants) étant différent sur les jarretières SFP, ça me risque pas de fonctionner malheureusement.
J'ai l'impression que Free marche mieux en ZTD qu'en ZMD, en tout cas c'est mon retour d'expérience après 5 ans en ZTD.
Comme on m'a indiqué une ou deux pages avant, passer par des FAI alternatifs (si dispo par chez toi) serait le bon plan.
-
Sinon je retourne chez Orange.
Ca marche, ils sont en retard sur la box et ses fonction par rapport à free mais au moins la base de la connexion, à savoir le débit est lui fonctionnel
-
En lisant la doc de l'ONU, un voyant vert clignotant indique une MAJ en cours, donc c'est upgradable: c'est déjà ça.
C'est manifestement un problème de gestion de l'engorgement TCP, probablement simplement des buffers sous dimensionnés dans la configuration.
D'ailleurs en UDP ou gestion de l'engorgement BBR, on a plein débit.
Il est aussi possible d'utiliser un service VPN sur UDP
-
Test en downloadant d'un serveur configuré en BBR. Et le réseau de collecte serait saturé de la même manière jour comme nuit ? Et pas avec un ONU v1 ? Et pas avec une Freebox Pop ou Delta ?
-
J'ai eu un retour de Free, particulièrement Julien du support Premium (grand merci à lui)
Une personne en mesure de comprendre les tests effectués, ce qui change beaucoup !
j'ai lancé un "thread" sur le site dev
https://dev.freebox.fr/bugs/task/36238 (https://dev.freebox.fr/bugs/task/36238)
-
Pourquoi avoir dupliqué le thread existant qui avait déjà 4 votes ? ( https://dev.freebox.fr/bugs/task/35674 )
Oui je l'avais vu, malheureusement la réponse de free quand j'ai mentionné ce thread a été "mais ca vous concerne pas, vous avez pas de Freebox Server Mini 4K"
-
Ah c'est dommage, cela isole ton problème qui est pourtant partagé par de nombreux autres clients. Ce n'est pas lié à la Freebox mais au boîtier ONU v2, qui peut être utilisé avec une Freebox Mini 4K tout comme une Freebox Révolution.
D'ailleurs au passage, étant donné que ce service dev-freebox concerne plutôt la Freebox proprement dite ce n'est pas sûr qu'ils puissent faire quelque chose...
Je serais toi j'aurais mis exactement le même titre que l'autre demande, et dans la description j'aurais mis "Doublon de la tâche 35674 créé à la demande du support car le problème concerne aussi la Freebox Révolution et pas seulement la Freebox Mini 4K. Les symptômes sont exactement les mêmes car le problème est lié à un défaut du boîtier ONU v2 et non au modèle de Freebox utilisé". Tout le reste (tests de débit mono-connexion etc.) a déjà été fourni de nombreuses fois dans le ticket original...
Ouais, j'avais peur que ca soit delete justement en mode doublon.
Après j'ai une personne de chez free qui a pris en charge le sujet.
Et d'ailleurs l'autre thread, n'avait pas été remonté chez eux (si j'ai bien compris)
-
Que donne le script checkBugOnuFree sur ta ligne lorsque tu l'exécutes tôt le matin d'une part, et entre 21h30 et 22h30 d'autre part ?
Je vais faire un script qui lance ça toutes les heures. A suivre !
-
[checkBugOnuFree v0.9] Windows 10 Build 19044 (64-bit)
--------------------------- 2022-01-12 11:03:31 GMT ---------------------------
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 (Freebox)...
--> Latence: 0.56 ms
--> Débit: 96.19 Mo/s (769.49 Mbps)
Test TCP Internet (AS12876-BBR)...
--> Latence: 6.38 ms
--> Débit: 34.67 Mo/s (277.38 Mbps)
[!] La connexion semble affectée par un dysfonctionnement de boîtier ONU Free.
-
Hum c'était avec l'application Speedtest, est-elle mono-session (serveurs LaFibre.info-CUBIC & LaFibre.info-BBR) ?
-
Hum c'était avec l'application Speedtest, est-elle mono-session (serveurs LaFibre.info-CUBIC & LaFibre.info-BBR) ?
Ça dépend du serveur choisi. Et pour multi ou mono, par défaut c'est en multi, il faut régler manuellement pour passer en mono.
-
J'ai vu l'option dans la version web, mais pas dans l'application ?
-
J'ai vu l'option dans la version web, mais pas dans l'application ?
Dans l'application, il semble que ce soit toujours en multi... Pas vu de choix!
-
Effectivement, j'ai commis une erreur d'interprétation, à force de faire des essais dans tous les sens !
Sinon, les essais avec CheckBugOnuFree à 23h30 hier ont toujours montrée le même débit "bridé".
-
Perso ça fait quasiment 1 an que ça dure avec leur ONT V2...
J'utilise la plupart du temps un VPN qui me permet de bypasser le problème en faisant tout transiter en UDP. Donc je n'ai pas trop de problèmes au quotidien mais c'est quand même chiant.
[checkBugOnuFree v0.9] Windows 10 Build 19044 (64-bit)
--------------------------- 2022-01-13 15:03:07 GMT ---------------------------
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 (Freebox)...
--> Latence: 0.54 ms
--> Débit: 116.52 Mo/s (932.14 Mbps)
Test TCP Internet (AS12876-BBR)...
--> Latence: 2.54 ms
--> Débit: 33.56 Mo/s (268.52 Mbps)
[!] La connexion semble affectée par un dysfonctionnement de boîtier ONU Free.
-
J'utilise la plupart du temps un VPN qui me permet de bypasser le problème en faisant tout transiter en UDP. Donc je n'ai pas trop de problèmes au quotidien mais c'est quand même chiant.
Peux-tu nous donner des VPN qui ont une bonne bande passante ?
-
Peux-tu nous donner des VPN qui ont une bonne bande passante ?
Personnellement j'utilise une machine virtuelle Vultr (6$/mois) qui a une bande passante de 5Gbps partagée et je suis tout le temps en 950mbps avec ma connexion. Sinon Mullvad fonctionne très bien aussi
-
Bonjour,
Merci pour le script qui confirme bien le doute que j'avais pour certains téléchargements bridés à 30 Mo/s que je n'ai pas avec un ONU v1.
Voilà mon résultat pour un ONU v2...
[checkBugOnuFree v0.9] Windows 10 Build 19043 (64-bit)
--------------------------- 2022-01-14 18:10:16 GMT ---------------------------
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 (Freebox)...
--> Latence: 1.20 ms
--> Débit: 115.67 Mo/s (925.37 Mbps)
Test TCP Internet (AS12876-BBR)...
--> Latence: 12.40 ms
--> Débit: 33.80 Mo/s (270.37 Mbps)
[!] La connexion semble affectée par un dysfonctionnement de boîtier ONU Free
-
Bonjour a tous, désolé si je donne l'impression de crié au complot mais es que Free, vu ça réaction que l'on pourrez qualifier d'inexistant ne ferait pas exprès de "bridé" les ONU V2 pour laisse un maximum de bande passante aux offres plus "haut de gamme" à savoir les delta/pop aux détriment des abonnements mini4k/révolution régulièrement en promo a moins de 20€ ?
-
Bonjour a tous, désolé si je donne l'impression de crié au complot mais es que Free, vu ça réaction que l'on pourrez qualifier d'inexistant ne ferait pas exprès de "bridé" les ONU V2 pour laisse un maximum de bande passante aux offres plus "haut de gamme" à savoir les delta/pop aux détriment des abonnements mini4k/révolution régulièrement en promo a moins de 20€ ?
La question a déjà été posée...
En fait, la limitation est uniquement sur les flux TCP, et la limitation est par flux TCP. En multipliant les flux TCP, vous pouvez saturer votre débit nominal, donc aucun gain pour Free.
Je pense plutôt que c'est une connerie dans le firmware, qu'en termes "politiquement corrects" on appellera bug... Peut-être un mauvais dimensionnement de buffer (le développeur fou qui a oublié un zéro dans le code... ;) ), comme il avait été signalé sur un device de chez Cisco il y a quelque temps...
-
Bonjour a tous, désolé si je donne l'impression de crié au complot mais es que Free, vu ça réaction que l'on pourrez qualifier d'inexistant ne ferait pas exprès de "bridé" les ONU V2 pour laisse un maximum de bande passante aux offres plus "haut de gamme" à savoir les delta/pop aux détriment des abonnements mini4k/révolution régulièrement en promo a moins de 20€ ?
Pas impossible mais un moyen plus simple et efficace est d'arrêter la commercialisation de ses 2 box pour la fibre
-
Sait-on qui fabrique cet ONU ? J'imagine que c'est un boîtier standard, et pas un dév interne Free...
Comment peut-on se connecter dessus ? Il y a peut-être une interface CLI RS232 comme à l'époque des Diva2430 de Tiscali ? ::)
-
La question a déjà été posée...
En fait, la limitation est uniquement sur les flux TCP, et la limitation est par flux TCP. En multipliant les flux TCP, vous pouvez saturer votre débit nominal, donc aucun gain pour Free.
Je pense plutôt que c'est une connerie dans le firmware, qu'en termes "politiquement corrects" on appellera bug... Peut-être un mauvais dimensionnement de buffer (le développeur fou qui a oublié un zéro dans le code... ;) ), comme il avait été signalé sur un device de chez Cisco il y a quelque temps...
Merci de ta réponse et désolé d'avoir reposer la question alors :)
-
Sait-on qui fabrique cet ONU ? J'imagine que c'est un boîtier standard, et pas un dév interne Free...
Comment peut-on se connecter dessus ? Il y a peut-être une interface CLI RS232 comme à l'époque des Diva2430 de Tiscali ? ::)
Je dirais bien que cela sent la fourniture par un intermédiaire résident au fond d'une cave du 13ème... Je n'ose envisager un "bébé" du Dev de Free! Quoique! ;) ;) ;)
-
Made in China, le tech m'a laissé la boîte.
(https://i.imgur.com/Qzre0vU.jpg)
-
Cela ne faisait de doute pour personne, je crois! Ceci d'autant plus que j'ai le même carton! Le doute était surtout au niveau de la conception, et de la voie d'approvisionnement...
D'où mon hypothèse extrêmement foireuse d'un transit par un sous-sol obscur au fin fond du treizième à proximité d'une honorable boutique affiliée aux "Frères Gourmands"...
Tout ceci n'étant qu'une immense galéjade, évidemment! ;) ;) ;)
-
Des nouvelles du front... Lâchement, j'ai abandonné mes coreligionnaires d'ONU V2 et je suis passé à la Freebox PoP... Honte à moi! Mais... bien sûr plus de problème d'ONU V2...
Par acquit de conscience, j'ai repassé le petit programme checkBugOnuFree v0.9, et bien sûr, tout est clean...
-
Hello.
J'ai une proposition de test à faire si vous avez du temps à y consacrer. On sait que l'ONU semble avoir du mal à gérer la transition du 1G au 10G pour le TCP, par contre pas de problème via un VPN en UDP. Cela semble montrer que l'algorithme qui gère la qos semble défectueux sur cet ONU.
Dans ce cas, si quelqu'un a un peu de temps et surtout un routeur capable de limiter le débit, pourrait-il configurer son routeur pour limiter le débit à 500M par exemple, afin que la gestion du débit soit fait forcément par le routeur aussi bien en downlink qu'en uplink, et non pas par l'ONU, puis vérifier si cela améliore les choses en TCP mono connexion.
C'est juste une suggestion.
-
Faudrait faire une capture entre l'ONU et la box pour voir ce qui ce passe et/ou utiliser iperf3 en UDP pour mesurer le taux de perte de paquets.
-
iperf3.exe -6 -c ping6.online.net -p 5208 -P1 -b 0
Connecting to host ping6.online.net, port 5208
[ 4] local 2a01:e0a:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx port 50305 connected to 2001:bc8:1::40 port 5208
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-1.00 sec 28.9 MBytes 241 Mbits/sec
[ 4] 1.00-2.00 sec 29.4 MBytes 247 Mbits/sec
[ 4] 2.00-3.00 sec 29.2 MBytes 246 Mbits/sec
[ 4] 3.00-4.00 sec 29.5 MBytes 248 Mbits/sec
[ 4] 4.00-5.01 sec 30.0 MBytes 250 Mbits/sec
[ 4] 5.01-6.01 sec 30.0 MBytes 252 Mbits/sec
[ 4] 6.01-7.00 sec 29.2 MBytes 247 Mbits/sec
[ 4] 7.00-8.00 sec 29.8 MBytes 249 Mbits/sec
[ 4] 8.00-9.01 sec 29.8 MBytes 249 Mbits/sec
[ 4] 9.01-10.00 sec 29.1 MBytes 245 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-10.00 sec 295 MBytes 247 Mbits/sec sender
[ 4] 0.00-10.00 sec 295 MBytes 247 Mbits/sec receiver
iperf Done.
iperf3.exe -6 -c ping6.online.net -p 5208 -P1 -u -b 0
Connecting to host ping6.online.net, port 5208
[ 4] local 2a01:e0a:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx port 56557 connected to 2001:bc8:1::40 port 5208
[ ID] Interval Transfer Bandwidth Total Datagrams
[ 4] 0.00-1.00 sec 112 MBytes 937 Mbits/sec 14300
[ 4] 1.00-2.00 sec 111 MBytes 935 Mbits/sec 14270
[ 4] 2.00-3.00 sec 111 MBytes 935 Mbits/sec 14270
[ 4] 3.00-4.00 sec 111 MBytes 935 Mbits/sec 14270
[ 4] 4.00-5.00 sec 111 MBytes 935 Mbits/sec 14260
[ 4] 5.00-6.00 sec 111 MBytes 935 Mbits/sec 14270
[ 4] 6.00-7.00 sec 111 MBytes 935 Mbits/sec 14270
[ 4] 7.00-8.00 sec 111 MBytes 935 Mbits/sec 14270
[ 4] 8.00-9.00 sec 111 MBytes 935 Mbits/sec 14270
[ 4] 9.00-10.00 sec 111 MBytes 935 Mbits/sec 14270
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[ 4] 0.00-10.00 sec 1.09 GBytes 935 Mbits/sec 0.000 ms 0/0 (0%)
[ 4] Sent 0 datagrams
iperf Done.
-
iperf-3.1.3-win64
Les tests réalisés avec le -R sont complètements incohérents quelque soit le serveur !!! :-[ D'ailleurs je ne comprends pas, si ce sont des tests en upload que j'ai réalisé, comment je peux avoir 935 Mbps de bande passante ?
Une ligne de commande complète à me suggérer ?
-
D'ailleurs je ne comprends pas, si ce sont des tests en upload que j'ai réalisé, comment je peux avoir 935 Mbps de bande passante ?
Ben c'est de l'UDP, il n'y a aucun contrôle de flux en UDP. La machine envoi à son max, mais évidemment que tout ne passe pas réellement. D'où la remarque qu'il manque une ligne dans le résultat, ce que le serveur a réellement reçu, sinon aucun intérêt.
-
oui le test iperf3 en udp n'a d'intérêt que si on voit la perte.
vu le cas ici, il faut faire un test avec -R. et j'éviterais d'utiliser -b 0, plutôt demander 900 Mbps par exemple (-b 900M) et monter ensuite au max -5% de l'abonnement.
par exemple:
iperf3.exe -6 -c ping6.online.net -p 5208 -b 900M -R
iperf3.exe -6 -c bouygues.testdebit.info -p 9240 -b 900M -R
il faut aussi s'assurer que la machine gère bien le haut débit en UDP, surtout sous Windows, idéalement via un test en LAN.
Car j'ai le cas sur une machine Windows qui réceptionne a 9Gbps en TCP mono flux depuis un serveur Linux sur le LAN mais qu'a 500 Mbps en UDP...et d'ailleurs ce même serveur n'émet qu'a 3.7 Gbps en UDP.
Linux --lien Ethernet 10 Gbps-->Windows
iperf3 -R -b0 -u depuis le Windows:
[ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams
[ 5] 0.00-10.00 sec 4.32 GBytes 3.71 Gbits/sec 0.000 ms 0/3176140 (0%) sender
[ 5] 0.00-10.00 sec 794 MBytes 666 Mbits/sec 0.025 ms 2605339/3175675 (82%) receiver
le meme iperf3 sans -u -b0 donc en TCP:
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 10.5 GBytes 9.01 Gbits/sec 0 sender
[ 5] 0.00-10.00 sec 10.5 GBytes 9.00 Gbits/sec receiver
c'est probablement une histoire de 'taille de tampon réception UDP' qui pose notamment des problème a QUIC(HTTP/3): https://github.com/lucas-clemente/quic-go/wiki/UDP-Receive-Buffer-Size
l'application peut y remédier parfois mais pour iperf3 j'en sais rien (l'option -w ne fait rien et de toute facon iperf3 et Windows c'est pas trop ca...).
-
Salut à tous!
Venant de prendre une offre freebox revolution en FTTH apres être parti de chez red (aussi en FTTH), je me rends compte que:
-impossible de mettre cette V6 en mode bridge en FTTH (dixit le 3244)
-connexion bridée en TCP.
Je ne comprenais pas pourquoi un simple test de débit sur quechoisir.fr pouvait montrer un chiffre aussi bas en DL (245Mb/sec) alors que sur speedtest.net j'étais bien à 1Gbps.
Et je suis tombé sur ce post apres avoir réalisé un petit test via curl qui m'indiquait être à 5,5Mo/sec...
j'ai donc lancé le script, en ethernet, sans rien d'autre que mon pc (i7-7700, 16Go de ram, full ssd, le tout sous linux) connecté à la box, wifi désactivé.
Et j'obtiens ça:
[checkBugOnuFree v0.9] Linux 5.4.0-97-generic (x86_64)
--------------------------- 2022-02-03 13:31:23 GMT ---------------------------
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: 189549 252734 379098
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
Test TCP local (Freebox)...
--> Latence: 0.45 ms
--> Débit: 76.20 Mo/s (609.60 Mbps)
Test TCP Internet (AS12876-BBR)...
--> Latence: 6.06 ms
--> Débit: 32.66 Mo/s (261.27 Mbps)
[!] La connexion semble affectée par un dysfonctionnement de boîtier ONU Free.
--------------------------- 2022-02-03 13:32:11 GMT ---------------
J'ai contacté free sur ce probleme (galère de rappatrier des gros fichiers via filezilla dans ces conditions...), qui ne semble pas au courant de ce probleme.
Ils vont surveiller ma ligne durant 72h, sans plus.
Avons-nous un recours?
-
Déjà tu peux t'inscrire sur dev.freebox.fr (https://dev.freebox.fr/bugs/task/36238), voter pour la tâche et remonter ton propre test iperf3 (attention à ne pas oublier le -R lors de l'essai)
-
Je viens de déterrer mon compte bugtracker (j'avais encore un mail de contact en @voila.fr c'est dire...).
Je ne vois pas comment voter pour faire remonter une tâche par contre.
Quels tests sous iperf faut-il faire exactement?Tous comme ce qu'a fait mog54?
-
Je ne vois pas comment voter pour faire remonter une tâche par contre.
Il suffit de cliquer sur le nombre à côté de "Vote"
Quels tests sous iperf faut-il faire exactement?Tous comme ce qu'a fait mog54?
Oui
-
Ah oui, je m'attendais à voir un truc en plus grand...
par contre j'ai posté que les tests en TCP, mono et multi...J'avais validé avant ta réponse.
-
Et j'obtiens ça:
[checkBugOnuFree v0.9] Linux 5.4.0-97-generic (x86_64)
--------------------------- 2022-02-03 13:31:23 GMT ---------------------------
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: 189549 252734 379098
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
...
--------------------------- 2022-02-03 13:32:11 GMT ---------------
C'est l'installation par défaut d'un système Linux qui vous fait hériter de tels paramètres ?
Edit: grammaire
-
Oula non, là je tourne sous une ubuntu 20.04.3 LTS.
Et ça fait un moment que je n'ai pas formaté...
ces paramètres sont incorrects?
Comment les modifier? Les réinitialiser?
Merci!
-
Je ne vois pas bien le problème, ces paramètres par défaut sur un nunux n'ont rien de particulier.
Le fait que la gestion de congestion soit en cubic par défaut n'a pas beaucoup d'importante, sauf si c'est le nunux l'émetteur de données...
J'ai une install fresh d'un nunux Ubuntu Desktop 20.04 dans une VM, et le paramétrage est ainsi...
-
les valeurs par défauts de la plupart des distribs Linux ne sont pas trop opti pour le tres haut débit (> 1 Gbps).
net.core.rmem_max est trop faible la par exemple.
-
les valeurs par défauts de la plupart des distribs Linux ne sont pas trop opti pour le tres haut débit (> 1 Gbps).
net.core.rmem_max est trop faible la par exemple.
Ok, merci pour tous!
-
Oula non, là je tourne sous une ubuntu 20.04.3 LTS.
Et ça fait un moment que je n'ai pas formaté...
ces paramètres sont incorrects?
Comment les modifier? Les réinitialiser?
Merci!
Pour l'instant, si vous avez ouvert un incident et si vous tombez sur un support compétent, ce dernier sera sans doute plus à l'aise si votre config est standard/par défaut.
Pour ce qui est des paramètres, ils correspondent à une utilisation et ne sont pas incorrects vis-à-vis de cette dernière. Ce n'est pas forcément ce que vous voulez en faire.
Dans le cas très précis du téléchargement de gros fichiers sur lien 1G+ à faible latence, vous avez un jeu de valeurs non optimales (net.ipv4.tcp_rmem: 4096 131072 6291456 et probablement désactivation de net.ipv4.tcp_sack: 1). Une fois votre problème réglé vous pourrez vous intéresser à ce décalage de la fenêtre tcp. Ca risque d'être néanmoins vain si la cause de limitation de débit fourni par les appareils du FAI n'est pas clairement documentée.
Voilà, grippe de classe galactique et fièvre, j'espère ne pas avoir trop dit de bétises.
-
Franchement, pas sur que ces réglages changent grand chose, car obljectivement, quand j'étais chez RED et meme chez free avec l'ONU V1, je n'avais strictement aucun probleme.
Là il faut avouer que rapatrier un fichier via Filezilla ou un simple téléchargement par un navigateur et etre bridé à 5Mo/sec quand on est fibré, c'est super rageant.
Et je ne comprends pas comment ce type de probleme peut encore perdurer...
-
Franchement, pas sur que ces réglages changent grand chose, car obljectivement, quand j'étais chez RED et meme chez free avec l'ONU V1, je n'avais strictement aucun probleme.
C'est bien ce que je vous dis noir sur blanc, réglez votre problème d'abord, vous verrez pour ces autres paramètres après.
Edit: grammaire
-
Alors, j'ai poussé les tests plus loin, histoire d'être sûr.
Voici ce que j'obtiens de base actuellement sur mon ubuntu 20.04.3 LTS:
Nperf global de ma connexion:
(https://zupimages.net/up/22/05/u5pl.png) (https://zupimages.net/viewer.php?id=22/05/u5pl.png)
Speedtest.net en multi:
(https://zupimages.net/up/22/05/ak4a.png) (https://zupimages.net/viewer.php?id=22/05/ak4a.png)
Speedtest.net en mono:
(https://zupimages.net/up/22/05/g32v.png) (https://zupimages.net/viewer.php?id=22/05/g32v.png)
Speedtest sur quechoisir.fr:
(https://zupimages.net/up/22/05/a9m0.png) (https://zupimages.net/viewer.php?id=22/05/a9m0.png)
Un simple wget montre un pb:
kkwete@kkwete:~$ wget http://test-debit.free.fr/1048576.rnd
--2022-02-06 15:48:12-- http://test-debit.free.fr/1048576.rnd
Résolution de test-debit.free.fr (test-debit.free.fr)... 212.27.42.153, 2a01:e0c:1:1598::3
Connexion vers test-debit.free.fr (test-debit.free.fr)|212.27.42.153|:80... connecté.
requête HTTP transmise, en attente de la réponse... 200 OK
Taille : 1073741824 (1,0G)
Enregistre : «1048576.rnd.4»
1048576.rnd.4 100%[===================>] 1,00G 5,37MB/s ds 3m 12s
2022-02-06 15:51:24 (5,34 MB/s) - «1048576.rnd.4» enregistré [1073741824/1073741824]
Comme j'ai un dualboot sur mon pc, j'ai aussi un Windows 10 à 64bit à jour qui tourne sur un autre SSD.
Les résultats sont identique.
J'en ai profité pour lancer le script en perl sous windows donc:
checkBugOnuFree v0.9] Windows 10 Build 19044 (64-bit)
--------------------------- 2022-02-06 11:53:53 GMT ---------------------------
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 (Freebox)...
--> Latence: 1.33 ms
--> Débit: 118.21 Mo/s (945.65 Mbps)
Test TCP Internet (AS12876-BBR)...
--> Latence: 6.79 ms
--> Débit: 32.81 Mo/s (262.51 Mbps)
[!] La connexion semble affectée par un dysfonctionnement de boîtier ONU Free.
--------------------------- 2022-02-06 11:54:46 GMT ---------------------------
Appuyer sur Entrée pour quitter...
J'ai changé ja jaretière optique, idem.
Changer le cable ethernet n'a bien évidemment rien changé non plus.
J'ai booté sur un liveUSB d'ubuntu pour tester:
ubuntu-budgie@ubuntu-budgie:~/Desktop$ perl checkBugOnuFree.pl
===============================================================================
checkBugOnuFree
---------------
Programme de diagnostique de connexion FTTH Free avec boîtier ONU
Ce programme effectue des tests de débit en mono-session TCP afin d'évaluer la
possibilité que la connexion FTTH soit affectée par un dysfonctionnement du
boîtier ONU Free.
Il est aussi possible d'utiliser ce programme sur une infrastructure sans
Freebox pour comparer les résultats, à condition de désactiver le test de débit
local via le paramètre --skip-lan-check (voir --help pour plus d'information).
Avant de continuer, veuillez vérifier que rien d'autre ne consomme de la bande
passante sur le réseau (ordinateurs, Freebox player, télévision...), ni du CPU
sur le système de test (mises à jour automatiques, antivirus...).
===============================================================================
Appuyer sur Entrée pour continuer (ou Ctrl-C pour annuler)...
[checkBugOnuFree v0.9] Linux 5.11.0-27-generic (x86_64)
--------------------------- 2022-02-06 12:43:20 GMT ---------------------------
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: 188973 251965 377946
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
Test TCP local (Freebox)...
--> Latence: 0.40 ms
--> Débit: 75.04 Mo/s (600.30 Mbps)
Test TCP Internet (AS12876-BBR)...
--> Latence: 6.18 ms
--> Débit: 32.48 Mo/s (259.84 Mbps)
[!] La connexion semble affectée par un dysfonctionnement de boîtier ONU Free.
--------------------------- 2022-02-06 12:44:08 GMT ---------------------------
ubuntu-budgie@ubuntu-budgie:~/Desktop$
le wget est identique à ma session linux installée, ainsi que tous les speedtests.
Donc en gros, windows ou linux, live session ou pas, même combat!
Une amie vient en soirée avec son ONU v1 pour que je puisse tester.
On verra!
Mais je me doute du résultat...
-
Il ne me semble pas que les ONU soient interchangeables, à mon avis vous n'allez pas pouvoir tester.
-
Il ne me semble pas que les ONU soient interchangeables, à mon avis vous n'allez pas pouvoir tester.
Il m'a semblé effectivement que cela a été déjà testé...
Quant aux tests avec les speedtest et autres douceurs, tout dépend du choix du serveur... En étant chez Free, les speedtests sur Bouygues Meudon en BBR ou la fibre.info Massy en BBR donnent des résultats relativement reproductibles. En passant, mieux vaut éviter les heures de pointe, car même sur ces serveurs, cela peut chuter pas mal! Depuis Free vers des serveurs chez Orange, pas glop!
-
Oui mais là les débits sont trop concordants.
Ca me fait exactement pareil du serveur dédié que je loue...
Les wget sont réalisés sur des serveurs de chez free.
Et c'est bien la première fois que je vois de tels débits!
Je n'ai jamais eu ça avant.
Quels tests pourrais-je réaliser pour être sûr de l'origine du problème?
-
Et en effet, je viens de tester un ONU V1.
Non détecté.
je m'en doutais un peu, car tous les techniciens enregistrent sur le réseau le matos utilisé chez le client...
Dommage...!
-
Quels tests pourrais-je réaliser pour être sûr de l'origine du problème?
A part essayer de faire changer l'ONU je ne vois pas trop ce que tu peux faire...
-
Des nouvelles du front... Lâchement, j'ai abandonné mes coreligionnaires d'ONU V2 et je suis passé à la Freebox PoP... Honte à moi! Mais... bien sûr plus de problème d'ONU V2...
Par acquit de conscience, j'ai repassé le petit programme checkBugOnuFree v0.9, et bien sûr, tout est clean...
J'avais un peu délaissé le sujet, je quitterais Free à la fin du mois pour aller chez Orange finalement.
Le service client a fini d'enfoncer le clou en m'annonçant ne pas fournir de solution de dépannage en cas d'accident majeur sur la fibre (un chantier ayant sectionné l'arrive à un point de distribution pour ma ville et celles des environs ...). Quatre jours en mode survie sur le forfait 4G quand on est en télétravail, ça le fait pas, surtout quand on bosse dans l'info.
Donc le problème de l'ONU se résoudra de lui-même.
Courage aux autres en tout cas et j'espère que Free se bougera les fesses.
-
A part essayer de faire changer l'ONU je ne vois pas trop ce que tu peux faire...
Toujours personne pour tester mon idée de limiter via un autre QOS externe à l'ONU (un PC ou un routeur) le débit d'une session TCP à par exemple 500Mbps ?
Ceci afin que la perte de paquets ne soit pas fait par l'ONU mais par le PC... et potentiellement "perdre des paquets comme il faut" pour TCP.
-
Toujours personne pour tester mon idée de limiter via un autre QOS externe à l'ONU (un PC ou un routeur) le débit d'une session TCP à par exemple 500Mbps ?
Ceci afin que la perte de paquets ne soit pas fait par l'ONU mais par le PC... et potentiellement "perdre des paquets comme il faut" pour TCP.
Perso, suis partant, si tu me dis comment faire!
-
J'ai un problème similaire avec BGYTEL quand j'utilise mon ONT perso (avec la bbox tout se passe bien) - mon upload en TCP reste bridé à 300M au lieu des 600M attendus
Je viens de faire un test avec la QOS activée sur mon upload et j'ai pas réussi à faire plus que 300M.
-
Je pense avoir en fait un double probleme car, si je relance le script sur ma machine, que cela soit sous linux ou windows 10, j'obiens systématiquement ce résultat, indépendamment de l'heure:
kkwete@kkwete:~/Bureau$ perl checkBugOnuFree.pl
===============================================================================
checkBugOnuFree
---------------
Programme de diagnostique de connexion FTTH Free avec boîtier ONU
Ce programme effectue des tests de débit en mono-session TCP afin d'évaluer la
possibilité que la connexion FTTH soit affectée par un dysfonctionnement du
boîtier ONU Free.
Il est aussi possible d'utiliser ce programme sur une infrastructure sans
Freebox pour comparer les résultats, à condition de désactiver le test de débit
local via le paramètre --skip-lan-check (voir --help pour plus d'information).
Avant de continuer, veuillez vérifier que rien d'autre ne consomme de la bande
passante sur le réseau (ordinateurs, Freebox player, télévision...), ni du CPU
sur le système de test (mises à jour automatiques, antivirus...).
===============================================================================
Appuyer sur Entrée pour continuer (ou Ctrl-C pour annuler)...
[checkBugOnuFree v0.9] Linux 5.4.0-99-generic (x86_64)
--------------------------- 2022-02-09 06:26:22 GMT ---------------------------
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: 189549 252734 379098
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
Test TCP local (Freebox)...
--> Latence: 0.50 ms
--> Débit: 76.71 Mo/s (613.66 Mbps)
Test TCP Internet (AS12876-BBR)...
--> Latence: 6.27 ms
--> Débit: 85.78 Mo/s (686.22 Mbps)
Test TCP Internet (AS12876-CUBIC)...
--> Latence: 6.07 ms
--> Débit: 4.95 Mo/s (39.59 Mbps)
La connexion ne semble pas affectée par un dysfonctionnement de boîtier ONU Free mais présente tout de même des performances dégradées.
La connexion semble affectée par une congestion réseau prononcée.
=> VERIFIER QUE RIEN D'AUTRE NE CONSOMME DE LA BANDE PASSANTE (RELANCER LE TEST LE CAS ECHEANT)
--------------------------- 2022-02-09 06:27:35 GMT ---------------------------
kkwete@kkwete:~/Bureau$
Je viens de réaliser le test à l'instant, après avoir réinitialisé la V6 et désactivé le wifi. Seul mon PC est connecté en ethernet.
Speedtest.net en single me donne aussi un débit descendant de 35Mbps, alors qu'en multi je suis à 930.
le speedtest de quechoisir me donne 150Mbps, et iperf me donne un score de 190000, avec un DL de 931Mbps sur un serveur free de 40Gbps.
En pratique, dès que je télécharge via un navigateur, je plafonne à 5Mo/sec, pile poil dans les 40bps retrouvés par le sript en perl.
par contre, le ping est tout à fait normal, entre 5 et 7ms, idem pour l'UL à environ 700Mbps.
Au final, je suis très en dessous du débit même problématique en lien avec les ONU V2. savez-vous d'où ça pourrait venir?Les ONU pourraient être aussi la cause d'une telle dégradation de performances?
Car à l'usage c'est vraiment pas terrible...
Je viens de signer pour l'offre freebox FTTH à 10€/mois alors que j'étais chez RED pour le double il y a encore une semaine. Je n'avais pas ce type de probleme.
Il ya 6 mois, j'avais la meme offre freebox qu'actuellement, sauf que j'avais un ONU V1 et je n'avais là non plus aucun soucis.
Je suis preneur de toute idée/suggestions car j'ai contacté free hier, je suis au dessus des 30Mbps donc tout va bien pour eux ( :o :o :o :o).
-
Hello!
Tous les tests ont été réalisé avec le même pc, une tour perso orientée gaming. Pas de wifi, tous les tests ont été réalisés en ethernet, carte en gigabit.
Au niveau de l'ONU, j'ai bien le V2, le modèle plat.
Mais je dois reconnaître que j'ai réalisé un truc, j'ai tenté, en désespoir de cause, un reset de l'ONU, via le bouton reset sur l'arrière. Cela a forcé une mise à jour du boîtier.
Ça a peut-être joué. Par contre, ça n'a eu aucune incidence sur le dl via le navigateur. Je plafonné toujours à 5Mo/sec dans ce cas de figure.
Vous pouvez tenter le truc si vous le souhaitez, mais c'est à vos risques et périls! 😄
-
Ce bouton là ?
https://www.busyspider.fr/Images/freebox_onu_v2_cote_bouton_reset.png
Intéressant...
Tout à fait.
Appuyer sur le bouton ONU débranché. Le rebrancher en gardant la pression sur le bouton. Perso j'ai attendu 10 sec pour être sûr.
Relâcher le bouton. Débrancher et rebrancher si besoin. Attendre. la led au dessus de l' entrée fibre va clignoter un moment (MAJ en cours donc), puis passer au vert.
Et tout fonctionne.
-
Est-ce que d'autres personnes avec un ONU v2 ont tenté la technique du bouton reset pour forcer une maj du coup ?
Le reset n'a rien changé. On voit bien que la LED au dessus de la fibre se met à clignoter en vert, ensuite passe rouge, puis s'éteint (reboot après update ?) puis revient, clignote brièvement et se fixe. Mais le problème est tjrs là.
-
Toujours personne pour tester mon idée de limiter via un autre QOS externe à l'ONU (un PC ou un routeur) le débit d'une session TCP à par exemple 500Mbps ?
Ceci afin que la perte de paquets ne soit pas fait par l'ONU mais par le PC... et potentiellement "perdre des paquets comme il faut" pour TCP.
J'ai fait quelques essais avec différents réglages en utilisant Net Limiter 4 sur mon PC: rien de concluant...
-
J'ai fait quelques essais avec différents réglages en utilisant Net Limiter 4 sur mon PC: rien de concluant...
Ok, bon je pensais que laisser le PC "contrôler" la perte de paquet permettait de démontrer que c'est au mauvaise perte de paquets au niveau de l'ONU qui bride.
Et sinon faire un test avec une MTU plus petite (genre 1300) cela pourrait peut être avoir un effet (paquet plus petit = plus de paquets acceptés dans la mémoire transitoire des contrôleur ethernet=> peut-être moins de perte).
Et enfin un tcpdump/wireshark d'un flux bridé devrait permettre de voir s'il y a un schéma qui se reproduit sur les pertes de ACK non ? Si quelqu'un (@vivien?) saurait analyser cela.
-
Perso, suis partant.
Par contre, va falloir me dire quoi faire exactement...
-
Sinon des ONUV1 sont dispo sur ebay
https://www.ebay.fr/itm/224779268039
-
Sinon des ONUV1 sont dispo sur ebay
https://www.ebay.fr/itm/224779268039
Sauf qu'ils ne fonctionneront pas car pas associés avec la ligne...
-
Sauf qu'ils ne fonctionneront pas car pas associés avec la ligne...
Ce n'est pas comme SFR. Uniquement avec le OLID :-\
-
??? Pas en zone RIP.
-
??? Pas en zone RIP.
On peut vérifier par le site de l'acrep si on est en zone RIP?
-
D'ailleurs je dirais même: pas en zone PON, car il faut que l'ONU s'identifie sur l'arbre PON.
-
D'ailleurs je dirais même: pas en zone PON, car il faut que l'ONU s'identifie sur l'arbre PON.
c'est quoi ca PON?
-
https://www.viavisolutions.com/fr-fr/reseau-optique-passif-pon
-
J'ai joué avec le MTU grâce à TCP Optimizer, mais ça n'a aucun effet non plus.
Même si je n'y crois pas, je n'ai pas encore testé le hard reset de l'ONU pour des raisons de... paix familiale !
-
Hard reboot effectué, toujours pareil.
-
Bonjour a tous,
la même ici, ONU V2 et ...
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.7M 0 0:00:33 0:00:33 --:--:-- 26.4M
-
Bonjour a tous,
la même ici, ONU V2 et ...
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.7M 0 0:00:33 0:00:33 --:--:-- 26.4M
-> https://dev.freebox.fr/bugs/task/36238 copie-colle ton résultat et vote pour la tâche.
Je vais tenter de voir si je peux pas alerter plus haut chez Free...
-
Je ferai ca quand je recevrai enfin le code pour l'inscription :D
Edit : si je le recois un jour :D
-
Bon, j'ai réussi à me faire repasser sur un ONU v1.
les tests iperf sont bon, le checkBugOnuFree.exe est bof bof en CUBIC.
[checkBugOnuFree v0.9] Windows 10 Build 19044 (64-bit)
--------------------------- 2022-02-23 14:29:48 GMT ---------------------------
Paramétrage réseau actuel du système:
AutoTuningLevelLocal: Normal
CongestionProvider: CTCP
EcnCapability: Disabled
NetworkCategory: Public
ScalingHeuristics: Disabled
Timestamps: Disabled
=> Latence TCP max pour une réception à 1 Gbps: 141 ms
Test TCP Internet (AS12876-BBR)...
--> Latence: 8.84 ms
--> Débit: 101.66 Mo/s (813.26 Mbps)
Test TCP Internet (AS12876-CUBIC)...
--> Latence: 8.57 ms
--> Débit: 5.91 Mo/s (47.31 Mbps)
--------------------------- 2022-02-23 14:30:39 GMT ---------------------------
si je monte un VPN UDP voilà le résultat
[checkBugOnuFree v0.9] Windows 10 Build 19044 (64-bit)
--------------------------- 2022-02-23 15:24:20 GMT ---------------------------
Paramétrage réseau actuel du système:
AutoTuningLevelLocal: Normal
CongestionProvider: CUBIC
EcnCapability: Disabled
NetworkCategory: Public,Public
ScalingHeuristics: Disabled
Timestamps: Disabled
=> Latence TCP max pour une réception à 1 Gbps: 141 ms
Test TCP Internet (AS12876-BBR)...
--> Latence: 18.35 ms
--> Débit: 51.27 Mo/s (410.13 Mbps)
Test TCP Internet (AS12876-CUBIC)...
--> Latence: 18.18 ms
--> Débit: 47.61 Mo/s (380.92 Mbps)
--------------------------- 2022-02-23 15:25:11 GMT ---------------------------
Si on sort du monde des tests, et qu'on fait une utilisation "normale", je me retrouve a être bloqué à 40-50Mbs sur un serveur où je montais au 1Gbs avant mon passage chez Free...
Il y pas vraiment à débattre, Free c'est quand même bien à chier.
-
Bizarre le : CongestionProvider: CTCP sans vpn, tu n'aurais pas bidouillé quelques niveau tpc dans ton os ?
-
Bizarre le : CongestionProvider: CTCP sans vpn, tu n'aurais pas bidouillé quelques niveau tpc dans ton os ?
Alors oui c'est possible mais le ctcp c'est moi qui l'ai fait avant le test. voilà sans. Par contre c'est possible que j'ai touché avant à des options dans ma carte réseau sur Windows.
Je test de reset tout ca
[checkBugOnuFree v0.9] Windows 10 Build 19044 (64-bit)
--------------------------- 2022-02-23 15:50:46 GMT ---------------------------
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 Internet (AS12876-BBR)...
--> Latence: 8.60 ms
--> Débit: 79.20 Mo/s (633.59 Mbps)
Test TCP Internet (AS12876-CUBIC)...
--> Latence: 8.48 ms
--> Débit: 5.89 Mo/s (47.10 Mbps)
--------------------------- 2022-02-23 15:51:37 GMT ---------------------------
-
Bon, j'ai réussi à me faire repasser sur un ONU v1.
Comment as-tu fais si ce n'est pas indiscret ?
-
J'ai acheté un onu v1 sur ebay => 13E
j'ai testé de le branché => ca n'a pas marché
J'ai créer des faux problemes sur ma ligne pour faire venir un tech free.
Je lui ai demandé de me mettre l'onu v1 en croisant fort les doigts
Que des choses qu'on devrait pas avoir à faire pour avoir une connexion internet parfaitement fonctionnelle...
-
Concernant le débit médiocre en CUBIC, c'est juste le reflet de la saturation du réseau de collecte utilisé par Free (cf ces graphs (https://lafibre.info/1gb-free/debits-ftth-faibles-freebox-revolution/msg912502/#msg912502) pour une bonne illustration du problème...)
C'est un problème complètement indépendant du souci de l'ONU v2 dont il est question sur ce fil de discussion.
Il est complètement normal que le changement d'ONU n'ait pas amélioré ton débit en CUBIC si celui-ci était déjà en dessous de 30Mo/s de base.
Je comprends bien, mais à quel moment Free peut proposer du 1Gbs ou même du 10Gbs quand tu tiens pas 50Mbs. Globalement, maintenant je vais subir jusque la fin de l'engament et finito après.
Faut leurs laisser encore un bonne dizaines, le temps qu'ils arrivent à créer un réseau fiable
Je suis entrain de poc le passage au BBR sur mon serveur pour me débloquer.
-
Si on sort du monde des tests, et qu'on fait une utilisation "normale", je me retrouve a être bloqué à 40-50Mbs sur un serveur où je montais au 1Gbs avant mon passage chez Free...
Il y pas vraiment à débattre, Free c'est quand même bien à chier.
Je rencontre exactement le même probleme:
https://lafibre.info/1gb-free/debit-limite-a-5mosec/
C'est juste du n'importe quoi...
Quand j'étais chez red, j'étais toujours à 120Mo/sec. Là, je suis à 5...Super pratique avec mon serveur pour les échanges de fichiers... >:(
Et en plus, je ne peux même pas résilier?
changer de box (pop ou 4K) changerait quelque chose ou c'est vraiment une limitation réseau?
Car de mon point de vue, c'est complètement imcompréhensible que free tienne cette position...
-
C'est un problème récurrent propre à certaines portions du réseau de Free (qui évoluent dans le temps en fonction des augmentations de capacité), par exemple moi je ne suis pas touché en ce moment (103 Mo/s en cubic actuellement sur une seule connexion avec une Freebox Révolution). Changer de modèle de Freebox ne changera rien.
-
Ok, merci pour cette réponse très claire!
Ce problème serait un motif de résiliation par hasard?
Car c'est proprement mensongé et clairement un problème technique de leur part...
-
J'avoue ne pas être très au fait des possibilités légales pour résilier sans frais dans ce genre de cas. Ce qui est certain c'est que Free s'engage dans ses CGV à un débit minimal qui est ridicule.
-
Bonjour,
Bon je sais que c'est le TOPIC ici c'est pour le problème avec ONU V2 mais nombreux sont aussi concernés par la congestion du réseau. (ou les deux)
Je relance le sujet sur le devblog free !
Bon we.
-
-> https://dev.freebox.fr/bugs/task/36238 copie-colle ton résultat et vote pour la tâche.
Je vais tenter de voir si je peux pas alerter plus haut chez Free...
Je ferai ca quand je recevrai enfin le code pour l'inscription :D
Edit : si je le recois un jour :D
Toujours pas reçu le code pour m'inscrire ... c'est long :D
-
L'inscription est instantanée.
Une faute de frappe ? 😇
-
Ah ben la c'est sûr!
Ou le dossier spams?
-
Non non, j'ai refais, ca me dis que ca m'envoie un code par mail, et je recois pas de mail ...
Je testerai sur un autre mail quand mon pseudo sera a nouveau "libéré"
-
Je relance le sujet sur le devblog free !
Tu as un lien?
Car honnetement, c'est insupportable...
-
Tu as un lien?
Car honnetement, c'est insupportable...
https://dev.freebox.fr/bugs/task/36440
Mais sujet clos ... car pas un beg mais un problème réseau !!
-
Alors là... les bras m'en tombent...
A la recherche d'une séquence magique j'ai -encore- tenté sans succès un reboot de l'ONU v2 ce matin (procédure: débranché, appui sur bouton reset, rebranché, bouton reset maintenu 5s, puis 3s après une nouvelle coupure d'alim, on voit bien l'ONU qui recharge un nouveau firmware).
A l'instant j'étais en train de télétravailler et je subis une coupure de la connexion Internet. Je sors dehors à la recherche d'un technicien indélicat (la zone est fraîchement couverte, donc c'est la période faste des raccordements)... rien
Je remonte à mon PC, je lance un CheckBugOnuFree et...
[checkBugOnuFree v0.9] Windows 10 Build 19044 (64-bit)
--------------------------- 2022-03-14 09:16:14 GMT ---------------------------
Paramétrage réseau actuel du système:
AutoTuningLevelLocal: Normal
CongestionProvider: CUBIC
EcnCapability: Enabled
NetworkCategory: Private
ScalingHeuristics: Disabled
Timestamps: Disabled
=> Latence TCP max pour une réception à 1 Gbps: 141 ms
Test TCP local (Freebox)...
--> Latence: 0.51 ms
--> Débit: 118.50 Mo/s (947.99 Mbps)
Test TCP Internet (AS12876-BBR)...
--> Latence: 6.48 ms
--> Débit: 106.33 Mo/s (850.62 Mbps)
Test TCP Internet (AS12876-CUBIC)...
--> Latence: 6.27 ms
--> Débit: 108.41 Mo/s (867.26 Mbps)
La connexion ne semble pas affectée par un dysfonctionnement de boîtier ONU Free.
--------------------------- 2022-03-14 09:17:30 GMT ---------------------------
Appuyer sur Entrée pour quitter...
Sachant que la coupure a durée moins longtemps que le temps nécessaire au flashage de l'ONU (qui est trèèès long).
Free ferait-il des MAJ des ONU v2 petit à petit ? C'est l'explication la plus probable. :o
-
Intéressant, sans doute un déploiement de MAJ effectivement :)
Après ce n'est peut-être pas le boîtier ONU qui est flashé, peut-être qu'une MAJ est déployée côté OLT pour améliorer la compatibilité avec les boîtiers ONU v2...
Mise à jour olt en journée, très peu probable.
-
Fabrice49 tu avais contacté le support Free concernant le souci ? (ou donné des informations quelque part permettant d'identifier ta ligne ?)
Absolument pas !
-
Oui c'est sûr ça paraît étonnant, peut-être une expérimentation restreinte à sa ligne alors...
Fabrice49 tu avais contacté le support Free concernant le souci ? (ou donné des informations quelque part permettant d'identifier ta ligne ?)
Il y a un autre abonné sur le forum qui a eu sa connexion débridée avec ONU v2.
-
Tu veux parler de piwi (https://lafibre.info/1gb-free/debits-ftth-faibles-freebox-revolution/msg912426/#msg912426) ?
Oui, c'est le seul autre cas à ma connaissance de boîtier ONU v2 qui ne serait pas touché par le problème (mais par d'autres problèmes de stabilité de débit d'après ces messages et résultats...).
Mais le cas de piwi est un peu différent, car a priori il n'a jamais été touché par le problème spécifique des boîtiers ONU v2, à la différence de Fabrice49 pour qui le problème était bien présent et est parti soudainement suite à une coupure ce matin...
Euh non je parle de kkwete, du coup ça fait 3 😅
-
Le plus surprenant, c'est que cette fameuse déconnexion/reconnexion a eu lieu au moins 1h30 après mon essai infructueux.
Donc ça ne semble pas vraiment lié, mais la chronologie reste troublante. C'est peut-être simplement un hasard...
- Vu le temps de coupure (10s d'après les logs Freebox) il n'y a pas eu re flashage de l'ONU
- Ca m'étonnerait aussi fort que Free fasse des MAJ des OLT en journée; et même sur l'ONU d'ailleurs même si c'est simplement lui faire prendre un nouveau fichier de configuration.
Serait-ce le fait de s'acharner sur ce maudit bouton Reset ?
Tout cela est bien mystérieux à mon goût. ::)
-
Le plus surprenant, c'est que cette fameuse déconnexion/reconnexion a eu lieu au moins 1h30 après mon essai infructueux.
Donc ça ne semble pas vraiment lié, mais la chronologie reste troublante. C'est peut-être simplement un hasard...
- Vu le temps de coupure (10s d'après les logs Freebox) il n'y a pas eu re flashage de l'ONU
- Ca m'étonnerait aussi fort que Free fasse des MAJ des OLT en journée; et même sur l'ONU d'ailleurs même si c'est simplement lui faire prendre un nouveau fichier de configuration.
Serait-ce le fait de s'acharner sur ce maudit bouton Reset ?
Tout cela est bien mystérieux à mon goût. ::)
Si tu redemarres électriquement le tout, les débits sont les mêmes ?
-
Ben d'habitude je suis joueur, mais là j'ai pas envie !
Si on en croit l'expérience de kkwete qui est quand même très proche de la mienne, ça devrait se maintenir.
Mais ne t'inquiète pas, vu la qualité du réseau électrique ici Enedis va s'en charger pour moi sous peu et je publierai le compte-rendu.
-
En effet, ya moi aussi! ;D
Au final, suis plus si sûr que c'est le fait d'avoir reseté l'ONU qui a tout changé.
Car, je ne peux être sûr de la temporalité... Je ne suis pas persuadé que ma situation s'est améliorée juste après avoir reseté l'onu.
Du coup, difficile pour moi de trancher...
-
Je suis intrigué aussi par le résultat d'un reboot electrique.
Je ne conseille à personne dans mon entourage les Freebox avec ONU à cause de ça, si ça se met à évoluer je verrais peut-être les choses différament.
-
Je suis intrigué aussi par le résultat d'un reboot electrique.
Je ne conseille à personne dans mon entourage les Freebox avec ONU à cause de ça, si ça se met à évoluer je verrais peut-être les choses différemment.
Il est probable aussi que l'on sera toujours avec une population relativement marginale qui s'apercevra qu'il y a un souci... Toujours l'histoire de la famille Michu! ;)
-
Bonjour à tous.
Je suis abonné Free fibre 1 Gb avec la Freebox Revolution et le boitier ONU v2. Je rencontre le même souci avec les téléchargements limités à 30 mo/s.
J'ai fait le test avec checkBugOnuFree qui indique que le boitier ONU est la source du problème.
J'ai lu le fil de la discussion et j'ai vu que certains ont fait un reset du boitier ONU et certains parlaient aussi d'un reboot électrique de la Freebox. Pardonnez mon ignorance mais quelle est la manip précise pour faire un reset du boitier ONU et pour faire un reboot électrique de la Freebox ?
Merci d'avance.
Xavier
-
::) C'est juste écrit à la page précédente...
procédure:
- débrancher la prise d'alimentation ONU
- appuyer avec un trombone sur bouton reset (a gauche du boîtier)
- rebrancher l'alimentation, en maintenant toujours le bouton reset pendant 5s
- puis 3s après une nouvelle coupure d'alim, on voit bien l'ONU - 3s après avoir relâché le bouton, couper à nouveau l'alimentation électrique
Le voyant fibre clignote ce qui indique une MAJ firmware
La coupure après les 3s n'est semble-t-il pas nécessaire mais comme je l'ai faite et qu1h30 après c'est tombé en marche...
-
J'ai bien reset le boitier ONU dont un des voyants a bien clignoté quelques secondes. Mais au final le bug est toujours là.
J'attends de voir ce que le service technique de Free va me répondre.
Merci pour l'aide.
-
Et bien en fait:
- si le boitier n'a clignoté que quelques secondes, il n'a pas fait de (potentielle) MAJ: celle-ci dure plusieurs minutes.
- probablement n'as-tu pas maintenu le bouton <reset> assez longtemps
Nous ne savons pas vraiment s'il y un lien de cause à effet: pour mon cas c'est tombé en marche 1h30 après. J'avais depuis plusieurs semaines fait de multiples reset sans résultat. Simple coïncidence, ou nombre de reset de l'ONU ?
Mon intime conviction est que le hard reset ne sert à rien (car au final c'est tombé en marche en 10s donc sans qu'aucun firmware n'ait eu le temps d'être flashé), je pense que c'est Free qui upgrade des paramètres sur les NRO, soit au compte-goutte (bêta-test), soit parce que le fait de faire des reset déclenche une "alerte"...
Quand au service technique... Ne perds même pas de temps à essayer d'appeler pour un tel problème.
-
Merci pour ces précisions.
Je réessaierai le hard reset. Je suis pourtant resté sur le mini bouton reset pendant 5 bonnes secondes en rebranchant le boitier. Ca doit être dans la manip d'après avec les 3 autres secondes où j'ai merdé. Une fois les 5 secondes de reset il faut débrancher 3 secondes puis rebrancher c'est bien ça ?
Pour ce qui est du service technique, un mec m'a appelé samedi matin et je suis resté pas loin d'une heure avec lui au tél. Il m'a fait essayer deux ou trois manips comme le redémarrage simple de la Freebox ou l'attribution d'une IP fixe. Et au final il en a conclu que le blocage à 30 mo/s était dû au fait que Free partage ses connexions fibre souvent entre une trentaine d'abonnés. J'ai trouvé cette explication un peu curieuse car trois ans avant j'avais été abonné Freebox Revolution fibre 1Gb avec un boitier ONU v1 et je n'avais jamais eu ce genre de limitation, pas plus que quand je suis passé chez Bouygues après.
Le souci c'est qu'il m'a dit que pour qu'un technicien se déplace en cas de possible problème matériel, il faut que le débit tombe en-dessous de 10 mo/s, ce qu'il m'a redit aujourd'hui sur twitter. Je lui ai répondu que le bug du boitier ONU v2 était avéré, en lui envoyant le lien de cette discussion + la capture d'écran du test que j'ai effectué avec checkBugOnuFree. Il ne m'a pas répondu depuis et je pense que ça ne suffira pas à les convaincre. J'ai également ouvert un sujet sur le bug tracker de Free car il n'y en avait pas semble-t-il. Mais bon, normalement Free est de toute façon déjà au courant de l'existence de ce bug, ce que j'ai fait remarquer au mec du service technique.
Bref comme tu le disais, va falloir être (très) patient. Heureusement pour moi en plus de Free fibre j'ai un 2ème opérateur avec SFR en câble coaxial qui vient de passer à 1 Gb il y a quelques jours chez moi. Je pourrais d'ailleurs m'en contenter mais je n'ai pas envie de lâcher l'affaire avec Free. On paye quand même pour 1 Gb, pas pour 300 Mb.
-
Pour l'explication c'est du bullshit de niveau 1.
On paye quand même pour 1 Gb, pas pour 300 Mb.
Non, débit "jusqu'à", lire le contrat ;)
-
Oui oui je sais, c'est ce que le mec du service technique m'a dit lui aussi.
-
Petit espoir ou pas ?
Une personne de chez Free a répondu au message que j'ai posté sur leur bug tracker. Comme on s'en doutait, ils sont au courant du problème et disent qu'il est en voie de correction....sûrement de manière progressive comme le suggère Fabrice49.
Pour info, ci-dessous le lien du sujet ouvert sur le bug tracker.
https://dev.freebox.fr/bugs/task/36474 (https://dev.freebox.fr/bugs/task/36474)
Edit : selon un des administrateurs du bug tracker de Free, la correction se fera en une seule fois, pas progressivement. L'espoir fait vivre.
-
Effectivement, ça calme. Un sujet ouvert en septembre 2021....
Ce n'est clairement pas une priorité pour Free vu que le bug ne fait pas descendre le débit de téléchargement en-dessous du niveau acceptable (le leur). Le seul moyen de résoudre le problème si Free ne le fait pas ce sera de passer sur Freebox Pop.
-
Cela me rappelle l'époque où ils experimentaient différents profils pour l'ADSL puis le VDSL, il y avait des changements NRA par NRA.
Vu ce qui est arrivé à kkwete et moi on est loin du scénario massif. Et crois-moi, le technicien que tu as eu n'as et n'aura aucune information de ce que fait Free Infra de son côté.
Sinon une petite perte de lien ce soir (1mn), mais débits toujours au top, que ce soit en download comme upload.
Clairement l'ONU v2 n'a aucun problème à tenir la charge !
-
Effectivement, ça calme. Un sujet ouvert en septembre 2021....
Ce n'est clairement pas une priorité pour Free vu que le bug ne fait pas descendre le débit de téléchargement en-dessous du niveau acceptable (le leur). Le seul moyen de résoudre le problème si Free ne le fait pas ce sera de passer sur Freebox Pop.
Ou Delta ou tomber sur un ONU v1.
-
Le seul moyen de résoudre le problème si Free ne le fait pas ce sera de passer sur Freebox Pop.
Ou changer de FAI, généralement les pepettes ils comprennent un peu plus vite ...
-
Changer encore de FAI peut-être mais le truc c'est que j'ai l'habitude de regarder la TV sur MyCanal via Appla TV 4K. Je ne me vois pas retourner chez Bouygues dont la BBox fibre est de qualité inférieure niveau image. Et puis il n'y a que la Freebox qui donne accès aux chaines TV de Canal Panorama sur MyCanal justement. Bref, on verra où on en sera dans 6 mois niveau boitier ONU v2.
-
Bon, ben 2ème perte de lien de 1mn ce soir, et je suis revenu à une connexion "bridée" !
:'( :o
Je sais plus quoi penser...
-
Du coup, échec de la théorie de la maj ONU
-
C'est pas au niveau ONU que ça se passe, mais au niveau OLT (dans le NRO).
Mais alors le pourquoi du comment...
Je pense que je vais tenter de générer des pertes de liens en débranchant la jarretière optique
-
C'est pas au niveau ONU que ça se passe, mais au niveau OLT (dans le NRO).
Mais alors le pourquoi du comment...
Je pense que je vais tenter de générer des pertes de liens en débranchant la jarretière optique
D'où le terme : théorie.
-
re re re coupure à 21h16 et j'ai retrouvé ma pleine bande passante.
Entre l'instabilité de la ligne le yo-yo bridé/pas bridé je ne sais même plus quoi penser ???
-
Ou Delta ou tomber sur un ONU v1.
Ça ne garantie rien en qualité de ligne non plus, alors oui pas de bride à 30 Mo/s à cause de l'ONU mais regarde sur une vm dans une delta à l'instant :
[checkBugOnuFree v0.9] Linux 5.4.0-91-generic (aarch64)
--------------------------- 2022-03-15 21:11:09 GMT ---------------------------
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: 8166 10891 16332
net.ipv4.tcp_no_metrics_save: 0
net.ipv4.tcp_rmem: 4096 131072 5576224
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: 23 ms
Test TCP local (Freebox)...
--> Latence: 0.60 ms
--> Débit: 151.09 Mo/s (1.21 Gbps)
Test TCP Internet (AS12876-BBR)...
--> Latence: 9.35 ms
--> Débit: 85.83 Mo/s (686.60 Mbps)
Test TCP Internet (AS12876-CUBIC)...
--> Latence: 9.43 ms
--> Débit: 3.03 Mo/s (24.26 Mbps)
La connexion ne semble pas affectée par un dysfonctionnement de boîtier ONU Free mais présente tout de même des performances dégradées.
La connexion semble affectée par une congestion réseau prononcée.
=> VERIFIER QUE RIEN D'AUTRE NE CONSOMME DE LA BANDE PASSANTE (RELANCER LE TEST LE CAS ECHEANT)
--------------------------- 2022-03-15 21:12:21 GMT ---------------------------
-
Ça ne garantie rien en qualité de ligne non plus, alors oui pas de bride à 30 Mo/s à cause de l'ONU mais regarde sur une vm dans une delta à l'instant :
[checkBugOnuFree v0.9] Linux 5.4.0-91-generic (aarch64)
--------------------------- 2022-03-15 21:11:09 GMT ---------------------------
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: 8166 10891 16332
net.ipv4.tcp_no_metrics_save: 0
net.ipv4.tcp_rmem: 4096 131072 5576224
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: 23 ms
Test TCP local (Freebox)...
--> Latence: 0.60 ms
--> Débit: 151.09 Mo/s (1.21 Gbps)
Test TCP Internet (AS12876-BBR)...
--> Latence: 9.35 ms
--> Débit: 85.83 Mo/s (686.60 Mbps)
Test TCP Internet (AS12876-CUBIC)...
--> Latence: 9.43 ms
--> Débit: 3.03 Mo/s (24.26 Mbps)
La connexion ne semble pas affectée par un dysfonctionnement de boîtier ONU Free mais présente tout de même des performances dégradées.
La connexion semble affectée par une congestion réseau prononcée.
=> VERIFIER QUE RIEN D'AUTRE NE CONSOMME DE LA BANDE PASSANTE (RELANCER LE TEST LE CAS ECHEANT)
--------------------------- 2022-03-15 21:12:21 GMT ---------------------------
Oui, ça va dépendre d'une saturation locale. Heureusement, c'est pas généralisé.
-
re re re coupure à 21h16 et j'ai retrouvé ma pleine bande passante.
Entre l'instabilité de la ligne le yo-yo bridé/pas bridé je ne sais même plus quoi penser ???
Pareil chez moi, 5 déco/reco entre 18h34 et 21h16.
Je n'ai pas testé les débits à chaque fois, mais actuellement tout va bien chez moi.
-
Par curiosité, dans une VM sur ma delta à l'instant :
Test TCP local (Freebox)...
--> Latence: 0.61 ms
--> Débit: 152.32 Mo/s (1.22 Gbps)
Test TCP Internet (AS12876-BBR)...
--> Latence: 12.90 ms
--> Débit: 182.54 Mo/s (1.46 Gbps)
Test TCP Internet (AS12876-CUBIC)...
--> Latence: 12.55 ms
--> Débit: 178.27 Mo/s (1.43 Gbps)
La connexion ne semble pas affectée par un dysfonctionnement de boîtier ONU Free.
--------------------------- 2022-03-15 21:33:17 GMT ---------------------------
-
Je note une chose bizarre ce soir : sur mon Apple TV 4K connecté à ma Freebox Revolution en ethernet, je fais régulièrement un test de débit avec l'appli Speedtest. Depuis le début de mon abonnement Free, je plafonne à 60-70 Mbps en down et 700 Mbps en Up, ce qui confirme la limitation de vitesse en down constatée sur le PC.
Et il y a quelques minutes, la vitesse en down est passée à environ 900 Mbps (et toujours 700 Mbps en Up). J'ai fait le test 5 ou 6 fois. 900 à chaque fois en down. Du coup je me suis dit ça y est, l'ONU v2 fonctionne normalement....mais non. Sur le PC ça plafonne toujours à 30 Mo/s en down (et le test de débit sur Fast.com annonce entre 200-250 Mbps max). Pourquoi alors tout à coup sur l'Apple TV ça mesure 900 alors que depuis le début de mon abonnement il y a 6 mois, ça mesurait toujours 60-70 ?
Une idée ? Merci.
-
Le test a été mis à jour pour faire du multi-connexions ?
-
Tu es en filaire sur le PC ?
Je viens d'essayer fast.com que je ne connaissais pas et je plafonne à 340MBps en mono-connexion. Certes c'est plus que les 250MBPs, mais ça ne paraît pas exceptionnel comme test...
Peux-tu réessayer avec checkBugOnuFree.exe (https://github.com/oounoo/checkBugOnuFree/releases/download/v0.9/checkBugOnuFree.exe) ou bien Speedtest.net (https://www.speedtest.net/) en n'oubliant pas de cliquer sur mono-connexion et en prenant LaFibre.info BBR comme serveur de test ?
-
J'ai refait le test avec checkBugOnuFree. Mêmes valeurs que la dernière fois.
TCP Local = 118 Mo/s (945 Mbps)
TCP Internet = 33 Mo/s (266 Mbps)
"La connexion semble affectée par un dysfonctionnement de boitier ONU Free."
Pour ce qui est de l'appli Speedtest sur Apple TV, je ne peux pas régler les paramètres. Je peux juste changer de serveur. Et en l'occurrence, j'ai trois serveurs La.Fibre.info. Voilà la mesure des débits ce soir (je les ai refaites trois fois chacune).
La.Fibre.info BBR-IPv4 à Palaiseau = 900-920 Mbps en down et 670 en up.
La.Fibre.info BBR à Massy = 900-920 Mbps en down et 680 en up.
La.Fibre.info CUBIC à Orly = 60-70 Mbps en down et 680 en up.
Et sur mon PC en ethernet, avec le test de Fast.com, ça n'atteint même pas les 200 Mbps ce soir. Entre 150 et 180 maxi (et 500 Mbps en upload).
Le problème est donc toujours bien là. Par contre, comment expliquer que sur mon Apple TV le test en down indique 900 Mbps sur certains serveurs et environ 60 sur d'autres ? (sur le serveur d'Orange France Rennes et sur celui de SFR Trappes, c'est 50-60 Mbps en down, comme sur celui de La.Fibre.info CUBIC)
Dernière précision : tous mes branchements sont en ethernet (PC et Apple TV).
-
J'ai refait le test avec checkBugOnuFree. Mêmes valeurs que la dernière fois.
TCP Local = 118 Mo/s (945 Mbps)
TCP Internet = 33 Mo/s (266 Mbps)
"La connexion semble affectée par un dysfonctionnement de boitier ONU Free."
Pour ce qui est de l'appli Speedtest sur Apple TV, je ne peux pas régler les paramètres. Je peux juste changer de serveur. Et en l'occurrence, j'ai trois serveurs La.Fibre.info. Voilà la mesure des débits ce soir (je les ai refaites trois fois chacune).
La.Fibre.info BBR-IPv4 à Palaiseau = 900-920 Mbps en down et 670 en up.
La.Fibre.info BBR à Massy = 900-920 Mbps en down et 680 en up.
La.Fibre.info CUBIC à Orly = 60-70 Mbps en down et 680 en up.
Et sur mon PC en ethernet, avec le test de Fast.com, ça n'atteint même pas les 200 Mbps ce soir. Entre 150 et 180 maxi (et 500 Mbps en upload).
Le problème est donc toujours bien là. Par contre, comment expliquer que sur mon Apple TV le test en down indique 900 Mbps sur certains serveurs et environ 60 sur d'autres ? (sur le serveur d'Orange France Rennes et sur celui de SFR Trappes, c'est 50-60 Mbps en down, comme sur celui de La.Fibre.info CUBIC)
Dernière précision : tous mes branchements sont en ethernet (PC et Apple TV).
Simple, l'appli Speedtest sur PC (je parle bien de l'Appli installée sur PC, et non le speedtest vie le navigateur) ou sur l'Apple TV est systématiquement en multi-sessions; pas de possibilité der passer en mono-session TCP, donc les résultats ne peuvent révéler le "bug".
En ce qui concerne les résultats essentiellement variables selon les serveurs, certains de ces serveurs peuvent être plus ou moins chargés, ou les chemins pour y parvenir plus ou moins encombrés...
Perso, je teste soit sur la fibre en BBR, soit Bouygues Meudon en BBR... C'est là que j'ai les résultats les plus réguliers...
-
Bonjour,
Visiblement le problème doit être corrigé ou bientôt ;)
https://dev.freebox.fr/bugs/task/36474
-
Bonjour,
Visiblement le problème doit être corrigé ou bientôt ;)
https://dev.freebox.fr/bugs/task/36474
Enfin !
-
Tant mieux si c'est corrigé pour certains mais pas pour d'autres.
Chez moi c'est toujours limité à 30 Mo/s en téléchargement et débit de la ligne à environ 200 Mbps avec le test fast.com.
Ils disaient que ce serait corrigé d'un coup mais une correction (lentement) progressive semble plus vraisemblable.
-
Il y a vraisemblablement eu des essais mardi 15/03, kkwete et moi avons subit les mêmes déconnexions/reconnexions aux mêmes horaires à la minute près, alors que nous habitons à 500km l'un de l'autre.
kkwete n'as pas pu vérifier, mais moi j'étais devant le PC et ma connexion faisait le yoyo entre bridé/pas bridé. A présent c'est stable et nous avons toujours tous les deux des ONU débridés.
-
Nouveau message sur le bug tracker : apparemment le correctif n'est déployé qu'en beta à certains endroits.
https://dev.freebox.fr/bugs/task/36474#comment165553 (https://dev.freebox.fr/bugs/task/36474#comment165553)
-
Il y a vraisemblablement eu des essais mardi 15/03, kkwete et moi avons subit les mêmes déconnexions/reconnexions aux mêmes horaires à la minute près, alors que nous habitons à 500km l'un de l'autre.
kkwete n'as pas pu vérifier, mais moi j'étais devant le PC et ma connexion faisait le yoyo entre bridé/pas bridé. A présent c'est stable et nous avons toujours tous les deux des ONU débridés.
Je te rejoins complètement.
A ce jour, ma connexion est stable et au taquet!
-
Je suis équipé d'un V2.
Sans que çà ne me gêne trop mes téléchargements de fichiers semblaient limités à ce fameux 30Mo/s.
Je viens de faire un test de débit et je dépasse la barre des 30Mo/s
-
J'ai eu une déco il y a 2 jours dans la nuit
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 84.1M 0 0:00:11 0:00:11 --:--:-- 84.5M
Par contre ...
Test TCP local (Freebox)...
--> Latence: 0.48 ms
--> Débit: 117.68 Mo/s (941.43 Mbps)
Test TCP Internet (AS12876-BBR)...
--> Latence: 12.20 ms
--> Débit: 101.95 Mo/s (815.61 Mbps)
Test TCP Internet (AS12876-CUBIC)...
--> Latence: 12.12 ms
--> Débit: 14.67 Mo/s (117.37 Mbps)
La connexion ne semble pas affectée par un dysfonctionnement de boîtier ONU Free mais présente tout de même des performances dégradées.
La connexion semble affectée par une congestion réseau prononcée.
=> VERIFIER QUE RIEN D'AUTRE NE CONSOMME DE LA BANDE PASSANTE (RELANCER LE TEST LE CAS ECHEANT)
--------------------------- 2022-03-30 22:02:30 GMT ---------------------------
Appuyer sur Entrée pour quitter...
-
Selon Maxime Bizon sur dev.freebox.fr (https://dev.freebox.fr/bugs/task/36474#comment165604)
le correctif est déployé et il nous demande de faire un test.
-
Chez moi c'est bon.
Tests tous en ethernet.
- Tests téléchargements : entre 80 et 90 Mo/s
- Tests avec Fast.com sur PC : entre 800 et 920 Mbps
- Tests avec appli Speedtest sur Apple TV 4K : 500 Mbps avec serveur SFR Trappes ou Orange Rennes (ça monte à 900 puis ça redescend à 500), 900 Mbps avec serveur LaFibre.info et LaFibre.info BBR.
- Tests avec PS4 pro : entre 500 et 650 Mbps
- Tests avec checkBugOnuFree : pas de dysfonctionnement du boitier ONU mais performances légèrement dégradées quand même. J’ai pourtant déconnecté tout ce qui pouvait consomme de la bande passante (Freebox TV, Apple TV, pas d’appareil connecté au wifi).
Donc pour moi c'est globalement ok, même si checkBugOnuFree détecte encore une anomalie.
Et chez vous ?
(https://i.postimg.cc/nLKSpsX1/Capture.jpg)
-
Chez moi c'est tout bon, mais ça l'était déjà avant vu que j'ai fait partie (à mon insu) d'un bêta-test.
Le problème en CUBIC montre plus une congestion réseau quelque part (les experts me contrediront si besoin), mais le test en BBR est parlant: plus de bridage.
-
Cool. Un petit pas en avant pour l'humanité !!! ;D
-
Merci pour ces précisions.
-
Je suis équipé d'un V2.
Sans que çà ne me gêne trop mes téléchargements de fichiers semblaient limités à ce fameux 30Mo/s.
Je viens de faire un test de débit et je dépasse la barre des 30Mo/s
Pareil, maintenant je tourne autour de 90Mo/s
-
Bonjour à tous.
Je me permet de remonter ce post.
je viens d'avoir la fibre (Mini4K) avec un boitier de ce type
(https://www.universfreebox.com/UserFiles/image/convertisseur1.jpg)
J'ai l'impression d'avoir le même problème.
J'ai de très bon résultat sur des sites comme Nperf (aux alentours de 900Mbits down et 600 Up)
Par contre sur un téléchargement ou un seul flux ca semble saturer aux alentours de 30Mo/s
root@nas:~# iperf3 -c scaleway.testdebit.info -b 0 -p 9200 -R
Connecting to host scaleway.testdebit.info, port 9200
Reverse mode, remote host scaleway.testdebit.info is sending
[ 5] local 10.0.0.250 port 34674 connected to 62.210.156.7 port 9200
[ ID] Interval Transfer Bitrate
[ 5] 0.00-1.00 sec 32.3 MBytes 271 Mbits/sec
[ 5] 1.00-2.00 sec 33.7 MBytes 283 Mbits/sec
[ 5] 2.00-3.00 sec 31.9 MBytes 268 Mbits/sec
[ 5] 3.00-4.00 sec 33.1 MBytes 278 Mbits/sec
[ 5] 4.00-5.00 sec 33.8 MBytes 283 Mbits/sec
[ 5] 5.00-6.00 sec 33.1 MBytes 278 Mbits/sec
[ 5] 6.00-7.00 sec 34.3 MBytes 288 Mbits/sec
[ 5] 7.00-8.00 sec 33.6 MBytes 281 Mbits/sec
[ 5] 8.00-9.00 sec 34.6 MBytes 291 Mbits/sec
[ 5] 9.00-10.00 sec 34.9 MBytes 292 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.01 sec 345 MBytes 289 Mbits/sec 0 sender
[ 5] 0.00-10.00 sec 335 MBytes 281 Mbits/sec receiver
Par contre sur plusieurs flux pas de problème.
root@nas:~# iperf3 -c scaleway.testdebit.info -b 0 -p 9200 -R -P 4
Connecting to host scaleway.testdebit.info, port 9200
Reverse mode, remote host scaleway.testdebit.info is sending
[ 5] local 10.0.0.250 port 38278 connected to 62.210.156.7 port 9200
[ 7] local 10.0.0.250 port 38290 connected to 62.210.156.7 port 9200
[ 9] local 10.0.0.250 port 38306 connected to 62.210.156.7 port 9200
[ 11] local 10.0.0.250 port 38316 connected to 62.210.156.7 port 9200
[ ID] Interval Transfer Bitrate
[ 5] 0.00-1.01 sec 18.2 MBytes 152 Mbits/sec
[ 7] 0.00-1.01 sec 29.9 MBytes 249 Mbits/sec
[ 9] 0.00-1.01 sec 30.2 MBytes 252 Mbits/sec
[ 11] 0.00-1.01 sec 14.1 MBytes 118 Mbits/sec
[SUM] 0.00-1.01 sec 92.4 MBytes 771 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ 5] 1.01-2.00 sec 20.7 MBytes 175 Mbits/sec
[ 7] 1.01-2.00 sec 33.9 MBytes 286 Mbits/sec
[ 9] 1.01-2.00 sec 36.1 MBytes 305 Mbits/sec
[ 11] 1.01-2.00 sec 13.7 MBytes 115 Mbits/sec
[SUM] 1.01-2.00 sec 104 MBytes 881 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
...
[ 9] 0.00-10.01 sec 357 MBytes 299 Mbits/sec 10950 sender
[ 9] 0.00-10.00 sec 346 MBytes 290 Mbits/sec receiver
[ 11] 0.00-10.01 sec 145 MBytes 121 Mbits/sec 3505 sender
[ 11] 0.00-10.00 sec 139 MBytes 116 Mbits/sec receiver
[SUM] 0.00-10.01 sec 1.03 GBytes 884 Mbits/sec 30893 sender
[SUM] 0.00-10.00 sec 1018 MBytes 854 Mbits/sec receiver
N'ayant pas de boitier ONU ca semble pas le même problème.. mais pour autant les faits son là...
Chose importante ma Mini4K est en mode bridge et j'utilise un boitier Alix avec Pfsense comme routeur.
Je ne pense pas que le problème viennent du pfsense puisque qu'entre 2 serveurs routé par Pfsense pas de soucis sur un flux
C:\>iperf-2.1.1-Feb_27_2021-win.exe -w1M -c 172.30.0.1
------------------------------------------------------------
Client connecting to 172.30.0.1, TCP port 5001
TCP window size: 1.00 MByte
------------------------------------------------------------
[ 1] local 10.0.0.100 port 49563 connected with 172.30.0.1 port 5001
[ ID] Interval Transfer Bandwidth
[ 1] 0.00-10.03 sec 559 MBytes 468 Mbits/sec
-
si c'est un boitier ONU ou ONT ?
je vais encore moins vite moi avec la même commande que toi (mais j'étais en IPV6)
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-1.00 sec 20.5 MBytes 172 Mbits/sec
[ 4] 1.00-2.00 sec 20.5 MBytes 172 Mbits/sec
[ 4] 2.00-3.00 sec 20.4 MBytes 171 Mbits/sec
[ 4] 3.00-4.00 sec 20.5 MBytes 172 Mbits/sec
[ 4] 4.00-5.00 sec 20.7 MBytes 173 Mbits/sec
[ 4] 5.00-6.00 sec 20.7 MBytes 173 Mbits/sec
[ 4] 6.00-7.00 sec 20.6 MBytes 173 Mbits/sec
[ 4] 7.00-8.00 sec 20.6 MBytes 173 Mbits/sec
[ 4] 8.00-9.00 sec 20.6 MBytes 173 Mbits/sec
[ 4] 9.00-10.00 sec 20.6 MBytes 172 Mbits/sec
c'est sur un PC tout pourri avec un Atom X5 je ne sais pas si ça joue, Mini 4K et le même boitier
-
J'ai fait un test intéressant pour avancer.
J'ai repasser temporairement ma Freebox Mini 4K en mode routeur non bridge et brancher on PC au cul..
et là le même test mono session dépasse bien les 30Mo/s
C:\>iperf3.exe -w1M -c scaleway.testdebit.info -b 0 -p 9200 -R
Connecting to host scaleway.testdebit.info, port 9200
Reverse mode, remote host scaleway.testdebit.info is sending
[ 4] local 2xxxxx2a port 63959 connected to 2001:bc8:3::7 port 9200
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-1.00 sec 81.8 MBytes 686 Mbits/sec
[ 4] 1.00-2.00 sec 80.7 MBytes 677 Mbits/sec
[ 4] 2.00-3.00 sec 84.1 MBytes 706 Mbits/sec
[ 4] 3.00-4.00 sec 85.8 MBytes 720 Mbits/sec
[ 4] 4.00-5.00 sec 85.4 MBytes 717 Mbits/sec
[ 4] 5.00-6.00 sec 86.0 MBytes 721 Mbits/sec
[ 4] 6.00-7.00 sec 86.2 MBytes 724 Mbits/sec
[ 4] 7.00-8.00 sec 83.0 MBytes 696 Mbits/sec
[ 4] 8.00-9.00 sec 85.3 MBytes 716 Mbits/sec
[ 4] 9.00-10.00 sec 86.2 MBytes 723 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-10.00 sec 847 MBytes 710 Mbits/sec 1121 sender
[ 4] 0.00-10.00 sec 846 MBytes 709 Mbits/sec receiver
Si je rebascule en mode Bridge derriere Pfsense la limitation revient
C:\>iperf3.exe -w1M -c scaleway.testdebit.info -b 0 -p 9200 -R
Connecting to host scaleway.testdebit.info, port 9200
Reverse mode, remote host scaleway.testdebit.info is sending
[ 4] local 1ccc86 port 63029 connected to 62.210.156.7 port 9200
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-1.00 sec 35.9 MBytes 301 Mbits/sec
[ 4] 1.00-2.00 sec 36.1 MBytes 303 Mbits/sec
[ 4] 2.00-3.00 sec 37.3 MBytes 313 Mbits/sec
[ 4] 3.00-4.00 sec 37.9 MBytes 318 Mbits/sec
[ 4] 4.00-5.00 sec 31.4 MBytes 263 Mbits/sec
[ 4] 5.00-6.00 sec 36.1 MBytes 303 Mbits/sec
[ 4] 6.00-7.00 sec 38.6 MBytes 324 Mbits/sec
[ 4] 7.00-8.00 sec 38.0 MBytes 319 Mbits/sec
[ 4] 8.00-9.00 sec 39.5 MBytes 331 Mbits/sec
[ 4] 9.00-10.01 sec 37.2 MBytes 309 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-10.01 sec 369 MBytes 309 Mbits/sec 80 sender
[ 4] 0.00-10.01 sec 368 MBytes 308 Mbits/sec receiver
iperf Done.
On note quand meme une différence, en mode non bridge la connexion s'est lancée en IPV6
En mode bridge en IPV4
Donc si on recoupe les informations, il semble que les limitations de débits mono session soient liées:
- Soit à la FB Mini 4k en mode Bridge
- Soit au Pfsense au niveau routage Wan
Là ou je suis étonné coté Pfsense, c'est que je ne constate pas cette limitation avec un transfert mono session en local entre 2 dmz internes..
-
avec -w1M j'obtiens pareil que toi dans les 800Mb/s mais sans ... je dépasse pas les 200Mb/s (tu n'avais pas mis w1M la première fois et j'avais copié ta cmd)
je suis en mode routeur
C:\Users\YoNeL\Downloads\iperf-3.1.3-win64>iperf3.exe -w1M -c scaleway.testdebit.info -b 0 -p 9200 -R
Connecting to host scaleway.testdebit.info, port 9200
Reverse mode, remote host scaleway.testdebit.info is sending
[ 4] local 2a01: port 50371 connected to 2001:bc8:3::7 port 9200
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-1.00 sec 101 MBytes 850 Mbits/sec
[ 4] 1.00-2.00 sec 106 MBytes 887 Mbits/sec
[ 4] 2.00-3.00 sec 103 MBytes 866 Mbits/sec
[ 4] 3.00-4.00 sec 106 MBytes 890 Mbits/sec
[ 4] 4.00-5.00 sec 106 MBytes 891 Mbits/sec
[ 4] 5.00-6.00 sec 105 MBytes 884 Mbits/sec
[ 4] 6.00-7.00 sec 103 MBytes 867 Mbits/sec
[ 4] 7.00-8.00 sec 102 MBytes 853 Mbits/sec
[ 4] 8.00-9.00 sec 105 MBytes 884 Mbits/sec
[ 4] 9.00-10.00 sec 104 MBytes 868 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-10.00 sec 1.02 GBytes 875 Mbits/sec 288 sender
[ 4] 0.00-10.00 sec 1.02 GBytes 875 Mbits/sec receiver
-
Merci pour ta réponse.
Ce qui m'interesse c'est si certains sont en mode bridge avec une Mini4k et remonte le même problème
-
un article intéressant qui semble dire que les flux seul pfsense semble avoir du mal sur un core
..
https://teklager.se/en/knowledge-base/apu2-1-gigabit-throughput-pfsense/
-
un article intéressant qui semble dire que les flux seul pfsense semble avoir du mal sur un core
..
https://teklager.se/en/knowledge-base/apu2-1-gigabit-throughput-pfsense/
La remarque est sans rapport avec l'intitule du fil de dicussion.
Par ailleurs, pfSense n'a aucun mal sur un coeur au sens strict.
Par contre vous touchez clairement du doigt un souci, le traitement des puces Intel i210, i211, i350 est loin d'etre optimal sous FreeBSD et donc sous pfSense ou OPNsense.
Pour faire court, ce n'est pas sans raison mais le probleme est factuel pour les utilisations domestiques de ces systemes d'exploitation.
Edit: syntaxe
-
Oui j'ai installé un pfsense sur un pc en core i3
Et je n'ai pas le problème
Donc bien mis en avant que c'est le hardware du Apu2c2
Qui est limitant
Je vais voir pour changer de hardware pour mon pfsense mais ça va coûter cher je pense
-
Effectivement un core i3 meme de plusieurs generations va masquer le probleme a 1G bit/s. Mais entre la puce AMD des APU2+ qui finit sa vie en 2024 et un core i3, vous avez probablement des alternatives dans votre cadre d'utilisation.
-
@bartounet16000
Hello.
Je viens de recevoir et migrer mon PFSENSE sur le nouveau boitier.
Micro Firewall Appliance, Pfsense, Mikrotik, OPNsense, VPN, Router PC, Intel Celeron J4125, HUNSN RS34g, AES-NI, 4 x Intel 2.5GbE I225-V LAN, 2 x USB3.0, VGA, HDMI, Fanless, 8G RAM, 64G SSD
migration super facile en partant d'un fichier de conf et en renommant les interfaces sources et cibles.
Premier tests:
Iperf sur 1 flux entre pc client et Pfsense lui même
```
C:\>iperf3.exe -w1M -c 10.0.0.254 -b 0 -p 5201 -R
Connecting to host 10.0.0.254, port 5201
Reverse mode, remote host 10.0.0.254 is sending
[ 4] local 10.0.0.100 port 56456 connected to 10.0.0.254 port 5201
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-1.00 sec 113 MBytes 947 Mbits/sec
[ 4] 1.00-2.00 sec 113 MBytes 947 Mbits/sec
[ 4] 2.00-3.00 sec 112 MBytes 938 Mbits/sec
[ 4] 3.00-4.00 sec 113 MBytes 949 Mbits/sec
[ 4] 4.00-5.00 sec 113 MBytes 947 Mbits/sec
[ 4] 5.00-6.00 sec 113 MBytes 946 Mbits/sec
[ 4] 6.00-7.00 sec 113 MBytes 946 Mbits/sec
[ 4] 7.00-8.00 sec 113 MBytes 946 Mbits/sec
[ 4] 8.00-9.00 sec 113 MBytes 946 Mbits/sec
[ 4] 9.00-10.00 sec 113 MBytes 946 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-10.00 sec 1.10 GBytes 947 Mbits/sec 438 sender
[ 4] 0.00-10.00 sec 1.10 GBytes 946 Mbits/sec receiver
Alors qu'avant j'étais bridé à max 340 Mbits/s
Test sur le même download de fichier sur le ftp de free.
```
(https://i.ibb.co/j6jPPwP/2022-09-14-18-59-16-Index-of-mirrors-ftp-opensuse-org-opensuse-distribution-open-SUSE-current-iso.png)
voilà la messe est dites.
C'est bien le boitiers APU2C4 qui bridait à 300Mbits sur un flux, mais arrivait à s'en sortir sur du multiflux