[DE] Quasi-Realtime mit BFScheduler per ck-patch

[ralul]

@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?

[towo]

Was hast du gegen Xserver 1.9?
Der läuft hier super.

Code: [Select]


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


[autoandimat]

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?

[agaida]

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.

Code: [Select]


# 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.

[reddark]

OT:

Die eierlegende Wollmilchsau wird es auch bei Unix nicht geben.

Hey und wat is mit Apt!!!?

[autoandimat]

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:

[brummer]

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.

[agaida]

Hey und wat is mit Apt!!!?

Wenn, dann dpkg oder pacman  

[ralul]

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...

[ralul]

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:

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...

[brummer]

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 :?:

[ralul]

@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?