Auteur Sujet: [Résolu] Freebox v6 + ONU v2 => 30 Mo/s max par session TCP (Lu 50377 fois)

Fabrice49 · « **Réponse #108 le:** 30 janvier 2022 à 12:23:04 »

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 ?

FloBaoti · « **Réponse #109 le:** 30 janvier 2022 à 16:29:32 »

Citation de: Fabrice49 le 30 janvier 2022 à 12:23:04

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.

kgersen · « **Réponse #110 le:** 30 janvier 2022 à 19:26:36 »

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:

Code: [Sélectionner]

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:

Code: [Sélectionner]

[ 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:

Code: [Sélectionner]

[ 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...).

kkwete · « **Réponse #111 le:** 03 février 2022 à 15:09:56 »

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:

Code: [Sélectionner]

[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?

Fabrice49 · « **Réponse #112 le:** 03 février 2022 à 15:21:14 »

Déjà tu peux t'inscrire sur dev.freebox.fr, voter pour la tâche et remonter ton propre test iperf3 (attention à ne pas oublier le -R lors de l'essai)

kkwete · « **Réponse #113 le:** 03 février 2022 à 15:42:22 »

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?

Fabrice49 · « **Réponse #114 le:** 03 février 2022 à 15:49:47 »

Citation de: kkwete le 03 février 2022 à 15:42:22

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"

Citer

Quels tests sous iperf faut-il faire exactement?Tous comme ce qu'a fait mog54?

Oui

kkwete · « **Réponse #115 le:** 03 février 2022 à 15:55:48 »

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.

pitalugue · « **Réponse #116 le:** 03 février 2022 à 17:36:01 »

Citation de: kkwete le 03 février 2022 à 15:09:56

Et j'obtiens ça:
Code: [Sélectionner]
[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

kkwete · « **Réponse #117 le:** 03 février 2022 à 18:10:19 »

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!

fansat70 · « **Réponse #118 le:** 03 février 2022 à 20:11:18 »

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...

kgersen · « **Réponse #119 le:** 04 février 2022 à 07:38:41 »

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.