Auteur Sujet: [RÉSOLU] Suspicion de limitation à 4Gps Freebox Delta & ULtra (Lu 30552 fois)

mbizon · « **Réponse #180 le:** 24 février 2025 à 14:43:22 »

Bonjour,

Citation de: geek31 le 22 février 2025 à 15:00:21

Code: [Sélectionner]
=> Latence TCP max pour une réception à 1 Gbps: 27 ms => Latence TCP max pour une émission à 700 Mbps: 35 ms [...] Test TCP local (IPv4): téléchargement depuis la Freebox --> Latence: 0.33 ms [gigue: 0.01 ms] --> Débit: 1.16 Go/s (9.32 Gbps) [fluctuation: 0.53%] Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [BBR] --> Latence: 12.75 ms [gigue: 0.29 ms] --> Débit: 246.04 Mo/s (1.97 Gbps) [fluctuation: 0.43%] Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [CUBIC] --> Latence: 11.80 ms [gigue: 0.39 ms] --> Débit: 265.99 Mo/s (2.13 Gbps) [fluctuation: 0.60%] -------------------------- 2025-02-22 14:22:22 +0100 --------------------------

Pour votre cas en particulier:

La sortie de checkFtthFree vous indique un débit en réception de 1Gbit/s max vers un peer TCP ayant 27ms de latence (limite/configuration de la stack TCP de votre OS, par connexion)

Avec une règle de trois, ça donnerait environ 2Gbit/s pour 13ms de latence, étrangement similaire à ce que vous constatez avec votre iperf.

Cela explique pourquoi vous avez de meilleurs résultats avec plusieurs connexions en parallèle.

J'invite les différents protagonistes sur ce fil à faire la même vérification, un test local LAN à 10Gbit/s est une condition nécessaire mais pas suffisante pour obtenir le même résultat avec une latence plus élevée (google://bandwidth-delay product)

A tous:

Il n'y a aucune limitation intentionnelle de débit.

Si problème il y a, c'est un bug involontaire, mais vous comprendrez qu'à ces débits ce ne soit pas évident de trouver la cause facilement.

vivien · « **Réponse #181 le:** 24 février 2025 à 14:51:09 »

Si vous souhaitez faire des tests avec des latences supérieures pour voir comment cela impact le débit, si vous êtes sous Linux, il y a un outil intégré qui permet de le faire NetEm.

⇒ Tutoriel pour générer des pertes de paquets / latence / gigue sur un équipement avec NetEm

Citation de: vivien le 14 juin 2011 à 07:21:18

Commande NetEm pour rajouter du délai sur les paquets émis par l'interface Eth0 :
- Premier lancement avec 100ms de latence : sudo tc qdisc add dev eth0 root netem delay 100ms
- Modification de la latence à 10ms : sudo tc qdisc change dev eth0 root netem delay 10ms
- Suppression de la latence supplèmentaire : sudo tc qdisc change dev eth0 root netem delay 0ms

Toujours sous Linux, voici quelques optimisations TCP pour permettre d'avoir des débits élevés sur une connexion TCP.

nano /etc/sysctl.d/90-optimisations-tcp.conf
Copier / coller la configuration BBR ou la configuration Cubic en fonction de votre choix.

BBR : Copier / coller le texte ci-dessous dans le fichier :

Code: [Sélectionner]

# Algorithme d’évitement de congestion TCP et qdisc
net.ipv4.tcp_congestion_control=bbr
net.core.default_qdisc=fq

# décorrélation des tests successifs
net.ipv4.tcp_no_metrics_save=1

# Paramétrage de la fenêtre TCP à 32 Mio
net.ipv4.tcp_rmem=4096 131072 33554432
net.ipv4.tcp_wmem=4096 87380 33554432
net.core.rmem_max=33554432
net.core.wmem_max=33554432

# Limiter l’utilisation du swap
vm.swappiness = 1

