Auteur Sujet: Algo de contrôle de la congestion TCP: BBR (Lu 64822 fois)

LROB · « **Réponse #144 le:** 18 mars 2024 à 00:54:14 »

Citation de: Fyr le 18 mars 2024 à 00:41:04

Et encore t'as pas vu la pile TCP de Netflix.

Je vois pas trop le souci avec ce que fait Netflix pour le coup, mais un détail m'échappe peut-être (l'article est super long, donc j'ai lu la partie sur TCP RACK Stack de Netflix), ça m'a l'air plutôt consciencieux au contraire.

Citation de: Fyr le 18 mars 2024 à 00:41:04

Sur un BSD pour lancer le BBR c'est easy.

https://groups.google.com/g/bbr-dev/c/bSvfbe9JQXI?pli=1

Le chacun sa poire ça va se calmer avec l'adoption de BBR comme ça ils se boufferont le nez entre eux.

Sous Debian c'est tout aussi simple (voir plus simple) :

Code: [Sélectionner]

modprobe tcp_bbr
sysctl net.core.default_qdisc=fq
sysctl net.ipv4.tcp_congestion_control=bbr

Pour rendre ça persistant et appliquer d'un coup :

Code: [Sélectionner]

echo "tcp_bbr" >> /etc/modules-load.d/bbr.conf
echo "net.core.default_qdisc=fq" >> /etc/sysctl.conf
echo "net.ipv4.tcp_congestion_control=bbr" >> /etc/sysctl.conf
modprobe tcp_bbr
sysctl -p

LROB · « **Réponse #145 le:** 19 mars 2024 à 02:03:35 »

Comme promis, différence d'upload de mon plus gros backup incrémental nocturne en Cubic (14.0Go) VS BBR (13.9Go) depuis Hetzner vers OVH FTTH.

On gagne environ 20-25Mbit/s et 10 secondes sur la durée du backup. Toujours bon à prendre, mais pas très intéressant sur ce cas spécifique.

Fyr · « **Réponse #146 le:** 19 mars 2024 à 12:02:37 »

Tu sais les algos de congestion ça marche... quand il y a de la congestion.

LROB · « **Réponse #147 le:** 19 mars 2024 à 12:56:54 »

On pourra voir après le 26 mars quand je serai chez Orange si c'était une limitation du serveur en upload (ce dont je doute car c'est du serveur 24 threads haute fréquence, 128Go de RAM, full SSD NVMe et liaison 1Gbit/s, donc ça ne peine pas à sortir du 900Mbit/s+ en théorie) ou bien d'OVH.

Edit: Après analyse des graphes du serveur source et cible, ni le CPU ni l'IO ne sont saturés (ni le réseau), ce qui laisse supposer que c'est bien le réseau qui bottleneck à 50% de la vitesse max théorique en direction Hetzner > OVH FTTH pour un envoi en FTPS passif.

LROB · « **Réponse #148 le:** 28 mars 2024 à 09:16:40 »

Comme promis, la vitesse de Hetzner vers Orange Pro FTTH en XGS-PON, toujours depuis un serveur 1G.

C'est le point de vue serveur, cette fois, et un backup bien plus gros (complet serveur, y'en a pour 666.25Go).
Comme on le voit, on sature en gros le gigabit avec une vitesse 2x plus rapide qu'avec OVH FTTH et ce sur toute la durée de l'upload.
Toujours en BBR du coup, je laisse mon serveur comme ça pour améliorer le débit vers mes clients ayant une interco pourrie (freenautes/20).

kgersen · « **Réponse #149 le:** 08 décembre 2024 à 01:18:27 »

pour info:

BBR2 est activable sur Windows 11 depuis quelques temps déja mais il pose des gros problemes de fonctionnement par moment. Notamment tout ce qui est trafic TCP sur l'interface loopback ('localhost').
J'ai mis un temps fou a trouver que c'est lui qui m'empêchait d'ouvrir une console hyper-vm (vmconnect) sur une vm par exemple...
Autre symptôme: débit sur localhost de quelques Mbps au lieu de plusieurs Gbps entre 2 iperf3 par exemple (ou nspeed ou un serveur web local et un navigateur).

Donc en attendant une maj officielle je déconseille vivement de l'activer sauf si la machine ne fait "que" serveur d'envoie vers Internet.

Code: [Sélectionner]

netsh int tcp set supplemental Template=Internet CongestionProvider=BBR2
Ok.

.\nspeed.exe b h1g

 #1| 125.5 Mbps|       0 bps| 8.00|   125.5 MB|           0 B|get http://[::1]:51282/20g (IPv6 - 0.0 ms - HTTP/1.1 - )

netsh int tcp set supplemental Template=Internet CongestionProvider=CUBIC
Ok.

.\nspeed.exe b h1g

 #1|  32.3 Gbps|       0 bps| 4.96|    20.0 GB|           0 B|get http://[::1]:51295/20g (IPv6 - 1.9 ms - HTTP/1.1 - )