tsp-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: TSP
Subject: RE : RE : RE : [Tsp-devel] Ordre d' arrivée des samples d'un groupe
Date: Thu, 21 Dec 2006 09:26:36 +0100

Salut,

Si on rajoute dans la spec des fournisseurs :

que le provider doit répondre dans l'ordre de la demande,
Que le provider doit mettre la date dans le PGI zero,

cela peut il arranger les choses ?
Y a-t-il une impossibilité de développement ?

Merci,

Cesare

-----Original Message-----
From: Eric Noulard [mailto:address@hidden
Sent: Wednesday, December 20, 2006 6:28 PM
To: address@hidden; Transport Sample Protocol development list
Subject: Re: RE : RE : [Tsp-devel] Ordre d'arrivée des samples d'un groupe


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

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

CE COURRIER ELECTRONIQUE EST A USAGE STRICTEMENT INFORMATIF ET NE SAURAIT 
ENGAGER DE QUELQUE MANIERE QUE CE SOIT EADS ASTRIUM SAS, NI SES FILIALES.

SI UNE ERREUR DE TRANSMISSION OU UNE ADRESSE ERRONEE A MAL DIRIGE CE COURRIER, 
MERCI D'EN INFORMER L'EXPEDITEUR EN LUI FAISANT UNE REPONSE PAR COURRIER 
ELECTRONIQUE DES RECEPTION. SI VOUS N'ETES PAS LE DESTINATAIRE DE CE COURRIER, 
VOUS NE DEVEZ PAS L'UTILISER, LE CONSERVER, EN FAIRE ETAT, LE DISTRIBUER, LE 
COPIER, L'IMPRIMER OU EN REVELER LE CONTENU A UNE TIERCE PARTIE.



This email is for information only and will not bind EADS Astrium SAS in any 
contract or obligation, nor its subsidiaries.

If you have received it in error, please notify the sender by return email. If 
you are not the addressee of this email, you must not use, keep, disseminate, 
copy, print or otherwise deal with it.

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]