Echtzeit in einer VM

[Don_2020]

Streit unter Kollegen.
QNX ist ein Multiuser/Multitasking-Echtzeitbetriebssystem.
Wenn QNX in einer Virtuellen Maschine läuft habe ich dann noch die Echtzeitfähigkeiten?
Ich meine nein. Wenn als Host Windows 10 genutzt wird können keine Echtzeitfähigkeiten im Guest zur Verfügung gestellt werden. Windows 10 ist halt kein Echtzeitbetriebssystem.

Mein Kollege meint nein, die Echtzeitfähigkeit bleibt auch als Guest erhalten. Wie soll das gehen?

 

[Stern1710]

Ich würde bei einer virtuellen Maschine immer soweit gehen, dass es nicht Echzeitfähig ist, solange nicht alle Elemente vom virtualisierten OS bis hin zum Hypervisor/HostOS Echtzeitfähig sind und diese Garantie auch weitergeben können.. Ich würde in diesem Fall also dir rechtgeben, da zwar QNX in der VM denkt, dass es RealTime ist, aber Windows keine Garantien abgeben kann und der Hypervisor wahrscheinlich auch nicht (in diesem Fall ein Level 2 Hypervisor). Da sind einfach zu viele Zwischenschichten am Arbeiten.
Auch bei einem Level 1 müsste der Hypervisor auch noch Echtzeitfähig sein und das mit QNX kommunizieren können würde ich meinen. Korrigiert mich aber bitte, wenn ich falsch liege, ich will auch gerne lernen

 

[floq0r]

Wahrscheinlich reine Definitionssache: QNX ist nach wie vor echtzeitfähig, die gesamte Befehlskette über den Host aber nicht.

 

[tollertyp]

Also es kommt halt auf die Sichtweise an, was konkret noch in Echtzeit ist.
Innerhalb der QNX-VM ist das vielleicht schon Echtzeit.

Will sagen:
Man stelle sich vor, unser Universum wird irgendwo simuliert, wir sind Teil der Simulation. Pausiert nun jemand von Außen das Universum, bekommen wir das gar nicht mit. Weil für uns alles wie immer ist.

Sobald die VM verlassen wird, ist die Echtzeit natürlich nicht mehr gegeben.

 

[SpamBot]

QNX ist nach wie vor echtzeitfähig,

Nein, wie soll es echtzeitfähig sein wenn es in einer Umgebung läuft die das nicht ist.

Ergänzung (18. November 2020)

Pausiert

Nach der Logik wäre jedes Programm Echtzeitfähig wenn es gleichzeitig seine eigene Zeit mit Synchronisiert. Etwas anderes passiert ja in dieser pausierenden VM auch nicht. Für irgendwelche Theoretischen Tests geht das bestimmt.

 

[AW4]

Das kommt wahrscheinlich drauf an.
Solange der Echtzeit-Anwedungsfall das OS nicht verlässt (also rein in/zwischen Software läuft) sollte es keinen großen Unterschied machen, die Logiken sind ja im OS und das läuft maximal etwas langsamer, weil eine MMU dazwischen hängt.
Dieser Anwednungsfall wird aber wohl eher selten sein.

Meistens ist ja irgendwo Hardware beteiligt (Festplatte, Netzwerk, Sensoren über diverse Schittstellen, etc.), die nicht eine CPU oder ein Arbeitsspeicher ist und standardmäßig in einer VM vom Hypervisor verdeckt oder vorgegaukelt wird.
Da kommt es dann drauf an, ob es möglich und auch umgesetzt ist, dass der Zugriff auf diese Hardware direkt in die VM durchgereicht wird und die Kommunikation damit nicht der Hypervisor handelt.
Ist das der Fall, dann kann man wohl auch bei Verwednung einer VM von "Echtzeit" reden, obwohl der Hypervisor und das Host-OS nicht echtzeitfähig sind.
Aber halt auch nur dann, wenn auf wirklich alle notwendige "Echtzeit-Hardware" über Passthrough zugegriffen wird.

 

[PHuV]

Es soll Hypervisoren geben, die Echtzeitfähigkeiten des Kernels an die VMs weitergeben können, das geht dann aber nur über Unix/Linux-Hypervisioren, und nicht über Windows.

https://www.embedded-software-engin...er-multi-core-embedded-und-echtzeit-a-582473/
https://de.wikipedia.org/wiki/RTOSVisor

 

[tollertyp]

Also ich meine halt es ist eine Frage der Perspektive einfach.

