Super! Dann habe ich endlich Amiga-Feeling auch unter Linux. Wer es nicht weiß: Das Amiga OS war fast ein Echtzeitbetriebssystem. Da wurde sofort auf Eingaben der Maus und Tastertur reagiert. Nicht so wie bei Win und Linux, daß ein Task der 99% CPU benötigt Eingaben extrem Zeitverzögert.
Soweit ich weiss, bedeutet Echtzeitfaehigkeit nur, dass ein Prozess nach einer bestimmten, festgelegten Zeit auf jeden Fall den Prozessor bekommt. Diese Zeit muss keinesfalls sehr kurz sein. Ich bin mir ziemlich sicher, dass AmigaOS kein Echtzeitbetriebssystem war. Soweit ich mich erinnere (ist lang her dass ich auf dem Amiga das letzte mal was programmiert habe...), ist es unter AmigaOS sogar moeglich, dass ein Prozess das Multitasking unterbindet und den Prozessor komplett uebernimmt. Sowas darf in einem Echtzeitsystem auf keinen Fall moeglich sein. Mit der Geschwindigkeit der Operflaeche hat das alles auch nur sekundaer was zu tun. Soweit ich weiss ist der Grund, warum Linux manchmal nicht sofort auf Maus oder Tatstatureingaben reagiert (hmmm, bei mir reagiert es eigentlich schon sofort...), dass X singlethreaded und synchron ist. Das merkt man vor allem wenn man X uebers Netzwerk benutzt. NX kann dieses Problem zum Teil loesen, ein Stichwort ist hier wohl roundtrips. Aber genauer kenne ich mich da auch nicht aus.
Ich hatte geschrieben: Das Amiga OS war "fast" ein Echtzeitbetriebssystem. :-) Das wurde im Übrigen auch von anderen Bestätigt, leider habe ich gereade keine Quelle. Das man Multitasking unterbindet konnte ist richtig.
AmigaOS hat mit typischen EchtzeitOSen den prioritätsgesteuerten Scheduler gemeinsam. Solche Scheduler führen immer nur den Prozeß mit der höchsten Priorität aus, es sei denn, dieser ist gerade durch eine I/O-Operation blockiert. Damit kann man auf dem Amiga z.B. ein Fraktalprogramm (oder einen anderen Prozessor-Hog) und gleichzeitig einen höherpriorisierten Editor laufen lassen. Der Editor reagiert dabei auf Tastendrücke praktisch genau so schnell, als ob er der einzige Prozeß im System wäre. Die maximale Reaktionszeit hängt damit nur von der Dauer von Interruptsperren in den Treibern ab. Inwieweit die Treiber auf harte Echtzeitfähigkeit ausgelegt sind, weiß ich nicht.
Prioritätsgesteuerte Scheduler haben den Nachteil, daß eine Endlosschleife ohne I/O-Operationen oder Sleeps im höchstprioren Prozeß zur Blockade des gesamten Systems führt.
Der Standardscheduler unter Linux vergibt die Rechenzeit an die einzelnen Prozessen eher nach Fairness-Gesichtspunkten, d.h. selbst der Prozeß mit der niedrigsten Priorität bekommt einen gewissen Anteil der CPU-Leistung zugweisen. Threads können allerdings (auch schon in älteren Standardkernels) mit Echtzeitprioritäten ausgestattet werden, die dann in der oben beschriebenen Weise scheduled werden. "Normale" Threads/Prozesse haben aus der Sicht des Echtzeitschedulers niedrigste Priorität und werden nur dann ausgeführt, wenn alle Echtzeitthreads schlafen. Auch hier ist natürlich die Gefahr des Aufhängens bei Endlosschleifen gegeben, weswegen für die Verwendung von Echtzeitprioritäten Rootrechte erforderlich sind.
Ich glaube, das war nicht wirklich das, was gemeint war, ist aber natürlich auch schön ;)
Es geht wohl eher um richtige harte Echtzeit, wie man sie teilweise im medizinischen oder im Produktionsbereich benötigt. Also Garantien, daß diese oder jene Operation nicht länger als eine gewisse Anzahl ms braucht und danach eben wirklich was schief geht.
Von Manfred Tremmel am Di, 12. Oktober 2004 um 12:55 #
Das Verhalten hatte der Amiga aber nicht so sehr dem OS als den Customchips zu verdanken. Da ruckelte der Mauszeiger nicht, wenn die CPU dicht war, weil die CPU sich gar nicht drum kümmern musste.
wirklich Amiga/BeOS Feeling oder nicht? Oder sind dazu noch Einstellungen notwendig? Werde es heut mal testen... ein Praxisbespiel hab ich schon in der Tasche: Sound stottert reproduzierbar.
abgehakt: ---snip--- arch/i386/kernel/irq.c:79: Warnung: `register_irq_proc' declared `static' but never defined arch/i386/kernel/irq.c:277: Warnung: `report_bad_irq' defined but not used make[1]: *** [arch/i386/kernel/irq.o] Fehler 1 make: *** [arch/i386/kernel] Fehler 2 ---snip---
Also erst mal auf einen Patch warten, der sich auch kompiliert... schade, hätte mich jetzt schon interessiert. Aber wenn ein gepatchter Kernel sich nicht kompilieren lässt, dann lass ich das besser. Da sind meine C-Kenntnisse zu schwach und gerade der Kernel kompiliert sich ja noch total "verpatched" (acpi,bluez,bootsplash,alsa-cvs,dvb-cvs) ganz sauber... sorry, MontyVista, dat war nix!
Spinlocks?
Aber für 1:15 nicht schlecht
Da hatte ich mein Idle-Task 
Wer es nicht weiß: Das Amiga OS war fast ein Echtzeitbetriebssystem.
Da wurde sofort auf Eingaben der Maus und Tastertur reagiert.
Nicht so wie bei Win und Linux, daß ein Task der 99% CPU benötigt
Eingaben extrem Zeitverzögert.
aber geht das dann wirklich so einfach oder muss nicht zuerst die Oberfläche dementsprechent angepaast werden?
was hat denn die Oberfläche damit zu tun wie zeitnah ein Mausklick entgegengenommen wird?
cya
Matthias
ps: hab keine Ahnung ist ne frage
Das wurde im Übrigen auch von anderen Bestätigt, leider habe ich gereade keine Quelle.
Das man Multitasking unterbindet konnte ist richtig.
Prioritätsgesteuerte Scheduler haben den Nachteil, daß eine Endlosschleife ohne I/O-Operationen oder Sleeps im höchstprioren Prozeß zur Blockade des gesamten Systems führt.
Der Standardscheduler unter Linux vergibt die Rechenzeit an die einzelnen Prozessen eher nach Fairness-Gesichtspunkten, d.h. selbst der Prozeß mit der niedrigsten Priorität bekommt einen gewissen Anteil der CPU-Leistung zugweisen. Threads können allerdings (auch schon in älteren Standardkernels) mit Echtzeitprioritäten ausgestattet werden, die dann in der oben beschriebenen Weise scheduled werden. "Normale" Threads/Prozesse haben aus der Sicht des Echtzeitschedulers niedrigste Priorität und werden nur dann ausgeführt, wenn alle Echtzeitthreads schlafen. Auch hier ist natürlich die Gefahr des Aufhängens bei Endlosschleifen gegeben, weswegen für die Verwendung von Echtzeitprioritäten Rootrechte erforderlich sind.
yalu
Es geht wohl eher um richtige harte Echtzeit, wie man sie teilweise im medizinischen oder im Produktionsbereich benötigt. Also Garantien, daß diese oder jene Operation nicht länger als eine gewisse Anzahl ms braucht und danach eben wirklich was schief geht.
Gruß,
Ember
Schöne Grüße an Agnus, Lisa, Denise, ...
ich nehmlich auch.
Diese Kiste machte sogar spass gell???
---snip---
arch/i386/kernel/irq.c:79: Warnung: `register_irq_proc' declared `static' but never defined
arch/i386/kernel/irq.c:277: Warnung: `report_bad_irq' defined but not used
make[1]: *** [arch/i386/kernel/irq.o] Fehler 1
make: *** [arch/i386/kernel] Fehler 2
---snip---
Also erst mal auf einen Patch warten, der sich auch kompiliert... schade, hätte mich jetzt schon interessiert. Aber wenn ein gepatchter Kernel sich nicht kompilieren lässt, dann lass ich das besser. Da sind meine C-Kenntnisse zu schwach und gerade der Kernel kompiliert sich ja noch total "verpatched" (acpi,bluez,bootsplash,alsa-cvs,dvb-cvs) ganz sauber... sorry, MontyVista, dat war nix!
Naja, hab genug zum ausprobieren unter Linux