La Fibre
Datacenter et équipements réseaux => Équipements réseaux => 
Infrastructure réseau (opérateurs) => Discussion démarrée par: willemijns le 31 octobre 2018 à 23:32:34
-
Hello soit ces 3 speedtests
(https://u.imageresize.org/v2/9f5ccbb7-0ba6-4b76-97fb-f08229053336.png)
Pourquoi un speedtest loin comme ici en asie met du temps (style 15/20 secondes) à être au taquet ?
J'ai mis une jolie courbe mais cela est la même chose avec plusieurs autres speedtest de différents opérateurs: plus le serveur est loin, plus la pente est douce... pour nous européens c'est asie et amérique latine et l'inverse doit être vrai...
Un des protocoles réseau permet d'ouvrir des buffers plus grand quand la connexion dure longtemps ???
-
TCP Slow Start, rwin :)
-
TCP Slow Start, rwin :)
le rwin augmente à la durée ???
-
A l'époque de Windows XP la Rwin était fixe.
Depuis Windows Vista (et bien avant sous Linux) la Rwin s'adapte automatiquement :
- il n'y plus de problème de Rwin trop grande (une Rwin trop grande entraîne un dépassement des buffers, donc des pertes de paquets et une baisse du débit)
- il n'y a plus de problème de Rwin trop petite (une Rwin trop petite limite le débit car il faut attendre les acquittements pour envoyer les paquets suivants)
Une Rwin met du temps à monter quand la latence est élevée.
-
Merci, je comprends mieux
-
Ouai, TCP c'est assez compliqué ^^.
Tu peux tenter de jouer avec, dans /proc/sys/net/ipv[4|6]/tcp_**** . Tu ne joueras par contre que sur un seul coté de la connexion, évidemment ;-)
Attention de ne pas tout casser et de ne pas abuser de la ressource Internet ^^
-
speedguide.net donne cela en non persistant:
sudo sysctl -w net.ipv4.tcp_congestion_control=cubic && sudo ifconfig enp0s7 txqueuelen 50000 && sudo sysctl -w net.ipv4.tcp_timestamps=0 && sudo sysctl -w net.core.rmem_max="8388608" net.core.wmem_max="8388608" net.ipv4.tcp_rmem="4096 87380 8388608" net.ipv4.tcp_wmem="4096 65536 8388608" net.core.netdev_max_backlog="250000" net.ipv4.tcp_no_metrics_save="1" net.ipv4.tcp_moderate_rcvbuf="1" net.ipv4.tcp_fin_timeout="15" net.ipv4.tcp_keepalive_probes="5" net.ipv4.tcp_tw_reuse="1"
je vais voir ce que cela donne...
-
Attention a tes optimisations : désactiver les timestamps peut avoir un effet catastrophique sur les débits.
Les timestamps sont nécessaire dans deux cas :
- Connexions avec des paquets deséquencé
- Connexion haut débit à forte latence, sans les timestamps la rwin ne peut pas monter très haut
Pour donner un exemple concret, en FTTH, il y a une box d'un opérateur français qui entraînait un paquet dé-séquencé lors du déclenchement des accélérateurs. Le débit était de l'ordre de 200 Mb/s sans timestamps et 900 Mb/s avec timestamps.
Pour le protocole de congestion TCP, ce n'est intéressant de le spécifier sur le client que en cas d'upload. Par ailleurs, cubic n'est pas un protocole congestion très agressif.
Voici une comparaison des protocole de congestion TCP. J'ai passé il y a quelques jours https://1.testdebit.info avec TCP-Illinois
(cliquez sur la miniature ci-dessous - le document est au format PDF)
(https://lafibre.info/images/doc/201207_TCP_Congestion_Control_Comparison.png) (https://lafibre.info/images/doc/201207_TCP_Congestion_Control_Comparison.pdf)
-
Je vais virer les 2 parametres et je te dirais quoi...