# Augmentation de la file d'attente dans le noyau Linux où le trafic est stocké après réception par la carte réseau
net.core.netdev_max_backlog=4000

# Réduire le seuil où un DDOS impacte le serveur
net.ipv4.tcp_max_syn_backlog = 4096

# Augmenter le nombre de connexions entrantes
net.core.somaxconn = 4096

Cubic : Copier / coller le texte ci-dessous dans le fichier :

Code: [Sélectionner]

# Algorithme d’évitement de congestion TCP et qdisc
net.ipv4.tcp_congestion_control=cubic
net.core.default_qdisc=fq_codel

# décorrélation des tests successifs
net.ipv4.tcp_no_metrics_save=1

# Paramétrage de la fenêtre TCP à 32 Mio
net.ipv4.tcp_rmem=4096 131072 33554432
net.ipv4.tcp_wmem=4096 87380 33554432
net.core.rmem_max=33554432
net.core.wmem_max=33554432

# Limiter l’utilisation du swap
vm.swappiness = 1

# Augmentation de la file d'attente dans le noyau Linux où le trafic est stocké après réception par la carte réseau
net.core.netdev_max_backlog=4000

# Réduire le seuil où un DDOS impacte le serveur
net.ipv4.tcp_max_syn_backlog = 4096

# Augmenter le nombre de connexions entrantes
net.core.somaxconn = 4096

kgersen · « **Réponse #182 le:** 24 février 2025 à 15:08:16 »

Citation de: mbizon le 24 février 2025 à 14:43:22

Si problème il y a, c'est un bug involontaire, mais vous comprendrez qu'à ces débits ce ne soit pas évident de trouver la cause facilement.

"qu'à ces débits ce ne soit pas évident"
non je ne comprend pas.

Lolilol51 · « **Réponse #183 le:** 24 février 2025 à 15:50:12 »

Je ne me souviens plus à quelle date exacte cela a commencé à planter, vers fin janvier 2025.
Mais ce dont j'ai la certitude, c'est qu'il n'y avait absolument aucun problème avant le lancement de la nouvelle Freebox Pro.

Pourquoi ne pas réinstaller l'ancien firmware sur le matériel réseau qui a été mis à jour ?

fansat70 · « **Réponse #184 le:** 24 février 2025 à 16:00:58 »

Citation de: Lolilol51 le 24 février 2025 à 15:50:12

Je ne me souviens plus à quelle date exacte cela a commencé à planter, vers fin janvier 2025.
Mais ce dont j'ai la certitude, c'est qu'il n'y avait absolument aucun problème avant le lancement de la nouvelle Freebox Pro.

Pourquoi ne pas réinstaller l'ancien firmware sur le matériel réseau qui a été mis à jour ?

La question que l'on peut se poser est de savoir quelle corrélation il peut y avoir entre le lancement de la nouvelle Freebox Pro, un éventuel nouveau firmware Sur la Freebox Pro, un éventuel nouveau firmware sur les Freebox grand public et/ou un upgrade réseau qui aurait partiellement foiré.
Toutes choses qui ne sont pas forcément sous la houlette des Devs de Freebox grand public?!?

Lolilol51 · « **Réponse #185 le:** 24 février 2025 à 16:07:04 »

Je gère 5 Freebox dans la famille, et lorsque les problèmes de débit ont commencé, j'ai remarqué des coupures de connexion de 2 ou 3 minutes entre 4h et 6h du matin sur presque toutes les Freebox.
C'était le même jour, mais je ne me souviens plus quand. En tout cas, après le 14 janvier 2025, c'est une certitude.

altair83 · « **Réponse #186 le:** 24 février 2025 à 16:08:56 »

Citation de: mbizon le 24 février 2025 à 14:43:22

Bonjour,

Pour votre cas en particulier:

La sortie de checkFtthFree vous indique un débit en réception de 1Gbit/s max vers un peer TCP ayant 27ms de latence (limite/configuration de la stack TCP de votre OS, par connexion)

