@KunterBunter:
Meinst Du meinen letzten Satz?
Die meisten (normalen) OS (in irgendeinem PC) haben ja auch heute noch keine Notwendigkeit, irgendwelche zeitabhängige Peripherie zu steuern oder mit jemandem "von außerhalb" zu kommunizieren, der auch innerhalb einer definierten Zeitspanne eine Reaktion erwartet und wo solche Kommunikation dann nicht "message-driven" ist (womit wir wieder bei einer Queue und dem "Speichern" von Events sind).
Eine Netzwerk-Antwort in einer TCP-Verbindung ist zwar auch (in Grenzen) zeitkritisch, weil sie vor dem Receive-Timeout beim Sender gesendet werden und dort auch noch eintreffen sollte - aber eine von einem GPIO-Pin und der dort "anliegenden Frequenz" abgeleitete Zeitkonstante für irgendwelche Peripherie (wo dann der Prozessor im richtigen Takt den Pin von 0 auf 1 und wieder zurück schalten muß) ist noch einmal eine andere Qualität bei den Anforderungen an die Latenzen in einem OS.
Welchen (kumulierten) Effekt schon geringe prozentuale Abweichungen über einen längeren Zeitraum haben können, konnte man irgendwann in diesem Frühjahr z.B. bei der Absenkung der (noch einigermaßen niedrigen) Frequenz im Stromnetz beobachten, wo darauf synchronisierende Uhren dann plötzlich alle nachgingen:
https://www.heise.de/newsticker/mel...knappheit-laesst-Uhren-nachgehen-3984126.html
Wenn es also zeitkritische Aufgaben in einem OS gibt, dann brauchen diese eine einigermaßen garantierte max. Latenz bei ihrer Bearbeitung - das ist in einem "normalen" PC eher selten der Fall (weil die Peripherie meist über Controller angebunden ist, die sich selbst um die Einhaltung von Protokollen kümmern), aber in dieser Hinsicht ist die FRITZ!Box eben doch ein "embedded device" und einiges der Steuerung der Hardware wird wohl (aus Kostengründen oder warum auch immer, AVM wird zwingende Gründe haben angesichts des Aufstands, der da in Software gemacht wird) auch in Software umgesetzt.
Ich habe jedenfalls schon Boxen gesehen, die "kernel panic" im DECT-Treiber geschoben haben, weil die Timing-Abweichungen im DECT zu hoch wurden (wenn meine Interpretation der Fehlernachrichten in den Crash-Logs korrekt ist) - ich würde das u.a. darauf zurückführen, daß der Data-Link-Layer für die DECT-Funktionen wirklich in Software umgesetzt ist (ob das auch in Hardware verfügbar wäre, ggf. mit anderem Chipset, weiß ich nicht). Auch das sind sicherlich alles noch keine "kritischen Bitraten", die da zu realisieren sind (ist iirc irgendwas knapp über 1 MBit/s), aber da hier das Timing eine große Rolle spielt (das ist m.W. TDMA auf dem Physical-Layer), müssen zu sendende Daten rechtzeitig bereitstehen und empfangene rechtzeitig verarbeitet werden. Hier kommt es vermutlich eher auf die Pünktlichkeit an als auf die Power - zwischen zwei Interrupts könnte sich die CPU sogar langweilen, wenn nichts anderes zu tun ist. Aber wenn sie zwischenzeitlich etwas anderes macht, dann muß das auch umgehend unterbrechbar sein, damit der nächste Interrupt wieder "in-time" behandelt werden kann.
Da ist eine "critical section" in irgendeinem Kernel-Driver zum falschen Zeitpunkt dann auch nicht gerade hilfreich ... ich vermute mal, daß die Timing-Anforderungen bei der Kommunikation CPE <-> DSLAM auch nicht so ganz ohne sein werden (reine Vermutung, kann man sicherlich in irgendeiner Spec nachlesen, wenn's einen wirklich interessiert) und so unterscheiden sich dann AIOs eben sogar noch mit ihren "Zusatzaufgaben" recht deutlich von einfachen Modems, die ggf. sogar auf denselben Chipsets basieren (deshalb die Betonung auf die "FRITZ!Box" im Speziellen, weil sie schon eines der am höchsten integrierenden Consumer-Geräte ist) und trotzdem deutlich mehr Reserven haben, weil sie andere Aufgaben nicht kennen.
Bei der Ausführung von "normalen Tasks" auf einem beliebigen OS ohne "externe Abhängigkeiten" mag eine höhere Priorisierung einer Task eine einfache Lösung sein ... wobei auch dort (und im Angesicht von Multi-Core-Prozessoren an allen Ecken und Enden) inzwischen sehr deutlich zwischen Prozessen für
MMI und "worker threads" unterschieden wird, denn wenn - als Beispiel - das Generieren eines RSA-Keys mit 4 KBit die "responsiveness" eines GUI in den Keller treibt, ist das ja - egal wie wichtig dieser Key aus sein mag und wie hoch der Prozess priorisiert wird - eher nicht im Sinne des Erfinders/Programmierers ... es ist also (und darauf wollte ich hinaus) immer noch eine Abwägung von Vor- und Nachteilen erforderlich und ein "Priorität hochsetzen, der Linux-Kernel macht dann schon den Rest" als Behebung eines echten Bottlenecks ist etwas, was max. bis zur Abnahme durch den Auftraggeber hält und beim Auftreten von Extremsituationen im Wirkbetrieb sehr schnell seine Schwächen offenbart.
