Bonjour à tous et merci pour vos nombreux retours,

Il y avait bien un problème de calcul du débit pour les connexions en THD avec un ping supérieur à ~8ms.
Nous avons mis à jour notre algorithme pour ne plus être dépendant du ping. Nous avons également ajouté un second serveur pour mieux répartir la charge. Chaque serveur ayant un débit de 10 Gb/s.
Je vous invite à tester de nouveau notre test de débit et de nous faire un retour sur ces optimisations : https://www.quechoisir.org/outil-speedtest-n64483/

Cordialement

Bonjour à tous et merci pour vos nombreux retours,

Il y avait bien un problème de calcul du débit pour les connexions en THD avec un ping supérieur à ~8ms.
Nous avons mis à jour notre algorithme pour ne plus être dépendant du ping. Nous avons également ajouté un second serveur pour mieux répartir la charge.
Je vous invite à tester de nouveau notre test de débit et de nous faire un retour sur ces optimisations : https://www.quechoisir.org/outil-speedtest-n64483/

Cordialement

c'est toujours des paquets de 60 ko mais sur 2 serveurs en meme temps... vous ne comprenez pas comment marche un échange de donnée avec acquittement ?

client : envoi moi 60 ko
serveur: voila 60 ko
client: envoi moi 60ko
serveur: voila 60 ko
...
ce type d’échange est toujours dépendant de la latence et ne peut atteindre 1 Gbps avec 4 flux par serveur en meme temps au delà de 8 ms de latence. pour chaque +4ms de latence il vous faut un nouveau serveur...

Je vous invite a lire  : https://en.wikipedia.org/wiki/Bandwidth-delay_product

@Anonyme : Ça ne serait pas la machine qui saturerait ?

Moi je vois une légère différence positive pour le débit descendant qui était déjà bon et le débit montant est presque doublé et correspond à ce que j'obtiens avec d'autres tests de débit.

Moi je vois une légère différence positive pour le débit descendant qui était déjà bon et le débit montant est presque doublé et correspond à ce que j'obtiens avec d'autres tests de débit.

Je vois moi aussi une légère amélioration du débit descendant, qui était déjà bon, j'arrive pratiquement au max de la liaison, mais je ne sais pas si c'est significatif.

Bonjour,

Le 2e serveur a été ajouté uniquement pour optimiser la charge.
La modification porte justement sur la nécessité d'acquitement des paquets qui sont maintenant streamés directement par le serveur sans intervention de la part du client.
La partie upload utilise des envois de paquets massifs de façon identique, c'est à dire sans attendre d'acquitement.

hum dangereux pour vos serveurs de streamer comme ca...mais bon j'en dirais pas plus ici.

Ca progresse mais il manque un truc: vous n'avez pas de cypher adaptatif a ce que demande le client, du coup Chrome sur des machines un peu faiblardes sans support AES hardware est très pénalisé par votre test. Votre site négocie un meilleur cypher avec Edge mais Edge est de toute facon abandonné et pas représentatif de la majorité des utilisateurs. Chrome sera bien plus performants avec chacha20 sur ce type de machines (et sur les mobiles en général).

Exemple sur un I7-920 avec Chrome : j'obtient maxi 300 Mbps environ , 930 Mbps avec Edge (930 Mbps avec Chrome sur Speedtest.net chez Testdebit.info (cypher CHACHA20_POLY1305)).

Selon le dernier "Steam hardware survey" (derniere ligne 'Other settings' tout en bas) il y a encore 13% de PC sans AES/AVX. 13% de PC qui ont installé Steam donc sans doute bien plus si on prend la population générale.

la mesure de l'upload donne des résultats fantaisistes et bug (j'ai pas été voir le nouveau code):

mon abo est 1G/250M (j'ai pas encore l'upgrade a 500M up):



avec UFC-QC, le test d'upload ne fini jamais et affiche d'entrée 380M (alors qu'un test d'upload a toujours un plus long "ramp-up"):