Auteur Sujet: Iperf x64 sous Windows (Lu 35178 fois)

kgersen · « **Réponse #12 le:** 24 juillet 2015 à 09:05:22 »

Citation de: vivien le 23 juillet 2015 à 23:29:28

Merci !

J'ai mis à disposition les versions que tu as compilé sur https://iperf.fr

3.testdebit.info ne repond pas ?

vivien · « **Réponse #13 le:** 24 juillet 2015 à 10:58:35 »

En fait, je modifie les pages de https://iperf.fr directement sur le site, et j'ai mis le tableau des serveurs iperf3 publics, avant de migrer 3.testdebit.info d'iperf2 vers iperf3.

Je viens de le migrer vers iperf3.

L'anglais n'est pas mon fort, si vous trouvez des tournures qui ne vont pas sut https://iperf.fr, n'hésitez pas à me le signaler.

kgersen · « **Réponse #14 le:** 24 juillet 2015 à 11:21:53 »

Citation de: vivien le 24 juillet 2015 à 10:58:35

Je viens de le migrer vers iperf3.

donc il ne fait plus les 2 (iperf et iperf3) comme celui d'Online ?

vivien · « **Réponse #15 le:** 24 juillet 2015 à 11:56:03 »

Non, uniquement iPerf3.

iPerf2 avait tendance :
- à planter régulièrement (obligation de vérifier toutes les minutes si le process iperf est bien présent)
- à gonfler fortement en mémoire
- à ne plus accepter de nouvelles connexion TCP alors qu'il est toujours en ram
=> obligation de killer et de redémarrer iperf toutes les 10 minutes.

Par ailleurs, si je n'utilisait plus trop iperf en TCP, c'est qu'il avait également des problématiques de Rwin limitée a quelques centaines de Ko, ce qui limite le débit dès que la latence ou le débit augmente. Iperf restait la référence pour l'UDP.

Bref, iperf3 est censé avoir résolut ces problèmes, et je pense qu'il est bon de tourner la page de iperf2.

iPerf 3 apportes de nombreuses nouveautés, dont 3 particulièrement intéressantes pour des tests grand-public :
- Possibilité de faire un test en download sans faire de test en uplaod avant
- Il n'est plus nécessaire d'ouvrir les ports TCP/UDP pour les clients qui sont derrière une box avec du NAT
- Possibilité d'ignorer la montée en débit sur iPerf3, afin de se concentrer sur le débit en régime établit

alain_p · « **Réponse #16 le:** 24 juillet 2015 à 13:33:34 »

Sur le site iperf, je vois mentionnée la date du 9 Janvier pour les packages windows 3.0.11, par Dji, or tu les as bien mis aujourd'hui, donc la date doit être fausse ?

vivien · « **Réponse #17 le:** 24 juillet 2015 à 16:54:17 »

La date du 9 Janvier 2015, c'est la date de sortie de Iperf 3.0.11, pas la date de compilation.

Cela semble plus logique de mettre la date de sortie du logiciel que la date de compilation ou la date de mise en ligne sur le site.

