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

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

autoandimat

  • Guest
[DE] Quasi-Realtime mit BFScheduler per ck-patch
« Reply #15 on: 2010/10/12, 22:55:29 »
Ich verwende auch seit Jahren fast ausschliesslich RT-Kernel. Als Musiker ist das schlichtweg nötig wenn man nicht will dass Ardour & Co ihren Dienst verweigern.
Zumindest im Audio-Bereich wüsste ich nicht was ich justieren sollte. :roll: Um stabil mit Jackd-Anwendungen zu arbeiten reichte es immer den Kernel einzuspielen damit die Apps ihren Dienst tun.
Beim Videoschnitt ist RT ja primär nicht unbedingt nötig. Hier sehe ich das Hauptproblem eher darin dass es derzeit noch an brauchbaren Apps mangelt die man oben drauf schraubt. Wenn Cinelerra mal wieder mit PAL nicht klar kommt nützt mir der beste Kernel der Welt nix. :mrgreen:

Seit sidux 01-2010 verwende ich zusätzlich aber auch den Standard-Kernel da der für viele meiner Zwecke reicht um unter 5 ms stabil arbeiten zu können - was ich sehr gut finde.

So ganz verstanden habe ich nie wo der Nachteil im RT-Patch sein soll.
Da ich keine grosse Lust hatte immer zu rebooten habe ich irgendwann auch alles andere (ausserhalb von Musikaufnahmen) mit den RT-Kerneln gemacht. Dabei konnte ich über viele Jahre nicht den leisesten Nachteil feststellen.

Ich habe von den ganzen Kernel-Geschichten absolut null Ahnung. Das ist nur eine reine Einschätzung bzw Erfahrung eines unwissenden Anwenders. Aber ich konnte wirklich auch bei allen anderen Alltagsanwendungen nix feststellen was jetzt anders oder schlechter laufen soll.
Vielleicht kann mich da jemand, der mehr Einblick hat, aufklären. :wink:

Das Einpflegen des RT-Patches stand ja schon vor elf Jahren zur Debatte. Ich hatte kürzlich auf dem Dachboden eine alte Linux-Magazin Zeitschrift von 12/99 gefunden. Da stand gleich auf der News-Seite dass ab Kernel 2.2 der RT-Patch in den Standard-Kernel implementiert werden sollte was aber wohl noch streitbehaftet war.
Irgendwie wurde das scheinbar erst in den letzten Monaten weitgehend umgesetzt – zumindest so dass ich es anhand praktischer Anwendungen merken kann. Auf jeden Fall finde ich es gut dass sich in der Richtung offenbar etwas nach vorne bewegt. :wink:

Offline agaida

  • User
  • Posts: 1.760
    • http://g-com.eu
Re: Bfs bleibt wie es war
« Reply #16 on: 2010/10/12, 23:32:53 »
Bitte keine schweren Waffen, an rt führt für Prozesse, die wirklich rt benötigen, nichts vorbei. Das ist natürlich bei Musik der Fall. Bei Steuerungen und anderen Anwendungen, die definierten i/o brauchen auch. Und ja, der rt-Kernel ist relativ schwierig zu justieren. Das das Ding nicht für maximalen Durchsatz gedacht ist, ergibt sich aus der Natur der Sache. Das wurde doch auf kernel.org hoch und runter diskutiert. Im Gegensatz dazu ist das ck-Patchset relativ einfach eingesetzt, 2 oder 3 Kernelparameter gesetzt und gut ist. Der Erfolg der ganzen Aktion ist, dass der Desktop snappy wird, wie ich das zuvor noch nie gesehen habe. Zur einfachsten Konfiguration kommt noch ein eigentlich für den Desktop-Bereich zu vernachlässigender Verlust an Durchsatz. Eigentlich genial.

Wenn die Buben um Ingo Molnár es mit dem normalen CFS schaffen, eine in Großteilen gleiche Desktop-Experience zu bieten, ist doch allen geholfen und das ck-Patchset eigentlich obsolet. Schneller als rattenschnell geht halt nicht. Bis dahin ist es aber noch ein weiter Weg und bis dahin muss sich die mainline am ck-Kernel messen lassen. So sehr auf Kernel kompilieren stehe ich nicht, die Zeit könnte ich auch für was anderes verwenden.
There's this special biologist word we use for "stable". It's "dead". ~ Jack Cohen

