La Fibre
Télécom => Réseau => 
TCP/IP / Fonctionnement des réseaux => Discussion démarrée par: vivien le 11 février 2020 à 12:39:36
-
Tuto: Analyser les problèmes de débit avec Wireshark
Exemple avec les problématiques de faible débit montant rencontrés par certains clients sur la Freebox Delta
(https://lafibre.info/images/wireshark/logo_wireshark.png) (https://lafibre.info/tcpip/realiser-une-capture-wireshark-pas-a-pas/)
Le résumé en un graphique :
(https://lafibre.info/images/wireshark/202002_free_delta_analyse_debit_breizh29_perte1.png)
L'explication complète :
Voici les débits montant de Breizh29 : en moyenne 100 Mb/s, ce qui est très éloigné des débits théorique de sa box.
iperf3 -c bouygues.testdebit.info -t 20 -i 1
Connecting to host bouygues.testdebit.info, port 5201
[ 7] local 2a01:e0a:1fc:xxxxxxx port 52671 connected to 2001:860:deff:1000::2 port 5201
[ ID] Interval Transfer Bitrate
[ 7] 0.00-1.00 sec 19.5 MBytes 163 Mbits/sec
[ 7] 1.00-2.00 sec 15.6 MBytes 131 Mbits/sec
[ 7] 2.00-3.00 sec 15.9 MBytes 134 Mbits/sec
[ 7] 3.00-4.00 sec 11.3 MBytes 95.3 Mbits/sec
[ 7] 4.00-5.00 sec 18.4 MBytes 154 Mbits/sec
[ 7] 5.00-6.00 sec 16.3 MBytes 137 Mbits/sec
[ 7] 6.00-7.00 sec 17.2 MBytes 144 Mbits/sec
[ 7] 7.00-8.00 sec 11.9 MBytes 100 Mbits/sec
[ 7] 8.00-9.00 sec 11.6 MBytes 97.4 Mbits/sec
[ 7] 9.00-10.00 sec 19.9 MBytes 167 Mbits/sec
[ 7] 10.00-11.00 sec 12.4 MBytes 104 Mbits/sec
[ 7] 11.00-12.00 sec 2.66 MBytes 22.3 Mbits/sec
[ 7] 12.00-13.00 sec 8.41 MBytes 70.7 Mbits/sec
[ 7] 13.00-14.00 sec 13.1 MBytes 110 Mbits/sec
[ 7] 14.00-15.00 sec 2.62 MBytes 22.0 Mbits/sec
[ 7] 15.00-16.00 sec 9.66 MBytes 81.1 Mbits/sec
[ 7] 16.00-17.00 sec 10.2 MBytes 85.8 Mbits/sec
[ 7] 17.00-18.00 sec 11.3 MBytes 94.6 Mbits/sec
[ 7] 18.00-19.00 sec 3.51 MBytes 29.4 Mbits/sec
[ 7] 19.00-20.00 sec 11.0 MBytes 92.1 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate
[ 7] 0.00-20.00 sec 242 MBytes 102 Mbits/sec sender
[ 7] 0.00-20.01 sec 238 MBytes 99.9 Mbits/sec receiver
iperf Done.
Dans de nombreux cas quand le débit est limité, c'est une problématique qui est du coté client et non du coté FAI : Utilisation du WiFi, d'un PC pas assez puissant ou présence de logiciels résidents (principalement sous Windows 10) qui limitent le débit.
La capture ci-dessous a été réalisée 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.
Breizh29 utilise iPerf3 version 3.7 pour faire ses tests de débit. Coté serveur, c'est un Ubuntu server 18.04 LTS avec Kernel 5.3 avec taille de buffer max de 16 Mo avec lui aussi iPerf3 version 3.7
Client : Mac mini (i7 3,2 GHz, 32 Go mémoire, 1 To SSD, macOS 10.15.2 - équipé d’un chip Aquantia AQC107) avc une optimisation réalisée sur le fichier /etc/sysctl.conf :
kern.ipc.maxsockbuf=33554432
kern.ipc.somaxconn=2048
net.inet.tcp.sendspace=4194304
net.inet.tcp.recvspace=4194304
net.inet.tcp.win_scale_factor=8
net.inet.tcp.autorcvbufmax=33554432
net.inet.tcp.autosndbufmax=33554432
net.inet.tcp.slowstart_flightsize=20
net.inet.tcp.local_slowstart_flightsize=9
net.inet.tcp.mssdflt=1432
net.inet.tcp.v6mssdflt=1452
Dans tous les tests ci-dessous le protocole de congestion TCP est Cubic aussi bien sur le mac que sur le serveur Linux. On fera une parenthèse sur le protocole de congestion TCP BBR à la fin de ce sujet.
Quand on parle de problème de débit, il est important de savoir si c'est lié à une congestion du réseau, congestion qui est présente le soir sur certains réseaux.
Pour répondre à cette question, Breizh29 à automatisé un test avec iPerf3, ce qui permet d'avoir un graphique des débits sur les 7 derniers jours :
Commande utilisée pour les tests montant multi-thread :
iperf3 -c bouygues.testdebit.info -t 4 -O 4 -p $numPort -4 -P 16 -f g
iperf3 -c bouygues.testdebit.info -t 4 -O 4 -p $numPort -6 -P 16 -f g
Commande utilisée pour les tests montant mono-thread :
iperf3 -c bouygues.testdebit.info -t 4 -O 4 -p $numPort -4 -P 1 -f g
iperf3 -c bouygues.testdebit.info -t 4 -O 4 -p $numPort -6 -P 1 -f g
(cliquer sur le graphique pour zoomer)
(https://lafibre.info/images/wireshark/202002_free_delta_analyse_debit_breizh29_ul.png) (https://lafibre.info/images/wireshark/202002_free_delta_analyse_debit_breizh29_ul.png)
On note que le débit mono-thread est régulièrement à moins de 100 Mb/s, même en pleine nuit. La limitation de débit n'est donc pas liée à une congestion.
Le débit multi-thread est lui stable mais reste éloigné du débit théorique de la ligne.
Le débit montant sur la Freebox Delta doit être proche de 566 Mb/s en mono-thread comme en multi-thread.
Exemple de résultat obtenu par darkmoon en mono-connexion, un client sur Saint Genis Laval (69), avec une latence trés proche de celle de Breizh29.
iperf3 -c bouygues.testdebit.info -t 20 -i 1
Connecting to host bouygues.testdebit.info, port 5201
[ 5] local 2a01:e0a:1d2:d8f0::xyzb port 36766 connected to 2001:860:deff:1000::2 port 5201
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 66.6 MBytes 558 Mbits/sec 5589 1.96 MBytes
[ 5] 1.00-2.00 sec 67.5 MBytes 566 Mbits/sec 9663 2.03 MBytes
[ 5] 2.00-3.00 sec 63.8 MBytes 535 Mbits/sec 8495 1.57 MBytes
[ 5] 3.00-4.00 sec 67.5 MBytes 566 Mbits/sec 4149 1.61 MBytes
[ 5] 4.00-5.00 sec 66.2 MBytes 555 Mbits/sec 8657 1.66 MBytes
[ 5] 5.00-6.00 sec 71.2 MBytes 598 Mbits/sec 3841 1.52 MBytes
[ 5] 6.00-7.00 sec 67.5 MBytes 566 Mbits/sec 5671 1.45 MBytes
[ 5] 7.00-8.00 sec 67.5 MBytes 566 Mbits/sec 2902 1001 KBytes
[ 5] 8.00-9.00 sec 67.5 MBytes 566 Mbits/sec 8688 1.54 MBytes
[ 5] 9.00-10.00 sec 67.5 MBytes 566 Mbits/sec 4491 1.14 MBytes
[ 5] 10.00-11.00 sec 66.2 MBytes 556 Mbits/sec 2471 2.20 MBytes
[ 5] 11.00-12.00 sec 70.0 MBytes 587 Mbits/sec 4959 964 KBytes
[ 5] 12.00-13.00 sec 66.2 MBytes 556 Mbits/sec 3696 2.26 MBytes
[ 5] 13.00-14.00 sec 70.0 MBytes 587 Mbits/sec 3885 1.88 MBytes
[ 5] 14.00-15.01 sec 67.5 MBytes 561 Mbits/sec 9621 1.59 MBytes
[ 5] 15.01-16.00 sec 67.5 MBytes 572 Mbits/sec 10308 1.81 MBytes
[ 5] 16.00-17.00 sec 67.5 MBytes 566 Mbits/sec 6166 1.41 MBytes
[ 5] 17.00-18.00 sec 67.5 MBytes 566 Mbits/sec 2273 1.61 MBytes
[ 5] 18.00-19.00 sec 67.5 MBytes 566 Mbits/sec 7242 1.05 MBytes
[ 5] 19.00-20.00 sec 67.5 MBytes 566 Mbits/sec 3519 1.56 MBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-20.00 sec 1.32 GBytes 566 Mbits/sec 116286 sender
[ 5] 0.00-20.01 sec 1.32 GBytes 566 Mbits/sec receiver
iperf Done.
-
Faut-il mesurer le débit en multi-thread ou en mono-thread ?
Le débit multi-thread permet d'augmenter les débits en faisant abstraction des problèmes sur un réseau, comme par exemple des pertes de paquets.
Si le multi-thread permet d'afficher de meilleurs débits, il est par contre moins représentatif d'un usage réel qui, est du mono-thread pour la quasi-totalité des usages sur Internet.
Une mesure de débit multi-thread, si elle permet de voir la taille du tuyau, est aussi une façon d'afficher un débit plus élevé, mais non représentatif de l’expérience des clients.
Il est donc pertinent de se pencher sur la problématique rencontrée en mono-thread, qui impacte directement le ressenti des utilisateurs.
La limitation pourrait-elle être liée au Mac de Mac mini de Breizh29 ? (i7 3,2 GHz, 32 Go mémoire, 1 To SSD, macOS 10.15.2)
iPerf3 à l'avantage de demander très peu de puissance processeur, contrairement à un test de débit réalisé dans un navigateur qui va demande un monstre de puissance pour faire du 10 Gb/s.
La réponse est non, car voici ses tests de débit en descendant : On observe là une saturation le soir avec une forte chute de débit en mono-thread et une chute plus faible en multi-thread.
(cliquer sur le graphique pour zoomer)
(https://lafibre.info/images/wireshark/202002_free_delta_analyse_debit_breizh29_dl.png) (https://lafibre.info/images/wireshark/202002_free_delta_analyse_debit_breizh29_dl.png)
Le serveur pourrait-il être l'élément limitant ?
Les tests descendant et montant sont réalisé sur le même serveur.
Il y a peu de chance que les limitations soient liée au serveur : celui ci à un trafic "in" ("in" correspond au trafic débit montant d'un client avec le serveur) qui est très faible.
Le serveur est par contre bien plus chargé sur "out" qui correspond aux tests de téléchargements qui sont eux bon.
Trafic sur l'interface réseau du serveur utilisé :
(https://lafibre.info/images/wireshark/202002_free_delta_analyse_debit_breizh29_serveur.png)
-
Maintenant que ces éléments de contextes sont posés, on peut passer à la capture Wireshark.
Il y a un tutoriel qui explique comment faire :
Réaliser une capture Wireshark pas à pas
(https://lafibre.info/images/wireshark/logo_wireshark.png) (https://lafibre.info/tcpip/realiser-une-capture-wireshark-pas-a-pas/)
Il faut bien vérifier la barre d'état de Wireshark (la ligne tout en bas) : après avoir arrêté la capture, il doit y avoir marqué Perdus: 0 (0,0%). Si vous avez autre chose que 0, cela signifie que votre machine a eu un peu de mal a écrire le flux et que des paquets ont été perdus. La capture n'est pas parfaite. Il est préférable de la refaire en veillant à fermer les applications non nécessaire, car les paquets perdus peuvent compliquer fortement l'analyse, Wireshark montrant des paquets perdus qui sont en fait des paquets non capturés.
Comment faire un graphique de la connexion TCP avec Wireshark ?
Il faut sélectionner un paquet de donnée du transfert de donnée. (Si vous sélectionnez un acquittement TCP, la courbe se fera dans le sens où aucune donnée n'est transmise, il sera donc vide)
Pour être sur d'être sur la bonne connexion TCP (il peut y avoir d'autres connexions avant et après) l'astuce est de se placer au milieu de la capture et de sélectionner un paquet d'une grande taille (la taille apparaît dans la colonne Length) puis aller dans le menu Statistiques => Graphique des flux TCP => Séquence de temps (tcptrace)
Un graphique comme celui-ci apparaît : (cliquer sur le graphique pour zoomer)
(https://lafibre.info/images/wireshark/202002_free_delta_analyse_debit_breizh29_wireshark.png) (https://lafibre.info/images/wireshark/202002_free_delta_analyse_debit_breizh29_wireshark.png)
En abscisse on a le temps depuis le début de la connexion TCP, exprimé en seconde. Ici le test dure 20 secondes.
En ordonnée on a les paquets transmis, exprimés en nombre d'octets transmis depuis le début de la connexion TCP. Chaque intervalle affiché correspond à 100 Mo transféré.
Plus la pente de la courbe est raide, plus le débit est élevé.
Plus la courbe est plate, plus le débit est faible.
On voit donc que le débit monte et à chaque incident, que j'ai entouré en rouge, le débit repars d'un débit faible avant d'augmenter lentement.
On va zoomer sur les incidents.
-
Détail du premier incident, qui arrive moins de 200ms après le début de la connexion : (cliquer sur le graphique pour zoomer)
(https://lafibre.info/images/wireshark/202002_free_delta_analyse_debit_breizh29_perte1_graphe.png) (https://lafibre.info/images/wireshark/202002_free_delta_analyse_debit_breizh29_perte1_graphe.png)
On est encore dans le début de la connexion, là où le débit progresse forcement. Cette perte de paquets que nous allons observer à un impact sur le débit accentué par les suivantes.
3 éléments sont dessinés :
- une courbe en bas en gris qui indique les octet acquittés par le serveur. La capture ayant été prise sur le client qui émet les paquets, les acquittements ne sont pas reçus immédiatement, il faut attendre 12 à 13 millisecondes, qui est la temps qui sépare entre l'envoi d'un paquet et la réception de la réponse. C'est le "ping" du client vers le serveur.
- des petits traits bleus, qui correspondent aux paquets émis.
- une courbe verte en haut qui 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.
La différence verticale entre la courbe grise et celle verte est la quantité de donnée non acquitté qu'il est possible d'envoyer. Cette quantité de donnée est régulièrement augmentée, quand tout se passe bien sur une connexion. Dans notre cas, on voit que l'émission des paquets n'est pas limité par la limite de la Rwin : TCP arrête d'émettre des paquets avant que cette limite soit atteinte, car l'algorithme d’évitement de congestion utilisé, Cubic, le demande.
La différence horizontale entre les paquets bleu et la courbe grise correspond à la latence effective, dans notre cas environ 13ms.
L'incident de perte de paquets :
J'ai surligné en rose l'endroit où il y a eu des des pertes de paquets : On note qu'une même séquence de donnée est envoyé une première fois peu après l'intervalle de temps 0,135sec et que ces mêmes paquets sont émis une seconde fois, à un débit plus faible, peu après l'intervalle de temps 0,165sec
Les traits rouge sont générés par Wireshark et correspondent à des acquittements qui signalement des donnes manquantes. On note que ces acquittements interviennent un temps égal à deux fois la latence après l'émission les paquets.
- Peu de temps après l'intervalle de temps 0,14sec :
Le Mac de Breizh29 envoi un gros paquet de données à un débit très élevé (près de 10 Gb/s). En effet, il un PC envoie au débit maximum de son interface soit ici à 10 Gb/s. Les paquets seront stockés dans les buffers au niveau de l'endroit où le débit est réduit à 600 Mb/s. Ces buffers doivent être présents à chaque endroit où le débit est limité, afin de ne pas être obligé de supprimer les paquets. Il ne faut pas tomber dans l’excès inverse avec des buffers trop grands (risque de buffer bloat).
Ici selon toute vraisemblance, la quantité de donnée envoyée a été trop importante pour la taille des buffers de l'OLT ou de la Freebox.
Les buffers qui posent problème sont toujours ceux à l'endroit où le débit est limité à 600 Mb/s. Cette limitation est probablement réalisée sur l'OLT, située dans le NRO, toutefois, il est possible que les buffers de la Freebox soient eux aussi sollicités en débit montant : Le 10G-EPON (IEEE 802.3av) mis en place par Free limite le débit de l'arbre à 1244 Mb/s (débit partagé par tous les clients). Il est donc possible que le buffers trop petit soient au niveau de la Freebox, juste avant que le débit parte sur l'arbre avec une limitation physique à 1244 Mb/s, soit au niveau de l'OLT qui doit limiter le débit montant aux 600 Mb/s contractuel.
Les paquets qui arrivent alors que le buffer est plein sont supprimés. L'ensemble des derniers paquets ont donc été supprimés et c'est ce que l'on observe sur la capture Wireshark.
- Peu de temps après l'intervalle de temps 0,15sec :
La courbe grise en bas augmente car le Mac à reçu les acquittements des paquets enfin de presque tous les paquets, vu que le serveur n'a pas reçu les paquets que j'ai surlignés en rose, probablement détruits par l'OLT ou la Freebox, au niveau de l’endroit où le débit est limité à 600 Mb/s.
Immédiatement le mac se met à envoyer la suite des données.
Ni le serveur ni le client ne s’inquiète que toutes les données ne soient pas acquittés : un petit retard est possible.
(https://lafibre.info/images/wireshark/202002_free_delta_analyse_debit_breizh29_perte1.png)
- Peu de temps après l'intervalle de temps 0,152sec :
Là on reçois les acquittements envoyés par le serveur suites aux paquets envoyés peu après 0,15sec et ces acquittements, mis en rouge par Wireshark indiquent qu'il manque une plage de donnée.
Le mac va immédiatement renvoyer les paquets qu'il manque, mais à un débit plus faible.
- Peu de temps aprés l'intervalle de temps 0,164sec :
On reçois les acquittement pour les paquets surlignés en rose : la deuxième émission à bien fonctionné.
Par contre le débit va être réduit pour les prochains paquets (il va limiter le nombre de paquets envoyés d'un seul bloc pour éviter de faire exploser les buffers de l'OLT / Freebox, au niveau de l'endroit où le débit est réduit à 600 Mb/s ou 1244 Mb/s)
Ping du client vers une autres des IPv6 utilisé par le serveur :
Start: 2020-01-05T18:53:48+0100
HOST: Mac-mini-BZH.local Loss% Snt Last Avg Best Wrst StDev
1. AS12322 monIP 0.0% 100 0.3 0.4 0.2 1.0 0.1
2. AS12322 2a01:e03:12:f836:7e2c::ffff 0.0% 100 2.7 2.4 1.6 12.2 1.2
3. AS12322 2a01:e03:12:1700::ffff 77.0% 100 1.8 2.9 1.7 17.1 3.1
4. AS12322 2a01:e03:11::1 0.0% 100 3.1 4.4 3.0 21.0 2.5
5. AS12322 2a01:e03:f::1 0.0% 100 4.4 4.7 3.9 12.4 1.2
6. AS12322 2a01:e03:e::5 0.0% 100 5.5 6.1 5.2 12.6 1.3
7. AS12322 2a01:e03:e::2 18.0% 100 9.6 8.5 6.2 10.4 1.2
8. AS12322 2a01:e03:1::22 40.0% 100 12.4 12.3 11.7 13.0 0.3
9. AS12322 2a01:e00:3f::5 9.0% 100 12.6 12.4 11.8 18.0 0.7
10. AS5410 2001:860:0:81::1 0.0% 100 11.9 12.1 11.6 12.8 0.3
11. AS5410 2001:860:bbee:b4::2 0.0% 100 12.2 12.8 12.2 13.4 0.3
12. AS5410 2001:860:bbe0:128::2 0.0% 100 13.3 13.2 12.7 13.7 0.3
13. AS5410 2001:860:de01:1100::2 0.0% 100 12.4 12.5 12.0 13.2 0.3
-
Détail du premier incident, qui arrive moins de 200ms après le début de la connexion : (cliquer sur le graphique pour zoomer)
(https://lafibre.info/images/wireshark/202002_free_delta_analyse_debit_breizh29_perte1_paquets.png) (https://lafibre.info/images/wireshark/202002_free_delta_analyse_debit_breizh29_perte1_paquets.png)
Il est intéressant de voir les paquets pour comprendre le fonctionnement et pouvoir analyser des cas complexes.
Sous la colonne Length on voit la taille des paquets :
- Tous les paquets de plus de 1514 octets sont des paquets de donnée, dans notre cas émis par le mac. L'élément le plus important est le numéro de séquence (Seq=xxxxx), le numéro qui identifie le paquet envoyé. Je l'ai surligné à la main en vert.
- Tous les paquets de moins de 114 octets sont des paquets d’acquittement TCP, dans notre cas, émis par le serveur. L'élément le plus important est le numéro d’acquittement (Ack=xxxxxx) qui acquitte les données reçues. Je l'ai surligné à la main en rose.
Une connexion TCP permettant de transférer des données dans les deux sens, chaque paquet de donnée est aussi un paquet d’acquittement pour un éventuel flux descendant. Ici chaque paquet de donnée acquitte Ack=1 car il n'y a aucune aucune donnée dans l'autre sens. Chaque acquittement a le numéro Seq=1 car il ne transporte aucune donnée.
Analyse : La connexion se déroule parfaitement bien jusqu'au paquet surligné en bleu.
Le paquet d’acquittement en bleu et les suivants sont spécifiques : ils ont à la fin un SLE=xxxxxx SRE=xxxxxxx, cela correspond à SACK, un acquittement sélectif (SACK = selective acknowledgement), qui autorise le destinataire TCP à acquitter des blocs de données reçus dans le désordre. SACK a été définie en 1996 dans la RFC 2018 (https://tools.ietf.org/html/rfc2018), permet au récepteur d'accuser réception d'un maximum de 3 blocs discontinus de paquets reçus correctement, en plus du numéro de séquence suivant immédiatement le dernier numéro de séquence du dernier octet contigu reçu successivement.
A droite du champ info, Wireshark indique le bord gauche du bloc (le premier numéro de séquence du bloc) et le bord droit du bloc (le numéro de séquence suivant immédiatement le dernier numéro de séquence du bloc ), un bloc étant une plage contiguë que le récepteur a correctement reçue.
Concrètement le paquet bleu acquitte jusqu'au numéro de séquence 504598, puis du numéro de séquence 506010 au numéro de séquence 547438.
Cela indique à l'émetteur que les paquets du numéro de séquence 504598 au numéro de séquence 506009 n'ont pas été reçus.
L’émetteur va analyser, pour soit laisser du temps si il pense qu'ils sont peut être dans le désordre (il peut arriver dans des cas spécifique que les paquets soient dans le désordre, ce qui va fortement limiter le débit) soit les ré-émettre.
Ici dans notre cas, le temps entre l'émission des paquets et la réception de acquittement indiquant qu'il manque des paquets est important, TCP va donc faire immédiatement une ré-émission des paquets en question. Les paquets ré-émis sont mis en rouge par Wireshark, pour indiquer qu'ils sont dans le désordre.
Seuls les paquets perdus sont ré-émis. A noter que avant l'invention de SACK, tous les paquets depuis le paquet perdu devaient être ré-émis, y compris les paquets reçus, faute de solution pour indique à l'émetteur quel paquets sont perdus et quels paquets ont été reçus.
-
Détail du second incident, qui arrive 1,3 seconde après le début de la connexion : (cliquer sur le graphique pour zoomer)
(https://lafibre.info/images/wireshark/202002_free_delta_analyse_debit_breizh29_perte2.png) (https://lafibre.info/images/wireshark/202002_free_delta_analyse_debit_breizh29_perte2.png)
TCP ayant réduit son débit après la perte de paquet, il tente lentement d'augmenter à nouveau le débit au fur et à mesure que la connexion avance.
A 1,3 seconde, on va de nouveau exploser les buffers de l'OLT / Freebox, mais l'augmentation de débit ayant été plus progressive qu'au début de la connexion, seuls quelques paquets sont supprimés.
Pour une raison que j'ignore, TCP va fortement réduire le débit, bien plus que nécessaire, on voit qu’après cette perte de paquet, le débit est presque nul et va ré-augmenter progressivement.
Les buffers qui posent problème sont toujours ceux à l'endroit où le débit est limité à 600 Mb/s. Cette limitation est probablement réalisée sur l'OLT, située dans le NRO, toutefois, il est possible que les buffers de la Freebox soient eux aussi sollicités en débit montant: Le 10G-EPON (IEEE 802.3av) mis en place par Free limite le débit de l'arbre à 1244 Mb/s (débit partagé par tous les clients). Il est donc possible que le buffers trop petit soient au niveau de la Freebox, juste avant que le débit parte sur l'arbre avec une limitation physique à 1244 Mb/s, soit au niveau de l'OLT qui doit limiter le débit montant aux 600 Mb/s contractuel. Dans tous les cas; il y a un endroit ou les buffers sont trop petits.
-
Détail du troisième incident, qui arrive 1,84 seconde après le début de la connexion : (cliquer sur le graphique pour zoomer)
(https://lafibre.info/images/wireshark/202002_free_delta_analyse_debit_breizh29_perte3.png) (https://lafibre.info/images/wireshark/202002_free_delta_analyse_debit_breizh29_perte3.png)
Le débit ayant peu à peu augmenté (TCP est persévérant), on va de nouveau avoir un dépassement de la taille des buffers de l'OLT ou de la Freebox à T=1,84 seconde.
-
Détail du quatrième incident, qui arrive 2,4 seconde après le début de la connexion : (cliquer sur le graphique pour zoomer)
(https://lafibre.info/images/wireshark/202002_free_delta_analyse_debit_breizh29_perte4_graphe.png) (https://lafibre.info/images/wireshark/202002_free_delta_analyse_debit_breizh29_perte4_graphe.png)
TCP tente de s'adapter pour ne pas faire éclater les buffers de l'OLT ou de la Freebox, mais en augmentant peu à peu le débit, il va perdre des paquets pendant que le buffer se vide et donc perdre plusieurs paquets non consécutifs.
Détail des paquets du quatrième incient : (cliquer sur le graphique pour zoomer)
(https://lafibre.info/images/wireshark/202002_free_delta_analyse_debit_breizh29_perte4_paquets.png) (https://lafibre.info/images/wireshark/202002_free_delta_analyse_debit_breizh29_perte4_paquets.png)
Ici on voit que l'on a atteint le maximum de la taille des option TCP : 40 octets.
SACK prend de la place et on est limité à 3 blocs qui sont tous utilisés ici.
Si l'émetteur à reçu des paquets après ceux indiqués, il ne peut le mentionner dans SACK et ils seront retransmis.
J'ai surligné en vert les numéro de séquence des paquet de donnée.
L'analyse de la situation réalisée par Wireshark est à prendre avec des pincette. En effet ce qui est inscrit entre crochet [TCP Dup ACK] [TCP Fast Retransmission] [TCP OUt-Of-Order] [TCP Retransmission] sont liés a des algorithmes qui tentent d'aider celui qui regarde la capture, mais ces commentaires ne sont pas toujours appropriés.
Certains paquets sont notés par Wireshark comme étant [TCP OUt-Of-Order] [TCP Retransmission] [TCP Fast Retransmission] alors que ce sont des paquets renvoyés suite à la même perte de paquet.
[TCP Dup ACK] est censé montrer un acquittement déjà reçu (intéressant pour voir si le réseau duplique les paquets, et oui cela s'est déjà vu) mais une analyse du SACK montre bien que ce n'est pas un acquittement identique à un déjà reçu.
Bref, il y a simplement des acquittements qui montrent que plusieurs paquets sont perdus et l'émetteur qui renvoi les paquets.
-
Détail du cinquième incident, qui arrive 8,8 seconde après le début de la connexion : (cliquer sur le graphique pour zoomer)
(https://lafibre.info/images/wireshark/202002_free_delta_analyse_debit_breizh29_perte5.png) (https://lafibre.info/images/wireshark/202002_free_delta_analyse_debit_breizh29_perte5.png)
TCP à fait attention après un début de connexion chaotique a envoyer les paquets de façon modérée pour ne pas faire éclater les buffers de l'OLT / Freebox.
Toutefois TCP ne sait pas qu'il est le seul à utiliser la box, et donc il va de temps en temps faire monter le débit pour voir si la limitation du départ est toujours présente. Si il y avait d'autres suage en parallèle, la situation évoluer, il faut donc de temps en temps tester les limites de la connexion et c'est ce qui est fait là.
On va de nouveau avoir un dépassement de la taille des buffers de l'OLT / Freebox à T=8,8 seconde.
-
Détail du sixième incident, qui arrive 15,8 seconde après le début de la connexion : (cliquer sur le graphique pour zoomer)
(https://lafibre.info/images/wireshark/202002_free_delta_analyse_debit_breizh29_perte6.png) (https://lafibre.info/images/wireshark/202002_free_delta_analyse_debit_breizh29_perte6.png)
7 seconde après le précédent problème, on est dans la même situation : TCP test les limites de la connexion et on a de nouveau un dépassement de la taille des buffers de l'OLT / Freebox à T=15,8 seconde.
-
Conclusion de cette capture :
Cela montre de façon quasiment certaine que l'endroit des buffers sont trop petits pour permettre d'avoir de bon débits sur une connexion TCP. Il faudrait, si c'est possible logiciellement, augmenter cette taille des buffers.
Les buffers qui posent problème sont toujours ceux à l'endroit où le débit est limité à 600 Mb/s. Cette limitation est probablement réalisée sur l'OLT, située dans le NRO, toutefois, il est possible que les buffers de la Freebox soient eaux aussi sollicités en débit montant : Le 10G-EPON (IEEE 802.3av) mis en place par Free limite le débit de l'arbre à 1244 Mb/s (débit partagé par tous les clients). Il est donc possible que le buffers trop petit soient au niveau de la Freebox, juste avant que le débit parte sur l'arbre avec une limitation physique à 1244 Mb/s, soit au niveau de l'OLT qui doit limiter le débit montant aux 600 Mb/s contractuel.
Comment savoir si c'est plutôt coté OLT ou coté Freebox que le débit est trop faible ?
Le test serait de faire un comparatif avec une connexion 1 Gb/s (connecter le PC sur port 1 Gb/s de la Freebox est suffisant).
Si le débit montant est nettement meilleur avec une connexion 1 Gb/s, la limitation est du coté Freebox.
Si le débit n'est pas meilleur, il est plus difficile de tirer une conclusion, mais le buffer trop petit est probablement coté OLT, là où est fait la limitation du débit montant. Dans le cas (possible également mais peu probable) où la limitation de débit à 600 Mb/s est réalisé coté Freebox, alors ce sera le buffer coté Freebox, au niveau de la limitation à 600 Mb/s)
-
Et cela donne quoi avec l'algorithme d'évitement de congestion BBR ?
Cryptage, qui est confronté à la même problémaique que Breizh29 a réalisé des tests avec l''algorithme d'évitement de congestion Cubic (utilisé par défault) puis en fin de message avec le nouveau BBR crée par Google :
Ci-dessous les tests en IPv6 puis en IPv4, en étant connecté directement sur la Freebox.
Les débits sont toujours merdiques, comme depuis le début... (Free ne veut rien faire, "tout est normal").
IPv6 (1 flux) :
Connecting to host bouygues.testdebit.info, port 5201
[ 4] local 2a01:e0a:2d... port 49773 connected to 2001:860:deff:1000::2 port 5201
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-1.01 sec 6.12 MBytes 51.0 Mbits/sec
[ 4] 1.01-2.00 sec 8.88 MBytes 75.0 Mbits/sec
[ 4] 2.00-3.00 sec 8.38 MBytes 70.3 Mbits/sec
[ 4] 3.00-4.00 sec 5.00 MBytes 41.9 Mbits/sec
[ 4] 4.00-5.00 sec 8.62 MBytes 72.4 Mbits/sec
[ 4] 5.00-6.00 sec 13.1 MBytes 110 Mbits/sec
[ 4] 6.00-7.01 sec 7.00 MBytes 58.4 Mbits/sec
[ 4] 7.01-8.01 sec 9.50 MBytes 80.0 Mbits/sec
[ 4] 8.01-9.00 sec 8.75 MBytes 73.8 Mbits/sec
[ 4] 9.00-10.00 sec 13.0 MBytes 109 Mbits/sec
[ 4] 10.00-11.01 sec 6.75 MBytes 55.9 Mbits/sec
[ 4] 11.01-12.01 sec 8.38 MBytes 70.7 Mbits/sec
[ 4] 12.01-13.01 sec 11.6 MBytes 96.8 Mbits/sec
[ 4] 13.01-14.00 sec 7.00 MBytes 59.6 Mbits/sec
[ 4] 14.00-15.01 sec 11.8 MBytes 97.8 Mbits/sec
[ 4] 15.01-16.01 sec 11.4 MBytes 94.8 Mbits/sec
[ 4] 16.01-17.00 sec 6.88 MBytes 58.3 Mbits/sec
[ 4] 17.00-18.00 sec 11.5 MBytes 96.7 Mbits/sec
[ 4] 18.00-19.00 sec 7.62 MBytes 64.0 Mbits/sec
[ 4] 19.00-20.00 sec 10.1 MBytes 84.9 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-20.00 sec 181 MBytes 76.1 Mbits/sec sender
[ 4] 0.00-20.00 sec 181 MBytes 76.1 Mbits/sec receiver
IPv6 2 flux :
[SUM] 0.00-20.01 sec 281 MBytes 118 Mbits/sec sender
[SUM] 0.00-20.01 sec 281 MBytes 118 Mbits/sec receiver
IPv6 4 flux :
[SUM] 0.00-20.00 sec 470 MBytes 197 Mbits/sec sender
[SUM] 0.00-20.00 sec 469 MBytes 197 Mbits/sec receiver
IPv6 8 flux :
[SUM] 0.00-20.01 sec 651 MBytes 273 Mbits/sec sender
[SUM] 0.00-20.01 sec 650 MBytes 273 Mbits/sec receiver
IPv6 16 flux :
[SUM] 0.00-20.00 sec 798 MBytes 335 Mbits/sec sender
[SUM] 0.00-20.00 sec 795 MBytes 334 Mbits/sec receiver
IPv4 (1 flux) :
Connecting to host bouygues.testdebit.info, port 5201
[ 4] local 192.168.200.22 port 49876 connected to 89.84.1.222 port 5201
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-1.01 sec 3.50 MBytes 29.1 Mbits/sec
[ 4] 1.01-2.00 sec 8.88 MBytes 75.1 Mbits/sec
[ 4] 2.00-3.00 sec 12.8 MBytes 107 Mbits/sec
[ 4] 3.00-4.00 sec 7.00 MBytes 58.9 Mbits/sec
[ 4] 4.00-5.01 sec 5.62 MBytes 46.7 Mbits/sec
[ 4] 5.01-6.01 sec 9.50 MBytes 80.1 Mbits/sec
[ 4] 6.01-7.01 sec 10.9 MBytes 91.5 Mbits/sec
[ 4] 7.01-8.01 sec 10.4 MBytes 86.2 Mbits/sec
[ 4] 8.01-9.00 sec 5.88 MBytes 50.0 Mbits/sec
[ 4] 9.00-10.00 sec 9.00 MBytes 75.4 Mbits/sec
[ 4] 10.00-11.01 sec 8.25 MBytes 68.8 Mbits/sec
[ 4] 11.01-12.00 sec 10.8 MBytes 90.7 Mbits/sec
[ 4] 12.00-13.01 sec 6.88 MBytes 57.1 Mbits/sec
[ 4] 13.01-14.01 sec 7.50 MBytes 63.0 Mbits/sec
[ 4] 14.01-15.01 sec 8.38 MBytes 70.4 Mbits/sec
[ 4] 15.01-16.01 sec 8.12 MBytes 68.3 Mbits/sec
[ 4] 16.01-17.00 sec 9.25 MBytes 77.8 Mbits/sec
[ 4] 17.00-18.01 sec 5.50 MBytes 45.9 Mbits/sec
[ 4] 18.01-19.01 sec 6.62 MBytes 55.6 Mbits/sec
[ 4] 19.01-20.00 sec 10.2 MBytes 86.2 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-20.00 sec 165 MBytes 69.1 Mbits/sec sender
[ 4] 0.00-20.00 sec 165 MBytes 69.1 Mbits/sec receiver
IPv4 2 flux :
[SUM] 0.00-20.01 sec 270 MBytes 113 Mbits/sec sender
[SUM] 0.00-20.01 sec 270 MBytes 113 Mbits/sec receiver
IPv4 4 flux :
[SUM] 0.00-20.01 sec 495 MBytes 207 Mbits/sec sender
[SUM] 0.00-20.01 sec 494 MBytes 207 Mbits/sec receiver
IPv4 8 flux :
[SUM] 0.00-20.00 sec 657 MBytes 276 Mbits/sec sender
[SUM] 0.00-20.00 sec 656 MBytes 275 Mbits/sec receiver
IPv4 16 flux :
[SUM] 0.00-20.00 sec 818 MBytes 343 Mbits/sec sender
[SUM] 0.00-20.00 sec 815 MBytes 342 Mbits/sec receiver
Edit : je viens de faire le test en bbr et c'est juste hallucinant... :o
Par contre sous Windows que ce soit en cubic, ctcp, dctcp ou newreno ça ne change strictement rien... débit de merde en upload. :-\
Je ne sais pas ce qu'on peut en conclure... Saturation chez Free ?
1 flux :
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-20.00 sec 1.17 GBytes 503 Mbits/sec 89401 sender
[ 5] 0.00-20.04 sec 1.17 GBytes 501 Mbits/sec receiver
2 flux :
[SUM] 0.00-20.00 sec 1.26 GBytes 542 Mbits/sec 122231 sender
[SUM] 0.00-20.03 sec 1.26 GBytes 539 Mbits/sec receiver
Pour les abonnés Free qui ont le même genre de désagréments n'hésitez-pas à voter ici : https://dev.freebox.fr/bugs/task/29953
-
C'est quoi cet algorithme BBR qui permet de passer le débit montant sur une connexion de 69 Mb/s à 503 Mb/s ? (multiplication du débit par 7,3)
BBR, (Bottleneck Bandwidth and Round-trip propagation time) est un algorithme de contrôle de congestion TCP développé chez Google en 2016.
Alors que la plupart des algorithmes de contrôle de la congestion sont basés sur la perte (ils s'appuient sur la perte de paquets comme signal pour réduire le débit), BBR utilise la bande passante maximale et le temps d'aller-retour pour construire un modèle explicite du réseau. Chaque accusé de réception de paquets produit un échantillon de débit qui enregistre la quantité de données livrées sur l'intervalle de temps entre la transmission d'un paquet de données et l'accusé de réception de ce paquet. Alors que les débits augmentent, la latence associée au bufferbloat au lieu de la perte de paquets devient un marqueur plus fiable du débit maximal, ce qui fait que BBR fournit, en mono connexion, un débit plus élevé et une latence inférieure, face aux algorithmes basés sur la perte de paquet, comme le populaire CUBIC.
A noter :
o Peu représentatif de l’Internet, BBR est principalement utilisé par Google. Une fois implémenté dans YouTube, BBR a permis en moyenne un débit de réseau supérieur de 4% et jusqu'à 14% dans certains pays (source Google).
o BBR est efficace et rapide, mais son équité vis-à-vis des flux non BBR est contestée. Alors que la présentation de Google montre que BBR coexiste bien avec CUBIC, des chercheurs le trouvent injuste par rapport aux autres flux et non évolutif. Ils montrent que BBR ne fonctionne pas bien dans des environnements dynamiques tels que les réseaux cellulaires. Ils ont également montré que BBR avait un problème d'injustice. Par exemple, lorsqu'un flux CUBIC coexiste avec un flux BBR dans le réseau, le flux BBR peut dominer le flux CUBIC et en obtenir toute la bande passante.
Comparatif Cubic / BBR, réalisé en débit descendant sur la même Freebox Delta de Breizh29, utilisée pour ce tutoriel sur l'analyse avec Wireshark :
Les évolutions du tcp_congestion_control :
- 17 janvier 9h32 Illinois => Cubic
- 20 janvier 8h12 Cubic => BBR
- 22 janvier 10h03 BBR => Illinois (on n'avais pas de tests mono-thread en Illinois)
Actuellement :
$ cat /proc/sys/net/ipv4/tcp_congestion_control
illinois
(https://lafibre.info/images/free_debit/202001_comparatif_bubic_bbr_1.png)
(https://lafibre.info/images/free_debit/202001_comparatif_bubic_bbr_2.png)
(https://lafibre.info/images/free_debit/202001_comparatif_bubic_bbr_3.png)
-
Comment passer à BBR ?
C'est l’émetteur qui doit changer de protocole de congestion.
Pour le débit descendant, il est donc impossible de le changer.
Ici on s'intéresse au débit montant, voici le tutoriel que pour Linux :
Je recommande de faire un fichier :
sudo nano /etc/sysctl.d/90-optimization.conf
Il suffit de mettre la ligne suivante :
net.ipv4.tcp_congestion_control=bbr
Redémarrez votre PC.
Pour vérifier l'algorithme de contrôle de congestion TCP utilisé :
cat /proc/sys/net/ipv4/tcp_congestion_control
Cela affiche "bbr" si la modification a bien été prise en compte ou "cubic" autrement.
Vous pouvez en profiter pour augmenter les buffer TCP afin d'être sur de ne pas limiter le débit quand la latence et le débit est élevé.
Insérer dans le même fichier les lignes suivantes :
# 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
-
Merci pour cette analyse, c'est très instructif.
T'as dû passer un moment pour la rédiger !
Ça met en évidence un problème de buffers pour lequel on a du mal à imaginer que Free n'en sache rien...
Personne n'aurait un contact chez Free pour faire remonter le problème ? L'analyse de Vivien doit pouvoir aider.
Mettre en place BBR ça aide mais ce n'est pas forcément une solution viable et surtout les Windowsiens restent sans contournement.
Une remarque pour ton tuto Vivien : pour appliquer la modification du sysctl.conf on peut s'éviter le reboot en passant la commande "sysctl -p".
-
Oui pour appliquer les modifications sans reboot : sudo sysctl -p permet de charger les fichiers /etc/sysctl.conf et /etc/sysctl.d/* et donc d'appliquer les paramètres.
Avant de contacter Free, il me semble important de poursuivre l'analyse pour voir où est le problème :
Comment savoir si c'est plutôt coté OLT ou coté Freebox que le débit est trop faible ?
Le test serait de faire un comparatif avec une connexion 1 Gb/s (connecter le PC sur port 1 Gb/s de la Freebox est suffisant).
Si le débit montant est nettement meilleur avec une connexion 1 Gb/s, la limitation est du coté Freebox.
Si le débit n'est pas meilleur, il est plus difficile de tirer une conclusion, mais le buffer trop petit est probablement coté OLT, là où est fait la limitation du débit montant. Dans le cas (possible également mais peu probable) où la limitation de débit à 600 Mb/s est réalisé coté Freebox, alors ce sera le buffer coté Freebox, au niveau de la limitation à 600 Mb/s)
-
Oui pour appliquer les modifications sans reboot : sudo sysctl -p permet de charger les fichiers /etc/sysctl.conf et /etc/sysctl.d/* et donc d'appliquer les paramètres.
Avant de contacter Free, il me semble important de poursuivre l'analyse pour voir où est le problème :
Salut Vivien et merci pour l'analyse !
Pour le test en 1gbps, il y a un topic complet qui en parle, on a en effet un meilleur upload en 1gbps qu'en 10gbps => https://lafibre.info/1gb-free/debit-upload-x520-da1/
Un ticket a été ouvert par Roncamma => https://dev.freebox.fr/bugs/task/28327
-
@Vivien : pour ma part je suis en Freebox Révolution donc forcément en 1 Gbps.
Du coup ça orienterait plutôt sur l'OLT car l'ONU n'est pas le même entre Delta et Révolution.
-
Si tu es avec la Freebox révolution ton PC ne dépasse pas 1 b/s en upload et donc le premier endroit où les buffer se remplissent, c'est là ou le débit est limité à 600 Mb/s.
La limitation de débit est généralement réalisée coté OLT (donc dans les équipements au NRO), mais c'est possible, bien que peu probable, que la limitation de débit à 600 Mb/s soit réalisé coté Freebox. Si on est dans ce dernier cas, alors ce sera le buffer coté Freebox, au niveau de la limitation à 600 Mb/s.
Les équipements étant différents pour les clients en point à point, il serait intéressant de savoir si ils sont également touché par ce problème de petits buffers.
-
Impressionnant le tuto !
Merci Vivien.
Je vous fais le test en 1 gbps asap.
-
@vivien : il y a quelques "SLACK" à la place de "SACK".
Sinon l'analyse est intéressante, en revanche elle n'explique pas pourquoi Fuli10 voit toujours des pertes sur un test en UDP avec débit limité : https://lafibre.info/1gb-free/serveur-iperf3-chez-free/msg725969/#msg725969.
Normalement, si le PC envoie plus lentement que la capacité de la ligne, il ne devrait pas y avoir de pertes au niveau des endroits où le débit est limité, même si les buffers sont petits (sauf si l'arbre est saturé bien sûr, ce qui ne semble pas être le cas).
-
J'ai corrigé les SACK mal écrits.
J'ai rajouté un résumé en un graphique :
(https://lafibre.info/images/wireshark/202002_free_delta_analyse_debit_breizh29_perte1.png)
-
Normalement, si le PC envoie plus lentement que la capacité de la ligne, il ne devrait pas y avoir de pertes au niveau des endroits où le débit est limité, même si les buffers sont petits (sauf si l'arbre est saturé bien sûr, ce qui ne semble pas être le cas).
Même sans parler de saturation de l'arbre, en xPON le débit upload est en permanence (125 us) renégocié (algo DBA, timeslots, TDMA) entre ONT et OLT, en fonction des demandes de trafic de tous les acteurs de l'arbre.
Ceci peut conduire à des variations de capacités dans le temps pour une ligne donnée, qui peut provoquer, si c'est mal géré au niveau bufferisation, des pertes de paquets.
-
Oui, Il faut prévoir des buffers au niveau de l'interface wan upload de la box, une saturation au niveau de l'arbre, entrainant pour l'utilisateur une limitaiton de débit plus forte que l'outil qui limite à 600 Mb/s coté OLT est possible.
Dans notre cas, on a vu que les débits étaient mauvais la nuit, or il y a de forte chance d'avoir l'arbre très peu chargé en upload la nuit.
Ce graphique a été un élément décisif pour fermer la porte à certaines possibilités, le graphe Wireshark n'est pas suffisant à lui seul. (cliquer sur le graphique pour zoomer)
(https://lafibre.info/images/wireshark/202002_free_delta_analyse_debit_breizh29_ul.png) (https://lafibre.info/images/wireshark/202002_free_delta_analyse_debit_breizh29_ul.png)
-
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 (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.
-
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)
-
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).
-
Passionnant. En espérant que ça débouche chez une explication de la part de Free...
-
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...
-
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.
-
J'ai ajouté des éléments sur le ticket.
Je vois pour faire la capture si je trouve un moment ;D
-
Comparaison Cubic / BBR réalisé sur une ligne Free FTTH impactée elle aussi par les pertes de paquets.
Débit montant :
(https://lafibre.info/images/free_debit/202002_comparatif_cubic_bbr_2.png) (https://lafibre.info/images/free_debit/202002_comparatif_cubic_bbr_2.png)
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
-
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).
-
Je suis preneur !
-
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)
(https://lafibre.info/images/wireshark/202002_free_analyse_debit_fuli10_cubic_1.png) (https://lafibre.info/images/wireshark/202002_free_analyse_debit_fuli10_cubic_1.png)
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.
-
Voici un zoom au moment de la perte des deux paquets :
(cliquer sur le graphique pour zoomer)
(https://lafibre.info/images/wireshark/202002_free_analyse_debit_fuli10_cubic_2.png) (https://lafibre.info/images/wireshark/202002_free_analyse_debit_fuli10_cubic_2.png)
-
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)
(https://lafibre.info/images/wireshark/202002_free_analyse_debit_fuli10_cubic_3.png) (https://lafibre.info/images/wireshark/202002_free_analyse_debit_fuli10_cubic_3.png)
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)
(https://lafibre.info/images/wireshark/202002_free_analyse_debit_fuli10_cubic_4.png) (https://lafibre.info/images/wireshark/202002_free_analyse_debit_fuli10_cubic_4.png)
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.
-
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)
(https://lafibre.info/images/wireshark/202002_free_analyse_debit_fuli10_bbr_1.png) (https://lafibre.info/images/wireshark/202002_free_analyse_debit_fuli10_bbr_1.png)
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 !
-
Voici le début de la connexion TCP :
(cliquer sur le graphique pour zoomer)
(https://lafibre.info/images/wireshark/202002_free_analyse_debit_fuli10_bbr_2.png) (https://lafibre.info/images/wireshark/202002_free_analyse_debit_fuli10_bbr_2.png)
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)
(https://lafibre.info/images/wireshark/202002_free_analyse_debit_fuli10_bbr_3.png) (https://lafibre.info/images/wireshark/202002_free_analyse_debit_fuli10_bbr_3.png)
-
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)
(https://lafibre.info/images/wireshark/202002_free_analyse_debit_fuli10_bbr_4.png) (https://lafibre.info/images/wireshark/202002_free_analyse_debit_fuli10_bbr_4.png)
Merci pour cette belle capture qui montre comment BBR s'y prend pour améliorer le débit par rapport à Cubic.
-
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.
-
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.
-
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.
-
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.
-
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 (https://fr.wikipedia.org/wiki/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).
-
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.
-
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)
-
@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
-
Oui, intéressé si c'est du mono-connexion (difficile 'analyser quelques chose sur du multi-connexions TCP).
Le trafic étranger ne me gène pas, je filtre toujours sur la connexion TCP de la capture.
-
C'est du mono-connexion oui, j'ai utilisé cette commande :
iperf3 -c bouygues.testdebit.info -t 20 -i 1 ( -4 ) ( -C bbr)
Le test a été fait à 13h : entre 80-130 Mbps en Cubic et 450-500 Mbps en BBR de mémoire.
--> Je te fais parvenir ça par MP.
-
La compression de tes captures est impressionnante : ton .tar.lzma a une taille de 6,2 Mo compressé et fait 3,3 Go décompressé.
Je commence par la capture Cubic IPv6
On voit assez quelques pertes de paquets. Wireshark à tagué 23 paquets "Out-of-Order" et 13 paquets "TCP Fast Restransmission", cela fait donc en réalité 36 paquets perdus.
(Le filtre à utiliser est tcp.analysis.retransmission et tcp.analysis.out_of_order pour voir ces paquets)
La courbe n'est pas une droite parfaite, on voit que le débit baisse à chaque perte de paquet, pour remonter doucement ensuite.
(cliquer sur le graphique pour zoomer)
(https://lafibre.info/images/wireshark/202002_free_analyse_debit_cryptage_ipv6_cubic_1.png) (https://lafibre.info/images/wireshark/202002_free_analyse_debit_cryptage_ipv6_cubic_1.png)
-
Un point important est le début de la connexion : si cela démarre mal, le trafic a de très forte chance d'être limité.
Voici les paquets de données depuis le début.
On note que lors de la 3ème slave d'envoi de paquets, à T=0,074, il y a des traits rouges, correspondants à ce que Wireshark considère comme [TCP Dup ACK] :
(cliquer sur le graphique pour zoomer)
(https://lafibre.info/images/wireshark/202002_free_analyse_debit_cryptage_ipv6_cubic_2.png) (https://lafibre.info/images/wireshark/202002_free_analyse_debit_cryptage_ipv6_cubic_2.png)
Quand on regarde le détaille, on note qu'un paquet, celui qui commence par 54302 a été retardé de 4 paquets.
Il y a donc un vrai problème dés le début et on voit que l'émetteur à réduit sa vitesse d'émission : Avant on était sur des paquets de 6 à 10 Ko, immédiatement après cette gigue on est majoritairement sur des paquets de 1,5 Ko.
(cliquer sur le graphique pour zoomer)
(https://lafibre.info/images/wireshark/202002_free_analyse_debit_cryptage_ipv6_cubic_3.png) (https://lafibre.info/images/wireshark/202002_free_analyse_debit_cryptage_ipv6_cubic_3.png)
-
On continue avec la capture Cubic IPv4
On voit assez quelques pertes de paquets. Wireshark à tagué 45 paquets "Out-of-Order" et 17 paquets "TCP Fast Restransmission", cela fait donc en réalité 62 paquets perdus.
Attention, ce ne sont pas des paquets de MTU de 1500, ce sont des paquets vu de ton PC, avant qu'ils soient découpés par la carte réseau. Certains paquets retransmis ont une taille de 14546 octets, c'est donc un assemblage de 10 paquets.
En réalité on dépasse donc les 100 paquets perdus.
La courbe n'est pas une droite parfaite, on voit que le débit baisse à chaque perte de paquet, pour remonter doucement ensuite.
(cliquer sur le graphique pour zoomer)
(https://lafibre.info/images/wireshark/202002_free_analyse_debit_cryptage_ipv4_cubic_1.png) (https://lafibre.info/images/wireshark/202002_free_analyse_debit_cryptage_ipv4_cubic_1.png)
Voici le tout début de la connexion, au note a la 5ème slave de paquets envoyés un éclatement des buffers, on est dans le même cas que Breizh29.
(cliquer sur le graphique pour zoomer)
(https://lafibre.info/images/wireshark/202002_free_analyse_debit_cryptage_ipv4_cubic_2.png) (https://lafibre.info/images/wireshark/202002_free_analyse_debit_cryptage_ipv4_cubic_2.png)
-
Voici la suite de la connexion, avec le même niveau de zoom que celui utilisé pour le tout début de la connexion.
On est à t=0,3 sec donc encore au début et là on observe 3 phénomènes de gigue, déjà observée dans les autres captures.
Pour le premier phénomène de gigue, le comportement de l'émetteur est différent de ce que l'on à vu jusqu'à présent : il va renvoyer le paquet, pensant qu'il est perdu.
C'est inutile car il est acquitté immédiatement derrière, donc l’acquittement correspond au paquet initial reçu avec un peu de retard.
On observe plus tard l’acquittement spécifique au paquet reçu en double.
(cliquer sur le graphique pour zoomer)
(https://lafibre.info/images/wireshark/202002_free_analyse_debit_cryptage_ipv4_cubic_3.png) (https://lafibre.info/images/wireshark/202002_free_analyse_debit_cryptage_ipv4_cubic_3.png)
Dans la vue par paquet, on voit :
- T=0,335 Le paquet 3110342 est arrivé en retard de 2 paquets
- T=0,335 l'émetteur a renvoyé le paquet présumé perdu dés le second [TCP Dup ACK]
- T=0,348 Le paquet renvoyé en double est acquitté de manière spécifique par le récepteur avec du SACK, pour bien faire comprendre à l'émetteur que le paquet a été reçu en double.
TCP ayant une capacité d’apprentissage, comme l'acquittement spécial, il laissera plus de temps lors des prochains phénomène de gigue pour recevoir l’acquittement. Bref, TCP prend en compte que cette connexion est dégradée et qu'elle a une forte gigue : il faut donc envoyer les paquets à un débit plus réduit (plus ils sont rapprochés, pus il y a un risque d'être dans le désordre à la réception) et en cas d'acquittements qui mentionnent une perte de paquets, laisser plusieurs paquets passer, au ca où cela serait une gigue.
(cliquer sur le graphique pour zoomer)
(https://lafibre.info/images/wireshark/202002_free_analyse_debit_cryptage_ipv4_cubic_4.png) (https://lafibre.info/images/wireshark/202002_free_analyse_debit_cryptage_ipv4_cubic_4.png)
-
La capture BBR en IPv6
En IPv6 Cubic, 240 Mo ont été échangés pendant les 20 secondes (l'axe des ordonnée s’arrête à 240 000 000 octets)
En IPv6 BBR, c'est plus de 1,2 Go qui ont été échangés pendant les 20 secondes (on dépasse 1 200 000 000 sur l'axe des ordonnée)
=> BBR a un débit moyen plus de 5 fois plus élevé à Cubic ici
Vous savez que si BBR est agressif, cela va faire des paquets perdus en masse.
Le filtre tcp.analysis.retransmission annonce 912 paquets, dont la plupart sont d'une grande taille (certains font même 53 Ko)
Le filtre tcp.analysis.out_of_order annonce 13 938 paquets, dont la plupart sont d'une grande taille (certains font même 60 Ko !)
On est donc sur de la perte de paquet massive.
(cliquer sur le graphique pour zoomer)
(https://lafibre.info/images/wireshark/202002_free_analyse_debit_cryptage_ipv6_bbr_1.png) (https://lafibre.info/images/wireshark/202002_free_analyse_debit_cryptage_ipv6_bbr_1.png)
Comme pour les autres captures, voici le tout début de la connexion.
On remarque que BBR envoi les paquets à un rythme régulier, là où BBR envoi des slave de paquets.
Tout se passe bien quand le débit est réduit, jusqu'à T=0,2 secondes ensuite ce sont des pertes massives.
(cliquer sur le graphique pour zoomer)
(https://lafibre.info/images/wireshark/202002_free_analyse_debit_cryptage_ipv6_bbr_2.png) (https://lafibre.info/images/wireshark/202002_free_analyse_debit_cryptage_ipv6_bbr_2.png)
-
Un point intéressant, c'est que l'on voit à la 15ème seconde du test que le trafic s’arrête un certain temps.
Voici le zoom sur cette période :
(cliquer sur le graphique pour zoomer)
(https://lafibre.info/images/wireshark/202002_free_analyse_debit_cryptage_ipv6_bbr_3.png) (https://lafibre.info/images/wireshark/202002_free_analyse_debit_cryptage_ipv6_bbr_3.png)
Les paquets d'acquittement sélectif (SACK = selective acknowledgement)sont limités à un maximum de 3 blocs discontinus de paquets reçus correctement, en plus du numéro de séquence suivant immédiatement le dernier numéro de séquence du dernier octet contigu reçu successivement.
Ici on dépasse visiblement 3 blocs discontinus, et il n'est donc pas simple à l'émetteur de faire son choix dans les paquets à ré-émettre.
La situation a visiblement dérapé. Voici le vue par paquets, j'ai coupé la partie droite, c'est simple, tous les paquets d’acquittements sont remplis de 3 blocs discontinus, le maximum possible.
Je dois par contre partir travailler, je ne pourrais pas analyser tout de suite la cause de cette interruption du trafic en BBR.
(cliquer sur le graphique pour zoomer)
(https://lafibre.info/images/wireshark/202002_free_analyse_debit_cryptage_ipv6_bbr_4.png) (https://lafibre.info/images/wireshark/202002_free_analyse_debit_cryptage_ipv6_bbr_4.png)
On note que quand l'émetteur repart après avoir renvoyé quelques paquets dont il attendait l’acquittement, BBR repart directement au débit maximum, alors que Cubic dans des situation comme celle à repart en "slow start" comme au début d'une connexion TCP, en envoyant quelques paquets puis attendant leur acquittements.
-
Capture BBR en IPv4
On a une belle droite : le débit est stable.
Contrairement à la courbe BBR en IPv6, il n'y a pas d'interruption
(cliquer sur le graphique pour zoomer)
(https://lafibre.info/images/wireshark/202002_free_analyse_debit_cryptage_ipv4_bbr_1.png) (https://lafibre.info/images/wireshark/202002_free_analyse_debit_cryptage_ipv4_bbr_1.png)
Voici la courbe du début de la connexion.
On note deux interruption de courtes durées à T=0,2 sec et T= 0,26 sec
(cliquer sur le graphique pour zoomer)
(https://lafibre.info/images/wireshark/202002_free_analyse_debit_cryptage_ipv4_bbr_2.png) (https://lafibre.info/images/wireshark/202002_free_analyse_debit_cryptage_ipv4_bbr_2.png)
-
On va ensuite avoir régulièrement ces petites coupures, où l’émetteur n'émet plus rien pendant une courte durée.
Un gain de débit est donc encore possible
(cliquer sur le graphique pour zoomer)
(https://lafibre.info/images/wireshark/202002_free_analyse_debit_cryptage_ipv4_bbr_3.png) (https://lafibre.info/images/wireshark/202002_free_analyse_debit_cryptage_ipv4_bbr_3.png)
(cliquer sur le graphique pour zoomer)
(https://lafibre.info/images/wireshark/202002_free_analyse_debit_cryptage_ipv4_bbr_4.png) (https://lafibre.info/images/wireshark/202002_free_analyse_debit_cryptage_ipv4_bbr_4.png)
-
Un zoom sur un de ces coupures.
Il y a un trait bleu des paquet émis à gauche puis un peu plus à droite un trait bleu en pointillé, ce sont tous les paquets renvoyés.
On note que pendant cette coupure, l’émetteur continue de renvoyer tous les paquets qui lui sont signalés perdus.
C'est uniquement la courbe de gauche qui est mis en pause quelques dizaines de millisecondes.
Pendant cette coupure, le débit est faible est les buffers doit se vider : on n'exploite pas au maximum le débit offert par la ligne dans ces moments là.
(cliquer sur le graphique pour zoomer)
(https://lafibre.info/images/wireshark/202002_free_analyse_debit_cryptage_ipv4_bbr_5.png) (https://lafibre.info/images/wireshark/202002_free_analyse_debit_cryptage_ipv4_bbr_5.png)
-
Est-ce que cette analyse te permet de conclure ? Par exemple sur des buffers trop petits comme supposé précédemment ?
-
Sur la capture IPv4 Cubic, on voit bien le fait que les buffers sont trop petits.
Cela ne se voit pas sur la capture IPv6 Cubic, mais c'est peut-être que tu avait fait un test avant : TCP est mesure de garder souvenir des destinations où les précédents connexions on posées problème et où il faut donc envoyer les paquets à un faible débit.
Pour éviter ce phénomène de mémoire, il faudrait employer net.ipv4.tcp_no_metrics_save=1 comme je l'ai mis dans mon fichier d'optimisation, présent sur les serveurs de test de débit que j'administre :
nano /etc/sysctl.d/90-server-optimization.conf
# Reduce the swap
vm.swappiness = 1
# 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
# Reduce the threshold where a DDOS impacts the server
net.ipv4.tcp_max_syn_backlog = 4096
# Increase number of incoming connections
net.core.somaxconn = 512
Par défaut, TCP enregistre diverses métriques de connexion dans le cache de routage lorsque la connexion se ferme, de sorte que les connexions établies dans un proche avenir peuvent les utiliser pour définir les conditions initiales. Habituellement, cela augmente les performances globales, mais peut parfois entraîner une dépendance du test N au test N-1.
Dans le cadre des tests réalisés ici, nous souhaitons voir les problèmes et éviter qu'il réduise préventivement son débit.
Afin d’assurer une décorrélation des tests successifs, il semble opportun de désactiver la mémorisation des tests précédents sur le serveur pour les tests download (déjà fait) et sur le client pour les tests upload, via l'emploi de « tcp_no_save_metrics=1 » afin d’éviter que serveur bride tous les tests suite à une performance limitée.
Les optimisations des buffers sont aussi bienvenue pour ne pas avoir de limitation de ce coté là (mais à priori ce n'est pas la cause de la limitation de débit enregistré et si cela briderait le débit, cela le ferait de manière équivalente en Cubic et en BBR)
Maintenant l'autre problème qui est présents dans les différentes captures (et que je n'avais pas vu lors de la première analyse de Breizh29), c'est le fait que les paquets arrivent régulièrement dans le désordre.
Je pense que ce désordre est probablement la cause des coupures vu avec un transfert avec le protocole de congestion BBR.
Il y a donc deux gros problèmes rencontrés dans ces captures.
Le buffer on sait que c'est sous la responsabilité de Free.
Les paquets qui arrivent dans le désordre, on n'a rien qui prouve que c'est sous la responsabilité de Free.
Il faudrait faire un capture en Cubic (BBR c'est compliqué à analyser vu les pertes dans tous les sens) avec un serveur qui n'est pas hébergé chez Bouygues Telecom pour voir si les paquets dans le désordre sont toujours présents.
Je suis donc intéressé par un upload Cubic, plutôt en IPv6, vers un autre serveur iPerf3.
-
En lisant plusieurs thread sur les forums, on remarque que l'augmentation de l'UL dans les offres Free à améliorer les résultats des tests de débit UL.
Savez-vous si Free est intervenu aussi sur les buffers ?
-
Les buffers, si ils ne sont pas présents matériellement, il n'est pas possible de les créer par une mises à jour logicielle.
Pour moi la Delta aurait besoin d'une révision pour corriger ce bug hardware.