Auteur Sujet: Wishlist pour la v2.0 de SpeedZilla  (Lu 4311 fois)

0 Membres et 1 Invité sur ce sujet

m1ko

  • Invité
Wishlist pour la v2.0 de SpeedZilla
« le: 15 août 2011 à 19:44:32 »
Bonjour,

Avis au utilisateurs de Speedzilla, j'ai ouvert une discussion sur les nouvelles fonctions de la v2.0 (sessions TCP multiples, debit pointe, historique...)

A vos contributions :

http://forum.speedzilla.net/script-et-site-speedzilla-net/idees-pour-speedzilla-2-0/

---
miko
 

vivien

  • Administrateur
  • *
  • Messages: 47 253
    • Twitter LaFibre.info
Wishlist pour la v2.0 de SpeedZilla
« Réponse #1 le: 15 août 2011 à 23:27:30 »
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ébit

Aujourd’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.

m1ko

  • Invité
Wishlist pour la v2.0 de SpeedZilla
« Réponse #2 le: 16 août 2011 à 01:08:14 »
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).
....

Un savant mélange de Speedtest.net et des outils de DSLreports ;-)

corrector

  • Invité
Wishlist pour la v2.0 de SpeedZilla
« Réponse #3 le: 16 août 2011 à 02:02:46 »
Et surtout : est-ce que le RTT augmente lors du téléchargement? (Idéalement il ne devrait pas.)

vivien

  • Administrateur
  • *
  • Messages: 47 253
    • Twitter LaFibre.info
Wishlist pour la v2.0 de SpeedZilla
« Réponse #4 le: 16 août 2011 à 08:00:58 »
La latence augmente systématiquement.

Supprimer les paquets dès que le lien est full au lieu de mettre en buffer les paquets, je ne suis pas sur que ce soit l'idéal.

C'est se qui se passe quand la Rwin est trop importante (avec Windows XP où la rwin est fixe).
A ce moment là les débits s'écoulent.

Petit test de ping fait avec une connexion 3G dans le train. On voit qu'en cas de coupure les paquets sont buffurisés puis arrivent tous en même temps :

$ ping 212.27.48.10
PING free.fr (212.27.48.10) 56(84) bytes of data.
64 bytes from (212.27.48.10): icmp_req=1 ttl=114 time=519 ms
64 bytes from (212.27.48.10): icmp_req=2 ttl=114 time=679 ms
64 bytes from (212.27.48.10): icmp_req=3 ttl=114 time=639 ms
64 bytes from (212.27.48.10): icmp_req=4 ttl=114 time=3019 ms
64 bytes from (212.27.48.10): icmp_req=5 ttl=114 time=11050 ms
64 bytes from (212.27.48.10): icmp_req=6 ttl=114 time=10050 ms
64 bytes from (212.27.48.10): icmp_req=7 ttl=114 time=9050 ms
64 bytes from (212.27.48.10): icmp_req=8 ttl=114 time=279 ms
64 bytes from (212.27.48.10): icmp_req=9 ttl=114 time=200 ms
64 bytes from (212.27.48.10): icmp_req=10 ttl=114 time=220 ms
64 bytes from (212.27.48.10): icmp_req=11 ttl=114 time=320 ms
64 bytes from (212.27.48.10): icmp_req=12 ttl=114 time=220 ms
64 bytes from (212.27.48.10): icmp_req=13 ttl=114 time=180 ms

corrector

  • Invité
Wishlist pour la v2.0 de SpeedZilla
« Réponse #5 le: 16 août 2011 à 19:10:23 »
Consternant. Le TTL n'a même pas été décrèmenté!