Dites, j'ai un problème avec la ligne Free fibre de mes parents dans le sud (Freebox Revolution, NRO 65440LAR). La ligne est censée fournir 1 Gbit/s en réception.

Le problème est qu'un flux TCP simple est fortement limité en débit (direction download). Sur un seul flux TCP je ne peux généralement obtenir que dans les environs de 50 Mbit/s (ça dépend des moments, parfois c'est 20, ça peut monter à 100 si j'ai de la chance). Je constate cette limitation quel que soit le serveur y compris les serveurs de test de Free eux-mêmes, avec iperf3 également, et y compris en jouant avec le mode "single" de speedtest.net. Cette limitation est rédhibitoire pour l'utilisation qui est faite de la ligne.

Notons que si j'ouvre plusieurs flux TCP à la fois (par example iperf3 -P 20 ou le mode multi de speedtest.net), je peux atteindre plusieurs centaines de Mbit/s. Donc ce n'est pas une limitation de débit de la ligne au sens habituel du terme.

Bien évidemment j'ai éliminé toutes les causes de mon côté : testé depuis plusieurs PC différents connectés en filaire au cul de la Freebox et j'ai également vérifié les performances du réseau local. RAS.

J'ai fait quelques mesures plus poussées. J'ai constaté que la ligne semble subir une perte de paquets de l'ordre de 0.033%. Ça semble pas beaucoup dit comme ça, mais ça explique complètement le problème : vu que la connexion a un RTT de l'ordre de 16 ms sur le serveur de test, on arrive mécaniquement à la limitation de débit TCP observée.

Je ne sais pas quelle est la cause de cette perte de paquets. Ça ne semble pas très cohérent avec de la congestion parce que le phénomène ne semble pas dépendre de l'utilisation de la ligne ni vraiment du moment de la journée (pas de différence notable entre heures creuses et heures de pointe).

J'ai essayé d'ouvrir un chat avec l'assistance Free. Comme vous pouvez vous en douter, la personne en face n'a pas compris le problème et pour elle tout va bien sur ma ligne. J'ai supplié mon interlocuteur d'ouvrir un ticket/message auprès d'un spécialiste qui pourrait comprendre la situation, en vain.

Quelqu'un a une idée ? Je pourrais essayer de changer de FAI mais j'ai peur que la perte de paquets soit due à un défaut physique sur l'infra mutualisée, et que changer de FAI n'aurait donc aucun effet…

Concernant l'up j'ai ça : https://lafibre.info/1gb-free/probleme-de-debit-en-upload-limite-de-40-mbps-par-session/

Sur le down par exemple ce témoignage :

Moi j'ai un débit stable autour des 900 Mbps mais seulement en multithread. Depuis que ça va mieux à ce niveau, ça va plutôt moins bien en monothread, j'ai tendance à être limité autour de 160 Mbps.

Je n'ai jamais remarqué de pertes de paquets mais j'ai pas forcément trop regardé non plus. Tu vois ça comment ?

Je fais un truc de ce genre :

.\Fping.exe ping.online.net -t 80 -w 300 -c -s 1460 -f
Il faut le laisser tourner quelques minutes histoire d'avoir assez de paquets pour pouvoir tirer des statistiques (je m'arrête au bout de 20000 paquets). Je peux pas vraiment réduire l'intervalle parce que sinon il y a un équipement sur la route qui finit par me bloquer (détection de ICMP flood j'imagine).

Sur d'autres connexions qui n'ont rien à voir, j'ai 0% de pertes. Sur cette connexion fibre Free, j'ai dans les environs de 0.03% de pertes (ce qui colle parfaitement à la limitation de débit). De manière assez surprenante, quand je pinge la Freebox fibre d'un pote installé à 100 mètres d'ici (même NRO), j'ai 0% de perte. C'est ça qui me fait suspecter un défaut local spécifique à cette fibre en particulier. J'ai du mal à confirmer ça de manière claire cela dit. Mon pote a du mal à faire des tests fiables parce qu'il n'est pas sur place et n'a pas d'équipements filaires là-bas, seulement Wi-Fi.

Sinon, est-ce que tu pourrais tester avec iperf sur "scaleway.testdebit.info" ?

iperf-3.1.3-win64> .\iperf3.exe -c scaleway.testdebit.info -R -4
iperf3: error - control socket has closed unexpectedly

Aucun port ne semble fonctionner sur scaleway.testdebit.info.

Cela dit j'ai testé https://ipv4.scaleway.testdebit.info/10G/10G.iso et Firefox me télécharge ça à 680 Mbit/s, ce qui est satisfaisant. Intéressant. Du coup j'ai retesté http://test-debit.free.fr/1048576.rnd et j'obtiens 280 Mbit/s. Bon, je dois être dans un bon jour. Sauf que si j'essaie iperf3 sur 3 serveurs différents (y compris ping.online.net) j'obtiens toujours 50 Mbit/s…

Je me demande si ce serait pas une histoire de TCP congestion control algorithm qui serait différent quand je fais mes tests en HTTP(S) par opposition à iperf3, et l'algo utilisé pour mes tests HTTP est plus résilient aux pertes de paquets. J'ai essayé "sysctl -w net.ipv4.tcp_congestion_control = bbr" sur les serveurs iperf3 que je contrôle mais ça n'a rien changé. (Peut-être que ça ne fonctionne pas si un des côtés de la connexion est sous Windows 10… malheureusement je n'ai pas de Linux sous la main du côté de la ligne Free pour tester.)

Cela dit, ça ne change rien au fait que je ne devrais pas avoir ce genre de problème en premier lieu. Je ne peux pas aller demander à tous les serveurs que j'utilise d'utiliser un autre algo de TCP congestion control… faudrait que je creuse le sujet cela dit parce que le plus important dans mon cas d'utilisation c'est le débit depuis un serveur spécifique sur lequel j'ai le contrôle, et sur cette destination précise je devrais pouvoir changer l'algo.

Tout ça est bien mystérieux…

scaleway.testdebit.info est en BBR. Je testerai ce soir mais ça m'étonne que le serveur iperf soit inaccessible.

Ce qui est sûr en tout cas c'est que BBR est connu pour "s'étaler" quand il est en compétition avec des flux en cubic. Du coup ça cache peut-être juste une saturation.

Ah pardon, je testais iperf3 scaleway.testdebit.info sur les ports 52xx, j'avais pas réalisé que c'était 92xx… autant pour moi. Je ne suis plus chez mes parents donc ça va être plus difficile pour moi de faire des tests supplémentaires.

C'est fort possible que le BBR aide dans l'absolu et que ce ne soit pas réellement un problème de perte de paquets mais plutôt un très classique problème de congestion. Je ne suis certain de rien. C'est pas dit qu'on ait le fin mot de l'histoire sans accès aux équipements internes de Free…