Offline reddark

  • User
  • Posts: 1.051
    • http://www.klangruinen.de/

Offline ralul

  • User
  • Posts: 1.814
Re: Bfs bleibt wie es war
« Reply #18 on: 2010/10/13, 12:32:18 »
@agaida, vielen Dank für Deine versachlichende Darstellung sogar aus beiden Blickwinkeln!

Der Nachteil von meiner provozierenden Überschrift scheint zu sein, dass die Leute, die sich auf den Schlipps getreten fühlen, aus Ärger nicht mehr unvoreingenommen lesen. Sollte man doch lieber lassen provozierend über zu schriften. Soll ich die Überschrift ändern?
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 #19 on: 2010/10/13, 13:15:03 »
Quote
Soll ich die Überschrift ändern?

Ja, das alles hier hat mit dem Realtime Kernel nicht das geringste zu tun.
Hier werden Eier mit Kartoffeln verglichen, meinethalben, kannst du über den BFS referieren bis du alle überzeugt hast das er besser für den Default Desctop User geeignet ist als alles andere in der freien Software Welt, das alles hat aber überhaupt garnichts mit dem RT-patch zu tun. Der rt-patch richtet sich an Anwender die Prozess Prioritäten vergeben müssen um zu arbeiten, eine dreidimensionale Faltungsmatrix z.b. funktioniert nun mal nur so. Da kann "dein BFS" nur abstinken.
Auch sehe ich eine komplizierte Justierung des RT kernels nicht, rechte werden mit PAM gesetzt, ein Zweizeiler, und Fertig, wo ist das bitte kompliziert?  

Ärgerlich ist also deine Titel Auswahl, genauso wie die Art deiner Argumentation.

Die Maintainer des rt-patches arbeiten seit Jahren hart daran den patch so auszugestalten das er anderen keine Behinderung ist, also die gesamte Community keinen Nachteil davon hat. Im Gegenteil, die bereits im Mainline Kernel eingeflossenen Änderungen haben einen Performance Vorteil für alle gebracht. Auch Sie standen zunächst vor verschlossenen Türen und müssten lange Diskutieren bis sie einen Platz bei Kernel.org bekamen. Das als Schwachsinn zu bezeichnen ist schon ein wenig mehr als provokativ, . . .

Wenn C.Kolivas seien BFS patch im Mainline sehen will, muß er wohl oder übel besser mit den anderen Kernel groups zusammen arbeiten.

Offline ralul

  • User
  • Posts: 1.814
Quasi-Realtime mit BFScheduler per ck-patch
« Reply #20 on: 2010/10/13, 13:56:33 »
Ich habe den alten Titel:
"Realtime Kernel ist Schwachsinn für Desktop User"
geändert in:
"Quasi-Realtime...."

@Brummer, auch wenn du dich eigentlich als Musiker nicht hast angesprochen fühlen sollen! Es war gemeint in der Hinsicht, dass RT-Kernel angeblich zu schwierig im täglichen Betrieb zu konfigurieren wären um einen Vorteil davon zu haben: Nach Deiner Erfahrung ist es aber einfach?

Oder ist es vielmehr so wie weiter oben autoandimat beschreibt, dass die heutigen cpu Kapazitäten und die gleichzeitige qualitative Verbesserung moderner Kernel einen speziellen Realtime Kernel meistens überflüssig machen?

Was dann ja noch nicht heisst, den optimalen Einsatz in Hinsicht auf Stromverbrauch bei Notebooks gefunden zu haben...
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 #21 on: 2010/10/13, 13:56:39 »
Ich halte nicht viel davon, theoretische Disskussionen zu führen. Das ist auch bei Schedulern der Fall. Ich bin auch nicht gegen Provokationen. Richtig eingesetzt dienen sie dazu, die eigene Meinung relativ eindeutig darzustellen. Wenn man sich die berühmt/berüchtigten Mail von Linus durchliest, dann ist die Auseinandersetzung hier noch reines Werfen mit Wattebällchen. Ich erinnere an die Diskussionen zu ext4 und btrfs und bestimmete Sachen wie das Verhalten von Commits und Journaling. Die Worte von Linus wahren wohl braindead, bullshit uä. Das mag nicht jeder mögen, aber es wurde was bewegt.

