Echtzeit in einer VM

[AW4]

Selbst wenn so eine Technik Interrupts zeitig durchgereicht bekäme, gibt es dann noch keine Garantie, dass dem Guest CPU, RAM und I/O wie benötigt bereitstehen, also innerhalb von Mikrosekunden (andere Definitionen von "Echtzeit" sind meiner Meinung nach witzlos, jedes halbwegs vernünftig konfigurierte Linux bekommt "Echtzeit mit Latenzen kleiner 1 Sekunde" hin).

Das entspricht nicht dem Sinn und der Bedeutung von Echtzeit in der Informationstechnik!
Geringe Latenzen bekommst du auch mit einem normalen OS, bei dem du die Prozessprioritäten entsprechend eingestellt hast.
Um Latenzen gehts bei Echtzeit aber im Grunde auch nicht.

Echtzeit, bezogen auf die Informationstechnik, meint die garantierte Erfassung von Ereignissen, innerhalb eines definierten Zeitrasters.

Hast du z.B. einen Sensor, der in der Lage ist im 3kHz-Takt Signaländerungen zu erfassen und dein Anwendungsfall hat die Notwendigkeit im schlimmsten Fall diese Signaländerungen auch genau in diesem Takt (Zeitraster) erfassen zu müssen, dann willst du am Ende auch, dass der Sensor garantiert genau in diesem Takt ausgelesen wird, damit kein Signalzustand verloren geht.
Ein RTOS ist so ausgelegt, im Bezug hierauf, erhöhte Anstrengungen zu unternehmen, sodass die Wahrscheinlichkeit eines Verlorengehens, ungeachtet dem restlichen, anstehenden Workloads (der z.B. auch die Verarbeitung der Ereignisse/Signale sein kann), minimiert wird oder (so gut wie) ganz ausgeschlossen werden kann.

Ein normales OS bietet diese Möglichkeit nicht, da das natürlich Resourcen für anderen Workload wegnehmen würde.
Und ob jetzt eine 1kHz Gaming-Maus beim Zocken tatsächlich im Schnitt 1000 (oder 999,9999999) Mal die Sekunde ausgelesen wird, oder aber halt nur ~998 Mal, bekommt man zum einen gar nicht mit und zum anderen sind einem beim Zocken dann die FPS wichtiger (wie viel auch immer das ausmachen würde).

Bzw. WENN man das garantieren kann, hat man keine VM mehr, weil man einen Teil des Rechners hart reserviert hat.

Eine VM ist aus der Sicht ja nichts anderes als ein laufender Prozess.
Und wenn Prozesse Last generieren, wollen die halt auch entsprechende Rechenzeit.
Ob das jetzt aber Echtzeit-Anwednungen sind oder nicht, spielt da keine Rolle.
Wenn du mit nem normalen OS zwei Videos parallel rendern können willst, brauchst du darunter halt entsprechende Hardware, die das auch vernünftig stemmen kann, sodass es nicht länger dauert als es sequentiell zu machen.
Das ist mit Echtzeit nicht anders.

Die Virtualisierbarkeit eines RTOS ist aber schön und nützlich, wenn du ein Rechenzentrum hast und On-Demand Betriebssysteminstanzen anbietest, mit gemixtem, bzw. dir unbekanntem Workload.
Oder du hast deinen (Arbeits-) Rechner, der für einen Gewissen Anwednungsfall oder eine Bandbreite an Anwendungsfällen ausgelegt ist, die kein Echtzeit erfordern und damit auch langsamer wären, aber manchmal musst du Sensordaten o.ä. verlässlich auslesen können.

 

[GrumpyCat]

Geringe garantierte Latenzen bekommst Du eben NICHT nur durch simples Erhöhen einer Prozesspriorität. Es kann z.B. sein, dass der Kernel mal eben für 100ms bei irgendwas blockiert (ist bei nicht-RTOS nicht schön, aber auch nicht verboten). Oder dass der kritische Prozess gar nicht im RAM ist (z.B. ausgeswappt), oder oder oder.

Die garantierte Erfassung bei Deinem Sensor-Beispiel bekommst Du trivial, indem Du den Sensor vernünftig anbindest, z.B. mit Buffern oder einfach DMA. Das hat mit RTOS erstmal nichts zu tun. Wäre der reine Datenfluss so ein Problem, wie könnte man denn garantieren, dass die Daten von z.B. der SSD nicht ab und zu im Nirvana enden.

