www.mikrocontroller.net

Forum: PC-Programmierung Standard Windows Echtzeitfähigkeit?


Autor: Benedikt Sauter (Firma: embedded projects GmbH) (flopper)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Yeah (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie soll ein OS echtzeitfähig sein, wenn es noch nicht mal die Hardware
ist???

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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....

Autor: Benedikt Sauter (Firma: embedded projects GmbH) (flopper)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: zett (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Benedikt Sauter (Firma: embedded projects GmbH) (flopper)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Und was hat man dann da so für Zeiten auf die man zurückgreifen kann? 
Gibts da Aussagen. Im Millisekundenbereich oder eher Sekunden?

Autor: Jorge (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Benedikt Sauter (Firma: embedded projects GmbH) (flopper)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Yeah (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Benedikt, du scheinst es nicht zu verstehen. Für Echtzeit ist es 
notwendig, dass auch die Hardware dieses unterstützt.

Autor: Benedikt Sauter (Firma: embedded projects GmbH) (flopper)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Benedikt Sauter (Firma: embedded projects GmbH) (flopper)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Und denk dran mir reicht weiche Echtzeit!

Autor: yalu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: horst (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 :)

Autor: Frank Link (franklink)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Benedikt Sauter (Firma: embedded projects GmbH) (flopper)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: Benedikt Sauter (Firma: embedded projects GmbH) (flopper)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Tom (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Interrupt und Echtzeit schließen sich gegenseitig aus.

Autor: Heinz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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.

Autor: 1391 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: yalu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Frank Link (franklink)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Benedikt Sauter (Firma: embedded projects GmbH) (flopper)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ein Genuss deine Antwort :-) Danke sowas wollte ich haben g

Autor: Winfried (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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/

Autor: 1391 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Frank Link (franklink)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: 1391 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
LPT, es gibt immer welche...

Autor: JojoS (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: JojoS (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
PS:
für solche Diskussionen sollte der Mod eine Rubrik 'Religion' aufmachen 
weil dieses Thema meist in einem Glaubenskrieg ausartet :-)

Autor: jens (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bei USB2.0 isochronen Streaming muß doch eigentlich 125µs Reaktionszeit 
garantiert sein. Wie ist das eigentlich gelöst?

Autor: Benedikt Sauter (Firma: embedded projects GmbH) (flopper)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Michael G. (linuxgeek) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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

Autor: Michael K (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 .....

Autor: Fritz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: yalu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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.

Autor: Benedikt Sauter (Firma: embedded projects GmbH) (flopper)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jau das hätte ich auch gedacht. Wie ist das nun?

Autor: Michael G. (linuxgeek) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Michael Korb (michaelkorb)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Michael G. (linuxgeek) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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:
#include <stdio.h>
#include <time.h>
#include <sys/time.h>

#define TIMESTAMP_USEC(timeval) (timeval.tv_sec*1000000+timeval.tv_usec)

int main(void)
{
  struct timeval  current_time;
  struct timespec sleep_time;
  unsigned long last_timestamp_us=0;
  
  
  sleep_time.tv_sec = 0;
  /* these are 50 milliseconds or 50000 mikroseconds */
  sleep_time.tv_nsec = 50000000UL;
  gettimeofday(&current_time, NULL);

  
  for (;;)
  {
    last_timestamp_us = TIMESTAMP_USEC(current_time);
    
    /* now sleep for 50 msecs */ 
    nanosleep(&sleep_time, NULL); 
    
    /* print the time that has actually passed */
    gettimeofday(&current_time, NULL);
    
    printf("%lu\n", TIMESTAMP_USEC(current_time) - last_timestamp_us );
  } 

  return 0;
}

Lasst das mal laufen...

Autor: 1391 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>> 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.

Autor: Michael G. (linuxgeek) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Echtzeit bedeutet nicht Mikrosekunden.

Ueberaus qualifiziert Dein Beitrag.

Autor: yalu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Hansl (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
rtai+linux und gut ists. kann man sich zb. bei emc2 angucken.

mfg
 hansl

Autor: Michael G. (linuxgeek) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: yalu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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 ...

Autor: Michael G. (linuxgeek) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>> 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

Autor: Winfried (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Rolf Magnus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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...

Autor: 1293 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ein Echtzeitbetriebssystem, fuer einen Schrittmotor... Aaaaaahhhhhhhhh. 
Nimm einen AVR fuer 2 Euro an die serielle Schnittstelle und gut ist.

Autor: Thomas O. (kosmos)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: JojoS (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ...

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.