Re: echtzeit

Clemens Hermann wrote:
> Am 02.02.2003 um 17:31:05 schrieb Jens Rehsack:
>
> Hallo Jens,
[...]
> die Ursprüngliche Behauptung war "es gibt harte Echtzeit unter Linux".

Das war eine Anwenderbehauptung - da wurde RT-Linux gelesen und Linux
als OS angenommen. Das soll die Namensgebung IMHO auch suggerieren, da
Linux ja sooo in ist.

>>>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.

I know. Aber: Die Anzahl der Takte für die Befehlsausführung stehen im
Prozessorhandbuch und sind auch in Ergänzungen der "Ralph Brown
Interrupt List" zu finden. Die Anzahl der Takte, die der Prozessor
benötigt, um Daten aus dem RAM in ein Prozessorregister zu laden, sind
auch dokumentiert. Demzufolge kann man die Zeit, die eine
Intruktionssequenz benötigt relativ problemlos berechnen.

> 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.

Die Aussage: "Der Prozessor und der Speicher ... schnell genug" kam
genau aus der Ecke. Um's kurz zu machen: Wenn ein Z80-System reicht,
reicht auch ein Pentium-System, solange ich den Scheduler kontrollieren
bzw. geeignet steuern kann.

Kein "Ich habe aber ..." Kleinkrieg bitte jetzt. Wenn der/die
Programmierer/-in nicht die Intruktionen prüft, falls die Sequenz in
einer Hochsprache programmiert wird, oder die Takte nicht zählt, kann
kein PC was dafür, da würde jedes andere System ebenso scheitern.

> 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)

Da habe ich auch nie etwas gegenteiliges behauptet.

>>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.
Das kann ich. Dazu gibt es das Prozessorhandbuch.

> 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.

Doch, denn ich kann ohne Branch-Prediction und ohne Pipeline rechnen.
Dann wird das Ergebnis zwar meistens deutlich schneller, aber da eine
Integer-Addition nur einen Takt benötigt, und das Laden einer Adresse
aus dem Hauptspeicher 200 Takte (müsste nachgelesen werden, ist aber in
etwa die Größenordnung), benötigt die Addition zweier Integer max. 601
Takte. Das sind bei einer Frequenz von 100MHz 0,00000601s. Ich emfehle
hier einen Blick in die o.g. Dokumentation der x86-Intruktionen der
Interrupt List von Ralph Brown (google). Meinetwegen kann man noch die
Dauer des Taskswitch draufrechnen - gibt's auch Doku für. Für 386/486
habe ich sie in Buchform hier, Pentium dürfte da sogar schneller sein.

> 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.

Und die kann man ohne Pipeline berechnen. Fertig ist. Außerdem weiss
man, ob eine Adresse im Register ist, im 1st Level Cache, ... oder im
Hauptspeicher. Wenn man dass nicht weiss - Finger weg vom
Echtzeitprogrammieren oder ein System ohne sowas nehmen oder ohne rechnen.

Soweit ich das verstanden habe, ist es auch egal, ob der worst case
unterschritten wird - daher kann man die ganzen Beschleuniger im Zweifel
auch einfach ignorieren.

>>>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.

Ich kann Dir nicht folgen? Wieso ist es nicht möglich,
Echtzeitanwendungen zu schreiben, wenn man den Scheduler kontrollieren
kann und die Instruktionslaufzeiten zählt?

>>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.

Schau Dir mal RT-Linux an! Die definieren Dir nämlich dies ganz genau.

>>Dafür sollte auch ein Dual-P90 System reichen, dass es mittlerweile für
>>30 EUR 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.

Darum ging es ja gerade: RT-Linux ist kein Linux. Linux ist das
User-Interface zum RT-Kernel des RT-Linux und läuft in einem niedrig
priorisieren Task.

So long,
Jens

To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message
Received on Sun 02 Feb 2003 - 18:57:53 CET