Le serveur arrête la réception + désynchronisation

Version imprimable

Voir 40 message(s) de cette discussion en une page

09/09/2009, 09h47
Mac LAK

Citation:

Envoyé par ens-lyon

Je vais essayer de faire comme tu di le probleme c'est qu'il faut justifier au responsable pourquoi je doi faire,je veux dire des explicaions rationnelle.

Commence déjà par lui redire ce que j'ai expliqué plus haut, si ça ne suffit pas, pose ses contre-arguments ici, que l'on puisse jouer à les démonter... :mrgreen:

Mais le coup du bench avec les leds, c'est imparable, ça te permettra de prouver que ta fonction send() est trop lente pour la fréquence d'échantillonnage désirée... Et c'est rapide à monter comme manip.
09/09/2009, 11h13
ens-lyon

Citation:

Envoyé par Mac LAK

Commence déjà par lui redire ce que j'ai expliqué plus haut, si ça ne suffit pas, pose ses contre-arguments ici, que l'on puisse jouer à les démonter... :mrgreen:

Mais le coup du bench avec les leds, c'est imparable, ça te permettra de prouver que ta fonction send() est trop lente pour la fréquence d'échantillonnage désirée... Et c'est rapide à monter comme manip.

Merci infiniment , grace a ton aide je suis sorti un peu de l'obscurité , je suis entrain de faire le programme des leds avec l'envoi de 8Bytes dans un tableaux,que je récupere ensuite dans un fichier coté client, je ferai les mesure et je te tiens au courant.
09/09/2009, 11h23
ens-lyon

1 pièce(s) jointe(s)

Citation:

if (T->Established() == 1)
{
I2C_transmit_char ( 0x70,0xff );
T->Send(data,8);

I2C_transmit_char ( 0x70,0x7F );

}

Donc voila j'ai fait quelques visualisations à l'osciilo , et voila le resultat :

j'ai des éteintes pendant 254us , allume pendant 124us.
Sans envoi j'ai les leds qui s'allument et s'eteignent chaque (124*2)us

Ce qui veux dire j'ai un plus de 130us pour envoyer la donnes de 8Bytes.

Ce que je comprend pas encore c'est pourquoi après un certain temps j'ai la led qui reste allume beaucoup plus longtemps et après s'éteint et reste éteinte aussi longtemps.

Je peux dire que le TCP/IP est la cause , mais quand elle éteinte elle doit pas le rester longtemps sauf s'il ya un autre processus qui tourne interruption non???

Voila la photo de du signal à l'oscillo
09/09/2009, 11h39
Mac LAK
Citation:

Envoyé par ens-lyon

Ce que je comprend pas encore c'est pourquoi après un certain temps j'ai la led qui reste allume beaucoup plus longtemps et après s'éteint et reste éteinte aussi longtemps.

Il faudrait sniffer le réseau en même temps, mais je pense que ta stack TCP/IP est en attente d'un ACK avant de continuer les envois : en effet, ta manière de procéder envoie un peu trop de paquets sur le réseau, et peut donc faire un peu dégénérer les algos TCP/IP (qui sont faits pour transmettre un FLUX de données, et non pas des petits paquets individuels).

Citation:

Envoyé par ens-lyon

Je peux dire que le TCP/IP est la cause , mais quand elle éteinte elle doit pas le rester longtemps sauf s'il ya un autre processus qui tourne interruption non???

Ou une IT perdue qui a mis le bronx, c'est possible aussi.
La cause réelle est difficile à déterminer sans avoir le code source intégral et complet, avec la liste totale des processus / IT / daemons de l'OS. Seul point positif, il est plus que probable que ce soit une conséquence du blocage dans le send(), et que ce problème disparaisse donc définitivement lorsque tu mettra l'envoi TCP/IP dans un thread séparé, et par "gros paquets" plutôt que par trames de 8 octets à chaque fois.

