Utiliser iPerf3


iPerf est un outil qui s'utilise via une ligne de commande.

Utilisation en mode client : iperf3 -c server [ options ] (utilisation classique pour un test de débit)
Utilisation en mode serveur : iperf3 -s [ options ] (pour ne pas dépendre d'un serveur sur internet, par exemple pour tester le débit entre 2 PC sur son réseau local)

Voici les options les plus utilisées :

• -c paris.bbr.iperf.bytel.fr : Exécutez iperf3 en mode client. Connexion au serveur iPerf3 paris.bbr.iperf.bytel.fr
• -p 9210 : spécifie d'utiliser le port 9210. Par défaut, c'est le port 5201 qui est utilisé. Attention : de nombreux serveurs ne sont pas sur le port par défaut
• -R : Test de débit descendant (par défaut, c'est un test de débit montant qui est effectué)
• -P 5 : Utiliser 5 connexions simultanées. Par défaut, une seule connexion TCP/UDP est utilisée
• -t 20 : Faire un test de 20 secondes, du test. Par défaut, le test dure 10 secondes
• -i 0.5 : Définit un intervalle de temps de 0,5 seconde pour afficher un rapport sur la bande passante, la gigue, et les pertes. Par défaut, la valeur est de 1 seconde
• -u : Utiliser UDP plutôt que TCP. Il faut alors spécifier un débit avec l’option -b : exemple -i -b 500m pour 500 Mbit/s
• -4 : Réaliser le test en IPv4 uniquement. Par défaut IPv6 est utilisé s'il est disponible sur le client et le serveur
• -6 : Réaliser le test en IPv6 uniquement
• --omit 4 : Omettre les 4 premières secondes du test pour ignorer la période de TCP slowstart^*
• --congestion=bbr : Configurer l'algorithme de congestion TCP BBR (il doit être supporté par le serveur)
• --congestion=cubic : Configurer l'algorithme de congestion TCP Cubic
• -V : Résultats des tests plus détaillés qu'auparavant (ex: indique le protocole de congestion TCP utilisé)
• -v : Afficher les informations de version et quitter

^* Slow start (démarrage lent): algorithme du protocole TCP qui consiste à augmenter progressivement le débit au cours du téléchargement.

---

Il existe de nombreux serveurs publics 10 Gbit/s (ou plus) en France.

Bouygues Telecom :

• Paris BBR : paris.bbr.iperf.bytel.fr (ports 9200 à 9240)
• Paris Cubic : paris.cubic.iperf.bytel.fr (ports 9200 à 9240)
• Marseille BBR : mrs.bbr.iperf.bytel.fr (ports 9200 à 9240)
• Marseille Cubic : mrs.cubic.iperf.bytel.fr (ports 9200 à 9240)
• Lyon BBR : lyo.bbr.iperf.bytel.fr (ports 9200 à 9240)
• Lyon Cubic : lyo.cubic.iperf.bytel.fr (ports 9200 à 9240)
• Toulouse BBR : tls.bbr.iperf.bytel.fr (ports 9200 à 9240)
• Toulouse Cubic : tls.cubic.iperf.bytel.fr (ports 9200 à 9240)
• Strasbourg BBR : str.bbr.iperf.bytel.fr (ports 9200 à 9240)
• Strasbourg  Cubic : str.cubic.iperf.bytel.fr (ports 9200 à 9240)
• Poitiers BBR : poi.bbr.iperf.bytel.fr (ports 9200 à 9240)
• Poitiers Cubic : poi.cubic.iperf.bytel.fr (ports 9200 à 9240)
• Rennes BBR : ren.bbr.iperf.bytel.fr (ports 9200 à 9240)
• Rennes Cubic : ren.cubic.iperf.bytel.fr (ports 9200 à 9240)

Groupe Iliad :

• Paris : ping6.online.net (IPv6) et ping.online.net (IPv4) (ports 5200 à 5209, BBR est l'algo par défaut et Cubic est disponible en option)
• Paris : scaleway.testdebit.info (ports 9200 à 9222, BBR est l'algo par défaut et Cubic est disponible en option)

Autres opérateurs :

• Moji Paris : iperf3.moji.fr (ports 5200 à 5240, Cubic est l'algo par défaut et BBR est disponible en option)
• MilkyWan Paris : speedtest.milkywan.fr (ports 9200 à 9240, BBR est l'algo par défaut et Cubic est disponible en option)
• Appliwave Paris : appliwave.iperf.fr (ports 9200 à 9240, BBR est l'algo par défaut et Cubic est disponible en option)

---

Les erreurs possibles

Si le message iperf3: error - the server is busy running a test. try again later s'affiche, il faut savoir qsue iPerf3 n'autorise qu'un seul client par port TCP/UDP. Si le port est occupé, il faut sélectionner un autre port de votre choix. C'est pour cette raison que les serveurs écoutent sur une plage de ports.

Les messages iperf3: error - control socket has closed unexpectedly et iperf3: error - received an unknown control message (ensure other side is iperf3 and not iperf) indiquent que ce n'est pas iPerf3 qui écoure sur le port en question. Le serveur ne semble pas correct.

Le message iperf3: error - unable to connect to server - server may have stopped running or use a different port, firewall issue, etc.: Connection timed out qui arrive aprés un certain temps indique que le serveur ne répond pas.

---

Un exemple de commande pour faire un test de débit mono-connexion avec iPerf : (une seule connexion simultanée)

Test du débit descendant : iperf3 -c paris.bbr.iperf.bytel.fr -p 9200 -R

Test du débit montant : iperf3 -c paris.bbr.iperf.bytel.fr -p 9200

---

Un exemple de commande pour faire un test de débit multi-connexions avec iPerf : (plusieurs connexions simultanées)

Test du débit descendant avec 3 connexions en parallèles pendant 4 secondes : iperf3 -c paris.bbr.iperf.bytel.fr -p 9200 -R -P 3 -t 4

Test du débit descendant avec 10 connexions en parallèles durant 15 secondes : iperf3 -c paris.bbr.iperf.bytel.fr -p 9200 -R -P 10 -t 15



iPerf3 remonte le débit côté récepteur et côté émetteur.

Il est préférable de regarder le débit côté récepteur pour avoir le débit utile.
Le débit côté émetteur étant augmenté par des paquets retransmis et diminué, pour un test de débit descendant, par la latence pour aller récupérer la donnée, ce qui explique que le débit côté émetteur est divisé sur un peu plus de 4 secondes, ici 4,03 secondes.

iPerf3 est un outil très complet, qui propose de nombreuses options pour analyser une connexion internet. Il utilise toutefois des ports et un protocole spécifiques. C'est ce point que corrige l'outil NSpeed, proposé ci-dessous.

Exemple des vitesses obtenues avec un SSD SATA


La différence fondamentale entre un SSD SATA et un SSD NVMe réside dans l'interface de connexion et le protocole de communication utilisés pour transférer les données vers le processeur. Un SSD SATA est plus lent, car la norme SATA 3.0 plafonne physiquement le débit à 6 Gbit/s (soit environ 550 Mo/s exploitables). Un SSD SATA moderne est limité par le câble/bus, et non par ses puces de mémoire.

Le SSD de gauche à un débit d'écriture qui frôle le maximum possible sur l'interface SATA. Avec 470 Mo/s, il offre un débit d'écriture moyenne à 3760 Mbit/s.

Le SSD de droite a des débits plus fluctuants et moins bons. Le débit en écriture varie fortement et peut descendre à moins de 200 Mo/s soit 1,6 Gbit/s. Par conséquent, cela peut être l'élément limitant pour une connexion proposant un débit de 2 Gbit/s.



Ci-dessous, c'est le même disque à droite et à gauche. La différence ?
À gauche, on a seulement 100 échantillons de 10 Mo (la valeur par défaut), qui ne permettent pas de mettre en évidence la saturation de cache.
À droite, c'est 1000 échantillons de 10 Mo qui sont écrits, soit 10 Go. Le cache, permettant une écriture au débit maximal semble limité à 3 Go.

Pourquoi cette baisse de débit ? Le SSD utilise de la mémoire flash TLC (Triple-Level Cell), capable de stocker 3 bits de données par cellule. Bien que très dense et économique, la TLC est nativement plus lente à écrire. Pour contourner ce problème, une petite portion de la mémoire flash est réservée pour fonctionner en mode SLC (Single-Level Cell), où l'on n'écrit qu'un seul bit par cellule. Ce sous-ensemble sert de tampon d'écriture très rapide : Pendant les 3 premiers Go (sur ce modèle), les données sont écrites dans ce cache SLC à pleine vitesse (~500 Mo/s soit 4 Gbit/s). Une fois le tampon de 3 Go saturé, le contrôleur doit commencer à écrire directement dans la mémoire TLC, dont le débit natif est d'environ 240 Mo/s soit 1920 Mbit/s.

Une fois le transfert volumineux terminé et le SSD au repos, le contrôleur transfère en arrière-plan les données stockées dans le cache SLC vers la zone TLC globale afin de libérer à nouveau le tampon de 3 Go.

Pour d'autres SSD, le cache n'est pas de 3 Go, mais de 6 Go ou 12 Go. Dans ce dernier cas, il n'est pas rempli par le test de 1000 échantillons de 10 Mo.

Note : sur de nombreux SSD, le cache n'utilise pas des puces SLC physiques dédiées et fixes. Le cache repose sur de la mémoire TLC simulée en SLC. Pour répartiere l'usure équitablement sur l'ensemble des puces du SSD, le contrôleur alterne dynamiquement les blocs de mémoire TLC qu'il utilise comme cache SLC, évitant de "brûler" prématurément un secteur précis.



Le SSD ci-dessous est défectueux et son débit s'est dégradé avec les années. Son débit moyen en écriture n'est que 16 Mo/s, soit 128 Mbit/s. Ses performances vont donc fortement limiter le débit de téléchargement. Compte tenu des opérations d'écritures que doit faire le système d'exploitation, il est possible de se retrouver avec quelques dizaines de Mbit/s maximum. À noter que le débit en lecture n'est pas dégradé.