Re: RE : [Tsp-devel] Questions sur TSP_consumer

[Stef Euskadi]

B'Soir,

Bienvenu à Virginie...

Je rebondis sur l'idée d'utiliser les extended-infos pour transporter des calibrations...
Je trouve l'idée géniale.
Je vais y réfléchir pour TARGA.
Première question qui me viens à l'esprit : comment trouver les calibrations parmis
l'ensemble des infos ?

A+

Euskadi.

Le 27/11/06, address@hidden < address@hidden> a écrit :

>-------- Message d'origine--------
>De: tsp-devel-bounces+eric.noulard= address@hidden de la part de ALAUX, Virginie
>Date: lun. 27/11/2006 10:41
>À: 'address@hidden'
>Cc: GERARD, Gaetan
>Objet : [Tsp-devel] Questions sur TSP_consumer
>
>
>Bonjour,
>
>Devant effectuer une étude pour réaliser un consumer performant à base de TSP.

C'est une bonne nouvelle pour TSP :))

>J'ai 2 questions:
>Dans le fichier tsp_consumer.h v 1.34, pour le type TSP_sample_t : il n'y a pas le type "string". Est-ce une vieille version du fichier?

Si tu veux vérifier si tu possède l'ultime version d'un fichier il suffit d'aller
consulter le fichier actuellement en conf sur Savannah, dans le cas de ce fichier:
http://cvs.savannah.nongnu.org/viewcvs/tsp/src/core/driver/tsp_consumer.h?rev=1.35&root=tsp&view=log

en l'occurence la révision 1.34 correspond à TSP 0.8.0 ce qui est l'avant dernière version
mais les changements ultérieurs (TSP 0.8.1 et bientôt 0.8.2  n'ont pas rajouté de type).

Il n'y pas de sample de type 'string' car TSP ne "sample pas" des données de taille
variable précisemment pour des raisons de performance.

Si tu veux sampler une string le provider devra définir un tableau char/uchar de taille fixe maximum
(contenant éventuellement des \0).

Concernant les tableaux tu recevras "un sample" par index du tableau.
En résumé, ce n'est pas une bonne idée de sampler des strings, mais c'est néanmoins possible.

>La requête lisant les samples : TSP_consumer_read_sample ne retourne qu'un sample à la fois?

Oui c'est le cas. Celà évite les allocations dynamiques ce qui est bon pour la perfo :))

TSP_sample_t.type permet de savoir quel est le type du sample reçu
TSP_sample_t.array_index l'index du tableau (de 0 à dim-1) si s'en est un et 0 pour les scalaires
TSP_sample_t.provider_global_index qui est l'identifiant unique d'un symbole côté provider.
TSP_sample_t.uvalue l'union contenant la valeur.

>Si c'est la cas, comment va t-on faire pour avoir tous les samples d'une fréquence donnée
> ( question du sleep à faire après chaque read ). Est-ce performant pour des hauts débits d'acquisition (500 valeurs à 32 Hz) ?

Nous n'avons pour l'instant pas eu de pb de performance lié à ces appels
et nous avons mis en oeuvre des consumers qui avalaient sans pb leurs 500 symboles à 64Hz.
Ce qui nous a limité c'est bien souvent ce qu'on en fait une fois qu'on les a reçu:
écrire sur disque, afficher, envoi réesau  etc...
500 valeurs double flottante (8 octets) à 32Hz avec TSP ça fait
32*500*8*8 soit environ 1 Mégabit/s de débit REEL TCP, ce qui n'est pas ridicule à traiter.

A noter également que le TSP_consumer_read_sample ne fait que lire dans un ringbuffer
les valeurs qui ont été déposées par un thread TSP de réception.
Cet appel ne peut pas bloquer, il ne prends pas de mutex, n'alloue pas de mémoire etc...
Bref il ne coûte pas cher (et pourrait être inliné)
Toufefois si tu avais des pbs de perfos n'hésites pas à nous en faire part et
on pourrait examiner la question pour faire mieux.

Le sleep que tu peux faire doit nécessairement être (bien inférieur) à la durée correspondante à la fréquence
max de ta demande de sample. Si tu as demandé au moins 1 symbole à 32Hz alors il ne faut pas faire
sleep (enfin plutôt usleep ou nanosleep voire tsp_usleep) supérieur à 31.25 ms.
L'algo de base pour un consumer devrait être de faire une boucle non-interrompue sur TSP_consumer_read_sample
jusqu'à ce qu'un appel indique (via le 3ième argument new_sample) qu'il n'y a pas de sample à lire,
alors faire PETIT sleep pour éviter une boucle active.

Concernant "comment va t-on faire pour avoir tous les samples d'une fréquence donnée"

TSP_sample_t.time est le timestamp TSP associé au sample.

Le timestamp TSP est incrémenté à chaque fois que le provider a terminé 1 cycle.
Tous les samples qui sont échantillonnés à la même fréquence auront donc le même
timestamp.

Si tu sample toutes les variables à 32Hz.
Lorsque time change alors tu reçois un nouveau lot d'échantillon.

Si tu sample 2 variables à 32Hz et 2 à 1Hz ben ... c'est pareil :))
Sauf que dans certain cas tu vas lire 4 symboles avant que le timestamp ne change de valeur
et dans d'autre cas tu lira seulement 2 symboles cas dans ce cas "bi-fréquence"
tu auras 2 groupes TSP. 1 avec 2 variables (les 2 var à 32Hz) et 1 avec 4 (les 2 à 32Hz + 2 à 1Hz).

>De plus, le provider nous fournit une variable "time" pour dater les valeurs reçues.
>Si on ne reçoit qu'un sample à la fois, comment va t-on gérer cette variable?

Je suppose que tu parle d'un symbole 'time ' à toi et pas celui de la structure TSP_sample_t.

Quand tu lis la valeur de la variable 'time' de ton provider avec TSP_consumer_read_sample
cette dernière est un symbole TSP comme un autre.
Donc elle possède aussi son timestamp (TSP_sample_t.time).
Toutes les symboles que tu auras reçu qui possède le même timestamp que ton symbole
'time' devraient donc avoir été échantilloné par le provider à cette date
(enfin c'est la responsabilité du provider de faire ça correctement).

Il faut garder à l'esprit que TSP ne s'occupe quasiment pas de la notion de 'temps'.
TSP gère des séquences de valeurs correspondant à des "cycles" indiqués par le provider.

En particulier, il n'est pas très bon de postuler au niveau d'un consumer qu'un
provider qui annonce fonctionner "à 32Hz" le fait vraiment.

Je peux écrire un provider TSP qui "annonce" fonctionner à 32Hz alors qu'il
fonctionne à 40Hz. Il existe même des providers TSP dont la fréquence n'est pas
constante, par exemple des lecteurs de fichiers.

Un consumer TSP ne doit donc pas "TROP" faire de supposition sur la fréquence réelle
du provider.

Un bon exemple de ça est que dans une request_sample, on ne spécifie pas la férquence
à laquelle on veut sampler mais la "périodicité" par rapport à la fréquence de base.
period = 1 ---> tous les samples produits par le provider
period = 2 ---> 1 sur 2 etc...

Du coup pour un même consumer, si le provider change de fréquence, le consumer
n'y voit que du feu, enfin... dans la limite de ses performances.


Bon développement TSP!!

A+
Erk


_______________________________________________
Tsp-devel mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/tsp-devel

-- 
--
Euskadi.