Discussion :

[molox]

Salut,

Grand merci de consacrer du temps à m'aider, merci merci merci.

Le problème, c'est que ton thread d'acquisition est en "retard" sur les acquisitions réelles, de 1 à 32 ms pour être précis...

Exacte, en fait la latence optimum de ma carte d'acquisition est de 32ms min.

Le ralentir pour obtenir un décalage plus ou moins constant n'est pas vraiment une solution

Ouaip, même si ça marche, ca ne me satisfait pas

sauf que tu vas "forcer" un décalage temporel constant au lieu d'un décalage temporel variable

.
Effectivement, j'essaye de rattraper avec le processeur le temps de ma carte d'acquisition. L'horloge de la carte d'acquisition à une haute résolution et est relativement stable dans le temps.

Donc, ton thread qui renvoie le "GET_CURRENT_SAMPLE" est lui aussi "en retard", qu'il soit multiple ou pas de 32...

C'est la ou je ne suis pas d'accord avec toi, ou il me manque un clef pour comprendre, je m'explique :
Quand tu dis en retard, c'est par rapport au temps UTC, enfin à la granularité de temps dont on dispose sur le PC.

* Déja sur Windows dur dur de compter le temps UTC à la milliseconde, a part le performance counter, mais sur les P4 il subit les variations de l'economie d'energie du processeur donc niveau stabilité....

* Ensuite, c'est pour ca que j'insisite sur les delais aquisitions/traitement, finalement mon horloge de référence n'est pas "lineaire" comme le temps universel.Elle est incrémenter de 32ms en 20µs toutes les 32 ms...
Autre problème, la durée d'implémentation de ces 32 "tops" est minime comparé au temps de traitement d'une trame.

Si tu voulais une valeur "exacte", il te faudrait horodater la réception des 32 valeurs, et renvoyer une valeur extrapolée en fonction du timestamp de réception du "GET_CURRENT_SAMPLE" (formule : (timestamp de la demande - timestamp de la dernière trame) + dernier compteur)...

Oui mais comme dis plus haut il faut une référence temporelle précise à la milliseconde avec une granularité à la milliseconde eet surtout stable. Et ca sur Windows, c'est pas évident à coder, d'ou l'idée d'utiliser la carte d'acquisition comme horloge

En fait j'essaye plus désormais d'envisager le problème comme :
"Quel est le décalage du nombre d'échantillon traités entre mes cartes d'acquisition de mes 2 clients"

Molox

[Mac LAK]

C'est la ou je ne suis pas d'accord avec toi, ou il me manque un clef pour comprendre, je m'explique :
Quand tu dis en retard, c'est par rapport au temps UTC, enfin à la granularité de temps dont on dispose sur le PC.

Disons plutôt que je pars du postulat que ta carte d'acquisition et ton PC sont temporellement synchronisés, que ce soit par une horloge externe (ex : GPS, NTP) ou via le PC (qui sert alors de référence temporelle, la carte n'ayant qu'un "compteur milliseconde").

A partir de ce moment, étant donné que ta carte n'envoie les échantillons que toutes les 32 ms, tu as un retard constant qui est dû au temps de propagation de la trame sur le réseau, au temps d'émission-réception de cette trame, et intrinsèquement un retard relatif induit par le fait même d'envoyer les données par paquets (une seule donnée est "fraîche" dans ce paquet, justement, la plus ancienne a 32 ms d'âge).

Ce qui fait qu'au total, dans le pire des cas, tu as un décalage de l'ordre de 35 ms entre le moment où le signal a été acquis par la carte et le moment où le PC de supervision le "voit"... Ce qui fait que si tu n'utilises pas exclusivement l'horodatage de la carte, tes mesures temporelles sont forcément "fausses", ou pour être plus précis, décalées.

* Déja sur Windows dur dur de compter le temps UTC à la milliseconde, a part le performance counter, mais sur les P4 il subit les variations de l'economie d'energie du processeur donc niveau stabilité....

Cela se désactive, c'est pas un problème en soi. Et même s'il "bouge" parce que tu ne peux pas modifier la politique d'économie d'énergie (cela arrive sur certains portables), il suffit d'appeler "QueryPerformanceFrequency" régulièrement avant "QueryPerformanceCounter" afin d'avoir la fréquence de base, et surtout, surtout, verrouiller le thread appelant cette fonction sur un cœur donné via SetThreadAffinityMask.

* Ensuite, c'est pour ca que j'insisite sur les delais aquisitions/traitement, finalement mon horloge de référence n'est pas "lineaire" comme le temps universel.Elle est incrémenter de 32ms en 20µs toutes les 32 ms...

Ce qui ne règle pas le "problème" de ton thread gérant la réponse à "GET_CURRENT_SAMPLE"... Car vu que tu es "en retard", tu n'as que trois solutions :
- Donner la dernière valeur connue garantie, donc une granularité de 32 ms (cas le plus simple).
- Extrapoler, en fonction du timestamp d'arrivée de la dernière trame et du timestamp courant du PC, de façon à donner une estimation sur un échantillon qui n'est pas encore arrivé et n'arrivera peut-être pas, ce qui peut être risqué. Cela demande à synchroniser les deux horloges, ce qui n'est pas bien dur (il n'y a qu'à recaler le PC à chaque réception de trame).
- "Ralentir" le PC de façon à obtenir un décalage constant et connu, et donner alors la valeur courante d'échantillon, sachant qu'il sera en retard de N ms par rapport à la réalité (sûrement 32 ms, d'ailleurs, dans ton cas). Tu peux implémenter ça via un buffer circulaire horodaté, par exemple.

Autre problème, la durée d'implémentation de ces 32 "tops" est minime comparé au temps de traitement d'une trame.

Ce n'est pas vraiment un problème, ça, ou alors j'ai mal cerné le souci...

Oui mais comme dis plus haut il faut une référence temporelle précise à la milliseconde avec une granularité à la milliseconde eet surtout stable. Et ca sur Windows, c'est pas évident à coder, d'ou l'idée d'utiliser la carte d'acquisition comme horloge

Oh, non, c'est très simple au contraire, surtout sur une base aussi courte que 32 ms...
Si ta carte t'envoie un horodatage "hard" à chaque trame, il te suffit de fabriquer une horloge logicielle :
- A chaque trame reçue, le timestamp "carte" de référence est stocké dans l'horloge logicielle, ainsi que le timestamp du PC (QPC de préférence, au pire GetTickCount). Tout doit être converti en millisecondes bien sûr, mais je préfère pour ma part travailler à la MICROseconde sur le sujet.
- Éventuellement, tu peux rajouter un offset pour tenir compte des temps de propagation des trames réseau.
- Lors de la demande d'un timestamp, on prends le timestamp PC courant, on retranche le timestamp PC de référence, et on ajoute enfin le timestamp de référence carte. Si l'on travaille en microsecondes, il suffit d'arrondir à la milliseconde la plus proche.

Tu auras alors une dérive temporelle à peu près égale à celle de ta carte, et qui sera très stable vu qu'elle sera "remise à l'heure" toutes les 32 ms.

En fait j'essaye plus désormais d'envisager le problème comme :
"Quel est le décalage du nombre d'échantillon traités entre mes cartes d'acquisition de mes 2 clients"

Là, par contre, je ne vois pas : il faudrait que tu expliques mieux le problème, car pour moi, les deux cartes sont indépendantes et ne sont (à priori) pas synchronisées pour un sou... Et n'acquièrent pas non plus les mêmes données !

Si par contre c'est un système d'acquisition redondant, on passe dans un tout autre registre, et il faudra expliquer ton souci plus en détail.