Re: echtzeit

Am 02.02.2003 um 17:31:05 schrieb Jens Rehsack:

Hallo Jens,

> >>danke für die info, aber meines wissens gibt es unter linux ahrte
> >>echtzeit.
> >
> >Unter Linux vielleicht (würde mich aber durchaus überraschen), aber sicher
> >nicht unter einem Linux, das auf einem PC läuft.
>
> Da gibt es offensichtlich ein Missverständnis: RTLinux ist kein
> Echtzeit-System im Linux,

die Ursprüngliche Behauptung war "es gibt harte Echtzeit unter Linux".

> >auf PC-Hardware ist keine "harte Echtzeit" realisierbar. Unter harter
> >Echtzeit
> Warum nicht? Der Prozessor und der Speicher sind IMHO schnell genug.

echtzeit != schnell. Wenn ich an einem Fließband eine Reaktionszeit von 1 Sec.
bei einer Lichtschranke benötige, dann hilft es mir nichts, wenn bei 99,99999%
aller Fälle das Signal nach 1 Millisekunde vorliegt, aber im verbleibenden
0,00001 ten Fall 1,1 Sekunden braucht. Echtzeit hat also nicht unbedingt was
mit einem schnellen System zu tun, sondern per Definition kann man bei einem
Echtzeit-System genau sagen, wie lange eine Berechnung maximal dauern wird.

bei einem Echtzeit system kann man das nachweisen und "weiss" das _nicht_
deshalb, weil ja bisher die Addition zweier smallints noch nie länger als
0,01 Sekunden gedauert hat und es ja vielleicht, hoffentlich, der Erfahrung
nach, eventuell, knock on wood auch so bleiben wird.

Ob es sich nun um ein hartes, festes oder weiches Echtzeit System handelt ist
dabei egal, diese Bezeichnungen legen lediglich die Folgen fest, wenn eine
Schranke überschritten wird (in einem Harten Echtzeitsystem wäre die
Überschreitung der Schranke der GAU)

> Lade deine Aktionen und Protokolle in einen Speicherbereich und
> initialisiere alle benötigten Variablen, etc.. Starte dein System und es
> wird so funktionieren, wie programmiert.

aber Du kannst keine Aussage treffen, wie lange Das System dazu benötigen wird.
Du kannst Dir zwar recht sicher sein, dass es weniger als einen Tag dauern wird,
zwei INTs zu addieren, aber Du kannst den worst case nicht bestimmen.
Dazu müßtest Du (auf assembler Ebene!) jeden Befehl durch die CPU Pipeline
schicken und unte Berücksichtigung aller möglichen externen Implikationen
(die Du bei PC hardware nie 100%ig verhindern kannst) berechnen, wie lange
der Befehl maximal braucht. Das wird schon daran scheitern, dass Du die
nötigen Specs nicht bekommst. Durch ausprobieren kommst Du auch nicht weiter, da
aktuellere CPUs z.B. durch branch prediction und Mehrfädigkeit den worst-case
sehr selten zu Tage treten lassen.

Solche Dinge, die die CPUs zweifellos massiv beschleunigen werden aus genau dem
Grund ich echtzeit-Systemen erst garnicht implementiert, weil da einfach nur
die worst-case execution Time interessiert und nicht die durchschnittliche,
statistische Berechnungsdauer.

> >versteht man garantierte Zeitschranken, also nicht unbedingt besonders
> >schnelle Systeme, sondern Systeme, die zur Erledigung einer vorgegebenen
> >Aufgabe garantert nicht länger als X (z.B. 0,1 Sekunden) benötigen. Um das
> >zu
> >gewährleisten darf man nicht nur glauben, dass man unter der Schranke
> >bleibt, sondern man muss es z.B. für den Worst case (den man vorher kennen
> >muss)
>
> Natürlich muss der Programmierer auf sowas aufpassen. Das muss er/sie/es
> aber auch auf nicht-PC-Hardware.

auch durch aufpassen allein bekommt man auf PC Hardware keine harten Echtzeitsysteme
hin. Du kannst Wie gesagt nen dicken Puffer draufrechnen, dann wird es in den meisten
Fällen schon passen (wenn Du den Puffer dick genug gewählt hast), aber das ist dann
kein wirkliches Echtzeit System und sowas kann man je nach Anforderung auch ganz ohne
Dinge wie RT machen, indem man einfach nen dicken Rechner hinstellt.

> Es sei denn, man hat Kontrolle über den Scheduler, der im RT-Linux ein
> RT-Scheduler ist, den man in benötigtem Maße kontrollieren kann. Im
> Zweifel kann man dafür immer noch ein Multiprozessor-System nehmen,
> wobei HW-IRQ's auf Proc-A und RT-Actions auf Proc-B ausgeführt werden.

Dennoch musst Du die IRQs ja mit dem eigentlichen Programm zusammenbringen und auch
Da musst Du wissen, wann die IRQs ausgewertet sind wenn Du sicher gehen willst, dass
Das Ergebgnis rechtzeitig vorliegt.

> Dafür sollte auch ein Dual-P90 System reichen, dass es mittlerweile für
> 30 ? bei ebay gibt.

je Nach Aufgabe wäre für die meisten Echtzeit-Aufgaben ein 386er mit 33 MHz rein von
der Rechenleistung mehr als ausreichend (wenn man sich auf den echtzeit-Teil beschränkt)

Ich wollte übrigens keineswegs behaupten, dass RT (was ich nicht kenne) einen PC nicht
deutlich besser für den Einsatz bei zeitkritschen Aufgaben macht als ein übliches
Betriebssystem. Nur wirst Du das, was Echtzeit wirklich ist, auch damit nicht erreichen
können. Dass RT dennoch für viele Anforderungen, die z.B. ein normales Linux nicht
leisten könnte vollkommen ausreichend sein kann möchte ich nicht bezweifeln.

Grüße

/ch

-- 
Wieviele Mitarbeiter von Microsoft benoetigt man fuer das auswechseln
einer defekten Gluehbirne? Keine, Microsoft erklaert die Dunkelheit zum
Marktstandard.
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message