Discussion :

[doommick31]

Bonjour,
Voilà je réalise une application en c avec laquelle je doit mesurer des débits. Je souhaite faire quelque chose qui resemble un peu au débit que l'on voit dans emule ou un client torrent comme azureus. J'aimerai savoir comment cela marche et qu'elle est le principe de fonctionnement de ces débits.

J'ai essayer pour ma part de faire ceci pour vous expliquer un peu le principe:
1° capture de temp
nRead = receive de mon socket
2° capture de temp
mon débit est égale à = nRead / (2° - 1°)

Le problème avec c'est façon de faire dépend de la résolution de la fonction qui capture le temp. Il m'arrive tout le temps d'avoir (2°-1°) = 0 car je reçoit tres peu de données. C'est pourquoi j'aimerai savoir comment fait la mule ou autre pour donner un débit moyen et/ou instantanée.

Merci d'avance pour votre aide.

[psyphi]

Moi je verrais le truc comme ca:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
 
Server         Client
------         ------
                initialize sizeToSend
:1             time1
wait          send file
recv file     wait
end recv    wait
send ok     time2
goto 1       speed = sizeSend / (time2 - time1)

Ensuite la moyenne pourrait etre calculé comme suit: (calcul peut précis)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
 
if(mean == 0)
        mean = speed;
else{
        mean += speed;
        mean /= 2;
}

Pour calculer la vitesse moyenne, ce serait peut etre plus réaliste de mettre en mémoire plusieurs vitesses par exemple 10 et ensuite de faire leur moyenne.

De plus pour avoir une vitesse réaliste il faut envoyer de gros fichier, il faudrait faire varier leur taille entre 100kB et 1MB.

[doommick31]

oulala oulala 100kB à 1MB, je ne peut pas générer autant de données. Les trames que j'envoie font a tout cassé 20 à grand maxi 30 octets. De plus je souhaite pouvoir avoir un débit d'un flux de donnée en temp réel. De plus si je vous dit que je fait des mesures depuis un module GPRS (c'est à dire que l'on paye au volume de données 5Mo = 5 euro), on a vite fait de changer de carte sim.

N'y a t'il pas un autre moyen de procéder pour faire ces mesures? Merci.

[Ksempac]

20 ou 30 octets ? On est pas du tout dans les memes cas d'utilisation que ceux que tu cites alors.

Tu as vu ce que te font les programmes que tu cites au depart (les premieres secondes, voir la premiere minute) ? Ou meme ton navigateur quand tu demarres un telechargement ? Ils t'indiquent des valeurs fantaisistes qui peu a peu convergent vers la valeur reelle. Et pourtant ils fonctionnent sur des lignes 56K, 512K voir plus, donc en quelques secondes ils ont envoyés bien plus que 20 ou 30 octets !

Franchement j'ai du mal a voir comment tu veux calculer un débit avec des messages de 20 ou 30 octets...J'ignore la vitesse d'un lien GPRS mais c'est surement bien plus rapide que 20B/s (impossible de faire de la communication vocale en 20B/s) donc le temps que tu demarres ta mesure, c'est quasiment deja fini.

Quelle est l'utilité de cette mesure ? Peut etre y a t il un autre moyen de faire ce que tu souhaites

[doommick31]

Le but de mon programme est plutôt simple, j'ai une trame de données 20 à 30 octets (dedans il y a divers paramètre provenant d'un bus CAN ). J'envoie de manière répété cette trame au travers de socket pour avoir un flux de donnée en temps réel. Et je cherche a avoir le débit de ce flux de données. Comme je travail avec du GRPS, connaître le débit est important suivant ou se trouve le module GPRS.

voici un peu le principe de mon débit :
do
1° capture ma trame
2° je l'envoie
while (tant que j'ai pas dit stop)

et c'est à la réception que je veut pouvoir avoir le débit réel et/ou moyen

En tout cas merci de votre aide

[souviron34]

eh ben dans ton message envoyé tu ajoutes le timestamp d'envoi....

Tu as donc 2 parties dans ton message :

timestamp
trame

quand tu lis, tu décodes, et tu fais la différence avec le timestamp d'envoi..

Mais vu la granularité du temps et la vitesse des réseaux et la petite taille de tes paquets, ça va t'obliger à coder un timestamp au moins à la milliseconde, mais plus vraisemblablement à la microseconde...