Welcome, Guest. Please login or register.
Did you miss your activation email?

Author Topic: [DE] Quasi-Realtime mit BFScheduler per ck-patch  (Read 22306 times)

Offline brummer

  • User
  • Posts: 276
    • http://guitarix.sourceforge.net/
[DE] Quasi-Realtime mit BFScheduler per ck-patch
« Reply #30 on: 2010/10/14, 15:20:23 »
Quote from: "ralul"

Weswegen meine ursprüngliche Überschrift mit dem Zusatz Gültigkeit hat?
RT ist Schwachsinn für den "normalen" Desktop Benutzer

Fast alle Distributionen verwenden den Low latency Kernel, dieser war bis vor wenige Jahren noch Bestandteil des RT-Patch's. Im Grunde verwenden damit schon alle den rt-patch, es braucht halt nur nicht mehr gepatched werden. Diese Aussage sagt also so-was wie "Der Linux Kernel ist Schwachsinn für den "normalen" Desktop Benutzer"  :wink:

Quote from: "ralul"

Die Anpassung an die Berdürfnisse verschiedener Benutzergruppen lehnt Kolivas ab, weil es eben _prinzipiell_ unmöglich ist für alle Anwendungsgebiete den optimalen Scheduler zu implementieren. Kolivas fordert statt dessen eine Pluginstelle für jeweils angemessene Scheduler. Was trivial zu realisieren wäre, da in den betroffenen 11 c-Quellcode Dateien meist jeweils nur eine Definition abgeändert werden muss.

Trivial nur wenn man eben andere Benutzergruppen außer acht lässt, Andere Kinder wollen auch den Kernel Patchen und Ihn so Ihren Bedürfnissen anpassen, soll dann in Zukunft jeder Patch für jede mögliche Sheduler Implementation ausgearbeitet werden?
Wie soll so-was gemaitained werden ?  Ist dir eigentlich klar wie-viele Gruppen es auf kernel.org gibt ?

Okay, das ist mit Sicherheit machbar, aber Trivial ? Ich weiß nich ?

Offline agaida

  • User
  • Posts: 1.760
    • http://g-com.eu
Quasi-Realtime mit BFScheduler per ck-patch
« Reply #31 on: 2010/10/14, 22:14:46 »
Bis auf die von brummer so schön gemachte  Teilung Desktop - ProAudio: Ja. Aber es bleibt halt quasi.  Kommst Du in den Bereich Signalverarbeitung -> RT. Hier ist Signalverarbeitung meist Audio. In der Industrie halt Produktionssteuerung. ;) Brauchst Du in irgendeiner Weise, wie auch von brummer dargelegt mehr als die einen schnellen Desktop, dann RT. Das sind dann wirklich Äpfel und Birnen und vollkommen unterschiedliche Intressengruppen. Der Link von brummer schildert den Einsatz von RT grade für Musiker und hier werden auch die Vorteile deutlichst herausgearbeitet, ohne großes Fachblub.

Ich weiss nicht, ob ich jetzt den Schwachsinn des Tages von mir gebe - meines Wissens lag der Sinn von Kolivas Anpassungen bei Systemen mit weniger als 16 Kernen. D.h. das Zeug skaliert nicht. Das ist einer der Hauptkritikpunkte. mir als User mit 4, 6, irgendwann 8 Kernen kann das ja egal sein, ich nehme die Vorteile mit und bin glücklich. Im größeren Rahmen gesehen ist aber die Ablehnung, das in den offiziellen Kernel aufzunehmen, nachvollziehbar. Wenn ich mit HT mit einem 8 Kerner vorstelle, bin ich also irgendwie an der Grenze angelangt, wo CK Sinn macht. Warten wir halt noch 1 oder zwei Jahre. Mit dem I7  980X und aktiviertem HT hätte ich 12 "Kerne", damit dürfte CK schon fast keine Vorteile mehr bringen. Abgesehen davon glaube ich da auch nicht mehr wirklich an gravierende Geschwindigkeitsdefizite...
There's this special biologist word we use for "stable". It's "dead". ~ Jack Cohen

Offline brummer

  • User
  • Posts: 276
    • http://guitarix.sourceforge.net/
