Essai par benchmark

à  partir de sites Web de test de vitesse comme DSL reports.com (http://www.dslreports.com), SPEEDUS (http://speedus.com) et 2Wire (http://www.2wire.com). La plupart des outils de test de ces sites Web permettent de choisir le serveur régional le plus proche du site Web pour le soumettre au test, puis ils utilisent le scripting côté client ou côté serveur pour générer du trafic et présenter les résultats

Bien que les sites Web de test de vitesse fournissent des outils de diagnostic utiles, ils ne procurent pas le niveau de test le plus exact en raison du manque partiel ou total de contrôle sur la distance logique (c’est-à -dire, le nombre de tronçons de routeur intervenant) entre la machine et le serveur à  distance du site. Bien que de nombreux sites permettent de choisir des serveurs Web géographiquement proches, un temps de latence significatif peut encore exister sur la connexion et influencer l’exactitude du test. En outre, les résultats du test peuvent aussi être influencés par le degré d’occupation du serveur Web au moment du test. En raison du risque d’interférence et du manque de contrôle de la plupart des outils basés sur site Web, j’ai préféré les écarter de mon test.

En lieu et place, j’ai utilisé deux produits pour le test : AnalogX NetStat Live (NSL) et MyVitalAgent (la nouvelle version de Net.Medic), tous deux téléchargeables gratuitement. J’ai utilisé deux outils de fournisseurs différents afin de pouvoir comparer les résultats. En effet, deux jeux de résultats peuvent révéler des chiffres erronés ou trompeurs en raison de méthodologies de test défectueuses et d’un échantillonnage de données insuffisant.

Après m’être assuré que la nouvelle connexion radio fonctionnait correctement et que ma connexion ISP avait été rétablie, j’ai utilisé NSL pour effectuer le premier test post-installation. (J’avais effectué les mêmes tests avant le changement pour disposer d’une base de comparaison.) Si vous appréciez un logiciel sans fioritures qui n’affiche que l’essentiel, vous aimerez NSL. Il fonctionne avec n’importe quel type d’adaptateur connecté à  Internet, qu’il s’agisse d’un adaptateur LAN Ethernet connecté à  un DSL ou à  un autre type de routeur, d’un modem analogique, ou d’un modem-câble. (Cela permet de se servir de l’utilitaire pour tester également le débit du réseau interne.) Comme le montre la figure 1, NSL offre une variété d’informations concernant la connexion, y compris le nombre actuel, moyen et maximum de kilobits par seconde ou de kilo-octets par seconde obtenu sur le trafic entrant et sortant, ainsi que l’utilisation de la CPU sur la machine locale. Il est également capable de collecter et d’afficher des récapitulatifs de l’historique d’utilisation des connexions.

Pour le second test, j’ai utilisé MyVitalAgent, qui a fourni des résultats similaires à  ceux de NSL. Comme on peut le voir figure 2, MyVitalAgent affiche une sorte de tableau de bord qui illustre les chiffres de téléchargement amont et aval indépendants. Cet affichage donne aussi des renseignements utiles sur le temps pris par chaque transaction de réseau et quel pourcentage de temps d’attente était imputable au client, au serveur, et au réseau. En outre, cet utilitaire peut détecter et afficher le type de transaction s’exécutant sur la connexion (un téléchargement FTP, par exemple) et fournir un journal de santé qui récapitule les problèmes d’une connexion et propose une cause potentielle et une correction pour chacun d’eux.

J’ai découvert avec plaisir que les résultats des deux utilitaires montraient que la nouvelle connexion était capable d’environ 1,3 Mbps en téléchargement aval (download) et 1 Mbps en téléchargement amont (upload). Ces chiffres sont nettement meilleurs que ma connexion précédente, créditée par l’utilitaire de 300 Kbps en upload et 600 Kbps en download.

Pour tirer le meilleur parti de ces utilitaires et de l’exactitude des tests, je conseille d’effectuer les opérations suivantes avant le test. Premièrement, fermer toutes les autres applications sur la machine, y compris celles qui s’exécutent dans le bac du système (system tray). Cette précaution réduira la contention de la CPU et le risque de voir d’autres applications perturber l’utilitaire de test.

Deuxièmement, si possible, essayer d’isoler la machine de test, afin que ce soit la seule à  employer la connexion Internet. Cette étape éliminera tout risque d’interférence résultant de l’utilisation de la bande passante de la connexion réseau et Internet par les autres machines du réseau.

Troisièmement, pour employer ces utilitaires, il faut générer du trafic sur votre connexion Internet. Pour tester les vitesses de téléchargement amont et aval de ma connexion, j’utilise les commandes FTP Get et Put, respectivement, pour envoyer et recevoir des fichiers du serveur FTP de mon ISP. Quelle qu’elle soit, la méthode utilisée pour générer du trafic doit saturer complètement la connexion pendant la période de test. Souvent, la pointe de débit se produit dès le début des transferts de fichiers et activités similaires, c’est pourquoi je recommande d’exécuter un test qui dure au moins deux ou trois minutes, pour obtenir un chiffre de débit moyen plus précis.

Si l’équipement connecté à  Internet permet la compression et si l’on est curieux de comparer les vitesses de transfert de données en mode compressé et non compressé sur la connexion, il faut exécuter les tests pour chaque scénario. Mon ISP garde deux petits fichiers bien commodes sur son serveur FTP appelés testfile.compressed.10meg et testfile.uncompressed.10meg que je peux télécharger pour tester les vitesses de téléchargement. Comme je dispose d’espace de fichier FTP sur le serveur de mon ISP, je peux également contourner la transaction et transférer en amont les fichiers pour tester les vitesses d’upload. (Pour créer un fichier non compressé d’une taille particulière, on peut utiliser l’utilitaire createfile.exe du Microsoft Windows 2000 Resource Kit.

Enfin, lorsqu’on se sert d’utilitaires de test des connexions Internet pour tester les performances de connexions Internet, il est conseillé d’utiliser le serveur le plus proche de l’ISP. On réduit ainsi la quantité d’interférence causée par le temps de latence Internet par suite des divers tronçons de routeur qui se situent entre la machine de test et le serveur à  distance.