Ich habe eine Quelle, die UDP-Pakete mit einer Rate von 819,2 Hz (~ 1,2ms) an meine QNX-Neutrino-Maschine sendet. Ich möchte diese Nachrichten mit möglichst wenig Verzögerung und Jitter empfangen und verarbeiten.
Mein erster Code war im Grunde:
%Vor%Das Problem ist, dass recv () nur bei jedem Tick des Systems prüft, ob ein neues Paket verfügbar ist. Der Timer Tick ist in der Regel 1ms. Also, wenn ich das benutze, werde ich einen riesigen Jitter bekommen, weil ich ein Paket alle 1 ms oder alle 2 ms verarbeite. Ich könnte die Größe der Timer-Ticks zurücksetzen, aber das würde das ganze System (und andere Timer von anderen Prozessen usw.) beeinflussen. Und ich würde immer noch einen Jitter haben, weil ich sicherlich nie genau die 819,2 Hz erreichen würde.
Also habe ich versucht, die Interrupt-Leitung der Netzwerkkarte (5) zu benutzen. Es scheint aber auch andere Dinge zu geben, die den Interrupt ansteigen lassen. Ich habe den folgenden Code benutzt:
%Vor%Dies führt zu einem einzigen erfolgreichen Lesevorgang am Anfang, gefolgt von Lesevorgängen mit 0 Byte Länge nach 0 Zeitüberschreitung. Es scheint, dass nach der InterruptUnmask (), die InterruptWait () überhaupt nicht warten, so dass es bereits einen neuen Interrupt (oder das gleiche?!) Geben muss.
Kann man so etwas mit der Interrupt-Leitung der Netzwerkkarte machen? Gibt es andere Möglichkeiten, die Pakete mit einer Rate von 819,2 Hz zu empfangen?
Einige Informationen zur Netzwerkkarte: 'pci -vvv' gibt aus:
%Vor%und 'nicinfo' Ausgänge:
%Vor%Danke fürs Lesen!
Ich bin mir nicht ganz sicher, warum die Anweisung "Das Problem ist, dass recv () nur bei jedem Tick des Systems prüft, ob ein neues Paket verfügbar ist. Der Timer tickt normalerweise 1 ms." würde für preemptive OS gelten. Es muss etwas in der Systemkonfiguration vorhanden sein oder die Implementierung des Netzwerkprotokollstapels hat einige Probleme.
Vor Jahren, als ich an einem IPTV STB-Projekt für Yahoo BB Japan arbeitete, bekam ich ein Problem beim Empfang von RTP. Die Probleme sind nicht Verzögerung oder Jitter, sondern die Gesamtsystemleistung in der STB, nachdem wir einen NDS-Algorithmus hinzugefügt haben. Wir verwenden vxWorks und vxWorks unterstützt die Ethernet-Hook-Schnittstelle, die jedes Mal aufgerufen wird, wenn ein Ethernet-Paket vom Treiber empfangen wird.
Ich hakte eine API hinein und parse den UDP mit dem angegebenen Port direkt von den Ethernet-Paketen. Natürlich gehen wir davon aus, dass es keine Fragmentierung gibt, die durch das Netzwerk-Setup für Performance-Probleme garantiert wird. Vielleicht können Sie auch prüfen, ob Sie den gleichen Haken im QNX-Ethernet-Treiber bekommen können. Sie haben herausgefunden, ob der Jitter vom Fahrer kommt oder nicht.
Ich vermute, dass das Interrupt Service Routing (ISR) den Interrupt nicht maskiert. Vielleicht ist es für Kantenempfindlichkeit ausgelegt und der Interrupt ist pegelempfindlich.
Entschuldigung, ich bin ein bisschen zu spät zur Party, aber ich bin auf Ihre Frage gestoßen und habe gesehen, dass es einer Situation ähnlich ist, der ich begegnet bin. Statt Hardware-Interrupts könnten Sie einen Software-Interrupt mit Signalen versuchen. QNX hat einige Dokumentation hier: Ссылка . Damals habe ich CentOS benutzt, aber die Theorie ist dieselbe. Laut Ссылка können Sie ioctl () zum Einrichten verwenden eine Empfangsgruppe für das SIGIO-Signal für einen bestimmten Dateideskriptor ... in Ihrem Fall einen UDP-Socket. Wenn der Socket über Daten verfügt, die zum Lesen bereit sind, wird ein SIGIO-Signal an den von ioctl () angegebenen Prozess gesendet. Verwenden Sie sigaction (), um dem Betriebssystem mitzuteilen, welche Signalverarbeitungsfunktion verwendet werden soll. In Ihrem Fall kann der Signal-Handler die Daten aus dem Socket lesen und zur Verarbeitung in einem Puffer speichern. Verwenden Sie pause (), um den Prozess bis zur Verarbeitung des SIGIO-Signals zu unterbrechen. Wenn der Signalhandler zurückkehrt, wird der Prozess aktiviert und Sie können die Daten im Puffer verarbeiten. Dies sollte es Ihnen ermöglichen, Ihre Daten so zu verarbeiten, wie sie kommen, ohne mit Timern oder Hardware-Interrupts umgehen zu müssen. Eine Sache zu beachten ist, dass Ihr System diese Signale so schnell verarbeiten kann, wie der UDP-Verkehr hereinkommt.