La Fibre
Télécom => Réseau => TCP/IP / Fonctionnement des réseaux => Discussion démarrée 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.
-
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).
-
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.
-
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
-
illinois est recomandé pour high-speed and long-distance networks
heu ca date un peu ton truc la :P
recommandé par qui ?
-
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
-
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.
-
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 !
-
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
-
Ç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 !
-
Il y a des options équivalentes sous Windows mais je ne suis pas sûr que l'algo BBR ait été implémenté.
-
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.
-
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?
-
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.
-
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.
-
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é)?
-
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.
-
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
-
Tiens... faudrait que je m'intéresse à cet algo sur MacOS aussi alors...
-
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.
-
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/))
-
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/
-
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.
-
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
-
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)
-
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.
-
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.
-
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
-
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.
-
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é.
-
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)
-
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 ?
-
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.
-
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.
-
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:
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.
-
tu sort d'ou ces chiffres ? on en trouve aucune trace/mention ni dans le blog, ni l'article ni la conf.
Le tableau
-
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.
-
Plutôt 110% de bénéfice.
Tout à fait, ils atteignent 115% sur le palier 200 ms de RTT et 500Mbs
-
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%
-
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.
-
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
-
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
-
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.
-
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
-
modifier tcp_allowed_congestion_control plutot que donner cap_net_admin a iperf3 me parait plus simple et sur.
-
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
-
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)
-
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 ?
-
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
-
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)
-
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
-
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)
-
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)
-
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)
-
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)
-
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)
-
Petit graphique proposé par Google pour comparer BBR à Cubic :
(https://lafibre.info/testdebit/linux/202002_google_tcp_bbr.gif)
-
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
-
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.
-
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
-
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
-
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)
- Un résumé sur le blog du RIPE Labs: https://labs.ripe.net/Members/ranysha_ware/modelling-bbr2019s-interactions-with-loss-based-congestion-control
- Le papier en question (ACM): https://dl.acm.org/authorize?N695087
- La présentation lors de la conférence: https://vimeo.com/showcase/6531379/video/369121357#t=999s
Bonne lecture :)
-
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
-
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)
-
Effet de l'algorithme de contrôle de la congestion sur une connexion FTTH avec une collecte saturée (à priori) :
- .\wget.exe -O NUL https://iperf.online.net/1000Mo.dat --> 37.3 Mo/s
- .\wget.exe -O NUL http://scaleway.testdebit.info/1G/1G.iso --> 106 Mo/s
-
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 :
- noyau client Linux : 5.5.2
- noyau serveur Linux : 5.4.0
- iPerf 3.7
- Netem pour les dégradations (pckloss coté serveur/latence coté client)
Conf. serveur (merci Vivien)
# 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.
-
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).
-
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.
-
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)
-
@Vivien, J'ai juste récupéré un Ubuntu sur leur site (la 20.04) pour le serveur.
-
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)
-
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.
-
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)
-
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)
-
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)
-
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)
-
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 ?
-
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.
-
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.
-
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
-
Ah, intéressant de le savoir. Je suppose que la version serveur, 2022, pour laquelle c'est le plus intéressant, l'a aussi.
-
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/)
-
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.
-
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
-
aucune idée, c'est quoi ton script d'upload deja ?
-
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);
}
?>
-
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.
-
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
-
- ton script ne fait jamais appel à "move_uploaded_file"; et donc les fichiers temporaires demeurent
non car
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.
-
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.
-
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
-
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.
-
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 "-" "-"
-
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.
-
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
-
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.
-
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).
-
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.
-
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.
-
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)
-
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...
-
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.
-
Upload avec quel logiciel, quel protocole ?
-
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.
-
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)
-
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 ?
-
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.
-
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.
-
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
-
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 -).
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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
-
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).
-
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.
-
Attention à ce que tu postes sur la capture, coquin ;D
-
Et on ne sait toujours pas si c'est du SFTP ou du FTP(S).
-
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é ?
-
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)
-
avec
netsh int tcp show supplemental
ou
Get-NetTCPSetting -SettingName Internet
(4eme ligne)
Pour toi c'est bon ?
-
oui c'est affiché bien 'bbr2'.
-
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.
-
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.
-
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 ?
-
L'IPv6 est déjà activé, il faut par contre renseigner l'IPv6 sur le DNS si tu utilises un nom de domaine.
-
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 ?
-
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
-
NoIP n'est pas compatible IPv6, l'IPv6 étant fixe, tu peux la mettre à la main sur ton PC.
-
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.
-
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.
-
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.
-
ç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
-
ç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.
-
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.
-
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.
-
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.
-
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.
-
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?
-
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)
-
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.
-
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
-
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.
-
Tu sais les algos de congestion ça marche... quand il y a de la congestion.
-
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.
-
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).