Tests de débit sans IPERF : quelques exemples - pourquoi IPERF ?

[vivien]

Je "râle" souvent contre les test de débit fait à partir d'un navigateur web et qui ont dés résultats bien en dessous de la réalité.
Combien de fois j'ai eu la réflexion sur le site xxx il me dit que mon débit est à 40 Mb/s alors que j'ai une offre à 100 Mb/s.

Voici un exemple réalisé avec une connexion fibre optique 100 mb/s symétrique :


Ces tests web font un test de téléchargement d'un petit fichier (exemple typique : 500 Ko, plus sur les dernières versions) et à partir du temps mis à télécharger ce fichier, calcul un débit.

Mais les performances sont tributaires de plusieurs éléments :
- En passant par le navigateur web, celui-ci peut amputer les performances (on peut voir des différence uniquement en changeant de navigateur web)
- Un accès disque peut également faire chuter de manière drastique la moyenne de ces petits téléchargement
- Un CPU peu puissant est encore une autre raison de piètre performance.
- La Rwin adaptative pour les OS "moderne" peut elle aussi influer à la baisse les débits.

J'explique ce denier point : Les système d'exploitation dit "moderne" ont une pile TCP avec Rwin adaptative (Cela concerne Windows à partir de Vista, Mac OS à partir de MacOS 10.5, linux à partir du noyau 2.4). Cette innovation qui permet d'aller à très haut débit nécessite une petite période d'adaptation à chaque nouveau téléchargement pour s'adapter au débit.

Pour comprendre les problématique de Rwin adaptative, il faut comprendre le mécanisme d'accusé réception de TCP. Je vais tenter d'être le plus clair possible et je dois pour cela faire quelques simplifications :

Avant l’invention de la Rwin :
Si l'émetteur envoie un paquet (taille maximum d’un paquet IP : 1,5 Ko) et attend l'accusé de réception pour envoyer le second, le débit sera mauvais car il faut 50ms en ADSL entre l'envoi du paquet et la réception de l'accusé de réception. Le débit maximum serait de 240 Kb/s (un paquet toutes les 50ms)

Avec une Rwin de taille fixe (Windows 2000 / XP / Mac OS < 10.5) :
Pour pallier à ce problème le protocole TCP utilise une fenêtre qui permet d'envoyer x Ko sans attendre d'accusé de réception. Cette fenêtre s'appelle Rwin pour Receive Windows et s'exprime en Ko. Par exemple si la Rwin est de 64 Ko, Windows XP va envoyer brutalement (je simplifie) 64 Ko de données puis attendre les accusés de réception. Au fur et à mesure que les accusés arrivent, il va envoyer de nouvelles données en se limitant toujours à 64 Ko de paquets envoyés sans accusé de réception.
Ces 64 Ko ne sont pas suffisants pour aller à pleine vitesse avec des lignes à 20 Mb/s. On pourrait se demander pourquoi Microsoft n'a pas positionné la fenêtre à 400 Ko qui est la valeur de la Rwin nécessaire pour transférer à 20 Mb/s si les serveurs sont aux Etats-Unis (rajouter 90ms de latence pour la liaison transatlantique soit 225 Ko de rwin à 20 Mb/s). Si on positionne la Rwin à 400 Ko et qu'on utilise ensuite une carte 3G, Windows XP va envoyer brutalement 400 Ko de données qu'il faut stocker. Les buffers ne permettant pas de stocker une aussi grosse quantité de données, des paquets seront supprimés imposant une retransmission des paquets.

Avec une Rwin adaptative (Windows Vista / Mac OS 10.5 / Linux 2.4.x et 2.6.x)
Windows Vista / Mac OS 10.5 (et linux depuis longtemps) ont donc changé de mécanisme : La Rwin démarre à quelques Ko et le système d'exploitation va l'augmenter si le transfert se passe sans pertes de paquets. Cela permet d'avoir des fenêtres de plusieurs Mo pour les transferts qui l'exigent de d'avoir une petite Rwin pour les connexions avec de faible buffers. L'inconvénient de cette méthode est qu'un transfert va démarrer lentement. Très rapidement il va s'accélérer, toutefois le débit moyen sur des petits fichiers sera impacté.

[vivien]

Et IPERF ?

Je reprend les points qui engendre des problèmes de performance des test de débit web :

	Tests de débit web	Tests de débit IPERF
Est sensible au type de navigateur utilisé	Oui	Non
Génère des accès disque qui font chuter les performances	Oui, parfois	Non
Demande un CPU puissant pour être fiable à haut débit	Oui	Non
A des performances moindre sur des OS a Rwin adaptative	Oui	Non

Sur le dernier point, IPERF permet de mesurer le débit en régime établi (il suffit d'ignorer la premiére valeur qui en download est généralement inférieur à la réalité)

En upload si la premiére valeur est en général supérieur au débit théorique c'est qu'il pense que tout ce qui est dans la Rwin est déjà envoyé et donc-si le PC a une Rwin fixe importante, on  peut avoir dés débit > 100 Mb/s sur une carte Ethernet 10/100 Mb/s  )
Il faut donc systématiquement ignorer la premiére et derniére valeur (à la fin il attend les derniers accusés de réception et les éventuelles dernières ré-émission de paquet perdu)

L'inconvenant d'IPERF , c'est le fait qu'il faut télécharger un logiciel et ouvrir des ports, il est donc plus compliqué a utiliser qu'une page web avec un bouton pour tester son débit.

Un test de débit IPERF est disponible ici : http://lafibre.info/iperf

[vivien]

Les tests de débit web, toujours inférieur au débit théorique ?

Non !
Ils sont de temps en temps au dessus des performances théorique, je n'ai jamais trop compris pourquoi...

Quelques exemple collector triés par date :



Octobre 2003
sur un Windows 2000 avec Internet explorer, en fessant un test de débit sur http://mire.ipadsl.net/ :




Juin 2005
Réalisé sur un Windows XP (32 bits) service pack2 (Rwin non modifiée) :
- Pentium IV 2,8 Ghz HT, 512 Mo DDR2 333 Mhz, carte 10/100/1000
- Internet explorer 6
- depuis une connexion FTTH citéFibre sur Sagem F@st 3190w à 10 Mb/s symétrique théorique (mais provisionné à 15 Mb/s ethernet symétrique)
- vers le test de débit de 60 millions de consommateurs http://www.60millions-mag.com/outils/testeur_de_connexion




Novembre 2008
Réalisé sur un Windows XP (32 bits) service pack 3 :
- Core 2 Duo E7200 à 2,53 Ghz, 2x 64 Ko L1, 3 Mo cache L2, 2 Go DDR2 800 Mhz
- depuis une connexion FTTH SFR NeufBox v4 sur le réseau Pau Broaddband Country à 50 Mb/s symétrique théorique (mais provisionné à 55 Mb/s ethernet symétrique) connecté en câble Ethernet 100 Mb/s
- vers le test de débit de citéFibre http://ca24.citefibre.fr/

[vivien]

Janvier 2009
Réalisé sur un linux 2.6.27-9 générique 32 bits (Ubuntu 8.10 i386) :
- Core2 duo T7100 à 1,8 Ghz, 2x 64 Ko L1, 2 Mo de cache L2, 2 Go DDR2, 10/100/1000 Broadcom
- Firefox 3.0.5
- depuis une connexion ADSL2+ Bbox à 3,73 Mb/s ATM connecté en câble 100 Mb/s ethernet
- vers le test de débit de citéFibre http://ca24.citefibre.fr/



327,9 Mb/s pour une connexion ADSL2+, record battu !

Voici les info sur la synchro ADSL :