Man wird bei Real-Time-Verarbeitung immer relativ viel Verlust im Durchsatz haben. Dadurch, dass ich auf jeden Fall zu einer genau definierten Zeit einen bestimmten Prozess ansprechen und ausführen muss, um Echtzeit zu erreichen, blocke ich alle anderen Prozesse, die dieser Priorität im Weg stehen. Die tatsächlichen Messungen und theoretischen Hintergünde sind recht eindrucksvoll. Die praktische Auswirkung auch. In Kürze: Der Desktop und alle anderen Anwendungen profitieren durch das Scheduling ganz gewaltig, der Durchsatz sinkt drastisch, was man bei den Datenmengen auf einem Desktop aber nicht merkt. Im Serverbereic führt an CFS nichts vorbei. Der Prozess, der wirklich arbeiten muss, bekommt die meiste Rechenleistung, was auch sehr sinnvoll ist. Leider führt das dazu, dass Prozesse, die kaum Last erzeugen, unterpriorisiert werden, und das in jedem Fall. Die Prozesse rund um den Desktop gehhören halt dazu. Das führ dann dazu, dass der Desktop nicht rund läuft. Zusammen mit einer Schedulingfrequenz von 300hz default oder noch niedriger macht das keinen Spass. Kolivas stösst mit seinen Überlegungen genau in diese Lücke und verteilt die Rechenzeiten halt kreativ um. Das ist nicht das allein Selig machende, aber im Desktop-Bereich State of Art. Und nur darum geht es.

Wer seine Gewichtung auf Signalverarbeitung setzt, für den sind CFS und BFS sinnlos, dieses Scheduler können vom Design auf keinen Fall die an sie gerichteten Anforderungen erfüllen. Das ist doch aber kein Drama, da man mit Linux, Wissen und Verfügbarkeit vorausgesetzt, die Werkzeuge zur Hand hat, die man geziehlt einsetzen kann, um Probleme zu lösen. Das mag dann jeder für sich tun.

Um ein kleines Beispiel für eine absolute Fehlkonfiguration im Serverbereich zu bringen: RT-Kernel, ext4 mit data=journal auf einem Mailserver mit 100000  Mails stündlich, dazu noch ein KDE mit vollständiger Kontrolle der Sensoren und auf dem Schirm die graphische Auswertung dieser. Und weil die Maschine eh nichts zu tun hat, noch eine größere Datenbank mit der Warenwirtschaft und 100 Conkurrent Usern. (Sorry, ein wenig extrem, aber heftiger fällt mir momentan nichts ein)
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 #22 on: 2010/10/13, 14:10:52 »
Quote from: "agaida"

Man wird bei Real-Time-Verarbeitung immer relativ viel Verlust im Durchsatz haben. Dadurch, dass ich auf jeden Fall zu einer genau definierten Zeit einen bestimmten Prozess ansprechen und ausführen muss, um Echtzeit zu erreichen, blocke ich alle anderen Prozesse, die dieser Priorität im Weg stehen.


Das ist falsch, bei Rt-Prozessen geht es nicht um die Abarbeitung zu einer bestimmten Zeit, sondern "bis zu einem bestimmten Zeitpunkt", ich denke der Unterschied wird dir sofort auffallen, was das blocking betrifft. Zu keiner Zeit wird CPU zeit einfach nur geblockt, lediglich bestimmte definierte Prozesse vorrangig abgearbeitet wenn sie anstehen, wenn sie nicht anstehen, wird auch nicht auf sie gewartet.   :wink:

Offline agaida

  • User
  • Posts: 1.760
    • http://g-com.eu
