La Fibre
Hébergeurs et opérateurs pro / entreprises => Hébergeurs et opérateurs pro / entreprises => OVH FAI => Discussion démarrée par: 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
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
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
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
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
-
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.
-
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 ?
-
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.
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 ?
-
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
-
t'as essayé avec un serveur en bbr ?
curl -o /dev/null https://appliwave.testdebit.info/10G/10G.iso
ou (self pub) avec nspeed:
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...
-
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.
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
-
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)
-
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
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
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)
-
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 :)
-
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.