Trés bonne idée, j'ai plein d'idées pour faire évoluer ce test de débit open source qui n'est pas adapté au trés haut débit (j'ai essayé de le modifier, mais augmenter la taille des fichiers n'es tpas la bonne solution, ca pose pb avec de nombreux navigateurs).
Pour faire un test très haut débit il faut impérativement :
- Prendre le débit en régime établi (au lieux de faire une moyenne du temps de téléchargement / upload d'un fichier)
- Faire un transfert suffisamment long pour laisser a TCP/IP le temps de "monter" en débit
- Faire plusieurs connexions TCP afin de limiter l'
impact de la Rwin limitée de Windows 7 sur le débitAujourd’hui SpeedTest met en pratique ces 3 impératif d’où des résultats meilleurs avec SpeedTest.
Il serait aussi intéressant de proposer : (quelques idées en vrac)
- Un test sur plusieurs ports (pas seulement le port 80) afin de voir une éventuelle QoS qui bride les ports du P2P.
- Indiquer la Rwin max utilisée et le multiplicateur négocié lors du [SYN] (scale factor)
- Indiquer la MTU utilisée en download et en upload
- Indiquer les options TCP activées (Sélectif acquittement, Timestamps, ...)
- Indiquer le ping a vide et le ping pendant le transfert (permet de voir la taille des buffers utilisés)
- Indiquer le % d’acquittement reçus par rapport au nb de paquet envoyé afin de détecter les problèmes de
TCP ACK Supression- Indiquer le % de paquet TCP retransmis (ce qui signifie qu'il y a eu des pertes de paquets)
- Tester si les
ACK sont envoyé par le PC sont priorisés quand il y a un uplaod en //- Proposer un transfert de 1 ou 2 minutes et noter la stabilité du débit
- Sélectionner le serveur le plus proche (via un test de ping des différents serveurs)
- Mettre en base de données les résultats et les présenter sous forme de carte
- test en IPv4 et IPv6
J'ai des bout de code open source pour une grosse partie de ces fonctions.