Quasi-Realtime mit BFScheduler per ck-patch
« Reply #32 on: 2010/10/15, 06:04:53 »
Quote from: "agaida"

Hier ist Signalverarbeitung meist Audio. In der Industrie halt Produktionssteuerung

Der rt-patch, garantiert keine Echtzeit, es handelt sich hier um sogenannte weiche Echtzeit, wendet sich tatsächlich nur an Musiker. Für Prozesssteuerung (Automatisation), gibt es einige andere Projekte welche sich mit harter (garantierter) Echtzeit beschäftigt.
RTAI oder
Wind River
Diese Kernel entsprechen allerdings raluls aussage, sie sind nicht-mal so ohne weiteres auf einem normalen Linux System installierbar. Diese Projekte sind so spezialisiert das Sie gar-nicht erst versuchen ins Mainline zu kommen.

Aber nochmal zum BFS, mich würde mal Interessieren wie er sich im Zusammenhang mit in OpenMP geschriebenen Programmen verhält ?

Offline agaida

  • User
  • Posts: 1.760
    • http://g-com.eu
Quasi-Realtime mit BFScheduler per ck-patch
« Reply #33 on: 2010/10/15, 10:49:03 »
Jetzt hast Du mich wirklich an einer Wissenslücke - in den Begrifflichkeiten: Wenn ich bisher RT-Kernel gelesen habe, ging ich davon aus, das es sich um die Ideen von Molnar und Co ging und von denen hier bemuckelt wird: https://www.osadl.org/ . Der Bezug auf osadl betrifft auch eher meine Interessen am Thema Echtzeit. Nachdem ich momentan keine Verwendung dafür habe, habe ich mich auch mit dem Thema RT Application Interface nicht weiter beschäftigt.
There's this special biologist word we use for "stable". It's "dead". ~ Jack Cohen

Offline ralul

  • User
  • Posts: 1.814
Quasi-Realtime mit BFScheduler per ck-patch
« Reply #34 on: 2010/10/15, 11:54:01 »
Hey brummer, ich habe keine tiefe Ahnung von Realtime. Und dieser Thread hatte sich an Leute gewandt, die auch keine Ahnung haben, sich aber wegen Audio Gedanken machen: Wenn man kein Spezialist ist, könnte BFS die einfachere Alternative sein. Das annonciert der Kolivas Blog Artikel. Wenn es gefragt ist, kann ich mich an einer Übersetzung aus dem Englischen versuchen?

Interessant ist die derzeitige Veröffentlichung des LinSched Simulators: Es soll damit ein genaues Scheduler Engineering möglich sein. Das heisst aber nichts anderes als dass einige unzufrieden sind mit dem Standartverhalten des Mainline Schedulers und nach besseren Lösungen suchen...

OpenMP ist eine Programmiersprache, die Parallelcoding vereinfachen solle, wie Haskell?
experiencing siduction runs better than my gentoo makes me know I know nothing

Offline brummer

  • User
  • Posts: 276
    • http://guitarix.sourceforge.net/
Quasi-Realtime mit BFScheduler per ck-patch
« Reply #35 on: 2010/10/15, 23:11:49 »
Quote from: "agaida"

Wenn ich bisher RT-Kernel gelesen habe, ging ich davon aus, das es sich um die Ideen von Molnar und Co ging und von denen hier bemuckelt wird: https://www.osadl.org/ .

Ja, ich dachte mir schon das du das verwechselst,  :wink:

Quote from: "ralul"

OpenMP ist eine Programmiersprache, die Parallelcoding vereinfachen solle, wie Haskell?

Nein, OpenMP ist eine Programmierschittstelle (implementiert in eine library) die es Programmierern ermöglicht genaue Anweisungen zu geben ob z.b. bestimmte Threads parallel oder sequentiell Abzuarbeiten sind, und zwischen den Cores aufzuteilen.
Anwendung findet sie in C/C++ oder auch Fortran.
Moderne RT Audio Applikationen nutzen diese Schnittstelle um die Prozessor Auslastung besser zu verteilen. Aber auch andere Software macht Gebrauch davon.
Quote from: "ralul"

Wenn man kein Spezialist ist, könnte BFS die einfachere Alternative sein.