Schaue ich von außen auf das System Host+VM, dann nein.
Schaue ich auf die VM Schaue ich aus Sicht des QNX-Systems, und für mich gibt es nur die Welt innerhalb der VM und nichts anderes, dann bin ich mir nicht sicher, ob man dann nicht mehr von Echtzeitfähigkeit sprechen kann. Wohlgemerkt: nur innerhalb der VM. Dass die Zeit außen absolut gesehen anders sein mag, steht außer Frage.

Btw: Festplatten und die anderen genannten Komponenten sind ja auch ohne Virtualisierung eine Wundertüte.

 

[Don_2020]

Danke für die Antworten. Da lag ich mit meiner Analyse ja nicht falsch.
Huhu, die Kiste Bier gehört mir!

 

[GrumpyCat]

Echtzeit heißt sowas wie z.B. die Garantie an eine Applikation, dass von außen eingehende Daten innerhalb von X Mikrosekunden auch an die Applikation weitergegeben werden und die Applikation dann CPU-Zeit zum Verarbeiten hat.

Die Treiber von Windows bieten keinerlei Garantie in diese Richtung, der Scheduler von Windows auch nicht, und die Prozesse innerhalb einer VM können/dürfen allerhand Dinge nicht, die dafür nötig wären (z.B. Pinning ins physische RAM).

(Wow, die Leute, die hier von "Echtzeit nur in der VM" reden, sind ja goldig. Macht doch von der Definition her gar keinen Sinn. Zeit ist an der Stelle NICHT relativ. )

 

[xxMuahdibxx]

Also es kommt halt auf die Sichtweise an, was konkret noch in Echtzeit ist.

Genau da liegt das Problem begraben... denn Echtzeit heist nicht es ist sofort was da ... sondern

Der Begriff Echtzeit (englisch real-time) charakterisiert den Betrieb informationstechnischer Systeme, die bestimmte Ergebnisse zuverlässig innerhalb einer vorbestimmten Zeitspanne, zum Beispiel in einem festen Zeitraster, liefern können.

Dieses Zeitraster bestimmt aber der wer die Daten braucht ergo kann sogar eine 5 Sekündige Mitteilung Echtzeit sein ... oder sogar eine 5 Minütige ... oder eine nach 20 Tagen.( natürlich etwas Übertrieben ^^ )

und dann auch noch unterscheiden in die Untergruppierungen je nach Anforderung
https://de.wikipedia.org/wiki/Echtzeit

 

[TorenAltair]

[...]
Huhu, die Kiste Bier gehört mir!

Ähem.. Teilen?

 

[floq0r]

Nein, wie soll es echtzeitfähig sein wenn es in einer Umgebung läuft die das nicht ist.

Davon weiß QNX doch nichts. Bist du auf einmal kein echter Mensch mehr nur weil dich jemand mit einer Überwachungskamera beobachtet und du auf seinem Screen als zweidimensionales Bild auftauchst?

 

[AW4]

Ich hab hier mal ein Paper gefunden, das meine Vermutung mit Soft-Real-Time untermauert:
https://hal.archives-ouvertes.fr/ha...on_top_of_a_Hosted_Virtual_Machine_System.pdf

We identified that in the average-case, all the overheads and the latencies commensurate with those measured in the native RTOS which do not influence the schedulability tests of soft real-time applications.

Bzgl. Hard-Real-Time sagt das Paper jedoch etwas anderes, als ich vermutet habe:

Interrupt handling.
When an interrupt is raised by a physical device, it is intercepted by the virtual machine monitor, converted to a virtual interrupt, and injected into the virtual machine. The time to emulate the access to the virtual device and to acknowledge the interrupt must be added to the time during which the interrupt is pending, and until it is accepted by the guest operating system and transferred to the appropriate ISR. As a result, the event latency in the virtualized RTOS is higher than in the native RTOS. To avoid this overhead, hardware manufacturers added a new feature to their processors to enable the virtualization of interrupts. For example, the Intel VT-d [1] feature enables the virtualization of the Advanced Programmable Interrupt Controller (APIC). When this feature is used, the processor will emulate many accesses to the APIC, track the state of the virtual APIC, and deliver virtual interrupts, all in VMX non root operation without any exit from the virtual machine to the virtual machine monitor. Currently, a patch [2] is being developed to support this feature in KVM.