Voici un historique (qui est disponible, plus bas sur la longue page https://iperf.fr avec le code source des différentes versions) :
iPerf 3.1 en développement iPerf 3.0.11 9 Jan 2015 416 Kio iPerf 3.0.10 16 Dec 2014 416 Kio iPerf 3.0.9 14 Oct 2014 395 Kio iPerf 3.0.8 30 Sep 2014 394 Kio iPerf 3.0.7 28 Aug 2014 391 Kio iPerf 3.0.6 28 Jul 2014 389 Kio iPerf 3.0.5 16 Jun 2014 389 Kio iPerf 3.0.4 12 Jun 2014 492 Kio iPerf 3.0.3 26 Mar 2014 345 Kio iPerf 3.0.2 10 Mar 2014 343 Kio iPerf 3.0.1 10 Jan 2014 332 Kio iPerf 2.0.5 8 Jul 2010 243 Kio iPerf 2.0.4 7 Avr 2008 243 Kio iPerf 2.0.3 18 Mar 2008 241 Kio iPerf 2.0.2 3 Mai 2005 228 Kio iPerf 2.0.1 8 Nov 2004 215 Kio iPerf 1.7.0 13 Mar 2003 179 Kio

A noter que iPerf 2.0.5 a été patché a de nombreuses reprises, notamment par Roberto Lumbreras pour Debian / Ubuntu et que c'est ce patch que j'ai appliqué avec succés pour la version 2.0.5-2 de Windows.

vivien · « **Réponse #18 le:** 24 juillet 2015 à 21:21:24 »

J'ai un gros souci avec iPerf3 : Le serveur n'accepte pas d'avoir plusieurs clients en parallèle, comme Iperf2.

Quand un client tente de se connecter alors qu'un client est déja en train de réaliser un test, cela affiche "iperf3: error - the server is busy running a test. try again later"
C'est une propriété intéressante dans certains cas, mais pas pour un serveur public.
Le serveur "iperf.volia.net" reste utilisé en permance, j'ai fait de très ombreuses demandes, mais il est toujours "busy", probablement par un test de très longue durée.

L'option -D "Run the server in background as a daemon" ne change rien au problème.

Un petit malin a réussi à faire que iperf3 ne réponde plus tout en restant en ram, ce qui fait qu'il n'est pas redémarré automatiquement. Il s'est attaqué à plusieurs serveurs de la liste. Exemple :

Code: [Sélectionner]

$ iperf3 -c iperf.eenet.ee -i 1
iperf3: error - unable to receive control message: Connection reset by peer

L'impact sur la RAM sur mon serveur avec 5,43 Go de ram committed :

kgersen · « **Réponse #19 le:** 24 juillet 2015 à 22:25:21 »

effectivement c'est génant. ouvres une requete sur le bugtracker: https://github.com/esnet/iperf/issues

j'ai rapidement regardé le code source du serveur: https://github.com/esnet/iperf/blob/master/src/iperf_server_api.c

effectivement c'est 'en dur' pour un seul test a un moment et c'est pas 'forké': c'est le même processus qui écoute et traite un (seul) client (fonction iperf_accept).

Il faudrait donc 'forker' a chaque demande client pour être multi sessions mais ca va être compliquer à mettre en oeuvre en gardant le multithreading (option -P).

il manque aussi un timeout/quota par client (quota temps et volume).

edit: a regarder plus en detail le code d'iperf, ca va pas etre simple à faire , il est parti d'une approche vraiment mono client...

vivien · « **Réponse #20 le:** 24 juillet 2015 à 22:45:03 »

Tu pourrais faire la requête pour moi sur le bugtracker ? J'imagine qu'une requête complète qui utilise les bon terme a plus de chance d'être traitée.

Je pensais faire un script de test de débit (toujours le but d'avoir un test fiable pour les connexion 1Gpb qui consomme peu de ressources), il reste possible de démarrer le serveur iperf sur plusieurs ports, mais cela complique les script coté client.

Le risque de blocage du serveur, va m’obliger a killer régulièrement iperf3, comme iperf2 (Je ne l'ai pas encore fait, je regarde dans combien d'heure il sera de nouveau planté).

kgersen · « **Réponse #21 le:** 24 juillet 2015 à 23:36:24 »

j'ai fais la requête. https://github.com/esnet/iperf/issues/285

En attendant, tu peux éventuellement faire du load balancing dns avec plusieurs IP sur le même serveur par exemple.

vivien · « **Réponse #22 le:** 24 juillet 2015 à 23:50:52 »

Merci,

Problème, pour l'idée de load balancing sur plusieurs IP, il ne semble pas possible de forcer iPerf à écouter sur une IP particulière (comme le fait Apache2), pour mettre plusieurs iPerf sur le même port, sur des IP différentes, sur le même serveur.

Cela passe forcèment par une virtualisation ou une mise en container type Docker

cookie · « **Réponse #23 le:** 25 juillet 2015 à 13:54:26 »

Iperf3 n'est pas conçu pour avoir plusieurs clients en même temps.
Une demande avait été faite il y a 2 ans pour supporter plusieurs tests parallèle avec le même serveur.
https://code.google.com/p/iperf/issues/detail?id=130
La demande avait été rejetéé, les développeurs d'iperf n'ayant aucune intention d'aller vers cette voie.