Das wage ich zu bezweifeln, die sogenannte " Komplizierte Konfiguration" muss der geneigte Pro Audio User sowieso vornehmen, damit die Audio Threads mit Echtzeit Priorität laufen, das funktioniert dann auch mit dem normale Standard Kernel.
Es mag ja sein das der BFS Kernel bessere Durchsatz Raten hat, allerdings fehlt hier, wie auch beim Standard Kernel die Möglichkeit Prioritäten genau festzulegen, und, das braucht nicht der User zu tun, das erledigen wir, die Programmierer, in unsere RT-Applikationen.
Als Beispiel mal guitarix, unser Tuner (Gitarren Stimmgerät) läuft mit einer etwas niedrigeren Priorität wie der restliche DSP part , da er nur Daten Empfängt und keine Daten an die Soundkarte weiterleitet, der Convolver läuft in 4 Threads mit abgestuften Priorität. Das gewährleistet eine Optimale Verteilung der CPU anfragen aus unserem Programm. Natürlich läuft das Programm auch wenn diese Prioritäten nicht gesetzt werden können, allerdings benötigt es dann mehr CPU zeit. Ich glaube nicht das der BFS das wieder hereinholen kann. :wink:

Noch härter wird es dann im Zusammenspiel mit weiteren rt-Applikationen, da Multipliziert sich dieses. . . .
Ausserdem geht es auch um den zugriff auf die Festplatte (recording,streaming) und, und, und.

Offline ralul

  • User
  • Posts: 1.814
Quasi-Realtime mit BFScheduler per ck-patch
« Reply #36 on: 2010/10/16, 12:31:27 »
@brummer, eine Schnittstelle openMP wird durch den BFScheduler in keiner Weise tangiert: Ich hätte irgendwo im Kolivas Patch einen bezüglichen Ifdef gesehen, was dies ausschaltet. Der BrainFuckScheduler ist ja nur ein kleiner begrenzter Patch, der den komplizierten CompletelyFairScheduler eindampft auf nur eine Ablaufwarteschlange.

Wenn man über dein Anwendungsbeispiel direkt für Realtime geschriebener Anwendungen liest, bekommt man ein Gefühl, dass man es in deinem Fall nicht mit BFS sondern eben nur RT-Patch versuchen sollte. Was anderes als RT-Patch absurd wäre.

Aber:
Die Programme sind sicher so gemacht, dass sie auch ohne RT-Patch ablaufen. Und wenn du ein ausreichend dimensioniertes System hast (Quadcore), könntest du es sicher auch mit dem BFScheduler hinbekommen, und zwar so, dass der Rest des Systems effizienter abläuft. Was jetzt heissen soll, du solltest den BFS Umstieg mit der Mühe von eigenen auf BFS angepassten schedtool Befehlen nur machen, wenn es sich lohnt, zB:
- du machst das ganze auf einem Notebook, mit dem du Mobil sein willst (Stromspareffekt)
- du machst neben Audio gleichzeitig andere aufwendige Sachen, wie VideoSchnitt. Aber da haben wir als Männer ja gar nicht die Multitaskingfähigkeit, so dass wir sowas hintereinander machen.
experiencing siduction runs better than my gentoo makes me know I know nothing

Offline brummer

  • User
  • Posts: 276
    • http://guitarix.sourceforge.net/
Quasi-Realtime mit BFScheduler per ck-patch
« Reply #37 on: 2010/10/16, 13:20:35 »
Quote from: "ralul"

- du machst das ganze auf einem Notebook, mit dem du Mobil sein willst (Stromspareffekt)

Quote from: "brummer"

Natürlich läuft das Programm auch wenn diese Prioritäten nicht gesetzt werden können, allerdings benötigt es dann mehr CPU zeit. Ich glaube nicht das der BFS das wieder hereinholen kann.

Quote from: "ralul"

- du machst neben Audio gleichzeitig andere aufwendige Sachen, wie VideoSchnitt.


Genau darum geht es doch beim rt-patch, das gibt mir die Gewährleistung das andere Programme mein "Workflow" nicht stören. Egal was ich nebenbei noch mache (Browser, mailclient, videoschitt, Image Bearbeitung, . .  .) es wird meine Audio Produktion nicht stören.    
 :wink:

Offline ralul

  • User
  • Posts: 1.814