Theoretisch sollte es also mittlerweile möglich sein (zumindest mit KVM) ein RTOS als Gast auf einem nicht-RTOS als echtes RTOS laufen zu lassen, ohne Hardware direkt durchzureichen!
Das Paper ist von 2013.
Kann also gut sein, dass das der Windows 10 Hypervisor auch kann.

Danke für die Antworten. Da lag ich mit meiner Analyse ja nicht falsch.
Huhu, die Kiste Bier gehört mir!

Wär mir da nicht so sicher, ob das jetzt wirklich dein Bierkasten ist...
Mehr Recherche wäre notwendig um das final zu beantworten.

 

[tollertyp]

Ich hätte wissen müssen, dass es Leuten schwer fallen wird, so abstrakt zu denken. Dafür entschuldige ich mich. (Zum Glück aber nicht allen)

Okay, angenommen unser Universum ist eine VM. Und jetzt drückt jemand auf Pause und nach einer beliebigen Dauer geht es weiter. Wir würden nichts mitbekommen, es hat keine Auswirkung bei uns auf den Verlauf der Zeit.

Wichtig ist dabei auch, wo sich der Beobachter befindet, der "bewertet", ob es Echtzeit ist oder nicht.

Okay, was ich damit sagen will: Sieht man die Zeit ebenfalls als simuliert an, dann kann die Echtzeiteigenschaft durchaus erhalten bleiben. Wartest du aber als Beobachter außen darauf, dass deine Ereigniskette in Echtzeit von der VM bearbeitet wird, dann würde ich sagen: Nein, nicht Echtzeit.

Dass Zeit nicht konstant verläuft dürfte jedem klar sein. Es ist unerträglich, wie langsam sie vergeht, um auf die Verfügbarkeit aktueller Hardware zu warten.

 

[floq0r]

Was du ansprichst sind unterschiedliche Bezugssysteme. Das OS ist aber seinerseits von der Hardware "virtualisiert". Könnte man den Betrieb des Rechners konsistent unterbrechen dann würde das OS von dieser Pause ebenfalls nichts mitbekommen.

 

[GrumpyCat]

Theoretisch sollte es also mittlerweile möglich sein (zumindest mit KVM) ein RTOS als Gast auf einem nicht-RTOS als echtes RTOS laufen zu lassen, ohne Hardware direkt durchzureichen!

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

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

 

[xxMuahdibxx]

@floq0r ich sag mal jein denn auch ein Virtuallisiertes System muss ja mit Zeit arbeiten... Ergo muss es irgendwoher diese bekommen wenn nicht durch CPU oder Bios Clock oder Internet.

@GrumpyCat deine Meinung in Bezug auf Echtzeit ist total egal .... und da kannst du mit Argumenten kommen wie du willst .

Der User oder der Prozess legt die Echtzeit fest !

@floq0r und weiterhin wenn das System was die Daten bereistellt in Echtzeit arbeitet ... das System was die Daten anzeigt und Eingaben ermöglicht virtualisiert ist kann sogar das virtuallisierte System abstürtzen der Rest läuft weiter.

Wer sich damit mehr Auseinandersetzen möchte sollte sich dann mal Prozessleitsysteme anschauen wie da herrangegangen wird. Und da ist Echtzeit nicht im ms Bereich ... da reicht je nach Prozess auch viel mehr aus.
https://de.wikipedia.org/wiki/Echtzeitsystem#Beispiele_für_Echtzeitsysteme

P.S.
https://de.wikipedia.org/wiki/Echtzeitbetriebssystem

Entscheidend ist hier nicht die Länge der Frist, sondern dass es überhaupt eine Frist gibt, die zugesichert werden kann.
Das Erfordernis eines Echtzeitbetriebssystem ergibt sich immer dann, wenn Rechner mit der physikalischen Welt messend und/oder steuernd in Verbindung stehen. Das ist das qualitative Erfordernis eines Echtzeitbetriebssystems.

und jetzt zur Notwendigkeit von Echtzeit ... zum Überlegen
https://de.wikipedia.org/wiki/Pechtropfenexperiment
Und jetzt kann man viel darüber diskutieren was man genau braucht ... ;-)

 

[SpamBot]

@floq0r daher schrieb ich ja das für theoretische Tests ist das ganze natürlich kein Problem ist. Ich kenne aber Echtzeitprogramme aus dem Labor oder für Steuerungen. Sobald hier irgendeine Information außerhalb dieses VM Universums kommt geht es natürlich nicht mehr.

 

[tollertyp]

Was anderes wurde AFAIK ja auch gar nicht gesagt...