RTOS brauchst Du insbesondere in Regelungssystemen. Wenn Änderungen von Umgebungsparametern durch den Rechner erfasst und in einem garantierten Zeitfenster darauf reagiert werden muss.

RTOS werden z.B. benötigt zum Steuern von Industrieprozessen (Roboter, Motoren, etc.) oder z.B. im Auto (Erkennung von Unfallereignis => Auslösen des Airbags, etc.). Im Heimbereich gibt's sowas eher selten, bzw. wenn, dann hat man eher Microcontroller ganz ohne irgendwelche Scheduler oder MMU, Beispiele wären da z.B. die Steuerungseinheiten in Hausgeräten oder 3D-Druckern oder auch in vielerlei Retro-Emulationshardware (z.B. Hardware-Floppy-Emulatoren für die ganzen 80er-Heimcomputer). Da gibt es teilweise Anforderungen wie "Auf Änderungen an Eingang X muss innerhalb von 2µS an Ausgang Y reagiert werden".

Das, was Du da benennst (RTOS im Rechenzentrum oder Desktop) kommt mir eher aus den 90ern bekannt vor, als einige Leute dachten, RTOS wären die Lösung für ihre stotternden MP3s. Nein, dafür braucht man nur einen vernünftigen CPU- und I/O-Scheduler - die damals noch nicht so toll waren, plus die Kernels waren voll mit "ich greif mir die CPU und hock ewig drauf".

Das mit dem "harten Reservieren" hast Du evtl. nicht richtig verstanden bzw. ich hab's nicht richtig erklärt. Z.B.
das, was in https://lwn.net/Articles/816298/ erklärt wird, geht in die Richtung. Ist ein ganz spannender Artikel, hat allerdings mit "VM" nichts zu tun, dafür aber um so mehr mit harten Echtzeit-Anforderungen.

 

[AW4]

Ich verstehe grundsätzlich, was du mir sagen willst.
Muss mir deinen Link noch durchlesen.

Die garantierte Erfassung bei Deinem Sensor-Beispiel bekommst Du trivial, indem Du den Sensor vernünftig anbindest, z.B. mit Buffern oder einfach DMA. Das hat mit RTOS erstmal nichts zu tun. Wäre der reine Datenfluss so ein Problem, wie könnte man denn garantieren, dass die Daten von z.B. der SSD nicht ab und zu im Nirvana enden.

Das ist kein sinnvoller vergleich.
Der Sensor kann nichts, außer von außen irgendeinen Input zu bekommen und diesen aktuellen Zustand bis zum nächsten Überschreiten einer Schwelle zum Auslesen vorzuhalten.
Da wird nichts gepuffert oder gespeichert, so fortgeschritten ist das Ding nicht.

Die SSD hat eine Queue und der Kernel oben drauf wahrscheinlich auch noch.
Da landet nichts im Nirvana, die Frage ist da nur, wann das ankommt.
Kommts tatsächlich nicht an, merkst dus aber, weil dann irgendwas crasht, hängen bleibt oder in einen Timeout läuft.

 

[GrumpyCat]

Wikipedia erwähnt tatsächlich auch RTOS als mögliche Lösung bei reinen Messsystemen. Passt schon, aber ist meiner Meinung nach etwas schräg, weil man da eigentlich immer einfacher rauskommt, indem man an den Sensor einen Buffer ranpappt (im Zweifelsfall in Form eines 20ct-Microcontrollers) statt einen PC (!) anzuschließen und auf dem PC ein spezielles Betriebssystem zu installieren (!). Da hat sich die Welt seit 1990, als Microcontroller etc. nicht für Cent-Beträge zu haben waren und es Standard war, Sensoren per Parallelport an einen PC anzuschließen, eben auch etwas gewandelt (speziell beim deutschen Wikipedia-Artikel zu "Echtzeitbetriebssystem" ist die Zeit aber etwas stehengeblieben, oh die Ironie ). Und als Erklärung für das Nicht-Fachpublikum ist reines Messen auch kein günstiges Beispiel, weil es letztendlich nur um ein Implementierungsdetail der Kommunikation mit Peripherie geht (und z.B. im PC-Umfeld kein einziges Gerät entsprechend "billig" angeschlossen ist: Schon in den 80ern waren serielle und parallele Schnittstellen komplett mit Handshake und Buffern ausgestattet).