Quasi-Realtime mit BFScheduler per ck-patch
« Reply #38 on: 2010/10/16, 14:20:27 »
@brummer, es braucht bei falscher (nicht) Prioritätensetzung nur ein winzig mehr Rechenzeit: Das Programm wird von der Ablaufwarteschlange nur ein wenig zu oft aufgerufen, kehrt ja aber wieder zurück. Kolivas benutzt dann Algorhythmen für dynamische Abschläge.

Also ich glaube, dass BFS das locker wieder reinholt...
Nichts genaues weiss man nicht und wir müssten Performance Tests machen....
experiencing siduction runs better than my gentoo makes me know I know nothing

Offline ralul

  • User
  • Posts: 1.814
Quasi-Realtime mit BFScheduler per ck-patch
« Reply #39 on: 2010/10/16, 14:29:59 »
Im letzten Blog Eintrag kündigt Kolivas eine optimiertere Version für Kernel 2.6.36 an, die sich auf IO intensive Prozesse bezieht:
http://ck-hack.blogspot.com/2010/10/2636-rc8-ck1.html
Quote from: "Kolivas"
I added a tiny patch which decreases the default dirty_ratio in the vm from 20 to 5. Here is the changelog in the patch:

    The default dirty ratio is chosen to be a compromise between throughput and
    overall system latency. On a desktop, if an application writes to disk a lot,
    that application should be the one to slow down rather than the desktop as a
    whole.
Prozesse, die an IO Überlastung haken, werden dadurch weniger oft aufgerufen, bis deren "dirty" Flag vom Kernel IO Subsystem wieder in Ordnung gebracht ist. (Dies ist auch ein Beispiel für die oben erwähnten dynamischen Effekte von BFS)
experiencing siduction runs better than my gentoo makes me know I know nothing

Offline brummer

  • User
  • Posts: 276
    • http://guitarix.sourceforge.net/
Quasi-Realtime mit BFScheduler per ck-patch
« Reply #40 on: 2010/10/16, 14:53:49 »
Ein gutes Beispiel warum es für mich nicht in Frage kommt, schließlich schreibe ich mein Record auf die Platte   :wink: , dafür erhöhe ich die Priorität für diesen Prozess. Es macht mir nichts, wenn in dieser Zeit meine GUI weniger oft upgedatet wird, Hauptsache meine (Audio) Daten gehen nicht verloren. Wenn nun eine Sheduler meint dagegen arbeiten zu müssen um den Desktop ein wenig smoother zu machen, is das nicht meins.
Es scheint mir wir reden hier aneinander vorbei.

Ralul, ich habe wirklich nichts dagegen das du denn BFS toll findest und benutzt, ich selber patche meinen Kernel auch um ihn meinen Bedürfnissen anzupassen.
Ich finde es aber verwunderlich das du den BFS hier für Anwendungen empfiehlst, die du 1.) nicht verwendest, und 2.) du nichts von verstehst (wie du selber sagst).

Der rt-patch ist auf bestem Weg in den Mainline Kernel, dieser Prozess dauert jetzt schon über 5 Jahre, zu Anfang kam den rt Entwicklern genau-soviel Ablenung entgegen wie es zur Zeit dem BFS entgegen schlägt. Ich glaube nicht das der BFS es auf absehbare Zeit in den Mainline schaft, und, ich bin mit dem RT-Kernel sehr zufrieden für meine Ansprüche. Deshalb habe ich auch keine Lust mehr mich mit dem BFS zu beschäftigen, ich wünsche dir aber trotzdem viel Erfolg bei deinen Bemühungen für BFS.

gruß  hermann

Offline ralul

  • User
  • Posts: 1.814
Quasi-Realtime mit BFScheduler per ck-patch
« Reply #41 on: 2010/10/16, 16:24:59 »
@brummer, Du musst die Priorität des IO-Subsystems erhöhen, um Daten schneller auf Platte zu schreiben. Genau das wird indirekt bewirkt (relativ) indem dirty Prozesse herabgestuft werden.

@brummer, ich wäre froh, wenn Du in einem eigenen Thread näheres über den Hintergrund der aktuellen RT Entwicklung schreiben würdest. Mein Artikel ist keinesfalls so gemeint, Dir persönlich Vorschriften machen zu wollen. Ich habe sogar aus Rücksicht auf dein Ärgernis den Threadtitel geändert, obwohl er nicht Musiker angesprochen hatte.

