Débit write() / read()

Version imprimable

14/05/2012, 16h22
vali103

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.. :calim2:, 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 ;)
14/05/2012, 17h01
ram-0000

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.
15/05/2012, 14h22
matafan

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
16/05/2012, 22h06
Jérôme_C

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

Citation:

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().