Das auch in Wikipedia erwähnte Beispiel mit dem Airbag-Auslöser ist besser. Da kommt man mit dem 20ct-Microcontroller nicht weiter (weil vermutlich 10 Sensoren angeschlossen sind und die Auswertung auch eher komplex ist), aber mit non-RTOS auch nicht (weil sonst schonmal 50ms Lag drin sind und ein so spät ausgelöster Airbag den Insassen dann nur noch einen zusätzlichen Schlag ins Gesicht verpasst).

Und wer behauptet, dass man solche Form von Echtzeit auch voll in einer Windows-VM haben kann, dem kann ich nur wünschen, dass er nie ein Auto fährt, bei dem die Programmierer ein ähnliches Mindset hatten.

 

[xxMuahdibxx]

@GrumpyCat naja ehrlich ich hätte nicht gerne immer einen Sensor mit Buffer ... ab und an brauchts auch was schnelleres ...

und nochmal RTOS sagt ja an für sich nichts aus wie schnell das System auf etwas reagiert sondern nur das es in einen bestimmten Intervall reagiert. Welcher vom Nutzer+Prozess definiert werden muss.

Weiterhin ist ein OS nicht immer gleich ein PC .... schon ein Programmierbarer Microcontroller kann mit einem RTOS versehen sein und damit arbeiten ( tun ja auch die ganzen Steuergeräte im Auto so )

https://en.wikipedia.org/wiki/Micro-Controller_Operating_Systems

 

[GrumpyCat]

Ja, laut Wikipedia ist das schon richtig, aber natürlich ist das dann so schwammig, dass irgendwie alles ein klein wenig RTOS ist, wenn man nur die akzeptablen Latenzen hoch genug wählt und es nachher auch mal okay ist, wenn ein paar Prozent der Ereignisse verlorengehen. Aber genau wegen solcher Wieselei versteht auch keiner, was ein RTOS tatsächlich ist, wie man hier im Thread ja trefflich sieht.

Ich sag mal, wenn die garantierten Latenzen nicht unter 200µS liegen können und/oder Ereignisse verlorengehen können, ist's halt kein RTOS, sondern irgendein Hack. Und ich weiß, dass das an Unis speziell vor Jahrzehnten anders gelehrt wurde, aber das ist halt auch massiv Elfenbeinturm und hat vermutlich in erster Linie damit zu tun, dass die Profen für ihr leicht gepatchtes Linux Fördergelder abgreifen wollten. "Kann nicht Echtzeit? Hmmm... aber vielleicht weiche Echtzeit?"

 

[AW4]

@GrumpyCat Ich versteh jetzt mein Problem mit deinen Postings in diesem Thread:
Du verwendest hier den Begriff "Latenz" in Bezug auf Echtzeit "falsch".
Geringe Latenzen können notwendig sein und Echtzeit dann das Mittel zum Zweck, primär gehts aber bei Echtzeit nicht um möglichst geringe Latenzen, sondern um die Reaktion auf irgendwas innerhalb eines Zeitfensters, innerhalb eines zeitlich möglichst homogenen Zyklus.

Geringe Latenzen sind nicht das Ziel von Echtzeit, sondern eine Notwendigkeit, die einen zum Einsatz von Echtzeit zwingen kann.

(Das folgende Beispiel darfst du gerne überspringen, da erzähle ich dir nichts neues. Es ist der Vollständigkeit halber da.)
Beispiel Airbag (nicht spezifisch auf ein Echtzeit-OS bezogen, sondern generell Echtzeit):
Am Anfang der Kette sind deine Sensoren, die willst du auslesen, im Anschluss auswerten und am Ende darauf reagieren (eine Nicht-Reaktion hier auch als Reaktion).
Das musst du, gezwungener Maßen, innerhalb eines gewissen, kurzen Zeitfensters, da sonst mehr Schaden als Gutes angerichtet wird.
Das soll aber alles nicht irgendwie und irgendwann passieren, sondern innerhalb einer gewissen Genauigkeit in homogenen Zeitabständen.
Du willst da nicht möglichst geringe Latenzen, um damit angeben zu können, sondern um Schaden zu verhindern und da hilft es dir wenig, wenn du rein theoretisch dazu in der Lage bist, im Schnitt 10.000 Mal in der Sekunde dein Auslesen, Auswerten und Reagieren auszuführen, wobei aber manchmal 95% der 10.000 innerhalb der ersten Hälfte der Sekunde und nur die restlichen 5% in der zweiten stattfinden.
(Das ist jetzt überspitzt und natürlich rein Hypothetisch und aus der Luft gegriffen, für den Versuch den Unterschied klar zu machen.)

