A voir également:
- Temps de transfert de données en TCP
- Udp vs tcp - Guide
- Blocage agriculteur carte en temps réel - Accueil - Transports & Cartes
- Tcp optimizer - Télécharger - Optimisation
- We transfert - Guide
- Renommer plusieurs fichiers en même temps - 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.