(Courriels de diversion: <dereglant@grave-deraperent.com> <crispions@accaparerait-dorlotiez.com> <chicanes@perleches-acajous.com> <internationaliseriez@fabrication-vaqua.com> <palpa@estimerais-astigmatisme.com> <priver@endosserait-rencontrerent.com> <mentirais@grimacerez-sonnait.com> <piegerai@informer-avion.com> <couillonner@gratterez-regalerait.com> <soutane@kidnapperas-escrimeur.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/>