La Fibre

Télécom => Réseau => reseau TCP/IP / Fonctionnement des réseaux => Discussion démarrée par: kgersen le 07 janvier 2020 à 16:56:33

Titre: Algo de contrôle de la congestion TCP: BBR
Posté par: kgersen le 07 janvier 2020 à 16:56:33
Hors sujet extrait de Serveur iperf3 chez Free (https://lafibre.info/1gb-free/serveur-iperf3-chez-free/)

ton client Linux a quoi comme controle de congestion TCP ?

pour l'afficher:

sudo sysctl net.ipv4.tcp_congestion_control

pour afficher les controles dispo:
sudo sysctl net.ipv4.tcp_available_congestion_control

en 2020, tout le monde devrait être en BBR mais pas mal de distro ne font pas l'effort de le mettre par défaut.

pour changer:

sudo sysctl net.ipv4.tcp_congestion_control=bbr
sudo sysctl net.core.default_qdisc=fq
(le qdisc est optionnel depuis le kernel 4.13 mais autant mettre fq dans des machines d'extrémités (serveur, client) plutot que fq_codel le défaut plutôt utile sur routeur).

il faudrait voir aussi coté serveur iperf ce qu'il y a comme réglages. si c'est les réglages par défaut d'une distro c'est pas forcement le mieux.

des tests récents que j'ai fais avec archlinux (client iperf3) et Debian (serveur iperf3) montraient pres de 100 Mbps d'écart entre les réglages par défaut des distros et bbr/fq.
Titre: BBR
Posté par: Fuli10 le 07 janvier 2020 à 17:27:29
Pour répondre à kgersen, sur un ubuntu server de base il n'y a que cubic et reno, cubic par défaut. Idem sur openWRT 19.07rc.
Autrement pas de tcp control sur IPv6 (ou du moins j'ai pas trouvé) et j'ai des resultats similaires. Et enfin je ne me suis jamais posé cette question chee Orange. J'ai toujours été au max (j'ai retenu 950 mais ça devait sûrement être moins).
Titre: Algo de controle de la congestion TCP: BBR
Posté par: kgersen le 07 janvier 2020 à 18:33:46
les options TCP sont communes IPv4/IPv6. Les sysctl de type "net.ipv4.tcp..." sont communs a IPv4 et IPv6. Oui c'est ambiguë et le sera plus encore quand on utilisera plus IPv4 ...

openwrt c'est un routeur donc pas concerné par bbr.

De toute facon c'est l'algo de congestion de l’émetteur qui compte donc du serveur pour le cas d'un download.

L'algo aide si la ligne est congestionné  ce qui n'était pas le cas avec Orange. Il est flagrant que y'a un souci chez Free mais ce n'est pas nouveau.
Titre: BBR
Posté par: vivien le 07 janvier 2020 à 21:33:35
Coté serveur, je suis en illinois

$ sysctl net.ipv4.tcp_congestion_control
net.ipv4.tcp_congestion_control = illinois

La protocole de congestion par défaut est cubic mais il est moins performant.
$ sysctl net.ipv4.tcp_congestion_control
net.ipv4.tcp_congestion_control = cubic

illinois est recomandé pour high-speed and long-distance networks
Titre: BBR
Posté par: kgersen le 07 janvier 2020 à 23:21:04
illinois est recomandé pour high-speed and long-distance networks

heu ca date un peu ton truc la  :P

recommandé par qui ?
Titre: Algo de controle de la congestion TCP: BBR
Posté par: esver le 08 janvier 2020 à 09:57:18
en 2020, tout le monde devrait être en BBR mais pas mal de distro ne font pas l'effort de le mettre par défaut.

Un gros gros merci !!!!
Avec curl sur test-debit.free.fr je passe de 15-20 à 50Mo/sec en upload !!!

Le graph Munin indique le changement
Titre: BBR
Posté par: Fuli10 le 08 janvier 2020 à 10:14:42
Merci kgersen !
J'ai fait un test avec bbr, et là direct 556Mbps en upload...
Du coup je ne comprend pas comment fait Orange pour ne pas avoir les mêmes problèmes de perf avec la configuration par défaut en cubic.
Idem je ne sais pas comment c'est géré côté windows (ils sont en wifi chez moi) mais je ne sais pas si c'est possible de changer l'algorithme ainsi dans windows.
Titre: BBR
Posté par: underground78 le 08 janvier 2020 à 10:18:28
Idem je ne sais pas comment c'est géré côté windows (ils sont en wifi chez moi) mais je ne sais pas si c'est possible de changer l'algorithme ainsi dans windows.
Ça m'intéresse pour Windows !
Titre: BBR
Posté par: willemijns le 08 janvier 2020 à 10:51:24
recommandé par qui ?

par les plus grandes marques de lave-linge, ca c'est bin vrai ! (blague de quadra voire plus !)

sinon
https://cloud.google.com/blog/products/gcp/tcp-bbr-congestion-control-comes-to-gcp-your-internet-just-got-faster
https://www.aplu.fr/v2/post/2017/07/24/augmenter-la-bande-passante-avec-tcp-bbr

Titre: BBR
Posté par: darkmoon le 08 janvier 2020 à 10:52:55
Ça m'intéresse pour Windows !

Vu que cela concerne des options du kernel linux, je ne pense pas que l'on puisse configurer ca dans Windows, mais je me trompe peut-être !
Titre: BBR
Posté par: underground78 le 08 janvier 2020 à 10:54:12
Il y a des options équivalentes sous Windows mais je ne suis pas sûr que l'algo BBR ait été implémenté.
Titre: BBR
Posté par: darkmoon le 08 janvier 2020 à 11:01:35
Sur mon windows 10 à jour j'ai 3 choix :
Utilisation : set global [[rss=]disabled|enabled|default]
             [[autotuninglevel=]
                disabled|highlyrestricted|restricted|normal|experimental]
             [[congestionprovider=]none|ctcp|default]

D'après quelques sites :
none: Use the built-in standard congestion control algorithm.
ctcp: Use the add-on Compound TCP congestion control algorithm.
default: Restore the selected provider to the system default.
Titre: Algo de controle de la congestion TCP: BBR
Posté par: Fuli10 le 08 janvier 2020 à 11:16:37
par les plus grandes marques de lave-linge, ca c'est bin vrai ! (blague de quadra voire plus !)

sinon
https://cloud.google.com/blog/products/gcp/tcp-bbr-congestion-control-comes-to-gcp-your-internet-just-got-faster
https://www.aplu.fr/v2/post/2017/07/24/augmenter-la-bande-passante-avec-tcp-bbr

Et sinon, pourquoi ça marche "out-of-the-box" chee Orange? Sans tripatouillage de congestion?
Titre: BBR
Posté par: Thornhill le 08 janvier 2020 à 11:32:58
Et sinon, pourquoi ça marche "out-of-the-box" chee Orange? Sans tripatouillage de congestion?

Peut-être parce que l'algo de congestion n'est utile qu'en cas de congestion.
Titre: Algo de controle de la congestion TCP: BBR
Posté par: vivien le 08 janvier 2020 à 11:58:26
illinois est recomandé pour high-speed and long-distance networks

heu ca date un peu ton truc la  :P

recommandé par qui ?

https://en.wikipedia.org/wiki/TCP-Illinois

BBR est bien récent je t'avoue ne pas l'avoir testé quand j'ai fait mon choix.

Je n'ai pas trouvé de comparatif mentionnant TCP-Illinois et BBR, donc je ne suis pas certain que BBR soit meilleur que TCP-Illinois (Ils sont tous les deux meilleurs que Cubic ou Reno)

Toutefois BBR a l'avantage d'être plus représentatif que TCP-Illinois du fait qu'il est utilisé par Google.

Je me demande pourquoi les distributions Linux restent sur Cubic comme algorithme de congestion TCP par défaut.

Je réfléchit pour changer, mais je suis preneur d'arguments.

Des opérateurs ont demandé plein d'optimisations pour les serveurs utilisés pour les tests Arcep pour les campagnes sur https://www.monreseaumobile.fr/, mais personne n'a demandé BBR.
Titre: Algo de controle de la congestion TCP: BBR
Posté par: kgersen le 08 janvier 2020 à 12:12:15
c'est juste que t'es le premier que je croise a parler d'Illinois et a utiliser Illinois... un truc de 2006 conçu avant Cubic donc ... c'est juste curieux. Je ne vois pas en quoi il est meilleur que Cubic d'ailleurs. Et par défaut quel distrib a Illinois inclus de base (juste inclus pas sélectionné)?
Titre: Algo de controle de la congestion TCP: BBR
Posté par: Thornhill le 08 janvier 2020 à 12:13:04
Dans certains cas d'usages, BBR fait moins bien que Cubic, cf https://blog.apnic.net/2019/11/01/bbr-evaluation-at-a-large-cdn/ (https://blog.apnic.net/2019/11/01/bbr-evaluation-at-a-large-cdn/)

Based on these findings, we concluded that for our traffic patterns, it is better to use Cubic for intra-PoP and PoP-to-PoP communications where RTTs and loss are low. For client-side traffic, it is worth using BBR.

Peut-être la raison pour laquelle BBR n'est pas sélectionné par défaut.

Titre: Algo de controle de la congestion TCP: BBR
Posté par: vivien le 08 janvier 2020 à 12:50:18
c'est juste que t'es le premier que je croise a parler d'Illinois et a utiliser Illinois... un truc de 2006 conçu avant Cubic donc ... c'est juste curieux. Je ne vois pas en quoi il est meilleur que Cubic d'ailleurs. Et par défaut quel distrib a Illinois inclus de base (juste inclus pas sélectionné)?

nPerf comme SpeedTest d'Ookla conseillent de changer le protocole de congestion TCP Cubic pour TCP-Illinois

"For high throughput testing increasing TCP send/receive buffer sizes and using a more aggressive TCP congestion control algorithm such as ILLINOIS can improve performance."
Source : https://support.ookla.com/hc/en-us/articles/360017436132-Server-Performance

"Using TCP Illinois module can improve speed by managing congestion diffrently."
Source : https://wiki.nperf.com/nperf-server/tcp-stack-tuning
Titre: Algo de controle de la congestion TCP: BBR
Posté par: Breizh29 le 08 janvier 2020 à 12:54:01
Tiens... faudrait que je m'intéresse à cet algo sur MacOS aussi alors...
Titre: Algo de controle de la congestion TCP: BBR
Posté par: esver le 08 janvier 2020 à 14:03:56
Je viens de faire des tests rapide avec curl sur test-debit.free.fr sur ma connexion mini 4k (ZMD AMII Orange) :
ubuntu@ubuntu:~$ sudo sysctl net.core.default_qdisc=fq
net.core.default_qdisc = fq

ubuntu@ubuntu:~$ sudo sysctl net.ipv4.tcp_congestion_control=cubic
net.ipv4.tcp_congestion_control = cubic

ubuntu@ubuntu:~$ curl -6 -o /dev/null -F "filecontent=@1048576.rnd" test-debit.free.fr
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 1024M  100   196  100 1024M      2  14.0M  0:01:38  0:01:12  0:00:26 16.7M

ubuntu@ubuntu:~$ sudo sysctl net.ipv4.tcp_congestion_control=illinois
net.ipv4.tcp_congestion_control = illinois

ubuntu@ubuntu:~$ curl -6 -o /dev/null -F "filecontent=@1048576.rnd" test-debit.free.fr
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 1024M  100   196  100 1024M      3  16.7M  0:01:05  0:01:01  0:00:04 25.9M

ubuntu@ubuntu:~$ sudo sysctl net.ipv4.tcp_congestion_control=bbr
net.ipv4.tcp_congestion_control = bbr

ubuntu@ubuntu:~$ curl -6 -o /dev/null -F "filecontent=@1048576.rnd" test-debit.free.fr
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 1024M  100   196  100 1024M      9  51.3M  0:00:21  0:00:19  0:00:02 51.5M

Donc chez moi, pour ce type de test il n'y a pas photo ! illinois est à peine mieux que cubic et bbr marche parfaitement.
Titre: Algo de controle de la congestion TCP: BBR
Posté par: vivien le 08 janvier 2020 à 15:09:35
Je confirme, c'est bien TCP-Illinois qui a été demandé il y a quelques années et qui est toujours d'actualité sur les serveur de test de débit des prestataires de l'Arcep pour les tests sur le mobile (Rapport Arcep QOS Mobile 2019: Orange 1er, Bytel 2ème, SFR 3ème Free 4ème (https://lafibre.info/qos-mobile/rapport-arcep-qos-mobile-2019-orange-1er-bytel-2eme-sfr-3eme-free-4eme/))
Titre: Algo de controle de la congestion TCP: BBR
Posté par: munsternet le 08 janvier 2020 à 15:39:42
A noter que BBR est "connu" pour bouffer toute la bande passante sur un lien congestionné au détriment d'autres implémentations (Cubic, Compound etc...)

Il y'a un bel article sur le blog de Dropbox à propos de ça et du pourquoi il y'a un BBRv2 dans les tuyaux:

https://blogs.dropbox.com/tech/2019/12/evaluating-bbrv2-on-the-dropbox-edge-network/
Titre: Algo de controle de la congestion TCP: BBR
Posté par: underground78 le 08 janvier 2020 à 20:04:53
Sur mon windows 10 à jour j'ai 3 choix :
En fait tu en as plus que ça avec "netsh int tcp set supplemental Internet congestionprovider=<algo>". Par défaut chez moi ça semble être cubic, tu peux aussi mettre ctpt, dctpt et newreno.
Titre: Algo de controle de la congestion TCP: BBR
Posté par: kgersen le 08 janvier 2020 à 21:00:00
A noter que BBR est "connu" pour bouffer toute la bande passante sur un lien congestionné au détriment d'autres implémentations (Cubic, Compound etc...)

Il y'a un bel article sur le blog de Dropbox à propos de ça et du pourquoi il y'a un BBRv2 dans les tuyaux:

https://blogs.dropbox.com/tech/2019/12/evaluating-bbrv2-on-the-dropbox-edge-network/

Dans certains cas c'est l'inverse. Ca dépend des conditions et circontances, d'ailleurs l'article cité dans le blog de Dropbox conclu le contraire (c'est BBR qui souffre dans un monde ou Cubic domine).

D'ailleurs Illinois a les memes soucis que BBR vis a vis de Cubic , tout les hybrides (BBR, Illinois) l'ont. C'est juste que quand Google utilise un algo hybride ca se voit sur le Net tellement y'a du volume  ;D

Le souci c'est que peu de gens s'éduquent correctement sur ces sujets, peu lisent les articles et les études (j'admet que TCP c'est déjà complexe et les algo de congestion encore plus).

La majorité dépend donc des réglages par défaut de leur distro/OS ou suivent l'influence de quelqu'un d'autre parce que 'c'est marqué sur son blog ou ses recommendations' sans pourtant ce poser la question de savoir si c'est adapté, si ses recos sont scientifiquement fondées ou de quelle époque elles sont ou si elles conviennent a son cas d'usage  ;D

Titre: Algo de controle de la congestion TCP: BBR
Posté par: vivien le 08 janvier 2020 à 21:21:13
Depuis 21h15, j'ai passé le serveur paris.testdebit.info (qui correspond au serveur utilisé par les clients Free quand ils utilisent le nom de domaine anycast bouygues.testdebit.info) en BBR

$ sysctl net.ipv4.tcp_congestion_control
net.ipv4.tcp_congestion_control = bbr


Pour répondre à kgersen, sur un ubuntu server de base il n'y a que cubic et reno, cubic par défaut. Idem sur openWRT 19.07rc.

Non, Ubuntu en propose plein, mais la commande sysctl net.ipv4.tcp_available_congestion_control ne liste que reno cubic + ceux qui sotn en cours d'utilisation.

Bref, pour passer à BBR (ou un autre), il n'y a rien à installer avec Ubuntu 18.04 ou plus récent (c'est  bon aussi avec Ubuntu 16.04 à condition de prendre le Kernel 4.15)
Titre: Algo de controle de la congestion TCP: BBR
Posté par: kgersen le 08 janvier 2020 à 21:24:07
Depuis 21h15, j'ai passé le serveur paris.testdebit.info (qui correspond au serveur utilisé par les clients Free quand ils utilisent le nom de domaine anycast bouygues.testdebit.info) en BBR

T'es en IPerf 3.7 car y'a plein de bugs dans les versions d'avant quand meme.
Titre: Algo de controle de la congestion TCP: BBR
Posté par: vivien le 08 janvier 2020 à 21:26:24
Non, je suis sur un vieux iPerf, mais c'est dans ma todo liste de changer d'iPerf coté serveur.

Il y a aussi le noyau Linux 5.3 qui va être déployé dans quelques jours sur Ubuntu 18.04.
Titre: Algo de controle de la congestion TCP: BBR
Posté par: underground78 le 08 janvier 2020 à 21:31:16
J'ai l'impression qu'il y a un soucis, en tout cas je n'arrive plus à faire de tester en utilisant l'adresse bouygues.iperf.fr
Titre: Algo de controle de la congestion TCP: BBR
Posté par: vivien le 08 janvier 2020 à 22:02:42
Le port est déjà occupé ? Un seul test peut être fait simultanément sur chaque port.

Les ports en écoute sont 5200 à 5209, il ne faut pas hésiter à tester un autre port.
Titre: Algo de controle de la congestion TCP: BBR
Posté par: underground78 le 08 janvier 2020 à 22:20:07
Fausse alerte, visiblement j'ai juste pas eu de chance, j'ai essayé à plusieurs reprises sur 5 min environ mais toujours sur le même port (pas celui par défaut) et ça n'a jamais fonctionné.
Titre: Algo de controle de la congestion TCP: BBR
Posté par: vivien le 09 janvier 2020 à 14:50:11
Depuis 14h44, j'ai passé le serveur paris.testdebit.info (qui correspond au serveur utilisé par les clients Free quand ils utilisent le nom de domaine anycast bouygues.testdebit.info / bouygues.iperf.fr) en cubic

$ sysctl net.ipv4.tcp_congestion_control
net.ipv4.tcp_congestion_control = cubic

- avant 8 janvier 21h15 => illinois
- entre 8 janvier 21h15 et 9 janvier 14h44 => bbr
- depuis 14h44 => cubic (algorithme par défaut)

BBR a fait chuter fortement les débits, comparés à Illinois :
(https://lafibre.info/images/free_debit/202001_free_debit_illinois_vs_bbr.png)
Titre: Algo de controle de la congestion TCP: BBR
Posté par: kgersen le 09 janvier 2020 à 16:44:22
BBR a fait chuter fortement les débits, comparés à Illinois :

on a d'autres exemples ? ou tu conclus sur un seul cas, un Mac qui plus est ?
Titre: Algo de controle de la congestion TCP: BBR
Posté par: kgersen le 09 janvier 2020 à 17:07:18
ps: avec IPerf3  v3.7 le client peut specifier l'algo a utiliser avec l'option -C.
Ca permet donc de faire des tests sans changer a chaque fois le mode par défaut du serveur (cubic étant généralement le défaut autant le laisser). Faut juste mettre a jour ton binaire IPerf.
Titre: Algo de controle de la congestion TCP: BBR
Posté par: Fyr le 10 janvier 2020 à 15:34:24
Blog de l'APNIC suite à une conf Google "When to use and not use BBR" https://blog.apnic.net/2020/01/10/when-to-use-and-not-use-bbr/ (https://blog.apnic.net/2020/01/10/when-to-use-and-not-use-bbr/)

En gros en dessous de 100Mbs de bande passante et 75ms de RTT : aucun intérêt. On atteint les 10% de bénéfice au dessus de 250Mbs et 150ms de RTT.

Le paragraphe sur la cohabitation BBR/Cubic est intéressant.
Titre: Algo de controle de la congestion TCP: BBR
Posté par: kgersen le 10 janvier 2020 à 16:12:51

En gros en dessous de 100Mbs de bande passante et 75ms de RTT : aucun intérêt. On atteint les 10% de bénéfice au dessus de 250Mbs et 150ms de RTT.


tu sort d'ou ces chiffres ? on en trouve aucune trace/mention ni dans le blog, ni l'article ni la conf.

Ensuite quel conf Google ?

C'est une étude indépendante fait dans un labo avec IPerf3 ("640 iperf3 experiments in our LAN network") et présentée a l'ICM' 19 (sponsorisée par Facebook principalement).
Google a des millions de serveurs, des milliards de clients, sur la planète entière et pourtant continu d'utiliser BBR.

Les conclusions de l'étude:

Citer
Takeaways:
 - In terms of goodput, BBR is well suited for networks with shallow buffers, despite its high retransmissions
 - Unfairness between BBR and Cubic depends on the bottleneck buffer size
 - The maximum pacing_gain parameter is the root cause for the goodput “cliff point”

"suited for networks with shallow buffers" me semble le point important d'ailleurs c'est pour cela que BBR a été concu a l'origine. duh

L'article suivant dans la conf, https://conferences.sigcomm.org/imc/2019/presentations/p282.pdf, me semble plus intéressant et pointu d'ailleurs.
Titre: Algo de controle de la congestion TCP: BBR
Posté par: Fyr le 10 janvier 2020 à 17:09:26
tu sort d'ou ces chiffres ? on en trouve aucune trace/mention ni dans le blog, ni l'article ni la conf.

Le tableau

Titre: Algo de controle de la congestion TCP: BBR
Posté par: Thornhill le 10 janvier 2020 à 17:30:18
En gros en dessous de 100Mbs de bande passante et 75ms de RTT : aucun intérêt. On atteint les 10% de bénéfice au dessus de 250Mbs et 150ms de RTT.

Plutôt 110% de bénéfice.
Titre: Algo de controle de la congestion TCP: BBR
Posté par: Fyr le 10 janvier 2020 à 17:33:14
Plutôt 110% de bénéfice.

Tout à fait, ils atteignent 115% sur le palier 200 ms de RTT et 500Mbs
Titre: Algo de controle de la congestion TCP: BBR
Posté par: kgersen le 10 janvier 2020 à 19:10:44
Le tableau

c'est le goodput relatif a cubic... pas absolu... donc quasi tout le temps bbr est meilleur sauf la case en 'bleue' a -12%
Titre: Algo de controle de la congestion TCP: BBR
Posté par: Fyr le 10 janvier 2020 à 21:09:31
c'est le goodput relatif a cubic... pas absolu... donc quasi tout le temps bbr est meilleur sauf la case en 'bleue' a -12%

Oui voilà, c'est équivalent à l'algo Cubic, et ca devient significativement meilleur à partir d'un certain palier de RTT/débit. Et au moins un cas où c'est moins bon.
Titre: Algo de controle de la congestion TCP: BBR
Posté par: vivien le 22 janvier 2020 à 10:36:51
Comparaison Cubic / BBR réalisée sur une ligne Free FTTH en monothread et multithread.

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 : Mac mini (Core i7-8700B 6 cœurs / 12 threads 3,2 GHz / 4,6 Ghz en boost PDT 65watts, 32 Go mémoire, 1 To SSD, macOS 10.15.2 - équipé d’un chip Aquantia AQC107)

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)

OS Serveur : Ubuntu server 18.04 LTS avec Kernel 5.3 avec taille de buffer max de 16 Mo.
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


OS Client : Mac OS
Optimisation réaisée sur le mac le 19/01/2020 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
Titre: Algo de controle de la congestion TCP: BBR
Posté par: vivien le 24 janvier 2020 à 13:44:29
Les versions récentes d'iPerf3 permettent de sélectionner un autre a "tcp_congestion_contro"

Est-il nécessaire de le rajouter dans "tcp_allowed_congestion_control" si bbr n'est pas l'algorithme par défaut ?

Je vais rester en cubic pour le "tcp_congestion_contro" par défaut.
"tcp_allowed_congestion_control"  ne contient que reno et cubic sous Ubuntu.

Faut-il rajouter une ligne
net.ipv4.tcp_allowed_congestion_control =bbr
dans mon fichier /etc/sysctl.d/90-server-optimization.conf ?

$ cat /proc/sys/net/ipv4/tcp_congestion_control
cubic

$ cat /proc/sys/net/ipv4/tcp_allowed_congestion_control
reno cubic
Titre: Algo de controle de la congestion TCP: BBR
Posté par: kgersen le 24 janvier 2020 à 17:58:21
tcp_allowed_congestion_control concerne uniquement les process non privilégiés (non root ou sans le droit CAP_NET_ADMIN).

C'est la liste des reglages  de congestion qu'ils ont droits de demander au kernel pour leur flux.

Si ton process tourne en root ou a CAP_NET_ADMIN alors il peut choisir ce qu'il y a dans tcp_available_congestion_control sinon il est limité a tcp_allowed_congestion_control.
Titre: Algo de controle de la congestion TCP: BBR
Posté par: vivien le 24 janvier 2020 à 18:19:12
Intéressant.

Je ne laisse pas tourner iPerf en root.

Pour CAP_NET_ADMIN pour ne pas devoir le remettre à chaque mise à jour du binaire ?

Regarde mon tutoriel pour Wireshark, la seulle solution que j'ai trouvé à l'époque c'est de réappliquer
setcap cap_net_raw,cap_net_admin=eip /usr/bin/dumpcap

A chaque démarrage de linux.

Utiliser Wireshark sous Linux, sans les droits "root"

Si vous démarrez Wireshark sous Linux sans les droits root, vous pouvez ouvrir des fichiers mais impossible de faire des captures.

Il n'est pas conseillé de démarrer Wireshark avec les droits root !
Une faille dans le logiciel pourrait avoir de lourdes conséquences.

La solution ?

Donner les droits à l’utilisateur courant de réaliser une capture après s'être déconnecté / reconnecté.

Copiez / collez ces 4 lignes dans un terminal, en remplacent VOTRE_LOGIN par votre login utilisateur :
sudo addgroup -quiet -system wireshark
sudo chown root:wireshark /usr/bin/dumpcap
sudo setcap cap_net_raw,cap_net_admin=eip /usr/bin/dumpcap
sudo usermod -a -G wireshark VOTRE_LOGIN


L'utilisateur mentionné peut maintenant réaliser des captures.


Par contre, lors des mises à jour de Wireshark, l’exécutable /usr/bin/dumpcap est modifié, ce qui fait perdre les droits.

Le plus simple consiste à rajouter les droits à chaque démarrage du PC en éditant le fichier /etc/rc.local :

Dnas une ligne de commande tapez : sudo nano /etc/rc.local
Et rajoutez la ligne setcap cap_net_raw,cap_net_admin=eip /usr/bin/dumpcap après #!/bin/sh -e et avant exit 0

Un exemple de fichier /etc/rc.local :

#!/bin/sh -e

setcap cap_net_raw,cap_net_admin=eip /usr/bin/dumpcap

exit 0
Titre: Algo de controle de la congestion TCP: BBR
Posté par: kgersen le 24 janvier 2020 à 18:29:49
modifier  tcp_allowed_congestion_control plutot que donner cap_net_admin a iperf3  me parait plus simple et sur.
Titre: Algo de controle de la congestion TCP: BBR
Posté par: vivien le 24 janvier 2020 à 21:01:53
C'est lequel des dossier qui me donne la bonne liste des alogo disponibles ?

Dans chacune des deux liste il y en a qui sont en "exclusivité", ceux que j'ai mis en gras.

$ ls -1 /lib/modules/5.3.0-26-generic/kernel/net/ipv4 | grep tcp
tcp_bbr.ko => BBR (Google 2016) => https://en.wikipedia.org/wiki/TCP_congestion_control#TCP_BBR
tcp_bic.ko => BIC https://en.wikipedia.org/wiki/BIC_TCP
tcp_cdg.ko => CAIA Delay-Gradient https://en.wikipedia.org/wiki/Delay-gradient_congestion_control
tcp_dctcp.ko => Data Center TCP https://www.bortzmeyer.org/8257.html
tcp_diag.ko
tcp_highspeed.ko => High Speed https://en.wikipedia.org/wiki/HSTCP
tcp_htcp.ko => H-TCP Hamilton TCP https://en.wikipedia.org/wiki/H-TCP
tcp_hybla.ko => Hybla https://en.wikipedia.org/wiki/TCP_congestion_control#TCP_Hybla
tcp_illinois.ko => Illinois https://en.wikipedia.org/wiki/TCP-Illinois
tcp_lp.ko => TCP-LP Low-priority https://users.cs.northwestern.edu/~akuzma/rice/TCP-LP/
tcp_nv.ko => TCP-NV New Vegas https://docs.google.com/document/d/1o-53jbO_xH-m9g2YCgjaf5bK8vePjWP6Mk0rYiRLK-U
tcp_scalable.ko => Scalable https://en.wikipedia.org/wiki/Scalable_TCP
tcp_vegas.ko => Vegas https://en.wikipedia.org/wiki/TCP_Vegas
tcp_veno.ko => Veno https://www.ie.cuhk.edu.hk/fileadmin/staff_upload/soung/Journal/J3.pdf
tcp_westwood.ko => Westwood https://en.wikipedia.org/wiki/TCP_Westwood
tcp_yeah.ko => YeAH http://www.csc.lsu.edu/~sjpark/cs7601/4-YeAH_TCP.pdf

$ ls -1 /usr/src/linux-headers-5.3.0-26-generic/include/config/tcp/cong
advanced.h
bbr.h
bic.h
cdg.h
cubic.h
dctcp.h
hstcp.h
htcp.h
hybla.h
illinois.h
lp.h
nv.h
scalable.h
vegas.h
veno.h
westwood.h
yeah.h
Titre: Algo de controle de la congestion TCP: BBR
Posté par: kgersen le 24 janvier 2020 à 21:44:21
Chaque distrib a ses modules dynamiques:
ls -l /lib/modules/$(uname -r)/kernel/net/ipv4/tcp_*

les .ko sont les algos chargeables dans le kernel.

ou des modules inclus directement le kernel:
cat /lib/modules/$(uname -r)/modules.builtin | grep ipv4/tcp
les algo chargés (en mémoire) sont visibles dans: tcp_available_congestion_control (ou via lsmod) mais un process qui a les droits (root ou cap) peut demander n'importe quel algo dont le module est dispo. ca fera un chargement dynamique.

donc tcp_available_congestion_control ne reflète pas tout ce qui est possible si le chargement dynamique de module est permis.

Au besoin tu peux blacklister  (https://wiki.archlinux.org/index.php/Kernel_module#Blacklisting)des modules et en pré-charger au boot (dans /etc/modules-load.d/modules.conf)

Titre: Algo de controle de la congestion TCP: BBR
Posté par: vivien le 25 janvier 2020 à 12:15:07
Finalement je ne pense pas proposer tous les algorithmes d'évitement de congestion.

Ceux qui sont pertinents pour avoir de hauts débits et comparer avec le legacy sont :

- Cubic (algorithme par défaut sous Linux)
- BBR, le dernier né de Google
- H-TCP Hamilton TCP https://en.wikipedia.org/wiki/H-TCP
- Illinois https://en.wikipedia.org/wiki/TCP-Illinois
- Reno (lui il est déjà mis à disposition par défaut sous Linux)

Vous en voyez d'autres à mettre a disposition dans tcp_allowed_congestion_control ?
Titre: Algo de controle de la congestion TCP: BBR
Posté par: vivien le 25 janvier 2020 à 16:06:39
Pour faire la chose proprement, j'ai crée un fichier /etc/modules-load.d/tcp_allowed_congestion_control.conf dans lequel je charge les 3 algorithme à proposer.

sudo nano /etc/modules-load.d/tcp_allowed_congestion_control.conf
# TCP congestion control protocol
# cat /proc/sys/net/ipv4/tcp_allowed_congestion_control
tcp_bbr
tcp_htcp
tcp_illinois

Mais dans les 3 charcgés, seul bbr est disponible.

$ cat /proc/sys/net/ipv4/tcp_congestion_control
cubic
$ cat /proc/sys/net/ipv4/tcp_allowed_congestion_control
reno cubic bbr


Pourtant, les fichiers .ko sont bien présents :

# locate tcp_bbr
/lib/modules/5.3.0-24-generic/kernel/net/ipv4/tcp_bbr.ko
/lib/modules/5.3.0-26-generic/kernel/net/ipv4/tcp_bbr.ko

# locate tcp_htcp
/lib/modules/5.3.0-24-generic/kernel/net/ipv4/tcp_htcp.ko
/lib/modules/5.3.0-26-generic/kernel/net/ipv4/tcp_htcp.ko

# locate tcp_illinois
/lib/modules/5.3.0-24-generic/kernel/net/ipv4/tcp_illinois.ko
/lib/modules/5.3.0-26-generic/kernel/net/ipv4/tcp_illinois.ko
Titre: Algo de controle de la congestion TCP: BBR
Posté par: vivien le 25 janvier 2020 à 17:16:03
ESnet a réalisé un document sur les optimisations pour les premiers serveurs qui ont des cartes Ethernet 100 Gb/s.

Le document date de septembre 2016 :
(cliquez sur la miniature ci-dessous - le document est au format PDF)
(https://lafibre.info/testdebit/linux/201609_esnet_100g_tuning.png) (https://lafibre.info/testdebit/linux/201609_esnet_100g_tuning.pdf)

On voit pas mal de choses intéressantes sur les apports d'un kernel récent et une comparaison CentOS 7 vs CentOS 6 (sur un serveur 10 Gb/s) :
(https://lafibre.info/testdebit/linux/201609_esnet_100g_tuning_1.png)

(https://lafibre.info/testdebit/linux/201609_esnet_100g_tuning_2.png)

BBR est évoqué :

(https://lafibre.info/testdebit/linux/201609_esnet_100g_tuning_3.png)
Titre: Algo de controle de la congestion TCP: BBR
Posté par: vivien le 06 février 2020 à 07:52:49
Je viens de passer ce matin le serveur LaFibre.info, qui héberge également le test de débit mono-connexion de QoSi 5GMark en BBR pour voir l'impact.

$ cat /proc/sys/net/ipv4/tcp_congestion_control
bbr
Titre: Algo de controle de la congestion TCP: BBR
Posté par: vivien le 14 février 2020 à 20:47:59
J'ai déjà publié un comparatif de BBR avec Cubic.

Les résultats sont sans appels : en mono-connexion BBR est presque systématiquement devant Cubic.

Je rajoute un autre exemple avec le débit Upload sur une Freebox :

- Cubic : 76.1 Mb/s
- BBR : 503 Mb/s

Sur cet exemple, BBR permet de multiplier par 6,6 les débits !


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

Avec de multi-connexion en parallèle, les débits de BBR sont souvent largement inférieurs à Cubic, comme le montre le comparatif ci-dessous (débit exprimés en Gb/s) :

(https://lafibre.info/images/free_debit/202001_comparatif_bubic_bbr_3.png)
Titre: Algo de controle de la congestion TCP: BBR
Posté par: vivien le 14 février 2020 à 20:55:44
Il manque par contre un comparatif Cubic / BBR / Illinois.

J'ai exploité les tests Breizh29. Il était difficile de tirer une conclusion avec les graphiques car on a eu des coupures a plusieurs moment (panne Free puis pb du coté de mon serveur) et surtout le trafic le week-end est plus important et il est difficile de comparer une courbe de semaine avec une courbe du week-end.

J'ai donc supprimé les données du week-end et j'ai mis ça sur 24 heures (tous les tests avec un même protocole de congestion TCP et une même tranche horaire sont moyennés).
J'ai supprimé les données avant le 19 janvier vu qu'il y avait des modification de configuration.

Voici ce que cela donne pour 16 connexions TCP en parallèle.
Cubic est clairement le meilleur algorithme de congestion TCP pour ce type de test.


(https://lafibre.info/images/free_debit/202002_tcp_congestion_control_multi-connexion_1.png)

(https://lafibre.info/images/free_debit/202002_tcp_congestion_control_multi-connexion_2.png)
Titre: Algo de controle de la congestion TCP: BBR
Posté par: vivien le 14 février 2020 à 20:57:42
Là où c'est plus intéressant, c'est pour les tests sur une seule connexion TCP, plus représentatif de ressenti réel d'un internaute.

Sans surprise, BBR est le meilleur algorithme de congestion TCP.

Illinois semble avoir une petite avance sur Cubic.


(https://lafibre.info/images/free_debit/202002_tcp_congestion_control_mono-connexion_1.png)

(https://lafibre.info/images/free_debit/202002_tcp_congestion_control_mono-connexion_2.png)
Titre: Algo de controle de la congestion TCP: BBR
Posté par: vivien le 14 février 2020 à 21:00:02
Autre représentation avec d'autres couleurs.

IPv4 est en pointillé et IPv6 en trait plein.
On voit un petit gain de débit en IPv6, vs IPv4.

BBR est en rouge
Cubic est en vert
Illinois est en violet


(https://lafibre.info/images/free_debit/202002_tcp_congestion_control_multi-connexion_3.png)

(https://lafibre.info/images/free_debit/202002_tcp_congestion_control_mono-connexion_3.png)
Titre: Algo de controle de la congestion TCP: BBR
Posté par: vivien le 14 février 2020 à 21:05:19
Autre représentation graphique des données avec le 1er tiers du graphique qui concerne BBR, le second Cubic et enfin Illinois sur le dernier tiers.

Les tests multi-connexions sont en violet (IPv6) et vert (IPv4)
Les tests mono-connexion sont en rouge (IPv6) et bleu (IPv4)


(https://lafibre.info/images/free_debit/202002_tcp_congestion_control.png)
Titre: Algo de controle de la congestion TCP: BBR
Posté par: vivien le 16 février 2020 à 15:39:18
Petit graphique proposé par Google pour comparer BBR à Cubic :

(https://lafibre.info/testdebit/linux/202002_google_tcp_bbr.gif)
Titre: Algo de controle de la congestion TCP: BBR
Posté par: vivien le 16 février 2020 à 15:41:02
Test réalisés par Andree Toonk (@atoonk) en simulant la latence et les pertes de paquets sur Ubuntu, avec iPerf pour tester le débit :
(https://lafibre.info/testdebit/linux/202002_comparaison_reno_cubic_westwood_bbr.png)
Source : Medium.com (https://medium.com/@atoonk/tcp-bbr-exploring-tcp-congestion-control-84c9c11dc3a9), le 15 février 2020
Titre: Algo de controle de la congestion TCP: BBR
Posté par: vivien le 16 février 2020 à 15:58:30
Geoff Huston, le scientifique en chef de l'APNIC, le registre Internet régional desservant la région Asie-Pacifique (équivalent du Ripe pour l'Europe) a fait une étude sur BBR.

Google rapporte des expériences qui montrent que les flux simultanés de BBR et de CUBIC s'équilibreront approximativement, CUBIC obtenant une part un peu plus grande de la ressource disponible, mais pas de manière scandaleuse. Il indique une conclusion raisonnable que BBR peut coexister dans un monde TCP RENO / CUBIC sans perdre ou dominer complètement tous les autres flux TCP.

Nos expériences limitées à ce jour indiquent une conclusion quelque peu différente. L'expérience était sous la forme d'un test 1: 1 avec des flux CUBIC et Reno simples simultanés passés sur un circuit de 10,2 Mbps RTT non encombré de 15,2 ms. CUBIC a été lancé initialement, et au point 20 secondes, une session BBR a été lancée entre les deux mêmes points de terminaison. L'algorithme de démarrage initial de BBR repousse CUBIC à un point où il semble incapable de rétablir une part équitable contre BBR. Il s'agit d'un résultat quelque peu inattendu, mais qui peut illustrer un résultat dans lequel les tailles de tampon interne sont bien inférieures au produit de bande passante de retard du circuit de goulot d'étranglement.


(https://lafibre.info/testdebit/linux/202002_geoff_huston_partage_bbr_cubic_1.png)

La deuxième expérience a utilisé un chemin RTT de 298 ms sur une grande étendue d'Internet entre des nœuds d'extrémité situés en Allemagne et en Australie. Il s'agit d'un chemin Internet standard à travers les FAI commerciaux, comme on pourrait s'y attendre sur Internet. Ce ne sont pas les deux seuls flux qui existent sur les 16 liaisons de composant vers l'avant et 21 dans ce chemin étendu, de sorte que les deux sessions TCP ne rivalisent pas seulement pour les ressources réseau sur toutes ces liaisons, mais rivalisent également avec cross trafic sur chaque lien de composant. Là encore, BBR semble mieux réussir à revendiquer des ressources de chemin et à les défendre contre d'autres flux pendant la durée de la session BBR.

(https://lafibre.info/testdebit/linux/202002_geoff_huston_partage_bbr_cubic_2.png)

C'est peut-être un résultat moins surprenant, dans la mesure où le RTT étendu a apparemment posé quelques problèmes pour CUBIC, tandis que BBR a été en mesure de maintenir son estimation de la bande passante du chemin pendant cette période. Ces résultats indiquent un certain niveau de coexistence entre BBR et CUBIC, mais le résultat semble biaisé pour que BBR gagne la plus grande part de la capacité du chemin.

Source : potaroo.net (http://www.potaroo.net/ispcol/2017-05/bbr.html), article datant de mai 2017 traduit rapidement en Français.
Titre: Algo de controle de la congestion TCP: BBR
Posté par: vivien le 16 février 2020 à 22:11:37
DropBox a fait des tests avec BBR en 2017 qui montrent une augmentation des vitesses de téléchargement de fichiers

Nous observons une augmentation de la vitesse à tous les centiles.

Expérience TCP BBR de 6 heures sur le POP de Tokyo :
(https://lafibre.info/testdebit/linux/201709_dropbox_tcp_bbr_experimentation.png)

axe x : temps
axe y : vitesse de téléchargement du client


Source : Blog Dropbox (https://blogs.dropbox.com/tech/2017/09/optimizing-web-servers-for-high-throughput-and-low-latency/), article du 6 septembre 2017
Titre: Algo de controle de la congestion TCP: BBR
Posté par: vivien le 16 février 2020 à 22:24:43
Spotify a également fait des tests sur BBR

L'expérience

De nombreux changements de protocole Internet nécessitent des mises à jour coordonnées des clients et des serveurs (en vous regardant, IPv6!). BBR est différent, il ne doit être activé que du côté de l'expéditeur. Il peut même être activé après l'ouverture de la connexion TCP !

Pour cette expérience, nous avons configuré un sous-ensemble aléatoire d'utilisateurs pour inclure «bbr» dans le nom d'hôte de la demande audio en tant qu'indicateur, et ajouter quelques lignes à la configuration du serveur. Les autres requêtes sont traitées en utilisant la valeur par défaut, CUBIC.

Nous avons maintenant des groupes de traitement et de contrôle pour notre test A / B. Pour chaque groupe, nous mesurons:
- Latence de lecture (médiane, p90, p99)
- Stutter/Bégaiement (nombre moyen par chanson)
- Bande passante, moyenne sur le téléchargement de la chanson (médiane, p10, p01)

Résultats

En prenant des moyennes quotidiennes, le Stutter/bégaiement a diminué de 6 à 10% pour le groupe BBR. La bande passante a augmenté de 10 à 15% pour les cohortes de téléchargement plus lentes et de 5 à 7% pour la médiane. Il n'y avait pas de différence de latence entre les groupes.

Variation significative entre les régions géographiques

Nous avons constaté la plupart des améliorations en Asie-Pacifique et en Amérique latine, avec respectivement 17% et 12% de baisse du bégaiement. La bande passante a augmenté de 15 à 25% pour les téléchargements plus lents et d'environ 10% pour la médiane.

En comparaison, l'Europe et l'Amérique du Nord ont enregistré une amélioration de 3 à 5% du bégaiement et environ 5% de la bande passante.


(https://lafibre.info/testdebit/linux/201808_spotify_stutters_by_region.png)


Bonus: Incident de congestion en amont

Au cours de notre expérience, nous avons connu un événement de congestion du réseau avec un fournisseur en amont sud-américain. C'est là que BBR a vraiment pu briller!

Au Pérou, le groupe non BBR a vu une augmentation de 400 à 500% du bégaiement. Dans le groupe BBR, le bégaiement n'a augmenté que de 30 à 50%.

Dans ce scénario, le groupe BBR avait une bande passante 4x pour des téléchargements plus lents (le 10e centile), une bande passante médiane 2x plus élevée et 5 fois moins de Stutter/bégaiement!

C'est la différence entre nos utilisateurs à peine remarqués et les problèmes de lecture suffisamment graves pour contacter le service client.


(https://lafibre.info/testdebit/linux/201808_spotify_stutters.png)


Conclusion

Nos résultats sont conformes aux rapports du trafic GCP, YouTube et Dropbox. Les performances avec une perte de paquets accrue sont également en ligne avec les résultats des expériences précédentes de Google .

Il y a eu des expériences montrant que BBR peut évincer le trafic CUBIC , entre autres problèmes . Dans le cadre de notre propre trafic, nous n’avons pour l’instant rien vu de tel. Par exemple, nous utilisons quelques partenaires CDN différents pour la livraison audio, mais nous n'avons exécuté l'expérience BBR que sur un seul. Le groupe non BBR ne présente aucune baisse de performance notable par rapport aux autres CDN. Nous continuerons de suivre cela de près.

Nous sommes très satisfaits des performances de BBR jusqu'à présent. Déplacer nos mesures de qualité de lecture dans la bonne direction est diaboliquement difficile, et implique normalement des compromis, par exemple bégaiement par rapport au débit audio. Avec BBR, nous avons constaté une amélioration substantielle sans coût apparent.


Source : Lab Spotify (https://labs.spotify.com/2018/08/31/smoother-streaming-with-bbr/) le 31 août 2018 par Erik Carlsson et Eirini Kakogianni
Titre: Algo de controle de la congestion TCP: BBR
Posté par: munsternet le 17 février 2020 à 08:16:34
Pour rajouter un peu d'eau au moulin, il y'a aussi eu un papier publié lors de la conférence Internet Measurement Conference 2019 sur la modélisation de BRR lorsqu'il est en concurrence avec d'autres algorithmes de controle de congestion (malheureusement c'est tout en anglais)


Bonne lecture  :)
Titre: Algo de controle de la congestion TCP: BBR
Posté par: vivien le 17 février 2020 à 11:26:00
Comparaison Cubic / BBR réalisée sur une ligne Free FTTH en monothread et multithread.

Débit descendant :
(https://lafibre.info/images/free_debit/202002_comparatif_cubic_bbr_1.png) (https://lafibre.info/images/free_debit/202002_comparatif_cubic_bbr_1.png)

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
Titre: Algo de controle de la congestion TCP: BBR
Posté par: vivien le 05 mars 2020 à 21:06:43
Nouvelle comparaison Cubic, BBR, toujours sur la même ligne, mais là les tests Cubic et BBR sont réalisés à quelques secondes d'intervalle :

(https://lafibre.info/images/free_debit/202002_comparatif_bbr_cubic.png)
Titre: Algo de controle de la congestion TCP: BBR
Posté par: underground78 le 12 avril 2020 à 20:05:53
Effet de l'algorithme de contrôle de la congestion sur une connexion FTTH avec une collecte saturée (à priori) :

Titre: Algo de controle de la congestion TCP: BBR
Posté par: Esco le 01 juillet 2020 à 10:59:14
Hello,

J'ai un problème avec des tests de débits TCP-Cubic en Multithread.
J'ai fait quelques tests BBR vs Cubic en Local avec iPerf3 avec dégradation de la ligne (PckLoss et Latence) pour voir l'impact des pckloss et latence sur les débits.

configuration de test :


Conf. serveur (merci Vivien)
Citer
# Reduce the swap
vm.swappiness = 1

# TCP congestion control protocol for high-speed and long-distance networks
#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

# 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

Problèmes
j'ai des valeurs incohérentes sur la conf "latence=50ms" comme vous pouvez le voir ici :
(https://zupimages.net/up/20/27/3th2.png) (https://zupimages.net/viewer.php?id=20/27/3th2.png)

Le débit chute à 50ms (cubic) et remonte à 100ms. J'ai refais 50x le tests, j'ai inversé le client et le serveur mais les résultats sont toujours les mêmes. Je ne comprends pas.

Quelqu'un sait-il pourquoi le débit Cubic chute à 50ms pour remonter à 100ms ? comment remédier à ce problème ?

Présicion : en monothread ce comportement n'a pas lieu. Uniquement en multi.
Précision 2 : j'ai testé d'autres valeurs autour de 50ms. ça ne change rien.
Titre: Algo de controle de la congestion TCP: BBR
Posté par: kgersen le 01 juillet 2020 à 22:15:12

Quelqu'un sait-il pourquoi le débit Cubic chute à 50ms pour remonter à 100ms ? comment remédier à ce problème ?


c'est peut-etre propre a IPerf3, test avec autre chose.

En tests multi-session TCP il y a:

- Goben : https://github.com/udhos/goben (Attention aux options sinon ca genere du traffic dans les 2 sens en meme temps)

exemple sous Linux:
# client et serveur
mkdir test
cd test
curl -L -o goben https://github.com/udhos/goben/releases/download/v0.3/goben_linux_amd64
chmod +x goben
# sur le serveur
./goben
# sur le client
./goben -connections 16 -passiveClient -hosts ip_serveur:8080
# -passiveServer pour l'autre sens
nb: avec cette version (0.3) il n'y a pasla somme des débits des connexions donc il faut la faire a la main.
sinon compiler soit meme pour avoir la v0.4 (cf le github).

- NSpeed (en cours de développement) - version preview ici: http://nspeed.org/nspeed-client/v0.2/
C'est un client http multi session donc il faut un serveur web en face avec des fichiers de mire (comme ceux de https://bouygues.testdebit.info/ ou créer localement avec fallocate) et préférence un ssd.
exemple sous Linux:
# serveur
mkdir test
cd test
# serveur web spark ( https://github.com/rif/spark/releases )
curl -s -L https://github.com/rif/spark/releases/download/v1.7.3/spark_1.7.3_linux_amd64.tar.gz | tar xzvf - spark
# creation d'un fichier de 1G
fallocate -l 1000000000 1G.bin
# lancement serveur web répertoire courant (ajuster port si deja utilisé)
./spark  -port 8080 $(pwd)
# si on a python3 installé on peut aussi utiliser
python3 -m http.server 8080
# mais la performance n'est pas forcement top

# client
mkdir test
cd test
curl -L -o nspeed http://nspeed.org/nspeed-client/v0.2/Linux-x64/nspeed-client
chmod +x nspeed
# test mono connexion pour voir si ok (ajusté port a celui du serveur)
./nspeed http://ip_serveur:8080/1G.bin
# test multi connexion (répéter l'url autant de fois que nécessaire)
./nspeed http://ip_serveur:8080/1G.bin http://ip_serveur:8080/1G.bin http://ip_serveur:8080/1G.bin http://ip_serveur:8080/1G.bin
comme Goben 0.3, y'a pas encore la somme des débits

Dans les 2 cas, pour l'algo de congestion tcp il faut le changer au niveau système (coté émetteur).
Titre: Algo de controle de la congestion TCP: BBR
Posté par: Esco le 02 juillet 2020 à 10:12:28
Merci kgersen pour ton retour.

"c'est peut-etre propre a IPerf3, test avec autre chose."
En phase.

J'ai fait de nouveaux tests hier après analyse TCP (capture shark coté serveur). Je me suis aperçu que pour les tests à 50ms/0.1% loss il y avait un problème de randomisation des pertes. Je m'explique, la première salve de perte arrivait toujours en tout début de DL, ce qui bloquait dès le départ la montée en débit avec une fenêtre de congestion qui n'arrive pas à grandir "assez rapidement" avec pour conséquence un Byte In Flight (BIF) toujours bas et un débit pourri au bout du tuyau. Ce problème arrivait dans 100% des tests.

J'ai donc ajouté un paramètre sur Netem pour randomiser l'injection de PckLoss et contourner le problème de burst de pckLoss en début de téléchargement.

avant : tc qdisc add dev eth1 root netem loss 1%  --> débits = 400Mbps
après : tc qdisc add dev eth1 root netem loss 1% 25% --> débit = (env)850Mbps

Cette simple modif m'a permis de retrouver une valeur plus cohérente. Je n'ai pas encore testé tous les points, mais je pense que le problème était à ce niveau.
Titre: Algo de controle de la congestion TCP: BBR
Posté par: vivien le 02 juillet 2020 à 13:14:53
C'est vrai que l'emplacement des pertes de paquets dans les connexions TCP n'a pas toujours les mêmes conséquences.

Les pertes de paquets au début de la connexion TCP, sur le paquet [SYN] ou sur les paquets lors de la montée en débit rapide (slow start TCP) sont bien plus impactantes que celles qui arrivent quand la connexion est régime établi.

Enfin je reste étonné du choix de choisir un noyau Linux custom, non proposé par la distribution (kernel 5.5 coté client sur une Ubuntu 20.04). Il ne me semble pas pertinent de travailler avec de vieux noyaux (sauf si c'est pour noter les progressions) mais il me semble que de prendre un noyau maison fait prendre des risques (a moins qu'il y ait une fonctionnalité intéressante rajouté entre le noyau 5.4 et 5.5)
Titre: Algo de controle de la congestion TCP: BBR
Posté par: Esco le 02 juillet 2020 à 16:55:45
@Vivien, J'ai juste récupéré un Ubuntu sur leur site (la 20.04) pour le serveur.
Titre: Algo de controle de la congestion TCP: BBR
Posté par: vivien le 11 septembre 2020 à 09:06:52
Dans le rapport sur l'état de l'internet en France : (cliquez sur la miniature ci-dessous - le document est au format PDF de 100 pages)
(https://lafibre.info/images/doc/202006_arcep_rapport_etat_internet_2020.png) (https://lafibre.info/images/doc/202006_arcep_rapport_etat_internet_2020.pdf#page=23)

Impact du contrôle de congestion (Cubic, BBR,...) sur la mesure de la Qos :
(https://lafibre.info/images/doc/202006_arcep_rapport_etat_internet_2020_1_qos_4.png)
Titre: Algo de contrôle de la congestion TCP: BBR
Posté par: ouno le 03 janvier 2022 à 16:17:50
Voici un comparatif de débits descendants mono-connexion TCP BBR vs CUBIC, réalisé en utilisant exactement le même protocole de test sur deux connexions FTTH 1Gbps:

(https://lafibre.info/testdebit/linux/2022201_Graph_Debits_BBR_Cubic_FTTH_Free.png)

(https://lafibre.info/testdebit/linux/2022201_Graph_Debits_BBR_Cubic_FTTH_Orange.png)

Protocole de test:

Toutes les 15 minutes, les 4 tests de débit suivants sont réalisés:
- 30 secondes de téléchargement TCP en BBR depuis l'AS 12876 (Scaleway)
- 30 secondes de téléchargement TCP en CUBIC depuis l'AS 12876 (Scaleway)
- 30 secondes de téléchargement TCP en BBR depuis l'AS 5410 (Bouygues Telecom)
- 30 secondes de téléchargement TCP en CUBIC depuis l'AS 5410 (Bouygues Telecom)

Pour chaque algo de congestion (BBR / CUBIC), seul le débit max entre les 2 AS testés est retenu pour tenter d'éliminer les éventuelles saturations extérieures au réseau du FAI.

La ligne Free était inutilisée au moment des tests.
Titre: Algo de contrôle de la congestion TCP: BBR
Posté par: vivien le 03 janvier 2022 à 16:40:23
Très intéressant.

C'est du mono-connexion ?

C'est possible de savoir la ville où sont les box ?

Les modèles de box utilisées et plus d'info sur la configuration du PC de test ?

(cela permet d'avoir des données complètes)
Titre: Algo de contrôle de la congestion TCP: BBR
Posté par: ouno le 03 janvier 2022 à 18:01:08
C'est du mono-connexion ?
Oui c'est du mono-connexion (je l'avais écrit dans la première ligne de mon post et dans le titre des graphs ;) )

C'est possible de savoir la ville où sont les box ?
Free: Orvault (ZMD)
Orange: Rennes

Les modèles de box utilisées et plus d'info sur la configuration du PC de test ?
Free:
- box: Freebox Révolution r2 avec ONU v1
- système de test: NAS Synology DS214+ (Marvell PJ4Bv7 / 1GB RAM)
Linux 3.2.40 (armv7l)
--------------------------- 2022-01-03 16:02:54 GMT ---------------------------
Paramétrage réseau actuel du système:
  net.core.rmem_max: 6291456
  net.core.wmem_max: 4194304
  net.ipv4.tcp_adv_win_scale: 1
  net.ipv4.tcp_congestion_control: cubic
  net.ipv4.tcp_mem: 24384       32512   48768
  net.ipv4.tcp_no_metrics_save: 0
  net.ipv4.tcp_rmem: 4096       87380   6291456
  net.ipv4.tcp_sack: 1
  net.ipv4.tcp_timestamps: 1
  net.ipv4.tcp_window_scaling: 1
  net.ipv4.tcp_wmem: 4096       16384   4194304
  => Latence TCP max pour une réception à 1 Gbps: 27 ms

Orange:
- box: Livebox 4
- système de test: Debian GNU/Linux 10 (i5-4570 CPU @ 3.20GHz / 16GB RAM)
Linux 4.19.0-13-amd64 (x86_64)
--------------------------- 2022-01-03 16:04:16 GMT ---------------------------
Paramétrage réseau actuel du système:
  net.core.rmem_max: 212992
  net.core.wmem_max: 212992
  net.ipv4.tcp_adv_win_scale: 1
  net.ipv4.tcp_congestion_control: cubic
  net.ipv4.tcp_mem: 187191      249591  374382
  net.ipv4.tcp_no_metrics_save: 0
  net.ipv4.tcp_rmem: 4096       131072  6291456
  net.ipv4.tcp_sack: 1
  net.ipv4.tcp_timestamps: 1
  net.ipv4.tcp_window_scaling: 1
  net.ipv4.tcp_wmem: 4096       16384   4194304
  => Latence TCP max pour une réception à 1 Gbps: 27 ms

Pour info le programme utilisé pour les tests est très très léger et n'utilise bien sûr pas le système de stockage pour les tests de débit.
Des vérifications ont été faites sur les systèmes en charge et ils tiennent sans problème le 1Gbps.

De plus, je ne l'ai pas précisé dans mon post précédent pour pas surcharger, mais sur la ligne Free un test témoin de débit local entre le système de test et la Freebox a aussi été réalisé toutes les 15 minutes, juste avant les tests de débit Internet.
Ce test témoin permet de vérifier qu'à chaque fois que les tests de débit Internet sont réalisés le système est bien capable de monter à 1Gbps. Le test témoin est parfaitement stable et permet d'être vraiment sûr du système de test.

Voici le graph avec le test témoin en plus:
(https://lafibre.info/testdebit/linux/2022201_Graph_Debits_BBR_Cubic_FTTH_Free_2.png)
Titre: Algo de contrôle de la congestion TCP: BBR
Posté par: vivien le 30 janvier 2023 à 19:37:43
Une étude de Ayush Mishra et présenté à l'IETF 109 le 20 novembre 2020 a étudié la répartition des protocoles de congestion TCP sur le top 250 Alexa, les 250 sites web qui sont les plus consultés selon le classement Alexa (qui au passage n'existe plus aujourd'hui) :

BBR est l'algorithme de contrôle de la congestion TCP le plus utilisé avec 25% devant Cubic 22%.


(https://lafibre.info/testdebit/tcp/202011_ietf_the_great_internet_tcp_congestion_control_census_4.webp)

L'évolution dans le temps des algorithmes de contrôle de la congestion TCP, sur le top 20 000 Alexa : Cubic est cette fois-ci devant BBR, car les sites les plus populaires utilisent plus BBR que les autres :

(https://lafibre.info/testdebit/tcp/202011_ietf_the_great_internet_tcp_congestion_control_census_5.webp)
Titre: Algo de contrôle de la congestion TCP: BBR
Posté par: vivien le 30 janvier 2023 à 19:40:10
The Great Internet TCP Congestion Control Census
(cliquez sur la miniature ci-dessous - le document est au format PDF)
(https://lafibre.info/testdebit/tcp/202011_ietf_the_great_internet_tcp_congestion_control_census.webp) (https://lafibre.info/testdebit/tcp/202011_ietf_the_great_internet_tcp_congestion_control_census.pdf)

Les slides des mesures :
(https://lafibre.info/testdebit/tcp/202011_ietf_the_great_internet_tcp_congestion_control_census_1.webp)

(https://lafibre.info/testdebit/tcp/202011_ietf_the_great_internet_tcp_congestion_control_census_2.webp)

(https://lafibre.info/testdebit/tcp/202011_ietf_the_great_internet_tcp_congestion_control_census_3.webp)
Titre: Algo de contrôle de la congestion TCP: BBR
Posté par: zergflag le 30 janvier 2023 à 20:35:23
Netflix utilise toujours du CUBIC ? Il me semble que Netflix utilise FreeBSD comme distro sur leurs serveurs vidéos, c'est en CUBIC par défaut dessus ?
Titre: Algo de contrôle de la congestion TCP: BBR
Posté par: vivien le 30 janvier 2023 à 20:45:43
Oui, c'est public, Netflix utilise du Cubic.

Peut-être, car c'est offloadé sur la carte réseau ?

Ils font faire pas mal de choses à la carte réseau pour décharger le CPU et pouvoir gérer 400 Gb/s par serveur.

Pour information, LaFibre.info, c'est BBR depuis 2020.
Titre: Algo de contrôle de la congestion TCP: BBR
Posté par: hwti le 30 janvier 2023 à 20:51:08
Ici, les tests sont effectués sur le chargement de pages, avec des petites tailles.
Rien ne dit que les CDN vidéo emploient le même algorithme.
Titre: Algo de contrôle de la congestion TCP: BBR
Posté par: ouno le 13 mars 2023 à 14:00:35
A priori BBR est aussi disponible sous Windows depuis Windows 11 22H2, il faut utiliser la commande suivante en admin pour l'activer:
netsh int tcp set supplemental Template=Internet CongestionProvider=bbr2
Titre: Algo de contrôle de la congestion TCP: BBR
Posté par: alain_p le 13 mars 2023 à 14:08:55
Ah, intéressant de le savoir. Je suppose que la version serveur, 2022, pour laquelle c'est le plus intéressant, l'a aussi.
Titre: Algo de contrôle de la congestion TCP: BBR
Posté par: vivien le 13 mars 2023 à 14:19:55
Plus intéressant, cela serait BBR2 et non BBR ?

=> BBR v2 est en train d'être finalisé par Google (https://lafibre.info/tcpip/bbr-v2/)
Titre: Algo de contrôle de la congestion TCP: BBR
Posté par: kgersen le 13 mars 2023 à 17:34:52
A priori BBR est aussi disponible sous Windows depuis Windows 11 22H2, il faut utiliser la commande suivante en admin pour l'activer:
netsh int tcp set supplemental Template=Internet CongestionProvider=bbr2

a noter que la version powershell ( Set-NetTCPSetting ) n'est pas encore a jour et refuse sous Windows 11 de changer le parametre (meme en admin) mais l'affiche bien avec Get-NetTCPSetting.

J'avais fait des tests la semaine derniere avec NSpeed et 2 machines :
- une linux sous BBR qui sert a saturer la connexion en sortie
- une sous Windows Insiders canal Dev ou je changeait entre CUBIC et BBR2

bizarrement les résultats étaient en faveur de CUBIC... :P (peut-etre que BBR2 est plus "faible" que CUBIC fasse a BBR ?)

exemple  avec BBR2:
./nspeed get http://nspeedapi:39757/api/v1/run?args=put%20http://speedtest.milkywan.fr%201g  put -id Milky http://speedtest.milkywan.fr 1g
running...
all done
    Id| Read speed| Write speed| Time| Bytes read| Bytes written|command
 Milky|      0 bps|  186.4 Mbps| 8.00|        0 B|      186.4 MB|put http://speedtest.milkywan.fr 1.0 GB ([2a0b:cbc0:42:1::1]:80 - 3.166 ms - )
      |           |            |     |           |              |
 Total|      0 bps|  186.4 Mbps| 8.00|        0 B|      186.4 MB|

sur plusieurs tests, ca oscille entre 180 et 250 Mbps.
avec CUBIC cela a oscille entre 360Mbs et 600Mbps.

L'ideal serait d'avoir 500Mbps , partage équitable de la ligne (qui fait 1Gbps et qu'on obtient bien quand une seule machine fait l'upload).

Quand on met l'autre machine en CUBIC on obtient a peu près le même résultat entre CUBIC et BBR2 coté Windows. Entre 400 Mbps et 500 Mbps ce qui semble normal.

Apres ma ligne en sortie n'est pas saturée au dela du 1er hop donc c'est moins critique que dans l'autre sens:

Freepro Paris 7 Gbps:
./nspeed g  -id CUBIC http://bouygues.testdebit.info/10G/10G.iso get -id BBR http://paris.testdebit.info/10G/10G.iso
running...
all done
    Id| Read speed| Write speed| Time| Bytes read| Bytes written|command
   BBR|   6.6 Gbps|       0 bps| 8.00|     6.6 GB|           0 B|get http://paris.testdebit.info/10G/10G.iso ([2001:860:de01:1101::2]:80 - 2.155 ms - HTTP/1.1)
 CUBIC|  52.3 Mbps|       0 bps| 8.00|    52.3 MB|           0 B|get http://bouygues.testdebit.info/10G/10G.iso ([2001:860:de01:1100::2]:80 - 2.528 ms - HTTP/1.1)
      |           |            |     |           |              |
 Total|   6.7 Gbps|       0 bps| 8.00|     6.7 GB|           0 B|
saturation/pertes, énorme avantage a BBR.
idem depuis un ligne Orange Pro 1Gbps Paris. Ca sature entre Orange et Bouygues ?

on peut penser que le serveur bouygues.testdebit.info a un souci ? mais depuis une machine chez Google en Belgique :

./nspeed g -id CUBIC http://bouygues.testdebit.info/10G/10G.iso  g -id BBR http://paris.testdebit.info/10G/10G.iso
running...
all done
    Id| Read speed| Write speed| Time| Bytes read| Bytes written|command
   BBR|   3.2 Gbps|       0 bps| 8.00|     3.2 GB|           0 B|get http://paris.testdebit.info/10G/10G.iso (89.84.1.194:80 - 6.340 ms - HTTP/1.1)
 CUBIC|   2.0 Gbps|       0 bps| 8.00|     2.0 GB|           0 B|get http://bouygues.testdebit.info/10G/10G.iso (89.84.1.186:80 - 9.894 ms - HTTP/1.1)
      |           |            |     |           |              |
 Total|   5.2 Gbps|       0 bps| 8.00|     5.2 GB|           0 B|

pas de saturation/perte, léger avantage a BBR.
Titre: Algo de contrôle de la congestion TCP: BBR
Posté par: vivien le 13 mars 2023 à 19:30:02
Les deux serveurs (paris / bouygues) sont chargés à environ 2 Gb/s (c'est assez stable dans le temps).

Par contre bouygues.testdebit.info avait sont /tmp de saturés.

Comment cela se fait que les fichiers uploadés ne sont pas supprimés ?

$ ls /tmp
ntpdate.log  php62e8Di  phpAJAZNr  phpda9VPz  phpfuqtr3  phpIfKMyD  phpLjaBD0  phpo5qFgg  phpPTLpNl  phpsimq66  phpvoN6Rx  phpYL2UxD
php02HscE    php62jRyq  phpAljO0J  phpdBFFAe  phpFypY6N  phpigdEUh  phplk32UG  phpo7HfXP  phpPufnTs  phpSiOhR6  phpvWz5Ua  phpYou64u
php03CcoS    php64hxI0  phpAlPiGF  phpdbMG6f  phpg2yFYr  phpIHcUrF  phpLLDqu9  phpo8Huiu  phpPuZwnm  phpsJfWYv  phpvxGgI9  phpyPPgQD
php0b8OUX    php69rhkg  phpAlRxkx  phpDbYiLg  phpG4N1Wf  phpiKHHQq  phpLo38Zh  phpO8Sfpm  phppwZEon  phpsKz9w1  phpW0QdRw  phpyrdpNY
php0CqWtX    php6b1GmB  phpaMiKzq  phpdEaOUe  phpg6Jjbx  phpiL1AU2  phplQNs2Y  phpO9jSYC  phpPwZYrk  phpsm0k5W  phpw1V4Wx  phpyrkyQN
php0dBms1    php6LHSeU  phpAmMPwT  phpDeHusT  phpG83hyC  phpIl7K5l  phpLvoMdR  phpodl4ej  phppZ8EIm  phpsMfpRp  phpw4gZ10  phpyrOhR0
php0SoDMk    php6PiMAm  phpaMzQv7  phpdH3OBm  phpGaJH6W  phpimYoxg  phplxYEZS  phpoG7b8p  phpq9Dy2F  phpspZrOi  phpw6UAvy  phpysHr0U
php0urwJf    php6rXet2  phpAnP1iv  phpdiZHfe  phpGaojd3  phpiOa9yb  phpm0mi1l  phpOKBrOR  phpQAxppS  phpsraqfN  phpW7YWEI  phpYVK0f8
php0z1l2r    php6s9ecL  phpAPvyfS  phpdkh0lg  phpgAUMoI  phpIOl2XN  phpM5TPUn  phpolMgYA  phpqenHki  phpsyubU4  phpW8xFIm  phpyZ6RJ5
php15RHj5    php6wnoOU  phpAr8Ky8  phpdPczF8  phpgbztw4  phpiSz9dQ  phpm77whz  phpoMnJYL  phpQFsCKM  phpt6qOQo  phpw9T8TQ  phpyZGkxu
php1aieYf    php6XnxGX  phpArBz9j  phpdri7YS  phpgc40II  phpiTNkOS  phpMAZUq9  phpomv1bu  phpqfWQmr  phpTBT3G1  phpwAnqtA  phpyZND9m
php1cU3kW    php6xRtZo  phpaUfvHS  phpdTqVgh  phpgcb5Ms  phpIvb9H0  phpmBwGEO  phpOmVblg  phpqGHsqQ  phpTCLP3h  phpwDzfR9  phpz0cqjU
php1Mbm9k    php6YKjq0  phpauuP5X  phpDyEw8f  phpGdmloj  phpIx0MmJ  phpMdjYdD  phpON15nF  phpQITJUp  phpTEmVfg  phpwjossH  phpZ3XSgi
php1xWcs8    php75Su99  phpB05X7V  phpe7HPIv  phpGE9Cn8  phpiZZFZQ  phpMezFaA  phpORrdKM  phpqIvzlm  phpTO8PjB  phpwku1iO  phpzIXxys
php1yq1oC    php76C0N6  phpb2d9S9  phpeAu6QT  phpGgYMWw  phpj4pmrc  phpMgUjvR  phpos2JYI  phpqIxehr  phptoB8qy  phpWm7JUR  phpZjXdXS
php2dpTfn    php7A03v3  phpB7PkGd  phpEFwUnI  phpGmASsk  phpjACfi2  phpmJBKN3  phpotIlUz  phpQKf43N  phpTtpyy7  phpWqpz4F  phpzkzETk
php2Qu2a3    php7birBz  phpbbdZtn  phpEiY8x0  phpGOIEsS  phpjb3bj7  phpMk3O55  phpOWF1QR  phpQkzpTt  phptYBCNq  phpwTfVi4  phpZLwAeF
php30yaYj    php7jTLWi  phpbcjXak  phpEJFC3i  phpgOXzJA  phpJdTsWK  phpmLTdg2  phpOwmQuo  phpQq7l2I  phptzJ1Rz  phpwU9bDH  phpzMB4NS
php34fPwf    php7lfmg3  phpbcQq9h  phpeK1WER  phpgPBkjQ  phpJfO09h  phpmmD4xk  phpOXlA13  phpqrh5Tk  phpu0QNB3  phpww4nto  phpZmto2j
php3BCcsM    php7qKw41  phpbdSd7c  phpekyndA  phpgrfbHd  phpJgaqxg  phpmN4js0  phpoXvU9s  phpQRxpYe  phpu0tkLb  phpWyx89W  phpzpvmVQ
php3cQCm2    php7s9CSK  phpbinfhs  phpeNfF8A  phpgvBHra  phpjqKUzb  phpmNhDTq  phpoY9d4t  phpQsNMTW  phpU1g0KB  phpX11eba  phpZRjRg6
php3fBBN7    php7vDLIj  phpbLza1V  phpEOPbBp  phpH0FdqT  phpjrixHb  phpmpVAQY  phpp04pVU  phpqueYeI  phpudkAI2  phpX3xSIN  phpZt5zR8
php3fBu9n    php7ZpZXp  phpbNemqF  phpEOTSFS  phpH1apBk  phpjRw7qh  phpmtrIr6  phpp2MgGA  phpqv7bJG  phpuezCkg  phpX4Z5O2  phpzZrRds
php3jeBgQ    php8b2x0U  phpBqX6MT  phpEsOg7v  phph1cek7  phpjUFD0Q  phpMueSfH  phpp6WX1t  phpQxKqzm  phpUFycMd  phpx7Yvmw  snap-private-tmp
php4Ej9jv    php8Bt2aV  phpbup61O  phpETN0MC  phpH3mHal  phpjzfqrf  phpmvSbEU  phpP9pb6V  phpr741FO  phpuLp7cH  phpxd13CP  systemd-private-52394ead526146868de3a2eb72b36079-apache2.service-lpgQAL
php4eYB53    php8i9SoP  phpbVGDe8  phpetw1hC  phpHCssYX  phpK7YhlX  phpmvsP7P  phpp9v8kx  phprg669p  phpUPR41J  phpXd1Tyj  systemd-private-52394ead526146868de3a2eb72b36079-ModemManager.service-EvUXzr
php4fAslg    php8KU3ji  phpc7A7vZ  phpEV5tot  phpHeOmbX  phpKfgZvm  phpMX8n9h  phppbx7m9  phprH1oML  phpuSm2CE  phpXejyDI  systemd-private-52394ead526146868de3a2eb72b36079-munin-node.service-Nth9g2
php4hUM0f    php8ViAaO  phpcDa7aB  phpExGv7W  phpHgLlxN  phpKFIql8  phpMXwYFG  phpPCVjDt  phprHEFlR  phpuvKDd7  phpxhnDik  systemd-private-52394ead526146868de3a2eb72b36079-systemd-logind.service-n6wDjG
php4iauMj    php8xA1Q8  phpcEToaM  phpExvhaZ  phphJjF6i  phpkgwTB3  phpmyYwHv  phppdClFM  phpRhVOL5  phpuwdLfh  phpxRHEwc  systemd-private-52394ead526146868de3a2eb72b36079-systemd-resolved.service-W7pbri
php4iYUHK    php99gZs9  phpCF1G9n  phpeYDhuj  phphKhjzV  phpkhDurj  phpN7IxG5  phpPdLtis  phprj9q7a  phpV6Jldw  phpXrLqF8  systemd-private-52394ead526146868de3a2eb72b36079-systemd-timesyncd.service-i1UJs2
php4NpF7q    php9jjzZc  phpcj5pKo  phpEZEXjr  phpHltcvY  phpKHfl3X  phpNBO1oy  phppdMIys  phprnHLX0  phpVDj7E1  phpxtu6Eq  systemd-private-52394ead526146868de3a2eb72b36079-upower.service-T5W1P7
php4rNcH9    php9Pc5RR  phpCJAxmG  phpF3cXSl  phphOWyo6  phpkKwFin  phpnDjEpl  phppf52uL  phpRqpTXw  phpVEuyfr  phpxzWxnL  tmp.96lua1KNBx
php5075fO    phpA2Mvnd  phpcLuhqi  phpF3qiG6  phphUWfNJ  phpkSqzAI  phpnedGAb  phppFIjYP  phpRWKFbh  phpVF57ZA  phpY1EoMP
php5fgBjA    phpaa9OcF  phpCmR4BV  phpF5rpnn  phphvMWgZ  phpkuONsr  phpNFWZMo  phpPgIDSm  phpRXNLfG  phpVFJAuw  phpY4BMr2
php5IOJOG    phpaavi67  phpCPu5Zs  phpf9uoSR  phphwkupG  phpKYInjw  phpnoOtvK  phppgtsrt  phpS0ofGs  phpVfmub8  phpYAeVN7
php5K54gI    phpAcfinC  phpcVdMLo  phpFC27I7  phphXIv8j  phpKyY43I  phpNqV4Bi  phpPJ6QKS  phps10Bt2  phpVhCizS  phpyd4EOZ
php5KKf9N    phpae2mRI  phpcXXOoj  phpfhKcK9  phphYa85u  phpkZEuxu  phpnrCLTz  phpPlAUbA  phps9VhQI  phpVHRABz  phpYedTqt
php5mk7N1    phpaefROL  phpd278uA  phpfj99HW  phpI4EJZ2  phpLbyUjW  phpNT0Uib  phppOKGx8  phpsBwaiL  phpviHskT  phpyHNxCh
php5oLtzP    phpagY2W5  phpd5Ubcb  phpFowEbC  phpi8aNGc  phpLiKBNo  phpo0zqyl  phpPPsgii  phpse0glH  phpviv9kl  phpyIgeqI
php5xhXHS    phpaI6019  phpD9ZmAU  phpFTubIz  phpIDkghk  phpLipNcn  phpo4GuDR  phppr4mj4  phpsezRzx  phpVnuTMs  phpYj8GH0
Titre: Algo de contrôle de la congestion TCP: BBR
Posté par: kgersen le 13 mars 2023 à 19:34:31
aucune idée, c'est quoi ton script d'upload deja ?
Titre: Algo de contrôle de la congestion TCP: BBR
Posté par: vivien le 13 mars 2023 à 19:44:24
Si c'est https://bouygues.testdebit.info/ul/ qui est utilisé, derrière c'est :

<!DOCTYPE html>
<html lang="fr">
 <head><title>Net-test</title></head>
 <body><?php echo '<p>URL pour réaliser un test de débit montant</p>'; ?></body>
</html>

Par contre, j'ai aussi un script utilisé par 5GMark et les outils de test de débit de QoSi by MOZARK :

https://bouygues.testdebit.info/ul/upload.php
<?php
$datas = file_get_contents('php://input');
$resultArray["status"] = "FICHIER RECU";

// retour vers le device
echo json_encode($resultArray);



//----------------------------- fonctions ---------------------------------------

function checkError($_val)
{
global $resultArray,$bd;

if (gettype($_val)=='string' && substr($_val,0,6)==substr(CONNEXION_ERROR,0,6))
{
$resultArray["status"] = $_val;
logToFile("error_log.txt",$_val);
echo json_encode($resultArray);
$bd->fermerConnexionBDD();
die();
}
}


function logToFile($filename,$msg)
{
      $fd=fopen($filename,"a");
      $str="[".date("Y/m/d h:i:s")."]".$msg;
      fwrite($fd,$str."\n");
      fclose($fd);
}

?>
Titre: Algo de contrôle de la congestion TCP: BBR
Posté par: kgersen le 13 mars 2023 à 22:51:36
hum curieux. a priori ces 2 scripts n'utilisent pas de fichiers temporaires dans /tmp.
regarde avec les dates&heures des fichiers et le log apache pour voir a quelles requêtes ils correspondent.
ils font quelles tailles ces fichiers phpxxxx et y'a quoi dedans ?

en general les fichiers dans /tmp sont supprimés quand un script se termine sauf si y'a un gros crash du script. surement aussi visible quelque part dans les logs.
Titre: Algo de contrôle de la congestion TCP: BBR
Posté par: Optix le 13 mars 2023 à 23:26:55
Les deux serveurs (paris / bouygues) sont chargés à environ 2 Gb/s (c'est assez stable dans le temps).

Par contre bouygues.testdebit.info avait sont /tmp de saturés.

Comment cela se fait que les fichiers uploadés ne sont pas supprimés ?

$ ls /tmp
ntpdate.log  php62e8Di  phpAJAZNr  phpda9VPz  phpfuqtr3  phpIfKMyD  phpLjaBD0  phpo5qFgg  phpPTLpNl  phpsimq66  phpvoN6Rx  phpYL2UxD
...

Soit :
- ton script est arrêté brutalement ou n'arrive pas à aller jusqu'au bout
- ton script ne fait jamais appel à "move_uploaded_file"; et donc les fichiers temporaires demeurent
Titre: Algo de contrôle de la congestion TCP: BBR
Posté par: kgersen le 14 mars 2023 à 00:26:38
- ton script ne fait jamais appel à "move_uploaded_file"; et donc les fichiers temporaires demeurent

non car
Citer
The file will be deleted from the temporary directory at the end of the request if it has not been moved away or renamed.
source: https://www.php.net/manual/en/features.file-upload.post-method.php

j'ai testé sur un serveur php de test,on voit bien le fichier temporaire (il suffit d'ajouter  print_r($_FILES);  dans le script pour voir le fichier temporaire). Le fichier temporaire est bien supprimer juste après la fin du script.

C'est donc surement un crash qui laisse les fichier temporaires.

@vivien tu peux monitorer /tmp avec cette commande:

inotifywait --monitor --timefmt "%a, %d %b %Y %T %z" --format "%T %e %w%f" --event move,create,delete ./tmp
(il faut installer inotifywait avec sudo apt install inotify-tools)

puis faire quelques tests  upload, tu verra les évènements de création/suppression des fichiers temporaires.
Titre: Algo de contrôle de la congestion TCP: BBR
Posté par: Optix le 14 mars 2023 à 08:56:50
non carsource: https://www.php.net/manual/en/features.file-upload.post-method.php

j'ai testé sur un serveur php de test,on voit bien le fichier temporaire (il suffit d'ajouter  print_r($_FILES);  dans le script pour voir le fichier temporaire). Le fichier temporaire est bien supprimer juste après la fin du script.

C'est donc surement un crash qui laisse les fichier temporaires.
Ok my bad.

Un max_execution_time trop court ou un timer côté php-fpm qui n'attend pas assez longtemps ? Là pareil, il faut voir dans les logs d'erreurs.
Titre: Algo de contrôle de la congestion TCP: BBR
Posté par: vivien le 14 mars 2023 à 09:27:46
J'ai regardé, la plupart des fichiers dans /tmp sont bien supprimés.

Y compris pour PHP.

Le problème, c'est que depuis hier, il y a environ 40 fichiers php qui n'ont pas été supprimés sans que je comprenne pourquoi.

Upload plus long que le timer coté php-fpm ?

# inotifywait --monitor --timefmt "%a, %d %b %Y %T %z" --format "%T %e %w%f" --event move,create,delete /tmp
Setting up watches.
Watches established.
Tue, 14 Mar 2023 09:12:02 +0100 CREATE /tmp/iperf3.x590kv
Tue, 14 Mar 2023 09:12:02 +0100 DELETE /tmp/iperf3.x590kv
Tue, 14 Mar 2023 09:12:15 +0100 CREATE /tmp/iperf3.vTgFuV
Tue, 14 Mar 2023 09:12:15 +0100 DELETE /tmp/iperf3.vTgFuV
Tue, 14 Mar 2023 09:12:28 +0100 CREATE /tmp/php2X2YtW
Tue, 14 Mar 2023 09:12:43 +0100 DELETE /tmp/php2X2YtW
Tue, 14 Mar 2023 09:12:47 +0100 CREATE /tmp/phptWyPv5
Tue, 14 Mar 2023 09:13:07 +0100 CREATE /tmp/iperf3.gk2cGK
Tue, 14 Mar 2023 09:13:07 +0100 DELETE /tmp/iperf3.gk2cGK
Tue, 14 Mar 2023 09:13:13 +0100 CREATE /tmp/iperf3.X7U385
Tue, 14 Mar 2023 09:13:13 +0100 DELETE /tmp/iperf3.X7U385
Tue, 14 Mar 2023 09:13:14 +0100 DELETE /tmp/phptWyPv5
Titre: Algo de contrôle de la congestion TCP: BBR
Posté par: kgersen le 14 mars 2023 à 11:32:12
Upload plus long que le timer coté php-fpm ?

je doute quand même que ce ne soit pas géré...

Regarde tes logs apache2 pour voir quelle(s) requête(s) correspondent aux fichiers non supprimés.
Titre: Algo de contrôle de la congestion TCP: BBR
Posté par: vivien le 14 mars 2023 à 11:40:48
Tu vois ca comment ?
188.23.188.xx 54068 443 [14/Mar/2023:11:38:30 +0100] "POST https://ipv4.bouygues.testdebit.info/ HTTP/1.1" 200 109735 "-" "-"
92.219.47.xx 51820 443 [14/Mar/2023:11:38:31 +0100] "POST https://ipv4.bouygues.testdebit.info/ HTTP/1.1" 200 109735 "-" "-"
84.174.238.xx 38696 443 [14/Mar/2023:11:38:39 +0100] "POST https://bouygues.testdebit.info/ HTTP/1.1" 200 109682 "-" "-"
77.21.236.xx 61511 443 [14/Mar/2023:11:38:44 +0100] "POST https://bouygues.testdebit.info/ HTTP/1.1" 200 109767 "-" "-"
87.79.54.xx 62600 443 [14/Mar/2023:11:38:50 +0100] "POST https://bouygues.testdebit.info/ HTTP/1.1" 200 109735 "-" "-"
84.73.206.xx 57600 443 [14/Mar/2023:11:38:54 +0100] "POST https://bouygues.testdebit.info/ HTTP/1.1" 200 109719 "-" "-"
77.57.172.xx 49258 443 [14/Mar/2023:11:39:06 +0100] "POST https://bouygues.testdebit.info/ HTTP/1.1" 200 109682 "-" "-"
78.134.75.xx 36768 443 [14/Mar/2023:11:39:04 +0100] "POST https://bouygues.testdebit.info/ HTTP/1.1" 200 109735 "-" "-"
80.123.131.xx 55845 443 [14/Mar/2023:11:39:12 +0100] "POST https://ipv4.bouygues.testdebit.info/ HTTP/1.1" 200 109735 "-" "-"
188.61.59.xx 36186 443 [14/Mar/2023:11:39:14 +0100] "POST https://bouygues.testdebit.info/ HTTP/1.1" 200 109735 "-" "-"
93.220.190.xx 46044 443 [14/Mar/2023:11:39:21 +0100] "POST https://bouygues.testdebit.info/ HTTP/1.1" 200 109767 "-" "-"
Titre: Algo de contrôle de la congestion TCP: BBR
Posté par: Optix le 14 mars 2023 à 11:55:37
Vu que c'est php-fpm, faut voir les logs à lui, vu que c'est lui qui prend la décision de timeout.

Mais oui, je mets une pièce sur un upload plus long que le timer.
Titre: Algo de contrôle de la congestion TCP: BBR
Posté par: vivien le 14 mars 2023 à 12:24:03
J'ai pas logué plus avec php-fpm, je vais lui demander d'être plus verbeux

[14-Mar-2023 11:33:48] WARNING: [pool www] child 82480, script '/home/net-test/ul/index.php' (request: "POST /ul/index.php") execution timed out (77.298450 sec), terminating
[14-Mar-2023 11:33:48] WARNING: [pool www] child 82480 exited on signal 15 (SIGTERM) after 2720.151385 seconds from start
[14-Mar-2023 11:33:48] NOTICE: [pool www] child 86218 started
[14-Mar-2023 11:48:28] WARNING: [pool www] child 76996, script '/home/net-test/ul/index.php' (request: "POST /ul/index.php") execution timed out (62.555015 sec), terminating
[14-Mar-2023 11:48:28] WARNING: [pool www] child 76996 exited on signal 15 (SIGTERM) after 8040.446160 seconds from start
[14-Mar-2023 11:48:28] NOTICE: [pool www] child 87441 started
[14-Mar-2023 11:50:08] WARNING: [pool www] child 79122, script '/home/net-test/ul/index.php' (request: "POST /ul/index.php") execution timed out (78.547338 sec), terminating
[14-Mar-2023 11:50:08] WARNING: [pool www] child 79122 exited on signal 15 (SIGTERM) after 6540.359027 seconds from start
[14-Mar-2023 11:50:08] NOTICE: [pool www] child 87581 started
[14-Mar-2023 11:50:48] WARNING: [pool www] child 86218, script '/home/net-test/ul/index.php' (request: "POST /ul/index.php") execution timed out (65.054672 sec), terminating
[14-Mar-2023 11:50:48] WARNING: [pool www] child 86218 exited on signal 15 (SIGTERM) after 1020.051003 seconds from start
[14-Mar-2023 11:50:48] NOTICE: [pool www] child 87724 started
[14-Mar-2023 12:08:09] WARNING: [pool www] child 75415, script '/home/net-test/ul/index.php' (request: "POST /ul/index.php") execution timed out (68.571061 sec), terminating
[14-Mar-2023 12:08:09] WARNING: [pool www] child 75415 exited on signal 15 (SIGTERM) after 10640.591859 seconds from start
[14-Mar-2023 12:08:09] NOTICE: [pool www] child 88822 started
[14-Mar-2023 12:21:49] WARNING: [pool www] child 75416, script '/home/net-test/ul/index.php' (request: "POST /ul/index.php") execution timed out (77.550853 sec), terminating
[14-Mar-2023 12:21:49] WARNING: [pool www] child 75416 exited on signal 15 (SIGTERM) after 11460.637476 seconds from start
Titre: Algo de contrôle de la congestion TCP: BBR
Posté par: ouno le 14 mars 2023 à 17:24:16
J'avais fait des tests la semaine derniere avec NSpeed et 2 machines :
- une linux sous BBR qui sert a saturer la connexion en sortie
- une sous Windows Insiders canal Dev ou je changeait entre CUBIC et BBR2

bizarrement les résultats étaient en faveur de CUBIC... :P (peut-etre que BBR2 est plus "faible" que CUBIC fasse a BBR ?)

sur plusieurs tests, ca oscille entre 180 et 250 Mbps.
avec CUBIC cela a oscille entre 360Mbs et 600Mbps.

L'ideal serait d'avoir 500Mbps , partage équitable de la ligne (qui fait 1Gbps et qu'on obtient bien quand une seule machine fait l'upload).

Quand on met l'autre machine en CUBIC on obtient a peu près le même résultat entre CUBIC et BBR2 coté Windows. Entre 400 Mbps et 500 Mbps ce qui semble normal.
J'ai fait des tests de ce genre ici (https://lafibre.info/tcpip/comparatif-implementations-tcp-gestion-du-out-of-order/msg1007224/#msg1007224) sauf que je m'intéresse au cas où une nouvelle connexion entre en concurrence avec une connexion existante qui a déjà atteint le max de la bande passante disponible, alors que toi si j'ai bien compris tu lances les deux simultanément.
Titre: Algo de contrôle de la congestion TCP: BBR
Posté par: kgersen le 14 mars 2023 à 17:42:48
J'ai fait des tests de ce genre ici (https://lafibre.info/tcpip/comparatif-implementations-tcp-gestion-du-out-of-order/msg1007224/#msg1007224) sauf que je m'intéresse au cas où une nouvelle connexion entre en concurrence avec une connexion existante qui a déjà atteint le max de la bande passante disponible, alors que toi si j'ai bien compris tu lances les deux simultanément.

ah super.

oui a peu prés simultanément. Je suis en train de terminer le code client/serveur de nspeed pour automatiser ce genre de tests avec plusieurs machines (ainsi que la  génération de graphes et d'export de metrics). Je ferais une batterie de tests plus complète une fois le code stabilisé (pour le moment c'est un peu trop 'brute' niveau UX).
Titre: Algo de contrôle de la congestion TCP: BBR
Posté par: vincentimes le 21 janvier 2024 à 21:12:31
Bonsoir tout le monde,

dites moi concernant windows 10, je suppose qu'il n'y a pas de solution pour éviter les congestions du réseau Free ?

Car au niveau de l'upload c'est une catastrophe pour mes transfères en ftp.
Titre: Algo de contrôle de la congestion TCP: BBR
Posté par: vivien le 22 janvier 2024 à 08:42:13
L'algo de congestion TCP est utilisé pour les flux sortants, donc le paramétrage du ton Windows 10 n'influe que sur les flux sortant.

Microsoft travaille sur l'implémentation de BBR dans Windows.
Titre: Algo de contrôle de la congestion TCP: BBR
Posté par: kgersen le 22 janvier 2024 à 19:16:51
je ne sais pas si ils ont mis a jour W10 ou le feront, pour Windows 11 c'est:

netsh int tcp set supplemental Template=Internet CongestionProvider=bbr2(en admin)
Titre: Algo de contrôle de la congestion TCP: BBR
Posté par: rooot le 22 janvier 2024 à 20:22:36
je ne sais pas si ils ont mis a jour W10 ou le feront, pour Windows 11 c'est:

netsh int tcp set supplemental Template=Internet CongestionProvider=bbr2(en admin)
c'est curieux chez moi lorsque je fais ca mon debit s'ecroule.

EDIT:
ha noon, c'est le serveur speedtest d'aubagne qui est à l'agonie...
Titre: Algo de contrôle de la congestion TCP: BBR
Posté par: vincentimes le 26 janvier 2024 à 21:49:59
L'algo de congestion TCP est utilisé pour les flux sortants, donc le paramétrage du ton Windows 10 n'influe que sur les flux sortant.

Microsoft travaille sur l'implémentation de BBR dans Windows.

Bonsoir, j'en suis bien conscient mais c'est justement ce qui pose soucis chez moi.

L'utilisation de l'upload lors de l'envoie de fichiers est une catastrophe avec FREE.

Etant sous windows 10 je n'arrive pas à trouver de solution pour contourner le soucis.
Titre: Algo de contrôle de la congestion TCP: BBR
Posté par: vivien le 27 janvier 2024 à 09:27:06
Upload avec quel logiciel, quel protocole ?
Titre: Algo de contrôle de la congestion TCP: BBR
Posté par: vincentimes le 27 janvier 2024 à 09:55:49
Upload avec quel logiciel, quel protocole ?

Bonjour Vivien,

Je possède un n’as synology ds1520+ qui se trouve chez mon père.

J’envoie dessus de très gros fichiers compris entre 50//200 go via filezilla.

J’ai un compte no ip pour me permettre de faire là passerelle.

Lorsque je désire envoyer des fichiers je ne dépasse pas les 5 Mo/s depuis mon passage chez Free contre 25/40 Mo/s quand j’étais chez RED.

J’ai bien compris qu’il y avait un phénomène de congestion très important chez cette opérateur cependant je n’arrive pas à trouver une solution n’étant pas sous Windows 11.

Quand je fais un test de débit via nPerf je ne rencontre aucun soucis pour atteindre environs 670 m.

Je possède la Freebox delta.
Titre: Algo de contrôle de la congestion TCP: BBR
Posté par: vivien le 27 janvier 2024 à 13:52:32
Tu connais la latence avant / après la migration vers Free ?

Je pense que c'est une limitation de la Rwin du NAS / Filezilla.

La Rwin, c'est le nombre d'octets en vol non acquités.

J'utilise Filezilla et j'ai noté que je n'atteins pas le débit maximum, je me suis demandé si la Rwin n'était pas limité.

La forumule :
(https://lafibre.info/images/tuto/RWin.png)

Mon graphique est vieux, mais il te montre l'impact d'un Rwin sur le débit en fonction de la latence.

(https://lafibre.info/images/tuto/201106_impact_du_ping_en_fonction_du_systeme_exploitation.png)
Titre: Algo de contrôle de la congestion TCP: BBR
Posté par: vincentimes le 28 janvier 2024 à 20:03:09
Bonsoir Vivien,

je suis navré je ne connais pas la latence que j'avais chez Red. N'ayant pas de soucis pour transféré je ne me suis pas psoé la question.

J'essaye à différentes heures de la journée et le résultat est toujours le même depuis que je suis chez Free impossible de dépasser 4 ou 5 MO/s.

Je pense que tout de même que ton débit lors de l'envoie est plus important que le mien non ?

Je n'arrive pas à trouver une solution, je lis les différents sujets sur le WEB mais ne saisit pas tout.

Aucun soucis pour faire dans le sens inverse c est a dire nas vers chez moi je fais environs 62 MO/S.

Le soucis vient bien de l'upload. Une idée de comment améliorer cela ?
Titre: Algo de contrôle de la congestion TCP: BBR
Posté par: vivien le 28 janvier 2024 à 21:10:30
Quelle est la latence actuelle ? (ping l'IP).

Si la limitation est présente quel que soit l'heure, ce n'est pas de la congestion et BBR ne peut rien pour toi.

Je regardes ce que j'obtiens chez moi en up avec Filezlla.
Titre: Algo de contrôle de la congestion TCP: BBR
Posté par: vincentimes le 28 janvier 2024 à 21:22:15
Quelle est la latence actuelle ? (ping l'IP).

Si la limitation est présente quel que soit l'heure, ce n'est pas de la congestion et BBR ne peut rien pour toi.

Je regardes ce que j'obtiens chez moi en up avec Filezlla.

Tu souhaites que je fasse un test de débit ?

Ce qui est étrange c’est que l’autre sens aucun soucis de débit. Je fais plus de 60 MO/s c’est nickel.

Donc cela se produit uniquement de chez moi vers chez mon père en upload.
Titre: Algo de contrôle de la congestion TCP: BBR
Posté par: MaxLebled le 29 janvier 2024 à 06:11:18
Question bête, mais est-ce que tu testes ça en Ethernet ? 60 Mo/s en down, 5 Mo/s en up, moi ça me fait penser à du Wi-Fi
Titre: Algo de contrôle de la congestion TCP: BBR
Posté par: vincentimes le 29 janvier 2024 à 07:26:23
Question bête, mais est-ce que tu testes ça en Ethernet ? 60 Mo/s en down, 5 Mo/s en up, moi ça me fait penser à du Wi-Fi

Éthernet. Mon ordinateur ne se trouve pas en wifi.

Je n’avais pas ce soucis quand j’étais chez red -).
Titre: Algo de contrôle de la congestion TCP: BBR
Posté par: vivien le 29 janvier 2024 à 08:32:27
Tu souhaites que je fasse un test de débit ?

Non, un ping vers le synology ds1520+ qui se trouve chez ton père.

Par exemple si l'IP de ton père est 8.8.8.8, faire un ping 8.8.8.8 et relever la valeur.
Titre: Algo de contrôle de la congestion TCP: BBR
Posté par: vincentimes le 29 janvier 2024 à 08:37:07
Non, un ping vers le synology ds1520+ qui se trouve chez ton père.

Par exemple si l'IP de ton père est 8.8.8.8, faire un ping 8.8.8.8 et relever la valeur.

Bonjour Vivien,

Je te fais cela ce soir en rentrant du travail.
Titre: Algo de contrôle de la congestion TCP: BBR
Posté par: vincentimes le 03 février 2024 à 10:04:23
Non, un ping vers le synology ds1520+ qui se trouve chez ton père.

Par exemple si l'IP de ton père est 8.8.8.8, faire un ping 8.8.8.8 et relever la valeur.

Bonjour Vivien,

je viens de faire le test je t'envoie cela en message privé pour ne pas mettre en public les informations Ip etc.

Tu peux me faire un retour ici sur le forum.

Je viens de faire un test d'envoie de fichier environs 80 go a 10h13 ce matin.

Voici a combien je tourne via les captures ci-dessous.

Ce n'est pas du tout constant.




Titre: Algo de contrôle de la congestion TCP: BBR
Posté par: vivien le 04 février 2024 à 16:41:59
Perso, avec une latence de 10ms, je suis limité à 200 Mb/s d'upload avec FileZilla en SFTP (FTP over SSH).
Je suis persuadé que la problématique vient d'une fenêtre TCP trop petite coté FileZilla.

Toi tu es à 13ms, donc une latence encore plus importante.
Titre: Algo de contrôle de la congestion TCP: BBR
Posté par: vincentimes le 04 février 2024 à 18:32:37
Perso, avec une latence de 10ms, je suis limité à 200 Mb/s d'upload avec FileZilla en SFTP (FTP over SSH).
Je suis persuadé que la problématique vient d'une fenêtre TCP trop petite coté FileZilla.

Toi tu es à 13ms, donc une latence encore plus importante.

Bonsoir Vivien,

Je vais essayer de tester d’autre client FTP mais quelque chose me dit que cela ne changera rien.

Ce qui n’est pas logique c’est que je devrais aussi être ennuyé dans le sens inverse c’est à dire quand je télécharge un gros fichier depuis chez mon père or cela fonctionne dans aucun soucis !

Je tourne à environs 69 mo/s stable sans fluctuations.

En revanche en upload pas moyen c’est une catastrophe.

J’ai même formaté mon ordinateur pensant que cela pouvait venir de la.

Mis mon antivirus sur pause, mis sans échec avec prise en charge réseau rien ne change.

Titre: Algo de contrôle de la congestion TCP: BBR
Posté par: vivien le 04 février 2024 à 19:15:49
Si tu avais la possibilité, il serait intéressant d'installer un Linux (par exemple sur un disque externe) afin de tester différents paramètres.

J'ai mis les paramètres Rwin optimisés sur https://lafibre.info/ubuntu/securisation-serveur/msg898838/#msg898838

Tu pourras voir si le débit augmente avec BBR + RWIN de 32 Mo et après voir si c'est BBR ou la RWIN qui est la cause de l'amélioration.
Titre: Algo de contrôle de la congestion TCP: BBR
Posté par: vincentimes le 04 février 2024 à 19:24:04
Si tu avais la possibilité, il serait intéressant d'installer un Linux (par exemple sur un disque externe) afin de tester différents paramètres.

J'ai mis les paramètres Rwin optimisés sur https://lafibre.info/ubuntu/securisation-serveur/msg898838/#msg898838

Tu pourras voir si le débit augmente avec BBR + RWIN de 32 Mo et après voir si c'est BBR ou la RWIN qui est la cause de l'amélioration.

Je vais essayer tous les clients ftp déjà.
Ensuite si cela ne change rien je vais regarder pour passer à Windows 11 qui gère le BBR car là je suis sur le 10 et y a zéro solutions
Titre: Algo de contrôle de la congestion TCP: BBR
Posté par: kgersen le 04 février 2024 à 19:28:47
C'est pas du SFTP ?!

si le débit n'est pas symétrique, pour le même  fichier,  c'est peut-être une histoire de taille de buffers.

ou alors vitesse écriture a l'arrivé sur le disque...

tu peux essayer en envoyant 2 fichiers en même temps avec 2 instances de Filezilla pour voir si c'est un souci de limite de débit d'une session tcp (donc influençable par l'algo de congestion sinon c'est hors sujet ici).
Titre: Algo de contrôle de la congestion TCP: BBR
Posté par: vincentimes le 04 février 2024 à 20:14:44
C'est pas du SFTP ?!

si le débit n'est pas symétrique, pour le même  fichier,  c'est peut-être une histoire de taille de buffers.

ou alors vitesse écriture a l'arrivé sur le disque...

tu peux essayer en envoyant 2 fichiers en même temps avec 2 instances de Filezilla pour voir si c'est un souci de limite de débit d'une session tcp (donc influençable par l'algo de congestion sinon c'est hors sujet ici).

Je fais ca de suite.

Voila c 'est fait.

La somme des deux est de 8 mo/S ce que je fais quand je ne lance qu'un seul upload ....

Je viens d 'essayer avec un autre client ftp winscp exactement pareil 8 mo/S et pas plus.

Pareil avec le logiciel cyberduck.

Le test aussi en sans echec avec prise en charge réseau ne change pas la donne ....

Après je passe par no ip je ne sais pas si c'est cela qui me pénalise avec FREE.

Bon je mets directement l'adresse ip du nas et ca ne change rien du tout non +. Je ne comprends pas ce qui peut pécher.
Titre: Algo de contrôle de la congestion TCP: BBR
Posté par: Optix le 05 février 2024 à 00:08:57
Attention à ce que tu postes sur la capture, coquin   ;D
Titre: Algo de contrôle de la congestion TCP: BBR
Posté par: kgersen le 05 février 2024 à 08:38:57
Et on ne sait toujours pas si c'est du SFTP ou du FTP(S).
Titre: Algo de contrôle de la congestion TCP: BBR
Posté par: vincentimes le 15 février 2024 à 22:47:28
je ne sais pas si ils ont mis a jour W10 ou le feront, pour Windows 11 c'est:

netsh int tcp set supplemental Template=Internet CongestionProvider=bbr2(en admin)

Comment sais tu si cela à fonctionné ? Je suis au final passé sous windows 11 et je viens de copier coller la commande pour le BBR.

Mais comment peut on savoir que cela à bien été appliqué ?
Titre: Algo de contrôle de la congestion TCP: BBR
Posté par: kgersen le 15 février 2024 à 23:22:17
Comment sais tu si cela à fonctionné ? Je suis au final passé sous windows 11 et je viens de copier coller la commande pour le BBR.

Mais comment peut on savoir que cela à bien été appliqué ?

avec

netsh int tcp show supplemental
ou

Get-NetTCPSetting -SettingName Internet(4eme ligne)
Titre: Algo de contrôle de la congestion TCP: BBR
Posté par: vincentimes le 15 février 2024 à 23:33:41
avec

netsh int tcp show supplemental
ou

Get-NetTCPSetting -SettingName Internet(4eme ligne)

Pour toi c'est bon ?
Titre: Algo de contrôle de la congestion TCP: BBR
Posté par: kgersen le 15 février 2024 à 23:44:44
oui c'est affiché bien 'bbr2'.
Titre: Algo de contrôle de la congestion TCP: BBR
Posté par: vincentimes le 15 février 2024 à 23:46:49
oui c'est affiché bien 'bbr2'.

Merci beaucoup.

Je constate une légère amélioration depuis que je suis passé a windows 11 + bbr lorsque je souhaites upload des fichiers chez moi vers mon père via filezilla.

Cependant, cela n'est pas encore terrible je trouve et je ne sais pas si je peux encore améliorer les choses.

Avant je plafonné entre 5/10 mo/S maintenant je suis plus entre 30 et 35 mo/s.

y at'il des réglages supplémentaire à effectuer que ca soit sous windows ou bien carte réseau ou encore via la freebox pour améliorer cela ?

Ci-joint une capture ce matin d'un upload et je suis au maximum.

Donc le soucis est bien une congestion en journée + une très grosse congestion le soir puisque le débit est divisé par 2.

C'est linaire sans aucune fluctuation alors que le soir ca monte direct a 70 puis ca chute a 50 et descend tout doucement pour ne reste que a 35 mo/s.
Titre: Algo de contrôle de la congestion TCP: BBR
Posté par: vivien le 16 février 2024 à 09:27:32
Chez Free la congestion peut être limitée à l'IPv4 (en fonction de là où elle se situe).

Comparer le débit en IPv4 et IPv6 peut être intéressant.
Titre: Algo de contrôle de la congestion TCP: BBR
Posté par: vincentimes le 16 février 2024 à 12:43:52
Chez Free la congestion peut être limitée à l'IPv4 (en fonction de là où elle se situe).

Comparer le débit en IPv4 et IPv6 peut être intéressant.

D’accord donc il faut que je passe en ipv6 ?

Je dois activer le dhcp ip v 6 de la Freebox ? Je suppose que je dois désactiver celui de l’ip v4 ou bien cela se fait automatiquement ?

Je n’ai pas de dns a changer à tous hasard ?
Titre: Algo de contrôle de la congestion TCP: BBR
Posté par: vivien le 16 février 2024 à 13:08:21
L'IPv6 est déjà activé, il faut par contre renseigner l'IPv6 sur le DNS si tu utilises un nom de domaine.
Titre: Algo de contrôle de la congestion TCP: BBR
Posté par: vincentimes le 16 février 2024 à 15:07:26
L'IPv6 est déjà activé, il faut par contre renseigner l'IPv6 sur le DNS si tu utilises un nom de domaine.

Je passe par no ip.

Tu veux dire que je dois renseigner cela sur la Freebox ou chez no ip ou chez mon père ?
Titre: Algo de contrôle de la congestion TCP: BBR
Posté par: MaxLebled le 16 février 2024 à 15:18:31
Perso, j'avais déjà pu constater une énorme différence entre ipv4 et ipv6 (mais ça ne m'était arrivé qu'une fois)

c.f. message ici : https://lafibre.info/1gb-free/checkftthfree-test-de-debit-tcp-mono-connexion-freeboxcubicbbr/msg1038234/#msg1038234
Titre: Algo de contrôle de la congestion TCP: BBR
Posté par: vivien le 16 février 2024 à 18:03:27
NoIP n'est pas compatible IPv6, l'IPv6 étant fixe, tu peux la mettre à la main sur ton PC.
Titre: Algo de contrôle de la congestion TCP: BBR
Posté par: vincentimes le 17 février 2024 à 14:07:09
NoIP n'est pas compatible IPv6, l'IPv6 étant fixe, tu peux la mettre à la main sur ton PC.

Peux-tu me donner un peu plus d'explications ?

Je dois renseigner quoi dans l ip v6 de ma carte réseau vivien stp ?

Pourtant je n'ai pas le dhcp activé en ip v 6 sur ma freebox.
Titre: Algo de contrôle de la congestion TCP: BBR
Posté par: buddy le 17 février 2024 à 17:36:32
Bonjour,

depuis le printemps 2019, il n'est pas possible de désactiver IPv6 sur les Freebox, par conséquent ton PC récupère une IPv6 via SLAAC et non DHCP.
Si tu vas sur le site http://ip.lafibre.info, tu verras que tu as une IPv6.

C'est l'IPv6 du serveur  depusi lequel du télécharge / vers lequel tu envoies qu'il faut que tu récupères pour t'y connecter.
Titre: Algo de contrôle de la congestion TCP: BBR
Posté par: vincentimes le 17 février 2024 à 17:48:02
Bonjour,

depuis le printemps 2019, il n'est pas possible de désactiver IPv6 sur les Freebox, par conséquent ton PC récupère une IPv6 via SLAAC et non DHCP.
Si tu vas sur le site http://ip.lafibre.info, tu verras que tu as une IPv6.

C'est l'IPv6 du serveur  depusi lequel du télécharge / vers lequel tu envoies qu'il faut que tu récupères pour t'y connecter.

D’accord, donc actuellement je me connecte au synology chez mon père en passant par no ip en ipv4.

Si je comprends bien je dois récupérer son ipv6 et je dois renseigner cela dans mes dns ? Car no ip ne gère pas l’ipv 6.
Titre: Algo de contrôle de la congestion TCP: BBR
Posté par: buddy le 17 février 2024 à 22:25:27
ça peut être une solution oui.
Tu peux aussi la "sauver" dans un fichier et la taper directement dans le champ serveur de filzilla.

Mais pourquoi dis tu que no ip ne gère pas IPv6 ?
https://blog.noip.com/no-ip-now-offers-ipv6-dynamic-dns
https://www.noip.com/support/knowledgebase/automatic-ipv6-updates-linux-duc
Titre: Algo de contrôle de la congestion TCP: BBR
Posté par: vincentimes le 17 février 2024 à 22:33:21
ça peut être une solution oui.
Tu peux aussi la "sauver" dans un fichier et la taper directement dans le champ serveur de filzilla.

Mais pourquoi dis tu que no ip ne gère pas IPv6 ?
https://blog.noip.com/no-ip-now-offers-ipv6-dynamic-dns
https://www.noip.com/support/knowledgebase/automatic-ipv6-updates-linux-duc

Parce que Vivien m’avait indiqué que cela n’était pas compatible.
Titre: Algo de contrôle de la congestion TCP: BBR
Posté par: vivien le 17 février 2024 à 22:54:45
Bonne nouvelle, j'avais regard il y a quelques années et ce n'était pas compatible IPv6, mais cela a changé, c'est bien.
Titre: Algo de contrôle de la congestion TCP: BBR
Posté par: vincentimes le 17 février 2024 à 23:01:51
Bonne nouvelle, j'avais regard il y a quelques années et ce n'était pas compatible IPv6, mais cela a changé, c'est bien.

T’inquiète Vivien. Moi je n’y connais rien du tout alors j’étais pas prêt de savoir que ça supportait l’ipv6 hé hé.

Je te remercie beaucoup de ton aide surtout -).

Je vais voir si cela change quoi que ce soir mais en ipv4 je tourne plus souvent à 40 mo maintenant.

Avant sous Windows 10 et sans bbr c’était 10/15 mo peu importe la journée.
Titre: Algo de contrôle de la congestion TCP: BBR
Posté par: vincentimes le 25 février 2024 à 07:39:45
Bonjour tout le monde,

Je n'ai pas encore changé mon adresse ip dans no ip en revanche je peux dire que depuis le passage de windows 11 + refresh de mon pc + BBR2 activé en de hors des heures de pointes je plafonne à 70/79 Mo/s c est un regal.

Comme quoi le soucis ne vient ni du synology, ni de ma latence entre opérateur puisque je suis a 13 ms.

Je vous ferais un retour une fois l ip 6 activé car le soir le débit est facilement divisé par 2.
Titre: Algo de contrôle de la congestion TCP: BBR
Posté par: vincentimes le 15 mars 2024 à 22:59:47
Bonsoir tout le monde,

alors je viens de passer de la freebox delta -> ultra.

Je rencontre de nouveau soucis ftp ... je suis bloqué et bridé à 2mo/s peu importe l'heure de la journée pour envoyé sur le synology de mon père alors que cela s'était amélioré avec la congestion BBR ....

Si je passe en http même soucis en allant déposer directement le fichier via l interface du synology

Je n'ai absolument rien changé sur mon ordinateur ni chez mon père.

Avez-vous des pistes à me soumettre ?

Test fait par ftp pour rapidgator aucune soucis 500 mo/s.
Titre: Algo de contrôle de la congestion TCP: BBR
Posté par: LROB le 17 mars 2024 à 23:59:08
Avez-vous des pistes à me soumettre ?

Malheureusement, le conseil que j'ai envie de donner est de choisir un opérateur dont le réseau n'est pas congestionné, si tu le peux, ça limite les problèmes.  ::)  Free semble être le pire élève à ce niveau.

Par ailleurs je ne comprends pas pourquoi tes captures montrent des débits différents de ce que tu reportes. Il n'y aurait pas des confusions entre MegaByte et Megabit?
Titre: Algo de contrôle de la congestion TCP: BBR
Posté par: LROB le 18 mars 2024 à 00:03:15
Je viens de prendre une claque monumentale en lisant l'intégralité de ce topic.  :-X
Merci pour le partage. J'en apprends tous les jours sur le réseau en ce moment, en particulier grâce à lafibre.info, tous les chemins mènent ici.

De nombreuses lumières se sont éclairées, expliquant de nombreux comportements qui semblaient aléatoires en fonction des sources sur un réseau congestionné... En particulier chez Free et OVH FTTH où le réseau est certainement le plus congestionné que j'ai pu connaître.

C'est fou la diff que peut faire BBR versus Cubic. J'ai testé entre un premier serveur Hetzner BBR > OVH FTTH, ça multiplie le débit par un facteur 2 à 3, passant de 200-250Mbit/s à 550-650Mbit/s.

J'ai vraiment l'impression que le BBR c'est "chacun pour sa poire".
Vais-je trop loin dans mes conclusions en imaginant que Google et consœurs vampirisent  tout le réseau avec leur BBR, forçant tout le monde à y passer s'ils ne veulent pas se trouver en retrait sur les réseaux congestionnés ?

Du coup je viens de passer tous mes serveurs Hetzner en BBR en espérant que ça aide pour les interco vers la France pas toujours au top (Free en particulier...). Les backups devraient se faire un poil plus vite (j'essaierai de trouver le temps pour checker les graphes Netdata demain).

Comportement un peu spécial sur un download HTTPS depuis une VM d'un hôte de virtu custom Hetzner, ça améliore légèrement le débit moyen mais en réduisant le débit peak.
(Premier peak en Cubic, 2e en BBR)
(https://cloud.lrob.fr/s/oj8i2ctYqdyn5jx/download/bbr.jpg)

Download d'un .zip de 833MB depuis l'hôte de cette VM en HTTPS aussi :
(https://cloud.lrob.fr/s/LKbeM28EQpjHJBz/download/bbr%20vs%20cubic%20download.png)
Titre: Algo de contrôle de la congestion TCP: BBR
Posté par: Fyr le 18 mars 2024 à 00:41:04
J'ai vraiment l'impression que le BBR c'est "chacun pour sa poire".

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

https://freebsdfoundation.org/our-work/journal/browser-based-edition/rack-and-alternate-tcp-stacks-for-freebsd/

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.
Titre: Algo de contrôle de la congestion TCP: BBR
Posté par: LROB le 18 mars 2024 à 00:54:14
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.

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) :

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 :

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
Titre: Algo de contrôle de la congestion TCP: BBR
Posté par: LROB 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.

(https://cloud.lrob.fr/s/zP9mtczfCGrS5be/download/backup%20cubic%20vs%20bbr.png)

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.
Titre: Algo de contrôle de la congestion TCP: BBR
Posté par: Fyr le 19 mars 2024 à 12:02:37
Tu sais les algos de congestion ça marche... quand il y a de la congestion.
Titre: Algo de contrôle de la congestion TCP: BBR
Posté par: LROB 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.
Titre: Algo de contrôle de la congestion TCP: BBR
Posté par: LROB 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.

(https://cloud.lrob.fr/s/QGQppcwbiqzPgFr/download/backup%20orange.png)

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).