Echtzeitgarantie unter Windows XP
#1
geschrieben 12. April 2012 - 07:40
Ich weiß, dass XP kein Echtzeitbetriebssystem ist und man daher auch keine Garantie darauf bekommen kann.
Dennoch sitze ich gerade an meiner Diplomarbeit und muss versuchen etwas auf einem Laptop zu simulieren, bei dem ich ansich Echtzeit garantieren müsste.
Ich muss also untersuchen, inwiefern das Programm, was die Simulation gewährleistet, Zugriffszeiten gewährt bekommt, bzw. wie lange es warten muss.
Ziel soll es sein eine Einschätzung treffen zu können, ob das Programm in einem vertretbaren Rahmen antwortet.
Ich hab versucht bei Google danach zu suchen, aber ich finde anscheinend keine korrekten Suchworte.
Kennt jemand ein Programm oder eine Umgebung, die ungefährt meinen Erwartungen gerecht werden könnte?
Um es auf den Punkt zu bringen:
Ich muss Windows XP nutzen (kein Echtzeitbetriebssystem, ist mir bekannt) um ein Programm möglichst Echtzeitnah zum laufen zu bringen.
Ich suche ein Tool, dass mir die Performance aufzeigt. Wie schnell bekommt das Programm wieder Rechnenzeit, wieviel Verzögerung hat es usw...
Ich muss eben gucken, ob das Programm in einem vertretbaren Rahmen agiert oder nicht.
Vielen Dank für Eure Bemühungen (allein das ihr bis hier gelesen habt )
Mit freundlichen Grüßen,
Stephan.
Anzeige
#2
geschrieben 12. April 2012 - 08:26
Taskmanager öffnen, Task raussuchen der in Echtzeit laufen soll, Rechtsklick > Priorität > "Echtzeit"
kann aber sein, dass XP hier bei "hoch" aufhört.
wie sehr die "Echtzeit" als "Echtzeit" zu verstehen ist kann dir aber nur MS selbst sagen. XP ist nunmal kein Echtzeit-System wie du schon richtig erkannt hast.
Zum Monitoring mal schauen ob "ProcessExplorer" (kostenfrei, Sysinternals mal nach googlen) ausreicht.
@Ler-Kuhn: Sieht mir nicht wirklich nach Sven-Uwe aus
#3
geschrieben 13. April 2012 - 08:34
danke für deine Antwort!
Ja auch unter XP gibt es schon den Punkt "Echtzeit". Allerdings wird an mehreren Stellen darauf hingewiesen, dass dann Systemwichtige Prozesse darunter leiden können.
Zudem, wie du bereits erwähnt hast, gearantiert diese Option keine Echtzeit (wie auch bei einem System, das nicht Echtzeit ist ).
Den ProcessExplorer werde ich mir mal angucken, allerdings siehts auf dem ersten Blick so aus, als würde man damit nur den Umfang von Prozessen (wie viele Threads, wieviel Speicher usw.) messen können und keine Zeitangaben bekommen.
LG,
ich.
#4 _lennard_
geschrieben 17. April 2012 - 09:20
#5
geschrieben 18. April 2012 - 07:44
Ich muss eben zeigen, dass das wirklich auch unter Windows XP klappt, bzw zeigen, dass dem nicht so ist
Dieser Beitrag wurde von Memnoch1337 bearbeitet: 18. April 2012 - 07:45
#6
geschrieben 02. Juli 2012 - 22:23
tja das mit der Echtzeit ist so eine Sache - es gibt halt keine halbe Echtzeit, d.h. ein wiederkehrendes Ereignis oder ein Signal muss innerhalb einer vorab definierten Abweichung jederzeit erfassbar oder auslösbar sein.
Nun die Voraussetzung für diese Forderung ist ein Betriebssystem mit verschachtelter Interrupt-Verarbeitung, oder mit einer nicht-präemptiven zeitgesteuerter Task-Verteilung.
Windows funktioniert mit einer prioritätsgesteuerten präemtiver Task-Verteilung, was systembedingt nicht geändert werden kann.
Daher spielt es mathematisch keine Rolle, ob die Task-Verzögerung unter Windows 1ms, 10ms oder 1 Minute beträgt - das ist zwar schwer zu aktzeptieren, ist jedoch eine Tatsache.
Wenn wir unter Windows von Determinismus reden, reden wir über ein durchschnittliches Zeitverhalten.
Was bringt das nun für die Aufgabenstellung (10ms Determinismus) ?
Auf der Applikationsebene unter Windows arbeiten die Tasks mit der System-Priorität IRQL-PASSIVE (niederste Systempriorität). Die daraus resultierende Gauss-Verteilung läßt grob geschätzt Abweichungen bis zu 200ms (je nach Plattform) zu.
Im Gegensatz dazu kann im Windows-Kernel mit höheren System-Prioritäten gearbeitet werden - doch Vorsicht - damit werden locker alle Applikationstasks blockiert. Daher muss ein zweiter Scheduler installiert werden, um ein quasi-deterministisches Ablaufverhalten zu erreichen.
Alles in Allem - es ist die Quadratur des Kreises - und glaubt mir, vielen haben Wochen und Monate an Entwicklungszeit investiert, nur um am Ende aufgeben zu müssen. Das ist das Existenzrecht von Echtzeit-SubSystemen für Windows.
#7
geschrieben 03. Juli 2012 - 10:27
#8
geschrieben 03. Juli 2012 - 10:33
Zitat (Holger_N: 03. Juli 2012 - 10:27)
Während Word eine für dich nicht wahrnehmbare Verzögerung aufweist, sind andere Vorgänge da deutlich kritischer. Lies die Posts vor deinem, da ist die Rede von recht konkreten Zeitwerten.
Per harter Definition ist ein Echtzeitbetriebssystem eins, das eine Höchstlatenz garantiert. Jetzt kann man die Latenz zwar auch mit ein paar Sekunden ansetzen, darum geht es aber nicht. Denke Sensortechnik, denke Prozesssteuerung, denke Boardcomputer vom Flugzeug. Da sind die tolerierbaren Verzögerungen deutlich unterhalb der paar Sekunden, die bei Word in Ordnung gehen.
Dieser Beitrag wurde von Kirill bearbeitet: 03. Juli 2012 - 10:34
DiskCache=AllocateMemory(GetTotalAmountOfAvailableMemory);}
#9
geschrieben 03. Juli 2012 - 11:07
#10
geschrieben 03. Juli 2012 - 11:38
Dieser Beitrag wurde von Kirill bearbeitet: 03. Juli 2012 - 11:39
DiskCache=AllocateMemory(GetTotalAmountOfAvailableMemory);}
#11
geschrieben 03. Juli 2012 - 12:22
Zitat (Kirill: 03. Juli 2012 - 11:38)
Das heißt doch aber auch nur, dass irgendjemand die 200 ms als Grenzwert festgelegt hat. Wenn dann für irgendwas 150 ms benötigt werden, dann wäre das nach dieser Festlegung "Echtzeit". Das nutzt doch aber jemandem, der höchstens 100 ms tolerieren kann dann auch nichts. Für den ist es dann auch keine Echtzeit auch wenn man es per Definition so bezeichnen dürfte.
#12 _Volume Z_
geschrieben 03. Juli 2012 - 12:36
#13
geschrieben 03. Juli 2012 - 12:48
Zitat (Holger_N: 03. Juli 2012 - 12:22)
DiskCache=AllocateMemory(GetTotalAmountOfAvailableMemory);}
#14
geschrieben 03. Juli 2012 - 12:56
Zitat (Volume Z: 03. Juli 2012 - 12:36)
Schreiben das Gleiche wie ich, nur fachmännischer formuliert.
Zitat
Zitat (Kirill: 03. Juli 2012 - 12:48)
Ich bezog mich da auf den Ausgangsbeitrag in welchem steht, dass XP kein Echtzeitsystem wäre. Nachdem was jetzt hier so steht käme es doch aber auf die Ansprüche des Nutzers an und XP wäre ein Echtzeitsystem, wenn die Verarbeitungszeitspannen für den User tolerabel sind.
#15
geschrieben 03. Juli 2012 - 13:17
Zitat (Holger_N: 03. Juli 2012 - 12:56)
Dieser Beitrag wurde von Kirill bearbeitet: 03. Juli 2012 - 13:59
DiskCache=AllocateMemory(GetTotalAmountOfAvailableMemory);}