LOL vous avez un doute sur la qualité du réseau de votre super hébergeur ?
Je doute que celui-ci vous garantisse les 3 Gbit/s. Donc la question à se poser est : est-ce que j'ai un problème à l'usage ou pas ? Si pas de problème, tout va bien, on s'en fou de ne pas avoir 3 Gbit/s vers le monde entier.
S'il y a un problème par contre, il faudra être plus précis plutôt que de faire des tests vers n'importe où.

Là vous ne testez que Bouygues Telecom <=> OVH.

Bouygues Telecom est connu pour ne pas saturer ses interconnexions, mais des exceptions ou incidents sont possibles.

Les 4 serveurs sont dans une configuration senblable (Ubuntu server 18.04 LTS avec noyau HWE, connexion 10 Gb/s via une carte Intel Ethernet Converged Network Adapters X710 DA-2)

Ce qui change entre ces 4 serveurs, c'est la latence, lié à la vitesse de lumière dans un cœur de silice.

Si le débit est bien le débit en régime établit, cela montre une saturation du nombre de paquets en vol (paquets non acquittés).

Je me demande si une optimisation des buffers sur le machine OVH ne permettrait pas d'être moins dépendant à la latence.

Serait-il possible de connaître le système d'exploitation utilisé coté OVH pour pouvoir donner des conseils ?

Si c'est un Ubuntu / Debian serait il possible de tester après avoir mis ce fichier ?
C'est ce qui est en place sur les serveurs que vous avez testé.

sudo nano /etc/sysctl.d/90-server-optimization.conf

Code: [Sélectionner]

# 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 = 4096

Il pourrait être intéressant de comparer les test avec Linux avant et après avoir passé mes commandes d'optimisation.

Cela serait intéressant de tester le débit descendant également (option -R )

Tu v a voir que c'est pas forcément symétrique...

TCP est fortement impacté par les pertes de paquets.

Pour vérifier si il y en a tu transmet des paquets en UDP à un débit largement inférieur au max pour ne pas saturer la connexion (par exemple 100 Mb/s ou moins) et tu regarde si il y a des pertes. 0,1% de perte de paquet c'est énorme pour TCP, il faut vraiment être bien en dessous.

Pour les tests UDP que tu as mis sous Debian, je vois 2,1% de perte de paquet dans le sens upload et 48% dans le sens download. C'est probablement lié à un débit d'émission trop élevé.