Auteur Sujet: Tuto:Analyser les problèmes de débit avec Wireshark (exemple avec Freebox Delta)  (Lu 3584 fois)

moms21 et 1 Invité sur ce sujet

Higs

  • Client Free fibre
  • *
  • Messages: 26
  • Caudry 59
Bonsoir à tous,

Très beau dossier Vivien que tu as fais là.
En lisant, j'avoue que je ne maîtrise pas tout, mais j'y ai vu (peut-être une erreur de ma part) des similitudes avec ce qui arrive a plusieurs freenaute comme moi.

la perte de paquets, déconnexion de certains jeux en multi très très rapidement donc non jouable.
pour éviter de tout répéter je mets le lien : https://dev.freebox.fr/bugs/task/27503, peut-être un oeil mieux avisé que moi pourra y décelé des similitudes plus fines ou voir que le problème et complètement différent.

Une note à ajouter à ce lien,
Ayant fait récemment l’acquisition d'une bête de compétition (R9 3950x / CM MSI X570 Prestige creation donc avec 10Gbits), j'ai pu avoir l'occasion de faire un download à environ 120/150Mo/s à destination de mon SSD (qui était loin de saturer) et remarqué sur les stats de la freebox que d'un coup l'upload qui était quasi nul se faisait présent fortement (sur la courbe de la freebox d'un calme quasi plat à bien voir le rouge, ça saute aux yeux) et dès que le download redescendait vers 100Mo/s l'upload redevenait quasi nul. ainsi de suite durant le temps du transfert.

je suivrais donc avec attention tout ce qui se passe ici.

vivien

  • Administrateur
  • *
  • Messages: 34 273
    • Twitter LaFibre.info
Les pertes de paquets que j'ai observé se produisent quand trop de paquets sont envoyés à un débit dépassant largement le débit de 600 Mb/s en upload.

Je ne connais pas World of Tanks ou World of Warships, mais d'habitude les jeux utilisent peu de bande passante et donc ce ne peut pas être la cause d'une saturation du buffer si il n'y a pas d'autres usages en même temps.

Si tu as "une perte de plus ou moins 75% de mes paquets de mon PC fixe branché en cable RJ45 vers la box. J’ai fait le test avec la wifi avec le même PC et la plus de soucis" cela pourrait être un problématique de câble Ethernet ou de driver de carte réseau. Le test est fait avec une carte 10 Gb/s (ta carte mère semble ne pas avoir de ports Ethernet 1 Gb/s, uniquement deux ports 10 Gb/s)

Connecté en Ethernet, un simple ping en IPv4 (exemple: ping ipv4.lafibre.info) montre des pertes de paquets ?
C'est la même chose en IPv6 ?
Si tu arrives à avoir des pertes de paquets par un simple ping, on va pouvoir trouver par différents tests le coupable.

Tu pourrais faire un test avec un PC moins haut de gamme connecté en Ethernet ? (On a déjà eu des problèmes avec des cartes réseau pour joueurs)

Higs

  • Client Free fibre
  • *
  • Messages: 26
  • Caudry 59
Oui, j'ai vu que de ton côté c'était en upload, j'ai pas possibilité de faire de l'upload rapidement de gros fichier.

j'ai pas précisé, Conan76 sur dev.freebox c'est moi.

Pour les jeux, il s'agissait de jeux tel que For Honor, Overcooked 2 et d'autre triple A, le seul que j'ai qui passe et Diablo 3. peut-être que les 2 premiers jeux pré-cité nécessite pas mal de synchro car ce sont des jeux type cooperatif ou 1vs1.

chez moi, je suis en RJ45, pas de wifi sur le pc volontairement, ma box étant au sous sol et dalle de béton (rez de chaussé et étage) cf mon installation (en recherchant Higs sur le forum de lafibre.info)
Ma nouvelle carte mère a 1 port 10Gb (aquantia) et 1Gb (intel) et du wifi 6. seul mon 10Gb est branché
sur mon ancienne, je n'avais que du 1Gb sur laquelle j'avais un I7-4790K, c'est avec elle que j'avais fait les tests sur dev.freebox

