Siduction Forum
Siduction Forum => Scripting & Kernelhacking => Topic started by: ralul on 2010/10/10, 13:24:54
-
Vor Kurzem hat Con Kolivas ein neues Blog angefangen, in dem er wunderbar den Unterschied seines BFS-Schedulers zum Realtime-Kernel erklärt:
http://ck-hack.blogspot.com/2010/10/bfs-in-real-time.html
Seiner Meinung nach sollten nur Spezialisten, die wirklich was verstehen vom Kernel Hacken, die Realtime Patches für den Linux Kernel benutzen: Die für optimale Arbeit notwendigen speziellen Justierungen der Konfig seien zu kompliziert, als dass ein normaler User damit Profit für seine Arbeit erhält. So ist zB beim Video Editieren, im Gegensatz zum reinen Audio Editieren, darauf zu achten, dass noch genügend Durchlauf (Load throughput) möglich ist. Sein BFS Scheduler dagegen sei sofort optimal einsetzbar.
Einen Artikel früher spricht er sich gegen die Angewohnheit der Mainline Kernelhacker aus, ihren Scheduler nur gegen Heavy-Load zu optimieren. Das kommt bei modernen PCs nur seltenst vor und vermindert aber den Load-Troughput: Er hat einen speziellen Demo Test Patch bereit gestellt, der die Maus des Benutzers auch noch bei Overload bereitwillig ohne Verzögerung bewegen lässt, aber zur Folge hat, dass 20 Prozent weniger Durchlauf vonstatten gehen kann.
-
Hi ralul,
interessant, aber die headline könnte sachlicher formuliert sein (hatten wir uns ja alle vorgenommen).
Was regt sich in Dir auf? Was ist Dein (bestimmt interessanter) Punkt?
Laß uns teilhaben (auch die Nicht-Hacker und Nixperten)...gern auf deutsch. Schlechtes Englisch macht nichts klarer oder deutlicher.
-
interessant, aber die headline könnte sachlicher formuliert sein (hatten wir uns ja alle vorgenommen).
Was regt sich in Dir auf? Was ist Dein (bestimmt interessanter) Punkt?
@mylo, ich hatte hier im letzten Forum keine Reaktionen auf meine Kern Gedanken, deswegen die Provo-Überschrift :)
Aber was ist dran: Das Konzept des BFS-Scheduler von Kolivas ist so einleuchtend, der Gedanke von Linus Thorwalds, dass ein Scheduler alles abdecken kann, vom Handy bis zum Supercomputer, dies ist so absurd, dass ich mich wundere, warum so wenig Distributionen (PCLinuxOS) diesen BFS Desktop-User-Scheduler einsetzen. Stattdessen werden manchmal hochkomplizierte Realtime Patches eingesetzt, die niemand richtig bedienen kann. Das alles erklärt der Link zum Kolivas Blog...
Eigentlich auch enttäuschend, dass slh keinen Versuch macht in dieser Richtung. Klar, der Nachteil wäre, dass aptosid nicht mehr optimal auf einem 128cpu Server läuft, aber alle anderen und besonders Notebook Benutzer (durch mehr Kernschlaf ist der Scheduler stromsparend) hätten nur Vorteile.
-
solange der BFS scheduler nicht mainline ist, ist er für uns uninteressant.
man kann viel spekulieren und lesen, ordentlich testen ist etwas ganz anderes.
greetz
devil
-
Eigentlich auch enttäuschend, dass slh keinen Versuch macht in dieser Richtung. Klar, der Nachteil wäre, dass aptosid nicht mehr optimal auf einem 128cpu Server läuft, aber alle anderen und besonders Notebook Benutzer (durch mehr Kernschlaf ist der Scheduler stromsparend) hätten nur Vorteile.
Ganz davon abgesehen, dass der wirkliche Vorteil der slh Kernels flöten geht: Immer am aktuellen Mainline dran zu sein, den der BTS Patch ist wohl kaum immer kompatibel zum aktuellen Stand. Auf jeden Fall schlechter getestet als der CFS und natürlich wird der CFS konstant weiterentwickelt wodurch natürlich auch nichts älter ist als der Benchmark von gestern…
Davon abgesehen hatte towo ja bereits von Problemen bei sich mit dem BTS berichtet, für die meisten Anwender sind duo und quad-core Rechner ja bereits Standard und schlussendlich halte ich es persönlich für recht unwahrscheinlich, dass der normale Anwender überhaupt irgendetwas spüren wird, was nicht mit dem Placeboeffekt zu erklären ist…
Ich kenne z.B. auchh keine openmoko Distribution die den BTS verwendet, obwohl man bei einem schwachbrüstigen ARMv4 400 MHz CPU ja was bemerken sollte, wenns denn was zu bemerken gäbe…
Einbildung ist ja bekanntlich auch 'ne Bildung ;)
-
solange der BFS scheduler nicht mainline ist, ist er für uns uninteressant.
Aber auch keiner von den im slh Kernel integrierten staging Treibern ist Mainline.
Ganz davon abgesehen, dass der wirkliche Vorteil der slh Kernels flöten geht: Immer am aktuellen Mainline dran zu sein, den der BTS Patch ist wohl kaum immer kompatibel zum aktuellen Stand.
Der "BFS" Patch wird schon portiert und getestet auf 2.6.36, also ziemlich aktuell. Und ein neues Feature des BFS soll Einzug halten: Bestrafung von Threads, die viel forken.
und natürlich wird der CFS konstant weiterentwickelt wodurch natürlich auch nichts älter ist als der Benchmark von gestern…
Der Mainline CFS hat im letzten Jahr tatsächlich enorm aufgeholt durch die Anstöße, die Kolivas durch seine Demontration gegeben hat! Das war auch der Grund, warum ich zurückhaltend war das letzte Jahr den BFS zu forden, denn vielleicht holte der CFS Scheduler den BFS ja ein? Aber je tiefer man in die Materie einsteigt, desto klarer wird, der CFS ist für Großrechner mit vielen Kernen gemacht. Deswegen ist er auch viel komplizierter als der BFS Scheduler. Schon deswegen spart der BFS einige Ticks ein und hält den Rechner kühler - siehe unten.
meisten Anwender sind duo und quad-core Rechner ja bereits Standard
Erst ab mehr als 16 cores kann der Mainline CFS besser sein als der BFS Scheduler.
und schlussendlich halte ich es persönlich für recht unwahrscheinlich, dass der normale Anwender überhaupt irgendetwas spüren wird, was nicht mit dem Placeboeffekt zu erklären ist…
Man merkt es schon, jedenfalls beim 2.6.35er Kernel. Ich habe den neuen 36 Kernel ohne BFS schon getestet, er schein performanter zu werden! Besonders an den IO Operationen scheint gearbeitet worden zu sein. Es gibt ja schon längere Zeit auch die Patches für die IO Queue, die im ZEN Kernel benutzt werden. Das Thema IO ist aber so enorm viel komplizierter als der kleine Task Scheduler im Kernel, dass ich das links liegen lasse.
Man kann Performance übrigens ganz esoterisch durch Handauflegen messen: Das Gerät bleibt kühler mit BFS. Die vielen erziehlten Micro-Sleeps sparen Strom. Deswegen ist BFS besonders für mobile Benutzer interessant.
Auf jeden Fall schlechter getestet als der CFSKolivas erzählt in seinem Blog, dass er von einem Fall gehört hat, dass ein Android Hersteller intern BFS getestet hat und wegen keinerlei positiver Wirkung außen vor ließ. Dies fiel in eine Phase, in der sein BFS Feature für Mono Core wirkungslos blieb, weil er, Kolivas, keine Testrückmeldungen für diese Architektur bekommen hatte:
http://ck.kolivas.org/patches/bfs/2.6.31/2.6.31.14-bfs-315-316.patch
...Testen ist ja gerade die Aufgabe von Debian unstable Benutzern...
Und ich gehe immer noch jede Wette ein, dass die "Plugin" Architektur für Kernel Scheduler kommen wird und Linus seine Meinung wieder um 180
Grad dreht....
Oder aber Linus Thorwalds will sich die Entwicklung offen halten, weil er selbst unsicher ist wohin die Reise geht. Wenn er eine Plugin Architektur für den Scheduler offiziös akzeptierte, wäre das eine Verpflichtung für die Zukunft, die ihn in seinen Entscheidungen binden und einschränken könnte.
-
BFS für Kernel 2.6.36
Das geplante neue Feature der Bestrafung von forking Threads ist auf Eis gelegt worden nach Tests von Arch Usern (https://bbs.archlinux.org/viewtopic.php?id=106086&p=2)
These sorts of bugs, although likely due to the userspace application itself, make changes of this nature in the scheduler as the default impossible, or at least foolish. So as much as I'd like to see this change go into the next -ck release and be the default, I can't.
...
But now I can relax and just sync up with mainline again when 2.6.36 final comes out.
-
Ich habe den 2.6.35 mit und ohne CK in Arch. getestet. CK bleibt mein Favorit. Im Lastbereich wirds geringfügig langsamer, dafür ist der gesamte Desktop auch bei Vollast noch wunderbar zu bedienen. Da nehme ich etwas geringeren throughput gern in Kauf. Obwohl ich zugeben muss, dass der 2.6.35 aufgeholt hat.
-
ralul, imposant Dein Wissen. :-)
-
'wissen' im bereich kernel ist ein heikler begriff.
halbwissen führt da schnell zu falschen schlussfolgerungen.
ich selbst bin weit davon entfernt, mir in sachen kernel wissen zu attestieren.
greetz
devil
-
@agaida, interessantes Feedback. Sehe ich auch so.
Ich fände ja eine "statistische" Performance Messung interessant. Das ist jetzt ein Gedanke von mir:
Die traditionellen Performancetest versuchen mit möglichst gleichen Voraussetzung möglichst genau zu messen. Dabei müssen diese Test sich auf bestimmte Anwendungen einschränken. Zum Beispiel die berüchtigten Phoronix Tests machen in ihrer Auswahl immer das Gleiche. Dabei gibt es aber die Einschränkung, dass bei geringen Abweichungen der Versuchsanordnung falsche Ergebnisse herauskommen. Macht sich der Versuchsleiter zB nicht die Mühe immer auf dem gleichen Rechner alles gleich und neu zu installieren, sind Vergleiche hinfällig, wenn die Anordnung auf der Festplatte eine Rolle spielt, weil unterschiedliche Plätze auf einer traditionellen HD unterschiedliche IO Performance ergeben.
Dagegen Statistik:
Bei hunderten, tausenden Teilnehmern spielt nichts Besonderes mehr eine Rolle. Gemessen wird nur der statistische Trend.
Wenn soviele Benutzer, besonders hier bei aptosid, dabei sind, die den Fortschritt von Opensource unterstützen wollen, sollte es dann nicht möglich sein bei uns die Teilnahme an einem ausgefeilten statistischen Performancemessungsprogramm zu erreichen?
Es sollte so einfach wie popcon zu installieren sein, und Ergebnisse zeigen, wie zB:
- nach Einspiel von linux-image-2.6.36-1.slh.0 Verbesserung
- nach Einspiel von linux-image-2.6.36-1.slh.1 Verschlechterung
- nach Einspiel von linux-image-2.6.36-bfs357 Verschlechterung
oder zB, Benutzer von amarok haben einen viel höheren Stromverbrauch als Benutzer von audacious ....etc
Was meint ihr?
Klar müsste man auf Datenschutz achten, vielleicht anonymisiert, damit keine Trojanerhersteller Angriffspunkte ausspähen können...
-
Ich nutze nur den realtime kernel, ich bin Musiker. Deinen Vorstoß hier finde ich Schwachsinn. Du weißt wahrscheinlich das der rt patch schon seit einigen Jahren in den Mainline Kernel eingepflegt wird, das finde ich persönlich sehr gut.
Der BFS patch würde mir den zugang zu rt rechten in IRQ Bereich verschließen, was verschließt dir im Gegenzug der rt patch? Bedenke bitte das es Anwender mit anderen Anforderungen gibt als deine. Deine Überschrift ist u.a.s.
-
Naja, ich hatte geschrieben "Schwachsinn für Desktop Benutzer" nicht Musiker.
Aber ganz davon abgesehen, mit RT musst Du sehr fein justieren, und wenn Du zusätzlich Video editieren willst, sieht es wieder anders aus. C.Kolivas behauptet, dass kaum einer die Feinjustierung, die notwendig ist, hinbekommen kann um wirkliche Vorteile zu haben. Mit dem BFS hättest Du sehr einfach quasi Realtime, wenn Du das schedtool benutzt. Hast Du den Link zum Blog dazu ganz gelesen?
-
C.Kolivas behauptet....
ich kanns nicht mehr hören.
greetz
devil
-
C.Kolivas behauptet....
ich kanns nicht mehr hören.
greetz
devil
Dito, Raul, was glaubst du denn warum Musiker den rt-patch benutzen, etwa weil sie zu doof sind Ihn auch anzuwenden/auszunutzen ?
Im übrigen habe ich hier gerade die rt vergabe für IRQ's angesprochen, und nicht das scheduling. Zum rt-patch gehört ein bisschen mehr als "nur" der scheduler.
Und "schwachsinn" ist der rt-patch für niemanden außer für dich, allerhöchstens wirkungslos wenn man nicht mit ihm umgehen kann, das kann man vom BFS allerdings nicht behaupten. :idea:
-
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:
-
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.
-
Passt vielleicht zum Thema:
http://www.pro-linux.de/news/1/16270/simulation-des-linux-schedulers-vorgestellt.html
-
@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?
-
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.
-
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...
-
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)
-
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:
-
Ä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 ;)
-
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.
-
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.
-
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.
keiner tut es und es gibt Gründe dafür.
AV Linux, KX Studio, GNUGuitariNUX, um nur ein paar zu nennen, . .. .
-
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
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?
-
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.
@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.
-
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.
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?
-
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:
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 ?
-
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...
-
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 (http://de.wikipedia.org/wiki/RTLinux) oder
Wind River (http://www.rtlinuxfree.com/)
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 (http://de.wikipedia.org/wiki/OpenMP) geschriebenen Programmen verhält ?
-
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.
-
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?
-
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:
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.
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.
-
@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.
-
- du machst das ganze auf einem Notebook, mit dem du Mobil sein willst (Stromspareffekt)
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.
- 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:
-
@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....
-
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.htmlI 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)
-
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
-
@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 :)
-
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?
-
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. :)
-
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.
-
@agaida, schreib doch mal einen Thread über Maverick! Meinst Du auch, dass sie mit xserver-1.9 eine Version zu hoch gegriffen und dadurch ein dröges System fabriziert haben?
-
Was hast du gegen Xserver 1.9?
Der läuft hier super.
towo:Defiant> inxi -SG
System: Host Defiant Kernel 2.6.36-rc8.towo.2-ck1 x86_64 (64 bit) Distro sidux XFCE
Graphics: Card nVidia G94 [GeForce 9600 GT] X.Org 1.9.0 Res: 1280x1024@75.0hz
GLX Renderer GeForce 9600 GT/PCI/SSE2 GLX Version 3.3.0 NVIDIA 260.19.12
-
Ich blicke da insgesamt sehr schwer durch da mir auch jegliches Background-Wissen fehlt. :oops:
Soweit ich das ganze verstehe zielt BFS darauf ab den Desktop zu optimieren bzw smoother zu machen.
Geht das zu Lasten der Priorität von Audio-Prozessen wird der Musiker das zwangsläufig ablehnen.
Der kann ohnehin nicht viel Kompromisse machen. Wer mal Ardour & Co richtig gequält hat weiss was für ein sensibler Bereich das ist. :mrgreen:
Einschränkungen in der RT-Fähigkeit bedeuten hier nicht dass man schlechter, sondern gar nicht mehr arbeiten kann. :wink:
Ich muss jackd schon mit nem F/P von 128 stabil antreiben können. Ansonsten wäre die Arbeit mit Guitarix im ungünstigen Falle aufgrund von Delay-Entwicklungen unmöglich. Das würde für mich eine wichtige Arbeitsgrundlage kaputt machen da ich das Programm extrem häufig und exzessiv einsetze.
Ich habe leider keinen Blassen von Kernel-Geschichten. Aber ich werkel ich schon jahrelang mit Audio-Anwendungen unter Linux rum. Von daher möchte ich einfach mal schildern wie extrem die Arbeit von Musikern von der RT-Fähigkeit abhängt. :wink: Es geht im Zweifelsfall nicht um Einschränkungen in der Performance der Apps sondern um Unbenutzbarkeit dieser. :!:
Sicherlich ist der Thread nicht an Musiker gerichtet. Nur wenn man einer ist reagiert man recht schnell emotional weil man um seine Arbeitsgrundlage bangt - gerade im Zuge dass sich die RT-Fähigkeit merklich mehr und mehr in den Standard-Kernel integriert was man natürlich aus der Sicht des Musikers sehr gerne sieht. :wink:
Natürlich kann man immer einen Performance-Test machen. Sofern es irgendwo fertige Kernel gibt würde ich das mal testen.
Was mich mal interessieren würde: (das ist ein Gedanke der sich einem unwissenden Anwender in diesem Kontext einfach aufdrängt :mrgreen: )
Schliesst ein RT-Patch den BFS aus? Ist das zwangsläufig eine Entweder-Oder Frage? Oder könnte man beides in einen Kernel integrieren?
-
Schliesst ein RT-Patch den BFS aus? Ist das zwangsläufig eine Entweder-Oder Frage? Oder könnte man beides in einen Kernel integrieren?
Wozu? Das wäre gegen jegliche Gesetze des gesunden Menschenverstandes und KISS. Ich will jetzt keine Werbung für Arch oder Ubuntu machen - ein großes ABER bleibt: Bitte immer das für den jeweiligen Zweck angemessene Werkzeug benutzen. Die eierlegende Wollmilchsau wird es auch bei Unix nicht geben. Als Allgebrauchskernel ist doch der jetzige, z.B. in Aptosid einfach Klasse. Wer mehr will, kann mit entsprechendem Aufwand auch mehr bekommen.
In meinen Augen war der BFS bei den Kernels so um 31-34 fast Pflicht, um einigermassen flüssig arbeiten zu können. Ich geb zu, dass ich in diesem Bereich ein wenig extrem bin. Wenn irgendwo etwas hakelt und sich wehrt, sehe ich irgendwie rot ;).
Ein Beispiel, auch für Aptosid. Installieren, glücklich sein. Als Besitzer eine ATI-Karte (4890) mit Catalyst einmal die Größe eines Fensters ändern:
- Dumm gucken und laut Scheisse schreien.
- Auf den verwendeten X-Server schauen und nochmal fluchen.
- Auf die Distribution schauen und fluchen.
- Das Ding patchen und einsetzen, lächeln
Bei solchen Fehlern hilft kein Kernel und kein Scheduling weiter, da müssen erst mal andere Fehler beseitigt werden. Wenn man dann solche Hürden beseitigt hat, ist noch weiterhin Politur angesagt, manchmal reicht eine einfache, minimale Korrektur aus.
# CONFIG_CC_STACKPROTECTOR is not set
# CONFIG_HZ_100 is not set
# CONFIG_HZ_250 is not set
# CONFIG_HZ_300 is not set
CONFIG_HZ_1000=y
CONFIG_HZ=1000
CONFIG_SCHED_HRTICK=y
CONFIG_KEXEC=y
# CONFIG_CRASH_DUMP is not set
Das sind z.B. eine der Einstellungen, die im -7 dafür verantwortlich sind, dass das Teil sich schon recht gut anfühlt. (config_hz=300 ist meines Wissens Standard und fühlt sich unter Last richtig Scheisse an). Es gibt halt auch ohne Patches gewisse Möglichkeiten, am Verhalten des Desktops zu schrauben.
@ralul: Kann ich gerne machen, viel positives wird nicht dabei rauskommen. Es gibt halt nur einige Knackpunkte, die in meinen Augen so schwerwiegend sind, dass ich keinen Bock mehr hatte. Eigentlich werfen ich den Buben bei Canonical nur vor feige, ignorant, inkompetent und inkonsequent zu sein. Ein Stück davon steckt in jedem von uns.
-
OT:
Die eierlegende Wollmilchsau wird es auch bei Unix nicht geben.
Hey und wat is mit Apt!!!? ;)
-
Schliesst ein RT-Patch den BFS aus? Ist das zwangsläufig eine Entweder-Oder Frage? Oder könnte man beides in einen Kernel integrieren?
Wozu? Das wäre gegen jegliche Gesetze des gesunden Menschenverstandes und KISS. Ich will jetzt keine Werbung für Arch oder Ubuntu machen - ein großes ABER bleibt: Bitte immer das für den jeweiligen Zweck angemessene Werkzeug benutzen. Die eierlegende Wollmilchsau wird es auch bei Unix nicht geben. Als Allgebrauchskernel ist doch der jetzige, z.B. in Aptosid einfach Klasse. Wer mehr will, kann mit entsprechendem Aufwand auch mehr bekommen.
Das wär mehr die allgemeine "Sinn-Frage". Was mich als unwissenden mehr interessieren würde ist ob es theoretisch und praktisch machbar wäre oder nicht. :wink:
-
Das wär mehr die allgemeine "Sinn-Frage". Was mich als unwissenden mehr interessieren würde ist ob es theoretisch und praktisch machbar wäre oder nicht. Wink
Theoretisch, vielleicht, aber praktisch Schließen sie sich gegenseitig aus. Der jetzige Sheduler, CFS, war mal Bestandteil des rt-patch Sets und ist inzwischen voll im Kernel integriert, da die rt-kernel Gruppe Linus Torvalds überzeügen konnte das er besser als der bis dahin verwendete Sheduler ist. Der rt-patch addiert noch einmal die "Top Level Sheduler Klassen (-21 bis -99)" hinzu.
Dieses funktioniert mit dem BFS nicht.
Grundsätzlich verwendet der CFS drei scheduling Klassen (SCHED_OTHER , SCHED_FIFO, SCHED_RR )wobei SCHED_FIFO die für uns Musiker interessante Klasse ist.
-
Hey und wat is mit Apt!!!? ;)
Wenn, dann dpkg oder pacman :D
-
Schliesst ein RT-Patch den BFS aus? Ist das zwangsläufig eine Entweder-Oder Frage? Oder könnte man beides in einen Kernel integrieren?
Das wird eigentlich mit dem Link zu Kolivas Blog im ersten Beitrag von mir beantwortet:
Nein
Man kann aber davon ausgehen, wenn immer mehr vom RT-Patch allgemein in den Kernel integriert wird, wird Linux mit BFScheduler natürlich Realtime fähiger. Auch ist Kolivas sicher sehr offen, wenn Du BFS benutzt und Rückmeldungen mit Anforderungen an ihn sendest...
-
Con Kolivas wurde gefragt, ob er den BFScheduler für Illumos, ehemals solaris, portieren könnte. Er schaute daraufhin in die Sun Quellen, hier sein Eindruck vom Solaris Kernel Code: (http://ttp://ck-hack.blogspot.com/2010/10/other-schedulers-illumos.html)
Real neat. Extremely neat. In fact, I found it painful to read after a while. It was so neatly laid out that I found myself admiring it. It seems to have been built like an aircraft. It has everything that opens and shuts, has code for just about everything I've ever seen considered on a scheduler, and it's all neatly laid out in clean code and even comments. It also appears to have been coded with an awful lot of effort to ensure it's robust and measurable, with checking and tracing elements at every corner. I started to feel a little embarrassed by what we have as our own kernel. The more I looked at the code, the more it felt like it pretty much did everything the Linux kernel has been trying to do for ages. Not only that, but it's built like an aircraft, whereas ours looks like a garage job with duct tape by comparison.
As an aside, I did google a few terms they used which I hadn't seen before, and I was more than a little disappointed to find patents regarding the names... Sigh.
...
So what do I think of it now? It looks like an excellent design for a completely different purpose. It's built like a commercial design for commercial purposes that have very different requirements than what most of us use Linux for, but it does appear to have been done so very well. It looks like a goddamn Star Destroyer, and the Linux kernel (scheduler) suddenly looks like the Millennium Falcon. Real fast, but held together with duct tape, and ready to explode at any minute.
Ich finde dies einen amüsant beschriebenen Vergleich...
-
http://blog.robertalks.com/index.php/2010/07/09/kernel-2-6-34-1-blackjack-released-for-debianubuntu-blackjack/
und 2.6.35.6 -> Conclusion
The results indicate that CFS outperformed BFS with minimizing turnaround time but that BFS
outperformed CFS for minimizing latency. This indicates that BFS is better for interactive tasks
that block on I/O or user input and that CFS is better for batch processing that is CPU bound.
url: http://forum.xda-developers.com/showthread.php?t=653598
Ralul, du bist doch sonst immer so kritisch, warum hast du diese Eigenschaft eigentlich Kolivas gegenüber abgelegt :?:
-
@brummer, mich würden neuere Tests interessieren...
Warum sollte ich meine kritische Haltung abgelegt haben? Ich habe keine kritische Haltung im Sinne einer negativ-Mäkel artigen Grundhaltung. Im Gegenteil bin ich zu leicht zu begeistern. Mir fehlt gleichzeitig ein gewisser Respekt vor Authorität. Also bin ich wohl ein eher schwieriger Charakter?