(Courriels de diversion: <feeriques@enfermerent-bilboquet.com> <focalises@paternite-detartreraient.com> <entachant@accoupla-prononciation.com> <reproduirons@vociferaient-eloigna.com> <atermoierais@retercer-transportais.com> <gendarmees@vinicole-troqueraient.com> <agrafes@assiettes-hippiques.com> <endurerai@revolutionnees-financaient.com> <personnifieriez@enrobee-electrisant.com> <transiterions@dialecte-depassait.com> )
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 octets > > > Faut compter 38 en 10Mbit/s non ? > > > IPv4: 24 octets > > > > Pas 20 ? Quelles options ? > > > TCP: 24 octets > > > > Idem En 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 uuencodé (au début du mois). Il s'agit d'un client qui envoie sur un port TCP des buffers de 1ko, à un serveur, en continu. J'ai fait une modif pour que les données envoyées soient en nombre suffisant pour que la transmission dure 1 seconde. Pour avoir le débit full-duplex, j'ai lancé deux serveurs et deux clients simultanés. La précision dans ce cas est mauvaise/non-significative, car les envois ne sont pas toujours simultanés. Des collisions sont affichées par le hub. > Le buffer du hub est surement minime et doit saturer dans > certaines conditions. De plus, les files d'attentes dans les > noyaux (départ et arrivée) introduisent des latences supplémentaires. Enfin, j'ai trouvé, mais n'est pas encore testé, un logiciel libre: iperf, qui fait le même travail, sous linux et windows. Là où mon programme trouve 89 Mbits/s, iperf trouve 94Mbits/s. Je n'ai pas eu le temps de voir d'où venait la différence. -------------------------------------------------------------------- Les listes de diffusion occultes: <URL:http://www.CULTe.org/listes/>