Institut MD Universität Rostock Real-Time Linux Szenario –Board, liest (sampled) analoge Daten –produziert 8 Bit Ergebnis und gibt dieses alle 100 ms aus.

Präsentation zum Thema: "Institut MD Universität Rostock Real-Time Linux Szenario –Board, liest (sampled) analoge Daten –produziert 8 Bit Ergebnis und gibt dieses alle 100 ms aus."—  Präsentation transkript:

1 Institut MD Universität Rostock Real-Time Linux Szenario –Board, liest (sampled) analoge Daten –produziert 8 Bit Ergebnis und gibt dieses alle 100 ms aus –Die meisten Boards haben Buffer. Damit kann das Nicht-EZ- Verhalten von Desktopsystemen (W98, Windows-ME) kompensiert werden –Buffer nimmt 512 Samples auf und wird alle 50ms einmal ausgelesen

2 Institut MD Universität Rostock Real-Time Linux Drei Probleme. 1.Auch wenn 50 ms lange Zeit sind, ist es nicht schwierig Deadline zu verlieren 2.Wenn HW mit SW-Unzulänglichkeiten rechnen muss, dann wird die HW u.U. komplex und teuer 3.Wenn ein Gerät gesteuert werden muss, dann können 50ms u.U zu lang sein und der HW-Buffer kann Instabilitäten und bewirken und Verzögerungen innerhalb der Steuerschleife bewirken

3 Institut MD Universität Rostock RTS implementiert als Schleife Nachteil: nicht skalierbar counter = 500; while (1) { if (data_on_sensor()) ( read_sensor(); compute_output(); counter--; } if (!counter) { output(); counter=500; }

4 Institut MD Universität Rostock Fundamentale Widersprüche im Code von Linux mit RT-Anforderungen: oder Warum ist Linux nicht echtzeitfähig?

5 Institut MD Universität Rostock Warum ist Linux nicht echtzeitfähig? I coarse grained (grobkörnige) Synchronisation: –Eine Tasks hat über einen längeren Zeitraum alleinigen Zugriff auf einige Daten –Fine grained (feinkörnige) Synchronisation bewirkt, dass das System viel Zeit mit dem Belegen und Freigeben von Datenstrukturen verbringt –Linux nutzt grobkörnige Synchronisation kein vollunterbrechbarer Kern

6 Institut MD Universität Rostock Warum ist Linux nicht echtzeitfähig? II Manchmal bekommt die unbedeutendste Tasks eine Zeitscheibe, obwohl es wichtigere Tasks gibt –Hintergrundtask, die z.B. Logfiles löscht –In RTS wartet eine hochpriore Tasks nicht auf niederpriore

7 Institut MD Universität Rostock Warum ist Linux nicht echtzeitfähig? III Linux ordnet u.U. einige Taskanforderungen neu, um Hardware effizienter zu nutzen –Z.B. Das Lesen eines Blocks von Festplatte durch einen niederprioren Prozess, kann dem Lesen eines höherprioren Prozesses vorangestellt werden, um z.B. Bewegungen des Festplattenkopfes zu minimieren oder die Chance zur Fehlerregenerierung zu verbessern

8 Institut MD Universität Rostock Warum ist Linux nicht echtzeitfähig? IV Linux stapelt Operationen, um Hardware effizienter zu nutzen –Anstelle, eine Page zur Zeit zu befreien, wenn der Speicher eng wird, geht Linux durch die Liste der Pages und löscht so viel Pages wie möglich. Damit wird die Ausführung aller Tasks unterbrochen. Es wäre nicht sonderlich produktiv für Linux, den Swapper immer dann zu starten, wenn eine Pages benötigt wird. Dadurch wird der Worst Case Fall beeinflusst. Linux unterbricht nicht die Ausführung einer niederprioren Tasks –Um das zu können, müssten Preemption Points in das System eingefügt werden. Die würden jedoch die Performance des Gesamtsystems verschlechtern Linux lässt hochpriore Tasks durch niederpriore Tasks auf die Freigabe von Ressourcen warten

9 Institut MD Universität Rostock Kann man Linux nicht selbst echtzeitfähig machen Prinzipiell bestände die Möglichkeit, Linux echtzeitfähig zu machen und den Code zu modifizieren. –Dazu wäre es erforderlich, 90% der Treiber herauszuschmeißen und den größten Teil des Codes neu zu schreiben. –Das Ergebnis wäre jedoch nicht Linux Ansonsten ist das Worst-Case-Delay der längste Pfad zwischen zwei Preemption Points. Dieses ist schwierig zu bestimmen oder zu reduzieren Jede Modifizierung des Codes hat einen globalen Effekt.

10 Institut MD Universität Rostock Die RTLinux-Lösung Linux wird so modifiziert (fix), dass Linux keine Interrupts selbst sperren kann. Ein kleiner Echtzeit-Kernel, teilt den Kernel-Bereich und erhält die IRQs zu erst. Linux hat jetzt einen Interrupt Control Emulator. Der wesentliche Unterschied zum System ohne RT-Teil

11 Institut MD Universität Rostock Die RTLinux-Lösung Betriebssystemkern (RT-Kernel) übernimmt die Kontrolle über das Betriebssystem (Linux) Das normale Linux wird als Task ausgeführt. RT-Linux stellt den Zugriff auf HW derart sicher, dass EZ-Task minimale Latenzzeit besitzen. Lycklama,H., Bayer, D.L.: The Mert Operating System. Bell System technical Journal 57(6) 2048-2086, 1998

12 Institut MD Universität Rostock Verwendung von RTLinux Interrupt Steuerhardware Real-Time Kernel Linux Real-Time Tasks Linux-Anwenderprozesse

13 Institut MD Universität Rostock API rtl_request_irq, rtl_free_irq rt_get_time rt_task_delete rt_task_init rt_task_make_periodic rt_task_suspend rt_task_wait rt_task_wakeup rt_use_fp rtf_create rtf_create_handler rtf_destroy rtf_get rtf_put rtf_resize rtf_set_periodic_mode rtf_set_oneshot_mode