[Tsp-devel] Mon buffer brésilien en string sur Internet

[DUFRENNE, Yves]

Salut à Tous!
Moi l'abstraction, c'est comme un canard clandestin le soir d'un dîner de
l'amical des chasseurs/douaniers : J'ai envie de tirer dessus juste pour
voir l'effet que cela fait. Donc je commence ...

1) Petit Bémol
==============
 L'échange de string ne sera pas uniquement limité au groupe asynchrone. Je
peux très bien être un gros neuneu d'utilisateur et vouloir sampler mes 1000
états sous forme de chaîne de caractère du genre "OK" ou "T'esFoutu" à
100Hz. Le provider ayant lui seul le pouvoir de convertir l'état en chaîne,
la protection que nous ayons c'est qu'il peut borner chaque symbole en
string à une taille max au retour du request_sample_init.

2) Postulat
===========
Le seul besoin coté client de FIFO, c'est pour gérer les retards TEMPORAIRES
du client dans la relecture => La socket n'est pas suffisante, mais je ne
sais plus pourquoi (128Ko / (1000 symboles *100Hz *8octets) me donne 125ms
de marge. C'est peu mais peux-t-on augmenter le buffer de la socket ?
=> Je pourrais construire au retour du request_sample_init. un gros tableau
circulaire de n structures de request_sample. Ainsi je pourrais stocker n
fois des données issus du protocole. Si je prends n > p*freq de sampling,
j'obtient au moins p secondes de répit pour le client. Avec les données
issues de la théorie des groupes de fréquences, je saurais dire à chaque
step lesquelles données ont été mise à jour pour les rendre au client. C'est
quasiment 0h en codage, et cela simplifie en plus l'écriture d'un archiveur
brut de protocole TSP.

3) Gros gourmand !
==================
Gros gourmand me direz vous, tu utilise bien trop de mémoire que nécessaire,
car à certains step, juste une portion infime des données seront mise à jour
(genre les 1% de variables à haute fréquence). Certes, mais si je prends
quelques chiffres, cela n'est pas énorme : 1 secondes * 10000 symboles *
100Hz * 10octets (je prends une valeur moyenne de taille des symboles) me
donne 1Mo de mémoire : Une paille pour un client sur les machines
actuelles....

4) Hérésie !!!
==============
J'irais même plus loin. Si je consomme trop de mémoire, c'est à cause de ce
putain de demande de mettre différentes fréquences dans une même connexion.
Si je dis "Une connexion TSP = 1Frequence*1Phase", je me débarrasse de la
théorie des groupes (je ne l'ai jamais aimé d'abord), je simplifie le codage
du core, et j'ai un mécanisme super simple optimum des buffers !!! De plus
tous les clients actuels ne demande qu'une seule fréquence, donc c'est
pareil. Avec cet affirmation, je suis sur d'aller au bucher des hérétiques
de TSP. Qui veut jouer le rôle de Torquemada ???

5) Pour les puristes
====================
Si vraiment le coté multi-fréquence vous tient à coeur, on peut le masquer
au client en découpant sa requête avec plusieurs groupe de même
fréquence/phase par autant de connections. Et je suis sur qu'on aura pas
beaucoup de clients qui dépasseront les 10 sockets par session. Peut-être
cela va-t-il acheter mon absolution ?

Bon le Golgothe est lâché, à vos clavier, mais pitié ne tapez pas trop fort
sur le pianiste, je suis déjà assez handicapé mental comme cela. Tout ceci
n'est qu'un pavé dans la mare pour faire peur aux canards, et non pas un
diktat de l'admin TSP, surtout que je n'ai toujours pas réactivé ma
connexion SSL.

Y++

On Tue, 2004-01-06 at 12:12, Eric NOULARD wrote:
> Selon "PAGNOT Robert (EADS ASTRIUM)" <address@hidden>:
> 
> > Faites gaffe aux données asynchrones !!!!
> 
> Oui très juste il faut 'juste' se donner un moyen de borner
> un volume de données asynchrone acceptables.
> A noter qu'actuellement le 'groupe' asynchrone est prévu
> mais non utilisé (Corrigez-moi si je me trompe).
> 
> Eric
> 
> > 
> > A+
> > 
> > Robert
> > 
> > -----Message d'origine-----
> > De : Eric NOULARD [mailto:address@hidden
> > Envoyé : mardi 6 janvier 2004 09:49
> > À : Stephane Galles
> > Cc : tsp-devel; address@hidden
> > 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 60k/s (une fois qu'on a passé tous les groupes) et le
> > client annonce qu'il tiendr
> > 
> > 
> > > 
> > > 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à.
> > > 
> --- more cutted ---
> ---
> Erk
> 
> 
> _______________________________________________
> Tsp-devel mailing list
> address@hidden
> http://mail.nongnu.org/mailman/listinfo/tsp-devel
>

important_notice.txt
Description: Text document