Avec une règle de trois, ça donnerait environ 2Gbit/s pour 13ms de latence, étrangement similaire à ce que vous constatez avec votre iperf.

Cela explique pourquoi vous avez de meilleurs résultats avec plusieurs connexions en parallèle.

J'invite les différents protagonistes sur ce fil à faire la même vérification, un test local LAN à 10Gbit/s est une condition nécessaire mais pas suffisante pour obtenir le même résultat avec une latence plus élevée (google://bandwidth-delay product)

A tous:

Il n'y a aucune limitation intentionnelle de débit.

Si problème il y a, c'est un bug involontaire, mais vous comprendrez qu'à ces débits ce ne soit pas évident de trouver la cause facilement.

Bonjour @mbizon,
Merci de prendre en charge notre demande collective, nous attendions cela depuis longtemps.
Comme je sais au fil de tes posts sur les réseaux que tu aimes les personnes qui s'y connaissent bien.

Citation de: mbizon le 04 décembre 2015 à 14:00:09

J'ai rarement reçu une réponse technique d'aussi grande qualité de la part d'un abonné...
ça mérite un test, je vous tiens au courant

Je suppose que tu as lu, sur le bug tracker, les explications de @nbanba https://dev.freebox.fr/bugs/task/40060 qui me paraissent très explicite et qui devrait plus te parler qu'à moi-même.
Personne de Free n'a encore répondu sur ce post du tracker, il faut savoir que nous aimons les explications, le suivis et cela évite aussi les débordements.
(je dis cela sans aucune intention de nuire, juste nous discutons tous dans le respect de chacun.)
Entre autres, certains avaient demandé de repasser en v 4.8.16 le dernier firmware ou nous n'avons pas de souci, ça serait un test aussi.
Merci de m'avoir lu.
Cordialement.
Franck

altair83 · « **Réponse #187 le:** 24 février 2025 à 16:15:29 »

Citation de: Lolilol51 le 24 février 2025 à 16:07:04

Je gère 5 Freebox dans la famille, et lorsque les problèmes de débit ont commencé, j'ai remarqué des coupures de connexion de 2 ou 3 minutes entre 4h et 6h du matin sur presque toutes les Freebox.
C'était le même jour, mais je ne me souviens plus quand. En tout cas, après le 14 janvier 2025, c'est une certitude.

Bonjour @Lolilo51,
Comme je garde des copies d'écran de beaucoup de chose, c'est pratique.
Pour ma part, j'ai eu une coupure le 28/01/2025 à 6h56 et c'est depuis le 28 que la connexion est tombée à ce débit ...
Cordialement.
Franck

Lolilol51 · « **Réponse #188 le:** 24 février 2025 à 16:20:04 »

@altair83

Cela ne semble pas correspondre à mes dates, mais cela semble en revanche coïncider au niveau de l'heure et de la durée de la coupure.

altair83 · « **Réponse #189 le:** 24 février 2025 à 16:27:55 »

@Lolilol51

et j'ai une copie d'écran aussi d'avant mais entre le 13/01/2025 et 24/01/2025 je n'ai pas de coupure donc là, je ne peux pas plus aider.
Cordialement.
Franck

kfc · « **Réponse #190 le:** 24 février 2025 à 16:54:36 »

est ce qu'il pourrait etre judicieux d'avoir une liaison semi-directe entre une communité d'abonnés avertis comme ici et un étage non-débutant du support Free ? genre un équivalent TAM / community manager avec double casquette pour escalader les sujet dont un sait que le premier niveau de support ne saura pas quoi faire ..

nbanba · « **Réponse #191 le:** 24 février 2025 à 16:56:31 »

Bonjour

Citation de: zbug le 24 février 2025 à 11:56:43

Tout à fait d'accord avec @kgersen.
Avoir un test de débit depuis l'écran de la box même, en supposant que du côté tech ils auraient une api pour voir la remonté et/ou le lancer à distance de la même manière serait un gros plus pour ce genre d'investigation.

