comment faire une pause précise (1/10000 s)

Bonjour,

Je cherche une méthode *fiable* pour faire des pauses précises au 1/10 de milliseconde (voire à 1 milliseconde).

J'ai exclu usleep qui est d'une précision ridicule (ne descend pas en dessous de 15 ms, sauf si j'indique usleep(1), alors là le temps d'attente varie de 1/2 à 1 microseconde.


La seule solution que j'ai trouvé actuellement est d'utiliser l'interruption RDTSC des x86 et faire une boucle d'attente. Cette interruption indiquant un nombre de cycles d'horloge, il me faut une base de temps (nombre de cycles pour une période donnée).

Je procède donc comme suit :

je récupère une 1ère valeur d'horloge
je fais un "usleep(500000)" qui semble être assez précis pour cette durée
je récupère la 2ème valeur d'horloge
j'en déduit un nombre de cycles pour une micro-seconde, et enfin, je peux faire une boucle d'attente.

Cette solution ne me convient cependant guère, d'une part parce que cela occupe 100% du cpu, d'autre part car je me base sur le fait que usleep(500000) est toujours juste (ce qui n'est apparement pas le cas sur un vieux portable PIII) et que la frequence du cpu ne varie pas (ce qui est faux par exemple sur une plateforme centrino).

Je cherche donc une solution plus fiable, et m'en remet à vos conseils.

Je précise que je dois faire un code compilable pour windows et linux.

Note : J'ai tenté de voir comment procedait la librairie LiveMedia (utilisée par VLC pour le streaming) pour appliquer le delai d'attente entre deux paquets. Mais je n'arrive pas à saisir comment cela fonctionne. (S'il y en a qui connaissent, je pense que ça se passe dans DelayQueue.cpp)

Deux questions :

1/ Pourquoi as-tu besoin d'une telle précision ?
2/ Qu'attendrais-tu comme résultat d'une pause de 0.1 ms, alors que ces systèmes d'exploitation ont des quantum de temps de plusieurs dizaines de millisecondes par processus ?

Citation:

---

Envoyé par Laurent Gomila

Deux questions :

2/ Qu'attendrais-tu comme résultat d'une pause de 0.1 ms, alors que ces systèmes d'exploitation ont des quantum de temps de plusieurs dizaines de millisecondes par processus ?

---

juste pour ma culture, ce ne serait pas 15 ms pour Windows XP ?
(disons pour un réglage de l'OS par défaut)

Citation:

---

Envoyé par Hylvenir

juste pour ma culture, ce ne serait pas 15 ms pour Windows XP ?
(disons pour un réglage de l'OS par défaut)

---

Personnellement je n'en ai aucune idée. J'ai souvenir de chiffres tels que 10, 20 ou 50, mais je suis incapable de les remettre dans un contexte précis.

J'ai besoin de ces pauses pour implémenter un protocole de streaming (c'est un projet de cours) RTP/RTCP.

Je dois donc diffuser des paquets à intervals réguliers qui devraient à priori être compris entre 15 et 100 ms (la valeur choisi est défini par le "débit" du média).

Edit : je n'ai pas vraiment besoin d'une précision de 1/10 ms, disons que c'est juste par mesure de précaution, une précision de l'ordre de la milliseconde est suffisant. En fait, il se peut que j'ai besoin d'une précision un peu moins grande, mais je n'en suis pas sûr (car je ne suis pas sûr que la méthode que j'emploie soit suffisament fiable).

Edit 2 : S'il y a un moyen de connaître les temps minimums alloués par l'OS, ça m'intéresse (je pourrais m'en servir en complément de la méthode que j'utilise afin de libérer du temps processeur).

Edit3 : J'ai également testé les boost::timer qui ne sont pas vraiment plus fiables que usleep :/

Pour ce genre de précision, des OS comme windows ou linux ne sont pas très appropriés. Le mieux que j'ai trouvé pour ce genre de valeur sur ce types d'OS, c'est l'attente active, après avoir passé le processus en priorité haute, et en ne faisant rien d'autre sur la machine.

Pour le temps de cadencement de base de windows, je crois bien que c'est effectivement autour de 16ms, mais avec des timers, et dans un environnement clean (pas d'encodage mp3 en tâche de fond, on évite de toucher à la souris...) on peut avoir des trucs relativement précis de quelques ms.

