Re: echtzeit

Bernd Walter wrote:
> On Sun, Feb 02, 2003 at 06:56:52PM +0100, Jens Rehsack wrote:
>
>>Clemens Hermann wrote:
>>
>>>Am 02.02.2003 um 17:31:05 schrieb Jens Rehsack:
>>>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.
>
>
> Die Take ist unwichtig.
> Wenn ich eine IO Reaktion brauche.
> Z.b. Motor anhalten, weil Lichtschranke aktiv ist, dann muß ich den
> Befehl zum Motor bringen.
> ummerweise kann aber eine PCI KArte theoretisch dem gesammten IO Bus
> auf unbestimmtete Zeit belegen.
> Kommt nicht oft vor, aber ausschließen kannst du es nicht.
> Darum geht es aber.
> Du brauchst eindeutig selektierte Hardware.
> Natürlich kann das auch PC Hardware sein, aber nicht eine X beliebige.
> Dummerweise bekommst du aber für PC Hardware solche Informationen in
> der Regel gar nicht erst, wodurch sich PCs nahezu komplett für echtes
> Realtime ausschließen.
>

Ok, da gehe ich mit.

>>>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.
>
>
> Eben nicht.
> Generel sind beide CPU Typen geeignet, aber es zählt das Gesammtsystem.
> Bei einem C64 beispielsweise kann ich Ausfürungszeiten garantieren, bei
> einem PC nicht.
> Bei einem C64 kann ich gar Garantien auf einen exakten Taktzyklus
> machen (ca 1µs!) - mit schnelleren 6502 natürlich noch kleiner.
> Wenn man sich dann die Nachfolger im Mikrocontroller Bereich anssieht,
> dann wird man feststellen, das man heutzutage problemlos Genauigkeiten
> von einigen Nanosekunden ereichen kann.
> Mit einem 33MHz 486'er komme ich nicht mal mehr annähernd auf die
> Genauigkeit von einem C64 , da du eben nicht mehr so genau Zyklen
> zählen kannst.
> Es ist sogar so schlimm, das sich das Verhalten nach Produktionsstätten
> unterscheiden kann.

Hm, das es da kleine Unterschiede gibt, wusste ich, aber das die so böse
sind, ts ts ts ...

>>>>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.
>
> Das ist richtig - nur ist die nutzlos, im Gegenteil der Worst Case
> wird in der Regel durch die größere Komplexität schlechter.
> Deswegen läßt man die in einigen Systemen weg.
> Lediglich der Preis bringt Echtzeit Systeme schon mal zu solchen CPUs.

???
Versteh' ich nich. Wenn ich die Branch Prediction weglasse und annehme,
es gäbe keine, und die Befehle kämen immer aus dem Hauptspeicher (statt
aus dem Cache oder der Pipeline), müsste dann das nichr der Worst-Case sein?

>>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.
>
> Wie ich schon oben erwähnte - die CPU ist nicht alleiniges Kriterium.
> Pentiums dürften schneller sein hilft auch nicht weiter.
> Es gibt Befehle, die in Pentiums langsammer sind als bei einem 386.
>

Stimmt - daher sollte man schon die Doc zur verwendeten CPU zu Rate
ziehen. Die Argumentation mit der Hardware sehe ich ein, aber ich
kapier' echt nicht, warum bei ausgewählter Hardware (es gibt sowas für
sog. Industrie-PC's) das eine Rolle spielt.

>>>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.
>
> Versuche doch mal den Hauptspeicher zu kalkulieren!
> Du kannst nicht wissen, ob noch eine Page aktiv ist oder nicht.
> Du weist nicht mal, wann das RAM seinen Refresh macht.
> Auf einem C64 ist mir das bekannt.

Muss ich auch nicht. Ich nehme für den Worst-Case an, dass sie nicht auf
Platte liegt (was ich bei einem RT-Kernel problemlos kann) und der
Refresh des RAM verdoppelt halt die Ladezeit aus dem Hauptspeicher (400
Takte statt 200).

>>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.
>
> Klar kann ich Worst Case rechnen, aber wie sieht der bei einem PC aus?
>

Man darf natürlich kein Media-Markt-System nehmen. Das ist klar. Aber
bei Industrie-PC's bekommt man IMHO die nötigen Info's um diese Aussage
treffen zu können.

[...]
>>>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?
>
> Weil du auf einem PC keine maximalen Instruktionslaufzeiten kennst.
>

Eigendlich schon. Beispiel:
----------O-INVLPG---------------------------------
OPCODE INVLPG - Invalidate Page Entry In TLB

CPU: I486 +
Type of Instruction: System

Instruction: INVLPG mem

Description:

        IF found in data or code (if both) (or common if single)
           TLB entry with linear address (page part) same as
           memory operand <mem> then mark this entry as Invalid;

Notes: This instruction not work in Real Mode and in
Protected mode work only in ring 0 ;

Flags Affected: None

CPU mode: RM,PM,VM,SMM

Physical Form: INVLPG mem
COP (Code of Operation): 0FH 01H mm111mmm
Clocks: Cyrix Cx486SLC : 4
              i486 : 12 if hit
                       : 11 if not hit
              Pentium : 25

Ist doch eigendlich eine klare Aussage, oder? Ok, meine Intrlist ist
lange nicht mehr geupdated worden (programmier' schon 'ne Weile kein
DOS(E) mehr ...)

Ich versteh' echt nicht, wo das Problem bei Instruktionen liegt?

>>>>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.
>
> Auf welcher Hardware?
> Definieren kann man viel - eine Garantie ist das aber nicht!
> Die können nichts garantieren, ohne die Hardware zu kennen.

Die können aber sagen, wie sie reagieren, z.B. das ein RT-Task max. x µs
Laufzeit bekommt, damit noch auf HW-IRQ's reagiert werden kann, etc. Die
könne sagen, wir haben folgende Instruktionen verwendet, wenn ein IRQ
kommt, auf den ein Echtzeit-Task reagieren möchte, ...

Wie erklärst Du Dir die Existenz von QNX, wenn PC's von Haus aus nicht
echtzeitfähig sind?

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 - 23:38:49 CET