Quasi-Realtime mit BFScheduler per ck-patch
« Reply #23 on: 2010/10/13, 14:31:38 »
Äh? Dann interpretieren wir den Begriff "bis zu einem bestimmten Zeitpunkt" unterschiedlich. Kern des RT ist, dass dieser Zeitpunkt der Abarbeitung definitv und unter allen Umständen erreicht werden muss. Alles Andere ist diesem Ziel untergeordnet, egal was es ist. Diese Herangehensweise (führt zu)(kann zu) (wird zu) Einbrüchen im Durchsatz (führen). Das ist aber wie angesprochen, nicht wirklich tragisch, ich habe das eventuell unklar dargestellt, blockiert wird nichts, es wird den Prozessen nur die Zeitscheibe entzogen ;). Es ist schon eine ganze Zeit her, ich muss mal sehen, ob ich den Thread von Molnar & Co. zu diesem Thema noch finde. War hochgradig interessant und richtig schön abgehoben. Dass müsste ich aber leider verschieben, denn ich stehe momentan vor den Trümmern meiner IT-Struktur und werf da einige wenige Buschtrommeln raus und strukturiere neu ;)
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 #24 on: 2010/10/13, 15:10:37 »
Ich habe damals im sidux forum mal einen Artikel über dieses Thema verfasst, der ist dann ins Wiki gekommen. Ralul kennt denn ja, vielleicht hilft er dir ja besser zu verstehen was der rt-patch überhaupt macht und warum er benutzt wird.
http://sidux.com/index.php?module=Wikula&lang=el&tag=RTKernel
Aber nochma, der rt-patch hat nichts mit dem BFS zu tun, man kann beide nicht vergleichen, sie zielen auf völlig unterschiedliche Nutzergruppe ab.

Offline agaida

  • User
  • Posts: 1.760
    • http://g-com.eu
Quasi-Realtime mit BFScheduler per ck-patch
« Reply #25 on: 2010/10/13, 15:33:27 »
Wenn ich Hilfe bräuchte, um den RT-Patch zu verstehen, würde ich danach fragen. Darum ging es hier nicht. Hier ging es um Vor- und Nachteile einiger Scheduler. Ich finde es immer wieder witzig, dass wenn einem die Argumente fehlen, die Qualifikation des Gegenüber in Frage gestellt wird, Wortklauberei betrieben wird oder Aussagen verdreht werden, nur um die eigene Meinung zu untermauern.

Der rt-Patch hat sehr wohl sehr viel mit BFS zu tun: Linux, Scheduling, Prozesssteuerung, Rechenzeitverteilung. BFS wurde fast ausschließlich für die Desktop-Anwendung auf kleinen Systemen mit geringer Prozessorenzahl entwickelt. Nicht mehr und nicht weniger. Wie Eingangs erwähnt ist RT für Musik unbedingt erforderlich. Das hast Du in Deinen Postings ja auch klar gemacht und keiner hat Dir wiedersprochen. Für den Desktop ist RT nicht die optimale Lösung, sonst würden ausnahmslos alle Distributionen ihren Standard-Desktop mit RT herausbringen. Genau dass ist der Punkt - keiner tut es und es gibt Gründe dafür.

Ich bin draussen aus dieser Diskussion.
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 #26 on: 2010/10/13, 16:36:02 »
Also eingangs hieß es hier "Der RT-Kernel ist Schwachsinn für Desktop User", von Shedulern war gar nicht die rede. Ich habe dadrauf hingewiesen das dieses Statement Schwachsinn ist.
Ich habe auch mehrfach schon dadrauf hingewisen das der rt-patch aus weit mehr als dem Sheduler besteht, der ist ja inzwischen garnicht mehr Bestandteil des rt-patches, sondern schon in den mainline kernel eingeflossen.

Der BFS bietet einen anderen Scheduler, DAS MACHT DER RT_PATCH NICHT !!!
Der RT-Patch addiert nur neue Sheduling Klasse dazu.
Also Hallo, wo ist hier der vergleich ???
Das eine hat mit dem anderen nichts zu tun.
Wenn du den von mir verlinkten Artikel gelesen hättest, wüstes du das es von mir bestimmt keine Abwertung deiner Kenntnisse sein sollte,
Die rt-kernel gruppe arbeitet hart um den rt-patch in den mainline kernel einzubauen ohne andere zu behindern, das sehe ich beim BFS nicht.

Quote

keiner tut es und es gibt Gründe dafür.

AV Linux, KX Studio, GNUGuitariNUX, um nur ein paar zu nennen,  . .. .

autoandimat

  • Guest
