Auteur Sujet: Étrange problème de performances FTTH (Lu 1447 fois)

bugmenot · « **le:** 17 octobre 2023 à 19:48:59 »

Nouvellement abonné FTTH chez OVH je rencontre un étrange problème de performance sur mes downloads via un seul flux TCP. Quoi que je fasse je suis autour des 80Mbit/s. Les upload dans les mêmes conditions me permettent de quasiment atteindre le Gbit/s. De même un download avec plusieurs flux TCP (par exemple un speedtest en mode multi) me permettent de quasi atteindre le Gbit/s.

Je suis sur collecte Kosc PPPoE via Altitude Infra (ex Covage) dans le 74. Je dois être un des premiers connectés de mon village donc j’imagine peu une saturation de l’arbre GPON. Ping aux alentours des 17ms.

Ce que j’ai essayé sans variation notable des performances:
- Tester depuis le routeur lui meme et depuis d’autres clients/os en Ethernet
- Utiliser d’autres ports/protocoles (http, https, iperf3)
- Utiliser IPv6
- Changer les paramètres MTU, MSS Clamping
- Faire les tests download a différentes heures du jour et de la nuit
- Remplacer mon routeur Banana PI R3/OpenWRT par une FrizBox avec config totalement vierge.

Un test avec iperf3 en UDP me permet d’atteindre le Gbit/s.

J’avoue un peu être a court d’idée pour comprendre ce qui se passe.

Quelques captures de sessions de test

Ping

Code: [Sélectionner]


root@bpi:~# ping www.ovh.com
PING www.ovh.com (198.27.92.1): 56 data bytes
64 bytes from 198.27.92.1: seq=0 ttl=55 time=16.939 ms
64 bytes from 198.27.92.1: seq=1 ttl=55 time=17.234 ms
64 bytes from 198.27.92.1: seq=2 ttl=55 time=17.196 ms
64 bytes from 198.27.92.1: seq=3 ttl=55 time=16.861 ms
64 bytes from 198.27.92.1: seq=4 ttl=55 time=16.888 ms
64 bytes from 198.27.92.1: seq=5 ttl=55 time=16.863 ms
64 bytes from 198.27.92.1: seq=6 ttl=55 time=16.960 ms
^C
--- www.ovh.com ping statistics ---
7 packets transmitted, 7 packets received, 0% packet loss
round-trip min/avg/max = 16.861/16.991/17.234 ms

Download TCP

Code: [Sélectionner]


root@bpi:~# iperf3 -4 -c proof.ovh.net -p 5210 -R -V
iperf 3.15
Linux bpi 5.15.134 #0 SMP Mon Oct 9 21:45:35 2023 aarch64
Control connection MSS 1440
Time: Tue, 17 Oct 2023 17:18:31 UTC
Connecting to host proof.ovh.net, port 5210
Reverse mode, remote host proof.ovh.net is sending
      Cookie: pyq2ahzz3m2wqbt7nminckuobd4jwnn7c3zg
      TCP MSS: 1440 (default)
[  5] local 109.190.106.43 port 58556 connected to 141.95.207.211 port 5210
Starting Test: protocol: TCP, 1 streams, 131072 byte blocks, omitting 0 seconds, 10 second test, tos 0
[ ID] Interval           Transfer     Bitrate
[  5]   0.00-1.00   sec  21.2 MBytes   178 Mbits/sec                  
[  5]   1.00-2.01   sec  10.6 MBytes  88.8 Mbits/sec                  
[  5]   2.01-3.01   sec  8.12 MBytes  67.9 Mbits/sec                  
[  5]   3.01-4.00   sec  9.62 MBytes  81.6 Mbits/sec                  
[  5]   4.00-5.00   sec  7.00 MBytes  58.5 Mbits/sec                  
[  5]   5.00-6.01   sec  8.12 MBytes  67.6 Mbits/sec                  
[  5]   6.01-7.00   sec  8.38 MBytes  71.0 Mbits/sec                  
[  5]   7.00-8.01   sec  11.0 MBytes  91.4 Mbits/sec                  
[  5]   8.01-9.00   sec  8.88 MBytes  75.1 Mbits/sec                  
[  5]   9.00-10.01  sec  6.50 MBytes  54.0 Mbits/sec                  
- - - - - - - - - - - - - - - - - - - - - - - - -
Test Complete. Summary Results:
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.07  sec   103 MBytes  86.0 Mbits/sec   19             sender
[  5]   0.00-10.01  sec  99.5 MBytes  83.4 Mbits/sec                  receiver
snd_tcp_congestion cubic
rcv_tcp_congestion cubic

