Linux Realtime und Applikation Netzwerkzugriff

[mekakic]

Hi... ich dachte hier passt es besser als im Linux oder Netzwerk Forum: Ich lese mich gerade in Linux Realtime Lösungen ein (genauer RtLinux und RTAI, wobei letzteres interessanter klingt) um herauszubekommen, ob man ohne teure Embedded RT-OS eine ausreichende Echtzeitfähigkeit bekommen kann, wenn man auf den Zugriff auf ein Netzwerkinterface angewiesen ist.

Ich möchte eine Anwendung erstellen, die aus einem eingehenden UDP Paket einer unidirektionale Punkt-zu-Punkt Ethernet Verbindung mit zeitlich abschätzbarer Obergrenze reagieren kann. Um Beispielsweise im Bereich von 10-20ms nach Eingang des Pakets immer reagiert zu haben; dann wäre es akzeptabel. Das Problem ist, wenn es durch eine IRQ Behandlung o.ä. mal deutlich länger dauert, dann kann eine Reaktion u.U. schädlich sein; bei 100ms fährt das Auto vielleicht in den Graben... zum Beispiel :)

Zu >99% wird das vermutlich jede Desktop Lösung hinkriegen, aber es geht eher um die nicht >99%. Wenn ich jetzt eine RTAI Anwendung auf einem Linux mit entsprechend gepatchtem Kernel ausführe, wie wird dieser Echtzeitprozeß denn beeinflusst, wenn er auf eine Hardware mit Treibern zugreift, die nicht für den Echtzeitbetrieb gemacht wurden? Kann das noch funktionieren? Oder ist der einzige Realtime Ansatz durch Ausmaskieren der Interrupts, während der RT Prozess seine CPU Zeit hat, bereits erreicht? Oder muß auch Netzwerkinterface und Treiber den RT Anforderungen gerecht werden?

Hat jemand Erfahrungen damit und eignet sich RTAI prinzipiell dafür? Neben dem Zugriff aufs Netzwerkinterface, müsste man auch auf ein anderes PCI Gerät zugreifen, aber dafür wird wahrscheinlich das gleiche gelten. Danke! :)

[TongPo]

wenn du wirklich echtzeitfähigkiet brauchst, dann solltest du vielleicht ein echtzeit-OS wie QNX in betracht ziehen. ich hab damit vor jahren mal ein wenig rumgespielt und es war relativ unix/linux ähnlich.

mit RTLinux oder RTAI hab ich aber noch keine erfahrung sammeln können.

[mekakic]

Danke. Aber das ist ein Studentenprojekt... unkommerziell ist da immer gut und Linux war explizit gewünscht.

[Ganon]

Also wenn das Paket beim OS-Kern landet, dann ist das ja schon an sämtlicher Netzwerkhardware vorbei. Je nachdem was für Hardware/Firmware/Treiber Switches/Hubs/sonstige Steuerungen kann das reine Ankommen des Pakets schon eine Weile dauern. Das RT OS wird dir aber nur Garantien für alles DANACH geben. Weil wenn die Firmware in der NIC irgendwelchen Mist macht, dann weiß das OS davon u.U. nichts.

D.h. wenn deine Kommunikation im Auto über Standard-Ethernet läuft, bringt dir ein RT OS so nicht in allen Fällen etwas. Klar, das OS wird im entsprechenden Zeitrahmen reagieren, aber je nachdem was davor oder danach passiert/passieren soll, kann das das RT schon wieder zum Einstürzen bringen.

Nicht umsonst gibt es für Steuerungen und Co. entsprechendes Industrial Ethernet in unterschiedlichsten Kategorien (PROFInet Class A / B / C z.B.).

[TongPo]

Danke. Aber das ist ein Studentenprojekt... unkommerziell ist da immer gut und Linux war explizit gewünscht.

ahso, na dann nimm ein linux mit echtzeiterweiterung. wenn du dazu noch die unterschiede zu einer richtigen echtzeitverarbeitung erklären kannst (und daraus folgend die wahl für deine lösung), dann solltest du auf der sicheren seite sein.

btw: QNX ist für sowas kostenlos. allerdings bleibt auch damit das problem, das Ganon schon angeführt hat. zur laufzeit zählen auch die netzwerkschichten, ethernet controller und treiber (falls der nicht echtzeittauglich ist). was nützt dir eine garantierte bearbeitung in 10-20ms deines betreibsystems, wenn das udp paket möglicherweise schon 50 ms auf dem ethernetkabel verloren hat?