Re: [Tsp-devel] Question utilisateur

[Nicolas]

Merci pour les réponses détaillées!

Comme demandé, je fais suivre sur la liste. En effet, ta solution permet de 
contourner les groupes acycliques dans ton cas, et ça peut servir à d'autres!

Malheureusement, dans mon cas je ne peux pas juste accumuler des variables et 
ensuite envoyer un signal "data is consistent" au blackboard (cf schema dia, 
pour d'éventuels lecteurs en cours de route): Chacune de mes données est 
indépendante... et du coup, le blackboard n'a pas de valeur ajoutée. 

Je devrais en effet faire des "blackboard write" suivi de "data consistent" à 
chaque envoi. Ex: "naissance à date t avec génôme X, population is Y". Data 
is consistent. Et on retombe sur le problème des groupes acycliques car le t 
dans cet exemple n'est pas du tout cyclique.

Enfin, dis-moi si je me trompe! 

Voici une autre réponse reçue en privé, mais que je me permet de diffuser afin 
d'éviter les mails croisés...

> Pour faire rapide, la spec originale de TSP prévoyait 2 styles de flux :
> - Synchrone (avec fréquence)
> - Asynchrone (Quand tu veux, sur changement)
>
> Manifestement ton cas a l'air de nécessiter les groupes asynchrones.
> Mais ils n'ont malheureusement pas encore été entièrement codés (ou
> alors robert travaille sans m'en parler) même si ils étaient + ou -
> prévus dans les API.
>
> A voir selon ton besoin et notre réactivité si :
> - On peut te les coder vite fait
> - Tu as envie de le faire toi-même

Vous embêtez pas avec ça pour l'instant, vu les discussions sur le refactoring 
actuel, il me semble qu'il y a déjà pas mal de boulot. Même si précisément, 
on pourrait arguer que c'est là une occasion à saisir... je ne veux pas vous 
prendre du temps pour ça. Disons que tu peux le mettre sur la wish-list :)

Je suis un peu pris par le temps ce trimestre-ci, donc je vais malheureusement 
devoir me contenter d'une solution "maison" rapide et spécifique à mon 
problème. Pour le moyen/long terme, par contre, on verra bien!

Merci pour tout, et pour les réponses rapides :)

Happy hacking!
Nicolas


----------  Message transmis  ----------

Je mets ma réponse en copie simple si tu es OK remets
là sur la liste je pense que nos discussions peuvent
être utile à d'autres.

> > a) Ton code c'est du C/C++? Ou qqchose du genre?
> >    Because y'a pas [encore] de lib TSP côté provider en Java :(((
>
> C++

Va bene sauf que comme tu t'en apercevra certainement
tous les en-têtes TSP ne sont pas C++ proof :((

J'ai commencé mais j'ai pas fini donc quand ça couine
quelques part c'est à cause des 'extern C' manquant.

Au cas où tu te sens d'attaque pour rajouter et nous envoyer
un patch y'a déjà les macros:
BEGIN_C_DECLS
END_C_DECLS
définies dans src/core/include/tsp_abs_types.h
avec un exemple d'utilisation dans:
src/util/libbb/bb_core.h

> > b) Quelle ta cible de machine (Linux, Solaris, DEC..)
>
> Linux. J'ai fait un port win32 à des fins de démo, mais si l'acquisition
> des paramètres est désactivée sous win32 c'est pas bien grave.

Yes malheureusement on a pas de port Win32 par manque de pthread correct
à l'époque du dernier essai. (et également de manque notoire de temps
pour le faire).

> > c) Combien de variables ton simu génère-t-il?
> >    100, 1000, 30000 .?
>
> En interne? Heu... un bon paquet...

Dans la version actuelle de TSP ce qui coûte cher c'est
pas tellement ce que tu veux POUVOIR exporter mais ce que
tu OBSERVES réellement.

J'ai l'exemple d'un simu utilisant TSP
(Blackboard TSP + bb_tsp_provider) qui rend "distribuable"
1 800 000 (1,8 millions) de variables et qui tourne sans
broncher car on n'en observe rarement plus de 200.
Cette appli est majoritairement cyclique avec un
cycle temps réel de 16ms.
C'est-à-dire qu'en 16ms on peut recopier 1 800 000 variables
(c'est un bête memcpy de 1,8e6*8 octets = 64000000 ~ 64Mo)
plus distribution de 200 variables parmi le tout.
En fait, je ne sais pas exactement combien de temps prends
la partie TSP car elle est faite 'pendant le temps' qui reste
des 16ms, en tout cas on a jamais explosé le cycle à cause
de TSP.

Par contre le bb_provider bouffe 250Mo de mémoire
principalement à cause du stockage du nom des symboles
(chaine de caractère).

J'ai fait tourné cette appli sur un
PIV 3GHz hyper-threadé sans problème.

> > d) Combien veux-tu en observer?
>
> Ca dépends de scénario. <100 a priori.

Alors je pense que l'archi. que j'utilise dans mon cas pourrait t'aller.
L'idée est la suivante.
Le simulateur crée un "Blackboard TSP" qui est une zone de
mémoire partagée dans laquelle le simulateur pourra 'publier' des
données.
[je te joins un schéma DIA qui illustre le concept]

Un publish est comme un malloc avec un peu plus d'argument:

display_level = (uint32_t*)
bb_simple_publish(mybb,"display_level",basename(argv[0]),-1,
                  E_BB_UINT32, sizeof(uint32_t),1);

*display_level = 0;

[tu peux trouver un exemple de faux simu utilisant un BB
 dans tsp/src/util/libbb/bbtools/bb_simu.c
 tu peux aussi compiler et lire le README du même répertoire]

Ensuite quand la simulation estime qu'un "jeu de variable doit être
observée" alors elle envoie une synchro vers une message queue
contenue dans le BB:

bb_simple_synchro_go(mybb,BB_SIMPLE_MSGID_SYNCHRO_COPY);

SI tu as lancé par ailleurs (APRES LA CREATION DU BLACKBOARD)
le 'bb_tsp_provider' (src/provider/bb_provider)
[le mieux est d'exécuter ce qu'il y a d'écrit dans le README pour
comprendre]
ce dernier déclenchera la recopie DE LA ZONE DE DONNEE du blackboard
à la réception du message de synchro.
En vue de le distribuer à d'éventuel consommateurs TSP.

> > e) Ta simu va à combien de fois le temps réel
> >    donc en gros quelle est la vitesse de ton 'pseudo-cycle'
> >    [si il y a la notion de cycle bien sur]
>
> C'est là le problème, et ma question sur l'émission de paramètres
> acycliques. J'ai bien des activations cycliques d'éléments, mais les
> variables "intéressantes" sont acycliques (ex: je poste une update de l'IA
> de façon cyclique, mais une naissance peut arriver n'importe quand).

Bon c'est là que tu as/n'as pas de chance.
Dans le TSP actuel la distribution est 'synchrone', la spec prévoit
ce qu'on appelle un 'groupe asynchrone' mais ce n'est pas implémenté.

Toutefois il faut se méfier de l'apparence cyclique de TSP.
Dans mon exemple précédent si, le simulateur décide d'envoyer 4 synchro
par cycle ou même une synchro de plus sur un évènement particulier ben
tu auras du pseudo-cyclique ou pseudo-acyclique comme tu veux.
Ce qui signifie en pratique que si tu as besoin d'une référence de temps
CE DOIT etre un symbole TSP que tu distribue avec les autres.
Il ne FAUT pas croire le provider qui te dit "je suis à 64Hz" c'est
peut-être un 'pseudo-64Hz' accéleré.

C'est d'ailleurs très pratique pour passer d'un simu RT à un simu
temps accéléré, les consommateurs TSP n'y voient que du feu, dans
la limite du débit réseau/disque que ça engendre.

Par contre à TOUS les cycles les consommateurs recevront tous
les échantillons qu'ils ont demandés.

> En mode batch, donc pour les expériences, as fast as possible, ratio
> variable. Par exemple, ça peut faire du 13x en moyenne avec des pointes à
> 15x quand y'a moins de calcul. Sur ma machine, bien sûr... ça change en
> fonction du hardware. En mode graphique, du 1x a priori, mais parfois on
> peut mettre la simu en pause...

Ben j'ai mal posé ma question, 15x c'est pas bien grave c'est surtout
quelle est la durée d'un cycle? Si on dit que ton cycle 'temps réel' est
de 16ms et que tu va à 16x RT donc tu as 1ms pour:

1) faire tes calculs
2) memcpy
3) distribution TSP de tes 200 symboles.

Et là ca va dépendre très fortement de ce que fais ton/tes consumer TSP,
genre j'ai un exemple de simu temps accéléré où j'ai dû mettre des
tempos car le simu 64Hz initial tombait à un temps de cycle inférieur
à 200 micro en temps accéléré, ce qui est génial (ou qui prouve que
le simu fait pas grand chose) mais mon petit consumer TSP qui crachait
ses 500 symboles par cycle sur le disque avait un peu de mal à suivre...

Dans ce cas là j'ai du faire un 'hand-shake' aller/retour entre la simu
et le thread provider pour pas que ça fasse n'importe quoi:

C'est le code commenté du bb_simu.c

/*  printf("Synchro Wait..."); */
/*  fflush(stdout); */
/*  bbntb_synchro_wait(BBNTB_MSGID_SYNCHRO_COPY_ACK); */
/*  printf("OK.\n"); */
/*  fflush(stdout); */

Mais pour que ça marche il faut modifier le code du bb_provider.

Fais un petit essai sans ce mécanisme pour voir si le principe te va
et je t'explique dans le détail comment faire le hand-shake si tu as
besoin.

A+
Eric

-------------------------------------------------------

BlackBoard.dia
Description: application/dia-diagram

BBtools.dia
Description: application/dia-diagram

pgpxJawBfLfQ9.pgp
Description: PGP signature