Echtzeit vs. Windows



  • Ich behaupte mal: mit VB wirst du das nicht so ohne weiteres hinbekommen. Mit oder ohne Echtzeiterweiterung. Und schon garnicht auf 1ms genau.



  • Warum meinst du, dass du sowas brauchst und vorallem warum mit VB?



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



  • kautz|logged_out schrieb:

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

    cool! kennste 'duck hunt'? das war auch komplett in vb gemacht.
    🙂



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

    Oh nein, was für eine Fehlentscheidung für die Wahl der Programmiersprache!



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


Anmelden zum Antworten