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

0 Membres et 1 Invité sur ce sujet

vivien

  • Administrateur
  • *
  • Messages: 47 081
    • Twitter LaFibre.info
Maintenant, tout n'est pas parfait, je vois au début de la connexions des acquittements sélectifs (SACK).

Sur le graphique, ce sont des petits traits rouge au niveau de la courbe en bas (couleur gris) qui indiquent les octet acquittés par le serveur.

Ces traits rouge se voient à t=0,253 et t=0,255.


(cliquer sur le graphique pour zoomer)


Quand on clique sur ces traits rouges, Wireshark nous place sur les paquets correspondants pour pouvoir comprendre le problème.

Les 3 paquets ont étés analyses par Wireshark comme [TCP Dup ACK] et mis en rouge. On note la présence d’acquittement sélectif : concrètement, il y a eu de la gigue et le serveur à reçu les paquets dans le désordre et c'est vraiment anormal. Le paquet qui vient juste après la séquence 3882770 est arrivé après 3 paquets situés après. D'où le fait que le serveur signale ce paquet manquant.

L'émetteur ne va pas ré-émettre le paquet en question car très rapidement (en moins d'une milliseconde) le serveur acquitte le paquet manquant.

Ici je ne vois pas d'impact sur le débit, mais une gigue qui met rompt l'ordre des paquets peut être catastrophique sur le débit. Bref, c'est un vrai problème, même si je ne pense pas qu'il a réduit le débit.


(cliquer sur le graphique pour zoomer)


Pourquoi le débit est deux fois plus faible qu'espéré ?

Je voit deux causes possibles pour expliquer un tel débit :
- Le client a des paramètres TCP/IP qui ne sont pas optimisé pour un si haut débit (il faudrait tester avec un vrai Linux, en effet les Linux embarqués peuvent avoir des paramètres plus conservateurs pour économiser de la ram)
- La gigue aurait convaincu l'émetteur de ne pas être trop agressif.

Il est possible que le débit soit imité à cause d'une autre cause, là rien n'est évident.

vivien

  • Administrateur
  • *
  • Messages: 47 081
    • Twitter LaFibre.info
Fuli10, on continue par ta capture BBR.

Là le débit est au rendez-vous.


root@gateway:~# iperf3 -C bbr  -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:46:47 UTC
Connecting to host bouygues.testdebit.info, port 5206
      Cookie: uhlltw5d3vpaciyan3f3lhhi3qmdtqdk3ibj
      TCP MSS: 1428 (default)
[  5] local 2a01:e0a:369:d4xx::1 port 58774 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  69.1 MBytes   580 Mbits/sec  5477    940 KBytes       
[  5]   1.00-2.00   sec  67.5 MBytes   566 Mbits/sec  7091    892 KBytes       
- - - - - - - - - - - - - - - - - - - - - - - - -
Test Complete. Summary Results:
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-2.00   sec   137 MBytes   573 Mbits/sec  12568             sender
[  5]   0.00-2.04   sec   134 MBytes   551 Mbits/sec                  receiver
CPU Utilization: local/sender 3.2% (1.4%u/1.9%s), remote/receiver 0.0% (0.0%u/0.0%s)
snd_tcp_congestion bbr
rcv_tcp_congestion bbr

Server output:
-----------------------------------------------------------
Server listening on 5206
-----------------------------------------------------------
Accepted connection from 2a01:e0a:369:d4xx::1, port 58772
[  6] local 2001:860:deff:1000::2 port 5206 connected to 2a01:e0a:369:d4xx::1 port 58774
[ ID] Interval           Transfer     Bitrate
[  6]   0.00-1.00   sec  62.4 MBytes   524 Mbits/sec
[  6]   1.00-2.00   sec  68.2 MBytes   572 Mbits/sec
[  6]   2.00-2.04   sec  3.30 MBytes   703 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate
[  6]   0.00-2.04   sec   134 MBytes   551 Mbits/sec                  receiver


iperf Done.


iPerf3 indique que 12568 paquets ont été retransmis. C'est bien le cas.

