Echtzeit vs. Windows



  • ein timer, der auf die millisekunde genau ist, gehört eigentlich nicht zum profil eines echtzeitbetriebssystems. das können dir schon die meisten unix systeme liefern. die anforderungen an echtzeit sind garantierte obere schranken. diese schranken können aber durchaus ein intervall von z.b. 100ms haben.



  • ich glaube darum ging es dem threadstarter auch. garantiert einmal pro ms was abarbeiten koennen.
    das kann weder windows noch linux liefern afaik. die chancen sind zwar gut dass es klappt, aber eben nicht garantiert.
    eventuell hilft dir 'REALTIME_PRIORITY_CLASS'.



  • kautz|logged_out schrieb:

    Hi,
    ob ihr es glaubt oder nicht, ich progge ein Atomkraftwerk in VB.

    *panik_kofferpack_auswander*



  • kautz|logged_out schrieb:

    Hi,
    ob ihr es glaubt oder nicht, ich progge ein Atomkraftwerk in VB.

    kool
    zeig mal den kot



  • Na er schreibt sicherlich nicht die tatsächliche Steuerung für die Reaktoren, denn die wird nicht unter Windows laufen, daher ist es kein Grund zum Auswandern :).

    Zur Frage: es gibt kein "nichts installiert außer Windows XP". Es sind sicherlich diverse Treiber installiert, die evtl. längere Wartezeiten erzeugen können. Außerdem ist die PC-Architektur nicht auf Determinismus ausgelegt, es könnte schon hardwarebedingt sein, dass du 1ms nie sicher erreichen wirst. Jitter mal außen vor gelassen...



  • http://de.wikipedia.org/wiki/RTAI

    rtai linux kann dir unter bestimmten umständen harte ausführungszeiten im userspace garantieren.



  • also ich programmiere auch gerade die Steuerung für mein Kernkraftwerk (hab ich mir neulich gebaut, als mir langweilig war) und wollte das auch erst mit VB machen, aber damit geht das echt nicht so gut, ich bin dann auf RTL (real time linux) umgestiegen und es funktioniert super!



  • Heizellotto schrieb:

    also ich programmiere auch gerade die Steuerung für mein Kernkraftwerk (hab ich mir neulich gebaut, als mir langweilig war) und wollte das auch erst mit VB machen, aber damit geht das echt nicht so gut, ich bin dann auf RTL (real time linux) umgestiegen und es funktioniert super!

    Clown gefressen?

    @OP: Was ist das denn für ein Atomkraftwerk das du da machst? Ne simulation, oder steckt pseudo hardware dahinter?

    Wenn das nur ne Simulation ist, ist dann Echtzeit so wichtig, bzw. wird da Ergebniss so verfälscht durch nicht-echtzeit-fähigkeit?



  • Superlexx schrieb:

    Außerdem ist die PC-Architektur nicht auf Determinismus ausgelegt, es könnte schon hardwarebedingt sein, dass du 1ms nie sicher erreichen wirst.

    computer sind immer deterministisch, so lange man keine äusseren einflüsse zulässt. was soll denn 'nen PC so lange bremsen, dass man 'ne auflösung von 1ms nicht hinbekommt?
    🙂



  • fricky schrieb:

    Superlexx schrieb:

    Außerdem ist die PC-Architektur nicht auf Determinismus ausgelegt, es könnte schon hardwarebedingt sein, dass du 1ms nie sicher erreichen wirst.

    computer sind immer deterministisch, so lange man keine äusseren einflüsse zulässt. was soll denn 'nen PC so lange bremsen, dass man 'ne auflösung von 1ms nicht hinbekommt?
    🙂

    das windows den process wechselt, z.b. um irgend nen timer zu updaten oder zu testen ob irgendwelche pages vom speicher ausgelagert werden koennten.
    und da eine zeitscheibe unter windows ca 10ms sind, ist dein thread fuer die 10ms weg vom fenster.
    sollte zwar nicht passieren, aber es ist eben nicht garantiert dass es doch passiert.



  • rapso schrieb:

    fricky schrieb:

    Superlexx schrieb:

    Außerdem ist die PC-Architektur nicht auf Determinismus ausgelegt, es könnte schon hardwarebedingt sein, dass du 1ms nie sicher erreichen wirst.

    computer sind immer deterministisch, so lange man keine äusseren einflüsse zulässt. was soll denn 'nen PC so lange bremsen, dass man 'ne auflösung von 1ms nicht hinbekommt?
    🙂

    das windows den process wechselt, z.b. um irgend nen timer zu updaten oder zu testen ob irgendwelche pages vom speicher ausgelagert werden koennten.
    und da eine zeitscheibe unter windows ca 10ms sind, ist dein thread fuer die 10ms weg vom fenster.
    sollte zwar nicht passieren, aber es ist eben nicht garantiert dass es doch passiert.

    es geht um die PC-architektur, also die hardware ohne windows, linux oder irgendein multitasking-OS etc. die sollte doch wohl mit konstantem takt usw. laufen. oder?
    🙂



  • @fricky:
    Jain. PCs sind oft Flickwerk.

    Wenn da in Komponente X ein Fehler ist der erst zu spät gefunden wird, dann wastelt der Hersteller solange im BIOS rum bis er den Fehler irgendwie fixen kann. Das sieht dann manchmal (oft?) so aus dass über den System-Management-Interrupt (das ist der den du nicht maskieren kannst, bzw. genauer gesagt: der je nach Chipset anders zu maskieren ist) irgendwas hingefummelt wird. Und das führt dann manchmal (oft?) dazu dass der PC ziemlich unvorhersehbar einfach eine Pause von X Takten macht -- weil die CPU halt damit beschäftigt ist im System-Management-Mode irgendwelchen flickwert Code auszuführen damit Fehler X sein hässliches Gesicht nicht zeigen kann.
    Damit ist "Echtzeit" schonmal gestorben.

    Mit ausgewählter, kontrollierter Hardware (inklusive BIOS Versionen) kann man das natürlich vermeiden.

    http://en.wikipedia.org/wiki/System_Management_Mode :

    Operations in SMM take CPU time away from the OS, since the CPU state must be stored to memory (SMRAM) and any write back caches must be flushed. This can destroy real-time behavior and cause clock ticks to get lost.



  • BorisDieKlinge schrieb:

    Clown gefressen?

    Jo, hab heute morgen nen Clown gefrühstückt.



  • Echtzeit vs. Windows

    Diese ganze Diskussion erübrigt sich schon daher, dass die "normale" PC Hardware nicht echtzeitfähig ist.

    1. Caches verhindern Echtzeitfähigkeit:
    Cache im Prozessor, Ram, Festplatte haben Zugriffszeiten die sich um 10er Potenzen unterscheiden. Da die Pageersetzungen von modernen Prozessoren nicht beinflußbar sind, geht die Vorhersagbarkeit und damit die echtzeitfähigkeit verlohren.

    2. Interrupts verhindern Echtzeitfähigkeit:
    Es ist kaum vorhersagbar ob die Hardware nicht irgendwelchen zeitlichen Abhängigkeiten beim Abarbeiten von Interrupts unterliegen. Und der Interrupt selbst ist auch Gift, wenn er in einer harten Deadline auftritt.

    3.Eternet ist nicht echtzeitfähig:
    Ethernet Netzwerkkarten arbeiten mit Kollisionserkennung (nicht Vermeidung) und sind daher nicht echtzeitfähig.

    Daher erübrigen sich diese "Windows ist nicht echtzeitfähig, Linux schon" Erörterungen. Denn auf dieser "normalen" Hardware ist kein Betriebssystem echtzeitfähig, weil es die Hardware schon nicht ist.



  • lasst uns ne echtzeit hardware bauen:) wäre doch was für dich Heinzelotto ^^



  • 1. Caches verhindern Echtzeitfähigkeit:
    Cache im Prozessor, Ram, Festplatte haben Zugriffszeiten die sich um 10er Potenzen unterscheiden. Da die Pageersetzungen von modernen Prozessoren nicht beinflußbar sind, geht die Vorhersagbarkeit und damit die echtzeitfähigkeit verlohren.

    Falsch. Es lässt sich eine (vernünftige) Obergrenze finden wo man garantieren kann dass die Zeit die nötig ist um Operation X durchzuführen nie drüber liegen wird. Die Festplatte kann man zudem einfach aus der Rechnung rausnehmen indem man einfach Seiten in den Speicher sperrt, bzw. ein System verwendet welches garnicht erst anfängt irgendwas zu pagen.

    2. Interrupts verhindern Echtzeitfähigkeit:
    Es ist kaum vorhersagbar ob die Hardware nicht irgendwelchen zeitlichen Abhängigkeiten beim Abarbeiten von Interrupts unterliegen. Und der Interrupt selbst ist auch Gift, wenn er in einer harten Deadline auftritt.

    WTF?
    Zeitliche Abhängigkeiten beim Abarbeiten von Interrupts? Geht es bitte noch etwas nebulöser?

    3.Eternet ist nicht echtzeitfähig:
    Ethernet Netzwerkkarten arbeiten mit Kollisionserkennung (nicht Vermeidung) und sind daher nicht echtzeitfähig.

    WTF^2?
    Schonmal auf die Idee gekommen die Netzwerkkarte einfach nicht an Stellen zu verwenden wo man Echtzeit garantieren muss? Und... wusstest du dass es auch was anderes neben Ethernet gibt?



  • Das ist eben das Problem, daß man auch den Begriff "Echtzeitfähigkeit" im Kontext der Aufgabe definieren kann.

    In der chemischen oder verfahrenstechnischen Industrie heißt Echtzeit oft "im Bereich von Minuten", und diese Zeit kann man problemlos mit einem normalen OS garantieren.

    Es gibt auch noch trickreiche Varianten, indem man z.B. nur einige wenige Operationen im Millisekundenbereich (z.B. Motorsteuerung, Reaktion auf einen Trigger) in einer SoftSPS im PC macht, den Rest aber im PC. So ein System deckt auch die Anforderung Echtzeit problemlos ab. Z.B. Triggerauswertung in der SoftSPS, aber die darauf folgende Bildverarbeitung im PC. Damit kommt man ohne Schwierigkeiten auch mit .NET in Taktzeiten unterhalb einer Sekunde. Das ist in der diskreten Fertigung schon eine sehr hohe Maschinentaktzeit.

    Ich würde diese Frage nicht so schwarz-weiß sehen.



  • Marc++us schrieb:

    Das ist eben das Problem, daß man auch den Begriff "Echtzeitfähigkeit" im Kontext der Aufgabe definieren kann.

    In der chemischen oder verfahrenstechnischen Industrie heißt Echtzeit oft "im Bereich von Minuten", und diese Zeit kann man problemlos mit einem normalen OS garantieren.

    Es gibt auch noch trickreiche Varianten, indem man z.B. nur einige wenige Operationen im Millisekundenbereich (z.B. Motorsteuerung, Reaktion auf einen Trigger) in einer SoftSPS im PC macht, den Rest aber im PC. So ein System deckt auch die Anforderung Echtzeit problemlos ab. Z.B. Triggerauswertung in der SoftSPS, aber die darauf folgende Bildverarbeitung im PC. Damit kommt man ohne Schwierigkeiten auch mit .NET in Taktzeiten unterhalb einer Sekunde. Das ist in der diskreten Fertigung schon eine sehr hohe Maschinentaktzeit.

    Ich würde diese Frage nicht so schwarz-weiß sehen.

    Echtzeit heißt einfach nur rechtzeitig. Das hat nicht mit Geschwindigkeit zu tun.



  • Eingebettete Systeme schrieb:

    Echtzeit vs. Windows

    Diese ganze Diskussion erübrigt sich schon daher, dass die "normale" PC Hardware nicht echtzeitfähig ist.

    1. Caches verhindern Echtzeitfähigkeit:
    Cache im Prozessor, Ram, Festplatte haben Zugriffszeiten die sich um 10er Potenzen unterscheiden. Da die Pageersetzungen von modernen Prozessoren nicht beinflußbar sind, geht die Vorhersagbarkeit und damit die echtzeitfähigkeit verlohren.

    2. Interrupts verhindern Echtzeitfähigkeit:
    Es ist kaum vorhersagbar ob die Hardware nicht irgendwelchen zeitlichen Abhängigkeiten beim Abarbeiten von Interrupts unterliegen. Und der Interrupt selbst ist auch Gift, wenn er in einer harten Deadline auftritt.

    3.Eternet ist nicht echtzeitfähig:
    Ethernet Netzwerkkarten arbeiten mit Kollisionserkennung (nicht Vermeidung) und sind daher nicht echtzeitfähig.

    Daher erübrigen sich diese "Windows ist nicht echtzeitfähig, Linux schon" Erörterungen. Denn auf dieser "normalen" Hardware ist kein Betriebssystem echtzeitfähig, weil es die Hardware schon nicht ist.

    Klar, außerdem muß man die Laufzeitverzögerungen jedes Signals berücksichtigen. Beträgt immerhin einige Nano- bis Picosekunden pro Transistor.



  • Die Diskussion hat ein bißchen von der folgenden Situation:

    Ein Mann schaut sich mit dem Mikroskop eine Blattlaus an. Entsetzt schreit er auf und rennt davon: "Hilfe, da sitzt ein Monster auf meinem Schreibtisch."

    🤡


Anmelden zum Antworten