Re: echtzeit

On Sun, Feb 02, 2003 at 04:41:38PM +0100, jens wrote:
> hi,
> danke für die info, aber meines wissens gibt es unter linux ahrte echtzeit.
> dies wird erreicht, in dem ganz unten der echtzeittask läuft. der normale
> kernel läuft als task mit nidriger priorität oder als idle task (weiss nicht
> mehr genau wies hies) damit wird harte echtzeit möglich.
> unter linux nennen sich 2 varianten rtlinux und rtai. es gibt ja auch noch
> qnx, aber das ist irgendwie kostenpflichtig.
> an einigen unis wurde mit echtzeitlinux divers experimentiert um damit
> Automaten zu steuern. das funktioniert nur in echtzeit.

Nun Echtzeit ist so eine Sache.
Letzlich geht es um garantierte Reaktionszeiten.
Echtzeitanwendungen im Desktopbereich gibt es bereits reichlich.
Man denke nur mal an Videofilme.
Aber letzlich merkst du daran, daß Videofilme selbst mit bester
Hardware ruckeln könne, das das System die Garantien nicht immer
erfüllen kann.
Oder man denke an das traditionelle Problem die Seriele Schnittstelle
schnell genug zu behandeln.
Du solltest als erstes herausbekommen, ob eine solche kurzfristige
Schwäche in der Reaktionszeit wirklich ein Problem für deine Problem-
stellung darstellt.

Meist löse ich Echtzeitprobleme für Automatisierungen durch einen
eigenen Microcontroller, oder durch Software im Kernel.
Unter FreeBSD hast du leider nur im Kernel die Chance garantiert
schnell zu reagieren.
Im Kernel bedeutet aber auch Komfortabstriche, sowie einen hoch
Priorisierten IRQ - typischerweise nehme ich den Timer.

Im Cosmo-Project haben wir mal so einen Fall für einen Schrittmotor
behandelt.
Es geht dabei darum, das du den Motor nicht aus dem Stand auf volle
Geschwindigkeit hochfahren kannst, wenn du allerdings mal zu langsamm
bist, dann kannst du nicht mit der gleichen Geschwindigkeit weiter-
machen, weil der Motor sonst Schritte überspringt.
Die möglichen Lösungen sind:
- Den Motor unterhalb der Kritischen Geschwindigkeit betreiben.
- Bei Zeitverlust den Motor wieder langsamm anfahren.
  Letzlich ist die maximale Geschwindigkeit aber immer noch unter dem
  vom Motor machbaren.
- Dafür Sorgen, daß man einfach keinen Fehler in der Ansteuerung macht.

Das gleiche Problem behandeln wir jetzt für eine Matrix LED
Ansteuerung.
Hir hast du andere Probleme:
Viele Fehler werde sichtbar, aber einzelne Ausreißer sind harmlos.
D.h. man kann durchaus damit leben, daß die Reaktionszeit immer
ausreichend ist, aber nicht 100% garantiert werden kann.

Alternativ gibt es auch rtprio im Userland - der Prozess bekommt immer
der CPU Zuschlag, solange er lauffähig ist.
Du mußt aber äußerst vorsichtig mit dem Feature sein.
Außerdem garantiert es immer noch keine echte RT, da auch dieser
Prozess mal auf Platte und Co warten muß, deren Reaktionszeit ist aber
unberechenbar.

rtlinux ist so eine Sache - es ist kein Linux, da Linux der Kernel ist,
welcher ja der entscheidende Unterschied von rtlinux zu anderen
Distributionen ist.

Wichtiger Punkt für ein RT System ist der Scheduler - in -current gibt
es Ansätze den austauschbar zu machen - sicherlich ein guter Anfang.
Letzlich gibt es aber wesentlich mehr zu machen, um normalen Prozessen
Garantien machen zu können.

-- 
B.Walter              COSMO-Project         http://www.cosmo-project.de
ticso(at)cicely.de         Usergroup           info(at)cosmo-project.de
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message