Login
Newsletter
Werbung

Thema: SCHED_DEADLINE in den Kernel aufgenommen

20 Kommentar(e) || Alle anzeigen ||  RSS || Kommentieren
Kommentare von Lesern spiegeln nicht unbedingt die Meinung der Redaktion wider.
0
Von maxxx am Mi, 22. Januar 2014 um 14:06 #

Und was kann der jetzt besser, als die anderen?

0
Von Pffft... am Mi, 22. Januar 2014 um 14:12 #

die Software und die Distributionen müssen diese Mechanismen auch mal nutzen. Zum Beispiel würde es sich ja anbieten, AV-Applikationen (auf dem gemeinen Desktop wohl das einzige, was von Echtzeit profitiert) in einen GUI- und einen Hintergrundprozess aufzuspalten, wobei letzterer dann mit Echtzeit läuft. Man könnte mit der lahmsten Hardware zumindest ruckelfrei Musik und Videos abspielen. So hat das schon vor 15 Jahren mit nur wenig Gefummel und den simplen Programmen und der Hardware damals geklappt.

Und heute? Keine Chance, gigantische AV-Stacks, in denen der normale Anwender niemals durchschaut, welche Komponente nun für das Ruckeln verantwortlich ist. Den ganzen Browser wollte ich auch nicht unbedingt mit SCHED_FIFO laufen lassen, dafür ist mir das Ding dann doch zu fett. Glücklich, wer eine Audio-Distribution verwendet, da ist zumindest dieser Teil besser vorkonfiguriert. Dafür ist dann irgendwas anderes kacke.

  • 0
    Von BT90 am Mi, 22. Januar 2014 um 19:28 #

    SCHED_FIFO gehört ins Schulbuch und nicht auf ein System,das man wirklich benutzen will.

    0
    Von Herzlos am Mi, 22. Januar 2014 um 19:32 #

    AV-Applikationen (auf dem gemeinen Desktop wohl das einzige, was von Echtzeit profitiert)

    Es macht auch Sinn, wenn auch Computerspiele schnellstmöglich auf die Eingaben des Nutzers reagieren können und nicht nur Audio & Video-Applikationen.


    Meiner Erfahrung nach hakte es bei Egoshootern immer fühlbar, so dass ich z.B. Doom 3 trotz brauchbarer Frameraten lieber unter Windows durchgespielt habe. Mit einem anderen Scheduler kann so etwas natürlich wesentlich besser laufen.

    Man könnte mit der lahmsten Hardware zumindest ruckelfrei Musik und Videos abspielen. So hat das schon vor 15 Jahren mit nur wenig Gefummel und den simplen Programmen und der Hardware damals geklappt.
    BeOS ;)

    • 0
      Von Pffft... am Mi, 22. Januar 2014 um 20:47 #

      Linux anno 1998. Damals war das kein Problem, weil die zeitkrtische Anwendung eben mpg123 war oder der Realplayer (spuck!) und das ganze direkt auf /dev/dsp und /dev/video ausgab. Heutzutage sind einerseits die Ansprüche etwas gestiegen, es soll direkt aus dem Browser gehen - ist ja nach 15 Jahren auch nicht zuviel verlangt -, andererseits sitzt jetzt noch ein Sound-Framework des Desktops und womöglich noch ein Soundserver dazwischen der irgendwelche supertollen Dinge macht, die 99% der Anwender nicht benötigen.

      Da wäre es toll, wenn die Desktop-Distributionen eben nicht auf Featuritis setzen würden, sondern darauf, was wirklich wichtig ist: Ruckelfrei, unabhägig ob die Hardware nun von 2004 stammt oder von 2014. Es ging wie gesagt bereits 1998.

      • 0
        Von Herzlos am Mi, 22. Januar 2014 um 23:18 #

        Linux anno 1998. Damals war das kein Problem,

        Doch, als Unix like Multiuser- und Multitastkingbetriebssystem musste Linux schon damals mehrere Programme "gleichzeitig" laufen lassen und war auch schon damals für Realtimeanwendungen nicht besonders gut geeignet bzw. optimiert, der Schwerpunkt der Entwicklung lag zu dem Zeitpunkt immer noch auf Serveraufgaben und Multimedia stand da eher ganz hinten an.
        Die Prozess- und auch Threadverwaltung war schon damals ein Thema und daran änderte auch der direkte Zugriff auf /dev/dsp und /dev/video nicht viel.

        BeOS war zu dem Zeitpunkt, als es neu war, dagegen eine Wucht.
        Das es sich nicht gegen Windows behaupten konnte und meiner Meinung nach auch die Multiuserfähigkeit fehlte, ist ein anderes Thema, aber was zeitkritische Multimediaanwendungen anbelangt, dafür war es wie geschaffen.

        womöglich noch ein Soundserver dazwischen der irgendwelche supertollen Dinge macht, die 99% der Anwender nicht benötigen.

        Der Soundserver sorgt dafür, dass der Sound von verschiedenen Anwendungen über ein einziges Sounddevice quasi gleichzeitig ausgegeben werden kann.
        Ohne Soundserver würde die eine Anwendung das Sounddevice belegen, ehe die andere Anwendung dieses benutzen kann.
        Insofern brauchen so etwas 99 % der Anwender.
        Die einzige Ausnahme davon sind bestenfalls diejenigen, die eine Soundkarte eingebaut haben, die Hardwaremixing beherrscht, aber da ist die Anzahl der Sounds die gleichzeitig zusammengemischt werden können auch irgendwann limitiert.

        • 0
          Von Pffft... am Do, 23. Januar 2014 um 00:36 #

          Ohne Soundserver würde die eine Anwendung das Sounddevice belegen, ehe die andere Anwendung dieses benutzen kann.
          Das kann alsa bereits innerhalb des Treibers - ohne spezielle Hardware. Dazu benötigt man keinen Soundserver, den braucht man nur, falls man Netzwerksound haben will und/oder Quellen ständig umstöpseln.

    0
    Von Der Jupp am Mi, 22. Januar 2014 um 20:03 #

    ????

    Hä?

    Hier geht es um den Prozess-Scheduler des Kernels. Da kannst pro Kernel genau einen haben! Unterschiedliche Scheduler pro Prozess??? Da müsstest du für jeden unterschiedlichen Scheduler schon eine eigene VM aufmachen...

    Es gibt noch I/O-Scheduler. Dort gibt es übrigens den Deadline schon sehr viel länger. Aber auch den kannst du nur einmal pro Blockdevice haben.

    Und ja, das haben die guten Distris auch implementiert, z.B. über tuned.

    Der Jupp

    • 1
      Von Pffft... am Mi, 22. Januar 2014 um 20:40 #

      Falsch. man sched_setscheduler.

      Man kann je Thread und jederzeit im Programmlauf den für den Prozess zuständigen Scheduling-Mechanismus umschalten, z.B. um einen zeitkritischen Teil einer Anwendung in Echtzeit ablaufen zu lassen, den Rest dann aber wieder in SCHED_OTHER.

0
Von Herzlos am Mi, 22. Januar 2014 um 19:27 #

Gibt es eine Möglichkeit bei laufendem System herauszufinden, welcher Scheduler im Einsatz ist?
Also kann man das irgendwie auslesen?

Von den Distributionen bekommt man in der Regel ja fertige Binarys
und spontan fällt mir nur ein, in die Kernelkonfiguration mit der das Binary erstellt wurde zu schauen, aber vielleicht gibt es dafür auch eine bessere Möglichkeit.

Pro-Linux
Traut euch!
Neue Nachrichten
Werbung