Moin,
wer weiss, wie bei einem Echtzeit-System die garantierte Antwortzeit ermittelt wird?
thx
moe.
Hallo,
ich glaube nicht, dass man die zuverlässig ermitteln kann, für mich ist das eine konstruktive Vorgabe bei der Erstellung des Systems. D.h. die Entwickler müssen beim Programmieren darauf achten, das critical sections usw. in der Laufzeit entsprechend begrenzt sind, und zwar immer und unter allen denkbaren Umständen.
Statistische Messungen widersprechen ja schon dem Begriff „garantiert“. Um etwa die Zeit zur Erfassung eines Interrupts und seine Übergabe an eine Verarbeitungsroutine zu bestimmen, wird man wohl oder übel den Code studieren müssen.
Gruss Reinhard
[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]
Moin,
wer weiss, wie bei einem Echtzeit-System die garantierte
Antwortzeit ermittelt wird?thx
moe.Hallo,
ich glaube nicht, dass man die zuverlässig ermitteln kann,
dann wäre der Begriff „garantierte Antwortzeit“ wohl etwas vermessen.
für
mich ist das eine konstruktive Vorgabe bei der Erstellung des
Systems. D.h. die Entwickler müssen beim Programmieren darauf
achten, das critical sections usw. in der Laufzeit
entsprechend begrenzt sind, und zwar immer und unter allen
denkbaren Umständen.
Aber irgendwo muss ich doch eine konkrete Zeitspanne bekommen. Schließlich wird diese doch auch angegeben. Und ich kann mir vorstellen, dass bei den System-Entwicklern der Teufel los ist, wenn die sich einfach eine Antwortzeit aus den Fingern saugen, die dann nicht eingehalten werden kann.
Statistische Messungen widersprechen ja schon dem Begriff
„garantiert“. Um etwa die Zeit zur Erfassung eines Interrupts
und seine Übergabe an eine Verarbeitungsroutine zu bestimmen,
wird man wohl oder übel den Code studieren müssen.
Also einfache Addition sämtlicher beim Interrupt ausgeführter Berechnungszeiten in Verbindung mit dem Prozessor-Durchsatz??
thx
moe.
Moien
wer weiss, wie bei einem Echtzeit-System die garantierte
Antwortzeit ermittelt wird?
Wenn’s hart auf hart kommt rechnet man alle Worst-Case-Senarionen von Hand durch, resp. lässt sie simulieren. Das ist sehr, sehr viel Arbeit und macht einen grossen Teil der Kosten von echten hart-time systemen aus.
Bei 0815-Dingen wie Echtzeit unter x86 brauchst du mit sowas gar nicht erst anzufangen. Der x86 ist zu unvorhersehbar.
cu
Hallo pumpkin
Bei 0815-Dingen wie Echtzeit unter x86 brauchst du mit sowas
gar nicht erst anzufangen. Der x86 ist zu unvorhersehbar.
Ich dachte mal auch der x86 wäre ein deterministisches System. 
Gruß
Stefan
Aber irgendwo muss ich doch eine konkrete Zeitspanne bekommen.
Schließlich wird diese doch auch angegeben. Und ich kann mir
vorstellen, dass bei den System-Entwicklern der Teufel los
ist, wenn die sich einfach eine Antwortzeit aus den Fingern
saugen, die dann nicht eingehalten werden kann.
Hallo Moe,
das kann garnicht anders funktionieren als mit einem Auftrag an die Entwickler „baut ein System, das unter allen Umständen innerhalb 100us auf ein beliebiges Ereignis reagiert“. Das Leben ist zu Programmierern hart, aber ungerecht. Wenn das Ziel nicht erreicht wird, ist das Projekt gescheitert, oder man setzt den Wert hoch, oder man sucht sich andere Programmierer.
Hat man ein laufendes System, wird man natürlich im Rahmen der Weiterentwicklung versuchen, die Antwortzeiten zu verbessern, indem man die kritischen Stellen in der Software sucht. Da es gerade nicht um Durchschnittswerte geht, sondern immer um den worst case, ist Denken angesagt - bekanntlich eine eher mühsame Angelegenheit.
Ob die Angabe des Herstellers stimmt, muss ich einfach glauben, sonst müsste ich den gesamten Code des Systems einer Revision unterziehen. Daher halten sich auch nur erfahrene und seriöse Hersteller. Falls du meinst, es gibt so etwas wie einen Benchmark für Echtzeit, der die Antwortzeit ausspuckt - das ist undenkbar.
Gruss Reinhard
Moien
Bei 0815-Dingen wie Echtzeit unter x86 brauchst du mit sowas
gar nicht erst anzufangen. Der x86 ist zu unvorhersehbar.Ich dachte mal auch der x86 wäre ein deterministisches System.
-)
Ja, klar ist das ein deterministisches System. Aber zur Ausführungszeit wird da nix gesagt. Um die Zeit die eine Funktion braucht zu bestimmen muss man wissen:
- wie die Funktion aussieht und wie lange die Operationen dauern
- welche Daten im Worst-case übergeben werden
zusätzlich muss man bei x86’er und anderen Desktop-CPUs wissen:
-
wo die Daten liegen (Register, Cache L1, L2, L3 …)
-
wie es im TLB Cache aussieht
-
ob die Funktion als Teil einer spekulativen Ausführung läuft oder nicht (also ob alle Pipelines zur Verfügung stehen oder nicht)
-
was die Branch-prediction zu den Entscheidungen in der Funktion sagt (der ist nicht wirklich dokumentiert, weder bei AMD noch bei Intel, Via)
-
welche MircoOp-Umsetzer für die verwendten ASM-Ops benutzt werden
-
ob die MicroOps schon in den caches des Umsetzer für komplexe Befehle liegen.
-
wie sieht es bei den Interrupts aus
-
in welchem setup laufen die pipelines
-
welche hazards können zwischen den Befehlen auftauchen
-
können hazards zwischen den eigentlichen Befehlen und spekulatiken Befehlen auftauchen
-
wenn die branch-prediktion sich irrt: wie lange dauert das roll-back oder switch des registersatzes ?
-
was tut die out-of-order unit wenn die Daten in Reihenfolge XY eintreffen
-
wenn RAM-Zugriffe zu tun sind:
-
wie sieht es auf der FSB-Front aus
-
in welchem Teil des Refresh-zyklus ist der RAM
-
auf welcher Page steht der RAM
-
wie schnell/langsam kann der Chipset sein ?
-
Ist die store-unit aktiv ? wenn ja in welchem Bereich des RAM ?
Und da fehlt noch einiges… Hart time auf dem x86 ist machbar, aber nicht beweisbar. Und bei richtig wichtigen Systemen muss alles nachweisbar sein. Deshalb werden stinknormale, kleine doofe Chips eingesetzt.
cu
Hallo Fragewuem,
- ob die MicroOps schon in den caches des Umsetzer für
komplexe Befehle liegen.
An diesem Punkt hast du noch die genaue Revision der CPU vergessen.
Bekannte CPU-Bugs werden ja durch MicroOps ausgebügelt.
MfG Peter(TOO)
Falls du meinst, es gibt so etwas wie
einen Benchmark für Echtzeit, der die Antwortzeit ausspuckt -
das ist undenkbar.
Sehe ich auch so und deshalb suche ich eine Antwort auf die Frage, wie diese vielbesagte „garantierte Antwortzeit“ zustande kommt…
thx
moe.
Abend!
Das hört sich mehr so an wie die letzte Vorlesung des Informatik
Profs.
Mein Prof war auch auf dem Trip das Echtzeitsysteme eigentlich nur
mit Analogrechnern gelöst werden können (daaaamals wurden die
Dinger in Flugsimulatoren benutzt).
Sorry aber ganz so schlimm wie du es darstellst ist es nicht.
Ich habe schon verstanden, dass du dich mit x86 beschäftigst
hast. Nur, zum einen wird man viele Dinge in einem Echtzeitsystem
einfach nicht zulassen (TLB miss, hallo!??!, nix Windoof, Usenix).
Ich kann sogar meinen Code und meine Daten im 2nd Level Cache
annageln. Je nachdem ob nur schnell oder flexibel gibt es verschiedene
Strategien die man nutzen kann.
Zum anderen gibt es durchaus Informationen über die CPUs die es
einem erlauben den Worst Case auszurechnen.
Ich gebe dir recht, das es sehr schwer ist und selbst mit Red-Level
NDA mit Intel kann man lediglich Worst-Case ausrechen, aber das geht
schon.
Deshalb werden stinknormale, kleine doofe Chips eingesetzt.
Wann immer das möglich ist, gebe ich dir recht. Wann immer du
Rechenleistung bis zum abwinken brauchst stimmt das nicht.
Gruß
Stefan
Abend!
wer weiss, wie bei einem Echtzeit-System die garantierte
Antwortzeit ermittelt wird?
Das hängt ein wenig (super duper viel) davon ab, was du unter
Echtzeitsystem verstehst.
Eine Datenbank die immer in 1s Antworten muß, ein Prozesssteuerungssystem
das in 0,1s reagieren muß, einen (Flug, LKW, Auto) Simulator der
wirklich recht flott reagieren muß oder eine Airbag Steuerung.
In wirklich kritischen Systemen verwenden wir FPGAs. Die CPUs in einem
FPGA laufen zwar nur mit ca. 50MHz aber zum einen kann man den
Befehlssatz recht einfach durch Spezialbefehle erweitern und zum anderen können wir auf den Takt genau sagen wie lange es dauert
bis die Antwort kommt.
Gruß
Stefan