Je confirme que dans les 2 cas, cela m'indique qu'il s'agit d'un serveur hébergé à Paris.
Alors comment expliquer ce que j'ai observé clairement ?
J'ai essayé une désactivation/réaction de la connexion réseau, et même un reboot du serveur (bon, là c'est merci à ma jeune fille - c'est irrésistible le bouton allumé en bleu d'un NUC-, mais ça a eu le mérite de prouver que ça ne venait pas de la VM, au moins...). Dans les deux cas, ça n'a rien amélioré.
Alors que dès que je suis passé de paris.xxx à bouygues.xxx, directement tout est allé mieux...

C'est étonnant que tu vois une différence entre paris.testdebit.info, bouygues.testdebit.info.

Les IP sont différentes mais, pour un client Free, c'est la même machine et si un port iPerf3 est utilisé avec paris.testdebit.info il sera inutilisable pour bouygues.testdebit.info

Lorsque j’ai le problème, je n’ai pas de réponse du serveur avant un timeout probable.
Edt-ce qu’il ne pourrait pas y avoir un problème de routage, en l’occurrence en IPv6, sur le nom paris.xxx là où ce souci n’existe pas avec bouygues.xxx ?

Breizh29, serait-il possible d'indiquer ici chaque changement de configuration ?

Cela permet de savoir quel modification sur la courbe est liée à quelle modification.

C'est vraiment pratique pour exploiter les résultats.

Je suis aussi preneur du processeur de ton mac (tu me l'a donné, mais quand j'ai cherché, impossible de le retrouver)

Pour ton NUC10 + Solo 10G , je suis intéressé par :
- lscpu
- lspci (je n'ai jamais eu de Thunderbolt 3, je ne sais pas si cela apparaît dans un lspci)
- free -m
- lsb_release -a
- uname -a
- version iPerf3 utilisée
- les optimisation réalisées.

Exemple avec l'optimisation du coté serveur : Fichier /etc/sysctl.d/90-server-optimization.conf
# Reduce the swap
vm.swappiness = 1

# 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 = 512
Enfin je te remercie pour tes tests qui intéressent beaucoup de monde (certains personnes ont tenté de comparer BBR et Cubic sur un réseau de test, sans aucune perte de paquets et ils étaient étonnés de ne pas voir de différences).

Un vrai réseau avec des vraies pertes et une latence non nulle est vraiment idéal pour comparer les algorithmes de congestion.

Avec bbr depuis la VM Ubuntu, j'ai passé la soirée au-dessus des 7 Gb/s en multithread, et d'honorables 3,6 à 4 Gb/s en monothread
C'est impressionnant !
Hâte de le mettre à l'épreuve du dimanche soir...

Merci pour les info sur la première page, j'avais zappé.

C'est un i7 8700B

Le Core i7-8700B est un 6 cœurs / 12 threads 3,2 GHz en fréquence de base / 4,6 Ghz en boost.
Ce qui est impressionnant, c'est le TDP/PDT de 65 watts pour un processeur catégorisé "mobile"

Cela change de mon Core i5-8250U : 4 cœurs / 8 threads à 1,6 GHz en fréquence de base / 3,4 Ghz en boost en un TDP/PDT de 15 watts.

J'ai amélioré ma gestion du timeout dans le script, car IPv6 est depuis ce midi encore dans les choux sur le serveur (en tout cas, depuis chez moi, ça "tombe dans le vide" en v6 là où je n'ai pas de problème en v4 - et j'ai encore validé que relance réseau ou reboot VM ne solutionnait pas).
Du coup, si je tombe en timeout dans un protocole, je ne poursuis pas les tests pour ce protocole.

PS: lors des soucis, ping et traceroute fonctionnent toujours.

PS2: revenu depuis 17h10. Vivien, tu as corrigé quelque chose ?