IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Réseau C Discussion :

Débit write() / read()


Sujet :

Réseau C

  1. #1
    Futur Membre du Club
    Profil pro
    Inscrit en
    Avril 2005
    Messages
    5
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Avril 2005
    Messages : 5
    Points : 5
    Points
    5
    Par défaut Débit write() / read()
    Bonjour,

    Je possède deux processus : A & B et je souhaite mesurer le débit entre eux.
    'A' envoi un fichier :
    * il l'ouvre avec fopen
    * créé un socket TCP à destination de B
    * écrit le fichier dans le socket avec write()
    Juste avant/après le write j'ai mis un gettimeofday() pour connaitre la durée d'écriture.

    'B' est le récepteur
    * création d'un socket TCP
    * écoute et récupère les octets du socket avec read()
    * les dépose dans un nouveau fichier
    Là encore, juste avant/après le read j'ai mis un gettimeofday() pour connaitre la durée d'écriture.

    Bref on est dans le cas typique & très simple d'un client/serveur.
    J'ai mis en place un select() pour ne pas avoir de blocage.

    Mon problème : les durées d’exécution du write() et du read(), mesurées avec gettimeofday, ne sont vraiment pas identique. 'A' écrit un fichier de 64ko en 0,3ms tandis que 'B' lit ce même fichier en 2,5ms en moyenne. J'ai réalisé de nombreux tests et tous confirment cette impression : 'A' écrit 10x plus rapidement que 'B' ne lit.
    J'ai essayé d'ajouter un fsync(fd) juste après le write() appelé par 'A', mais cela ne change rien. Cependant, si j'ajoute un sync(), là, la durée d'exécution passe de 0,3ms à 250ms.. , ce qui est irréaliste pour un si petit fichier.

    Bref, que faire pour avoir un ordre de grandeur d'écriture et de lecture sur socket à peu près identique ?

    Merci pour vos réponses

  2. #2
    Rédacteur

    Avatar de ram-0000
    Homme Profil pro
    Consultant en sécurité
    Inscrit en
    Mai 2007
    Messages
    11 517
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 61
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Consultant en sécurité
    Secteur : High Tech - Opérateur de télécommunications

    Informations forums :
    Inscription : Mai 2007
    Messages : 11 517
    Points : 50 367
    Points
    50 367
    Par défaut
    Probablement que ton write() écrit par petit tronçons, lors du transit, ces write() sont ré-assemblés et tu lis la même quantité d'octets avec moins d'appel read().

    Essaye de compter le nombre de write() et de read() pour confirmer ce que je viens de supposer.

    Une solution tronçonner au niveau du write() avec des gros paquets (10K ou plus) et laisser la pile TCP ou UDP gérer le tronçonnage, cela sera plus efficace.
    Raymond
    Vous souhaitez participer à la rubrique Réseaux ? Contactez-moi

    Cafuro Cafuro est un outil SNMP dont le but est d'aider les administrateurs système et réseau à configurer leurs équipements SNMP réseau.
    e-verbe Un logiciel de conjugaison des verbes de la langue française.

    Ma page personnelle sur DVP
    .

  3. #3
    Membre émérite
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Octobre 2008
    Messages
    1 515
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 45
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : Octobre 2008
    Messages : 1 515
    Points : 2 505
    Points
    2 505
    Par défaut
    Le problème c'est que tu ne comptes pas seulement le temps nécessaire à la lecture des données, mais aussi le temps que tu passe à attendre que des données soient disponibles. En gros dans ton read() tu as :

    - Le temps à attendre que l'autre commence à envoyer des données
    - Le temps à attendre que l'autre envoie ces données
    - Le temps passé à lire les données

  4. #4
    Membre averti
    Profil pro
    Inscrit en
    Janvier 2008
    Messages
    214
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Janvier 2008
    Messages : 214
    Points : 310
    Points
    310
    Par défaut
    Est-ce que c'est exactement du même ordre de grandeur pour des données plus volumineuses ?

    Ta différence de temps d’exécution montre bien que ton write n'est pas bloquant : Ton write pousse et te rend la main alors que les données ne sont pas encore sorties de la scoket, alors que pour le read, il faut le temps que toutes les données soient arrivées.

    Teste vraiment avec des données plus grandes, les décalages constants sont courants, la proportionnalité dans les débits fonctionne souvent que pour les volumes les plus grands, les plus optimisés...

    J'ai essayé d'ajouter un fsync(fd) juste après le write() appelé par 'A', mais cela ne change rien. Cependant, si j'ajoute un sync(), là, la durée d'exécution passe de 0,3ms à 250ms.. , ce qui est irréaliste pour un si petit fichier.
    sync() concerne tous les descripteurs de fichiers ouverts, n'est-ce pas ? Et pas que le descripteur de ficher passé en paramètre, comme peut l'être fsync().

Discussions similaires

  1. Envoi sur tube "tmp", write(), read()
    Par Damien3193 dans le forum C
    Réponses: 4
    Dernier message: 07/01/2013, 12h28
  2. Réponses: 2
    Dernier message: 30/04/2010, 20h34
  3. Write puis read sur port com
    Par chourmo dans le forum API, COM et SDKs
    Réponses: 34
    Dernier message: 21/06/2005, 17h36
  4. Problème de read/write
    Par mylooz dans le forum Entrée/Sortie
    Réponses: 7
    Dernier message: 25/03/2005, 19h15
  5. Réponses: 6
    Dernier message: 18/10/2004, 14h30

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo