Re: [Tsp-devel] Question utilisateur

[Eric NOULARD]

Le dimanche 13 mars 2005 à 17:06 -0500, Nicolas a écrit :
> 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. 

En fait oui et non.
Data is consistent est mal choisi :))
Je m'explique après.

> 
> 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.

Je te dis ce que j'essaierai dans ton cas, 
même si c'est pas très "naturel"...

Le temps est une variable 't' du blackboard.

[A noter que tu n'as jamais besoin de faire 'blackboard write'
 le blackboard te donne un pointeur et toi tu l'utilises
 donc même sans utilisation de TSP le blackboard à son intérêt
 via les BBTools car tu peux lire/écrire les variables
 BlackBoard depuis un autre process]

"genome" est une variable du blackboard
"naissance" est une variable du BB
"mort" est une variable du BB
"population" est une variable du BB.

Désormais, A TOUT MOMENT (i.e. de façon acyclique) tu fais

*t          = TimeKeeper.getTime();
*genome     = genome_value();
*naissance  = 1;
*mort       = 0;
*population = *population+1;

bb_simple_synchro_go(mybb,BB_SIMPLE_MSGID_SYNCHRO_COPY);

Et hop ton message part à destination de tout ceux qui en veulent.

Tu peux évidemment faire une boucle ou quoique ce soit d'autre
à chaque "événement" (genre 'n' naissances puis 'n' morts 
à la même date etc...)

Ton provider aura une fréquence ultra variable, qui dépendra
des évènements et pas d'une cyclicité temporelle quelconque.
Tu dois transporter le temps simulé 't' pour que tu puisses
en faire qqchose à l'autre bout.

Un dernier truc si jamais tu essaies.
Le Blackboard est multi-type (int, double, etc...) TSP
aujourd'hui ne transporte que des doubles.

A noter que dans ton cas [et là je risque de dire des âneries
vu ma méconnaissance de ton domaine de travail]

tu peux aussi publier d'autres stats dans le BB:
"nb_naissance_depuis_le_debut"
"nb_mort_depuis_le_debut"
etc...

Maintenant je reconnais que c'est un peut torturer BB+TSP pour
faire de l'évènementiel. Je pense que ce qui t'irait le mieux
serait un truc genre 'syslog', vu que tu peux balancer
des messsages "formatés" à tout instant et c'est ton
syslogd préféré qui les rangeras dans des fichiers locaux
ou bien les enverras à un serveur de log via UDP.

Syslog en temps accéléré ça dégomme la machine sérieux
car c'est un appel système donc si tu en fait beaucoup
(genre 30 par seconde) la machine va s'écrouler.

Tu peux tenter syslog-ng qui a de bien meilleur perfo.
http://www.balabit.com/products/syslog_ng/


A noter que le projet sur lequel je travaille actuellement
on utilise les 2 
   BB + TSP
   Mini-wrapper au-dessus de syslog-[ng]

Quand veux pas faire mal à la machine et/ou ne pas perturber
une simu RT on fait du BB+TSP (même dans les cas 'pseudo-évènementiel)
sinon syslog.

Si tu codes un beau petit truc à la main pour
de l'évènementiel et que d'aventure tu cherchais à 
l'OpenSourcer/héberger ce code quelque part 

Ben en ce qui me concerne tu es le bienvenu
dans les 'utils' de TSP ou dans un autre module
de haut niveau :)))

Evidemment ça se vote donc, ma voix compte pour 1.

Sinon globalement mon opinion sur tes besoins c'est
que l'observabilité va te mettre un gros coup de frein
à ta perf, à moins de bufferiser comme un fou ou 
d'avoir 2 processeurs et un disque/carte réseau méga rapide.


> 
> 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
> 
> -------------------------------------------------------
> _______________________________________________
> Tsp-devel mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/tsp-devel