Probier mal Real Time LINUX, auch RTL. Dort kann man die Prioritaet der Prozesse definieren uns so das Verhalten ganau vorhersagen was beim normalen Linux nicht moeglich ist.
Ausserdem glaube ich gibt es einen patch fuer linux um prozesse real time laufen zu lassen.
Was moechtest du denn genau machen?

RTLinux ist eine feine Sache, sofern man sich ein bisschen damit herumspielt und das ganze vernünftig zum Laufen bekommt.

QNX ist auch ein RTOS und ist mittlerweile für den Privatgebrauch gratis verfügbar. Hab es allerdings nur kurz mal getestet. Lustig ist auch die eigene grafische Oberfläche und der ganze Heckmeck.

wie ist eigentlich so ein rtos im alltagsgebrauch? kann man da normale anwendungen laufen lassen, und welche unterschiede machen sich da bemerkbar? die gängige vorstellung, dass einfach alles gleich passiert, wird ja nur schwer zutreffen, oder?

lg michi

würd mich auch interessieren was das genau sein soll. klingt irrgendwie nach nuklearAngriffsSimulationsSystem oder sowas... (oder halt des mit die erdbeben oder dem wetter)

=)

Zitat von C++Redeemer

würd mich auch interessieren was das genau sein soll. klingt irrgendwie nach nuklearAngriffsSimulationsSystem oder sowas... (oder halt des mit die erdbeben oder dem wetter)

=)

naja normalerweise verwendet man so etwas in ubahnen, steuerungssystemen etc, wo man definitiv wissen muss, wie lange eine aktion dauert (zumindest ist das mein wissensstand). aber dass jemand so was auf seinem pc installiert hör ich zum 1. mal.

lg michi

ah die antwort kam aber schnell =)


na reicht es bei sowas nicht, in einem normalen OS einen prozess auf maximum priorität laufen zu lassen?!

Zitat von C++Redeemer

ah die antwort kam aber schnell =)


na reicht es bei sowas nicht, in einem normalen OS einen prozess auf maximum priorität laufen zu lassen?!

Fast is not real-time!, wies so schön heißt.

Es geht bei Echtzeitanwendungen immer darum, dass der worst case sich in Grenzen hält. Ethernet ist z.B. nicht geeignet für Echtzeitkommunikation, weil es zwar _meistens_ schnell ist, der worst case aber ziemlich böse ist. Bei einem RTOS müssen dementsprechend Antwortzeiten garantiert werden, was "normale" OSs nicht machen. Dazu kommen aber auch noch Synchronisations- und Schedulingprobleme. Wen es noch genauer interessiert, dem sei die VO Echtzeitsysteme am vmars empfohlen.

Zitat

Es geht bei Echtzeitanwendungen immer darum, dass der worst case sich in Grenzen hält.

Das würd ich so nicht sagen.
Ok, das ist nicht unwichtig bzw nice to have, aber noch wichtiger ist die *Berechenbarkeit* des worst case.
Also *beweisbare* garantierte Antwortzeiten.
Zumindest bei Hard-Realtime-Systems.
Ein HRS mit <=12 micro-secs Antwortzeit in 99.99999999%
ist unbrauchbar, eines mit *garantierten* 120 micro-secs sehrwohl, soferne das für die Applikation noch akzetabel ist.

Schon alleine das werben von RTLinux mit
* Hard real-time networking over Ethernet or FireWire (1394) ...
ist nicht sehr vertraunserweckend.
Ethernet und HRT ? wtf ?

Egal, will ned weiter klugschei**, hab' das Zeug eh schon lange vergessen und verdrängt :>

Bei einer ernsthaften Beschäftigung mit dem Thema würd' ich auch die Kopetz-VO empfehlen.

Mfg, LB

Zitat von Lord Binary

Das würd ich so nicht sagen.
Ok, das ist nicht unwichtig bzw nice to have, aber noch wichtiger ist die *Berechenbarkeit* des worst case.
Also *beweisbare* garantierte Antwortzeiten.
Zumindest bei Hard-Realtime-Systems.
Ein HRS mit <=12 micro-secs Antwortzeit in 99.99999999%
ist unbrauchbar, eines mit *garantierten* 120 micro-secs sehrwohl, soferne das für die Applikation noch akzetabel ist.

Nun ja, der Sinn eines worst case ist ja, in 100% der Fälle zuzutreffen Statt "in Grenzen halten" wäre aber wohl "garantiert beschränkt sein" der bessere Ausdruck gewesen.

Jo, da könnte durchaus was dran sein :p

Also für Ethernet gibts einen abgewandelten Standard, der auch RT-kompatibel ist. Hab schon wieder vergessen wie der heißt. Irgendsowas war da aber. Sowas wie Etherbus, kann das sein? Also eher Bus-System, aber halt Ethernet-mäßig.

Was RTLinux betrifft, wird da quasi ein kleiner RT-Kernel vor den Linux-Kernel eingeschoben. Dann kann ich einige Anwendungen dem RT-Kernel anvertrauen, die laufen dann in RT, und der Rest läuft normal in "Plain-Linux"