RE : [Tsp-devel] Questions sur TSP_consumer

[eric.noulard]

>-------- Message d'origine--------
>De: 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