Download UDP

Code: [Sélectionner]


root@bpi:~# iperf3 -4 -c proof.ovh.net -p 5210 -R -V -u -b 1000M
iperf 3.15
Linux bpi 5.15.134 #0 SMP Mon Oct 9 21:45:35 2023 aarch64
Control connection MSS 1440
Setting UDP block size to 1440
Time: Tue, 17 Oct 2023 17:33:19 UTC
Connecting to host proof.ovh.net, port 5210
Reverse mode, remote host proof.ovh.net is sending
      Cookie: rxz2vwdbogopno35qrma3mkt7wuoz5znzvnb
      Target Bitrate: 1000000000
[  5] local 109.190.106.43 port 41379 connected to 141.95.207.211 port 5210
Starting Test: protocol: UDP, 1 streams, 1440 byte blocks, omitting 0 seconds, 10 second test, tos 0
[ ID] Interval           Transfer     Bitrate         Jitter    Lost/Total Datagrams
[  5]   0.00-1.00   sec   113 MBytes   951 Mbits/sec  0.005 ms  6774/89344 (7.6%)  
[  5]   1.00-2.00   sec   113 MBytes   951 Mbits/sec  0.003 ms  4236/86796 (4.9%)  
[  5]   2.00-3.00   sec   113 MBytes   951 Mbits/sec  0.057 ms  4252/86811 (4.9%)  
[  5]   3.00-4.00   sec   113 MBytes   951 Mbits/sec  0.054 ms  4264/86803 (4.9%)  
[  5]   4.00-5.00   sec   113 MBytes   951 Mbits/sec  0.045 ms  4256/86807 (4.9%)  
[  5]   5.00-6.00   sec   113 MBytes   951 Mbits/sec  0.005 ms  4265/86804 (4.9%)  
[  5]   6.00-7.00   sec   113 MBytes   951 Mbits/sec  0.005 ms  4246/86811 (4.9%)  
[  5]   7.00-8.00   sec   113 MBytes   951 Mbits/sec  0.004 ms  4247/86805 (4.9%)  
[  5]   8.00-9.00   sec   113 MBytes   951 Mbits/sec  0.009 ms  4252/86801 (4.9%)  
[  5]   9.00-10.00  sec   113 MBytes   951 Mbits/sec  0.007 ms  4244/86807 (4.9%)  
- - - - - - - - - - - - - - - - - - - - - - - - -
Test Complete. Summary Results:
[ ID] Interval           Transfer     Bitrate         Jitter    Lost/Total Datagrams
[  5]   0.00-10.07  sec  1.17 GBytes  1000 Mbits/sec  0.000 ms  0/0 (0%)  sender
[  5]   0.00-10.00  sec  1.11 GBytes   951 Mbits/sec  0.007 ms  45036/870589 (5.2%)  receiver

Upload TCP

Code: [Sélectionner]


root@bpi:~# iperf3 -4 -c proof.ovh.net -p 5210 -V
iperf 3.15
Linux bpi 5.15.134 #0 SMP Mon Oct 9 21:45:35 2023 aarch64
Control connection MSS 1440
Time: Tue, 17 Oct 2023 17:44:00 UTC
Connecting to host proof.ovh.net, port 5210
      Cookie: eixxkbazkppmuty66vskughde2xbehcsuzac
      TCP MSS: 1440 (default)
