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

[Stef Euskadi]

B'Soir,

Et bonne année à tous.

Voici ma pierre à l'édifice, même si cela n'est pas d'une très grande utilité.

Le PPCM dont parle Bob est tout simplement la MAF (MAjor Frame), très connue
de tous ceux qui ont eu un jour à séquencer des modèles de simulation en temps réel
ou non.

Je n'ai aucun mérite, je suis en plein dedans (entre autres choses)

Euskadi.

Le 23/12/06, PAGNOT, Robert <address@hidden> a écrit :

Désolé d'avoir raté votre thread, mon accès au réseau Astrium est très sporadique ... Je viens de changer vers mon e-mail perso.

 

De la part du "géniteur de cette $ address@hidden|`\@ théorie des groupes", je tiens à signaler que c'est ne pas une théorie, mais juste une conséquence naturelle des spécs de TSP liées à l'émission en multifréquence à partir d'une période de base.

Le principe est très simple : à chaque variable sa fréquence, donc sa période ... et quand on "empile" toutes les variables dans le temps, on observe un pseudo-cycle d'émission égal au plus petit multiplieur commun de toutes les périodes.

Par conséquent, le contenu des paquets est CYCLIQUE et PREVISIBLE. En déroulant le même algo d'assemblage des variables côté consumer/provider, on évite de transmettre les PGI de chaque variable. Cette approche permet de réduire au strict minimum la taille des paquets car seules les XDR_values sont transmises.

 

Exemple : Fprovider = 100Hz,

        V1 demandée à 100 Hz (10 ms)

        V2 demandée à 50 Hz (20 ms)

        V3 demandée à 33,33 Hz (30 ms)

PPMC = 60 ms.

Les paquets s'organisent en :

    Cycle 0 : V1,V2,V3

    Cycle 1 : V1

    Cycle 2 : V1,V2

    Cycle 3 : V1,V3

    Cycle 4 : V1,V2

    Cycle 5 : V1

    Cycle 6 : V1,V2,V3 ... idem Cycle 0, et ça recommence !

 

Je soutient pleinement Eric sur le fait qu'une variable TIME n'est pas différente de tout autre donnée applicative. Dans TSP, il n'y a que la notion de cycle (sur la période de base du provider) dont le ZERO d'origine n'a pas de sens. Par conséquent, il serait abusif d'inclure une quelconque contrainte au TSP provider sur ce sujet.

 

Je me souviens de discussions acharnées sur l'organisation des variables vues côté consumer. Nous avions deux options :

• FIFOs par variable
• FIFO unique de lignes par cycle TSP, genre datapool daté (proche du format RES, donc)

Il me semble que seul le premier a été retenu (TSP_consumer_read_sample), car le deuxième posait des problèmes avec des variables à fréquence très différentes et le groupe asynchrone (pas le read_async, mais le groupe contenant des couples PGI,XDR_VALUE, triggé par la modif de valeur d'un sample).

 

Si j'ai bien compris Virginie, cette deuxième option collerait à son besoin.

 

Eric & Yves, faites appel à vos mémoires, corrigez-moi si je me trompe et peut-être est-il temps de discuter de la deuxième option, genre TSP_consumer_read_line(provider, line, newline). La "ligne" serait décrite comme les fichiers RES (compteur de cycle + la valeur courante des variables en brut). On devrait restreindre ce type d'API à l'utilisation mono-fréquence par provider ?

 

A bientôt,

 

    Robert

 

 

-----Original Message-----
From: TSP [mailto:address@hidden]
Sent: Tuesday, December 19, 2006 6:34 PM
To: 'Transport Sample Protocol development list'
Subject: RE : [Tsp-devel] Ordre d'arrivée des samples d'un groupe

Je me rends compte que j'ai oublié de répondre à ce mail.

 

Mon avis est que si TSP respecte l'ordre de tsp_sample dans la réception par groupe.

Donc demande d'abord le temps, et ensuite les autres autres variables, et tu  devrais toujours avoir le temps en premier.

Merci à la communauté, et surtout aux "géniteurs" de cette $address@hidden|`\@  théorie des groupes de me confirmer et surtout de m'infirmer si jamais je me trompe.

 

Yves

-----Original Message-----
From: ALAUX, Virginie [mailto:address@hidden]
Sent: Tuesday, December 05, 2006 5:04 PM
To: 'address@hidden'
Subject: [Tsp-devel] Ordre d'arrivée des samples d'un groupe

Re,

J'ai encore une question sur l'ordre d'arrivée, côté consumer, des samples dans un groupe.

En effet, mon consumer doit demander un paramètre "temps" au provider. Ce paramètre est présent dans tous les groupes et permettra au consumer de dater les autres samples du groupe.

Comment puis-je faire pour recevoir ce paramètre en premier lors de la réception d'un groupe ?
En effet, pour des pb de perfos, je ne peux pas bufferiser tous les samples reçus avant lui et les dater une fois ce param "temps" reçu.

De plus, je ne sais pas à l'avance à quelle fréquence demander ce paramètre "temps". Je dois attendre que l'utilisateur ait fini de programmer ses acquisitions, pour le demander alors au provider à la fréquence maximum. Il sera donc demandé par tsp_consumer_request_sample après tous les autres params.

Merci

Virginie Alaux (55-24)

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

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.

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

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

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.

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

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

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.

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

_______________________________________________
Tsp-devel mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/tsp-devel

-- 
--
Euskadi.