TIMER MICROSECONDE PAS TRÉS PRECIS
jlen100
Messages postés
1606
Date d'inscription
samedi 10 juillet 2004
Statut
Membre
Dernière intervention
25 juillet 2014
-
14 févr. 2006 à 16:03
jlen100 Messages postés 1606 Date d'inscription samedi 10 juillet 2004 Statut Membre Dernière intervention 25 juillet 2014 - 16 févr. 2006 à 13:46
jlen100 Messages postés 1606 Date d'inscription samedi 10 juillet 2004 Statut Membre Dernière intervention 25 juillet 2014 - 16 févr. 2006 à 13:46
A voir également:
- TIMER MICROSECONDE PAS TRÉS PRECIS
- Microseconde signe ✓ - Forum C
- Microseconde en seconde ✓ - Forum PHP
7 réponses
jlen100
Messages postés
1606
Date d'inscription
samedi 10 juillet 2004
Statut
Membre
Dernière intervention
25 juillet 2014
13
14 févr. 2006 à 16:40
14 févr. 2006 à 16:40
pour le probléme du temps passé dans l'Application.ProcessMessage je ne sais pas s'il existe une routine permettant de le vérifier.
dans mon appli je m'étais livré à l'expérience suivante:
1) pour déterminer les temps de calcul propre aux routines j'envoie sur le port ethernet (facilement accessible et rapide pour ne pas perturber la mesure)une trame et je mets un analyseur sur le port ceci me permets de déterminer l'interval de temps entre chaque trame sachant que je n'attends pas de réponse c'est en quelque sorte une boucle ouverte
2) dans un premier temps je place cette trame dans une boucle for . Avec un processeur à 2,6Ghz l'interval est ~100ns ceci donne donc le temps pour efffectuer une iteration.
3) ensuite je place cette trame dans un thread en priorité haute et j'appelle l'Application.ProcessMessage à chaque itération.
résultat
temps mini400ns temps maxi15ms
conclusion les threads ne sont pas adaptés au processus rapides exigeant un timming précis
je n'ai pas testé mais l'on devrait peut etre obtenir une meilleure précision en gerant les events de windows (sorte d'interruption logiciel) je ne l'ai pas fait car meme 100ns était encore trop long pour moi.
@+
jlen
dans mon appli je m'étais livré à l'expérience suivante:
1) pour déterminer les temps de calcul propre aux routines j'envoie sur le port ethernet (facilement accessible et rapide pour ne pas perturber la mesure)une trame et je mets un analyseur sur le port ceci me permets de déterminer l'interval de temps entre chaque trame sachant que je n'attends pas de réponse c'est en quelque sorte une boucle ouverte
2) dans un premier temps je place cette trame dans une boucle for . Avec un processeur à 2,6Ghz l'interval est ~100ns ceci donne donc le temps pour efffectuer une iteration.
3) ensuite je place cette trame dans un thread en priorité haute et j'appelle l'Application.ProcessMessage à chaque itération.
résultat
temps mini400ns temps maxi15ms
conclusion les threads ne sont pas adaptés au processus rapides exigeant un timming précis
je n'ai pas testé mais l'on devrait peut etre obtenir une meilleure précision en gerant les events de windows (sorte d'interruption logiciel) je ne l'ai pas fait car meme 100ns était encore trop long pour moi.
@+
jlen
Sylvainlefou
Messages postés
43
Date d'inscription
vendredi 27 décembre 2002
Statut
Membre
Dernière intervention
15 février 2006
14 févr. 2006 à 19:43
14 févr. 2006 à 19:43
Ok, merci beaucoup, je pense que je vais garder le timer classique 1ms, si cela ne vas pas, je passerais par un microcontroleur (qui ne tourne pas sous windows, lui )
jlen100
Messages postés
1606
Date d'inscription
samedi 10 juillet 2004
Statut
Membre
Dernière intervention
25 juillet 2014
13
14 févr. 2006 à 20:19
14 févr. 2006 à 20:19
c'est sur que dans ton cas le timer classique doit faire l'affaire car s'il n'est pas précis sur des petits intervals il présentent une bonne reproductibilité sur de longues périodes (en fait même s' il y a erreur sur une periode elle n'est pas cumulative tant qu'on le laisse enabled)
je l'uitlise reglé à 50ms pour faire des scans de process sans qu'il présente de problème les actions demandant des timing très courts étant réalisées par un carte à microcontroleur.
@+
jlen
je l'uitlise reglé à 50ms pour faire des scans de process sans qu'il présente de problème les actions demandant des timing très courts étant réalisées par un carte à microcontroleur.
@+
jlen
Vous n’avez pas trouvé la réponse que vous recherchez ?
Posez votre question
jlen100
Messages postés
1606
Date d'inscription
samedi 10 juillet 2004
Statut
Membre
Dernière intervention
25 juillet 2014
13
14 févr. 2006 à 20:20
14 févr. 2006 à 20:20
la M.. sur la textbox évoluée recommence!!
cs_rt15
Messages postés
3874
Date d'inscription
mardi 8 mars 2005
Statut
Modérateur
Dernière intervention
7 novembre 2014
13
16 févr. 2006 à 13:05
16 févr. 2006 à 13:05
Heu pardon, ça à m'a l'air très pro ce topic. Mais bon, je m'exprime quand même.
J'ai été confronté à ce probléme. La première solution que j'ai trouvé à été d'utiliser le compteur TSC du processeur, accessible via l'instruction assembleur RDTSC. Ce compteur s'incrémente à chaque front d'horloge du processeur.
Cependant, la régularité de ce compteur n'est pas garantit, sur certains processeurs de portables nottement.
Heureusement, windows permet d'accéder aux compteur hardware, via les API QueryPerformCounter et QueryPerformFrequency. Le premier renvoie la fréquence du compteur hardware, et la deuxième la valeur du compteur.
Je n'ai pas trouvé le source situé plus haut, donc désolé s'il utilisait déjà ces API.
Néanmoins, comme le dit jlen100, cette méthode est ultra précise, dans un certain nombre de cas (Boucler sur un Sleep(0) en attendant une certaine valeur du compteur).
Car si windows à la mauvaise idée de passer la main à un trhead un peu long, la valeur est dépassée. Donc on à généralement des résultat du style :
510 µs
504 µs
503 µs
13345 µs
505 µs
C'est les joies du multitâche, et comme le dit jlen100, carte d'extension ou instruction systèmes obligatoires pour passer outre.
J'ai été confronté à ce probléme. La première solution que j'ai trouvé à été d'utiliser le compteur TSC du processeur, accessible via l'instruction assembleur RDTSC. Ce compteur s'incrémente à chaque front d'horloge du processeur.
Cependant, la régularité de ce compteur n'est pas garantit, sur certains processeurs de portables nottement.
Heureusement, windows permet d'accéder aux compteur hardware, via les API QueryPerformCounter et QueryPerformFrequency. Le premier renvoie la fréquence du compteur hardware, et la deuxième la valeur du compteur.
Je n'ai pas trouvé le source situé plus haut, donc désolé s'il utilisait déjà ces API.
Néanmoins, comme le dit jlen100, cette méthode est ultra précise, dans un certain nombre de cas (Boucler sur un Sleep(0) en attendant une certaine valeur du compteur).
Car si windows à la mauvaise idée de passer la main à un trhead un peu long, la valeur est dépassée. Donc on à généralement des résultat du style :
510 µs
504 µs
503 µs
13345 µs
505 µs
C'est les joies du multitâche, et comme le dit jlen100, carte d'extension ou instruction systèmes obligatoires pour passer outre.
jlen100
Messages postés
1606
Date d'inscription
samedi 10 juillet 2004
Statut
Membre
Dernière intervention
25 juillet 2014
13
16 févr. 2006 à 13:46
16 févr. 2006 à 13:46
salut rt15
j'avais posté mes commentaires ici suite à quelques problèmes de post
tu peux trouver la source ici
il utilise effectivement ces API mais pur ne pas bloquer le process il
les a incluses dans un thread en association avec un
Application.ProcessMessage (pour résumer mais il vaut mieux voir
la source) ce qui à pour conséquence que la fin du thread n'est
effectivement donnée que quand Windows le traite avec le résultat que
tu as donné.
Une solution aurais été de le traiter en event mais même dans ce cas
c'est Windows qui traite l'event et la précision n'est pas garantie.
La véritable solution est de provoquer un interruption mais ceci n'est
accessible qu'en langage assembleur et XP n'aime pas trop ce genre de
manip: il faut que le traitement soit suffisament court pour ne pas
perturber la gestion de thread et c'est génarelement assez pour avoir
le resultat dans l'application (en général on met le traitement en DLL)
Pour les process rapides demandant des timing très précis on fait appel à de cartes d'extension ou des circuits spécialisés.
l'expérience montre que Windows n'est pas du tout adaptée à ce genre de
situation (d'ailleurs il n'a pas été développé pour cela) et que les
solutions logicielles finissent par couter plus chères que la carte
d'extension.
@+
jlen
j'avais posté mes commentaires ici suite à quelques problèmes de post
tu peux trouver la source ici
il utilise effectivement ces API mais pur ne pas bloquer le process il
les a incluses dans un thread en association avec un
Application.ProcessMessage (pour résumer mais il vaut mieux voir
la source) ce qui à pour conséquence que la fin du thread n'est
effectivement donnée que quand Windows le traite avec le résultat que
tu as donné.
Une solution aurais été de le traiter en event mais même dans ce cas
c'est Windows qui traite l'event et la précision n'est pas garantie.
La véritable solution est de provoquer un interruption mais ceci n'est
accessible qu'en langage assembleur et XP n'aime pas trop ce genre de
manip: il faut que le traitement soit suffisament court pour ne pas
perturber la gestion de thread et c'est génarelement assez pour avoir
le resultat dans l'application (en général on met le traitement en DLL)
Pour les process rapides demandant des timing très précis on fait appel à de cartes d'extension ou des circuits spécialisés.
l'expérience montre que Windows n'est pas du tout adaptée à ce genre de
situation (d'ailleurs il n'a pas été développé pour cela) et que les
solutions logicielles finissent par couter plus chères que la carte
d'extension.
@+
jlen
