Hallo, System ist ein Windows XP Pro mit Intel DualCore Prozessor. Habe ein Programm geschrieben mit dem ich versuche relativ zyklisch Daten einzulesen/auszugeben. Um überhaupt einigermaßen einen stabiles Timing zu realisiern habe ich mir für die Ausführung meines Programms einen CPU Kern blockiert, bzw. läuft men Programm halt in diesem Kern. Das Programm macht nicht wirklich viel, Daten lesen und schreiben, und es hält stabil den Zyklus von 1ms ein. Frage: XP ist kein Echtzeitbetriebssystem, welche Probleme kann ich in dieser Konstellation noch haben. Sprich gibt es Prozesse die mein Timing durcheinander bringen könnnen? Ausser meinen Programm läuft sonst nichts auf dem Rechner, kein Office, kein gar nichts :-) Trotzdem habe ich da ein wenig Angst? Wie seht Ihr das? Langzeitversuche habe ich noch nicht gemacht, aber erste Messungen ergaben Abweichungen von der 1ms um +/-5%. Mache ich das ganze ohne CPU Kern Reservierung, bin ich Welten von der 1ms und einem stabilen Zyklus entfernt. Gruss Heiko
Wie ich das sehe ? WinXP wurde gar nicht erst als Realtime OS konzipiert. Allenfalls kann man SoftRealTime erreichen mit WinXP-Embedded. Das kann man zumindest zuschneiden sodass es passt. Und dann gibt es noch Zusatzmodule, die im Kernelmodus laufen. So kann man die Realtimeanwendung in einen Treiber packen. Eine bessere Frage ist, ob man das denn auch braucht. Man kann sich viel arbeit und aerger sparen, wenn man die Realtimegeschichten auf einen externen kleinen, oder groesseren Prozessor auslagert, und den PC zu dessen Steuerung und Visualisierung verwendet.
@Heiko, ich würde dir empfehlen auf ein OS wie z.B. Linux mit Realtime Patches zu wechseln. Was nützt es dir wen die aktuelle Lösung zu 99% funktioniert und du wegen dem 1% deine Kunden verlierst. Gruss, Bernd
Ich kann dieses Tool empfehlen. Ist allerdings nicht gerade umsonst. Aber es ist eine einfache Rechnung ob es sich lohnt oder nicht. Viel Arbeit und Aufwand in eine eigene Lösung reinzustecken ist auch teuer. Guckst du hier: http://www.kithara.de Gruß 900ss
>Ausser meinen Programm läuft sonst nichts auf dem Rechner, kein Office, >kein gar nichts :-) Trotzdem habe ich da ein wenig Angst? Aber noch andere Treibermodule. Du musst sicherstellen, dass auf dem einen Kern keine anderen Module mehr laufen.
ich denke das ganze funktioniert sofern im zweiten kern wenig Last besteht, sobald du im zweiten Kern mehr als 70% Auslastung hast gibt es Schwierigkeiten. Wie seht Ihr das?
> Wie seht Ihr das?
Das ist reine Glückssache. Wie schon gesagt wurde ist Windows XP kein
Echtzeit-Betriebssystem, deswegen hat sich jede Frage nach irgendwelchen
Zeit-Garantien schon im Kern erledigt.
Windows XP kann per Definition keine Zeit-Garantien liefern, nicht mal
schwache Garantien der Art "ein Thread mit höchster Priorität wird vom
Scheduler höchstens 100ms am Stück unterbrochen".
Ob dein Programm funktioniert, kann dir also niemand garantieren, es
wird immer Glückssache bleiben.
Die saubere Lösung wäre ganz klar die zeitkritischen Komponenten auf
eine externe Hardware auszulagern. Das ist normalerweise nicht so schwer
und man erspart sich damit viel Ärger.
Echtzeitsysteme die auf/neben Windows laufen und die Anforderungen erfüllen wären z.B. IntervalZero RTX und tenAsys INtime RTOS (beide auch für harte Echtzeit Sachen geeignet) IMO die bessere Lösung bei x86-Systemem wäre VxWorks, QNX, WindowsCE und u.U. eCos oder, wie schon vorgeschlagen, ein dediziertes, nicht x86-basiertes System, für die Echtzeitaufgaben und den Rest mit einem normalen PC erledigen.
@chris danke für die Info, ....aber warum sollte das nicht funktionieren wenn ich zwei Kerne nutze? .....Ich finde einfach keine definitiven Informationen darüber? Wenn ich momentan meine Lösung über Bord werfe brauche ich "harte" Argumente, könnt Ihr mir da welche geben? Mir fehlen einfach fundierte Informationen dazu. Jeder sagt es geht nicht, aber es läuft ja. Nochmal zu meiner Situation. - XP Pro mit DualCore - nur Windows installiert (standard) - Mein Programm reserviert sich meinen Kern exklusiv --> meine Timinganforderungen von 1ms werde bei allen Versuchen eingehalten. Ohne die Reservierung der CPU natürlich nicht (um längen nicht). So, und jetzt sagt mir einer welche Argumente ich da vorbringen kann? Auf dem System wird auch in Zukunft nichts mehr installiert werden. Es wird immer nur mein Programm laufen. Ganz wichtig. Netzwerk ist noch angeschlossen, meine Daten werde über das Netzwerk entsorgt. h
> --> meine Timinganforderungen von 1ms werde bei allen Versuchen > eingehalten. Weiter oben schriebst du > Langzeitversuche habe ich noch nicht gemacht, aber erste Messungen > ergaben Abweichungen von der 1ms um +/-5%. 5% sind ja nicht sooo schlecht, aber eben doch 50µs. Wenn das Betriebssystem dein auf einem eigenen Core laufende Programm völlig in Ruhe lassen würde, wäre der Jitter nur durch Verzögerungen in der Hardware (bei der Busarbitrierung u.ä.) bedingt und läge damit nicht 50µs, sondern mehrere Größenordnungen darunter. Offensichtlich beeinflusst also das Betriebssystem den "Rundlauf" deines Programms, zwar weniger als auf einem nichtreservierten Core, aber immer noch sehr deutlich. Wenn man wüsste, in welcher Form das genau geschieht, könnte man versuchen, für den Jitter eine obere Schranke zu ermitteln. Windows ist aber eine Blackbox, und es gibt, was solche Aspekte betrifft, kaum öffentlich zugängliche Dokumentation. Deswegen musst du davon ausgehen, dass der Jitter sporadisch auch auf 10%, 20% oder mehr anwachsen kann. Könnte man die maximal 5% wirklich garantieren, hätte man einen Weg gefunden, unter Windows ohne teure Zusatzsoftware harte Echtzeit zu machen. Schön wär's :)
angenommen ich würde die zykluszeit z.B. auf 20ms erhöhen, wird dann die Wahrscheinlichkeit eines möglichen Problems geringer? oder nicht? h
heiko wrote: > @chris > > danke für die Info, ....aber warum sollte das nicht funktionieren wenn > ich zwei Kerne nutze? .....Ich finde einfach keine definitiven > Informationen darüber? > > Wenn ich momentan meine Lösung über Bord werfe brauche ich "harte" > Argumente, könnt Ihr mir da welche geben? Mir fehlen einfach fundierte > Informationen dazu. Jeder sagt es geht nicht, aber es läuft ja. > > Nochmal zu meiner Situation. > - XP Pro mit DualCore > - nur Windows installiert (standard) > - Mein Programm reserviert sich meinen Kern exklusiv > > --> meine Timinganforderungen von 1ms werde bei allen Versuchen > eingehalten. Ohne die Reservierung der CPU natürlich nicht (um längen > nicht). > > So, und jetzt sagt mir einer welche Argumente ich da vorbringen kann? http://research.microsoft.com/en-us/um/people/mbj/papers/tr-98-29.html bzw. http://www.grahamwideman.com/gw/tech/dataacq/wintiming.htm (die Links sind teilweise sehr veraltet u.U. über archive.org erreichbar)
ok, das sind alles sehr alte Dokus, NT denke ich ist dann ähnlich wie XP im verhalten?
Wie hast du denn die Reservierung des Kerns realisiert?
heiko wrote: > Wenn ich momentan meine Lösung über Bord werfe brauche ich "harte" > Argumente, könnt Ihr mir da welche geben? Mir fehlen einfach fundierte > Informationen dazu. Jeder sagt es geht nicht, aber es läuft ja. Es gibt ein Totschlagargument: Windows ist nicht echtzeitfähig. Es geht zwar in gewissen Grenzen gut, aber man kann es nicht garantieren. > - Mein Programm reserviert sich meinen Kern exklusiv Soso, wie das? Etwa mit SetProcessorAffinityMask()? > --> meine Timinganforderungen von 1ms werde bei allen Versuchen > eingehalten. Ohne die Reservierung der CPU natürlich nicht (um längen > nicht). Und das würdest du garantieren wollen? Mit deiner Unterschrift dafür haften? Ich weiß ja nicht, wofür es ist, aber wenn was sicherheitsrelevantes dran hängt oder viel wirtschaftlicher Schaden entstehen kann, wenn die Forderungen nicht eingehalten werden....na dann gute Nacht.
Nochmal, wie hast du die Reservierung des Kerns realisiert?
Vermutlich gar nicht. Ich bin zwar jetzt nicht der Oberprogrammierer, aber soweit ich weiß, kann man das aus dem User Space aus nicht. Wäre ja auch noch schöner. Man denke nur dran, was passiert, wenn man nur einen Kern hat. Dann steht der ganze Rechner. Man kann lediglich sagen, dass der Prozess nur auf einem bestimmten (logischen oder realen) Prozessor laufen soll.
Die Affinität heisst doch nur, dass ein Process an einen Kern gebunden ist. Es heisst nicht im Umkehrschluss, dass der Kern nur den einen Prozess ausführt.
daniel wrote: > Die Affinität heisst doch nur, dass ein Process an einen Kern > gebunden ist. Es heisst nicht im Umkehrschluss, dass der Kern > nur den einen Prozess ausführt. Ja, ich weiß das, aber ob der Threadstarter das auch weiß?
Du willst Daten einlesen und ins Netzwerk verschicken. Wozu zur Hoelle braucht man dafuer Windows? Das Totschlagargument hier sind die Lizenzkosten pro System, die dann noch nicht mal das garantieren, was Du willst. Gast3
Man kann dem Prozess auch eine höhere Priorität geben: Task Manager | Processes | Rechtsklick auf den Prozeß | Set Priority | Realtime
Man kann sich auch ein Loch ins Knie bohren und Radieschen reinsäen... Dafür reicht doch ein schnuckliges FreeDOS oder RTLinux. Beide sind vermutlich selbst auf einer alten 400MHz-Gurke näher an der Echtzeit als ein Windows auf Dualcore mit vierfacher Taktfrequenz.
Ich glaub, Heiko liest hier eh nicht mehr mit. Er scheint recht beratungsresistent zu sein, und wir haben ja sein Konzept ad absurdum geführt. Naja. Dafür brauchts nicht mal ein Linux, ein kleiner µC mit LAN reicht da sicher auch aus. So wie er es jetzt hat, kann man jedenfalls für nix garantieren. Schön, wenn´s in den Versuchen gerade mal klappt, aber das kann sich jederzeit ändern, auch ohne extra Software. Und einen Kerjn exclusiv reservieren geht ja eh nich. Das was er sicher gemacht hat, heißt nur, dass deine Anwendung nicht auf 2 Kerne aufgeteilt wird. Trotzdem können noch andere Threads den Kern nutzen. Und der Scheduler von XP hat eh nur 10ms Raster im Normalfall.
Kannst du mal ein etwas quellcode anhängen? Denn sonst ist es bloss raten wie du das Timing umgesetzt hast. Wenn du mit einem Sleep arbeitest dann kann sich ein Fehler aufsummieren.
sorry war am Wochenende nicht online! Also Kern 2 wird reserviert mit SetProcessorAffinityMask()und dann Prio auf Realtime.
Heiko wrote: > sorry war am Wochenende nicht online! Jaja, der Fasching.... > Also Kern 2 wird reserviert mit > SetProcessorAffinityMask()und dann Prio auf Realtime. Aha, hab ich´s doch gewusst. Dann hast du ihn aber immer noch nicht exclusiv für deine Anwendung. Sonst würde ja Windows stehen bleiben, wenn du das auf einem Single-Core machst...
>Also Kern 2 wird reserviert mit >SetProcessorAffinityMask()und dann Prio auf Realtime. Wenn du dir alles genau durchgelesen hättest, wüsstest du schon, was zu tun wäre. Du musst lediglich dafür sorgen, dass alle anderen Module auf dem entsprechenden Kern nicht mehr zur Ausführung kommen. Manuell kannst du dies (nach jedem Start) für die meisten Programme über den Taskmanager erledigen. Es gibt aber auch Automatisationstools von WinNT, die auch unter XP laufen. Die schreiben die Affinitätsmask dauerhaft in eine Konfigdatei, so dass diese sofort nach jedem weiteren Start und für alle Submodule gültig ist. Damit kannst du exklusiv einen Kern (fast) nur für ein Programm reservieren. (In der Praxis spielt dir der Bus natürlich auch noch ein kleines Schnippchen.)
Also soweit ich mich erinnere, lassen sich die Systemtasks nicht vorschreiben, auf welchem Kern sie ausgeführt werden. Windows ist nun mal kein Echtzeitbetriebssystem! Alle Versuche, das zu erreichen, werden zwangsläufig scheitern. Aber mal was ganz anderes: Ist das Programm nur für dich oder sollen das auch andere einsetzen? Du kannst nicht davon ausgehen, dass alle Anwender einen Mehrkernprozessor haben.....
>Alle Versuche, das zu erreichen, werden zwangsläufig scheitern Es gibt auch kommerzielle erweiterungen für Windows die es Realtime fähig machen, unmöglich ist es also nicht. Aber ich denke für heiko sollte dies hier schon reichen. http://www.codeproject.com/KB/system/RealTimeModule.aspx
@Peter:
>Alle Versuche, das zu erreichen, werden zwangsläufig scheitern
Die Aussage bezog sich auf das "handelsübliche" Windows
XP/Vista/irgendwas. Auch bei diesen kommerziellen Erweiterungen bin ich
skeptisch. Ich kann mir gut vorstellen, dass funktionierende,
professionelle "Erweiterungen" den Preis der eigentlichen Windows-Lizenz
bei weitem übersteigen....
Gruß,
Rayk
Ha, Moment! soweit ich mich erinnere, läuft bei Beckhoff nicht der Windows-Teil in Echtzeit! Dort wird die Realtime-Erweiterung für die proprietäre Software-SPS und Bewegungssteuerung genutzt. Bitte verbessere mich, wenn ich mich getäuscht haben sollte. Hier aber geht es aber offensichtlich darum, ein Windows-Programm zu verwenden, dass sich quasi-echtzeitfähig verhalten soll.
Klar kann man Windows echtzeitfähig machen, ist alles eine Frage des Aufwandes. Die Professionellen Tools kosten richtig Geld und tauschen dazu große Teile des Kernels aus. Für weiche Echtzeit muss man nicht ganz so viel hinblättern, aber tiefgreifende Eingriffe in den Kernel sind es trotzdem. So einfach aus dem User Space heraus gehts nur mit Glück, dass es halbwegs stabile Zeiten macht.
> Klar kann man Windows echtzeitfähig machen, ist alles eine Frage des > Aufwandes. Die Professionellen Tools kosten richtig Geld und tauschen > dazu große Teile des Kernels aus. Alternativ sind sie ein eigenes Betriebssystem, unter dem Windows dann in einer Virtualisierung als eigener Task mit geringer Priorität läuft. Ziemlicher Aufwand, nur um krampfhaft an Windows festhalten und damit etwas machen zu können, für das es nicht gedacht ist.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.