RE : RE : [Tsp-devel] Question sur le type 'String'

[Eric.NOULARD]

J'ai merdé la fin de mon message en appuyant frénétiquement sur
<Enter> je continue donc.

-------- Message d'origine--------
De:     Eric NOULARD [mailto:address@hidden]
Date:   mar. 06/01/2004 09:48
À:      Stephane Galles
Cc:     NOULARD, Eric-Syntegra FR; tsp-devel
Objet:  Re: RE : [Tsp-devel] Question sur le type 'String'
Selon Stephane Galles <address@hidden>:

>
> Pouf, pouf, j'ai pas tout compris à ce que tu dis,
> mais je peux te passer l'info dont tu a besoin.

Je vais essayer de préciser.

>
> Tu trouveras des RingBuf à 3 endroits :
>
> - coté consumer : 1 RingBuf pour empiler
> les données qui arrivent dans leur format final
> (double, etc...)
> - coté provider : 1 RingBuf pour chacun des clients
> pour empiler les données avant de les envoyer par
> la socket,  pour éviter qu'un client qui bloque ne bloque
> les autres clients.

Les 2 ringbuf précédents sont spécifiques d'une request_sample
particulière, donc on sait déjà dans quel ordre on va mettre
les choses dedans et également la place que cela prendra vu
qu'on a construit les groupes pour les fournir en réponse dans
l'answer_sample.

Donc on peut 'tailler' et instancier un ringbuf en fonction
de la derniière request sample et au moment de la request_sample_init.

