J'ai une source qui envoie des paquets UDP à une vitesse de 819,2 Hz (~ 1.2ms) à ma machine à neutrino QNX. Je veux recevoir et traiter ces messages avec aussi peu de retard et de gigue que possible.
Mon premier code était fondamentalement: P>
wm1:
INTEL 82544 Gigabit (Copper) Ethernet Controller
Physical Node ID ........................... 000E0C C5F6DD
Current Physical Node ID ................... 000E0C C5F6DD
Current Operation Rate ..................... 100.00 Mb/s full-duplex
Active Interface Type ...................... MII
Active PHY address ....................... 0
Maximum Transmittable data Unit ............ 1500
Maximum Receivable data Unit ............... 0
Hardware Interrupt ......................... 0x5
Memory Aperture ............................ 0xfebc0000 - 0xfebdffff
Promiscuous Mode ........................... Off
Multicast Support .......................... Enabled
4 Réponses :
Quelle est la taille de vos paquets UDP? Si la taille du paquet est faible, vous obtiendrez une plus grande efficacité en emballant plus de données en un seul paquet et en diminuant le taux de transmission.
Je soupçonne que le routage de service d'interruption (ISR) ne masque pas l'interruption. Peut-être est-il conçu pour la sensibilité des bords et l'interruption est sensible au niveau.
Je ne suis pas sûr de savoir pourquoi la déclaration "Le problème est que RECV () uniquement vérifie à chaque ticket de la minuterie du système s'il existe un nouveau paquet disponible. La tick TIMER est généralement de 1 ms." serait vrai pour le système d'exploitation préventif. Il doit y avoir quelque chose dans la configuration système ou la mise en œuvre de la pile de protocoles réseau a des problèmes.
Il y a des années lorsque je travaillais sur un projet IPTV STB pour Yahoo BB Japan, j'ai eu un problème dans la réception de RTP. Les problèmes ne sont ni retardés ni gigants, mais la performance globale du système dans la STB après avoir ajouté un algorithme NDS. Nous utilisons Vxworks et Vxworks Prise en charge d'une interface crochet Ethernet, qui sera appelée chaque fois qu'un paquet Ethernet est reçu par le pilote.
Je manque une API dans celle-ci et simplement analyser l'UDP avec un port spécifié des paquets Ethernet directement. Bien sûr, nous avons une hypothèse qu'il n'y a pas de fragmentation, qui est garantie par la configuration du réseau pour les problèmes de performance. Vous pouvez également vérifier si vous pouvez obtenir le même crochet dans le pilote Ethernet QNX. Au bail, vous avez découvert si la gigue vient du conducteur ou non.
Désolé je suis un peu en retard à la fête, mais je suis tombé sur votre question et j'ai vu que c'était semblable à une situation que j'ai rencontrée. Au lieu d'interruptions matérielles, vous pouvez essayer une interruption logicielle à l'aide de signaux. QNX a une documentation ici: http: // www .qnx.com / Développeurs / DOCS / QNX_4.25_DOCS / QNX4 / SYSARCH / MICROKERNEL.HTML # IPCSIGNALS . J'utilisais Centos à l'époque, mais la théorie est la même. Selon http://www.qnx.com /Developers/docs/6.3.0SP3/neutrino/lib_ref/s/socket.html Vous pouvez utiliser iOCTL () pour configurer un groupe de réception pour le signal SIGIO pour un descripteur de fichier donné ... dans votre cas A Prise UDP. Lorsque la prise dispose de données prêtes à lire, un signal SIGIO est envoyé au processus indiqué par IOCTL (). Utilisez SIGRACTION () pour indiquer à l'OS quelle fonction de traitement du signal à utiliser. Dans votre cas, le gestionnaire de signal peut lire les données de la prise et la stocker dans un tampon pour le traitement. Utilisez Pause () pour suspendre le processus jusqu'à ce qu'il gère le signal Sigio. Lorsque le gestionnaire de signal revient, le processus se réveillera et vous pouvez traiter les données dans le tampon. Cela devrait vous permettre de traiter vos données telles qu'elles entrent sans avoir à gérer les minuteries ou les interruptions matérielles. Une chose à prendre conscience est que votre système peut traiter ces signaux aussi rapidement que le trafic UDP arrive.
«Le problème est que RECV () uniquement chèques à chaque ticket de la minuterie du système s'il existe un nouveau paquet disponible» - Pourquoi cela ferait-il cela? Je ne sais pas de QNX, - Le pilote de réseau ne fonctionne-t-il pas? Le pilote d'interruption doit définir un événement / un sémaphore et une sortie via le système d'exploitation afin de pouvoir définir le thread RECV () immédiatement 'immédiatement'. Il ne devrait pas y avoir besoin de "attendre tache de minuterie" - c'est juste sans espoir - pourrait aussi bien utiliser une boucle de vote coopérative :(
Les détails de la mise en œuvre comme Martin mentionné peuvent varier avec le pilote et même un modèle de carte spécifique, mais vous n'avez pas non plus répertorié.
@Martinjames et Ben Voigt: Désolé, je n'étais pas au courant du fait que mon problème pourrait être lié au conducteur. "Nicinfo" dit "Contrôleur Ethernet Gigabit (cuivre) Intel 82544" et "Sorties" PCI -VVV '"Vendeur ID = 8086H, Intel Corporation Device ID = 107CH, 82541PI Gigabit Controller Ethernet"
Est-ce utile (ou même possible) à l'horodatage des paquets de la source afin de ne pas avoir besoin de compter sur le chronométrage de la réception du paquet? Et si vous faites une attente occupée en utilisant
msg_peek au lieu demsg_waitall ?L'interruption est-elle sensible au bord ou sensible au niveau?