Ich finde dieses Forum könnte bereichert werden, wenn mehr Leute Zusammenfassungen und Hinweise geben zu Ausschnittsthemen, mit denen sie sich gerade beschäftigen. Nichts anderes versuche ich hier, mit wirklich keiner Absicht Dich zu nötigen :)
experiencing siduction runs better than my gentoo makes me know I know nothing

Offline agaida

  • User
  • Posts: 1.760
    • http://g-com.eu
Quasi-Realtime mit BFScheduler per ck-patch
« Reply #42 on: 2010/10/16, 16:44:59 »
Lasst uns doch aus dem Thread drei Wiki-Artikel machen. 1. Definitionen, was zum Thema rt auf dem Markt ist. Drei Leute, 2 1/2 Meinungen. Und eine direkte Gegenüberstellung 2. bfs, Definition, Einsatzgebiet, Einsatz. 3. rt-Patch auf der Basis Wiki-Eintrags.

Was haltet Ihr davon?
There's this special biologist word we use for "stable". It's "dead". ~ Jack Cohen

Offline brummer

  • User
  • Posts: 276
    • http://guitarix.sourceforge.net/
Quasi-Realtime mit BFScheduler per ck-patch
« Reply #43 on: 2010/10/16, 20:25:20 »
Quote from: "ralul"

Ich habe sogar aus Rücksicht auf dein Ärgernis den Threadtitel geändert, obwohl er nicht Musiker angesprochen hatte.

NaJa, der RT_Patch spricht halt in erster Linie Musiker an  :wink:
Und auch jetzt noch, der BFS hat eben mit Realtime nichts zu tu, nicht mal Quasi, bei ihm geht es um eine verbeserte Desktop Performance, und du gehst halt davon aus das das dem gemeinen Musiker ja auch entgegenkomme müsste. Dem ist aber nicht so, wir benötige eine fein strukturierte Prioritäts  Auswahlmöglichkeit um (für uns) die beste Performance zu erreichen. Der BFS bietet uns die nicht, von daher kann er nur die zweite Wahl sein. Auch brauchen wir die Möglichkeit IRQ zugriffe zu priorisieren, genauso wie Zugriffe auf die FestPlatte.
Ich brauche keinen Sheduler der meint es besser zu wissen als ich und in meine Priorisierung eingreift.  
Für den "normalen" Desktop betrieb ist das sicherlich gut und birgt ein gewisses Potential an Performance Vorteilen, aber für denjenigen der genau weiß was er will kann sich dieser Sheduler zu einem Gewissen Ärgernis entwickeln.
 :wink:

@agaida
Einen Gedanken Austausch finde ich ja gut, von mir aus kann auch jeder einen Wiki Eintrag daraus machen, aber ich selber, ne. Keine Zeit und so weiter, nicht mal für mein eigenes Programm bekomme ich mein Wiki fertig, wenn das nicht andere machen würden, gäbs da keins.   :)

Offline agaida

  • User
  • Posts: 1.760
    • http://g-com.eu
Quasi-Realtime mit BFScheduler per ck-patch
« Reply #44 on: 2010/10/16, 21:04:06 »
Ist ja auch nur so eine Idee gewesen. Zeit habe ich momentan auch nicht. Dank meiner eigenen Dösigkeit und der in meinen Augen leicht verfehlten Release-Politik bei Canonical habe ich momentan beide Hände mit der Umstellung der Maschinen auf debian zu tun.  Da ich inzwischen glaube, zu wissen was ich tue, war das der genau richtige Zeitpunkt. Nur meine eigentliche Arbeit bleibt liegen. Aufgeschoben ist aber nicht aufgehoben, ich denke, die Disskussion wird uns noch eine Weile erhalten bleiben und da ist so eine Wissensbündlung im Wiki nicht wirklich schlecht. Kommt Zeit kommt Rat. Es liegt ja jetzt eigentlich alles auf dem Tisch und kann irgendwann verwurstet werden.
There's this special biologist word we use for "stable". It's "dead". ~ Jack Cohen