Discussion :

[cheprod]

Bonjour,

Je souhaite faire des benchs sur un serveur. Pour cela j'ai écrit un injecteur qui toutes les n microsecondes envoie une requête au serveur.

Pour effectuer ces opérations, j'utilise la fonction ftime pour les mesures de temps.

Pour les pauses, j'ai essayer d'utiliser les fonctions usleep et nanosleep mais j'ai l'impression qu'auncunes d'entre elles n'ai réellement précises.

Par exemple, si je fais :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
times(&t1);
usleep(1000);
times(&t2);

Le temps entre t1 et t2 est alors le plus souvent près de 10ms que de 1ms. J'ai vu que la résolution de ces fonctions étaient souvent de 10ms...
http://man.developpez.com/man2/nanosleep.2.php J'ai le même résultat avec la procédure nanosleep...

Existe-t-il un moyen d'obtenir une précision supérieur en faisant par exemple appel à des fonctions liés au processeur ?

Merci d'avance pour vos réponses

[JulienDuSud]

Une précision d'1ms c'est, je pense, impossible sur le pc de l'utilisateur lambda

[cheprod]

Re,

Pour plus de précision, c'est un pc quadri-processeur avec une Red-Hat d'installer dessus.

gcc 3.2.3
noyau linux : Linux version 2.4.21-20.0.1

Vous croyez que c'est possible

[Invité]

Ton 10 ms est du au fait que linux (comme windows et la plupart des autres os grand public) utilisent un timeslice de 10 ms (100 hz) pour le task-switching.

Etant donne que tu utilise linux, tu peux switcher a un kernel plus recent ou etal a 2.6.12 pour profiter d'un timeslice plus precis. En effet, depuis cette version, tu as le choix entre 100hz, 250hz, ou 1000hz (a toutes les millisecondes).

Tu devrais voir une amelioration de precision sur tes mesures de temps.

[BigNic]

Même en appelant des fonctions liées au processeur, cela parait difficile. En effet le micorprocesseur peu certainement avoir la précision requise, mais qu'est-ce qui t'assure que le systéme (l'OS) ne donne pas la main à d'autre prog entre ton instruction times et usleep ?
Si tu regardes les docs d'outils de profiling comme quantify, il se dédoine de ce genre de pb en t'asurant que les proportions entre les temps d'appel sont bon, mais que les temps d'appel sont qu'indicatif. Car justement leurs programmes ne font qu'ajouter des appels à time (ou équivalent) autour de tes fonctions.
Pour avoir un telle précision il faut avoir une vrai archi temps réel, mais ça c'est une autre histoire.
Dans ma boite pour tester les serveurs on a grosso modo 3 méthodes. Les deux premières servent à déterminer le temps de latence de réponse du serveur:
1) On envois nos requêtes par gros paquets (ex:1000) et on attend la dernière réponse et après on fait la moyenne des temps de réponse.
2) On balance une seule requête et on attend la réponse. Puis on en revois une autre. etc...
Les deux modes de test peuvent donner des résultats différents, car dans le premier le serveur peut spooler.
Si on veut une fréquence max de réponse du serveur, on utilise la méthode 1) en augmentant la tailles des paquets. Généralement au bout d'une certaine taille le temps de réponse du serveur se stabilise, et augmenter la taille des paquets ne fait que le faire spooler d'avantage.
HTH.