Re: [Tsp-devel] RE : TSP Facile

[Eric Noulard]

Le 11/03/08, Yves DUF<address@hidden> a écrit :
> Hello.
> I (try to :=) switch to english language.
>
> Le 07/03/08, CAZENAVE, Claude
> <address@hidden> a écrit :
> > Bonjour à tous,
> >
> > J'ai 2 questions suite à l'exemple du glue_stub :

Sorry for the delayed answer, I realize I forgot to write down my planned
answer when Yves answered ...

> >
> > 1) ma compréhension est que un seul TSP_provider_run est possible et donc
> un seul TSP_provider_init et donc un seul GLU_handle et donc une seule base
> frequency. J'ai donc dans mon process un seul et unique provider. Je sais le
> gerer comme cela mais j'aurais voulu etre sur qu'il n'y a pas de possiblite
> de multi provider (chacun avec sa liste et sa frequence) par process.
>
> Is it possible to get more  than one provider in one process,

The question is it possible to do several calls to :

int32_t
TSP_provider_init(GLU_handle_t* theGLU, int* argc, char** argv[])

in a SINGLE process.
My answer is NO, it is not possible with the current code.
In fact it is possible to have several GLU instance for a
single provider but  the code is not  really easy to understand in
this area :-).
If someone is interested by this I will be pleased to start another discussion
thread on this subject.

>  in order to allow many frequency.

having more than one process is not the only mean to get multi-frequency
as told by yves:

> As far as I know, TSP provider use handles that could allow more than one
> providers.

it should work but the current API does not support this scheme.

>  But I don't think it as ever been tested, so I do not advise you
> to do it. I would rather create one provider running at a multiple frequency
> of all your simulation frequency.

I would do that too.
You must be aware that the notion of "base frequency" is 'only effectively used'
to size buffers. In fact the provider may tell that it's base frequency is 100Hz
and produce sample at 1000Hz or 1Hz, the TSP lib will do its jobs.

Timing is not the job of TSP (it is a provider specific issue)
TSP is for sampling.
So a consumer may ask for getting p out of
n produced [symbol] values.
p is the (ill-named) "period" field of the request sample.

you may find more detailed explanation in the draft
"TSP group explained" document:

http://cvs.savannah.nongnu.org/viewvc/*checkout*/tsp_docs/tsp_progguide/tsp_group_explained.pdf?root=tsp

Now when you code your GLU [the specific part of the provider]
you may decide that symbol "SlowPaced" may not be requested
at TSP period 1 but only at most 10.
(10 times slower than the base cycle).

If you ask for [filtered] information about a symbol the provider
should indicate this "max period" in the answer sample.

> > 2) une fonction est passée en argument du GLU_handle_create pour etre
> utilisé dans un thread crée dans le TSP_provider_run. C'est cette fonction
> qui va envoyer les samples en fonction de ce qui est demandé. Dans ton
> exemple, la fonction attend avec un sleep pour simuler le temps. Est il
> possible que cela soit un thread que j'ai déja et qui est en charge de faire
> les acquisitions cycliques qui fassent ce traitement
> (TSP_datapool_get_reverse_list et boucle sur les symboles demandés avec
> appel à TSP_datapool_push_next_item). Cela me semble correspondre au cas GLU
> passive et a l'appel de async_write sur la GLU mais je suis pas sur car j'ai
> pas réussi à trouver d'exemple.
>
> Yes I think it possible to use  your own thread to simulate time.  But I
> don't find simple sample provider to give. Does anybody get one ?

In fact Nicolas Tchintcharadzé  already did something similar
for his TSP usage for BASILE:
http://download.savannah.nongnu.org/releases/tsp/events/First_TSP_Workshop_27march2007/BASILES_HLA_TSP.pdf.

Nicolas is not a tsp-devel subscriber I will contact him directly
in order to ask for real source code example.

I may explain the principle behind this usage.

In fact it is not necessary to have a thread at all this is only the
"default" TSP core  behavior.

The GLU "run" callback is wrapped by a default "start" callback:
(see tsp_default_glu.c::GLU_start_default) which essentially
does: pthread_create(&(this->tid), NULL, this->run, this);

If you use this scheme one should implement a 'run' callback
which may be called as shown.
This is what the Stub Server example does
see glue_stub.c::GLU_stub_create

stub_GLU->run                    = &STUB_GLU_thread;

If you don't want this TSP thread you may define you own start function
and redefine the start callback when you create your GLU object:
(if you redefine start, run won't be called).

my_GLU->start                    = &myOwnStart

you may even want to implement a no-op start like this:

int32_t
myOwnStart(GLU_handle_t* cthis) {
   return 0;
}

Since your start function does nothing,
you'll have to implement a user function which calls

TSP_datapool_push_next_item
TSP_datapool_push_commit

when needed.

your user function call is scheduled by "another mean" than
the TSP "GLU thread" in the Nicolas case it was the scheduler of his
own simulator.

As I said before.
TSP is not _really_ concerned by the time handling.
The TSP core knows that 'the next' cycle has come
because 'TSP_datapool_push_commit' is called.

This means that the "real time" of your provider directly
comes from the 'TSP_datapool_push_commit' call pace.

If your application is calling 'TSP_datapool_push_commit'
at 100Hz then you will have a 100hz provider.

The real pace is unrelated with the "base_frequency"
advertised by the provider.

In turn from the TSP viewpoint a consumer knows nothing
about time. A consumer knows about sample data,
sample data are not TIME-stamped they a "CYCLE-stamped"
that is sample data belongs to cycle 0,1,2 etc...
That's why consumer is asking for "subcycle" in a TSP request sample
and not for "frequency".

You may even implement a provider for which cycle
time vary (cycle 0 is 10ms, cycle 1 is 40ms, cycle 3 is 5ms)
consumer won't notice it unless there is some TSP symbol
which includes "real" wallclock time value.

I hope this help.
Do not hesitate to ask clarification, I'll try to answer faster.

-- 
Erk