BBR est agressif et génère pleins de paquets perdu c'est connu.

Voici la courbe Séquence de temps (tcptrace) :

(cliquer sur le graphique pour zoomer)


On note un débit très stable, la ligne bleu est une vrai droite, le débit est toujours au maximum.

On note aussi beaucoup, beaucoup de paquets retransmis. Un même paquet peut même etre élis 4 fois avant d'être reçu par le serveur !

vivien

  • Administrateur
  • *
  • Messages: 47 081
    • Twitter LaFibre.info
Voici le début de la connexion TCP :

(cliquer sur le graphique pour zoomer)


Jusqu'à 0,09 seconde, les paquets émis sont reçus et acquittés rapidement.

A partir de 0,09 seconde et jusqu'à la fin de la capture, c'est paquet perdu sur paquets perdus et la courbe grise des acquittements se décale vers la droite vu qu'il faut attendre d'avoir tous les paquets et qu'il faut renvoyer plusieurs fois certains.

A 0,12 secondes, l'émetteur arrête d'envoyer des paquets : la Rwin (paquets non acquittés) est remplie. C'est quand la courbe bleu des paquets envoyés touche la courbe verte. La courbe verte située en haut indique la limite du nombre de paquets non acquittés qu'il est permis d'envoyer. Cette courbe augmente à chaque fois que les acquittements sont reçus. Avec l'augmentation de la Rwin, c'est le seul moment où l'émetteur va arrêter d'envoyer des paquets. Augmenter la Rwin aurait peut-être permis d'éviter cette courte interruption et de gagner encore un petit peu de débit au début de la connexion.

Voici un zoom, regardez bien les petits point bleu qui sont ré-émis jusqu'à 4 fois !

(cliquer sur le graphique pour zoomer)

vivien

  • Administrateur
  • *
  • Messages: 47 081
    • Twitter LaFibre.info
Zoom vers la fin de la capture pour montrer que l'on est toujours dans la même configuration avec pleins de traits rouge qui sont des acquittements qui indiquent que des paquets sont perdus et les traits bleu qui sont des paquets ré-émis.

(cliquer sur le graphique pour zoomer)


Merci pour cette belle capture qui montre comment BBR s'y prend pour améliorer le débit par rapport à Cubic.

Fuli10

  • Abonné Free fibre
  • *
  • Messages: 1 004
  • Conflans Sainte Honorine (78)
Le problème de débit étant reproductible avec un pc (linux ou windows) derrière le routeur, j'ai testé justement avec la machine la plus proche de la box. Sinon je peux faire aussi facilement une capture avec un ubuntu derrière le routeur. Mais le pire étant que c'est pareil avec le routeur connecté directement sur l'ONT (débit faible en uplink aussi bien depuis ubuntu que depuis openwrt). Je pourrais aussi faire une capture dans ce mode mais pas avant un moment, et de toute façon je doute de sa pertinence vs derrière la freebox).
Je n'ai configuré que l'IPv6 mais j'atteind aussi des débits équivalents sur iperf depuis le routeur et depuis ubuntu.
Et là encore c'est 300Mbps, mais d'habitude en cubic c'est plus proche des 200-250Mbps comme ce soir.

vivien

  • Administrateur
  • *
  • Messages: 47 081
    • Twitter LaFibre.info
J'ai regardé la capture de Breizh29 que j'avais conservé et on voit aussi de la gigue et comme toi des paquets qui arrivent en retard de 3 paquets sans que l'émetteur ne ré-envoi le paquet indiqué comme non reçu car acquitté rapidement.

Comme pour toi, on ne voit pas une basse de débit après cette forte gigue.

Cryptage

  • Abonné Free fibre
  • *
  • Messages: 297
  • Dijon
Du coup on voit bien qu'il y a des choses à faire côté Free...  ;)

Espérons que les équipes réseaux vont trouver quelque chose.

hwti

  • Abonné Orange Fibre
  • *
  • Messages: 2 237
  • Chambly (60)
