Auteur Sujet: Plusieurs Gbps en une session TCP à haute latence ?  (Lu 901 fois)

0 Membres et 1 Invité sur ce sujet

eahlys

  • Expert
  • Abonné Free fibre
  • *
  • Messages: 1 099
  • Shadow AS64476 & AS396919
Plusieurs Gbps en une session TCP à haute latence ?
« le: 21 octobre 2022 à 17:08:02 »
Hello à tous,

J'ai besoin de vos lumières :)

Je cherche à transférer de grandes quantités de données sur une distance importante (UE<->USA).
J'ai deux serveurs Debian avec une connectivité 10Gbps, et une latence de 100ms.
J'arrive pas à monter à plus de 270Mbps par thread TCP avec iPerf3 (Cubic ou BBR, cela ne change rien). J'ai joué avec les window TCP mais je connais un peu moins les meilleurs paramètres à utiliser pour ça, donc c'est moins mon rayon.

Quand je prends ces deux mêmes serveurs et que je les mets côte à côte dans le même DC, j'ai bien mes 10Gbps avec un seul thread TCP (mais une latence de <1ms ça aide).
Voilà voilà, je prends toutes les suggestions au cas où je passe à côté de quelque chose de plus ou moins évident.

Bonne journée :)

kgersen

  • Modérateur
  • Abonné Bbox fibre
  • *
  • Messages: 9 078
  • Paris (75)
Plusieurs Gbps en une session TCP à haute latence ?
« Réponse #1 le: 21 octobre 2022 à 19:32:08 »
en théorie il faut le double du 'Bandwidth-delay product' en taille de buffer :

avec ce calculateur, https://www.switch.ch/network/tools/tcp_throughput/, en mettant 10 Gbps et 100ms on obtient:

Citer
required tcp buffer to reach 10000 Mbps with RTT of 100.0 ms >= 122070.3 KByte

ca fait 122 Mo ce qui est plus que le défaut maxi de la plupart de OS.

mais il faut aussi tenir compte des pertes donc ca ne sert a rien de monter trop la taille des buffers si de toute facon ils ne seront jamais rempli a 100%. Comme indique ouno, fait des mesures en udp avant pour connaitre le taux de perte ca donnera le débit maxi possible sur une session. A partir de la tu peux calculer la taille des buffers (ou prendre la taille théorique si l'OS le supporte).

sur Linux c'est:

# tailles maxi des buffers
net.core.rmem_max (reception)
net.core.wmem_max (emission)

# taille des buffers tcp (3 valeurs min default max)
net.ipv4.tcp_rmem (reception)
net.ipv4.tcp_wmem (emission)

Par exemple pour mettre 122070.3 KByte:
net.core.rmem_max = 122070300
net.core.wmem_max= 122070300
net.ipv4.tcp_rmem = 4096    65536  122070300
net.ipv4.tcp_wmem = 4096   65536  122070300
A mettre dans /etc/sysctl.conf ou mieux dans un ficher de ton choix , par exemple /etc/sysctl.d/reglages_tcp.conf

puis
sudo sysctl --system
pour appliquer les changements.

Optix

  • AS41114 - Expert OrneTHD
  • Abonné Orne THD
  • *
  • Messages: 4 644
  • WOOHOO !
    • OrneTHD
Plusieurs Gbps en une session TCP à haute latence ?
« Réponse #2 le: 21 octobre 2022 à 19:46:19 »
Et en utilisant un protocole qui repose sur UDP plutôt que TCP ? Genre bittorrent ou http3 ?

Fyr

  • Abonné Free fibre
  • *
  • Messages: 783
  • Talissieu 01
Plusieurs Gbps en une session TCP à haute latence ?
« Réponse #3 le: 22 octobre 2022 à 15:01:48 »
Sur le receveur des données :

Les SACK aussi. net.ipv4.tcp_sack = 1

Et le delais des paquets ACK https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux_for_real_time/7/html/tuning_guide/reducing_the_tcp_delayed_ack_timeout

Le delais c'est pour les envoyer en rafale, sans delais l'ACK est immédiat à chaque paquet

simon

  • Abonné Orange Fibre
  • *
  • Messages: 935
Plusieurs Gbps en une session TCP à haute latence ?
« Réponse #4 le: 22 octobre 2022 à 17:21:07 »
La limite de 270Mbit/s, est-elle stable et reproductible entre plusieurs tests ? Peux-tu faire des traceroute entre tes différents serveurs ?
As-tu moyen de faire des tests en ipv6 et ipv4, et potentiellement depuis un des serveurs en question (celui aux US, par exemple) vers un serveur speedtest en UE ?
Si tu effectues deux tests iperf simultanément, qu'obtiens tu ?

Il est facile de saturer un lien multi-Gbit/s quand on reste dans le même datacenter car le réseau est souvent généreusement dimensionné. Pour les liens inter-DC (même chez le même provider), à fortiori lorsqu'on passe d'un continent à l'autre, la capacité du réseau est souvent bien plus faible.