hallo, matlab hat es geschafft echtzeitprogramme auf windows laufen zu lassen. siehe http://de.mathworks.com/products/rtwt/. matlab spuckt also auf knopfdruck ein programm aus, das auf windows in echtzeit läuft?!? Ich dachte immer das geht nicht... das höchste der gefühle war ja bisher, dass man ein echtzeitbetriebssystem installiert und windows dann als task unter diesem läuft, was in der praxis immer mit vielen nebenwirkungen verbunden war. auf diese weise konnte man neben windows einen anderen task in echtzeit laufen lassen. da aber matlab es hingekriegt hat, frage ich mich, wie man selber echtzeitprogramme fuer windows schreiben kann. da muss doch windows irgendwie einen api-zugang zu dieser echtzeit-funktionalität bieten? weiss einer wonach ich suchen muss, um sowas selber zu proggen? (letztendlich glaub ich matlab das auch erst, wenn ich sehe, wie das in der theorie geht) danke schonmal fuers lesen lg
Realtime != Realtime !!! Zitat: "Real-time performance approaching 1 kHz in normal execution mode Real-time performance approaching 20 kHz in external execution mode (with Simulink Coder)"
Test schrieb: > Zitat: > "Real-time performance approaching 1 kHz in normal execution mode > Real-time performance approaching 20 kHz in external execution mode > (with Simulink Coder)" Wobei 1 kHz für Windows durchaus schon ziemlich viel ist. Aber offenbar sind sich die Jungs von mathworks selbst nicht so ganz einig, was da geht: ▪ Real-time performance approaching 500 Hz in normal execution mode ▪ Real-time performance approaching 20 kHz in external execution mode (with Simulink Coder) http://de.mathworks.com/products/datasheets/pdf/real-time-windows-target.pdf Ich frage mich auch, ob das wirklich Echtzeit ist, also z.B. auch funktioniert, wenn der Speicher voll ist und der Rechner mit Auslagerungsorgien anfängt und dabei gleichzeitig eine fork-Bombe gestartet wird. Außerdem stört mich das Wort "approaching". Heißt das nun, daß die Software das definitiv kann, oder nur, daß man sich vorstellen könnte, daß es funktioniert?
Man kann unter Windows schon was mit Echtzeit machen. Ist nur ein bisschen tricky ;-) Wir machen das so: - Per Hypervisor ein paar Kerne der CPU abgreifen - Dort ein Windows Embedded Compact 2013 (= RTOS) laufen lassen - Teile der Anwendung in diesen Echtzeitteil verlagern - Beide Teile dann nach Bedarf kommunzieren lassen
Boris P. schrieb: > - Per Hypervisor ein paar Kerne der CPU abgreifen > - Dort ein Windows Embedded Compact 2013 (= RTOS) laufen lassen > - Teile der Anwendung in diesen Echtzeitteil verlagern > - Beide Teile dann nach Bedarf kommunzieren lassen Nur das bedeutet ja ebend das unter dem "normalen" Windows nichts realtime läuft!
Ohne jetzt einen Streit Windows<->Linux losbrechen zu wollen, fand ich das in Linux besser gelöst. Ich habe dort mal mit xenomai gearbeitet. Das ist eine Echtzeiterweiterung, die im Kernel läuft. Da gibt's auch einen Echtzeitscheduler und einen darauf aufsetzenden Linux-Scheduler. Das tolle ist aber, dass man Echtzeit- und Linux-Tasks innerhalb eines gemeinsamen Prozesses haben kann. Und die Tasks können sogar nach Bedarf dynamisch zwischen non-Realtime- und Realtime-Modus wechseln. Bei PREEMPT_RT geht man dann noch einen Schritt weiter und bietet Echtzeit ganz ohne separate Erweiterung an. Man kann einfach direkt die normalen Linux-Funktionen verwenden, um Echtzeit-Tasks zu erstellen. Das einzige, was man dazu gegenüber einen gewöhnlichen Desktop-Linux-System braucht, ist der Echtzeit-gepatchte Kernel, da noch nicht alle Funktionalitäten in den Standard-Kernel eingeflossen sind.
Max Mustermann schrieb: > Nur das bedeutet ja ebend das unter dem "normalen" Windows nichts > realtime läuft! Ohne entsprechende Kernelerweiterungen ist das korrekt. Windows ist kein RT-OS, genauso, wie Linux auch kein RT-OS ist. Für beide gibt es aber entsprechende Kernelerweiterungen, bei Windows sind diese natürlich kommerziell - wie z.B. http://www.kithara.de/de
Test schrieb: > Realtime != Realtime !!! Das was die anbieten ist meiner Meinung nach überhaupt nicht Realtime, denn Realtime bedeutet nicht schnell, sondern nur schnell genug, aber das eben garantiert. Unter Windows wird so etwas FAST immer funktionieren, aber nur fast. Garantieren kann man eine bestimmte Antwortszeit unter Windows nicht, nicht mal eine ganze Sekunde. Georg
Was spricht eigentlich dagegen sich von Windows als Echtzeitrechner zu loesen und auf einen Controller auszulagern ? Wenn man sich etwas mit einem Problem befasst hat muss man es nicht mehr in Matlab laufen lassen.
Boris P. schrieb: > Man kann unter Windows schon was mit Echtzeit machen. Ist nur ein > bisschen tricky ;-) > > Wir machen das so: > - Per Hypervisor ein paar Kerne der CPU abgreifen > - Dort ein Windows Embedded Compact 2013 (= RTOS) laufen lassen > - Teile der Anwendung in diesen Echtzeitteil verlagern > - Beide Teile dann nach Bedarf kommunzieren lassen Welchen real time hypervisor kannst du empfehlen?
Auf einem PC (egal ob Windows oder Linux) will man bei solcherlei Anforderungen auch eine System haben das den SMM[1] nicht verwendet. [1] http://de.wikipedia.org/wiki/System_Management_Mode
Jetzt Nicht schrieb: > Wenn man sich etwas mit einem Problem befasst hat muss man es nicht mehr > in Matlab laufen lassen Wenn ich den Ansatz richtig verstehe, ist das dafür gedacht, ein System unter Windows halbwegs realistisch zu testen, da machen gelegentliche Aussetzer ja nichts, man weiss dass das unter Windows vorkommt. Ein Kernkraftwerk kann man so nicht betreiben, aber das war auch nicht die Idee. Was man auf dem PC getestet hat, kommt dann auf ein "echtes Echtzeitsystem". Georg
Μαtthias W. schrieb: > Auf einem PC (egal ob Windows oder Linux) will man bei solcherlei > Anforderungen auch eine System haben das den SMM[1] nicht verwendet. Ja, der ist ärgerlich. Vor allem benutzen manche Hersteller den, um Bugs in der Hardware zu kaschieren. Georg schrieb: > Wenn ich den Ansatz richtig verstehe, ist das dafür gedacht, ein System > unter Windows halbwegs realistisch zu testen, da machen gelegentliche > Aussetzer ja nichts, man weiss dass das unter Windows vorkommt. Das dann allerdings als Echtzeit zu verkaufen, finde ich etwas dreist.
hmmm... fazit also? Echtzeit ist auf PC möglich. Muss neben Windows ein weiteres RTOS laufen lassen (wie beim trick mit hypervisor). Frage ist, ob matlab etwas dergleichen im hintergrund tut? das wird wohl nicht so leicht herauszufinden sein... denn egal wie matlab das umgesetzt hat, wird matlab immer von echtzeit reden. Rufus Τ. Firefly schrieb: > Windows ist kein RT-OS, genauso, wie Linux auch kein RT-OS ist. > > Für beide gibt es aber entsprechende Kernelerweiterungen, bei Windows > sind diese natürlich kommerziell - wie z.B. http://www.kithara.de/de wie hab ich mir die kernelerweiterung vorzustellen? wie soll man denn den kernel von windows erweitern können, da windows quasi black box? oder meint ihr, dass kithara da direkt mit microsoft zusammenarbeitet? wie bereits gesagt, bin ich immer davon ausgegangen, dass tools wie kithara einen task haben, in dem dann windows laeuft. Μαtthias W. schrieb: > Auf einem PC (egal ob Windows oder Linux) will man bei solcherlei > Anforderungen auch eine System haben das den SMM[1] nicht verwendet. und sowas ist auch etwas, was mich immer wieder verunsichert. oft liest man auch, dass diese PC-prozessoren an sich gar nicht fuer echtzeit ausgelegt sind und daher auch gar kein RTOS darauf laufen kann (so laufen, dass echtzeit garantiert wird). problem ist nur... wer ist schon mit der ganzen architektur von den prozessoren vertraut, so dass dieser auch eine kompetente aussage dazu machen kann... man, man, man... wann ist das alles so kompliziert geworden ;)
Sina Anargo schrieb: > wie bereits gesagt, bin ich immer davon ausgegangen, dass tools wie > kithara einen task haben, in dem dann windows laeuft. man könnte ja einfach mal auf der Webseite lesen. Dort steht, das sie alles im Kernel laufen lassen, also wie ein Treiber.
Sina Anargo schrieb: > und sowas ist auch etwas, was mich immer wieder verunsichert. oft liest > man auch, dass diese PC-prozessoren an sich gar nicht fuer echtzeit > ausgelegt sind und daher auch gar kein RTOS darauf laufen kann (so > laufen, dass echtzeit garantiert wird). Naja, man kann nicht die selben Erwartungen, wie an einen µC haben. Viele glauben immer, da der PC ja im Vergleich irrsinnig schnell ist, daß auch Echtzeit da besonders gut drauf funktionieren muss, mit kürzesten Latenzzeiten und extrem kurzen Zykluszeiten. Das stimmt aber eben so nicht. Selbst ein AVR kann im Bezug darauf mit einem PC mithalten. Das liegt an verschiedenen Faktoren. Einer davon ist, daß der PC auf hohen Durchsatz ausgelegt ist und nicht auf geringe Latenz. Das heißt vereinfacht gesagt, er muss im normalen Betrieb eher selten auf ein Ereignis reagieren, aber dann jedesmal einen großen Block Daten auf einmal verarbeiten. Und genau darin ist der PC richtig gut. Und dann gibt es da die leidigen nichtmaskierbaren Interrupts, die z.B. für's ACPI-Powermanagement verwendet werden und eben zum Teil auch, um im Hintergrund irgendwelche Work-Arounds für Bugs in der Hardware zu triggern. Diese sind wie der Name vermuten läßt nicht abschaltbar und können jederzeit dazwischenfunken. Wenn die ISR dann lange braucht, weil sie auf irgendwelche externe Hardware warten muss, ist der Prozessor so lange blockiert. Und dann gibt's da natürlich noch die Peripherie, die ja nicht einfach wie beim µC direkt am Prozessor hängt, sondern meist über mehrere verschiedene Busse, die ihrerseits auch wieder nicht auf geringe Latenz, sondern auf hohen Durchsatz optimiert sind. > problem ist nur... wer ist schon mit der ganzen architektur von den > prozessoren vertraut, so dass dieser auch eine kompetente aussage dazu > machen kann... man, man, man... Deshalb gibt's bei der OSADL eine Testfarm, wo verschiedene Rechner (nicht nur PCs) getestet werden im Bezug auf die Echtzeitfähigkeit. Das sagt noch nichts über die Peripherie aus, aber zumindest, ob der Rechner selbst eine Problem hat. Hier kann man mal die Unterschiede sehen: https://www.osadl.org/Latency-plot-of-system-in-rack-b-slot.qa-latencyplot-rbs1.0.html https://www.osadl.org/Latency-plot-of-system-in-rack-1-slot.qa-latencyplot-r1s8.0.html Man beachte die Ausreißer im zweiten Bild und die Angabe der höchsten gemessenen Latenz im Vergleich zum ersten.
:
Bearbeitet durch User
Angehängte Dateien:
-
DPCLAT.PNG
7,6 KB
Ein kurzer Test ob einem auf dem eigenen System Interrupts "quer" kommen ist grob mit dem DPC Latency Checker moeglich.
@rolf magnus: wow, danke für die ausführliche Antwort... auf jeden fall wieder was dazugelernt. thx
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.