EDIT : à l'instant : je ping paris.xxx en IPv6, mais pas lille.xxx ; en IPv4, tous les pings sont OK

Étonnant. Je ne note pas de pb, c'est toujours le cas ?

$ mtr -rwc100 lille.testdebit.info
Start: Wed Feb 19 15:58:23 2020
HOST: lafibre                        Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- bgp1.adeli.biz                  0.0%   100    0.3  53.1   0.2 2651. 326.6
  2.|-- 6-1-18.ear1.Paris1.Level3.net   0.0%   100   15.2  20.6  14.9 450.4  43.5
  3.|-- lo-0-v6.ear3.Paris1.Level3.net  0.0%   100   14.7  14.8  14.6  15.5   0.0
  4.|-- 2001:1900:5:2:2::4a52           0.0%   100    7.7   7.7   7.6   8.1   0.0
  5.|-- 2001:860:bbee:42::2             0.0%   100   11.0  11.1  11.0  11.4   0.0
  6.|-- 2001:860:bbe0:af::2             0.0%   100   11.4  11.5  11.4  11.7   0.0
  7.|-- 2001:860:b212::3:2              0.0%   100   11.6  11.6  11.5  11.8   0.0
  8.|-- 2001:860:de12:200::2            0.0%   100   10.9  10.9  10.8  11.0   0.0

$ mtr -rwc100 lille.testdebit.info
Start: Wed Feb 19 17:53:02 2020
HOST: lafibre                        Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- bgp1.adeli.biz                  0.0%   100    0.3 111.3   0.2 2717. 472.0
  2.|-- 6-1-18.ear1.Paris1.Level3.net   0.0%   100   15.1  18.1  14.9 218.5  20.5
  3.|-- lo-0-v6.ear3.Paris1.Level3.net  0.0%   100   14.8  14.8  14.7  15.4   0.0
  4.|-- 2001:1900:5:2:2::4a52           0.0%   100    7.6   7.6   7.5   8.1   0.0
  5.|-- 2001:860:bbee:42::2             0.0%   100   11.1  11.1  11.0  11.6   0.0
  6.|-- 2001:860:bbe0:af::2             0.0%   100   11.5  11.5  11.4  11.7   0.0
  7.|-- 2001:860:b212::3:2              0.0%   100   11.6  11.6  11.5  11.8   0.0
  8.|-- 2001:860:de12:200::2            0.0%   100   10.9  10.9  10.8  11.0   0.0

Bon, c'est clairement un problème de la VM Linux.

Depuis le mac, je ping les 2 IPv6 sans souci.

Depuis la VM, ça pingait sur paris mais pas sur Lille.
J'ai désactivé / réactivé la connexion réseau, et là ça ping sur Lille (d'où mon "revenu !"), mais plus sur Paris (sic).

Je deviens fou. Je vais me changer les idées... 

EDIT: j'ai refait des tests à tête reposée sur la VM: je confirme bien que ça ping sur lille, mais pas paris... et les tests iperf3, eux, tournent.

Je suis toujours en train de modifier mes scripts pour tester et ainsi comparer les algos de gestion de la congestion TCP.

@Vivien
A ce jour, quels sont les algos qui peuvent être spécifiés ?
cubic et bbr, j'ai fait lors de tests, c'est OK. A part ça ? illinois, toujours pas ? reno, autre ?

Je suis également toujours preneur, en préalable, de paramètres de la stack TCP à injecter avant de lancer les mesures enregistrées (sysctl.conf...).

Merci.

En fait c'est toi qui congestionne le reseau! 

Seul reno cubic bbr sont disponibles.

Pour avoir plus il faut trouver l'origine de mon problème :

$ cat /proc/sys/net/ipv4/tcp_congestion_control
cubic

$ cat /proc/sys/net/ipv4/tcp_allowed_congestion_control
reno cubic bbr

Cubic est l'algorithme de congestion TCP par défaut.
Vous pouvez choisir reno ou bbr

J'ai essayé de proposer htcp et illinois, mais cela ne fonctionne pas. Pour faire la chose proprement, j'ai crée un fichier /etc/modules-load.d/tcp_allowed_congestion_control.conf dans lequel je charge les 3 algorithme à proposer.

sudo nano /etc/modules-load.d/tcp_allowed_congestion_control.conf

Code: [Sélectionner]

# TCP congestion control protocol
# cat /proc/sys/net/ipv4/tcp_allowed_congestion_control
tcp_bbr
tcp_htcp
tcp_illinois
Seul bbr est rendu disponible par mon fichier

Pourtant, les fichiers .ko sont bien présents :

# locate tcp_bbr
/lib/modules/5.3.0-24-generic/kernel/net/ipv4/tcp_bbr.ko
/lib/modules/5.3.0-26-generic/kernel/net/ipv4/tcp_bbr.ko

# locate tcp_htcp
/lib/modules/5.3.0-24-generic/kernel/net/ipv4/tcp_htcp.ko
/lib/modules/5.3.0-26-generic/kernel/net/ipv4/tcp_htcp.ko

# locate tcp_illinois
/lib/modules/5.3.0-24-generic/kernel/net/ipv4/tcp_illinois.ko
/lib/modules/5.3.0-26-generic/kernel/net/ipv4/tcp_illinois.ko

Si vous avez une idée pour proposer htcp et illinois, je suis preneur.

Optimisations réseau et swappiness :
nano /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
Voici la configuration mise en place sur mes serveurs :
nano /etc/modules-load.d/tcp_allowed_congestion_control.conf
# TCP congestion control protocol
# cat /proc/sys/net/ipv4/tcp_allowed_congestion_control
tcp_bbr

Bonsoir,

Voici comme promis un graphique comparant les débits en téléchargement Cubic / BBR, en monothread / multithread, sur une semaine de mesures.

C'est uniquement de l'IPv6 ou uniquement de l'IPv4 ?

Uniquement de l'IPv6 (cf. fin du titre du graphique).
De toute façon, a priori, ce serait similaire en IPv4, avec un débit légèrement moindre en général.

La configuration n'a pas changé, excepté le passage à 8 Go sur la VM ?

Il y a eu un changement par rapport à ce tu reprends: iPerf passé en 3.7 (cf. 1er post).
Par ailleurs, je corrige un truc: depuis le début, c'est un ESXi 6.7u3 et non u2.

A noter que les opérateurs vont être consultés prochainement sur le choix de l'algorithme de congestion TCP pour la campagne de test Arcep mobile 2020 (le résultats de la campagne 2019 est sur https://www.monreseaumobile.fr/ )

On est nombreux à pouvoir te remercier, je sais que au vu de tes résultats, certains opérateurs ont lancé des campagnes de test.

Content si ça peut faire avancer le schmilblick (et prêt à d'autres tests, dans la limite de mes compétences...) 
Ce serait bien si les OS comme Windows ou MacOS pouvaient intégrer l'algorithme BBR (que ce soit la version 1 ici testée, ou la proche version 2, a priori un peu moins forte en débit, mais moins agressive sur les retries).
Et j'aimerais aussi comprendre pourquoi, que ce soit sous Windows ou dans une moindre mesure MacOS, je suis assez en dessous des résultats obtenus sous Linux, et comment améliorer cela...

Tu partagerais tes scripts de mesure et de génération du graphique  ?

Oui, ça pourrait le faire, mais il me faut régler quelques détails et je ne suis pas spécialiste Shell/bash, donc indulgence avec ma façon de coder (surtout que le script a évolué en fonction des orientations prises, il n'a pas été pensé totalement générique depuis le début) !