2009-10-27 6 views
3

AIDE SVP! J'ai une application qui doit être aussi proche que possible du traitement en temps réel et je continue à courir dans 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 (la plupart du temps entre 15 et 16 ms). Cela se produit lors de la transmission à n'importe quelle machine (veille locale) et sur n'importe quel réseau (nous en avons deux).Quel est le délai pour en TCP/UDP?

Un rapide résumé du problème:

J'utilise toujours winsock en C++, compilé dans VS 2008 Pro, mais je l'ai écrit plusieurs programmes pour envoyer et recevoir de diverses manières à l'aide de TCP et UDP. J'utilise toujours un programme intermédiaire (s'exécutant localement ou à distance) écrit en plusieurs langues (MATLAB, C#, C++) pour transmettre les informations d'un programme à l'autre. Les deux programmes winsock fonctionnent sur la même machine, de sorte qu'ils affichent des horodatages pour Tx et Rx à partir de la même horloge. Je continue à voir apparaître un schéma où une rafale de paquets sera transmise et il y a un retard d'environ 15 à 16 millisecondes avant la prochaine rafale, sans retard programmé. Parfois, il peut y avoir 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, comme ~ 47 ms. J'ai toujours l'impression de recevoir les paquets à l'intérieur d'une milliseconde d'entre eux étant transmis avec le même motif de retard étant exposé entre les rafales transmises.

Je soupçonne que winsock ou la carte réseau est en train de tamponner des paquets 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 ressens la même chose lors de l'exécution du programme intermédiaire sur un cluster qui a un réseau privé sans trafic (des utilisateurs au moins) et une connexion 2 Gigabit. Je vais même éprouver ce retard en exécutant le programme intermédiaire localement avec les programmes d'envoi et de réception.

+0

Si vous avez besoin de "temps réel", avez-vous envisagé d'utiliser un système d'exploitation en temps réel? –

+0

Les décisions ont été prises avant que j'aie été employé ici et ils ont déjà un cluster de 100k $ et plus qui fonctionne sous Windows Compute Cluster. Si je devais choisir, je supprimerais le cluster et exécuterais les calculs sur une seule machine à quatre processeurs, donc aucune communication réseau ne serait nécessaire. – ACE2100

Répondre

4

J'ai trouvé 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 en fait envoyé à différentes millisecondes dans un intervalle de 16 millisecondes, mais mes horodatages ne sont incrémentés que tous les 15 à 16 millisecondes pour qu'ils paraissent 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 commencé les trois programmes, je suis entré dans le gestionnaire de tâches, j'ai élevé les trois à la priorité «en temps réel» (ce qui n'était pas le cas d'autres processus) et je les ai exécutés. J'ai les mêmes intervalles de 15 à 16 millisecondes.

Merci pour les réponses cependant.

+1

vous pouvez utiliser la méthode QueryPerformanceCounter (Chronomètre dans .Net), pour obtenir une meilleure précision (implémentée par le matériel) de Windows) –

2

Il y a toujours un tampon impliqué et il varie entre le matériel/drivers/os etc. Les planificateurs de paquets jouent également un grand rôle.

Si vous voulez « dur en temps réel » garanties, vous devriez probablement rester à l'écart à partir de Windows ...

+2

Gardez à l'esprit que, dans la plupart des cas, un délai de 15 ms passera inaperçu. J'ai un ping 40ms à mon FAI, et ne remarque pas de problèmes même quand cela double. Un système d'exploitation conçu pour une utilisation bureautique, comme Windows ou Mac OSX, n'a pas à s'inquiéter des retards si petits. Je suis tout à fait d'accord avec jldupont: si un délai de 15 ms est un problème, il faut vraiment trouver un OS conçu pour une utilisation en temps réel, car le temps réel doux ne le coupe pas pour vous. ("Temps réel" = tout fonctionne assez vite, "temps réel dur" = le système garantit des tranches de temps.) –

0

Qu'est-ce que vous voyez probablement est un retard de planificateur - votre demande est en attente d'autres processus (s) pour finir leur temps et abandonner le CPU. Les durées standard sur Windows multiprocesseur sont de 15ms à 180ms.

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

0

Oh oui, je sais ce que vous voulez dire. Windows et ses tampons ... essayez d'ajuster les valeurs de SO_SNDBUF sur l'expéditeur et SO_RCVBUF sur le côté receveur. Vérifiez également le matériel de mise en réseau impliqué (routeurs, commutateurs, passerelles multimédias) - éliminez autant que possible entre les machines pour éviter la latence.

Questions connexes