Re: echtzeit

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.

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

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

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

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

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

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

Weil du auf einem PC keine maximalen Instruktionslaufzeiten kennst.

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

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