D'où les actions suivantes à mettre en place :
- Mise en thread de l'envoi TCP/IP et en IT de l'acquisition SPI (ou thread très haute priorité pour le SPI, et priorité moyenne pour le TCP/IP).
- Mise en place d'un double buffer entre les deux afin d'émettre des paquets TCP/IP de taille presque maximale.
Une fois ceci fait, ton souci devrait être réglé.
09/09/2009, 11h46
ens-lyon

Je te remercie , c'est un peu louche ce qu'on apprend à l'école surtout en elec concernant les matière info et réseaux!!lol! et après on nous harcèle d'être feneant.

A bientot
09/09/2009, 12h14
Mac LAK

Citation:

Envoyé par ens-lyon

Je te remercie , c'est un peu louche ce qu'on apprend à l'école surtout en elec concernant les matière info et réseaux!!lol! et après on nous harcèle d'être feneant.

Nan, ça, c'est juste la gueguerre constante softeux/hardeux, en fait... :twisted:

Sinon, de rien, n'oublie pas le :resolu: quand ce sera le cas, et éventuellement de poster aussi si ça a bien marché ! ;)
09/09/2009, 13h04
ens-lyon

Bh apparemment , mon maitre de stage ne veux pas la méthode des leds , et s'en fou des résultats que j'ai trouvé , et dit que ca doit marcher même en asynchrone,et propose a la place du SPI de remplir les buffer manuellement et de les envoyer comme le faisait le SPI .

La méthode des leds ne nous permettra pas de voir si les données sont perdues , d'après lui.8O
09/09/2009, 13h45
Mac LAK

Citation:

Envoyé par ens-lyon

Bh apparemment , mon maitre de stage ne veux pas la méthode des leds , et s'en fou des résultats que j'ai trouvé , et dit que ca doit marcher même en asynchrone,et propose a la place du SPI de remplir les buffer manuellement et de les envoyer comme le faisait le SPI .

Il a eu son diplôme la semaine dernière, ton maître de stage, ou alors il s'est reconverti récemment depuis la charcuterie en gros ?
Les leds, c'est juste un moyen simple de trigger vers l'extérieur, si ça ne lui plait pas, connecte directement un GPIO pour faire les mesures, ça reviendra au même.