[  5] local 109.190.106.43 port 38256 connected to 141.95.207.211 port 5210
Starting Test: protocol: TCP, 1 streams, 131072 byte blocks, omitting 0 seconds, 10 second test, tos 0
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec  99.8 MBytes   837 Mbits/sec    0   2.43 MBytes       
[  5]   1.00-2.00   sec   111 MBytes   933 Mbits/sec    0   2.43 MBytes       
[  5]   2.00-3.00   sec   111 MBytes   932 Mbits/sec    0   2.43 MBytes       
[  5]   3.00-4.00   sec   110 MBytes   924 Mbits/sec    0   2.43 MBytes       
[  5]   4.00-5.00   sec   111 MBytes   933 Mbits/sec    0   2.43 MBytes       
[  5]   5.00-6.00   sec   111 MBytes   933 Mbits/sec    0   2.43 MBytes       
[  5]   6.00-7.00   sec   110 MBytes   923 Mbits/sec    0   2.43 MBytes       
[  5]   7.00-8.00   sec   111 MBytes   933 Mbits/sec    0   2.43 MBytes       
[  5]   8.00-9.00   sec   111 MBytes   933 Mbits/sec    0   2.43 MBytes       
[  5]   9.00-10.00  sec   111 MBytes   933 Mbits/sec    0   2.43 MBytes       
- - - - - - - - - - - - - - - - - - - - - - - - -
Test Complete. Summary Results:
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec  1.07 GBytes   921 Mbits/sec    0             sender
[  5]   0.00-10.05  sec  1.07 GBytes   916 Mbits/sec                  receiver
CPU Utilization: local/sender 10.6% (0.0%u/10.6%s), remote/receiver 0.2% (0.0%u/0.2%s)
snd_tcp_congestion cubic
rcv_tcp_congestion cubic

bugmenot · « **Réponse #1 le:** 17 octobre 2023 à 21:51:36 »

Citation de: ouno le 17 octobre 2023 à 20:20:11

Peut-être un souci de buffer de réception TCP ?

Merci pour l’idée … mais ne semble pas être ça. J’ai passé rmem a un énorme 12Mb qui devrait permettre presque 5Gbit/s avec 20ms de RTT, mais pas d’influence.

Hugues · « **Réponse #2 le:** 17 octobre 2023 à 22:40:07 »

Citation de: bugmenot le 17 octobre 2023 à 19:48:59

Je suis sur collecte Kosc PPPoE via Altitude Infra (ex Covage) dans le 74. Je dois être un des premiers connectés de mon village donc j’imagine peu une saturation de l’arbre GPON. Ping aux alentours des 17ms.

Une saturation de la collecte est par contre plus probable vu que c'est la même collecte que le FTTH activé. Rien ne dit que le souci vienne de là mais je préfère le préciser.

Coté MTU tu es bien à 1500 IP et 1600 L2 ?

bugmenot · « **Réponse #3 le:** 18 octobre 2023 à 01:44:11 »

Citation de: Hugues le 17 octobre 2023 à 22:40:07

Une saturation de la collecte est par contre plus probable vu que c'est la même collecte que le FTTH activé. Rien ne dit que le souci vienne de là mais je préfère le préciser.

Bon point, mais mêmes performances à toute heure du jour et de la nuit.

Citer

Coté MTU tu es bien à 1500 IP et 1600 L2 ?

Ah alors pas du tout. Toutes mes interfaces sont à 1500 sauf la pppoe-wan à un classique 1492. Dans le doute j’ai essayé avec les valeurs que tu mentionnes mais pas de changement significatif dans les performances. C’est la première fois que je vois mentionner une MTU à 1600, pourrais tu éclairer ma lanterne sur la rationale ?

Hugues · « **Réponse #4 le:** 18 octobre 2023 à 02:03:10 »

En FTTH on a enfin arrêté cette hérésie de la MTU à 1492, on a largement de quoi faire passer plus.