Deine durchschnittliche Latenz ist klasse, aber eben wenig hilfreich, da Minima und Maxima der Latenzen Grütze sind.
Du kannst da auch das Zeitfenster der Bestimmung der Homogenität beliebig vergrößern oder verkleinern, je nach Anwendungsfall, das Problem bleibt aber dasselbe, weil den zulässigen Abweichungen Grenzen gesetzt sind.
(Klar ist eine geringere Latenz immer nett, aber dem steht der Interessenskonflikt mit der Kostenminimierung gegenüber.)

Wichtig ist, dass du verlässlich in der Lage bist, innerhalb eines bestimmten Zeitrasters auf Veränderungen zu reagieren.
Aber als Mittel zum Zweck nicht zwangsweise mit möglichst geringer (u.U. durchschnittlicher) Latenz, sondern mit einer bestimmten Latenz, mit bestimmten Abweichungen.

Und als Erklärung für das Nicht-Fachpublikum ist reines Messen auch kein günstiges Beispiel, weil es letztendlich nur um ein Implementierungsdetail der Kommunikation mit Peripherie geht

Mein Beispiel mit dem Sensor war ein Einfaches, weil du erst danach deinen Wissensstand zu dem Thema offenbart hast...

RTOSes wirst du in immer öfter sehen.
Es ist einfach billiger Hardware von der Stange zu kaufen und dann ein paar Programmierer drauf zu setzten, statt dir deine eigene Hardware zu designen, bzw. designen zu lassen.
Software kannst du auch noch im Nachhinein "entspannt" Patchen, Hardware nicht (immer).
(Beispiele gibt es dafür ja mittlerweile mehr wie Sand am Meer: Release first, patch later!)

Das mit dem "harten Reservieren" hast Du evtl. nicht richtig verstanden bzw. ich hab's nicht richtig erklärt. Z.B.
das, was in https://lwn.net/Articles/816298/ erklärt wird, geht in die Richtung. Ist ein ganz spannender Artikel, hat allerdings mit "VM" nichts zu tun, dafür aber um so mehr mit harten Echtzeit-Anforderungen.

Das war mir so tatsächlich nicht bewusst.
Ich habe das nicht im Detail verfolgt und war der Annahme, dass ein entsprechend kompilierter Linux Kernel tatsächlich RT-fähig wäre.
Tatsächlich ist er das auch heute nur eingeschränkt.

D.h. dann also:
Ist RT-Linux RT-fähig? -> Bedingt.
Ist RT-Linux in einer VM auf einem RT-Linux-Host RT-fähig? -> Bedingt bedingt.
Ist RT-Linux in einer VM auf einem Nicht-RT-Linux-Host RT-fähig? -> Nein!
Ist RT-Linux in einer VM auf einem Windows-Host RT-fähig? -> Nein nein!

@Don_2020 Ich nehm alles zurück! GZ für den Bierkasten (hoffentlich gefüllt mit vollen Bierflaschen )!

 

[GrumpyCat]

Latenz ist die Zeit bis zum Registrieren bzw. Antworten auf einen Stimulus. Z.B. der Airbag muss in jedem Fall, genau Null Ausnahmen akzeptabel, 5ms nach erster Sensormeldung ausgelöst werden. Da sind die max. 5ms Latenz. Homogene Zeitraster spielen da keine Rolle in der Definition. Und es geht auch nicht um durchschnittliche Latenzzeiten, sondern hart maximal erlaubte Latenzzeiten. Durchsatz spielt keine Rolle. Und klar möchte man im Mittel, dass Latenzen gering und konstant sind. Ersteres können echte RTOS garantieren ("100% Antworten innerhalb von 100uS"), zweiteres in Grenzen, es bleibt etwas Jitter.

Auch mal aus der englischen Wikipedia zitiert: "Key factors in a real-time OS are minimal interrupt latency and minimal thread switching latency".