et donc les même soucis en changeant de matériel et d'autres PC sur le réseau.

pour les ping, les captures que j'avais faite comme l'autre personne via le logiciel Plotter effectué des ping et même avec on voyait de la perte de paquets au plus l'analyse était fine au plus on avait des pourcentages élevés dans le ping

Sur les captures on voit bien qu'il s'agissait directement de la freebox et l'élément juste derrière elle. je précise que je suis en IP full stack et que le problème est présent (je suis passé dessus pour accéder à l'ensemble de mes ports pour mes équipements interne).



Florian

  • Client Free fibre
  • *
  • Messages: 1 611
  • FTTH 10G-Epon+4G BT - Argenteuil (95)
Passionnant. En espérant que ça débouche chez une explication de la part de Free...

Cryptage

  • Client Free fibre
  • *
  • Messages: 170
  • Dijon
Passionnant. En espérant que ça débouche chez une explication de la part de Free...

Ce sera le cas uniquement si quelqu'un connaît du monde chez Free.

Dès que Vivien aura donné le go je compléterai le ticket dev.freebox.fr mais je pense qu'ils traiteront rien...

vivien

  • Administrateur
  • *
  • Messages: 34 273
    • Twitter LaFibre.info
Tu as le go.

Une capture en uplaod depuis un PC connecté sur le port 1 Gb/s Ethernet de la Freebox à une heure où le trafic sur l'arbre 10GEpon est statistiquement faible serait intéressante, pour être sur que le pb vient de l'équipement qui limite le débit à 600 Mb/s.

Toutefois, il est possible de faire un ticket avec les infos déjà récupérées.

Cryptage

  • Client Free fibre
  • *
  • Messages: 170
  • Dijon
J'ai ajouté des éléments sur le ticket.

Je vois pour faire la capture si je trouve un moment  ;D

vivien

  • Administrateur
  • *
  • Messages: 34 273
    • Twitter LaFibre.info
Comparaison Cubic / BBR réalisé sur une ligne Free FTTH impactée elle aussi par les pertes de paquets.

Débit montant :


Tests réalisés par Breizh29, client Freebox Delta à Ergué-Gabéric, une commune du département du Finistère (29), dans la région Bretagne sur un serveur 10Gb/s hébergé par Bouygues Telecom à Nanterre (92). L’interconnexion entre Free et Bouygues Telecom se fait sur Paris TH2 en IPv4 comme en IPv6 dans les deux sens.

Client : VM sur ESXi 4vCPU sur un Core i7-10710U @1.1 GHz avec 4 Go de ram (sur 32 Go de l’hôte)
La connectivité 10G est assurée par un Sonnet Solo 10G Thunderbolt 3 édition
La VM est montée sous ESXi (6.7u2), la configuration réseau de VMWare est laissée d'origine.
La MTU est passée à 9000 dans la conf.
OS invité : Ubuntu 19.10 (Kernel Linux 5.3) et iPerf 3.6

Protocole de congestion BBR via /etc/sysctl.conf :
net.core.default_qdisc=fq
net.ipv4.tcp_congestion_control=bbr
net.core.optmem_max = 268435456
net.core.rmem_default = 212992
net.core.wmem_default = 212992
net.core.rmem_max = 134217728
net.core.wmem_max = 134217728
net.ipv4.tcp_rmem = 4096 87380 134217728
net.ipv4.tcp_wmem = 4096 65536 134217728
net.ipv4.tcp_fastopen = 1
net.ipv4.tcp_tso_win_divisor = 8


OS Serveur : Ubuntu server 18.04 LTS avec Kernel 5.3 avec taille de buffer max de 16 Mo.
iPerf 3.7
Optimisation réalisée :

# Reduce the swap
vm.swappiness = 1

# Reduce the threshold where a DDOS impacts the server
net.ipv4.tcp_max_syn_backlog = 4096

# TCP congestion control protocol for high-speed and long-distance networks
#net.ipv4.tcp_congestion_control=illinois
net.ipv4.tcp_congestion_control=bbr

# Disable the memorization of previous tests, in order to avoid that the server burns the tests following a limited performance
net.ipv4.tcp_no_metrics_save=1