Donc on ALLOUE (éventuellement dans un pool autorisé, pas forcément
un malloc mais c'est un détail d'implementation) les RingBUF consumer
et provider AU MOMENT de la request_sample_init EN FONCTION de la
dernière request sample.
On sait la taille et le type de ce qu'on aura à empiler dans ces
RingBuf car on a construit la table des groupes.
On dimensionne les ringbuf suivant un débit mini
annoncé par le consumer. Genre la requete global correspond à un débit
moyen de 60ko/s (une fois qu'on a passé tous les groupes) et le
client annonce qu'il tiendra 100ko/s [a noter que l'annonce du client
n'est actuellement pas présente mais on peut estimer qu'il est grand
est qu'il assumer être capable d'avaler le débit moyen qu'il a demande]

Toutefois le RingBuf doit pouvoir "éponger" les pics de débits
c'est-à-dire la différence entre le débit max sur une durée donnée
et le débit moyen.
Genre on a un pic à 200ko/s sur les cycles 57 et 59
(sur 63 d'un provider à 64Hz))
donc on doit éponger 400k/s sur 3 cycles (64Hz)
Donc on taille le ringbuf à 400*1024*3/64 octets.

Est-ce qe c'est plus clair.

Eric
>
> Accessoirement, un RingBuf dans le glu stub de demo.
> Mais c'est juste un choix d'implémentation, ce RingBuf
> pourrait ne pas etre là.
>
> address@hidden wrote:
>
> >
> > Je suis d'accord avec le coup des 2 ringBuf de Robert
> > MAIS une idée vient à germer
> > ne devrait-on pas spécialiser un peut notre ringBuf.
> >
> > Je veux dire par là que, 'hors' mis lorsqu'on change la structure
> > du provider on a toujours un ringBuf qui empile la MEME CHOSE
> > dans le MEME ordre, c'est ce qui nous permet de grace aux groupes
> > TSP de ne pas passer l'id d'une variable à chaque fois.
> >
> > Donc, pourquoi est-ce que le RingData de Robert ne serait pas
> > créer une fois pour toute (un pour chaque provider) et donc
> > dimensionner à une taille fixe et on vote ensuite que le
> > consumer doit consommer le RingVector à disons 1 Mo/s ce qui
> > dimensionne le RingVecteur au 'n' premières données  décritent
> > dans le RingData?
> >
> > Bon je sens que je commence à être pas clair.
> > Je me plonge dans le code ce soir ou demain
> > soir et j'en reparle plus concrètement.
> >
> > D'ailleurs quelqu'un de plus au jus que moi au niveau du
> > code pourrait-il me dire où (consumer/provider/glu) et
> > combien (1 par consumer...) de RingBuf sont utilisés
> > ACTUELLEMENT.
> >
> > Eric
> > -------- Message d'origine--------
> > De:     address@hidden de la
> > part de PAGNOT Robert (EADS ASTRIUM)
> > Date:   lun. 05/01/2004 13:43
> > À:      'Stephane Galles'; tsp-devel
> > Cc:   
> > Objet:  RE: [Tsp-devel] Question sur le type 'String'
> > Suite ...
> >
> > Par la même occasion, réflechissons bien à la manière de ranger les
> > vecteurs/tableaux.
> > Au départ je pensais deplier les vecteurs dans le RingBuf et accompagner
> > chaque element d'un compteur pour indiquer qu'ils font partie d'un même
> > vecteur.
> > L'idée est intéressante pour simplifier le dimensionnement du RingBuf de
> > vecteurs (que j'appelerai RingVector), mais l'overhead mémoire serait très
> > important. Je crois que l'on peut s'affranchir de ce compteur et même du
> > pointeur dans le RingBuf initial (que j'appelle RingData) par la méthode
> > suivante :
> > *       élément de type VECTOR serait codé en RingData par un couple
> > ID-Type/Longueur uniquement
> > *       RingVector serait un ringbuf d'octets bête et méchant.
> > *       Le push d'une variable VECTOR se fait par un push dans
> > RingVector du
> > nombre d'octets qui va bien, suivi d'un push de id-type/longueur dans
> > RingData (section critique Mthread à prévoir ?)
> > *       Le pop d'une variable VECTOR se fait par un pop de RingData (sans
> > commit !), puis un pop du nombre d'octets qui va bien dans RingVector
> > (avec
> > commit), puis un commit dans RingData.
> >
> > Cette méthode est généralisable à des vecteurs de n'importe quoi : il
> > suffit
> > de définir un ringbuf (RingVector) dont l'élément de base n'est pas un
> > octet, mais le "n'importe quoi", et de créer un type particulier dans
> > RingData.
> >
> > Il est à prévoir un overhead important en temps CPU car on doit
> > empiler/dépiler octet par octet (pas d'opération de cache possible
> > ...). Les
> > méthodes "BURST" de ringbuf peuvent améliorer les choses, sinon on peut
> > "clusteriser" les données et dire, par exemple, que chaque élément de
> > RingVector mémorise, disons, 16  octets, et que l'on empilera/dépilera
> > autant de blocs de 16 octets qui faut pour compléter le vecteur. Ainsi, un
> > vecteur de 14 octets utilise un seul bloc (+ deux octets inutilisés),
> > et un
> > vecteur de 33 octets utilise 3 blocs (+ 15 octets inutilisés). C'est
> > clair ?
> >
> > Maintenant, histoire de mélanger les discussions : une String
> > peut elle/doit elle etre considérée comme un vecteur de char, hum ?
> > Un puriste te dirait que non, surtout s'il a subi une (dé?)formation
> > Object
> > (argh !). Maintenant en ce qui concerne un protocole de communication, mon
> > humble avis est que C'EST STRICTEMENT PAREIL, on fait tous du ASCii, non ?
> >
> > Steph.
> > Bob
> >
> >
> > PAGNOT Robert (EADS ASTRIUM) wrote:
> >
> > > Eh oui, Robert is back !
> > >
> > > Premièrement toutes mes félicitations pour vos élocubrations pleines
> > > de bon sens, même en période franchement plutôt propice aux
> > > gastro-entérites et autres crises de foie. Je vois que le sujet
> > passione !
> > >
> > > Puisque je dois dire quelque chose d'utile, je vous proposerai de
> > > gérer les string (et d'une manière générale tout élement de longueur
> > > variable) par deux zones mémoires.
> > >
> > > 1) LE ringbuf basique qui ne contient qu'un pointeur, à la place de la
> > > valeur (tableau de bytes) : peu de changements par rapport à l'état
> > > actuel car ce ringbuf serait à largeur constante et connue !
> > >
> > > 2) Un ou plusieurs ringbufs stockant de façon circulaire les élements
> > > à taille variable. La largeur serait égale au max (fourni par le
> > > provider), et profondeur calculée selon la fréquence de sampling.
> > >
> > > On pourrait discuter sur le nombre de ringbufs à instancier (autant de
> > > ringbufs que d'élements, un seul ringbuf pour tous les éléments de
> > > longueur variable, ...), mais aussi sur la profondeur qui risque
> > > d'être difficile à modéliser !
> > >
> > > Sans vouloir se torturer l'esprit, pensez que dans le cas des textes,
> > > il s'agira essentiellement de messages asynchrones, dont la fréquence
> > > de changement sera très lente par rapport aux données synchrones !
> > > Limiter donc les paramètres à longueur variable en asynchrone (en gros
> > > - je transmet quand sa valeur change) ne serait pas très limitatif.
> > >
> > > De plus, dissocier en termes de mémoire les paramètres à longueur
> > > variable (string, tableaux - de quoi déjà ?, ...) des paramètres à
> > > longueur fixe (doubles, int, ...) sera probablement plus efficace que
> > > de tout mélanger. Ce sont des paramètres de nature différente.
> > >
> > > A+
> > >
> > >         Robert
> > >
> > > -----Message d'origine-----
> > > De : Stephane Galles [mailto:address@hidden]
> > > Envoyé : dimanche 4 janvier 2004 20:30
> > > À : Ibou de Joie; tsp-devel
> > > Objet : Re: [Tsp-devel] Question sur le type 'String'
> > >
> > >
> > > OK, donc dans ma TODO list je passe en priorité :
> > >
> > > "Comment implémenter un ringbuf qui gère des types variables ".
> > >
> > > C'est vrai que je restais conservateur pour la taille des strings
> > > parceque je n'avais pas envisagé de toucher de nouveau au RingBuf
> > > (A cause du vieux precepte : "ca marche bien, et depuis longtemps;
> > > donc t'evite de toucher avec tes gros doigts").
> > >
> > > Mais pas de problèmes, on va voir comment modifier le RingBuf.
> > >
> > > Par contre, je vais créer une batterie de tests unitaires qui vont
> > > aller avec le nouveau RingBuf, et il faudra les passer sur
> > > toutes les plateformes pour attraper tous les problèmes
> > > d'alignement.
> > >
> > > Je sens que cela va nécessiter un FrameWork de test un peu sérieux.
> > > Je connais quelqu'un qui a utilisé un FrameWork de tests unitaires
> > > il y a peu de temps. Je vais le contacter car il en était trés content.
> > > Je crois que c'est CUnit (http://cunit.sourceforge.net/) mais il
> > > faut que je vérifie.
> > >
> > > Steph.
> > >
> > > Ibou de Joie wrote:
> > >
> > > >Et un ringbuf qui gere des types de taille variable (Une zone memoire
> > > >commune globale, et on decale le ptr courant de la taille du dernier
> > > >element) : Certes on ne sait pas exactement le nombre de truc que l'on
> > > >peut y mettre, mais on connait leur occupation mémoire totale ? Ce doit
> > > >etre un peu tricky pour les pb d'alignement, et donc sans doute moins
> > > >efficace, mais à voir.
> > > >
> > > >Et je suis (comme d'hab) d'accord avec Eric, le provider doit pouvoir
> > > >donner la taille max de chaque element à la connexion.
> > > >
> > > >Y++
> > > >
> > > >
> > > >On Sat, 2004-01-03 at 13:13, Eric NOULARD wrote:
> > > >
> > > >
> > > >>Selon Stephane Galles <address@hidden>:
> > > >>Euh très honnêtement je pense que 8 caractères c'est un peu
> > > >>petit quiqui pour un Caribou de ta trempe.
> > > >>
> > > >>Je ne vois pas précisément le pb du ring buffer
> > > >>car je n'ai pas le code sous la main là ou je suis
> > > >>mais je pensais (bêtement) qu'une string avait une taille
> > > >>a priori illimité mais que le provider annonçait au consumer
> > > >>une taille MAX pour la session de sampling en cours de négoce.
> > > >>Ensuite une fois la request_sample_init, on peut plus toucher
> > > >>à la taille max, ce qui fait que le provider doit tailler
> > > >>son ring-buf en fonction de ça.
> > > >>
> > > >>
> > > >> 
> > > >>
> > > >>>Bon, je me suis lancé sur le codage des autres types, int, string,
> > > etc...
> > > >>>J'ai commencé par le coté consumer. Je pense par contre que dans
> > > >>>un premier temps, et quitte à me contredir, je ne vais pas utiliser
> > > >>>les structures XDR pour la couche de transport. On vera cela
> > > >>>dans un 2eme temps.
> > > >>>
> > > >>>Une question concernant le type 'String' : Il y a bien une taille
> > > max ?
> > > >>>parceque si ce n'est pas le cas, je vais etre trés ennuyé pour les
> > > stocker
> > > >>>dans un ringbuffer coté consummer.
> > > >>>
> > > >>>Donc je propose 8 charatères max pour les string. Simplement parceque
> > > >>>les plus gros types (double et long long) font au max 8 octets et
> > > que donc
> > > >>>on ne perd pas de place dans les ringbuf à cause des strings.
> > > >>>
> > > >>>j'espere que le besoin 'String' ne consiste pas à essayer de faire
> > > transiter
> > > >>>des nombres en format string, sinon 8 charactères cela va etre un
> > > peu juste.
> > > >>>
> > > >>>J'avais compris ce besoin plutot pour faire passer des infos
> > > textuelles
> > > >>>comme "ON", "OFF", etc ... Am I right ?
> > > >>>   
> > > >>>
> > > >>Je pense que tu as raison, mais on peut vouloir faire transiter
> > > >>un peu plus que 8 caractères.
> > > >>
> > > >>En gros, en ce qui concerne la taille max d'un string peut être
> > > dynamique
> > > >>MAIS une fois que les sample sont en route celle-ci ne change plus.
> > > >>
> > > >>De façon plus général, le consumer "découvre" les types des symboles
> > > >>(et donc leur taille) avec une request_info et/ou la premiere
> > > >>request_sample ensuite ces tailles ne peuvent pas changer dès que les
> > > >>sample ont commencés à transiter du provider au consumer.
> > > >>
> > > >>On pourrait imaginer que suite à un arrêt/redémarrage de la MEME
> > > >>requete de sample la taille/le type d'un symbole est changé.
> > > >>(si on oublie 30s le problème que ça pose côté provider).
> > > >>
> > > >>Qu'en penses-tu?
> > > >> 
> > > >>
> > > >>>Stephane.
> > > >>>
> > > >>>
> > > >>>
> > > >>>
> > > >>>
> > > >>>
> > > >>>
> > > >>>_______________________________________________
> > > >>>Tsp-devel mailing list
> > > >>>address@hidden
> > > >>>http://mail.nongnu.org/mailman/listinfo/tsp-devel
> > > >>>
> > > >>>   
> > > >>>
> > > >>--
> > > >>---
> > > >>Erk
> > > >>
> > > >>
> > > >>_______________________________________________
> > > >>Tsp-devel mailing list
> > > >>address@hidden
> > > >>http://mail.nongnu.org/mailman/listinfo/tsp-devel
> > > >>
> > > >> 
> > > >>
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> > >
> > >
> > > _______________________________________________
> > > Tsp-devel mailing list
> > > address@hidden
> > > http://mail.nongnu.org/mailman/listinfo/tsp-devel
> > >
> > > This mail has originated outside your organization,
> > > either from an external partner or the Global Internet.
> > > Keep this in mind if you answer this message.
> > >
> > >------------------------------------------------------------------------
> > >
> > >_______________________________________________
> > >Tsp-devel mailing list
> > >address@hidden
> > >http://mail.nongnu.org/mailman/listinfo/tsp-devel
> > >
> > >
> >
> >
> > This mail has originated outside your organization,
> > either from an external partner or the Global Internet.
> > Keep this in mind if you answer this message.
> >
> >
>
>
>
>
> _______________________________________________
> Tsp-devel mailing list
> address@hidden
> http://mail.nongnu.org/mailman/listinfo/tsp-devel
>


--
---
Erk