Discussion :

[doommick31]

Bonjour,
Actuellement je travail sous Qt et j'utilise la classe QTime mais celle -ci ne gére au maximum les milli-secondes ms . Est ce qu'il existe une librairie en C++ (ou même en C ) qui permette d'utiliser des temps et des timers gérant la micro seconde µs?

Merci d'avance pour votre réponse.

[dtrosset]

Bonjour,

Il existe gettimeofday en C, pour Linux (POSIX), et Windows propose QueryPerformanceCounter.

Didier

[Matthieu Brucher]

Mais bon, faut pas rêver. Les OS classiques ne permettent pas de descendre à une telle précision.

[loufoque]

HPET ça fournit une précision de l'ordre de 100 nanosecondes, et c'est supporté par Windows (Vista, 2008), Mac OS X et Linux...

[buzzkaido]

Tout depend ce que tu veux faire :

Si il s'agit de declencher periodiquement un evenement avec un intervalle de temps tres court (ms ou plus petit) les OS classiques ne le permettent pas : en dessous d'un certain seuil ce n'est pas possible, et sinon il y a toujours une marge d'erreur (pouvant etre assez grande : selon ce que l'OS est en train de faire, le Timer peut se declencher avec plusieurs ms, voire plusieurs dizaines de ms de retard)

Si il s'agit de "chronometrer" le temps ecoulé entre deux instants, tous les processeurs modernes permettent d'acceder à des compteurs extrement precis : compteur de temps, compteur de nb de cycles... et les OS modernes permettent de lire ces compteurs, on peut donc mesurer du temps de façon tres precise (QueryPerformanceCounter sous windows)

Pour ce qui est du HPET, ça ne marche que sur les OS tres recents :wikipedia

Enfin, une technique couramment utilisée pour pallier à ces soucis lorsque l'on souhaite declencher des evenements de façon precise, par exemple dans un jeu vidéo, lorsque le joueur appui sur une fleche, on doit deplacer le personnage de 50px toutes les 10ms :

- On crée un timer declenché toutes les 10ms
- A chaque fois que le timer est declenché, on lit un compteur tres precis (QueryPerformanceCounter par exemple) et on calcule le temps ecoulé depuis la derniere fois, on a :
deltaT = t2-t1
= 8ms parfois
= 12ms parfois
- on calcule le deplacement du joueur avec cette valeur :
deltaPx = (50px / 10ms) * deltaT

ainsi, meme si le personnage a l'ecran n'est pas réélement deplacé toutes les 10ms, la vitesse à laquelle il se deplace est constante et est bien celle voulue.

[Klaim]

Sous windows, l'api propose la fonction QueryPerformanceCounter() pour les mesures de temps précises.

A partir de ça tu peux avoir ce que tu demandes, mais attention aux subtilitées : http://support.microsoft.com/?scid=k...72338&x=17&y=5

Il y a aussi potentiellement des problèmes avec les processeurs multicores. Je recommande la lecture du code qu'utilises Ogre pour ajuster l'information du temps : http://ogre.svn.sourceforge.net/view.../OgreTimer.cpp

[mayayu]

Il ne faut pas rêver, sur un OS type Windows ou Linux, les intervalles de temps ne sont pas garantis.
Seuls des OS temps réel (eCos, RTAI, ...) peuvent garantir un intervalle de temps fixe (et encore tout dépend de la priorité du processus), mais il n'attendra jamais la µS.
A ce niveau-là il faudrait que tu développes ton propre OS.
Sinon il faut faire comme le propose "buzzkaido", utiliser les compteurs de ton processeur.

[Klaim]

OS temps réel

Tiens c'est la première fois que j'entends parler de ça, ça mérite une longue plongée dans wikipédia.

[mayayu]

Wikipedia est un peu limité pour ça, par contre tu trouveras des infos ici : http://kadionik.developpez.com/ notamment dans cet article : http://kadionik.developpez.com/cours...ux-temps-reel/

[Klaim]

Ok merci pour le doc qui est effectivement plus clair. En gros on fait sauter la couche d'ordonnancement pour que tout soit direct (dans le temps) entre le hardware et le software, si j'ai bien compris.

[mayayu]

Je ne suis pas assez pointu sur le sujet pour te répondre précisément mais je pense que ça reste au niveau soft.

A chaque cycle de l'ordonnanceur, il prend la priorité configurée du processus auquel il ajoute son "âge" (temps depuis sa dernière exécution) pour créer un "priorité dynamique" et identifier celui qu'il doit exécuter.

Exemple :

Le processus 1 a une priorité de 100 et le processus une priorité de 95

1er cycle :
processus 1 (priorité = 100) + (âge = 0) = 100
processus 2 (priorité = 95 ) + (âge = 0) = 95
exécution du processus 1 (son âge reste à 0), l'âge du processus 2 s'incrémente de 10.

2ème cycle :
processus 1 (priorité = 100) + (âge = 0) = 100
processus 2 (priorité = 95 ) + (âge = 10) = 105
exécution du processus 2 (son âge passe à 0), l'âge du processus 1 s'incrémente de 10.

etcétéra

On peut en déduire que plus la priorité d'un processus sera élevé par rapport aux autres, plus souvent l'ordonnanceur l'exécutera.

La période d'ordonnancement s'appelle le "ticks".

Il est illusoire de croire que l'on pourra exécuter un processus de forte priorité à chaque "ticks" car même un processus de faible priorité finira par avoir un âge suffisant pour être exécuté, et c'est là qu'on va se poser la question "Pourquoi ça marche pas?".

Il faut donc bien avoir à l'esprit que la période d'exécution de notre processus doit être un multiple du "ticks".

[Matthieu Brucher]

Temps réel = on sait au bout de combien de temps la requête aura abouti. Une interruption se déclenche, on ne sait pas au bout de combien de temps elle sera traitée dans un OS classique. Avec un OS temps réel, on sait.

[Klaim]

Ok je vois maintenant, merci pour ces précisions

[ctxnop]

Salut, je reviens un peu sur ce sujet de temps réel.
Un OS temps réel n'est pas forcément plus rapide qu'un OS classique. C'est juste que, comme l'a dit Matthieu Brucher, sur un OS temps réel on connait à la perfection l'agencement que vont prendre les processus dans l'ordonnanceur. On connait également de mannière certaine le nombre de cycle d'ordonnancement qu'un traitement donné va prendre.
On peux donc établire de manière certaine des faits qu'on ne connait absolument pas sur un OS classique. Par exemple, je code un processus A et un autre B, je peux déterminer avec certitude, sans code ni moyens de synchronisation entre ce deux processus et avant même que j'ai éxécuté ne serait-ce qu'une fois ces programmes, que A finira exactement 12 cycles d'ordonnancement avant B. Celà permet donc "juste" d'être déterministe sur les évènements qui vont arriver.

Ce que tu cites Emiaille, ce n'est qu'un algo d'ordonnancement parmis tant d'autres. On a même des algos d'ordonnancement temps réel qu'on a jamais vraiment implémenté car sur le papier le calcul se fait bien mais en informatique le calcul prendre trop de temps et enlève donc ce temps à l'éxécution des processus et ne sont donc pas viables.

Le temps réel porte assez mal son nom dans la mesure où il n'est absolument pas question de vitesse ou de temps tels qu'on le mesure nous (en seconde).

Pour finir, j'ajouterais que le kernel Linux peut se configurer de plein de manière différentes, et accepte notemment une configuration de la fréquence du tick d'ordonnancement ce qui réduit la latence et augmente donc la précision du temps (au détriment des performances car l'ordonnaceur switchant plus souvent ca veux aussi dire que le processeur fait un changement de contexte à chaque fois et c'est lent). De plus, le kernel linux existe dans des déclinaisons temps réel (RTLinux et d'autre).

[doommick31]

Merci de vos réponses, j'ai pu me faire une idée sur les performances des OS classiques.

Avec les OS classiques on peut tenir des performances de l'ordre de 10ms très facilement.
En dessous, il faut soit passer à un OS temp réel pour être sur de ce que l'on fait ou bien bidouiller un peu avec des fonctions un peu spéciale (pas sur).

Bien entendu cela depends de l'utilisation que l'on fait.