La Fibre
Fournisseurs d'accès à Internet fixe en France métropolitaine => Free => 
Débits fibre Free => Discussion démarrée par: kkwete le 22 février 2022 à 21:31:56
-
Salut à tous.
disposant de l'offre freebox V6 à 10€/mois, je rencontre au final pas mal de pb.
Je ne reviens pas sur la problématique des ONU V2 limités à 30 Mo/sec, déjà largement discutée.
Mais là, c'est le top...:(
En téléchargement via navigateur, je suis forcément limité à 5Mo/sec, idem par le client torrent de la freebox.
Test en multiconnexions:
(https://zupimages.net/up/22/08/h4eu.png) (https://zupimages.net/viewer.php?id=22/08/h4eu.png)
Test en monoconnexion:
(https://zupimages.net/up/22/08/zh58.png) (https://zupimages.net/viewer.php?id=22/08/zh58.png)
(https://zupimages.net/up/22/08/td5g.png) (https://zupimages.net/viewer.php?id=22/08/td5g.png)
Alors qu'elle synchronise bien en 1Gbps/700Mbps:
(https://zupimages.net/up/22/08/7rbq.png) (https://zupimages.net/viewer.php?id=22/08/7rbq.png)
(https://zupimages.net/up/22/08/rypt.png) (https://zupimages.net/viewer.php?id=22/08/rypt.png)
Le meme torrent en parallèle sur ma seedbox perso, sur un tout petit VPN:
(https://zupimages.net/up/22/08/abwl.png) (https://zupimages.net/viewer.php?id=22/08/abwl.png)
kkwete@kkwete:~$ 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 2a01:e0a:a6c:f290:557d:7267:1926:aa40 port 47218 connected to 2001:bc8:3::7 port 9200
[ ID] Interval Transfer Bitrate
[ 5] 0.00-1.00 sec 33.7 MBytes 283 Mbits/sec
[ 5] 1.00-2.00 sec 32.1 MBytes 270 Mbits/sec
[ 5] 2.00-3.00 sec 31.3 MBytes 263 Mbits/sec
[ 5] 3.00-4.00 sec 31.3 MBytes 263 Mbits/sec
[ 5] 4.00-5.00 sec 31.4 MBytes 264 Mbits/sec
[ 5] 5.00-6.00 sec 32.0 MBytes 268 Mbits/sec
[ 5] 6.00-7.00 sec 32.0 MBytes 268 Mbits/sec
[ 5] 7.00-8.00 sec 31.7 MBytes 266 Mbits/sec
[ 5] 8.00-9.00 sec 31.0 MBytes 260 Mbits/sec
[ 5] 9.00-10.00 sec 31.8 MBytes 267 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.01 sec 328 MBytes 275 Mbits/sec 38676 sender
[ 5] 0.00-10.00 sec 318 MBytes 267 Mbits/sec receiver
iperf Done.
Très honnetement, c'est très pénible.
De plus, je rencontre des microcoupures sur le player de la tv, des coupures de moins d'une secondes, mais régulièrement.
J'ai testé 3 PC différents, toujours le même résultat, que cela soi sous linux ou windows. Mon PC principal étant un i7-7700, 16Go de RAM DDR4 et SSD, bien évidemment relié en ethernet.
Freebox réinitialisée et en mode routeur. En mode bridge, c'est pareil.
J'ai testé à toutes les heures de la journée, le constat est le même.
Là, je sèche...
Je peux faire d'autres tests, demandez!
-
Je suis sur la même offre avec l'ONU limité à 30Mo aussi.
Les 5 Mo je les rencontre si je télécharge un fichier directement depuis la Freebox. C'est une limite de la bête en version R1 à priori.
Par-contre j'ai le disque dur HS. Remplacement du server en cours.
-
j'ai bien une version R1.
Donc tu es en train de em dire qu'on peut être fibré et que télécharger à 5Mo par seconde c'est normal?
C'est carrement incompréhensible ça!
S'en est même délirant, car où se trouve l'interet d'être fibré alors?
Car au final, je fais environ 2,5 fois mieux que mon ancien ADSL d'il y a 2 ans...
:o :o :o
-
j'ai bien une version R1.
Donc tu es en train de em dire qu'on peut être fibré et que télécharger à 5Mo par seconde c'est normal?
C'est carrement incompréhensible ça!
S'en est même délirant, car où se trouve l'interet d'être fibré alors?
Car au final, je fais environ 2,5 fois mieux que mon ancien ADSL d'il y a 2 ans...
:o :o :o
Il parle de télécharger sur le HDD de ma box. Perso, je suis à +/-23 Mon/ssur une révolution (100Mo/s sur une Delta).
-
Alors qu'elle synchronise bien en 1Gbps/700Mbps:
C'est codé en dur dans l'interface de la Freebox ;)
Tu pourrais faire des tests en IPv6 ? (Puisque le réseau Free est IPv6 natif et IPv4 encapsulé ?)
Après si c'est un défaut lié à la Freebox Revo r1, peut être qu'il est possible de passer sur une r2/r3 ? Mais je n'ai pas souvenir d'avoir lu/entendu parler d'une telle limitation ... Car même sur du VDSL çà serait visible.
Par acquis de conscience, un même test en Windows en mode sans échec donne les mêmes résultats ?
-
Je parlais effectivement de téléchargement sur le HDD de la box.
-
Tu pourrais faire des tests en IPv6 ? (Puisque le réseau Free est IPv6 natif et IPv4 encapsulé ?).
Par acquis de conscience, un même test en Windows en mode sans échec donne les mêmes résultats ?
Pkoi pas, comment faire? Je suis en ipv4 full stack.Je dois activer l'ipv6?
Je n'utilise pas windows, je suis sous linux.
J'ai testé via un live usb sous linux, idem.
Par acquis de conscience, un pote est venu avec son portable gamer sous windows, en ethernet, idem aussi...
-
Pkoi pas, comment faire? Je suis en ipv4 full stack.Je dois activer l'ipv6?
même en IPv4 Full Stack ton IPv4 reste portée par IPv6 avec des routeurs de collecte. Normalement ça ne devrait pas mal se passer mais c'est pour tester.
Normalement IPv6 est activée (et non désactivable) sur toutes les Freebox depuis le printemps 2019.
Si ton linux est correctement paramétré, tu devrais être en IPv6 sur cette page : http://ip.lafibre.info/
pour tester le téléchargement de fichiers et être sur que çà passe en IPv6 tu as les sites suivant
http://ping6.online.net/
http://ipv6.rbx.proof.ovh.net/
+ tous les liens qui sont dans la colonne "IPv6"
https://testdebit.info/
Si tu essaye de télécharger un fichier avec un smartphone connecté en wifi à la Freebox, as tu la même limitation de débit ?
-
En effet, j'ai vérifié, plus d'activation manuelle.
A priori, pas de problème niveau ipv6:
(https://zupimages.net/up/22/08/3i4u.png) (https://zupimages.net/viewer.php?id=22/08/3i4u.png)
Par contre, téléchargement toujours trèèèès lent:
(https://zupimages.net/up/22/08/drxk.png) (https://zupimages.net/viewer.php?id=22/08/drxk.png)
(https://zupimages.net/up/22/08/pfxg.png) (https://zupimages.net/viewer.php?id=22/08/pfxg.png)
(https://zupimages.net/up/22/08/yowu.png) (https://zupimages.net/viewer.php?id=22/08/yowu.png)
Et des fois, je rencontre la limitation dûe à l'ONU V2:
(https://zupimages.net/up/22/08/si2u.png) (https://zupimages.net/viewer.php?id=22/08/si2u.png)
J'ai aussi testé via mon tel, idem, limitation vers 5Mo/sec alors que je suis en 5ghz avec une largeur de bande de 80Mhz, à 1m de la box.
Vraiment, je ne comprends pas...
-
A votre avis, comment pourrais-je etre sur que dans mon cas, la congestion réseau prime?
Avant d'appeler une nouvelle fois le service technique et essayer de demander un tech niveau 2...
-
Salut,
si tu es limité à 5 Mo/s la nuit >23h, le matin tôt, ce n'est pas une saturation réseau interne.
-
Oula non!
J'ai ce débit H24, quelque soit l'heure du jour ou de la nuit...
-
Depuis le début ce problème ?
-
Tout à fait.
Il y a environ 1 mois.
Auparavant chez red, aucun soucis, 120Mo/sec tout le temps.
Même matériel, aucun changement à ce niveau. Uniquement le changement de box.
Tests avec d'autres pc, en wifi et en ethernet, passage de Linux à Windows, utilisation de live USB, toujours le même débit.
-
Tout à fait.
Il y a environ 1 mois.
Auparavant chez red, aucun soucis, 120Mo/sec tout le temps.
Même matériel, aucun changement à ce niveau. Uniquement le changement de box.
Tests avec d'autres pc, en wifi et en ethernet, passage de Linux à Windows, utilisation de live USB, toujours le même débit.
La jarretière Free a bien été utilisée (connecteur bleu/vert) ?
-
Yep.
-
Yep.
Et le bleu bien branché côté box ?
-
Tout à fait.
J'ai même testé dans l'autre sens, ça ne change strictement rien dans mon cas.
-
Il n'y aurait pas un autre matériel sur le LAN qui aurait la même IP que la box ? Genre un switch ou autre?
[mode "j'ai vu de tout et surtout du n'importe quoi"]
J'ai eu une fois ce genre de problème de débit aléatoire car j'avais branché un switch manageable qui avait sa config par défaut avec (comme par hasard) la même IP de la box de l'époque. Du coup j'avais aléatoirement soit un très bon débit, soit un débit pourri. A coup de TCPDUMP il m'a fallut du temps pour détecter qu'une fois c'était la box qui répondait en premier à la requête ARP, puis parfois le switch. Et que du coup le flux TCP perdait quelques paquets (le switch n'avait rien à faire des paquets TCP pas pour lui). En tout cas il y avait suffisamment de perturbation non pas pour couper la connexion mais pour voir une grosse perte de débit. Et windows à l'époque ne disait rien sur un potentiel conflit d'IP.
J'ai surtout vu qu'en branchant le PC seul à la box (sans strictement rien d'autre sur aucun autre port, et surtout même pas de switch en plus), j'avais mon plein débit tout le temps.
[/mode]
Du coup des tests avec rien que le PC (en wifi ou ethernet, peut importe) et strictement rien d'autre sur le LAN (ni switch, ni routeur) ça serait pas mal.
Et si vraiment ça déconne toujours, un coup de "l'affichage ne fonctionne plus" au support devrait lancer une procédure d'échange de box non ?
-
Il n'y aurait pas un autre matériel sur le LAN qui aurait la même IP que la box ? Genre un switch ou autre?
[mode "j'ai vu de tout et surtout du n'importe quoi"]
J'ai eu une fois ce genre de problème de débit aléatoire car j'avais branché un switch manageable qui avait sa config par défaut avec (comme par hasard) la même IP de la box de l'époque. Du coup j'avais aléatoirement soit un très bon débit, soit un débit pourri. A coup de TCPDUMP il m'a fallut du temps pour détecter qu'une fois c'était la box qui répondait en premier à la requête ARP, puis parfois le switch. Et que du coup le flux TCP perdait quelques paquets (le switch n'avait rien à faire des paquets TCP pas pour lui). En tout cas il y avait suffisamment de perturbation non pas pour couper la connexion mais pour voir une grosse perte de débit. Et windows à l'époque ne disait rien sur un potentiel conflit d'IP.
J'ai surtout vu qu'en branchant le PC seul à la box (sans strictement rien d'autre sur aucun autre port, et surtout même pas de switch en plus), j'avais mon plein débit tout le temps.
[/mode]
Du coup des tests avec rien que le PC (en wifi ou ethernet, peut importe) et strictement rien d'autre sur le LAN (ni switch, ni routeur) ça serait pas mal.
Et si vraiment ça déconne toujours, un coup de "l'affichage ne fonctionne plus" au support devrait lancer une procédure d'échange de box non ?
Si le problème avait été sur une seule machine, ce serait une hypothèse plausible. Mais avec des tests avec différents matos, dont un "étranger" à la config, cela ne tient plus...
-
Si ça tient, car c'est justement un problème indépendant du nombre de machine et de leur OS, le fait d'avoir un switch, un point d'accès wifi, un CPL, ou autre avec la même IP que la freebox.
-
Si ça tient, car c'est justement un problème indépendant du nombre de machine et de leur OS, le fait d'avoir un switch, un point d'accès wifi, un CPL, ou autre avec la même IP que la freebox.
Là, faut m'expliquer les problèmes avec le seedbox de la box, qui semble également limitée à un peu moins de 4Mo/s. Là, le conflit d'adresse IP du LAN ne doit pas perturber, non?
Si la Box est une Revo R1, il est plus simple de la changer. Les serveurs Revo R1 étaient de vraient chaudière pour de l'ADSL. Clair que les circuits doivent être dans un état "avancé"...
EN passant, si l'afficheur est "secoué" (à peine visible) il suffit d'appeler le SAV sur ce motif. Cela rend impossible l'autorisation de couplage d'une application avec la box, car il faut l'afficheur pour valider!
C'est un motif "légitime" pour le SAV pour le remplacement du serveur!
-
Là, faut m'expliquer les problèmes avec le seedbox de la box, qui semble également limitée à un peu moins de 4Mo/s. Là, le conflit d'adresse IP du LAN ne doit pas perturber, non?
La seedbox de la revo est très limitée. La faute au fait que cela consomme des ressources processeurs (qui n'est PAS celui pour le routage), que le chiffrement HW n'est probablement plus supporté (probablement un support HW pour le TDES plus supporté, mais pas pour l'AES courant aujourd'hui,faut traiter en software chaque paquet, donc le CPU doit recevoir chaque paquet et surenchère d'interruption), et que le processeur est lent (top pour les années 200x mais plus maintenant). Que la seedbox soit limitée à 5MB/s ça ne me choque pas plus que ça. Il me semble qu'on peut obtenir au mieux un 10MB/s sur un téléchargement depuis http(SANS s), sinon le chiffrement fait chuter considérablement.
Edit: Et bien sûr c'est pas mieux via torrent qui chiffre tout aussi.
-
La seedbox de la revo est très limitée. La faute au fait que cela consomme des ressources processeurs (qui n'est PAS celui pour le routage), que le chiffrement HW n'est probablement plus supporté (probablement un support HW pour le TDES plus supporté, mais pas pour l'AES courant aujourd'hui,faut traiter en software chaque paquet, donc le CPU doit recevoir chaque paquet et surenchère d'interruption), et que le processeur est lent (top pour les années 200x mais plus maintenant). Que la seedbox soit limitée à 5MB/s ça ne me choque pas plus que ça. Il me semble qu'on peut obtenir au mieux un 10MB/s sur un téléchargement depuis http(SANS s), sinon le chiffrement fait chuter considérablement.
Edit: Et bien sûr c'est pas mieux via torrent qui chiffre tout aussi.
Sur Revo, le HDD interne tient 23/25 mo/s que ce soit torrent ou téléchargement classique.
-
Je ne comprends pas trop, car ici (https://lafibre.info/1gb-free/freebox-v6-onu-recent-gt-30-mos-max-par-session-tcp/msg927243/#msg927243) par exemple tu montres un résultat avec un débit à 85 Mo/s en mono-connexion:
Donc c'est que ta ligne permet de monter à ce débit en mono-connexion, comme avec un navigateur web...
C'est justement ça que je ne comprends pas.
test-debit.free.fr me donne systématiquement 5Mo/sec, idem via fillezilla (sur n'importe quel serveur), et ce quelque soit la machine utilisée, ou l'OS utilisé.
Les tests ont bien entendu été réalisés que par ethernet, wifi désactivé, et une seule machine connectée à la box.
Donc, en dehors d'un problème matériel (freebox server ou ONU) ou engorgement réseau systématique, je ne vois pas.
De plus, je tiens à préciser que tout le matos venant de chez free est neuf, car j'ai mon abonnement que depuis un mois...
-
biensur!
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-100-generic (x86_64)
--------------------------- 2022-03-03 16:35:14 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: 73.61 Mo/s (588.86 Mbps)
Test TCP Internet (AS12876-BBR)...
--> Latence: 6.27 ms
--> Débit: 82.26 Mo/s (658.12 Mbps)
Test TCP Internet (AS12876-CUBIC)...
--> Latence: 6.08 ms
--> Débit: 5.27 Mo/s (42.15 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-03 16:36:26 GMT ---------------------------
-
Et voila!
Au passage, que veux-tu dire par "changer d'AS"?
kkwete@kkwete:~/Bureau$ perl checkBugOnuFree.pl -a
===============================================================================
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-100-generic (x86_64)
--------------------------- 2022-03-03 16:53:17 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.38 ms
--> Débit: 74.28 Mo/s (594.26 Mbps)
Test TCP Internet (AS5410-BBR)...
--> Latence: 6.19 ms
--> Débit: 110.82 Mo/s (886.54 Mbps)
Test TCP Internet (AS5410-CUBIC)...
--> Latence: 6.10 ms
--> Débit: 5.54 Mo/s (44.33 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-03 16:54:29 GMT ---------------------------
Je te rejoins, je n'y comprends rien...
Je viens d'appeler free, ils vont faire une surveillance de ligne et ils m'ont demandé de redémarrer 3x la freebox, samedi, mardi et vendredi prochain.
-
Et voila!
Au passage, que veux-tu dire par "changer d'AS"?
kkwete@kkwete:~/Bureau$ perl checkBugOnuFree.pl -a
===============================================================================
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-100-generic (x86_64)
--------------------------- 2022-03-03 16:53:17 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.38 ms
--> Débit: 74.28 Mo/s (594.26 Mbps)
Test TCP Internet (AS5410-BBR)...
--> Latence: 6.19 ms
--> Débit: 110.82 Mo/s (886.54 Mbps)
Test TCP Internet (AS5410-CUBIC)...
--> Latence: 6.10 ms
--> Débit: 5.54 Mo/s (44.33 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-03 16:54:29 GMT ---------------------------
Je te rejoins, je n'y comprends rien...
Je viens d'appeler free, ils vont faire une surveillance de ligne et ils m'ont demandé de redémarrer 3x la freebox, samedi, mardi et vendredi prochain.
4194304
=> Latence TCP max pour une réception à 1 Gbps: 27 ms
Y a eu bidouille TCP, c'est 141 par défaut.
-
Est-ce que tu te souviens si tu avais le même souci de téléchargement limité à 5 Mo/s avec les serveurs en CUBIC avant que tu fasses le hard reset de ton boîtier ONU ?
Honnêtement, je ne pourrais te répondre, incapable de m'en souvenir.
Et oui, je suis le plus clair de mon temps sous linux, plus précisément sous Ubuntu budgie LTS.
Mais je peux faire des tests sous Windows si cela peut aider!
-
Ah non, pourquoi?
Je reste le seul à avoir tenté le coup?
-
Je peux tenter en effet, mais vu que ma ligne est sous surveillance, j'hésite...
;)
-
4194304
=> Latence TCP max pour une réception à 1 Gbps: 27 ms
Y a eu bidouille TCP, c'est 141 par défaut.
C'est un calcul théorique issu essentiellement de la taille maximale de la fenêtre de réception TCP et de la bande passante. Sous Windows cette taille max est par défaut plus importante que dans cette configuration-ci et il en résulte les 141 ms.
-
Hard reboot de l'ONU v2 fait à l'instant... toujours bridé à 300 Mbits/s !
:o bizarre bizarre
-
Je peux tenter en effet, mais vu que ma ligne est sous surveillance, j'hésite...
;)
Rassures-toi, ils ne surveillent rien du tout ;)
-
Rassures-toi, ils ne surveillent rien du tout ;)
Toutafé, on a parfaitement le droit d'avoir une coupure de courant, juste au moment où l'on se demandait ce qu'était le petit bouton et s'il ne ferait pas par hasard "crac-boum-hue", non? ;)
-
Allez, je tente le truc!
En même temps, pas grand chose à perdre... ;)
Donc, reset de l'ONU V2 puis:
kkwete@kkwete:~/Bureau$ perl -a 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-100-generic (x86_64)
--------------------------- 2022-03-04 16:44:52 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.44 ms
--> Débit: 73.64 Mo/s (589.09 Mbps)
Test TCP Internet (AS12876-BBR)...
--> Latence: 6.55 ms
--> Débit: 108.96 Mo/s (871.72 Mbps)
Test TCP Internet (AS12876-CUBIC)...
--> Latence: 6.15 ms
--> Débit: 4.86 Mo/s (38.88 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-04 16:46:04 GMT ---------------------------
kkwete@kkwete:~/Bureau$
-
Je viens de tester:
-30Mo/sec en IPv4 et en IPv6 en BBR
-5Mo/sec en IPv4 et en IPv6 en CUBIC
Sans appel.
Existe-il une solution à cela?
Concernant le test iperf3 en UDP, je viens de tester ceci:
kkwete@kkwete:~$ iperf3 -c lille.testdebit.info -p 9200
Connecting to host lille.testdebit.info, port 9200
[ 5] local 2a01:e0a:a6c:f290:d545:421d:f109:3380 port 50236 connected to 2001:860:de12:200::2 port 9200
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 79.5 MBytes 667 Mbits/sec 65 1.35 MBytes
[ 5] 1.00-2.00 sec 81.2 MBytes 682 Mbits/sec 0 1.47 MBytes
[ 5] 2.00-3.00 sec 81.2 MBytes 682 Mbits/sec 0 1.56 MBytes
[ 5] 3.00-4.00 sec 81.2 MBytes 682 Mbits/sec 0 1.64 MBytes
[ 5] 4.00-5.00 sec 81.2 MBytes 682 Mbits/sec 25 1.20 MBytes
[ 5] 5.00-6.00 sec 81.2 MBytes 682 Mbits/sec 0 1.28 MBytes
[ 5] 6.00-7.00 sec 81.2 MBytes 682 Mbits/sec 0 1.34 MBytes
[ 5] 7.00-8.00 sec 81.2 MBytes 682 Mbits/sec 0 1.38 MBytes
[ 5] 8.00-9.00 sec 81.2 MBytes 682 Mbits/sec 0 1.40 MBytes
[ 5] 9.00-10.00 sec 80.0 MBytes 671 Mbits/sec 0 1.42 MBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 810 MBytes 679 Mbits/sec 90 sender
[ 5] 0.00-10.02 sec 808 MBytes 677 Mbits/sec receiver
iperf Done.
-
Ah quel c**! ;)
J'ai pris un serveur sur Lille, je suis pas très loin.
J'ai bien vérifié, mon débit est bien à 0 au moment du test.
kkwete@kkwete:~$ iperf3 -c lille.testdebit.info -u -b 800M -p 9201 -R
Connecting to host lille.testdebit.info, port 9201
Reverse mode, remote host lille.testdebit.info is sending
[ 5] local 2a01:e0a:a6c:f290:d545:421d:f109:3380 port 36520 connected to 2001:860:de12:200::2 port 9201
[ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams
[ 5] 0.00-1.00 sec 55.5 MBytes 465 Mbits/sec 0.016 ms 29245/69982 (42%)
[ 5] 1.00-2.00 sec 55.8 MBytes 468 Mbits/sec 0.013 ms 29092/70041 (42%)
[ 5] 2.00-3.00 sec 55.7 MBytes 467 Mbits/sec 0.011 ms 29159/70028 (42%)
[ 5] 3.00-4.00 sec 55.8 MBytes 468 Mbits/sec 0.014 ms 29051/70019 (41%)
[ 5] 4.00-5.00 sec 56.0 MBytes 470 Mbits/sec 0.014 ms 28917/70035 (41%)
[ 5] 5.00-6.00 sec 56.0 MBytes 470 Mbits/sec 0.015 ms 28900/70028 (41%)
[ 5] 6.00-7.00 sec 55.8 MBytes 468 Mbits/sec 0.014 ms 29062/70025 (42%)
[ 5] 7.00-8.00 sec 56.4 MBytes 473 Mbits/sec 0.014 ms 28609/70031 (41%)
[ 5] 8.00-9.00 sec 56.4 MBytes 473 Mbits/sec 0.015 ms 28580/70027 (41%)
[ 5] 9.00-10.00 sec 55.9 MBytes 469 Mbits/sec 0.016 ms 28987/70017 (41%)
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams
[ 5] 0.00-10.01 sec 955 MBytes 800 Mbits/sec 0.000 ms 0/700940 (0%) sender
[ 5] 0.00-10.00 sec 559 MBytes 469 Mbits/sec 0.016 ms 289602/700233 (41%) receiver
iperf Done.
-
Par Paris, c'est encore pire...
kkwete@kkwete:~$ iperf3 -c paris.testdebit.info -u -b 800M -p 9201 -R
Connecting to host paris.testdebit.info, port 9201
Reverse mode, remote host paris.testdebit.info is sending
[ 5] local 2a01:e0a:a6c:f290:2487:c234:a59:94a7 port 54694 connected to 2001:860:de01:1101::2 port 9201
[ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams
[ 5] 0.00-1.00 sec 54.2 MBytes 454 Mbits/sec 0.043 ms 30213/69980 (43%)
[ 5] 1.00-2.00 sec 54.0 MBytes 453 Mbits/sec 0.042 ms 30371/70027 (43%)
[ 5] 2.00-3.00 sec 55.6 MBytes 466 Mbits/sec 0.042 ms 29210/70030 (42%)
[ 5] 3.00-4.00 sec 54.5 MBytes 457 Mbits/sec 0.039 ms 30003/70031 (43%)
[ 5] 4.00-5.00 sec 54.7 MBytes 459 Mbits/sec 0.046 ms 29877/70023 (43%)
[ 5] 5.00-6.00 sec 54.5 MBytes 457 Mbits/sec 0.046 ms 30041/70029 (43%)
[ 5] 6.00-7.00 sec 55.4 MBytes 465 Mbits/sec 0.046 ms 29354/70026 (42%)
[ 5] 7.00-8.00 sec 54.8 MBytes 460 Mbits/sec 0.047 ms 29785/70027 (43%)
[ 5] 8.00-9.00 sec 54.3 MBytes 455 Mbits/sec 0.046 ms 30179/70028 (43%)
[ 5] 9.00-10.00 sec 54.4 MBytes 457 Mbits/sec 0.044 ms 30059/70035 (43%)
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams
[ 5] 0.00-10.01 sec 954 MBytes 800 Mbits/sec 0.000 ms 0/700651 (0%) sender
[ 5] 0.00-10.00 sec 546 MBytes 458 Mbits/sec 0.044 ms 299092/700236 (43%) receiver
iperf Done.
Donc, dans ce cas, le probleme peut venir d'où?
-
Toujours à propos de l'ONU v2. Pourrait on imaginer, que par une manipulation aussi subtile qu'inconnue il soit revenu au firmware usine (qui ne comporterait pas le bug) à l'instar des Freebox (débrancher/rebrancher) ???
-
A mon sens, les 2 problèmes sont distincts, et ce débit catastrophique chez moi dure depuis l'installation de la freebox.
sauf que le temps que je m'en apperçoive, il s'est passé du temps.
Je n'avais pas pensé aux cables en effet, j'ai donc testé le changement de port, de cable et de jarretière: sans effet.
Dommage, c'était une bonne idée!
-
Comme il fallait s'en douter, aucun changement niveau débit après 2 redemarrages programmées...Le dernier se fera vendredi, mais je doute fortement que cela change quoi que ce soit...!
::)
-
Comme il fallait s'en douter, aucun changement niveau débit après 2 redemarrages programmées...Le dernier se fera vendredi, mais je doute fortement que cela change quoi que ce soit...!
::)
En gros, pour se faire remplacer le matos, il ne reste que la "panne" complète... Genre l'ONU qui rend son petit déjeuner, ou la box, ou... Le problème est la rupture complète de service pendant 20/72h... ;)
Dans une vie antérieure, j'ai "sévi" dans le dépannage électronique grand public (On pouvait encore dépanner!), et à certaines occasions, il fallait "aider" le client à diagnostiquer un coup de foudre pour l'assurance... :) ;) :o
-
En gros, pour se faire remplacer le matos, il ne reste que la "panne" complète... Genre l'ONU qui rend son petit déjeuner, ou la box, ou... Le problème est la rupture complète de service pendant 20/72h... ;)
Dans une vie antérieure, j'ai "sévi" dans le dépannage électronique grand public (On pouvait encore dépanner!), et à certaines occasions, il fallait "aider" le client à diagnostiquer un coup de foudre pour l'assurance... :) ;) :o
Ne me tente pas, mon fer à souder mé démange...
;D ;D ;D
-
Ne me tente pas, mon fer à souder mé démange...
;D ;D ;D
Mais nan! J'évoquais juste le cas du gars qui à un monstrueux bol qui ferait la panne définitive arrive à point nommé! M'enfin, qu'est-ce l'imagination peut faire, quand même! ;)
-
Et ben en fait, j'ai bien fait de patienter un peu...
Je test un dl un iso free un peu machinalement, et je vois ça:
(https://zupimages.net/up/22/10/6dqx.png) (https://zupimages.net/viewer.php?id=22/10/6dqx.png)
Je me dis, tiens c'est bizarre ça...!
Du coup je lance un test ONU sur mon ubuntu budgie:
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-104-generic (x86_64)
--------------------------- 2022-03-12 12:01:25 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.46 ms
--> Débit: 73.94 Mo/s (591.54 Mbps)
Test TCP Internet (AS12876-BBR)...
--> Latence: 6.50 ms
--> Débit: 107.63 Mo/s (861.05 Mbps)
Test TCP Internet (AS12876-CUBIC)...
--> Latence: 6.50 ms
--> Débit: 108.08 Mo/s (864.61 Mbps)
La connexion ne semble pas affectée par un dysfonctionnement de boîtier ONU Free.
--------------------------- 2022-03-12 12:02:37 GMT ---------------------------
Et là, je tombe des nues...
Je finis par réaliser un test en single via speedtest.net:
(https://zupimages.net/up/22/10/r3s6.png) (https://zupimages.net/viewer.php?id=22/10/r3s6.png)
Du coup, je ne touche plus à rien!!!
Ces résultats sont identiques sous windows 10, sur la même machine, via un dualboot, ce qui confirme que ça n'est pas un pb de paramétrage de l'OS.
De plus, je n'ai rien modifié à l'installation, uniquement un reboot complet de la freebox et de l'ONU, comme demandé par free.
Je vous encourage donc à tester!
-
Tout cela est bien mystérieux.
Je ne comprends pas comment tu as réussi à faire fonctionner ton ONU v2 à plein régime.
Apparemment tu es bien le seul... Et on n'a pas moyen de connaître la version de firmware de ce fichu machin !
Ta révolution est une R2, R3 ?
-
A priori, cest une R1.
(https://zupimages.net/up/22/10/v57w.png) (https://zupimages.net/viewer.php?id=22/10/v57w.png)
C'est pas d'ailleurs un peu étrange?
Car le matériel est neuf, je dois l'avoir reçu en janvier...
-
Les Revolution sont des box reconditionnées. Ca se remarque souvent à l'afficheur OLed qui est brûlé.
Moi c'est une R2 également reçue en janvier.
-
Les Revolution sont des box reconditionnées. Ca se remarque souvent à l'afficheur OLed qui est brûlé.
Moi c'est une R2 également reçue en janvier.
Sans vouloir trop la ramener, le premier truc qui semble être remplacé sur les Revo reconditionnées est l'afficheur Oled...
Un gentil "chaud ligneur" m'a lâché un jour que c'était une cause "valable" de remplacement...
Clair que s'il n'y a plus d'affichage, impossible de faire les manips demandée par le chaud-ligneur...
-
Dans les usines de reconditionnement, il y a des critères pour savoir si on laisse tel quel / remplace / détruit.
Pour changer de Freebox tous les 15 mois ;) j'en ai déjà eu avec des traces de brûlure, après évidemment si le OLed est vraiment dégueu ils doivent le changer ! Le module WiFi aussi est changé (d'origine les R1 n'ont pas le 802.11 AC).
J'avais visité en son temps une usine Anovo qui reconditionnait les décodeurs Canal+ "Discret 11" (les bien-nommés ;D). Très intéressant notamment pour la partie grainage qui redonnait l'aspect du neuf aux capots plastiques.
-
Merci pour ces infos.
Maintenant, j'ai juste peur de devoir redémarrer la box...
;D ;D
-
Merci pour ces infos.
Maintenant, j'ai juste peur de devoir redémarrer la box...
;D ;D
De toutes façons, sauf à être sur une alimentation secourue genre onduleur, elle redémarrera un jour ou l'autre... Et récupèrera le firmware qui "ira bien"... ou non! ;)
-
Elle est en effet sur un onduleur, mais comme je suis joueur et que je voulais savoir, j'ai redémarré le tout.
Et......ben toujfonctionne parfaitement.
Ceux qui ont tenté un reset ONU V2, il serait peut-être interessant de retenter le coup, je ne vois que ça...
-
Et ben en fait, j'ai bien fait de patienter un peu...
Je test un dl un iso free un peu machinalement, et je vois ça:
(https://zupimages.net/up/22/10/6dqx.png) (https://zupimages.net/viewer.php?id=22/10/6dqx.png)
Je me dis, tiens c'est bizarre ça...!
Du coup je lance un test ONU sur mon ubuntu budgie:
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-104-generic (x86_64)
--------------------------- 2022-03-12 12:01:25 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.46 ms
--> Débit: 73.94 Mo/s (591.54 Mbps)
Test TCP Internet (AS12876-BBR)...
--> Latence: 6.50 ms
--> Débit: 107.63 Mo/s (861.05 Mbps)
Test TCP Internet (AS12876-CUBIC)...
--> Latence: 6.50 ms
--> Débit: 108.08 Mo/s (864.61 Mbps)
La connexion ne semble pas affectée par un dysfonctionnement de boîtier ONU Free.
--------------------------- 2022-03-12 12:02:37 GMT ---------------------------
Et là, je tombe des nues...
Je finis par réaliser un test en single via speedtest.net:
(https://zupimages.net/up/22/10/r3s6.png) (https://zupimages.net/viewer.php?id=22/10/r3s6.png)
Du coup, je ne touche plus à rien!!!
Ces résultats sont identiques sous windows 10, sur la même machine, via un dualboot, ce qui confirme que ça n'est pas un pb de paramétrage de l'OS.
De plus, je n'ai rien modifié à l'installation, uniquement un reboot complet de la freebox et de l'ONU, comme demandé par free.
Je vous encourage donc à tester!
Pour résumer, ONU v2, et plus de soucis de bridage à 30mo/s en mono cession ?!
-
Tu as en effet bien résumé l'affaire!
-
Je l'ai fait et refait, sans résultat.
La seule hypothèse qui me reste, c'est que tu as peut être fait une manœuvre supplémentaire accidentellement...
Du même genre que quand on débranche/rebranche 3 fois la Freebox elle part sur le firmware usine (juste pour l'exemple).
-
Je l'ai fait et refait, sans résultat.
La seule hypothèse qui me reste, c'est que tu as peut être fait une manœuvre supplémentaire accidentellement...
Du même genre que quand on débranche/rebranche 3 fois la Freebox elle part sur le firmware usine (juste pour l'exemple).
A tout hasard, tu as essayé de sortir l'adaptation de la cage sfp de la box, souffler un bon coup dedans et remettre l'ONU. Avec le temps, vu que le port c'est pas utilisé en ADSL, il se charge de poussière et ça arrive que la pose problème au passage de la fibre (en fin de bridage, mais on ne sait jamais).
-
Je ne pense pas avoir fait autre chose, même pas inadvertance, car cela ne fonctionnait pas mieux avant de harceler free.
Puis, j'ai juste redémarré l'onu et la box.
Je penche donc sur une résolution du pb du côté de chez free.
Ce qui sous entendrait qu'il est possible de régler le pb de manière logicielle, uniquement par une maj.
-
Je ne pense pas avoir fait autre chose, même pas inadvertance, car cela ne fonctionnait pas mieux avant de harceler free.
Puis, j'ai juste redémarré l'onu et la box.
Je penche donc sur une résolution du pb du côté de chez free.
Ce qui sous entendrait qu'il est possible de régler le pb de manière logicielle, uniquement par une maj.
Très très peu probable.
T'es bien certain d'avoir l'ONU v2 ?
-
ah oui!
J'ai celui-ci:
https://www.busyspider.fr/Free-fibre-optique-freebox-boitier-onu-version-2-presentation-schemas-branchements-photos-notice-installation.php
-
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
-
Il est possible qu'ils poussent des firmware beta à quelques utilisateurs pour voir le retour, ou un déploiement par vagues (les autres opérateurs le font aussi)
-
- Ou une MAJ firmware des OLT, NRO par NRO, voire un fichier de paramétrage que les ONU récupèrent à la connexion...
En tous cas, point positif: les choses bougent !