Ich habe mal nach Windows Process Scheduler gegoogelt und 2 Quellen gefunden.
- Uni Erlangen zu dem Thema Windows Scheduler
- Ein Buch über Windows Server Internals
Die Windows Erweiterte Systemeinstellung, Hintergrunddienste zu priorisieren verändert also
etwas an den Quantum Werten für den Prozess Scheduler. Wie genau, habe ich noch nicht gefunden.
In dem Windows Server 2003 Internals Buch stand dies unter dem Kapitel "I/O Handling".
Das finde ich sehr interessant, denn Audio hat ja im weitesten Sinne mit I/O zu tun.
Interessant auch der Hinweis, dass bei Servern das Quantum höher ist als bei Workstations.
Erinnert mich ein bisschen an die ASIO Buffer size.
Immer mal wieder einen kleckerjob ausführen macht viel Arbeit, jeder wird zwar fix bedient, aber man kommt nicht nennenswert vom Fleck....
Vermutlich gibt es Situationen, wo man einfach mal mehr Zeit am Stück braucht, Arbeiten zu erledigen, damit ich nichts staut oder auch bei Last nichts verloren geht (Audio).
Sofern man in dem Bereich keinen Bottleneck hat, wird man bei der Priorisierung von entweder
Vordergrund oder Hintergrundprozessen als Anwender vermutlich nicht viel spüren.
CPUen werden halt immer schneller, das einzige was dem ganzen nicht so ganz nachkommt
sind zB Speicherzugriffe auf DRAM, deshalb gibt es bei CPUen ja auch das mehrstufige Cache Konzept.
Und dann sind wir auch schon wieder beim Numa Design, was bei Prozessoren mit vielen Cores hat, soweit ich das noch richtig in Erinnerung habe. Bei so vielen CPU Kernen können nicht alle CPUen auf das gesamte Memory zugreifen, sonst hätte man an der Stelle einen Bottleneck. Darum wird das RAM auf Gruppen von CPU Kernen aufgeteilt.
Jede Gruppe von CPU Cores hat eine direkte Anbindung auf einen Teil des Hauptspeichers,
vermutlich 1 oder 2 bestimmte DRAM Sockel.
Nun ist es aber die Kunst des Prozess Schedulers die CPU Architektur zu kennen und eine Task
möglichst auf einer Gruppe von CPU Cores ausführen zu lassen, die an das DRAM direkt angebunden
sind, wo sich die Daten befinden die der Task bearbeiten möchte, sonst gibt es zusätzliche Latenzen,
weil der viel langsamere DRAM-Zugriff über Cross Links zwischen den CPUen einfach noch länger dauert.
Das ist wohl der grund, weshalb über lange Jahre Intel für den Audio Bereich grundsätzlich besser geeignet war,
weil Intel im Gegensatz zu AMD effizientere CPU Cores designed hat, die ohne NUMA design auskommen.
Da hat noch jeder Core direkten Zugriff auf das Memory.
Fazit:
- Moderne AMD CPUen sind äußerst fix, die Frage ist, wie NUMA design sich auf systeminterne Latenzen auswirkt (DPC Latenz, etc)
- Die Optimierung von Hintergrunddiensten ist bei sehr performanten Systemen möglicherweise nicht direkt spürbar.
Ich persönlich werde diese Einstellung nach wie vor beibehalten. Ich empfinde das wie einen "Sicherheitsgurt" im Auto.
Im normalen Betrieb spürt man keine Vorteile, in Ausnahmesituationen könnte es vielleicht doch helfen.
Zumindest wird es nach wie vor von vielen Herstellern weiterhin empfohlen und es war in der Vergangenheit ja auch anscheinend mal erforderlich. Und so viel hat sich an der prinzipiellen Art und Weise, wie Rechner intern arbeiten, auch nicht geändert.
Sorry, keine 100% wasserdichte Erklärung, aber zumindest wird die Richtung in die das ganze wirkt, etwas klarer.