Tout à fait d'accord, ce serait un gros plus qui aurait éviter tout ce bruit.

Citation de: zbug le 24 février 2025 à 11:56:43

Pour l'autre point, peut-importe d'ailleurs la société, quand on à faire à un support technique (que vous soyez le client ou le tech), la base, c'est de partir sur la configuration la plus simple pour s'assurer que le soucis n'est pas exterieur.
Venir avec son "je m'y connais et j'ai du gros matos" n'apporte rien à part ajouter de forte chance que la personne de l'autre côté vous fiche direct et traîne les pieds.

Je suis aussi dans le milieu, ai du matos entreprise, mais, étant un utilisateur d'une ligne grand publique (Free), je sais reconnaitre ou sont les limites et quand je contacte free pour un soucis, je m'assure d'avoir uniquement la box, un pc, point barre.

Je pense qu'il faudrait un peu modéré ce raccourci...
Tout à commencé par des remontés simples et claires au support.
Au lieu d'être prises en compte on nous a expliqué que tout allait bien et que les infra locales étaient certainement défectueuse ou nos tests invalides.
À force d'insistance on à du prouver que les infra locales n'étaient pas en cause ni les tests réalisés par ceux qui étaient concernés d'où le détail des architectures et leurs métriques postées et probablement d'où votre raccourci: "je m'y connais et j'ai du gros matos".
D'ailleurs je ne pense pas qu'en 2025 les équipements LAN qui supportent le 10Gbps (ou un flux 10Gbps les traversant) même de gamme pro soient du "gros" matos (c'est juste assez fiable).

Si tout simplement le souci avait été pris en compte sur nos simples dires (voir une démo en visio d'1 minutes pour montrer 3 iperf3 à une personne sachant les comprendre), on n'en serait jamais arrivé là.
On n'aurai d'ailleurs bien aimé éviter (ça prends du temps, faut vulgariser, on n'avait pas forcément envie de poster autant de détails sur des forums publiques ...)

Citation de: zbug le 24 février 2025 à 11:56:43

Pour le bruit de comm, c'est bien dommage que l'on en soit arrivé à cela, mais depuis 4/5ans, c'est ce qui marche, peut importe pour quel soucis. Si le support vous aide pas, un gros ralage sur X et miracle... (c'est une généralité, rien à voir avec Free)

Malheureusement je crois que vous avez encore raison sur ce point... Malheureusement...

Dans tous les cas, merci à tous ceux qui ont contribué à la prise en compte du problème et qui ont aidé

Cordialement
nbanba

Auteur Sujet: [RÉSOLU] Suspicion de limitation à 4Gps Freebox Delta & ULtra (Lu 30552 fois)

mbizon

[TEST SVP] Suspicion de limitation à 4Gps des Freebox Delta & ULtra

vivien

[TEST SVP] Suspicion de limitation à 4Gps des Freebox Delta & ULtra

kgersen

[TEST SVP] Suspicion de limitation à 4Gps des Freebox Delta & ULtra

Lolilol51

[TEST SVP] Suspicion de limitation à 4Gps des Freebox Delta & ULtra

fansat70

[TEST SVP] Suspicion de limitation à 4Gps des Freebox Delta & ULtra

Lolilol51

[TEST SVP] Suspicion de limitation à 4Gps des Freebox Delta & ULtra

altair83

[TEST SVP] Suspicion de limitation à 4Gps des Freebox Delta & ULtra

altair83

[TEST SVP] Suspicion de limitation à 4Gps des Freebox Delta & ULtra

Lolilol51

[TEST SVP] Suspicion de limitation à 4Gps des Freebox Delta & ULtra

altair83

[TEST SVP] Suspicion de limitation à 4Gps des Freebox Delta & ULtra

kfc

[TEST SVP] Suspicion de limitation à 4Gps des Freebox Delta & ULtra

nbanba

[TEST SVP] Suspicion de limitation à 4Gps des Freebox Delta & ULtra