Quasi-Realtime mit BFScheduler per ck-patch
« Reply #27 on: 2010/10/13, 22:29:06 »
Quote from: "ralul"
Oder ist es vielmehr so wie weiter oben autoandimat beschreibt, dass die heutigen cpu Kapazitäten und die gleichzeitige qualitative Verbesserung moderner Kernel einen speziellen Realtime Kernel meistens überflüssig machen?

So ist es noch nicht ganz. :wink: Es geht aber scheinbar tendenziell in die Richtung dass der Standard-Kernel immer RT-fähiger wird.
Ich verwende kaum Plugins und nur sehr wenig virtuelle Klangerzeugung. Wenn ich also nur Ardour, ZynAdd und Guitarix gleichzeitig einsetze und auf Plugins weitestegehend verzichte komme ich mit dem aptosid-Standard-Kernel bis weit über 40 Spuren aus.
Das geht jedoch derzeit nur bei meinem sparsamen Workflow. Man sieht aber deutlich die Tendenz wie sich das Realtime-Verhalten von Version zu Version bei den Standard-Kerneln verbessert. :D

Quote from: "brummer"
Zu keiner Zeit wird CPU zeit einfach nur geblockt, lediglich bestimmte definierte Prozesse vorrangig abgearbeitet wenn sie anstehen, wenn sie nicht anstehen, wird auch nicht auf sie gewartet. :wink:

Für mich (als absoluten Laien :oops: :wink: ) hört sich das so an als wenn der RT-Patch nur dann aktiv greift wenn Prozesse anliegen welche RT erfordern. Wenn nicht hat man also praktisch funktionell das gleiche wie mit einem Standard-Kernel?

Offline brummer

  • User
  • Posts: 276
    • http://guitarix.sourceforge.net/
Quasi-Realtime mit BFScheduler per ck-patch
« Reply #28 on: 2010/10/14, 09:16:56 »
Quote from: "autoandi"

Für mich (als absoluten Laien  ) hört sich das so an als wenn der RT-Patch nur dann aktiv greift wenn Prozesse anliegen welche RT erfordern. Wenn nicht hat man also praktisch funktionell das gleiche wie mit einem Standard-Kernel?


Laienhaft betrachtet, JA.  :) Kernel intern laufen einige Prozesse natürlich anders ab.
Das der Standard Kernel immer RT fähiger wird liegt eben daran das der rt-patch Stück für Stück eingepflegt wird. Dafür sind natürlich apassungen an die Bedürfnisse anderer Benutzergruppen nötig. Das ist es, was C.Kolivas vermissen lässt, Linux ist ein Community Projekt, es gibt auch andere nutzer als den Default Desktop User.
Quote from: "ralul"

@Brummer, auch wenn du dich eigentlich als Musiker nicht hast angesprochen fühlen sollen! Es war gemeint in der Hinsicht, dass RT-Kernel angeblich zu schwierig im täglichen Betrieb zu konfigurieren wären um einen Vorteil davon zu haben: Nach Deiner Erfahrung ist es aber einfach?

Ja, wie gesagt, es sind einfach zwei Zeilen für PAM. Um den Rest kümmert sich die verwendete Software. Allerdings, wie schon mehrfach erwähnt, der Normale Desktop User wird da nichts von haben, deshalb sage ich ja auch die ganze Zeit, rt und BFS haben nichts miteinander zu tun, BFS -> Desktop User und  RT -> Pro Audio User.

Offline ralul

  • User
  • Posts: 1.814
Quasi-Realtime mit BFScheduler per ck-patch
« Reply #29 on: 2010/10/14, 12:32:57 »
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.
Quote
Allerdings, wie schon mehrfach erwähnt, der Normale Desktop User wird da nichts von haben
Weswegen meine ursprüngliche Überschrift mit dem Zusatz Gültigkeit hat?
RT ist Schwachsinn für den "normalen" Desktop Benutzer

Aber lassen wir es mit Rechthaberei. Kolivas meint, dass bei RT-Threads > Anzahl_Cores leichter "quasi" Realtime Ergebnisse mit seinem BFScheduler zu erwarten sind?
experiencing siduction runs better than my gentoo makes me know I know nothing