Quel est le délai pour TCP / UDP?

Question

HELP PLEASE! J'ai une application qui nécessite un traitement aussi proche que possible du temps réel et je continue de rencontrer ce problème de délai inhabituel avec TCP et UDP. Le retard se produit comme sur des roulettes et c'est toujours la même durée (généralement 15 à 16 ms). Cela se produit lors de la transmission vers une machine (même locale) et sur un réseau (nous en avons deux).

Résumé du problème:

J'utilise toujours winsock en C ++, compilé dans VS 2008 Pro, mais j'ai écrit plusieurs programmes pour envoyer et recevoir de différentes manières à l'aide de TCP et d'UDP. J'utilise toujours un programme intermédiaire (exécuté localement ou à distance) écrit dans différents langages (MATLAB, C #, C ++) pour transférer les informations d'un programme à l'autre. Les deux programmes WinSock s'exécutent sur le même ordinateur, de sorte qu'ils affichent les horodatages de Tx et Rx à partir de la même horloge. Je continue de voir apparaître un motif où une rafale de paquets est transmise, puis un délai d’environ 15 à 16 millisecondes s’écoule avant que la prochaine rafale ne soit programmée. Parfois, il peut s'écouler 15 à 16 ms entre chaque paquet au lieu de une rafale de paquets. D'autres fois (rarement) j'aurai un retard de longueur différent, tel que ~ 47 ms. Il me semble toujours que les paquets sont renvoyés dans la milliseconde, même si le même type de retard est observé entre les rafales transmises.

Je soupçonne WinSock ou la carte réseau de stocker les paquets en mémoire tampon avant chaque transmission, mais je n’ai trouvé aucune preuve. J'ai une connexion Gigabit à un réseau qui reçoit différents niveaux de trafic, mais je rencontre également la même chose lorsque je lance le programme intermédiaire sur un cluster disposant d'un réseau privé sans trafic (de la part des utilisateurs au moins) et d'une connexion de 2 Gigabit. Je vais même faire l'expérience de ce délai lors de l'exécution locale du programme intermédiaire avec les programmes d'envoi et de réception.

Answer 1

J'ai découvert le problème ce matin en réécrivant le serveur en Java. La résolution de mon horloge système Windows est comprise entre 15 et 16 millisecondes. Cela signifie que chaque paquet qui affiche la même milliseconde que son heure de transmission est effectivement envoyé à différentes millisecondes dans un intervalle de 16 millisecondes, mais que mon horodatage n’incrémente que toutes les 15 à 16 millisecondes pour qu’elles soient identiques.

Je suis venu ici pour répondre à ma question et j'ai vu la réponse à propos de l'augmentation de la priorité de mon programme. J'ai donc démarré les trois programmes, suis entré dans le gestionnaire de tâches, j'ai élevé les trois en "temps réel". priorité (ce qu’aucun autre processus n’était) et les a exécutées. J'ai les mêmes intervalles de 15 à 16 millisecondes.

Merci pour les réponses cependant.

Answer 2

La mise en mémoire tampon est toujours impliquée et varie selon le matériel, les pilotes, le système d'exploitation, etc. Les ordonnanceurs de paquets jouent également un rôle important.

Si vous voulez "dur en temps réel" garanties, vous devriez probablement rester à l’écart de Windows ...

Answer 3

Ce que vous voyez probablement est un retard du planificateur - votre application attend que d'autres processus aient terminé leur tranche de temps et abandonnent le processeur. Les tranches de temps standard sous Windows multiprocesseurs vont de 15 ms à 180 ms.

Vous pouvez essayer d'augmenter la priorité de votre application / thread.

Answer 4

Oh oui, je sais ce que tu veux dire. Windows et ses tampons ... essayez d'ajuster les valeurs de SO_SNDBUF de l'expéditeur et SO_RCVBUF du côté du destinataire. Vérifiez également le matériel réseau impliqué (routeurs, commutateurs, passerelles multimédias) - éliminez-en le plus possible entre les ordinateurs pour éviter le temps de latence.