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

[Eric.NOULARD]

Après une bataille à la visseuse avec Yves ce Week-End voici
mes quelques remarques.

> -----Message d'origine-----
> De : address@hidden
> [mailto:address@hidden
> De la part
> de DUFRENNE, Yves
> Envoyé : vendredi 9 janvier 2004 10:22
> À : 'address@hidden'
> Objet : [Tsp-devel] Mon buffer brésilien en string sur Internet
> 
> 
> 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.

  C'est exact, on ne peut borner la taille qu'au moment du
request_sample_init.
  A noter que le problème serait similaire si on gérait les tableaux de
  taille dynamique (ben ouaih pourquoi pas...)

> 
> 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 
> uffisante, 

  NE PAS REFLECHIR EN TERME DE CHAUSSETTE, elle est là car
  on a une réalisation de TSP sur TCP/IP ça serait très différent
  si on avait une sorte de SHM (VME, DualPort, IPC POSIX...)

> 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 ?

  Mis à part pour la lessive pas de chaussette ici.

> => 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.

   Je laisse Yves préciser ce qu'est une 'structure de request_sample'
   mais je suis d'accord sur le principe.

> 
> 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....

        Il faudra prévoir des cas où on s'offrira par le Mo car j'ai
en tête un CPU VME ERC32 avec 4Mo au total donc... 
        Evidemment on peut mettre des restrictions sur les capacités
de certains provider vu l'environnement dans lequel ils tournent
genre 'je veux des request mono-frequence'.
      Mais plus simplement je pense qu'on peut coder l'idée d'Yves en premier
approche et garder à l'esprit l'impact qu'aurait un ringbuf un peu plus
"taillé sur mesure" sur la complexité du code.

        De façon connexe, il serait utile que le provider annonce 
(dans l'answer_sample ou via une api de la lib TSP qui prend
 en parametre une answer_sample) au consumer que sa requête correspond à un 
débit moyen de x ko/secondes.
        Ca permettrait au consumer de savoir à quoi s'attendre sans 
faire le calcul et au provider de refuser éventuellement une requete
pour le motif: bande passante demandée NON dispo.

> 
> 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 ???

        Euh moi  :)))
      La théorie des groupes est aujourd'hui un avantage MAJEUR
de conception pour limiter simplement la bande passante ET pour
rendre les clients CRETINS (au sens du protocole de données je ne
veux facher personne). Si le client commence à ouvrir 10 connexions 
(sockets) avec un SEUL provider je sens bien que sa complexité ne 
va pas aller décroissante.
      De plus le multi-fréquence est UTILE, même si on a généralement
pas 40 fréquences différentes mais plutôt 5/6 dans les exemples que
j'ai en tête.
      De plus il est de bon goût qu'un provider puisse limiter 
le nombre de connexion qu'on lui inflige sans empêcher un client
d'accéder à toutes ses fonctionnalités.

> 
> 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 ?

   Pas du tout decapité au lieu d'être brulé tout au mieux.

> 
> 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
> > 
>