Hallo, sag mal kennt Ihr irgendwo Quellen in den steht bis zu welchem Zeitraster man sich in einem Betriebssystemen sicher sein kann, dass ein Prozess an die Reihe kommt? Also ein klasssicher Standardrechner mit vielleicht 1 GHz und einer normalen Aulastung. Also primär würd ich es bei Windows wissen wollen. Nicht weil ich etwas machen will nur rein aus Interesse halber. Wenn ich einen Timer brauch der 100%ig jede 100ms etwas aufrufen soll, kann ich davon ausgehen das das klappt oder ist das alles andere als Planbar? Ich kenn nur Linux und da ist das alles kein Problem. Man muss es halt nus pro Rechner messen aber 10 ms Takt ist eigentlich immer möglich. Mir wurde nur gestern gesagt das im Windows sogar im Sekundenbereich zu dicken Verzögerungen kommt. Ich will das irgendwie nicht glauben das Windows da wirklich so katastophal ist ... Kann mir das jemand beantworten?
Wie soll ein OS echtzeitfähig sein, wenn es noch nicht mal die Hardware ist???
Das geht bei Windows nicht. Eben weil man nicht garantieren kann, dass ein Prozess irgendwann drankommt, ist es nicht echtzeitfähig. Man kan z.B. durch einen Treiber oder irgendwas kernel-nahes das ganze System bis zum Sankt-Nimmerleins-Tag stilllegen. Schöne Kandidaten sind solche Frickel-Treiber für direkte Hardwarezugriffe....
Echzeit heisst ja nicht mit volldampf bis alles glüht es reich ja auch wenn ich gewiss jede Sekunde einen Wert abholen kann usw..... @Christian ok aber berechnen kann man dann wirkich nichts im vorhinein. Da gibts keine Zeitbasis die man irgendwie pauschal beantworten kann? Also ich red wieder von einem klassischen Rechner ohne viel Last und Schnickschnack
Man kann Windows mit einer Echtzeiterweiterung versehen. Diese sitzt dann aber eher über dem OS. Das ganze kommt bei Soft-SPSen zum Einsatz und bietet dort eine recht hohe Performance. CoDeSys RTE ist so eine Soft-SPS gibt es aber auch von anderen Herstellern.
Und was hat man dann da so für Zeiten auf die man zurückgreifen kann? Gibts da Aussagen. Im Millisekundenbereich oder eher Sekunden?
Habe schon Echtzeit mit Windows probiert. Wenn allerdings Windows dran ist kann man nichts mehr tun um an die CPU zu kommen. Bei Festplattenzugriffen ist Warten im Viel-Sekundenbereich drin.
Die Aussage ist interesannt: >Habe schon Echtzeit mit Windows probiert. Wenn allerdings Windows dran >ist kann man nichts mehr tun um an die CPU zu kommen. Bei >Festplattenzugriffen ist Warten im Viel-Sekundenbereich drin. Hat ja jemand Erfahrungen unter einem Standard Linux? Oder wo steht sowas beschrieben?
Benedikt, du scheinst es nicht zu verstehen. Für Echtzeit ist es notwendig, dass auch die Hardware dieses unterstützt.
Ok dann erklär mir bitte was für Hardwareunterstützung man braucht? Wenn ich z.B. ale 100ms einen Wert von einer Hardware abholen will.
> Für Echtzeit ist es notwendig, dass auch die Hardware dieses > unterstützt. Warum sollte die PC-Hardware nicht echtzeitfähig sein? Es gibt sicher einige Komponenten (wie z.B. Ethernet und USB), deren Zeitverhalten etwas schwerer vorherzusehen ist. Aber streng genommen sind es auch hier nicht die Hardwarekompoenten, die nicht echtzeitfähig sind, sondern die Übertragungsprotokolle, und die sind größtenteils in Software realisiert. Für eine echtzeitkritishe Anwendung wird man diese Komponenten mit Bedacht einsetzen, dann gibt es auch keine Probleme damit. Immehin gibt es ja etliche Echtzeitbetriebssysteme und -kernels für PCs, die harte Echtzeitfähigkeitversprechen (und auch halten) und dies teilweise mit Latenzzeiten im µs-Bereich. Neenee, an der Hardware liegt's nicht, wenn das System rumeiert.
Windows hat kein cooperatives Taskswitching, nur preemtives. Wenn ein Task es will, wird ein Taskwechsel durchgeführt, aber "Zeitscheiben" gibt es schlichtweg nicht! Dafür bräuchtest du z.B. ein RT-Linux, dieses hat preemtives und cooperatives Tasking und somit auch einstellbare Timeslices. Wenn ich mich nicht irre gibts das auch bei Microsoft - Windows Mobile und so geschichten :)
Hallo Benedikt, als ich mich noch mit Messdatenerfassung beruflich beschäftigen musste, haben wir eigene AD-Wandler Karten entworfen, die über einen eigenen Timer und eigenen Speicher verfügten. Damit war der PC aussen vor. Das gleiche haben wir mit I/O Zugriffen und anderem gemacht. Du kommst in diesem Fall wo Du zu bestimmten Zeiten und das möglichst genau irgendetwas auslösen willst, nicht umhin das ganze ausserhalb vom PC zu machen bzw. dir eine Hardware zu überlegen, die als Karte im PC steckt oder über eine Schnittstelle mit diesem kommuniziert. Ich muss allerdings dazu sagen, dass wir seiner Zeit noch mit CPM und DOS gearbeitet haben. Windows gab es noch nicht. Da war der Entwurf und die Verwendung eigener PC-Karten noch deutlich einfacher. Gruss Frank
Jau das mein ich auch. Und ich bin sogar der Meinung USB mit dem Interruptransfer ist sogar sehr gut geeinget für den Echzeiteinsatz. Da ist garantiert das wenn man jede Millisekunde einen Wert will bekommt man diesen auch. Ok bevor alle meckern, ich red grad nur von der USB Hardware ansich! Was der Hosttreiber macht kann man natürlich nicht wissen. Ok aber ich denke auch es reicht der Timer auf dem PC und dann hat man schon mal viel erledigt. Dann kann man ausrechenn wie lange maximal ein Festplattenzugriff dauert oder sonst was und kann dann fix sagen es ist zu 99% Möglich das man jede xxx ms drankommt. Aber im Windows gibt es das nicht drum ist das wirklich da so eine katastrophe. Gut aber dann bin ich jetzt schlauer!
nochmal kurz zu zwei Grundlagen preemtives heisst doch der Scheduler hat die Macht :-) und kooperatives da gibt jeder Task die CPU nach Lust und Laune böse gesagt ab? So hat ich das immer in meinem Kopf?
>Wenn ein Task es will, wird ein Taskwechsel durchgeführt, aber >"Zeitscheiben" gibt es schlichtweg nicht! Quark! Seit Windows NT (3.1, 4.0, 2000, XP, ...) gibt es die "Zeitscheiben" (10ms Maximum bzw. 1ms bei entsprechender Anforderung). Trotzdem können Kernel bzw. Hardware sich mehr rausnehmen bzw. alles ausbremsen.
Ein Haufen Mist wurde schon erzaehlt. Die PC hardware ist echzeitfaehig, Windows ist es nicht. Es gibt harte und weiche Realtimekernel fuer windows. Der Weiche kostet in der Ordnung von 10k$, der Harte in der Ordnung von 30k$. Natuerlich hat Windows ein preemptive Multitasking und Zeitscheiben. Die Zeitscheiben liegen bei 100ms, wobei die Server und die Desktopversion verschieden sind. Nur ist es so, dass man die Zeitscheibe nicht immer bekommt. Also wenn das OS einen Scan fuer die allenfalls neuen Festplatten, fuer USB devices, ein Desktoprefresh oder eine Garbage Collection macht ist nichts. Ein weicher Realtimekernel fuer Windows basiert auf einem Devicetreiber, der am Timer haengt. Ein harter Realtimekernel implementiert einen eigenen Scheduler, und das gesammte Windows ist nur ein Task. Meine Antwort an den Poster. Die uebliche Vorgehensweise ist externe Hardware zu haben mit einem Controller und diese Hardware macht das Echzeitverhalten. Diese externe Hardware kommuniziert mit dem PC, resp. gebraucht den PC als nicht echtzeit-Visualisierungstool.
Noch etwas zu den Betriebssystemen:
Die Reaktionszeit auf ein Ereignis (Timerinterrupt oder externes
Signal) hängt im Wesentlichen von den folgenden Faktoren ab:
1. Zeit bis zum Aufruf des entsprechenden Interrupthandlers
2. Zeit bis der Scheduler einen auf das Ereignis wartenden
Anwendungsprozess/-thread aufgeweckt hat
3. Zeit, die der Anwendungsprozess für die Bearbeitung benötigt
Für 3 ist der Anwendungsprogrammierer verantwortlich. Mit schlechter
Programmierung kann man die beste Echtzeitfähigkeit eines Betriebs-
systems kaputt machen.
Punkt 2 hängt von der Anzahl der laufenden Prozesse, deren Zustand
(schlafend, aktiv) und deren Priorisierung ab. In Linux (und soviel
ich weiß, auch in Windows) gibt es so genannte Real-Time-Threads, die
Priorität über sämtliche gewöhnlichen Threads haben. Die Zeitdauer für
deren Aufwecken sollte konstant sein und liegt schätzungsweise maximal
in ein- bis zweistelligen µs-Bereich. Tatsächlich könnte es sein, dass
diese Zeit noch etwas von der Gesamtzahl der existierenden Threads
abhängt (kenne die internen Algorithmen nicht genau). Aber das sollte
bei Echtzeitanforderungen im ms-Bereich keine Rolle spielen.
Wenn von den Real-Time-Threads kein Gebrauch gemacht wird, hängt die
Zeit bis zum Aufwecken sehr stark von anderen laufenden Anwendungen
ab. Nur wenn man deren Verhalten genau kennt, ist eine Abschätzung der
Zeit möglich. Sonst kann sie theoretisch beliebig hoch werden. Zu den
"anderen Anwendungen" gehören nicht nur die vom Benutzer selbst,
sondern auch die vom Betriebssystem automatisch gestarteten Prozesse
(in Windows die Dienste, in Linux die Dämonen), so dass eine
Abschätzung meist schwierig ist. Aber, wie gesagt, dies kann man mit
den Real-Time-Threads in den Griff bekommen.
Bleibt Punkt 1, die Zeit bist zur Ausführung des Interrupthandlers.
Diese ist ebenfalls schwer abzuschätzen, da der Kernel und jeder
Treiber die Möglichkeit hat, Interrupts für eine beliebig lange Zeit
zu sperren. Die Zeit hängt also stark von den aktiven Treibern ab, die
insbesondere bei Windows aus ganz unterschiedlichen Quellen stammen.
Linux hat es da etwas leichter, da fast alle Treiber Bestandteil des
offiziellen Kernelpakets sind. Baut ein Treiberentwickler exzessive
Interruptsperren in seinen Code ein, wird ihm ziemlich schnell von
anderen Kernelentwicklern auf die Finger geklopft. Bei Windows gibt es
diese Kontrolle höchstens bei den von MS offiziell unterstützten
Treibern.
Ein weiterer Punkt, der speziell timergesteuerte Aktivitäten betrifft,
ist die Timerauflösung. Sie beträgt bei Windows 10ms*, d.h. es ist
Anwendungsebene unmöglich, zyklische Aktivitäten mit mehr als 100Hz zu
realisieren (auf Treiberebene geht das schon, aber dann muss man eben
in die Treiberprogrammierung einsteigen). Unter Linux beträgt die
Auflösung wahlweise 10ms, 3ms oder 1ms, wobei letztere der Default bei
Desktopsystemen ist.
*) Ah, habe gerade bei Heinz gelesen, dass auch 1ms möglich ist. Das
habe ich vorher nicht gewusst.
Da Linux in letzter Zeit immer häufiger in Steuerungsanwendungen
eingesetzt wird, sind die Entwickler bestrebt, die Latenzzeiten weiter
zu senken. So sind seit Version 2.6 die Kernelroutinen unterbrech-
bar, was sie früher nicht waren und in Windows m.W. auch nicht sind.
Ohne diese "Kernel-Preemption" blockieren Aufrufe von Kernelroutinen
aus Anwendungsprogrammen (z.B. für I/O) das komplette System teilweise
bis in den ms-Bereich.
Zusätzlich gibt es für Linux den Real-Time-Patch von Ingo Molnar, der
u.a. die Interruptsperrzeiten weiter verkürzt.
Fazit:
- Harte Echtzeit ist in Window und Standard-Linux nicht möglich.
- Weiche Echtzeit geht bei Windows in der Größenordnung von 30ms.
Beispiel aus eigener Erfahrung: Ein zyklischer Thread, der timer-
gesteuert alle 100ms aktiviert wird, wies einen Jitter von ca.
20 bis 30ms auf. Man muss aber mit sporadische Ausreißern rechnen,
bei denen Verzögerungen bis in den Sekundenbereich auftreten.
- Weiche Echtzeit geht in Linux in der Größenordnung von 4ms. Beispiel
aus eigener Erfahrung: Ein zyklischer Thread, der timer- gesteuert
alle 5ms aktiviert wird, wies einen Jitter von ca. 2ms auf. Sporadi-
sche Ausreißer lagen in der Größenordnung von 20ms. Man muss aber
dazu sagen, dass es sich um eine sehr schlanke Linuxinstallation
handelte, bei der nur der Anwendungs- und die nötigsten System-
prozesse aktiv waren. Der Kernel war aber standardmäßig und
ungepatcht.
- "Fast" harte Echtzeit geht in Linux mit dem Real-Time-Patch im
Bereich von 200-400ns, hab's aber selber noch nicht intensiv
getestet. Infos gibt's z.B. hier:
http://www.captain.at/howto-linux-real-time-patch.php
- Richtig hart und schnell geht es mit speziellen Real-Time-Kerneln,
die praktisch unter den normalen Kernel geschoben werden und diesen
als niederpriorisierten Thread ausführen. Beispiele: RT-Linux (schon
mal gestestet) und RTAI, für Windows gibt's wohl vergleichbares.
Damit lassen sich Latenzzeiten erreichen, die garantiert im
µs-Bereich liegen, erreichen. Nachteil: Das API für System- und
I/O-Funktionen unterscheidet sich prinzipbedingt von dem, was man
gewohnt ist, so dass man sich in die Programmierung erst einarbeiten
muss. Es gibt aber Kommunikationschnittstellen zwischen Echtzeit-
und Nichtechtzeitebene, so dass man i.Allg. nur einen kleinen Teil
einer Anwendung für die Ausführung in dieser "Kellerebene" portieren
muss.
Anmerkung: Die angegeben Zahlenwerte sind keine fundierten Messdaten
und hängen auch natürlich stark von der eingesetzten Hardware ab. Sie
sollen lediglich einen Eindruck der Größenordnungen vermitteln.
Hallo 1391 > Ein Haufen Mist wurde schon erzaehlt. Die PC hardware ist echzeitfaehig, > Windows ist es nicht. Es gibt harte und weiche Realtimekernel fuer > windows. Der Weiche kostet in der Ordnung von 10k$, der Harte in der > Ordnung von 30k$. Natuerlich hat Windows ein preemptive Multitasking und > Zeitscheiben. Die Zeitscheiben liegen bei 100ms, wobei die Server und > die Desktopversion verschieden sind. Nur ist es so, dass man die > Zeitscheibe nicht immer bekommt. Also wenn das OS einen Scan fuer die > allenfalls neuen Festplatten, fuer USB devices, ein Desktoprefresh oder > eine Garbage Collection macht ist nichts. Ein weicher Realtimekernel > fuer Windows basiert auf einem Devicetreiber, der am Timer haengt. Ein > harter Realtimekernel implementiert einen eigenen Scheduler, und das > gesammte Windows ist nur ein Task. Vollkommen richtig. Wobei ich für mich entschieden habe, dass immer dann, wenn Windows im Spiel ist, sich ein echtes Multitasking und Realtime grundsätzlich ausschliessen. > Meine Antwort an den Poster. Die uebliche Vorgehensweise ist externe > Hardware zu haben mit einem Controller und diese Hardware macht das > Echzeitverhalten. Diese externe Hardware kommuniziert mit dem PC, resp. > gebraucht den PC als nicht echtzeit-Visualisierungstool. Ohne weiteren Kommentar die richtige und einzige Aussage die ich stehen lassen würde. Jede andere Behauptung wurde ich als unkorrekt hinstellen! Gruss Frank
Es gibt Software unter Windows, die es schafft, Schrittmotorensteuerungen mit Takt/Richtung zu versorgen, bis 40 KHz relativ jitterfrei. Ich weiß, dass das alles ziemlich kompliziert ist und die Software-Hersteller da jahrelang rumgefummelt haben, aber es geht. Softwarebeispiele sind z.B. http://www.editasc.com/HomePage/German/ http://www.artsoftcontrols.com/
Winfried. Es mag sein. Mit Port-IO und sepziellen Port Treibern schaft man das gerade noch. Die Frage ist dann nur noch was bringt's ? Denn als Windowsmaschine ist dieser PC nicht mehr zu gebrauchen. Es ist nur noch ein wahnsinnig teuerer Controller, der irre viel Strom verbraucht. Mit nem AVR krieg ich eine Schrittmotor Steuerung mit closedloop Regelung auf irgendwas mit ein paar mA fuer ein paar Euro. Ueber die serielle Schnittstelle am PC ist die ganze Wellt fuer den Schrittmotor offen und die Zuverlessigkeit der Steuerung mit dem AVR ist erst noch viel hoeher. Fazit : Ein PC, der einen Schrittmotor direkt steuert ist eine ganz schlechte Idee.
Hallo Winfried, ohne Dir zu nahezutreten, diese Software steuert die Maschinen nur indirekt! Hier werden Befehle generiert, die die Maschine verarbeitet. Die Steuerung der Schrittmotoren übernimmt die Werkzeugmaschine und der, ist es ziemlich egal mit welcher Geschwindigkeit diese Befehle übermittelt werden. Wenn der PC die Taktung und die Positionierung des Schrittmotors über nehmen sollte, an welche Schnittstellen am PC sollen diese den angeschlossen werden? Gruss Frank
mit Windows XP kriegt man Zykluszeiten von 5ms recht sauber hin, mit Windows CE auch kleiner 1ms mit einem Jitter von wenigen µs. WinCE ist aber schwieriger zu 'bauen' und Treiber für PC Hardware sind recht rar. Bei XP muß man die Umgebung sauber halten und der Desktop sollte in Ruhe gelassen werden, dann kann man auch paar ms gut einhalten (so 99,x % geht das schon). Es kommt eben darauf an ob sporadisch einige zig ms Delay tolerierbar sind, für eine Maschinensteuerung kann das im ungüstigen Fall bedeuten das z.B. ein Endschalter überfahren wird, bei einer Messanwendung und einem fehlenden Messwert ist das vielleicht egal. Gute Zykluszeitstabilität bekommt man ein ext. Hardwaretimer im XP Treiber einen Takt vorgibt. Der muß zwar auch erst durch die DPC Queue, aber bei schnellen Rechnern habe ich hier noch keine Probleme gesehen. Die Zeitscheiben waren bei Windows übrigends Versionsabhängig: bei NT waren es Standard 10ms, die Server oder Mehrprozessorversionen hatten 15ms. Bei XP müssten es 5ms sein, da müsste ich auch nochmal nach suchen. Wenn man den Takt per Software machen möchte kann man den Multimedia Timer nehmen, der ist recht genau und geht bis 1ms. Bei der ganzen Timingdiskussion sollte man ein anderes Problem nicht vergessen das schwerwiegender ist bei der Betrachtung Windows als RT System: die fehlenden Prioritäten. Windows XP bietet nur eine Handvoll Prioritäten auf denen sich sehr viele Threads tummeln, man muß sein System daher immer sehr kooperativ bauen.
PS: für solche Diskussionen sollte der Mod eine Rubrik 'Religion' aufmachen weil dieses Thema meist in einem Glaubenskrieg ausartet :-)
Bei USB2.0 isochronen Streaming muß doch eigentlich 125µs Reaktionszeit garantiert sein. Wie ist das eigentlich gelöst?
Der host controller macht das selber. Er nimmt die Daten direkt aus dem Speicher! Daher klappt das auf jedenfall. Es müssen halt genügend Tranfers in den Queues sein.
> Immehin gibt es ja etliche Echtzeitbetriebssysteme und -kernels für > PCs, die harte Echtzeitfähigkeitversprechen (und auch halten) und dies > teilweise mit Latenzzeiten im µs-Bereich. Dann isses auch aus mit interaktiven Prozessen. Ich verstehe die Diskussion nicht. Betriebssysteme mit preemptivem Multitasking sind generell nicht echtzeitfaehig. > Ich kenn nur Linux und da ist das alles kein Problem. Quark. Der scheduler in Linux mag zwar besser implementiert sein als jener von Windows, aber Garantien ueber ausfuehrungszeitpunkte sind keinesfalls gegeben. Michael
Such mal nach "spin on a bit" bzw. nutze den Performance Counter ... laut Win32 API gibts da Funktionen wie QueryPerformanceCounter .... damit gehts schon ziemlich genau .....
In LabVIEW ist ein Realtime-Programm vorhanden. http://sine.ni.com/nips/cds/view/p/lang/en/nid/13754 In Matlab, meines Wissens auch. Gruß Fritz
@Michael G.: >> Immehin gibt es ja etliche Echtzeitbetriebssysteme und -kernels für >> PCs, die harte Echtzeitfähigkeitversprechen (und auch halten) und dies >> teilweise mit Latenzzeiten im µs-Bereich. > > Dann isses auch aus mit interaktiven Prozessen. Warum das? > Ich verstehe die Diskussion nicht. Betriebssysteme mit preemptivem > Multitasking sind generell nicht echtzeitfaehig. Wirklich? Ich hätte gesagt, dass Präemption sogar eine Voraussetzung für Echtzeitfähigkeit ist, da nur damit einem weniger wichtigen Prozess der Prozessor schnell entrissen werden kann, um diesen für einen wichtigeren verfügbar zu machen.
yalu wrote: > @Michael G.: > >>> Immehin gibt es ja etliche Echtzeitbetriebssysteme und -kernels für >>> PCs, die harte Echtzeitfähigkeitversprechen (und auch halten) und dies >>> teilweise mit Latenzzeiten im µs-Bereich. >> >> Dann isses auch aus mit interaktiven Prozessen. > > Warum das? Interaktive Prozesse (z.B. solche, die auf Tastatureingaben reagieren), brauchen in nicht vorhersehbaren Zeitintervallen die CPU. Wenn Du nun ein System mit harter Echtzeit hast, wird die CPU oft monopolisiert, so dass ein interaktiver Prozess nicht mehr vernuenftig reagieren kann. Das Ergebnis waere abgehackte und stotterhafte Reaktion, das wuerde Dich als Nutzer schnell in den Wahnsinn treiben -- also mich treibt sowas in den Wahnsinn ;) >> Ich verstehe die Diskussion nicht. Betriebssysteme mit preemptivem >> Multitasking sind generell nicht echtzeitfaehig. > > Wirklich? Ich hätte gesagt, dass Präemption sogar eine Voraussetzung > für Echtzeitfähigkeit ist, da nur damit einem weniger wichtigen > Prozess der Prozessor schnell entrissen werden kann, um diesen für > einen wichtigeren verfügbar zu machen. Nein. Bei praeemptiven Multitasking fuehrt das Betriebssystem als kontrollierende Schicht Regie ueber die Vergabe der CPU. Praeemptiv heisst "zwanghafter Entzug" von Ressourcen. Ein Echtzeitprozess entscheidet in der Regel selbst, wann er die CPU abgeben will, d.h. es kommt kooperatives Multitasking zum Einsatz. Der Prozess weiss selber am besten, wann er unkritische Bereiche betritt und kann dies dann mitteilen ("jetzt koennte ich unterbrochen werden"). Es ist natuerlich klar dass kooperatives Multitasking fuer PCs ungeeignet ist. Ein kleiner Programmierfehler in einem Prozess (der z.B. dazu fuehrt, dass die CPU nicht mehr freigegeben wird) und das ganze System kommt zum erliegen. In Echtzeitsystemen hat man oft eine sehr vorhersehbare Situation, teilweise eine feste Anzahl an (wenigen) Prozessen und eine ganz spezifische Anwendung so dass es realistisch ist, mit kooperativen Multitasking zu arbeiten, da die Komplexitaet ueberschaubar ist und das System auch als ganzes Entwickelt werden kann. In der Hinsicht ist ein moderner PC eher ein Zoo... Michael
Ich will nicht in die Diskussion einsteigen, aber es gibt Wege, um Realtime-Anwendungen auch unter Windows zu bauen - guckst Du http://www.kithara.de. Zumindest sollte damit ein 100ms Takt kein Problem sein. Ich stand auch schon mal vor einem solchen Problem, habe dann allerdings die zeitkritischen Teile mit einem ARM gelöst und mit einem Windowsprogramm den unkritischen Teil gelöst.
> Zumindest sollte damit ein 100ms Takt kein Problem sein.
Das mag moeglich sein. Aber mit Echtzeit hat das nichts zu tun ;) Das
ist hoechstens "Echtzeit light".
Hier mal etwas Beispielcode fuer Linux:
1 | #include <stdio.h> |
2 | #include <time.h> |
3 | #include <sys/time.h> |
4 | |
5 | #define TIMESTAMP_USEC(timeval) (timeval.tv_sec*1000000+timeval.tv_usec)
|
6 | |
7 | int main(void) |
8 | {
|
9 | struct timeval current_time; |
10 | struct timespec sleep_time; |
11 | unsigned long last_timestamp_us=0; |
12 | |
13 | |
14 | sleep_time.tv_sec = 0; |
15 | /* these are 50 milliseconds or 50000 mikroseconds */
|
16 | sleep_time.tv_nsec = 50000000UL; |
17 | gettimeofday(¤t_time, NULL); |
18 | |
19 | |
20 | for (;;) |
21 | {
|
22 | last_timestamp_us = TIMESTAMP_USEC(current_time); |
23 | |
24 | /* now sleep for 50 msecs */
|
25 | nanosleep(&sleep_time, NULL); |
26 | |
27 | /* print the time that has actually passed */
|
28 | gettimeofday(¤t_time, NULL); |
29 | |
30 | printf("%lu\n", TIMESTAMP_USEC(current_time) - last_timestamp_us ); |
31 | }
|
32 | |
33 | return 0; |
34 | }
|
Lasst das mal laufen...
>> Zumindest sollte damit ein 100ms Takt kein Problem sein. >Das mag moeglich sein. Aber mit Echtzeit hat das nichts zu tun ;) Das >ist hoechstens "Echtzeit light". Das ist leider falsch. Echtzeit bedeutet in einer festgelegten Zeit reagieren. Und wenn diese Zeit 100ms ist ist auch gut. Echtzeit bedeutet nicht Mikrosekunden.
> Echtzeit bedeutet nicht Mikrosekunden.
Ueberaus qualifiziert Dein Beitrag.
Michael G. schrieb: > Interaktive Prozesse (z.B. solche, die auf Tastatureingaben > reagieren), brauchen in nicht vorhersehbaren Zeitintervallen die > CPU. Wenn Du nun ein System mit harter Echtzeit hast, wird die CPU > oft monopolisiert, so dass ein interaktiver Prozess nicht mehr > vernuenftig reagieren kann. Das Ergebnis waere abgehackte und > stotterhafte Reaktion, ... Bei typischen Echtzeitanwendungen benötigen die hochpriorisierten Prozesse wenig Rechenzeit, die aber bei Bedarf augenblicklich verfügbar sein muss (ähnlich wie bei Interrupthandlern, die praktisch eine noch höhere Prioritätsstufe darstellen). Um zu verhindern, dass sich ein hochpriorisierter Prozess selbst blockiert, weil die Ereignisse, auf die er reagieren soll, schneller eintreffen, als er sie bearbeiten kann, hält man genügend CPU-Reserven vor, um eben auch im worst Case die Zeitanforderungen einhalten zu können. Da der worst Case aber nur selten eintritt, bleibt im Normalfall ausreichend CPU-leistung übrig, um so banale Dinge wie User-Interfaces bearbeiten zu können. Natürlich wird die Reaktion auf einen Tastendruck verzögert, wenn ein hochpriorisierter Prozess aktiv ist. Da diese Aktivität meist aber nur von kurzer Dauer ist (ms, oft auch nur µs), ist die Verögerung des Tastendruck entsprechend kurz und deswegen kaum bemerkbar. Eine stotternde Reaktion auf Benutzereingaben ist ein Anzeichen dafür, dass die CPU durch die hochpriorisierten Prozesse zu stark ausgelastet ist. Das ist dann ein Design-Fehler, der meist dazu führt, dass auch das gefordertes Zeitverhalten der hochpriorisierten Prozesse nicht mehr garantiert werden kann. Abhilfe schafft nur eine Verbesserung Prozessstruktur oder mehr CPU-Power. > Bei praeemptiven Multitasking fuehrt das Betriebssystem als > kontrollierende Schicht Regie ueber die Vergabe der CPU. Praeemptiv > heisst "zwanghafter Entzug" von Ressourcen. Richtig. > Ein Echtzeitprozess entscheidet in der Regel selbst, wann er die CPU > abgeben will Auch richtig. Er gibt die CPU ab, um weniger wichtigen (niederpriori- sierten) Prozessen die Chance zu geben, abgearbeitet zu werden. Der Echtzeitprozess muss deswegen kooperativ sein, um nicht das ganze System zu blockieren. Was passiert aber, wenn gerade ein niederpriorisierte Prozess läuft und durchaus noch einige Dinge zu tun hätte, aber auf Grund eines externen Ereignisses der hochpriorisierte Prozess zum Zuge kommen sollte? Woher weiß der niederpriorisierte Prozess, dass die CPU gerade für wichtigere Dinge gebraucht wird und er die Kontrolle abgeben sollte? Soll er die CPU auf Verdacht abgeben? Dies müsste er dann aber idealerweise nach jeder ausgeführten Maschineninstruktion tun, was einen riesigen Overhead mit sich bringen würde. Viel besser ist es doch, wenn das Betriebssystem beim Eintreffen des Ereignisses den niederpriorisierten Prozess sofort anhält (ihm also zwanghaft die CPU-Ressource entzieht) und die Kontrolle an den hochpriorisierten Prozess übergibt, der das Ereignis bearbeitet. Das nennt sich dann Präemption, wie du richtig geschrieben hast. Kooperatives Multitasking kenne ich nur von Windows <=3.11, was sicher alles andere als ein Echtzeitbetriebssystem war. Dort war es nicht möglich, schnell reagierende Prozesse zu realisieren, weil diese immer auf das Wohlwollen weniger wichtiger Prozesse angewiesen waren. Hingegen sind alle Echtzeitbetriebssystem, die ich kenne (OS-9, VxWorks, RT-Linux usw.) präemptiv in dem Sinne, wie ich es gerade beschrieben habe.
rtai+linux und gut ists. kann man sich zb. bei emc2 angucken. mfg hansl
Es gibt natuerlich unterschiedeliche Design-Ansaetze und oftmals mischt man unterschiedliche Konzepte in realen Systemen... aber "normale" Systeme wie Linux und Windows sind keinesfalls echtzeitfaehig. Und auch so "Kruecken" helfen da nur wenig. > Viel besser ist es doch, wenn das Betriebssystem beim Eintreffen des > Ereignisses den niederpriorisierten Prozess sofort anhält (ihm also > zwanghaft die CPU-Ressource entzieht) und die Kontrolle an den > hochpriorisierten Prozess übergibt, der das Ereignis bearbeitet. Das Problem ist, dass dies leider nicht immer so einfach ist, wie Du es hier darstellst. Aber generell ist der Ansatz natuerlich gangbar. Wir koennten das jetzt ewig fortsetzen und diskutieren, wie wir am besten ein Betriebssystem entwerfen, aber ich denke mal die eingehende Frage haben wir beantwortet ;) Damit gebe ich mich erstmal zufrieden. Gruesse, Michael
> Und auch so "Kruecken" helfen da nur wenig. Meinst du mit Kruecke die RTAI+Linux-Kombination? Ich glaube nicht, dass das eine Krücke ist. RTAI und RT-Linux stecken, was die Reaktionszeiten betrifft, teilweise die Platzhirsche wie VxWorks in die Tasche. Nicht umsonst schwenkt der VxWorks-Hersteller Windriver langsam aber sicher in Richtung Linux, um da auf keinen Fall etwas zu verpassen. > Das Problem ist, dass dies leider nicht immer so einfach ist, wie Du > es hier darstellst. Aber generell ist der Ansatz natuerlich gangbar. Meines Wissens wird bei den mir bekannten Echtzeitbetriebssystemen genau dieser Weg gegangen. Und dass er nicht so einfach ist, ist vielleicht der Grund dafür, dass für diese Systeme oft so viel Geld verlangt wird ;-) > Wir koennten das jetzt ewig fortsetzen und diskutieren, wie wir am > besten ein Betriebssystem entwerfen, ... Es geht ja nicht darum, ein neues Betriebssystem zu entwerfen, sondern herauszufinden, wie das Problem bei bestehenden Systemen gelöst ist. Ich habe dargestellt, wie es meinem Wissen nach bei den mir bekannten Echtzeitbetriebssystemen gemacht wird, kann mir aber durchaus vorstellen, dass es da ganz andere Ansätze gibt. Mich hätte halt nur interessiert, ob und wo diese tatsächlich eingesetzt werden. > ... aber ich denke mal die eingehende Frage haben wir beantwortet ;) Da hast du allerdings recht. Ich glaube, das war sogar schon vor etlichen Stunden der Fall :-) Da aber dieses Forum ja kein reiner Supportdienst ist, ist es ja manchmal auch ganz interessant, bei einem Thema mal etwas in die Tiefe zu gehen. Aber begraben wir nun das Thema ...
>> Und auch so "Kruecken" helfen da nur wenig. > Meinst du mit Kruecke die RTAI+Linux-Kombination? Ne irgendein Aufsatz im Userspace von Windows... ;) OK aber nun Schluss jetzt :D Ich werd wahrscheinlich noch in Echtzeitsysteme gehen danach koennen wir weiter sprechen hehe Michael
Nochmal zu der Schrittmotor-Software: Über LPT wird direkt Takt und Richtung über zwei Portleitungen ausgegeben, das Timing macht also der PC und das bis 40KHz Taktfrequenz unter Windows relativ jitterfrei. Das zeigt zumindest, dass es irgendwelche Wege geben muss, solche Anforderungen zu erfüllen. Der PC ist nebenher sogar noch für alles mögliche nutzbar, man kann z.B. gleichzeitig im Internet surfen oder Briefe schreiben. Das geht mit RTAI+Linux unter EMC2 ganz ähnlich, ich glaub aber nur bis ca. 20KHz. Die Frage, ob sowas Sinn macht, kann man klar mit Ja beantworten, weil: Die Bahnsteuerung für eine CNC-Maschine kann so komplex sein, dass in einem bestimmten Preissegment so gut wie keine Microcontroller-Implementierungen verfügbar sind, jedoch PC-Software schon. Konkretes Beispiel: Für ca. 150 Euro bekommt man eine Windows-PC-Software, die G-Code einliest und daraus Takt-Richtung für 3 Schrittmotore generiert, die dann die CNC-Fräse bewegen. Unter Linux gibt es dafür sogar kostenlos EMC/EMC2. Hardwarelösungen, die genauso intelligent und komfortabel sind, kosten einige tausend Euro. Also gerade im Hobby-CNC-Sektor ist das ein schlagendes Argument. Auch braucht es eben keine Spezialhardware sondern jeder beliebige ausgediente PC kann die Steuerung übernehmen.
> Echtzeit bedeutet in einer festgelegten Zeit reagieren. Vor allem bedeutet es, daß diese Zeit unter allen Umständen garantiert wird. @Michael G. (linuxgeek): >> Meinst du mit Kruecke die RTAI+Linux-Kombination? > > Ne irgendein Aufsatz im Userspace von Windows... ;) Da finde ich die, bei denen Windows im Userspace des Echtzeitsystems laufen, aber auch irgendwie krückenhaft. @Winfried (Gast): > das Timing macht also der PC und das bis 40KHz Taktfrequenz unter > Windows relativ jitterfrei. ^^^^^^^ Das "relativ" ist hier der springende Punkt. > Das zeigt zumindest, dass es irgendwelche Wege geben muss, solche > Anforderungen zu erfüllen. Naja, wenn deine CNC-Schrittmotorsteuerung ein paar Millisekunden länger braucht, um das Programm zu durchlaufen, macht das ja auch nicht viel aus. Aber wenn du eine Maschinensteuerung hast, bei der eine Millisekunde mehr bereits zu großen und teuren Schäden an der Maschine oder gar zu Personenschäden führen kann, reicht halt "relativ jitterfrei" nicht mehr. > Der PC ist nebenher sogar noch für alle mögliche nutzbar, man kann z.B. > gleichzeitig im Internet surfen oder Briefe schreiben. Dadurch wird es dann eben nur noch etwas weniger jitterfrei...
Ein Echtzeitbetriebssystem, fuer einen Schrittmotor... Aaaaaahhhhhhhhh. Nimm einen AVR fuer 2 Euro an die serielle Schnittstelle und gut ist.
Ich kann mich noch an Windows for Workgroups 3.11 erinnern da konnte man in der Systemsteuerung einstellen wieviel solcher Zeitscheiben ein Prozess bekommt und wie schnell man sie im wieder entziehen konnte, allerdings hatten die Rechner damals noch Taktraten im 2stelligen Bereich. Bin mir nicht mehr ganz genau sicher was die Einheit war, entweder Takte oder sogar mSek, man konnte das selbst einstellen müsste zw. 1-1000 oder 1-10000 gewesen sein.
das machte aber WfW weder zu einem Echtzeit OS noch überhaupt zu einem ordentlichen OS :-) Und am allerwenigsten konnte man sich darauf verlassen das ein Prozess überhaupt drankam. Da hiessen die Religionsgemeinschaften noch 'Windows' oder 'OS/2', ja das waren noch Zeiten...
Windows 3.0 und Nachfolger (3.1, 3.11) hatte auf einem 386er tatsächlich schon einen zeitscheibenbasierten Scheduler - mit dem konnte man, ausreichend Arbeitsspeicher vorausgesetzt, DOS-Programme "im Hintergrund" parallel zu Windows-Programmen im Vordergrund laufen lassen. Besonders performant war das natürlich nicht, und die DOS-Programme sollten auch tunlichst wenig Textausgaben und schon gar keine Graphikausgaben machen. Immerhin wurde bereits hier in einer VDM die PC-Hardware soweit virtualisiert, daß die seriellen Schnittstellen für das DOS-Programm verwendbar waren. Allerdings konnte man, soweit ich mich erinnere, nicht allzuviel konfigurieren und die ganze Chose war sowieso eher wackelig ...
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.