Re: RE : RE : [Tsp-devel] Ordre d'arrivée des samples d'un groupe

[Eric Noulard]

Je réponds/précise mon avis sur quelques trucs par rapport à ce qu'a dit Robert:
(voir ci après dans le texte)

Le 23/12/06, PAGNOT, Robert <address@hidden> a écrit :
> Exemple : Fprovider = 100Hz,
>         V1 demandée à 100 Hz (10 ms)
>         V2 demandée à 50 Hz (20 ms)
>         V3 demandée à 33,33 Hz (30 ms)

Je précise qu'avec le TSP actuel on ne demande pas
une variable à une fréquence donnée mais on demande
un sous-multiple de la fréquence de base du provider.

Dans l'implémentaion TSP actuelle on a appelé ça "period"
ce qui est trompeur car la valeur ne correspond pas
à la période mais à un MULTIPLICATEUR de la période
(la vraie cette fois-ci) la plus rapide du provider.

V1 demandée avec period=1 soit 100Hz (soit 10ms)
V2 demandée avec period=2 soit 50Hz  (soit 20ms = 2 * 10ms)
V2 demandée avec period=3 soit 100Hz/3 (soit 30 ms = 3 * 10ms)

Demander à sampler avec ces paramètres permet d'éviter
simplement que le consumer demande une fréquence (en Hz)
impossible (ou trop difficile) à générer pour le provider.
En plus les calculs sur les multiplicateurs de periode sont
fait en nombre entier et donc sans pb d'arrondis possible
contrairement à des calculs (potentiellement) flottants en Hz.

Par exemple si ma fréquence de base est 64Hz
générer du 10Hz est réellement pénible. TSP ne permet pas
de faire ça c'est "trop compliqué" pour lui.

> PPMC = 60 ms.
> Les paquets s'organisent en :
>     Cycle 0 : V1,V2,V3
>     Cycle 1 : V1
>     Cycle 2 : V1,V2
>     Cycle 3 : V1,V3
>     Cycle 4 : V1,V2
>     Cycle 5 : V1
>
>     Cycle 6 : V1,V2,V3 ... idem Cycle 0, et ça recommence !

Et ici la lib TSP provider aurait
(probablement car j'ai pas testé) généré  4 "groupes TSP".

Groupe 0 contenant V1,V2,V3
Groupe 1 contenant V1,
Groupe 2 contenant V1,V2
Groupe 3 contenant V1,V3

> Je soutient pleinement Eric

Ben ça ca fait plaisir :))

> Je me souviens de discussions acharnées sur l'organisation des
> variables vues côté consumer. Nous avions deux options :
>
> FIFOs par variable
> FIFO unique de lignes par cycle TSP, genre  datapool daté (proche du format 
> RES, donc)
> Il me semble que seul le premier a été retenu (TSP_consumer_read_sample),

Oui et Non car au milieu se trouve la vertue, je vais préciser ci-après.
Néanmoins je crois pouvoir dire que le Caribou a été assez malin
dans l'implem' actuelle.

> car le deuxième posait des problèmes avec des variables à fréquence très 
> différentes

Oui c'est exacte plus les différences de fréquences ou plus exactement
de fréquences
générées par des multiplicateurs de périodes très éloignés plus la capacité
de bufferisation "devrait" être importante.

> et le
> groupe asynchrone (pas le read_async, mais le groupe contenant des couples
> PGI,XDR_VALUE, triggé par la modif de valeur d'un sample).

Ajourd'hui le groupe asynchrone n'est pas implémenté mais
il n'y a pas de raison qu'il nous pose pb vu l'implem' actuelle
(tant qu'on borne le nombre de variable asynchrone à une valeur
"raisonnable")

Et donc je viens dans le vif du sujet.
Aujourd'hui on envoi/reçoit des "groupes" TSP complets. donc
dans l'exemple de Robert on reçoit 4 groupes.
Dans un cas mono-fréquence/period on reçoit 1 seul groupe
qui contient toute les variables samplées (ce qui est le cas pire).

Donc la capacité de bufferisation nécessaire à TSP est
la taille max d'un groupe
(multipliée par la durée tolérée pour éponger les jitters de réception).
Je trouve ce choix un TRES bon choix, et je le dis librement d'autant
que je ne me souviens pas avoir participé à ce choix.

NEANMOINS celà ne se VOIT PAS dans l'API TSP consumer
car on ne dispose "QUE" de TSP_consumer_read_sample
et ce alors qu'en dessous on reçoit groupe par groupe :))

Le Caribou avait fait le choix de "cacher" un certain nombre
de choses "potentiellement" trop compliquées pour l'utilisateur de l'API.
Je pense que c'ETAIT une bonne idée (et d'ailleurs on a mis 4 ans à
ce que ça nous pose un pb...) même si j'aurais préféré une API à 2 niveaux.

C'est une discussion que nous avons eu sur la version Java
http://lists.gnu.org/archive/html/tsp-devel/2005-04/msg00001.html
http://lists.gnu.org/archive/html/tsp-devel/2005-04/msg00003.html
pour lequel il existe 2 APIs:

tsp.core.consumer           = niveau "warrior" du TSP
tsp.core.consumer.simple = biveau "keep it simple" (but still efficient)

l'API "basse" est proche des specs et l'API simple est proche ....
de l'utilisateur :)))

C'est moins criant en Java car l'orientation-objet allège déjà
pas mal l'API warrior mais quand même l'idée est là.

Dans la version C on a une seule API qui est un intermédiaire entre ces 2 là.

> Si j'ai bien compris Virginie, cette deuxième option collerait à son besoin.

Je pense qu'une API fournissant des "groupes" complets suffirait.

> Eric & Yves, faites appel à vos mémoires, corrigez-moi si je me trompe et 
> peut-être
> est-il temps de discuter de la deuxième option, genre
> TSP_consumer_read_line(provider, line, newline). La "ligne" serait
décrite comme les
> fichiers RES (compteur de cycle + la valeur courante des variables en
brut). On devrait
> restreindre ce type d'API à l'utilisation mono-fréquence par provider ?

Je pense qu'on peut (?doit?) conserver les échanges "par groupe" au niveau
de la socket car bufferiser  "1" groupe me parait 'raisonnable' même
10000 variables
de 8 octets ça va pas chercher bien loin en terme de place.

En revanche il faudrait rajouter 1 ou 2 APIs

TSP_consumer_read_group(provider, ....)
qui lit un groupe entier et qui dans le cas du mono-fréquence correspond
à ce que tu dis.

TSP_consumer_read_supercycle(provider,...)
qui lirait "un super-cycle" qui correspond à la période PPCM
générée par la demande.

Dans les 2 cas il serait souhaitable que le buffer
(dont on sait calculer la taille dès le request sample)
soit fourni par l'utilisateur via l'API utlisateur pour éviter les
recopies inutiles.

Bon je retourne écrire ma bafouille sur les groupes au propre :))
--
Erk