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