En attendant, sans un thread dédié à l'envoi TCP/IP, cela ne marchera jamais. Il peut tripoter le code dans tous les sens qu'il veut, mais vouloir émettre 1000 paquets TCP/IP (surtout qu'ils feront 64 octets à tout casser !!) par SECONDE avec un µC à 96 MHz tout en gardant une acquisition synchrone et régulière SANS la mettre sous IT, c'est de la simple bêtise. Cela ne peut en aucun cas marcher : OK, le temps CPU disponible en dehors des acquisitions SPI est suffisant pour gérer des envois TCP/IP, mais pas n'importe comment.

A se demander s'il a déjà fait du logiciel bas niveau embarqué, d'ailleurs, le debug aux leds, c'est un très grand classique pour surveiller ce genre de choses...

Citation:

Envoyé par ens-lyon

La méthode des leds ne nous permettra pas de voir si les données sont perdues , d'après lui.8O

La source des données SPI possède un buffer ? Si la réponse est "non", alors tu en perdras, la preuve avec les "plateaux" que tu as obtenu.
09/09/2009, 13h48
ens-lyon

Citation:

Envoyé par ens-lyon

Bh apparemment , mon maitre de stage ne veux pas la méthode des leds , et s'en fou des résultats que j'ai trouvé , et dit que ca doit marcher même en asynchrone,et propose a la place du SPI de remplir les buffer manuellement et de les envoyer comme le faisait le SPI .

La méthode des leds ne nous permettra pas de voir si les données sont perdues , d'après lui.8O

Effectivement quand j'ai fait le test avec des buffer que je rempli et j'envoi , je reçois mes données sans perte?c'est pas contradictoire avec le test que j'ai fait avec les leds , et qui montre que le send bloc un moment ou trop lent???
09/09/2009, 13h53
Mac LAK

Citation:

Envoyé par ens-lyon

Effectivement quand j'ai fait le test avec des buffer que je rempli et j'envoi , je reçois mes données sans perte?c'est pas contradictoire avec le test que j'ai fait avec les leds , et qui montre que le send bloc un moment ou trop lent???

Ton send() bloque presque à coup sûr à cause du trop grand nombre de paquets émis par seconde. Problème aisément résolu via l'envoi d'un gros paquet contenant plusieurs acquisitions (disons de 150 acquisitions, donc) au lieu de plein d'envoi d'acquisitions unitaires.
Le problème en envoyant un "gros" paquet, c'est qu'il n'est pas certain que ça puisse se faire dans les 800 µs disponibles entre deux acquisitions SPI, d'où le threading de cette étape afin de le garantir.

Reste à savoir ce que tu veux dire par "des buffers comme le faisait le SPI"... Rappelles-toi que je n'ai pas les datasheet de tes trucs sous les yeux, moi, je ne sais même pas ce que tu acquiert par le SPI ! ;)

bh en fait ce que je fait j'envoi des donnes dans des buffer de 8 bytes que je recupere cote client. voila le code .

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
 
if (T->Established() == 1)
   	{
         switch(i)
         {  //remplir le buffer
                case 1 :
                {
                 remplir(data,"testdat1");
                 remplir(data+8,"ens-lyo1");
                 remplir(data+16,"12345671");
                 break;
                }
               case 2 :
                      {
                       remplir(data,"testdat2");
                       remplir(data+8,"ens-lyo2");
                       remplir(data+16,"12345672");
                       break;
 
                      }
               case 3 :
                      {
                       remplir(data,"testdat3");
                       remplir(data+8,"ens-lyo3");
                       remplir(data+16,"12345673");
                       break;
                      }
 
            }
           T->Send(data,24);
           i++;
           if(i==4)
           i=1;
 
 
 
      }

Donc a chaque fois j'envoie des donnes différentes , les donnes arrivent dans l'ordre et sans perte, la seule chose qui change avec le SPI c'est que c'est moi qui rempli manuellement les buffer .

Alors ce test veu dire que le TCP/IP ne cause aucun probleme.????:roll:

09/09/2009, 14h41
Mac LAK

Citation:

Envoyé par ens-lyon

Donc a chaque fois j'envoie des donnes différentes , les donnes arrivent dans l'ordre et sans perte, la seule chose qui change avec le SPI c'est que c'est moi qui rempli manuellement les buffer .

Bien sûr qu'elles arrivent, dans l'ordre et sans pertes, ça c'est garanti par TCP/IP... Et tu n'as pas, dedans, les indications d'un blocage éventuel de ton send() non plus ! ;)

Citation:

Envoyé par ens-lyon

Alors ce test veu dire que le TCP/IP ne cause aucun probleme.????:roll:

En lui-même, non, mais dans le bout de code que tu montres, tu ne fais rien d'autre : pas de contraintes temporelles comme tu en as avec l'acquisition SPI, et pas de problèmes de mixage synchrone/asynchrone...

C'est le test que tu viens de faire qui n'est pas représentatif, c'est tout.
09/09/2009, 14h52
ens-lyon

Citation:

Bien sûr qu'elles arrivent, dans l'ordre et sans pertes, ça c'est garanti par TCP/IP

C'est ce que je me disais aussi.

Citation:

mais dans le bout de code que tu montres, tu ne fais rien d'autre : pas de contraintes temporelles comme tu en as avec l'acquisition SPI, et pas de problèmes de mixage synchrone/asynchrone...

Comment convaincre le, maitre de stage que son test ne sert a rien??? s'il dit qu'on s'en fou si c'est asynchrone et que ca doit fonctionner meme en asynchrone???:furieux:
09/09/2009, 15h18
Mac LAK

Citation:

Envoyé par ens-lyon

Comment convaincre le, maitre de stage que son test ne sert a rien??? s'il dit qu'on s'en fou si c'est asynchrone et que ca doit fonctionner meme en asynchrone???:furieux:

S'il n'est pas capable de comprendre que l'on peut mesurer le temps d'exécution d'une fonction via un trigger sur un GPIO, donnée mesurable via un oscilloscope, c'est peine perdue.
Or, il est quasiment garanti que ton send(), à un moment où à un autre, prendra plus de 800 µs pour s'exécuter (dû à sa nature asynchrone, justement).

Mais il n'y a pas le choix : soit tu mets ton acquisition SPI sous interruption matérielle, soit ton send() en thread de priorité moins élevée que l'acquisition SPI, l'idéal étant de faire les deux.

Au pire, fais-lui lire ce sujet directement...
09/09/2009, 15h51
ens-lyon

Ah oups j'ai vu que pour une simulation plus longue , genre je tourne mon client avec une boucle de i =[0..50000] , le premier fichier qui contient le premier buffer ne contien aucune erreur , par contre le deuxieme fichier et le troisieme bloque a un certain moment sur une valeur donne du buffer .

Pourquoi ca se produit pas pour le premier buffer ce blocage ???normalement tu a di il doit pas y avoir de perte ainsi ou de blocage dans ce cas??8O
09/09/2009, 16h11
Mac LAK

Heu, pas tout pigé, là, c'est pas super clair ton dernier message... :?
09/09/2009, 16h32
ens-lyon

Je disai que quand j'envoi un buffer de donne , et que je tourne la reception avec une boucle for , de i : 1->40000 par exemple , j'ai dans mes fichier de donnes :

12345671
12345672
12345673
.
.
12345672
12345672
.
.

j'ai une répétition de la séquence 12345672 , alors que normalement si il ya pas de perte je dois pas l'avoir.non???,
09/09/2009, 16h35
Mac LAK

Citation:

Envoyé par ens-lyon

j'ai une répétition de la séquence 12345672 , alors que normalement si il ya pas de perte je dois pas l'avoir.non???,

Normalement, non, en effet, ce qui veut peut-être dire aussi que ta stack TCP/IP possède un bug que tu déclenches en balançant trop de trames... Comme je te l'ai dit, TCP/IP n'est pas idéal pour balancer des tonnes de toutes petites trames, c'est UDP qui est "taillé" pour ça.
D'où la construction de plus grosses trames que je te conseillais.
09/09/2009, 17h38
ens-lyon

Citation:

Or, il est quasiment garanti que ton send(), à un moment où à un autre, prendra plus de 800 µs pour s'exécuter (dû à sa nature asynchrone, justement).

tu peux m'expliquer d'une facon rationnelle pourquoi il prendra plus que 800 us???
09/09/2009, 18h20
Mac LAK

Citation:

Envoyé par ens-lyon

tu peux m'expliquer d'une facon rationnelle pourquoi il prendra plus que 800 us???

Parce que c'est asynchrone côté stack : il suffit que les buffers internes de la stack soient pleins, et en attente d'un ACK TCP/IP pour continuer les envois, et t'as un send() bloqué et/ou des écrasement de données.

Sur un PC "normal", avec un OS classique (Windows, Linux, etc.), l'écrasement de données est impossible (ça se serait vu, depuis le temps...). Par contre, le blocage est tout à fait possible, même si c'est extrêmement rare au vu des performances relatives des machines.
La seule différence, c'est que c'est quelque chose de non pénalisant sur ce genre de machine, qui ne diffère le send() que de quelques millisecondes, alors que sur ton µC, c'est nettement plus critique bien sûr : tu ne peux pas te permettre d'être bloqué plus de 800 µs, ni de perdre des données (et ta stack de µC possède manifestement un bug à ce niveau).

Voir 40 message(s) de cette discussion en une page