Auteur Sujet: Latence des clients Free Pro  (Lu 32709 fois)

0 Membres et 1 Invité sur ce sujet

kgersen

  • Modérateur
  • Abonné Bbox fibre
  • *
  • Messages: 9 091
  • Paris (75)
Latence des clients Free Pro
« Réponse #180 le: 12 juillet 2022 à 09:55:17 »
Tu peux m'en dire plus sur les réglages que tu utilises ?
Quel est la difference par rapport aux miens ?

Mes réglages :
net.ipv6.conf.all.disable_ipv6 = 1
net.ipv4.tcp_congestion_control=bbr
net.core.wmem_max = 16777216
net.core.wmem_default = 131072
net.core.rmem_max = 16777216
net.core.rmem_default = 131072
net.ipv4.tcp_rmem = 4096 131072 16777216
net.ipv4.tcp_wmem = 4096 131072 16777216
net.ipv4.tcp_mem = 4096 131072 16777216
net.core.netdev_max_backlog = 30000

c'est surtout wmem_max et rmem_max qui comptent car ils imposent une limite que les logiciels ne peuvent dépasser. Dans ton cas 16M ca suffit pour la plus part des usages.
pour tcp_rmem et tcp_wmem  la dernière est importante aussi et pour certains logiciels mal conçu celle du milieu.

Ces valeurs concernant les tailles maxi de tampon d'envoi et réception. Ils servent a monter en débit au détriment de la consommation mémoire.
Avec une taille trop petite et suivant la latence on ne peut dépasser un certain débit quoi qu'on fasse. C'est ce qu'on appelle le https://en.wikipedia.org/wiki/Bandwidth-delay_product
Pour atteindre des débits élevés de plusieurs Gbps il faut de toute facon des grands tampons c'est mathématiquement inévitable.
Certaines distro de Linux ont des réglagles par défaut un peu trop faible pour l'univers du 10Gbps et conviennent plus pour une époque ou on ne dépassait jamais 1 Gbps.

Cela c'est pour une seule connexion, on peut dépasser les limites de l'OS et/ou de la latence en utilisant plusieurs connexions en parallèle c'est ce que font les speedtest en ligne.
Mais peu de logiciel font cela.

Tu peux calculer les valeurs optimals avec un outil comme: https://www.switch.ch/network/tools/tcp_throughput/ (2eme partie du calculateur).
par exemple pour obtenir 10Gbps avec un serveur qui a 10ms de latence, il faut un tampon de 12,50 Mo ( https://www.switch.ch/network/tools/tcp_throughput/?mss=1460&rtt=80&loss=1e-06&bw=10000&rtt2=10&win=64&Calculate=Calculate  ). Mais c'est théorique. Utiliser 16Mo suffit donc dans la plupart des cas. Il n'est pas recommandé d'avoir en dessous de 2,5 Mo pour les max.
I

Pour ce qui est de bbr vs cubic, il y a plusieurs sujets sur le forum. BBR est l'algo recommandé de nos jours. Ca ne concerne que l'émétteur donc l'upload dans ton cas.

Il savoir aussi qu'on est en plein transition vers UDP via l'utilisation de QUIC pour remplacer TCP. Actuellement 20% du trafic mondial a déjà basculé notamment a cause des gros comme Google, Facebook, etc. Pour UDP les parametres qui importent sont juste net.core.rmem_max et net.core.wmem_max et net.ipv4.udp_mem (il n'est pas recommandé de toucher ce dernier qui est dépendant de la RAM dispo au boot).




« Modifié: 12 juillet 2022 à 14:44:26 par kgersen »

daleksek

  • Abonné Orange Fibre
  • *
  • Messages: 1 359
Latence des clients Free Pro
« Réponse #181 le: 12 juillet 2022 à 18:34:43 »
Je confirme quand j'étais chez Free Pro, mon serveur linux avec une carte 10Gbits atteignait toujours le max de l'upload avec le BBR activé, alors que sur Windows (qui ne peut pas utiliser BBR) c'était très rare.

Le fait que j'avais une très grosse latence, ne devait pas aider non plus, mais je pense qu'il doit y avoir comme des pertes de paquets sur le réseau Free, chez Orange aucun problème avec le même matos réseau, pour atteindre les 1Gbits d'upload avec ou sans BBR

CLusmi

  • Abonné Free Pro
  • *
  • Messages: 11
  • Angers (49)
Latence des clients Free Pro
« Réponse #182 le: 18 juillet 2022 à 19:34:29 »
c'est surtout wmem_max et rmem_max qui comptent car ils imposent une limite que les logiciels ne peuvent dépasser. Dans ton cas 16M ca suffit pour la plus part des usages.
pour tcp_rmem et tcp_wmem  la dernière est importante aussi et pour certains logiciels mal conçu celle du milieu.

Ces valeurs concernant les tailles maxi de tampon d'envoi et réception. Ils servent a monter en débit au détriment de la consommation mémoire.
Avec une taille trop petite et suivant la latence on ne peut dépasser un certain débit quoi qu'on fasse. C'est ce qu'on appelle le https://en.wikipedia.org/wiki/Bandwidth-delay_product
Pour atteindre des débits élevés de plusieurs Gbps il faut de toute facon des grands tampons c'est mathématiquement inévitable.
Certaines distro de Linux ont des réglagles par défaut un peu trop faible pour l'univers du 10Gbps et conviennent plus pour une époque ou on ne dépassait jamais 1 Gbps.

Cela c'est pour une seule connexion, on peut dépasser les limites de l'OS et/ou de la latence en utilisant plusieurs connexions en parallèle c'est ce que font les speedtest en ligne.
Mais peu de logiciel font cela.

Tu peux calculer les valeurs optimals avec un outil comme: https://www.switch.ch/network/tools/tcp_throughput/ (2eme partie du calculateur).
par exemple pour obtenir 10Gbps avec un serveur qui a 10ms de latence, il faut un tampon de 12,50 Mo ( https://www.switch.ch/network/tools/tcp_throughput/?mss=1460&rtt=80&loss=1e-06&bw=10000&rtt2=10&win=64&Calculate=Calculate  ). Mais c'est théorique. Utiliser 16Mo suffit donc dans la plupart des cas. Il n'est pas recommandé d'avoir en dessous de 2,5 Mo pour les max.
I

Pour ce qui est de bbr vs cubic, il y a plusieurs sujets sur le forum. BBR est l'algo recommandé de nos jours. Ca ne concerne que l'émétteur donc l'upload dans ton cas.

Il savoir aussi qu'on est en plein transition vers UDP via l'utilisation de QUIC pour remplacer TCP. Actuellement 20% du trafic mondial a déjà basculé notamment a cause des gros comme Google, Facebook, etc. Pour UDP les parametres qui importent sont juste net.core.rmem_max et net.core.wmem_max et net.ipv4.udp_mem (il n'est pas recommandé de toucher ce dernier qui est dépendant de la RAM dispo au boot).

Merci beaucoup pour ta réponse très bien détaillée