# Increase TCP buffers
net.ipv4.tcp_rmem=4096 131072 16777216
net.ipv4.tcp_wmem=4096 87380 16777216
net.core.rmem_max=16777216
net.core.wmem_max=16777216

# Increase the queue within the Linux kernel where traffic is stored after reception from the NIC
net.core.netdev_max_backlog=4000

# Increase number of incoming connections
net.core.somaxconn = 512

Fuli10

  • Client Free fibre
  • *
  • Messages: 699
  • Conflans Sainte Honorine (78)
Hello,
Quelqu'un serait intéressé pour interpréter 2 captures pcap du problème de perf. en uplink cubic et bbr sur un lien 1Gb ?
Pris directement entre la fbx et l'ONT, avec comme client un openwrt 19.1 (x64 - kernel 4.14) directement en DMZ de la box (donc NAT).

vivien

  • Administrateur
  • *
  • Messages: 34 273
    • Twitter LaFibre.info
Je suis preneur !

vivien

  • Administrateur
  • *
  • Messages: 34 273
    • Twitter LaFibre.info
Fuli10, on commence par ta capture Cubic.

root@gateway:~# iperf3 -C cubic -c bouygues.testdebit.info -p 5206 -t 2 -i 1 -V --get-server-output
iperf 3.7
Linux gateway 4.14.167 #0 SMP Wed Jan 29 16:05:35 2020 x86_64
Control connection MSS 1428
Time: Mon, 17 Feb 2020 13:55:57 UTC
Connecting to host bouygues.testdebit.info, port 5206
      Cookie: pqqc6v4qa3l4up7eqye6yofg5eeyqhhs2cql
      TCP MSS: 1428 (default)
[  5] local 2a01:e0a:369:d4xx::1 port 58782 connected to 2001:860:deff:1000::2 port 5206
Starting Test: protocol: TCP, 1 streams, 131072 byte blocks, omitting 0 seconds, 2 second test, tos 0
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec  31.3 MBytes   262 Mbits/sec    0    262 KBytes
[  5]   1.00-2.00   sec  33.8 MBytes   283 Mbits/sec    2    241 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
Test Complete. Summary Results:
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-2.00   sec  65.0 MBytes   273 Mbits/sec    2             sender
[  5]   0.00-2.04   sec  63.9 MBytes   262 Mbits/sec                  receiver
CPU Utilization: local/sender 2.7% (1.1%u/1.6%s), remote/receiver 0.2% (0.0%u/0.2%s)
snd_tcp_congestion cubic
rcv_tcp_congestion cubic

Server output:
-----------------------------------------------------------
Server listening on 5206
-----------------------------------------------------------
Accepted connection from 2a01:e0a:369:d4xx::1, port 58780
[  6] local 2001:860:deff:1000::2 port 5206 connected to 2a01:e0a:369:d4xx::1 port 58782
[ ID] Interval           Transfer     Bitrate
[  6]   0.00-1.00   sec  28.9 MBytes   242 Mbits/sec
[  6]   1.00-2.00   sec  33.5 MBytes   281 Mbits/sec
[  6]   2.00-2.04   sec  1.46 MBytes   292 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate
[  6]   0.00-2.04   sec  63.9 MBytes   262 Mbits/sec                  receiver


iperf Done.


iPerf3 indique que seul 2 paquets ont été retransmis, c'est très peu. (Il n'est pas anormal d'avoir quelques paquets perdus avec TCP)

Voici ton graphique Statistiques => Graphique des flux TCP => Séquence de temps (tcptrace) :

(cliquer sur le graphique pour zoomer)


Il est très propre. On note une montée en débit rapide (liée à la faible latence entre toi et le serveur) puis on a une droite, ce qui signifie que le débit est stable a environ 300 Mb/s.

A t=1,4 seconde, on voit les deux paquets consécutifs qui sont perdus et la baisse de débit qui est immédiatement opérée.

vivien

  • Administrateur
  • *
  • Messages: 34 273
    • Twitter LaFibre.info
Voici un zoom au moment de la perte des deux paquets :

(cliquer sur le graphique pour zoomer)


 

Mobile View