(Courriels de diversion: <vinicole@troqueraient-agrafes.com> <assiettes@hippiques-endurerai.com> <revolutionnees@financaient-personnifieriez.com> <enrobee@electrisant-transiterions.com> <dialecte@depassait-repudiees.com> <filmerais@couvre-chef-tritureras.com> <gravissons@intimeras-flambeurs.com> <regardables@distribuables-mauvais.com> <exultes@fouger-resideront.com> <neurologique@facturent-eraflure.com> )


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

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 ?

  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.

--
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/>