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

[Eric Noulard]

Fred,

Je me permets de répondre car je ne sais pas si tu poses
la question à Virginie ou à moi-même.

2006/12/20, Frederik Deweerdt <address@hidden>:
> Bonjour,
>
> Juste pour être sûr d'avoir bien compris, est-ce que tu contrôles
> l'ordre dans lequel les symboles sont enregistrés par le provider?

A mon tour je ne suis pas sûr de comprendre.

Côté provider:
Dans TSP il n'y a pas "réellement" d'ordre des samples
mais juste la notion de cycle.
Donc TOUS les symboles produits par le provider dans 1 cycle
ne sont pas "ordonnés"  (d'un point de vue de TSP).

Chaque provider a SA propre façon d'ordonner
[la production effective de] ses symboles
la couche de TSP provider lib ne voit pas d'ORDRE mais seulement
un ensemble de PGI qui lui sont fournis par le GLU.
De même le datapool n'est pas une FIFO mais un
pool non ordonné de valeurs.
Au moment du datapool commit la lib TSP provider
distribuera à chaque consumer les symboles dans l'ordre
que le provider a LUI-MEME déterminé au moment de la request sample.

Le fait que l'implémentation actuelle "trie" les sample dans l'ordre
croissant des PGIs est un avatar d'implémentation et pas une "feature".
D'ailleurs l'ordre est essentiellement guidé par la façon dont est
codé la fonction get_pgi de chaque GLU.

Côté consumer:

Le consumer demande un "ensemble" de symboles avec les périodes
associées et LE PROVIDER calcule (sans contrainte) le nombre de groupe
que celà va générer et l'ordre d'envoi qui l'arrange.

Des remarques pour Viriginie juste après:

> On 12/20/06, ALAUX, Virginie <address@hidden> wrote:
> >
> > Bonjour,
> >
> Je reviens alors sur mon besoin d'avoir une API consumer permettant de 
> >récupérer le groupe entier. En effet, si je ne peux pas avoir un moyen sur 
> d'avoir
> ce sample "time" en PREMIER,

!! question de vocabulaire le sample.time qu'on trouve dans chaque
sample issu d'un TSP_consumer_read_sample n'est PAS un symbole
TSP NI même une variable qui représente le temps mais seulement
un compteur de "cycle" TSP. Si time change alors c'est qu'on a changé
de cycle TSP donc de cycle provider.

Si tu parles d'un symbole qui s'appelle "time" alors c'est différent
c'est un symbole TSP "comme un autre" dont seuls le(s) consumer(s)
et le provider concernés connaissent la "sémantique".

i.e. ce symbole représente le temps de mon simulateur.

> je suis obligé de buffériser tous mes samples,

Oui c'est exact néanmoins si on suppose que tu as 10000 samples
(ce qui me parait déjà considérable) et que chaque sample est
un double (64bit = 8 octets) ton buffer fera un peu plus de 78Ko
(allouable 1 fois pour toute tant que la config de sample ne change pas)
ce qui me parait sincèrement pas grand chose par rapport à
l'empreinte mémoire des simulateurs que je connais, surtout ceux
qui transmettent des objets CORBA :))


> puis
> lorsque je recois le "time", de parcourir les samples mémorisés, de les dater
> puis de les ajouter dans mon OCDS => pb de perfos

Je dirais que le fait de devoir dater CHAQUE sample à rajouter à un OCDS
est la "vraie" contrainte, car si tu pouvais dater ton OCDS 'globalement'
le pb serait différent.

Quoiqu'il en soit OUI tu vas faire une boucle de plus pour construire l'OCDS.

Vu tes remarques il est ?peut-être? pertinent de pouvoir demander
via TSP des samples "ordonnés".

Mon avis personnel est que la gestion de cet "ordre" n'est pas le pb de TSP
et peut se faire "par-dessus", mais si les autres pouvaient s'exprimer
sur ce point :))

Personnellement je serais curieux de connaître l'overhead entre une
double boucle
et une simple boucle permettant de construire ton OCDS en même temps
que la réception des samples.

Je rajouterais que "vu de ma fenêtre" le pb (si je l'ai bien compris) est plutôt
du côté de la méthode de construction des OCDS.

(Je pense qu')on devrait pouvoir construire un OCDS contenant moult' valeurs
et dire à un moment OCDS.setTimeForAllInsertedOCDSItem(time).



--
Erk