ntttcp (Windows NT Test TCP) est un utilitaire d’analyse comparative de réseau similaire à iperf3 qui fonctionne à la fois sous Windows et Linux, écrit et recommandé par Microsoft sur iperf3, nous allons donc tester l’alternative dans cette mini test.
iperf3 est un utilitaire de choix pour nos tests d’ordinateurs monocarte et de mini PC fonctionnant sous Windows ou Linux, mais nous avons remarqué que même si Ethernet (jusqu’à 2,5 GbE) fonctionne généralement aussi bien sous Windows et Linux, le WiFi est généralement beaucoup plus performant. plus rapide dans Ubuntu 22.04 que dans Windows 11. Ainsi, lorsque les développeurs XDA ont remarqué un message de Microsoft disant que iperf3 ne devrait pas être utilisé sur Windows 11, cela a attiré mon attention.
Microsoft explique qu’iperf3 ne doit pas être utilisé sous Windows pour trois raisons principales :
- Le responsable d’iperf – ESnet (Energy Sciences Network) – déclare : « iperf3 n’est pas officiellement pris en charge sous Windows, mais iperf2 l’est. Nous vous recommandons d’utiliser iperf2. Certaines personnes utilisent Cygwin pour exécuter iperf3 sous Windows, mais toutes les options ne fonctionneront pas »
- iPerf3 est émulé sous Windows – iPerf3 n’effectue pas d’appels API natifs Windows car il sait uniquement comment effectuer des appels Linux/POSIX, ce qui peut avoir un impact sur les performances.
- Je télécharge habituellement iperf3 3.1.3 pour Windows sorti en 2016, et Microsoft note que celui proposé par ESnet (version 3.16) est plus récent mais toujours en retard de 15 versions, les utilisateurs n’exécutent donc pas la dernière version des utilitaires.
Alors, quelle est l’alternative à iperf3 ? Microsoft en maintient deux :
- ntttcp (Windows NT Test TCP) utilitaire open source pour Windows et Linux avec une ligne de commande similaire à iperf3 selon Microsoft dans le sens où il vise à isoler le débit de la pile réseau.
- ctsTraffic pour les tests Windows à Windows uniquement, également open source et maintenu sur Github. ctsTraffic se concentre sur les scénarios de goodput de bout en bout.
Nous pouvons disqualifier ctsTraffic immédiatement ici chez Raspberryme Software puisque nos tests impliquent généralement un mélange de machines Linux et Windows. Microsoft a comparé iperf3 aux utilitaires ntttcp dotés d’interfaces réseau haut débit (10 GbE+), et ce dernier rapporte des performances bien supérieures. Je n’ai que du matériel avec 2,5GbE et WiFi 6, mais je voulais quand même le tester, notamment pour vérifier le WiFi. J’ai donc décidé d’essayer ntttcp en suivant les instructions de Microsoft Learn. Cela a fini par être un défi car ceux-ci ne fonctionnaient pas sur mon système, et il m’a fallu un certain temps pour trouver les bons paramètres…
Mon banc de test est composé de quatre composants principaux :
Le Khadas Mind Premium a été sélectionné car c’est le seul système Windows de rechange avec 2,5 GbE et WiFi 6 que je possède et que j’ai déjà examiné. Vous remarquerez que les tests réseau sous Windows 11 et Ubuntu 22.04 utilisant iperf3 révèlent des performances bien inférieures dans le système d’exploitation Microsoft, comme résumé dans le tableau ci-dessous.
| WiFi 6 émission | Réception Wi-Fi 6 | Transmission 2,5 GbE | Réception 2,5 GbE | |
|---|---|---|---|---|
| Windows 11 Accueil | 712 Mbit/s | 590 Mbit/s | 700 Mbit/s | 2,30 Gbit/s |
| Ubuntu 22.04 | 1,40 Gbit/s | 991 Mbit/s | 2,35 Gbit/s | 2,35 Gbit/s |
Le mini PC Khadas est une valeur aberrante en ce qui concerne les performances de téléchargement 2,5 GbE, mais le WiFi est plus rapide sous Linux dans toutes les critiques de mini PC que nous avons effectuées. Depuis que l’test Mind Premium a été effectué il y a quelque temps (août 2023), j’ai mis à jour Windows avec la dernière version et les derniers pilotes et testé à nouveau les performances réseau avec iperf3 et ntttcp dans Windows 11 Home en utilisant la même ligne de commande que dans le billet de blog Microsoft.
La première étape consistait à installer ntttcp (Linux) sur le mini PC UP Xtreme i11 exécutant Ubuntu 20.04 :
|
clone git https://github.com/microsoft/ntttcp-for-linux cd ntttcp-pour-linux/src faire sudo make install |
Nous pouvons exécuter la commande Receiver comme suit.
|
1 2 3 4 5 6 7 8 9 dix 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 |
devkit@UPX-i11 :~/ntttcp-for-linux$ ntttcp -r -m 1,*,192.168.31.12 -t 60 -V NTTTCP pour Linux 1.4.0 ————————————————– ——- *** rôle de récepteur ports : 1 affinité CPU : * adresse du serveur : 192.168.31.12 domaine : IPv4 protocole : TCP port du serveur à partir de : 5001 Tampon du socket du récepteur (octets) : 65536 test d’échauffement (sec): non durée du test (sec): 60 test de refroidissement (sec): non afficher la retransmission TCP du système : non mode silencieux : désactivé mode verbeux : activé ————————————————– ——- 12:25:30 DBG : limites utilisateur pour le nombre maximum de fichiers ouverts : soft : 1024 ; dur : 1048576 12:25:30 DBG : Interface :[lo] Adresse : 127.0.0.1 12:25:30 DBG : Interface :[enp44s0] Adresse : 192.168.31.12 12:25:30 DBG : Interface :[docker0] Adresse : 172.17.0.1 12:25:30 DBG : Interface :[flannel.1] Adresse : 10.42.0.0 12:25:30 DBG : Interface :[cni0] Adresse : 10.42.0.1 12:25:30 INFO : 2 fils de discussion créés 12:25:30 DBG : le serveur ntttcp écoute sur 192.168.31.12:5001 12:25:30 DBG : le serveur ntttcp écoute sur 192.168.31.12:5000 12:25:47 DBG : Nouvelle connexion : 192.168.31.69:50666 –> local :10000 [socket 6] erreur de lecture du socket : 104 12:26:11 DBG : prise fermée : 6 12:26:32 DBG : Nouvelle connexion : 192.168.31.69:50675 –> local :10000 [socket 6] erreur de lecture du socket : 104 12:26:37 DBG : prise fermée : 6 12:26:49 DBG : Nouvelle connexion : 192.168.31.69:50683 –> local :10000 [socket 6] |
Un seul cœur est utilisé pour émuler iperf3 et les options V (verbeuses) aident beaucoup à résoudre les problèmes. Après avoir téléchargé le binaire ntttcp.exe sur Windows, nous pouvons l’exécuter immédiatement en tant qu’expéditeur dans une invite de commande :
|
1 2 3 4 5 6 7 8 9 dix 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 |
C:\Utilisateurs\jaufr\Downloads>ntttcp.exe -s -m 1,*,192.168.31.12 -l 128K -t 60 -V Copyright version 5.39 longueur_tampon : 131072 num_buffers_to_send : 9223372036854775807 send_socket_buff : -1 recv_socket_buff : -1 port : 5001 port_sync : 0 no_sync : 0 wait_timeout_milliseconds : 600 000 async_flag : 0 verbose_flag : 1 wsa_flag : 0 use_ipv6_flag : 0 envoyer_flag : 1 udp_flag : 0 udp_unconnected_flag : 0 verify_data_flag : 0 wait_all_flag : 0 temps d’exécution : 60 000 temps d’échauffement : 0 temps de recharge : 0 dash_n_timeout : 10800000 bind_sender_flag : 0 nom de l’expéditeur: max_active_threads : 1 no_delay : 0 node_affinity : -1 udp_uso_size : 0 udp_receive_coalescing : 0 tp_flag : 0 use_hvsocket_flag : 0 no_stdio_buffer : 0 débit_Bpms : 0 cpu_burn : 0 latence_mesure : 0 use_io_compl_ports : 0 cpu_from_idle_flag : 0 get_estats : 0 qos_flag : 0 période_paquet : 0 gigue_mesure : 0 cartographie[0]: 1 21/04/2024 10:10:45 proc_speed : 2611 MHz 21/04/2024 10:10:45 ConfigurationThreads 21/04/2024 10:10:45 Threads : 1 Processeur : -1 Hôte : 192.168.31.12 21/04/2024 10:10:45 fil de discussion créé 0 port 5001 21/04/2024 10:10:45 StartSenderReceiver démarre le thread 0 port 5001 21/04/2024 10:10:45 Configuration du port Net 5001 21/04/2024 10:10:45 connecté au port 5001 21/04/2024 10:10:45 SetupNet terminé sur le port 5001 21/04/2024 10:10:45 Tous les sujets sont prêts ! 21/04/2024 10:10:45 Configuration du port Net 6001 21/04/2024 10:10:47 ERREUR : échec de SetupNet : échec de la tentative de connexion, GetLastError : 10061 – Aucune connexion n’a pu être établie car la machine cible l’a activement refusée. 21/04/2024 10:10:47 Numéro de port : 6001 21/04/2024 10:10:49 ERREUR : échec de SetupNet : échec de la tentative de connexion, GetLastError : 10061 – Aucune connexion n’a pu être établie car la machine cible l’a activement refusée. |
Mais comme vous pouvez le voir dans le journal ci-dessus, cela n’a pas fonctionné comme prévu. Il s’avère que pour les tests Windows vers Linux, nous devons utiliser le paramètre « ns » (No Sync). C’est mentionné dans le billet de blog de Microsoft
Il existe une limitation d’interopérabilité connue lors des tests entre Windows et Linux. Les détails peuvent être trouvés dans cet article wiki ntttcp pour Linux sur GitHub.
Il m’a fallu quelques heures pour le découvrir, mais une fois cela fait, j’ai pu terminer le test WiFi 6 Tx (téléchargement) :
|
1 2 3 4 5 6 7 8 9 dix 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 |
C:\Users\jaufr\Downloads>ntttcp.exe -s -m 1,*,192.168.31.12 -l 128K -t 60 -ns Copyright version 5.39 L’activité du réseau progresse… Temps de thread(s) Débit (Ko/s) Moy B / Compl ====== ======= ================ ============= 0 60.011 100476.513 131072.000 ##### Totaux : ##### Octets (MEG) temps réel Taille de trame moyenne Débit (Mo/s) ================ =========== ============== ========= ======= 5888.375000 60.009 1459.307 98.125 Débit (tampons/s) Cycles/tampons d’octets ===================== =========== ============= 785.001 4.024 47107.000 DPC (nombre/s) Paquets (num/DPC) Intr (nombre/s) Paquets (num/intr) ============= ============= =============== ========= ===== 906.366 4.807 3218.159 1.354 Paquets envoyés Paquets reçus Erreurs de retransmission Moy. CPU % ============ ================ =========== ====== ===== ===== 4231054 261456 5 0 0,991 |
98,125 Mo/s soit environ 785 Mbps, légèrement mieux qu’avec iperf3, mais encore loin des performances sous Linux.
J’ai ensuite connecté un câble Ethernet pour tester l’upload 2,5GbE :
|
1 2 3 4 5 6 7 8 9 dix 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 |
C:\Users\jaufr\Downloads>ntttcp.exe -s -m 1,*,192.168.31.12 -l 128K -t 60 -ns Copyright version 5.39 L’activité du réseau progresse… Temps de thread(s) Débit (Ko/s) Moy B / Compl ====== ======= ================ ============= 0 60.015 90110.806 131072.000 ##### Totaux : ##### Octets (MEG) temps réel Taille de trame moyenne Débit (Mo/s) ================ =========== ============== ========= ======= 5281.250000 60.014 1458.979 88.000 Débit (tampons/s) Cycles/tampons d’octets ===================== =========== ============= 703.998 3.927 42250.000 DPC (nombre/s) Paquets (num/DPC) Intr (nombre/s) Paquets (num/intr) ============= ============= =============== ========= ===== 11814,824 0,449 31926,446 0,166 Paquets envoyés Paquets reçus Erreurs de retransmission Moy. CPU % ============ ================ =========== ====== ===== ===== 3795663 318708 1 0 0,867 |
88 Mo/s soit 704 Mbps, donc c’est globalement la même chose qu’avec iperf3 même après avoir mis à jour les drivers.
iperf3 a une option de transfert inversé, mais je n’ai vu aucune option de ce type sur ntttcp. J’ai donc dû taper les commandes pour exécuter ntttcp.exe en mode récepteur sous Windows et ntttcp en mode expéditeur sous Linux. Nous devrons exécuter CMD en tant qu’administrateur, ouvrir le pare-feu et l’outil de référence réseau avec d’autres paramètres :
|
netsh advfirewall pare-feu ajouter un programme de règles = C:\Users\jaufr\Downloads\ntttcp.exe name= »ntttcp » protocol=any dir=in action=allow activate=yes profile=ANY C:\Utilisateurs\jaufr\Downloads>ntttcp.exe -r -m 1,*,192.168.31.141 -ns -t 60 -V |
La commande Linux pour l’expéditeur Ubuntu est assez différente de la même commande pour l’expéditeur Windows car les paramètres sont différents :
|
1 2 3 4 5 6 7 8 9 dix 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 |
devkit@UPX-i11:~/ntttcp-for-linux$ ntttcp -s -m 1,*,192.168.31.141 -b 128K -N -t 60 -V NTTTCP pour Linux 1.4.0 ————————————————– ——- *** rôle d’expéditeur *** pas de synchronisation émetteur/récepteur connexions : 1 X 1 X 1 affinité CPU : * adresse du serveur : 192.168.31.141 domaine : IPv4 protocole : TCP port du serveur à partir de : 5001 Tampon de socket de l’expéditeur (octets) : 131072 test d’échauffement (sec): non durée du test (sec): 60 test de refroidissement (sec): non afficher la retransmission TCP du système : non mode silencieux : désactivé mode verbeux : activé ————————————————– ——- 14:45:55 DBG : limites utilisateur pour le nombre maximum de fichiers ouverts : soft : 4096 ; dur : 4096 14:45:55 INFO : Démarrage de l’activité de l’expéditeur (pas de synchronisation)… 14:45:55 INFO : 1 discussion créée 14:45:55 DBG : Nouvelle connexion : local:42880 [socket:3] –> 192.168.31.141:5001 14:45:55 INFO : 1 connexion créée en 1708 microsecondes 14:46:55 INFO : test terminé. 14:46:55 INFO : Cycle de test terminé. 14:46:55 INFO : Temps de thread (s) Débit 14:46:55 INFO : ====== ======= ========== 14:46:55 INFO : 0 60,00 2,28 Gbit/s 14:46:55 INFO : 1 connexions testées 14:46:55 INFO : ##### Totaux : ##### 14:46:55 INFO : durée du test :60.00 secondes 14:46:55 INFO : nombre total d’octets : 17068195840 14:46:55 INFO : débit :2,28Gbps 14:46:55 INFO : retrans segs :54998 14:46:55 INFO : cœurs de processeur : 8 14:46:55 INFO : vitesse du processeur : 2000,462 MHz 14:46:55 INFO : utilisateur :0,46% 14:46:55 INFO : système :0,78% 14:46:55 INFO : inactif :97,94% 14:46:55 INFO : j’attends :0.00% 14:46:55 INFO : softirq :0,82% 14:46:55 INFO : cycles/octet :1.16 14:46:55 INFO : processeur occupé (tous) :5,16% 14:46:55 INFO : tcpi rtt :397 us |
Mais j’ai quand même réussi. Inutile de dire que j’ai eu jusqu’à présent une vision trop positive de l’utilitaire ntttcp. Le seul avantage que je vois est que nous disposons de données supplémentaires telles que l’utilisation du processeur pendant le transfert. 2,28 Gbit/s correspond à ce que nous attendons pour une connexion 2,5GbE.
Je déconnecte généralement le câble Ethernet pour tester le WiFi 6 avec iperf3 et exécute la même commande. Mais ici, nous devons également changer l’adresse IP côté serveur et côté client pour la tester à nouveau :
|
1 2 3 4 5 6 7 8 9 dix 11 12 13 14 15 16 17 18 19 20 21 22 23 |
devkit@UPX-i11:~/ntttcp-for-linux$ ntttcp -s -m 1,*,192.168.31.69 -b 128K -N -t 60 NTTTCP pour Linux 1.4.0 ————————————————– ——- 14:54:58 INFO : Démarrage de l’activité de l’expéditeur (pas de synchronisation)… 14:54:58 INFO : 1 discussion créée 14:54:58 INFO : 1 connexion créée en 6716 microsecondes 14:55:58 INFO : test terminé. 14:55:58 INFO : Cycle de test terminé. 14:55:58 INFO : 1 connexions testées 14:55:58 INFO : ##### Totaux : ##### 14:55:58 INFO : durée du test :60.00 secondes 14:55:58 INFO : nombre total d’octets : 4530110464 14:55:58 INFO : débit :604,01Mbps 14:55:58 INFO : retrans segs :0 14:55:58 INFO : cœurs de processeur : 8 14:55:58 INFO : vitesse du processeur : 2800.000MHz 14:55:58 INFO : utilisateur :0,53% 14:55:58 INFO : système :0,41% 14:55:58 INFO : inactif :99,01% 14:55:58 INFO : j’attends :0.00% 14:55:58 INFO : softirq :0,04% 14:55:58 INFO : cycles/octet :2,93 14:55:58 INFO : processeur occupé (tous) : 1,98 % |
604 Mbps donc il n’y a aucune amélioration ici.
| WiFi 6 émission | Réception Wi-Fi 6 | Transmission 2,5 GbE | Réception 2,5 GbE | |
|---|---|---|---|---|
| iperf3 | 551 Mbit/s | 608 Mbit/s | 736 Mbit/s | 2,30 Gbit/s |
| ntttcp | 785 Mbit/s | 604 Mbit/s | 704 Mbit/s | 2,28 Gbit/s |
Le tableau ci-dessus résume les résultats après avoir réexécuté iperf3. Bien que ntttcp soit plus rapide pour le téléchargement en WiFi 6, les résultats ne sont pas concluants car les autres résultats sont plus ou moins inchangés. Je suppose que cela n’a d’importance que pour les réseaux à haut débit avec des connexions 10GbE ou supérieures.
Les tests ci-dessus ont été effectués pour comparer ntttcp à iperf3 avec des paramètres similaires, mais Microsoft affirme que le multithread et des tailles de tampon plus grandes devraient être utilisés pour tester la bande passante. Essayons à nouveau avec le téléchargement WiFi 6 en utilisant 8 threads et une taille de tampon de 1 024 Ko :
|
1 2 3 4 5 6 7 8 9 dix 11 12 13 14 15 16 17 18 19 20 21 22 23 24 |
devkit@UPX-i11:~/ntttcp-for-linux$ ntttcp -s -m 8,*,192.168.31.69 -b 1024K -N -t 60 NTTTCP pour Linux 1.4.0 ————————————————– ——- 15:00:06 INFO : Démarrage de l’activité de l’expéditeur (pas de synchronisation)… 15:00:06 INFO : 8 fils de discussion créés 15:00:06 INFO : 8 connexions créées en 5242 microsecondes 15:01:06 INFO : test terminé. 15:01:06 INFO : Cycle de test terminé. 15:01:06 INFO : 8 connexions testées 15:01:06 INFO : ##### Totaux : ##### 15:01:06 INFO : durée du test :60.00 secondes 15:01:06 INFO : nombre total d’octets : 4234149888 15:01:06 INFO : débit :564,55Mbps 15:01:06 INFO : retrans segs :573 15:01:06 INFO : cœurs de processeur : 8 15:01:06 INFO : vitesse du processeur : 2800.000MHz 15:01:06 INFO : utilisateur :0,52% 15:01:06 INFO : système :0,54% 15:01:06 INFO : inactif :98,62% 15:01:06 INFO : j’attends :0.00% 15:01:06 INFO : softirq :0,32% 15:01:06 INFO : cycles/octet :4.39 15:01:06 INFO : processeur occupé (tous) :2,90% ————————————————– ——- |
564 Mbps est plus lent qu’avec un seul thread et un tampon de 128 Ko, même si je pense que les résultats WiFi peuvent être assez volatils.
Sur la base des tests effectués ci-dessus, il y a très peu de différence entre les résultats d’iperf3 et de ntttcp, ntttcp Linux n’a pas été mis à jour depuis plus de trois ans, donc je ne suis pas convaincu, et nous continuerons à utiliser iperf3 pour les tests de réseau dans les critiques de Windows mini. PC…
Retrouvez l’histoire de Raspberry Pi dans cette vidéo :
