Pour la Overthebox, je suppose que le packet loss est mesuré uniquement entre le serveur nPerf et le point de sortie (d'entrée dans le cas du DL) chez OVH car les acquittements des paquets se font ici (avant d'être retransmis à l'utilisateur) non ? Vivien pourra probablement confirmer.

Cela dépend du type du VPN : les VPN basés sur TCP font que les pertes de paquet accès seront ré-émis alors que les VPN UDP vont perdre les paquets, ce qui n'est pas grave car il y a du TCP à l'intérieur.
OpenVPN propose les deux modes (TCP/UDP). La recommandation est de passer en UDP, j'imagine que c'est ce que fait Overthebox, sans avoir de certitude

C'est le même pb avec les NAT opérateurs sur les réseaux cellulaires à priori...

La majorité des opérateurs mobiles coupent la connexion pour améliorer les performances donc le serveur nPerf ne vois pas les pertes sur le réseau mobile.
Par contre chez certains opérateurs, seul le port 80 et le port 443 sont coupés, donc en réalisant un test sur le port 8443 on devrait voir les pertes bout en bout.

Les cyphers utilisés par nperf tuent carrement le cpu sur certains appareils.

Je viens de faire un comparatif sur un PC où c'est le CPU qui limite.
Je vais ouvrir un autre sujet pour ne pas polluer celui-ci sur les Packet Loss.

Edit: réalisé => SpeedTest / nPerf: L'impact du CPU sur les débits

Il me semble que nPerf est le premier test de débit à utiliser TLS 1.3

On en a profité pour mettre à jour les ciphers et ajouter le support TLS 1.3

C'est déployé sur les 4 serveurs concernés par le PacketLoss 

Vous privilégiez Chacha20-Poly1305 même pour les clients qui supportent AES-NI, c'est un choix ?

Je capte pas pourquoi nperf est toujours faiblard en download:

depuis un chromebook en wifi (>500 Mbps vérifié en local) sur une connexion fibre 1G/250M Bytel:

SFR - packet loss affiché: 0.01%


Bytel:


avec speedtest:



j'ai fait plusieurs fois les tests pour évacuer tout souci de wifi. c'est constant a 20Mbps pres.

c'est un i5-7Y57

j'obtient 500+ avec Massy (toujours en wifi):



ce chromebook atteint 940 en filaire avec un adapteur ethernet_usb-c.

J'ai aucun souci avec speedtest ou iperf, curl, wget, etc, y'a que nperf qui se traine en download avec un cpu pas a fond (60% au max sur un des cores).

je ne pense pas, j'ai une autre machine pas trop puissante sous Win10 qui a le meme souci avec nperf.

j'ai testé avec un 'user-agent' switcher , nperf voit bien ce que lui dit le switcher (chrome win10), le résultat est le meme.

Je pense que leur code est juste un peu trop gourmant  en cpu. je ne vois que ca comme explication.