(Courriels de diversion: <hypothequeriez@vieilliraient-inopportunement.com> <calquaient@avouait-feeriques.com> <enfermerent@bilboquet-focalises.com> <paternite@detartreraient-entachant.com> <accoupla@prononciation-reproduirons.com> <vociferaient@eloigna-atermoierais.com> <retercer@transportais-gendarmees.com> <vinicole@troqueraient-agrafes.com> <assiettes@hippiques-endurerai.com> <revolutionnees@financaient-personnifieriez.com> )
jeanmichel.123@free.fr wrote:
Quoting Emmanuel Chaput <Emmanuel.Chaput@enseeiht.fr>:Jean-Michel wrote:Jean-Michel a �crit :Jean-Michel a �crit :Je souhaite mesure le d�bit entre n machines (deux � deux) sur un r�seau LAN. J'ai donc envisag� d'�crire un script python afin de * mesurer le temps pris par le transfert * pouvoir ajouter des fonctionnalit�s de mesure facilement Je suis donc emmen� � me poser les deux questions suivantes: * Python ne risque t'il pas de par sa lenteur al�atoire due au garbage collector de perturber les mesures? * Est-il possible de lire des donn�es sur un flux TCP, sans avoir � cr�er un objet pour chaque paquet lu? Le cas �ch�ant, comment faire?N'ayant aucune r�ponse, je ne peux que faire le constat suivant: a priori, l'acc�s au r�seau est plus rapide en java qu'en python, � moins que cela soit simplement du � une moindre sollicitation du garbage collector.Pour r�duire les lenteurs de python, il y a deux solutions: * passer de python 2.4 � python2.5 * activer l'option d'optimisation. Mais m�me en cumulant ces deux avanc�es, java reste plus rapide.code java ci-apr�s:(...) Les performances obtenues en java sont de l'ordre de: 89 Mbits TCP/s (entre deux cartes PCI reli�es par un cable) 8.0 � 8.5 Mbits TCP/s (entre les deux m�me cartes PCI reli�es via un hub 10 MBits indiquant des collisions) 700 Mbits TCP/s (en loopback, sans doute li� � la lenteur de java). 60 � 75 Mbits dans chaque sens (�missions bidirectionnelles, en direct) 8 et 0.5 Mbits avec une dissym�trie forte (�missions bidirectionnelles, via un hub 10 Mbits/s) Toutefois, d'apr�s un calcul th�orique, la �perte� de d�bit serait de ethernet: 14 ou 22 octetsFaut compter 38 en 10Mbit/s non ?IPv4: 24 octetsPas 20 ? Quelles options ?TCP: 24 octetsIdemEn fait, je ne sais pas exactement.Soit un total de 62 � 70 octets d'ent�te, pour 1000 octets transmis, soit 6 ou 7 pourcent. Cela m'emm�ne � me poser quelques questions: * Pourquoi est-ce que le d�bit mesur� est de 89 Mbits et pas 93 ou 94? * Pourquoi sur un hub 10Mbits, un sens de connexion est privil�gi� par rapport � l'autre lors d'une communication bidirectionnelle?Quelle est la pr�cision de tes mesurees ? O� et comment sont elles r�alis�es ? Observes-tu des pertes/erreurs/collisions ?C'est le r�sultat d'un programme java que j'ai envoy� dans cette liste au format
Je viens d'y jeter un oeuil ... Si la seule mesure du débit est celle que j'ai trouvé dans RequestHandler, il ne faut pas s'attendre à une précision foudroyante ! Cela dit, vouloir mesurer un débit avec précision, qu'est-ce que ça veut dire ?
Des collisions sont affich�es par le hub.
Oui. On peut observer un peu plus précisément sur les machines (avec ifconfig, par exemple, tout simplement).
Enfin, j'ai trouv�, mais n'est pas encore test�, un logiciel libre: iperf, qui fait le m�me travail, sous linux et windows.
Il ne faut pas non plus s'attendre à quelque chose de précis, si tant est que ça veuille dire quelque-chose, donc ...
L� o� mon programme trouve 89 Mbits/s, iperf trouve 94Mbits/s.
Quelques paramétrages ou mesures un peu différents et on y est ... 5% ce n'est pas énorme ... Cordialement -- Emmanuel Chaput, Maître de Conférences - Dépt Télécom & Réseau, ENSEEIHT Equipe Ingénierie Réseaux et Télécommunications IRIT-CNRS *5 61 58 82 10 (Fax *5 61 58 83 06) Emmanuel.Chaput@n7.fr -------------------------------------------------------------------- Les listes de diffusion occultes: <URL:http://www.CULTe.org/listes/>