Auteur Sujet: Vitesse de croisière d'un speedtest (Lu 3010 fois)

willemijns · « **le:** 31 octobre 2018 à 23:32:34 »

Hello soit ces 3 speedtests

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

Hugues · « **Réponse #1 le:** 31 octobre 2018 à 23:46:56 »

TCP Slow Start, rwin

willemijns · « **Réponse #2 le:** 31 octobre 2018 à 23:53:56 »

Citation de: Hugues le 31 octobre 2018 à 23:46:56

TCP Slow Start, rwin

le rwin augmente à la durée

vivien · « **Réponse #3 le:** 01 novembre 2018 à 08:39:45 »

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.

willemijns · « **Réponse #4 le:** 01 novembre 2018 à 09:54:51 »

Merci, je comprends mieux

doctorrock · « **Réponse #5 le:** 01 novembre 2018 à 20:09:44 »

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 ^^

willemijns · « **Réponse #6 le:** 01 novembre 2018 à 20:18:38 »

speedguide.net donne cela en non persistant:

Code: [Sélectionner]

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

vivien · « **Réponse #7 le:** 01 novembre 2018 à 21:07:55 »

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)

willemijns · « **Réponse #8 le:** 01 novembre 2018 à 21:28:40 »

Je vais virer les 2 parametres et je te dirais quoi...