Bon en fait, j'ai fait une mauvaise analyse du comportement de la fonction usleep ...

Celle-ci ne descend bel et bien en dessous de 15ms jusqu'à 1ms. Elle réagis cependant bizzarement, elle fait des sauts de d'environ 900-1000 µs (parfois moins) à chaque fois que le chiffre des milliers est incrémenté.

Par exemple sleep(17000) dure 17847µs alors que sleep(16999) dure 16874µs.

Mais bon je devrais pouvoir me débrouiller avec ça. :aie:


PS : Je viens de me rendre compte que j'aurais du poster dans le forum C (désolé donc)

Sous windows, les valeurs de quantum sont en général de 6 'ticks' ou clock-interrupts (12 si l'application est en avant-plan ET que le système est règlé pour 'booster' celles ci). Les clock-interrupts étant d'environ 10.625ms (sur ma machine en tout cas). Soit carrément 63.75ms.

Ce qui veut dire que l'application en avant-plan doit être prête à attendre 64ms si elle lâche le CPU (wait, sleep, ...) et même 128ms si elle n'est pas en avant-plan.

Mais ca ne veut pas dire que ca arrive... Il est rare qu'un processus ne rende pas la main de temps en temps (sleep(0), wait for event-queue). Si aucun autre processus n'utilise 100% du CPU, il y a de grandes chances pour l'application récupère la main en moins de temps.

Pour ce qui est de ton projet... Il y a plein de moyens pour arriver à ca. A noter que le timer le + précis d'un PC lambda est celui du chipset audio (à moins qu'un GPS soit installé :) ).
Il est tout à fait possible de dire au timer audio de "raiser" un event toutes les X millisecondes... (par exemple être signalé à la fin de lecture z d'un buffer de 12000 échantillons, lus en boucle à 96kH fera un timer assez précis de 125ms).
Ensuite, dans ton code tu as juste une boucle qui "reset" l'event, puis envoit les données, et enfin attend l'event à nouveau.

Merci pour ces précisions, j'ignorais que l'on pouvait utiliser le timer audio comme ça.

Citation:

---

Pour ce qui est de ton projet... Il y a plein de moyens pour arriver à ca.

---

Et bien j'en cherche un qui soit fiable, donc si tu en sais davantage, n'hésite pas à m'en faire part ;)

Petite idée comme ca : Peut etre que tu pourrais regarder dans le code source de VLC/demander sur leur forum comment eux ils implementent ce delai apparemment tres important pour RTP

Je l'ai déjà fait, comme je l'ai précisé dans mon premier message, mais je n'arrive pas à comprendre comment la pause est faite ...

En fait je vais décocher résolu car si le usleep a bien fonctionné hier soir, ce devait être par miracle car j'ai retrouvé son comportement habituel ce matin c-à-d n'importe quoi.

Tu peux aussi utiliser WinMM qui possede un certains nombre d'utilitaire de timers...
Genre:
http://msdn.microsoft.com/library/de...mesetevent.asp
Mais 1ms minimum pour la lib multimédia.

En même... pour du RTP... 1ms (voire 10ms) devrait être largement suffisant pour le serveur.
Et côté client, c'est le son qui fait office de synchro :)

WinMM aurait pu être un bon moyen en effet, mais je en fait souhaite faire un code portable au moins sous windows et linux, donc pour ça c'est râpé.

Mais j'ai pu me débrouiller finalement avec ces usleep, je fais juste varier la durée de la pause en fonction des durées précédentes, pour obtenir une moyenne la plus proche possible du débit thérorique à atteindre.

Du coup, le débit varie parfois un peu (pour un débit de 192kbps, ça varie entre 189 et 195) mais le buffer de vlc semble absorber cette variation sans broncher :)

Merci pour ces conseils en tout cas.