Si l'opérateur en face n'est pas trop bête (et chez Altitude ça marche, j'en ai en prod), la MTU utile est à 1500, ce qui donne des paquets IP à 1508 et des paquets entre 1522 et 1526 octets.
Comme en Ethernet, qui peut le plus peut le moins, on recommande à nos abonnés de mettre 1600 de L2MTU, voilà tout

Personnellement je configure tout matériel qui passe dans mes mains en L2MTU 9216 (ou le max de l'interface le cas échéant), ça ne coute pas cher et ça évite des soucis dans le futur

kgersen · « **Réponse #5 le:** 18 octobre 2023 à 02:18:14 »

t'as essayé avec un serveur en bbr ?

Code: [Sélectionner]

curl -o /dev/null https://appliwave.testdebit.info/10G/10G.iso
ou (self pub) avec nspeed:

Code: [Sélectionner]

curl -o nspeed https://dl.nspeed.app/nspeed-client/preview/nspeed_linux_amd64_v1/nspeed
chmod +x nspeed
./nspeed from https://dl.nspeed.app/bbrcubic

a 2h du mat j'ai 280 Mbps avec proof.ovh.net et 6 Gbps avec appliwave...

bugmenot · « **Réponse #6 le:** 18 octobre 2023 à 11:27:51 »

Citation de: kgersen le 18 octobre 2023 à 02:18:14

t'as essayé avec un serveur en bbr ?

Bingo! En BBR j’ai des bien meilleures perfs, autour de 500Mbit/s. Une piste pour comprendre le problème.
Reste a comprendre pourquoi les perfs avec Cubic ou (New)Reno sont tellement en dessous de BBR. Je pensais que ca se jouait a quelques points de pourcentages.

En attendant je vais déjà pouvoir régler le souci pour le serveur que je contrôle en le passant en BBR. Dommage sous FreeBSD il faut recompiler pour ajouter BBR, pas par défaut, les devs FreeBSD ne sont pas trop chauds.

Code: [Sélectionner]


root@bpi:~# time wget -O /dev/null https://appliwave.testdebit.info/10G/10G.iso
Downloading 'https://appliwave.testdebit.info/10G/10G.iso'
Connecting to 2a05:46c0:100:1007::3:443
Writing to '/dev/null'
/dev/null            100% |*******************************|  9536M  0:00:00 ETA
Download completed (10000000000 bytes)
real    2m 30.45s
user    1m 55.13s
sys     0m 33.12s

kgersen · « **Réponse #7 le:** 18 octobre 2023 à 15:58:18 »

Citation de: bugmenot le 18 octobre 2023 à 11:27:51

Reste a comprendre pourquoi les perfs avec Cubic ou (New)Reno sont tellement en dessous de BBR. Je pensais que ca se jouait a quelques points de pourcentages.

C'est BBR qui n'est pas 'fair play' avec les autres du coup la ou passe BBR les autres souffrent (du moins quand y'a congestion, pertes, 'out of order', etc et que les buffers ou ca bouchonne sont petits sinon c'est l'inverse).

BBR est utilsé par Google , Cloudflare et bien d'autres gros providers du coup ceux qui ne sont pas en BBR en pâtissent.

des détails tech sur le probleme ici: https://blog.apnic.net/2020/01/10/when-to-use-and-not-use-bbr/

(sans parler ensuite des évolutions de BBRv1, BBRv2, BBRv3)

Le problème des algos de congestion TCP est qu'ils sont liés a la stack TCP qui est lié a l'OS et pas aux applications. Du coup l'utilisateur ou l'éditeur d'une application n'a souvent pas le contrôle la dessus et il y a le problème d'inertie des mises a jour des OS par les différents acteurs (certaines distro linux ne fournissent toujours BBR de base).

C'est pourquoi, entres autres raisons, que les gros acteurs, Google en tête, poussent QUIC pour remplacer TCP en dessous d'HTTP (et pas que). La on ne dépend plus de l'OS pour le contrôle de congestion, il est embarqué dans la stack QUIC qui est directement dans l'application. Les mises a jour et évolution sont bien plus rapides et faciles quand on contrôle les 2 applications a chaque bout sans pour autant contrôler les OS en dessous.

Ce point est crucial pour l'avenir de l'évolution du trafic: plus on supprime des intermédiaires, notamment ceux notoirement 'lents' à faire des maj, plus les évolutions seront rapides.

Du coup l'avenir d'Internet ca sera quasi que de l'UDP partout avec probablement des ilots de "trainards" qui seront toujours en TCP.

A ce jour, on est déjà a 30% pour QUIC donc pour UDP (du moins rapporter a la part d'HTTP dans le trafic total). (cf https://pulse.internetsociety.org/blog/why-http-3-is-eating-the-world pour plus d'infos)

bugmenot · « **Réponse #8 le:** 18 octobre 2023 à 18:36:30 »

Citation de: kgersen le 18 octobre 2023 à 15:58:18

C'est BBR qui n'est pas 'fair play' avec les autres du coup la ou passe BBR les autres souffrent (du moins quand y'a congestion, pertes, 'out of order', etc et que les buffers ou ca bouchonne sont petits sinon c'est l'inverse).

Et effectivement je pense qu’il y a un peu de congestion/perte qui pourrait expliquer mes soucis. J’ai refait des essais en UDP avec une bande passante de 500Mbit/s soit la moitié de mon débit théorique et j’ai de la perte surtout au début du test. Cela correspond aussi a la baisse de débit constatée sur les essais en TCP, on voit qu’il commence fort et réduit ensuite.
Download - on voit de la perte en UDP et mon débit TCP est mauvais

Code: [Sélectionner]

root@bpi:~# iperf3 -4 -c proof.ovh.net -p 5210 -R -V -u -b 500M
iperf 3.15
Linux bpi 5.15.134 #0 SMP Mon Oct 9 21:45:35 2023 aarch64
Control connection MSS 1440
Setting UDP block size to 1440
Time: Wed, 18 Oct 2023 16:30:54 UTC
Connecting to host proof.ovh.net, port 5210
Reverse mode, remote host proof.ovh.net is sending
      Cookie: pceq6vdh6sxkno5sxr7anltjm2rngdixdvne
      Target Bitrate: 500000000
[  5] local 109.190.106.43 port 57825 connected to 141.95.207.211 port 5210
Starting Test: protocol: UDP, 1 streams, 1440 byte blocks, omitting 0 seconds, 10 second test, tos 0
[ ID] Interval           Transfer     Bitrate         Jitter    Lost/Total Datagrams
[  5]   0.00-1.00   sec  59.7 MBytes   500 Mbits/sec  0.003 ms  1756/45197 (3.9%)  
[  5]   1.00-2.00   sec  59.6 MBytes   500 Mbits/sec  0.003 ms  8/43403 (0.018%)  
[  5]   2.00-3.00   sec  59.6 MBytes   500 Mbits/sec  0.003 ms  7/43403 (0.016%)  
[  5]   3.00-4.00   sec  59.6 MBytes   500 Mbits/sec  0.003 ms  9/43402 (0.021%)  
[  5]   4.00-5.00   sec  59.6 MBytes   500 Mbits/sec  0.003 ms  5/43403 (0.012%)  
[  5]   5.00-6.00   sec  59.6 MBytes   500 Mbits/sec  0.003 ms  9/43403 (0.021%)  
[  5]   6.00-7.00   sec  59.6 MBytes   500 Mbits/sec  0.008 ms  8/43404 (0.018%)  
[  5]   7.00-8.00   sec  59.6 MBytes   500 Mbits/sec  0.006 ms  7/43409 (0.016%)  
[  5]   8.00-9.00   sec  59.6 MBytes   500 Mbits/sec  0.003 ms  3/43418 (0.0069%)  
[  5]   9.00-10.00  sec  59.6 MBytes   500 Mbits/sec  0.005 ms  10/43407 (0.023%)  
- - - - - - - - - - - - - - - - - - - - - - - - -
Test Complete. Summary Results:
[ ID] Interval           Transfer     Bitrate         Jitter    Lost/Total Datagrams
[  5]   0.00-10.06  sec   600 MBytes   500 Mbits/sec  0.000 ms  0/0 (0%)  sender
[  5]   0.00-10.00  sec   596 MBytes   500 Mbits/sec  0.005 ms  1822/435849 (0.42%)  receiver

Upload - pas de perte en UDP et mon débit TCP est bon

Code: [Sélectionner]

root@bpi:~# iperf3 -4 -c proof.ovh.net -p 5210 -V -u -b 500M
iperf 3.15
Linux bpi 5.15.134 #0 SMP Mon Oct 9 21:45:35 2023 aarch64
iperf3: error - unable to connect to server - server may have stopped running or use a different port, firewall issue, etc.: Connection refused
root@bpi:~# iperf3 -4 -c proof.ovh.net -p 5209 -V -u -b 500M
iperf 3.15
Linux bpi 5.15.134 #0 SMP Mon Oct 9 21:45:35 2023 aarch64
Control connection MSS 1440
Setting UDP block size to 1440
Time: Wed, 18 Oct 2023 16:31:20 UTC
Connecting to host proof.ovh.net, port 5209
      Cookie: j5jwcd7pgdkombitifqi6hjspt4y2g2e2ymq
      Target Bitrate: 500000000
[  5] local 109.190.106.43 port 36590 connected to 141.95.207.211 port 5209
Starting Test: protocol: UDP, 1 streams, 1440 byte blocks, omitting 0 seconds, 10 second test, tos 0
[ ID] Interval           Transfer     Bitrate         Total Datagrams
[  5]   0.00-1.00   sec  59.6 MBytes   500 Mbits/sec  43391  
[  5]   1.00-2.00   sec  59.6 MBytes   500 Mbits/sec  43395  
[  5]   2.00-3.00   sec  59.6 MBytes   500 Mbits/sec  43405  
[  5]   3.00-4.00   sec  59.6 MBytes   500 Mbits/sec  43400  
[  5]   4.00-5.00   sec  59.6 MBytes   500 Mbits/sec  43389  
[  5]   5.00-6.00   sec  59.6 MBytes   500 Mbits/sec  43416  
[  5]   6.00-7.00   sec  59.6 MBytes   500 Mbits/sec  43414  
[  5]   7.00-8.00   sec  59.6 MBytes   500 Mbits/sec  43391  
[  5]   8.00-9.00   sec  59.6 MBytes   500 Mbits/sec  43396  
[  5]   9.00-10.00  sec  59.6 MBytes   500 Mbits/sec  43428  
- - - - - - - - - - - - - - - - - - - - - - - - -
Test Complete. Summary Results:
[ ID] Interval           Transfer     Bitrate         Jitter    Lost/Total Datagrams
[  5]   0.00-10.00  sec   596 MBytes   500 Mbits/sec  0.000 ms  0/434025 (0%)  sender
[  5]   0.00-10.06  sec   596 MBytes   497 Mbits/sec  0.033 ms  0/434002 (0%)  receiver
CPU Utilization: local/sender 65.5% (15.3%u/50.3%s), remote/receiver 0.1% (0.0%u/0.1%s)

bugmenot · « **Réponse #9 le:** 21 octobre 2023 à 11:03:10 »

Toujours pas mieux sur mes performances TCP download. Une analyse Wireshark montre effectivement des SACK (en rouge) et donc de la perte quelque part.

Un point que je n'ai pas mentionné dans mes précédents posts : ma commande chez OVH n'est pas totalement finalisée, il y a un couac entre l'installateur fibre et OVH qui n'a toujours pas reçu le rapport d'installation. Peut être que la finalisation de la commande entraine des changements (QOS, routage collecte ou je ne sais quoi) qui règleront le souci. On peut toujours rever

bugmenot · « **Réponse #10 le:** 03 janvier 2024 à 18:50:32 »

Après deux mois et demi de travail avec le support OVH nous avons eu le fin mot de l’histoire. Un SFP défectueux dans le réseau de collecte qui causait des pertes de paquets.

Ce que j’en retire:
- L’excellente qualité et bienveillance des interventions sur ce forum (et dans quelques messages privés), que ce soit pour des pistes techniques ou pour l’évocation fort intéressante de l’évolution des protocoles / mécanismes de gestion de la congestion.
- La ténacité du support OVH face a un opérateur de collecte / d’infrastructure pas des plus réactifs, sur un RIP connu pour être problématique
- L’empilage d’acteurs et de leurs sous traitants sur la chaîne opérateur commercial / collecte / infrastructure / RIP. Pas de vision bout en bout, communication par passage de tickets. Au final deux mois et demi d’escalades, 4 techniciens intervenus chez moi (pour rien), OLT changé 3 fois (aussi pour rien).
- Malheureusement aussi les limites de ce que l’opérateur commercial peut faire dans ce genre de situation.