Temps de transfert de données en TCP
Cyborg
-
cyborg -
cyborg -
Bonjour,
je suis en train de développer un système permettant de récupérer convertir des signaux analogiques d'un module vers un ordinateur via un câble ethernet.
un microcontroleur s'occupe de la conversion analogique/numérique, et un module wiznet de la transformation des données en paquet sur protocole TCP.
Mon problème est que les données sont envoyées du module vers le serveur toutes les 40ms, ce qui est nettement insuffisant. J'aimerais savoir quel est le temps entre l'envoi de 2 trames de données (client-serveur) ? En gros, est ce qu'il y a un délai incompressible entre 2 trames successives ?
J'espère être assez clair dans ma démarche. D'avance, merci de vos réponses.
Cordialement,
Cyb
je suis en train de développer un système permettant de récupérer convertir des signaux analogiques d'un module vers un ordinateur via un câble ethernet.
un microcontroleur s'occupe de la conversion analogique/numérique, et un module wiznet de la transformation des données en paquet sur protocole TCP.
Mon problème est que les données sont envoyées du module vers le serveur toutes les 40ms, ce qui est nettement insuffisant. J'aimerais savoir quel est le temps entre l'envoi de 2 trames de données (client-serveur) ? En gros, est ce qu'il y a un délai incompressible entre 2 trames successives ?
J'espère être assez clair dans ma démarche. D'avance, merci de vos réponses.
Cordialement,
Cyb
A voir également:
- Temps de transfert de données en TCP
- Fuite données maif - Guide
- Tcp udp - Guide
- Tcp optimizer - Télécharger - Optimisation
- Renommer plusieurs fichiers en même temps - Guide
- Supprimer les données de navigation - Guide
3 réponses
Salut,
Je ne connais pas ce module wiznet mais il attend certainement d'avoir un paquet entier avant de l'envoyer, donc voir si tu peux diminuer la taille de ce paquet.
Par exemple, regarde si tu peux réduire la MTU sur ton module.
Je ne connais pas ce module wiznet mais il attend certainement d'avoir un paquet entier avant de l'envoyer, donc voir si tu peux diminuer la taille de ce paquet.
Par exemple, regarde si tu peux réduire la MTU sur ton module.
Salut,
Je viens de remarquer que le module attend 70ms entre le ACK du serveur et l'envoie de la prochaine trame. Le MTU n'est pas réglable.
Par contre, le débit est meilleur si le paquet de données est plus grand. Ces 70ms étant largement supérieur au temps d'envoie de beaucoup d'octets.
Je passe de 0,003Mb/s avec une trame de 25 octets à envoyer, à 0,25Mb/s avec une trame de 2040 octets. Seul ce délai de 70ms me plombe le débit.
Bien entendu, c'est bien loin du débit attendu.
Cyb
Je viens de remarquer que le module attend 70ms entre le ACK du serveur et l'envoie de la prochaine trame. Le MTU n'est pas réglable.
Par contre, le débit est meilleur si le paquet de données est plus grand. Ces 70ms étant largement supérieur au temps d'envoie de beaucoup d'octets.
Je passe de 0,003Mb/s avec une trame de 25 octets à envoyer, à 0,25Mb/s avec une trame de 2040 octets. Seul ce délai de 70ms me plombe le débit.
Bien entendu, c'est bien loin du débit attendu.
Cyb
Le retard entre deux trame, du client vers le serveur est constant, et de 70ms.
Le cheminement est le suivant :
client : PSH + ACK + 1460 octets de donnees
PSH + ACK + 58 octets de données restant
serveur : ACK
70ms de tempo, puis rebelote.
Le module fonctionne effectivement en UDP, mais ce qui me plait dans le TCP c'est justement le contrôle du flux, car j'envoie des donnees provenant d'un CAN pour être afficher sur le pc sous forme d'oscilloscope.
Le cheminement est le suivant :
client : PSH + ACK + 1460 octets de donnees
PSH + ACK + 58 octets de données restant
serveur : ACK
70ms de tempo, puis rebelote.
Le module fonctionne effectivement en UDP, mais ce qui me plait dans le TCP c'est justement le contrôle du flux, car j'envoie des donnees provenant d'un CAN pour être afficher sur le pc sous forme d'oscilloscope.
Pour avoir un meilleur contrôle sur les données envoyées, rien n'empêche d'implémenter son propre contrôle de flux en UDP. (c'est d'ailleurs comme ça que marche le tftp, sip/udp, ...)
Mais dans ce cas il faut que tu puisses écrire les données nécessaires pour le gérer.
Sinon je crois que tu vas devoir choisir entre ce temps de latence ou l'absence de contrôle de flux.
Personnellement je choisirais l'UDP si tu es sur un réseau local car c'est rare d'y perdre des données, tu as plus de chances que ce soit ton CAN qui soit perturbé en premier par des interférences (regarde les flux audio en rtp par exemple).
A moins que tu ne trouves d'autres options pour diminuer ce temps en TCP.
Mais dans ce cas il faut que tu puisses écrire les données nécessaires pour le gérer.
Sinon je crois que tu vas devoir choisir entre ce temps de latence ou l'absence de contrôle de flux.
Personnellement je choisirais l'UDP si tu es sur un réseau local car c'est rare d'y perdre des données, tu as plus de chances que ce soit ton CAN qui soit perturbé en premier par des interférences (regarde les flux audio en rtp par exemple).
A moins que tu ne trouves d'autres options pour diminuer ce temps en TCP.