iPerf3 indique que 12568 paquets ont été retransmis. C'est bien le cas.
...
On note aussi beaucoup, beaucoup de paquets retransmis. Un même paquet peut même etre élis 4 fois avant d'être reçu par le serveur !
13% de pertes donc, c'est effectivement beaucoup.

J'ai regardé la capture de Breizh29 que j'avais conservé et on voit aussi de la gigue et comme toi des paquets qui arrivent en retard de 3 paquets sans que l'émetteur ne ré-envoi le paquet indiqué comme non reçu car acquitté rapidement.
Est-ce que ça pourrait être Free qui répartit aléatoirement les trames sur plusieurs liens 10Gbps ?
Autant sur le download ça pourrait avoir un intérêt, autant sur l'upload avec 600Mbps par abonné c'est bizarre.

vivien

  • Administrateur
  • *
  • Messages: 47 081
    • Twitter LaFibre.info
Les liens sont symétriques et les opérateurs utilisent des LAG de n port 10 Gb/s pour la collecte ou n ports 100 Gb/s pour le backone.

J'ai déjà vu des liens constitués de LAG de 128 ports 10 Gb/s.

La base dans les réseaux c'est de faire en sorte qu'une connexion TCP utilise toujours le même lien du LAG pour éviter que les paquets arrivent dans le désordre.

- Mode 4 : IEEE 802.3ad : Groupement de ports pour load balancing et Failover : Fonctionne les switchs Ethernet qui supportent cette norme. Le mécanisme de load blancing est similaire à celui du mode Balance-XOR.Il est basé sur le principe qui consiste à affecter toujours le même chemin à la même machine en fonction du couple IP source / IP destination / port. Cela implique que le switch gère le 802.ad et que les interfaces soient compatibles mii-tool et/ou ethtool.

La répartition du trafic se fait par un hash XOR (eXclusive OR ou OU exclusif) en fonction des arguments sélectionnables suivants :
  • les adresses MAC(source et ou destination)
  • les adresses IP (source et ou destination)
  • le port applicatif (destination)

Tous les ports d'un groupe doivent obligatoirement être paramétrés à la même vitesse, même duplex (full/half), même VLAN, même mode (access/trunk).

Fuli10

  • Abonné Free fibre
  • *
  • Messages: 1 004
  • Conflans Sainte Honorine (78)
Perso je verrais plutôt un problème avec les buffers internes de l'ONT qui divise dynamiquement mais mal son pool de mémoire entre UL et DL (sûrement un buffer unique partagé). Ce qui me fait dire ça c'est les résultats catastrophiques oscillant DL/UL quand on fait 2 sessions iperf en DL et UL. Possible que l'algorithme d'allocation fait que certains paquets apres un watermark sorte avec plus ou moins de délais.

vivien

  • Administrateur
  • *
  • Messages: 47 081
    • Twitter LaFibre.info
Je ne comprends pas comment un buffer pourrait faire que les paquets se retrouvent dans le désordre.

A moins que ce soit un bug de la fonction de priorisation des paquets [SYN] [SYN-ACK] présent de mémoire sur la Freebox, qui permet de prioriser ce types de péquets pour éviter qu'ils aient a attendre leur tour (et c'est plutôt une bonne idée de prioriser les paquets [SYN] [SYN-ACK], ce sont des paquets de petite taille, il vont peu ralentir les autres connexions et le temps gagné va permettre de monter plus rapidement la connexion)

Cryptage

  • Abonné Free fibre
  • *
  • Messages: 297
  • Dijon
@Vivien : ça t'intéresse des captures tcpdump au cul d'une Freebox Revolution, IPv4 + IPv6 et Cubic + BBR ?

Ca a été testé en governor à "performance" pour être sûr que le CPU ne vienne pas perturber.
Normalement il ne devrait pas y avoir de pollution externe car c'était la seule machine sur la Freebox.

Il y a + de 3 Go de data pour 4 captures de 20 secondes...  :o
« Modifié: 18 février 2020 à 20:36:05 par Cryptage »