Windows 10 1903

Hab jetzt mit LICEcap 1.28 for Windows im Laufe der Woche verschieden Windows Versionen (Win7 Aug. 2018; Win10 1511; Win10 1903),
die LeistungsAnlzeige von Cubase 10.0.40 (ohne offenen Projekt) gecaptured, so dass man die großen Spikes sieht. Durch LICEcap hat man leider mehr und hefigere Spikes.

Auf einen ASUS x99 deluxe
Intel 5960x (3GHz fixed)
RME HDSPe MADI FX

Reihenfolge der gif's jeweils:

32 Samples:
win7 32.gif

win10 TH2.gif

1907 32.gif



64 Samples:
win7 64.gif

win10 TH2 64.gif

1907 64.gif



128 Samples:
win7 128.gif

win10 TH2 128.gif

1907 128.gif



Die Samping-Rate Anzeige bei Win7 im Treiber Pannel, zeigt leider nicht 44,1khz an, weil ich die Sampling-Rate versehentlich, mit den Pitch-Regler im Treiber-Pannel verstellt habe.

Lg
 
Zuletzt bearbeitet:
naheliegender Tipp wart doch stets, in den erweiterten Computereinstellungen die Leistung von "Programme" auf "Hintergrunddienste" zu stellen, da ASIO als Hintergrunddienst arbeitet.
War damals zu XP-Zeiten ein Tipp von RME.
Ist aber seit Windows 7 nicht mehr nötig.
Wie Northern schon geschrieben hat, hält sich der Tipp aber hartnäckig in vielen Foren. ;)

Empfiehlt auch Focusrite immer noch für Windows 7.
https://support.focusrite.com/hc/de/articles/207726799-Windows-7-für-die-Arbeit-mit-Audio-optimieren

Warum ist es Deiner Meinung nach seit Windows 7 nicht mehr nötig ?
Das würde mich mal interessieren.
Falls Du URLs zu dem Thema hättest, nur her damit, vielen Dank.
 
Du meintest mit Deiner Nachfrage zwar sicher Realist, der mir geantwortet hatte....aber spannender als die Frage, ob der Tipp unter Windows 10 weiterhin, und wenn nicht warum nicht Bestand hat, ist doch die Frage, ob er unter XP bis Win7 überhaupt jemals Bestand hatte und nachweislich etwas bewirkt hat? Die Umschaltung "Programme zu Hintergrunddienste" ist stets derart tief in den Menüs, dass es schwerfällt zu glauben, dass mehr als 0,0001% aller Win-Nutzer jemals überhaupt diesen Schalter auf Hintergrunddienste gestellt hat....und nur 0,0001% von denen wiederum in tatsächlichem Wissen und Überzeugung darüber, dass sie damit etwas bewirken.
Offiziell dokumentiert außer einem Mouse-Over Tooltip unter Win-Xp war dieser Switch nie und was genau der im OS dann anders macht und wie sich das auf welche Art von Anwendungen jeweils auswirkt.
Wir argumentieren hier nur aus Cubase-Audio-Optimierungssicht....aber über 20 Jahre seit XP bis heute mit tausenden Hobby- und professionellen Anwendungs-Softwares hätte das doch mal schon längst präsenter gemacht und MS diesen Switch direkt ins Startmenü verfrachtet, wenn die Zuordung von Programme und Hintergrunddienste so einfach ist und der Nutzen, es richtig einzustellen im jeweiligen Kontext denn ach so groß...war wohl immer schon eine Luftnummer dieser Tipp und der Switch selbst niemals messbar belegt in seinem Nutzen und Wirkung. Wer das da versteckt, wo es ist, der will auch nicht, dass der normale User das ständig ändern muss...ich lasse es seit etlichen Jahren auf "Programme"...meine Leistung reicht Dank Top Hardware...ob ich nun 0,03% verschenke durch das nicht-umstellen...so what...;)
Von einem OS im Jahre 2019 erwarte ich zudem, dass es meine Software entsprechend erkennt und deren Bedürfnisse und seine Ressourcenverwaltung on the fly entsprechend ausrichtet statt sich tief in Menüs klicken zu müssen vor Start und nach Beenden wieder zurück in der Angst, dass World of Warcraft mit "Hintergrunddienst" mit sicher 10fps weniger läuft!
 
Sorry, aber Deine Antwort ist etwas .. nichtssagend. Viele Vermutungen, eine Erwartungshaltung, aber doch irgendwie keine wirkliche Antwort auf meine Frage.
 
"Low Latency ASIO Betrieb unter Windows 2000/XP mit Single CPU System
Um ASIO mit niedrigsten Latenzen unter Windows 2000/XP auch mit nur einer CPU nutzen zu können, muss die Systemleistung auf Hintergrundbetrieb optimiert werden. Dies geschieht über Systemsteuerung/System/Erweitert/Systemleistungsoptionen. Hier die Vorgabe 'Applikationen' ändern zu 'Hintergrunddienste'. Damit sinkt die niedrigste nutzbare Latenz von circa 23 ms auf circa 3 ms."

http://www2.rme-audio.de/support/faq.php

Dies steht in der alten FAQ und auch stellenweise in den Bedienungsanleitungen.
Mit nur einer CPU hat sich heute eh erledigt und die Architektur hat sich mittlerweile auch geändert.
Ich habe auch noch unter Windows 7 ab un an mal Tests gemacht mit Prio Hintergrundienst oder Programme.
Also, mal nen Projekt so oder so. Letztendlich konnte ich keinen Unterschied feststellen in Bezug auf spätere Knackser oder bessere Leistung. Will sagen, die RME hat immer klaglos ihren Dienst verrichtet und wenn Schicht im Schacht ist, dann muss halt die Buffersize höher.
Unter Windows 10 habe ich auch diverse Tests gemacht und mal alle Optimierungstipps durchgespielt. Auch HT an oder aus. Ich konnte keinen merklichen Unterschied feststellen. Ich habe mittlerweile nur noch SSD`s verbaut, ein gutes Mainboard, guten, schnellen Speicher. Der Flaschenhals ist bei mir, wenn man Latency Mon glaubt, die Nvidia Grafik. Aber selbst die ist llaut Latency Mon weit, weit unter 1 ms. M.M. nach geht es nicht besser,
Wir hatten ja auch schon das Thema mit der niedrigsten Buffersize. Für mich reichen beim Einspielen von Keyboards die 6 ms aus. Tiefer muss ich nicht, da ich Gitarre und Bass noch extern monitore.
Ich nutze bei der Aufnahmephase auch nur ausgewählte Plugins die so gut wie keine Leistung und Latenz verbrauchen.
Also mit Izotope und Co aufnehmen und komponieren kommt bei mir nicht in die Tüte. :)

Nochmal kurz zum Thema Hintergrunddienst. Steinberg erwähnt diesen "Trick" in ihrem Optimierungsartikel nicht mehr.
https://helpcenter.steinberg.de/hc/...d-Optimierung-einer-Digital-Audio-Workstation
 
Das überzeugt mich noch nicht so ganz, dass die Einstellung egal ist.

Ich könnte ja mal meinen Cubase 400 Spuren 800+ VST benchmark mit und ohne Optimierung auf Hintergrunddienste laufen lassen, mal sehen, ob mich das schlauer macht. Bei 96 kHz und ASIO buffersize von 32 samples.

Was ich mal gelesen habe ist, dass die Einstellung nicht nur Hintergrunddienste, sondern auch Treiberroutinen priortisiert, was bei Audio durchaus von Vorteil wäre.

Auf der anderen Seite gibts auch MMCSS für ASIO.... was aber bei Win10 limitiert ist.

Mal sehen, was meine Tests ergeben.
 
In einer älteren FAQ von Steinberg steht bei dem Tipp (nur Windows XP).
10. Damit ASIO Treiber mit geringer Latenz störungsfrei benutzt werden können, kann es in einigen Fällen sinnvoll sein, die "Prozessorzeitplanung" einzustellen (nur Windows XP)
https://www.steinberg.net/de/suppor...ails/kb_show/optimizing-windows-for-daws.html

Bei NI ist der Tipp auch mit einem Hinweis versehen.

Hinweis: einige Anwendungen funktionieren unter Umständen besser, wenn die Prozessorzeitplanung auf Programme eingestellt ist. Sollte sich die Audioverarbeitung Ihres Rechners nach dieser letzten Einstellung verschlechtert haben, wählen Sie bitte die ursprüngliche Einstellung Programme. Im Handbuch Ihrer Software finden Sie zumeist Hinweise, welche Einstellung für Ihre Anwendung optimal ist.
https://support.native-instruments....-Optimierungs-Tipps-für-die-Audioverarbeitung

 
Danke, es ist leider alles sehr vage und kratzt nur an der Oberfläche.
 
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.

upload_2019-10-13_9-46-56.png
Windows Optimierung für Hintergrunddienste .jpg
 

Anhänge

  • Windows Scheduler.pdf
    125,7 KB · Aufrufe: 464
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.
Ich möchte da auch nicht widersprechen und kann auch nur von meinen Erfahrungen seit Win 95 sprechen.
Ich bin in erster Linie Musiker und kein ITler. Trotzdem habe ich über die Jahre immer mit verschiedenen Einstellungen experimentiert.
Was ich aus all den Jahren sagen kann.
Jedes System ist anders.
Für mich ist wichtig, dass die Kiste durchgehend problemlos läuft, also ich nicht immer irgendwas ab- oder umschalten muss um Musik zu machen.
Ich habe nur Cubase, ein Videoprogramm und VLC installiert. Keine Email oder sonstige Sachen.
Mir ist bewusst, dass ich mit meiner 9632 nicht auf 32Samples arbeiten kann. Brauch ich auch nicht, weil mir 256 und 6ms reichen. Dafür habe ich beim Aufnehmen und Komponieren ein durchgehend stabiles System ohne Knackser oder sonstigen Phänomene.
Beim Mischen, wenn alles in Audio voliegt, gehe ich auf 512. Fertig.
Ich musste mir dadurch in all den Jahren nie Gedanken machen über irgendwelche Probleme. Weder unter Windows 7 oder Windows 10.
Wenn dann Probleme auftraten, war es in 99,9 Prozent der Fälle ein Plugin eines Drittherstellers in Cubase oder der eLicenser oder iLok, welcher aktualisiert werden wollte.
Einmal hatte ich ein Problem mit dem USB-Treiber.
Letztens hat meine alte Crucial-SSD nicht mehr mitgespielt. Immer wieder gab es Unterbrechungen, die nicht nachvollziehbar waren. Diverse Tests zeigten, dass die SSD "eigentlich" in Ordnung sei. Hab dann aber doch nochmal ne neue Samsung gekauft und seitdem ist alles wieder wie es sein soll.

Ich kann jetzt nur von Cubase sprechen, aber da sind über die Jahre auch Veränderungen vorgenommen worden.
Der Asio-Guard als offensichtliches Beispiel.
Oder halt Hyperthreading.
Auch bei Plugins wie Kontakt kann man optimieren. Multi-CPU Mode an oder aus, wenn in Cubase Multisupport aktiviert, bringt z.B. auch unterschiedliche Ergebnisse auf verschiedenen Systemen.
Da bringt es m.M nach auch, sich mehr mit auseinander zu setzen. Zumindest hatte ich da die meisten "spürbaren Erfolge".

Zu dem Punkt Porzessorzeitplanung und Cubase gehe ich jetzt einfach mal von aus, dass die Progrmmierer bei Steinberg, dass mittlerweile aufm Schirm haben und ihre Programme auf "normale" Einstellung (also Programme)
optimiert haben, da das nicht mehr explizit erwähnt wird. Interessieren würde mich eine Erklärung seiten Steinberg zwar auch, aber die sind ja generell immer etwas schweigsam. :)
 
"Low Latency ASIO Betrieb unter Windows 2000/XP mit Single CPU System
Um ASIO mit niedrigsten Latenzen unter Windows 2000/XP auch mit nur einer CPU nutzen zu können, muss die Systemleistung auf Hintergrundbetrieb optimiert werden. Dies geschieht über Systemsteuerung/System/Erweitert/Systemleistungsoptionen. Hier die Vorgabe 'Applikationen' ändern zu 'Hintergrunddienste'. Damit sinkt die niedrigste nutzbare Latenz von circa 23 ms auf circa 3 ms."

http://www2.rme-audio.de/support/faq.php

Dies steht in der alten FAQ und auch stellenweise in den Bedienungsanleitungen.
Mit nur einer CPU hat sich heute eh erledigt und die Architektur hat sich mittlerweile auch geändert.
Ich habe auch noch unter Windows 7 ab un an mal Tests gemacht mit Prio Hintergrundienst oder Programme.
Also, mal nen Projekt so oder so. Letztendlich konnte ich keinen Unterschied feststellen in Bezug auf spätere Knackser oder bessere Leistung. Will sagen, die RME hat immer klaglos ihren Dienst verrichtet und wenn Schicht im Schacht ist, dann muss halt die Buffersize höher.
Unter Windows 10 habe ich auch diverse Tests gemacht und mal alle Optimierungstipps durchgespielt. Auch HT an oder aus. Ich konnte keinen merklichen Unterschied feststellen. Ich habe mittlerweile nur noch SSD`s verbaut, ein gutes Mainboard, guten, schnellen Speicher. Der Flaschenhals ist bei mir, wenn man Latency Mon glaubt, die Nvidia Grafik. Aber selbst die ist llaut Latency Mon weit, weit unter 1 ms. M.M. nach geht es nicht besser,
Wir hatten ja auch schon das Thema mit der niedrigsten Buffersize. Für mich reichen beim Einspielen von Keyboards die 6 ms aus. Tiefer muss ich nicht, da ich Gitarre und Bass noch extern monitore.
Ich nutze bei der Aufnahmephase auch nur ausgewählte Plugins die so gut wie keine Leistung und Latenz verbrauchen.
Also mit Izotope und Co aufnehmen und komponieren kommt bei mir nicht in die Tüte. :)

Nochmal kurz zum Thema Hintergrunddienst. Steinberg erwähnt diesen "Trick" in ihrem Optimierungsartikel nicht mehr.
https://helpcenter.steinberg.de/hc/...d-Optimierung-einer-Digital-Audio-Workstation

@Realist: Ich habe herausgefunden, was diese Funktion bewirkt.

Du kannst es hier gerne nachlesen: https://www.tonstudio-forum.de/blog/index.php/Entry/92-Windows-Optimale-Leistung-anpassen-für-Hintergrunddienste-weiterhin-erforderlich/

Es ist nach wie vor empfehlenswert, diese Option für Windows Desktop Betriebssysteme zu setzen.

Darum wird es auch weiterhin von verschiedenen Herstellern empfohlen, weil es hier um Einstellungen grundlegender Natur im Bereich des Prozess Schedulers geht, damit CPU Resources optimal genutzt werden können und nicht so viel Leistung auf der Strecke bleibt wegen zu häufiger Kontextwechsel.

Das ist unabhängig von CPU Leistung und Architektur.

Es muss möglicherweise nur bei Windows Desktop Betriebssystemen eingestellt werden, weil ansonsten Unixoide Betriebssysteme und Windows Server von Hause aus mit festen und längeren Quantums arbeiten. Falls jemand Windows Server einsetzt und es diese Einstellung dort auch gibt, vielleicht doch besser setzen.
 
Zuletzt bearbeitet:
Heißt das auch, dass Windows Server besser für einen haufen Plugins in Cubase für ultra-Low-Latency (64Samples@192khz) geeignet ist?
 
Ich verstehe nicht, warum im Einstellungsdialog nur 2 Möglichkeiten gibt:
Priorität: "Hintergrund Dienste" oder "Programme".

Es aber in der Registry 3 mögliche Werte gibt:

https://www.thewindowsclub.com/processor-scheduling-in-windows-7-8
"
...
Just in case you wish to know, the PriorityControl key defines the foreground vs. background priority differential. The possible default values for Win32PrioritySeparation REG_DWORD 0, 1, or 2, with the default being 0x2.

This default value specifies the priority to give to the application running in the foreground. This application receives more process or time relative to other applications running in the background, explains TechNet.. The values here correlate to the following options in the Tasking dialog box: Value Meaning

  • 0 Foreground and background applications equally responsive
  • 1 Foreground application more responsive than background
  • 2 Best foreground application response time.
Coming back, if you have NOT changed this setting at all, and you were to open the Windows Registry, you would see Win32PrioritySeparation have a value 2. These screenshots are from my Windows 8 Pro.


...
"


Ist "0" = Priorität für "Hintergrund Dienste"?
 
Kann mich bitte Jemand Aufklären bezüglich des "Kontex-wechsels":

Passiert bei jeder weitergabe innerhalb Cubase, von einen Plugin zum nächsten ein "Kontexwechsel"? (glaube nicht, drum stürzt es so leicht ab, es seiden man nimmt eine PluginBridge dann hat man auch einen Kontextwechsel, oder?)

Wenn man mit 32Sampels @ 44,1khz ASIO-Puffer arbeitet, dauert ein Pufferdurchlauf ca. 0,7ms.

Sprich spätestens alle 0,7ms wird sowieso das ganze Cubase interrupted.
Ist in diesen Fall, abgesehenen von ALLEN um Cubase drumherum, ist das größere Quantum, für Cubase, irrelevant, da Cubase sowieso so nicht mal ein ganzes Quantum zur Verfügung steht? Aber:
Mir kommt gerade, Cubase tut doch viel mehr als nur den ASIO-Puffer zu Befüllen > durch größeres quantum weniger Overhead = mehr Leistung > mehr Resourcen zur ASIO-Puffer Abhandlung?

Lg
 
Zuletzt bearbeitet:
Man habt ihr Probleme, am wenigsten Latenz, hatte ich auf Cubase 1.0 Atari ST 1040, da hingen noch echte Synthies dran. Problematisch wurde es dann mit WIN95, da habe ich dann doch erst mal lieber den Atari weiterwendet. Spassig war es mit OS/2 (Win 3.1) Simulation, es hat total geleiert. Brauchbar wurde das ganze erst mit Win 98 2nd Edition. Asio4all, damit hat man sich dann behelfen können.

Aktuell verwende ich den gleichen Rechner wie vor 10 Jahren, gut etwas mehr Speicher und größere SATA HD's, damals Cubase 5 Pro/Win7 heute aktuelle Cubase 10.0.40 Pro und Win 1903 und alles läuft, ich würde sogar sagen, besser als vor 10 Jahren. Was ich halt geändert habe ist das Interface, damals Lexicon Omega heute , behringer umc404hd, alles Standard Einstellungen und es läuft. Was halt den Unterschied macht, ist wenn man alles mögliche auf dem System hat (games/apps/sonstiger müll) oder ein reines Musik System. Daher habe ich 2 Boot Partionen, auf einer physikalischen Maschine. Normal mit allem, und Musik. Auf Musik ist nur Cubase und benötigte Plugins, wie Tools für die Nachbearbeitung. Das Musik System ist auch Offline (ohne Internet), somit habe ich nie Stress, wenn ich was machen will läuft es.
 
Hab jetzt auch fast keine Latenz, spiele am Master-USB-Keyboard am PC welcher z.B. meinen DeepMind12 via USB ansteuert, der DeepMind rein in den Wandler und via Soundkarten-Mischer raus auf die Abhöre.

Aber es ist halt schon fetzengeil, wenn man ihn zusammen mit Sylenth1, MassiveX und co. benutzen kann, am DeepMind12 noch VST-Schnuckis drauf tun, ..., und dann Alles samplegnau sitzt, da man durch eine Audio-Spur durchgespielt hat, schon beim aufnehmen.
Was bei 32Samples @ 44,1khz (ca 0,7ms IN + 0,7ms Out = ca. 1,5ms + Wandler und so = round trip latency) gar nicht groß auffällt, außer das die Signale mit Plugins processt werden. (Fabfilter e.t.c. bei der Vocal aufnahme sind schon geil z.B.)
 
Zuletzt bearbeitet:
Loop_Breaker:
Ich kann das Verhalten bestätigen, das sich auf deinem PC zeigt. Ich habe gestern nacht einen Versuch gemacht von 1809 auf 1903 zu wechseln, und landete in einer sehr ähnlichen Performance-Hölle wie du. Wir verwenden wohl beide Intel Series 9 Chipsätze mit RME-Audiodevices. Das Blöde ist, dass es die Mehrzahl der User nie bemerken wird was da abgeht, entweder weil sie keinen Series 9 Chipsatz mehr verwenden, oder weil ihre Audio-Interfaces sowieso nur ab 128 Samples Puffergröße vernünftig performen, und der Unterschied dort vernachlässigbar ist.

In diesem Thread in einem Drittforum hat der User EvilDragon ähnliche Probleme:
https://www.gearslutz.com/board/showthread.php?t=1266677

Obwohl der Thread vermeintlich als gelöst markiert ist (weil die Mehrzahl der Anwender nach einem MS Patch keine Probleme mehr mit 1903 hat), bestätigt der Microsoftie Psychlist1972, dass EvilDragons Problem nicht gelöst ist. Allerdings benutzt der einen Z170-Chipsat, also eine Generation nach uns (je nach Zählweise auch zwei).

Für mich persönlich geht das in die Richtung, dass es was mit den Gegenmaßnahmen zu Spectre/Meltdown zu tun, die in 1809 noch optional waren (solange du KB4465065 nicht installiert hast), in 1903 aber erzwungen werden, d. h. die CPU kriegt einen neuen Microcode beim Boot des Rechners, der inzwischen dreimal revisioniert wurde und auf älteren CPUs bitteren Schaden anrichtet, außerdem versucht sich Windows jetzt an Retpoline und weiteren Speicherverwirbelungen, und nicht alles davon kann man in den Sicherheitseinstellungen des Rechners abschalten; außerdem erforderten diese Maßnahmen massive Änderungen am Windows-Kernel. Aber dieser Absatz ist eine begründete Annahme, kein erwiesener Fakt.

Da 1809 für Firmen 30 Monate lang supportet wird, ist das vorerst meine Option. Ich hoffe allerdings, dass die Patches auch auf einem Win Pro installierbar sein werden, und nicht nur auf Enterprise. Ansonsten gehen in 6 Monaten die Lichter aus für 1809.
 
Guten Tag, ein vielleicht hilfreicher Beitrag zu den Meltdown und Spectre Patches.

Zu den Grundprinzipien zur Abwehr dieser Sicherheitslücken zählt das der aktuelle CPU Microcode mit den Betriebssystem Patches zusammen arbeiten muss. Das BIOS besitzt eine Microcode -Versionskontrolle, das bedeutet ein älterer Microcode kann nicht über einen neueren Microcode installiert werden.

Aus Sicht von Windows (bei Mac kenne ich mich leider zu wenig aus) wurden inzwischen mehrere Versionen von Patches ausgerollt und es kommen ständig neue Funktionen hinzu welche die Performance des Systems beeinträchtigen können. Dabei gibt es wiederum zwei verschiedene Behinderungen des Systems:
a) Eine generelle Verlangsamung des Systems ( die Wirkung auf Programme und Dienste ist analog der Wirkung eines generell reduzierten Systemtaktes)
b) Mikrolatenzen im Bereich von Millisekunden, ( man könnte vielleicht sagen das System stottert und sämtliche Programme und Dienste werden immer wieder für Millisekunden unterbrochen ).

Für Audio und Multimedia sind vor allem b) die Mikrolatenzen spürbar in Form von kleinen Aussetzern des Sound und oder asynchronem Timing beim Aufnehmen oder Abspielen von Samples u.a. ähnlichen Effekten.

Wie bereits erwähnt muss das Betriebssystem den Microcode der CPU unterstützen. Im Verlauf der Monate und Jahre seit Entdeckung der Sicherheitslücken hat Microsoft nicht nur Programmcode hinzugefügt welche die Sicherheit betreffen, es wurde auch versucht Optimierungen dieses Code vorzunehmen, was zum Teil sogar zu separat erhältlichen Patches geführt hat.

Hier zum Beispiel die Resultate der System-Status-abfrage eines meiner Computer (neues Modell 2019) in der Powershell:

Speculation control settings for CVE-2017-5715 [branch target injection]

Hardware support for branch target injection mitigation is present: True
Windows OS support for branch target injection mitigation is present: True
Windows OS support for branch target injection mitigation is enabled: True

Speculation control settings for CVE-2017-5754 [rogue data cache load]

Hardware requires kernel VA shadowing: True
Windows OS support for kernel VA shadow is present: True
Windows OS support for kernel VA shadow is enabled: True
Windows OS support for PCID performance optimization is enabled: True [not required for security]

BTIHardwarePresent : True
BTIWindowsSupportPresent : True
BTIWindowsSupportEnabled : True
BTIDisabledBySystemPolicy : False
BTIDisabledByNoHardwareSupport : False
KVAShadowRequired : True
KVAShadowWindowsSupportPresent : True
KVAShadowWindowsSupportEnabled : True
KVAShadowPcidEnabled : True


Mir ist bei Durchsicht dieser Ergebnisse verschiedenes aufgefallen das für die Performance einer Audio Workstation wichtig sein könnte.
Erstens wäre dies der OS -Support für die PCID Performance die entweder auf True oder auf False sein kann (ohne die Sicherheit des PC zu gefährden).
Zweitens der Wert BTIDisabledBySystemPolicy : False und
Drittens der Wert KVAShadowWindowsSupportEnabled : True

Zur PCID Performance Verbesserung (vor allem bei der Meltdown Abwehr durch Windows) ist zu sagen dass diese Massnahme erst bei neueren CPU möglich ist. PCID (Process-Context Identifiers) ist eine Funktion, die nur in einigen CPUs vorhanden ist (meist neuer und High End CPU, allgemein seit Haswell (4. Generation) aufwärts/neuer), die dazu beiträgt, einige der durch den Eingriff der Patches verursachten Leistungseinbussen abzumildern.

Wenn bei Euch die Performance Optimierung = False angegeben ist, dann bedeutet dies dass euer System stark unter den Massnahmen gegen Meltdown leiden kann. In diesem Fall ist fraglich ob ein solcher PC bei aktiviertem Meltdown Patch noch genügend gut als Audio Workstation dienen kann. Bei euren High End Vorrichtungen und möglichst Sample genauen Audio Aufnahmen würde ich empfehlen entweder eine neue CPU zu besorgen oder dann den OS Meltdown Support abzuschalten während der Arbeit mit der DAW.

Hier kommen die Werte BTIDisabledBySystemPolicy und BTIDisabledBySystemPolicy zum Zuge.
Microsoft hat einen Weg eingerichtet um sowohl die Meltdown als auch die Spectre Patches per Policy zu kontrollieren, was wiederum über den Weg eines Registry Patches geht.

Ihr könnt diese Befehle entweder direkt (als Administrator) in der Shell ausführen oder ihr könnt damit eine ausführbare Textdatei mit der Endung .cmd erstellen (die man auch mit Maus Doppelklick ausführen kann).

reg add “HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management” /v FeatureSettingsOverride /t REG_DWORD /d 3 /f

reg add “HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management” /v FeatureSettingsOverrideMask /t REG_DWORD /d 3 /f

Achtung, erst ein anschliessender Neustart des Systems führt zur Aktivierung dieser Befehle. Der obere Befehl deaktiviert Meltdown und der Untere die Spectre Abwehr.

Um dem Betriebssystem wieder mehr Sicherheit zu ermöglichen kann man wiederum in der Shell befehlen oder in einer ausführbaren Datei:

reg add “HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management” /v FeatureSettingsOverride /t REG_DWORD /d 0 /f

reg add “HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management” /v FeatureSettingsOverrideMask /t REG_DWORD /d 3 /f

Auch hier ist ein anschliessender Neustart des Systems notwendig. Man kann die Patches zum Beispiel aktivieren um danach Arbeiten über das Internet zu verrichten wie zum Beispiel die Aktivierung von Plugin und dergleichen mehr.

Ein PC der in einem Studio steht über welchen praktisch nie auf das Internet zugegriffen wird und der nur am internen Netzwerk hängt ist kaum von Spectre und Meltdown bedroht, auch deshalb nicht weil ein Angreifer kaum etwas vom Abgriff von irgendwelchen Sound Dateien hätte.

Anhang: Der Programmcode zur Abfrage des Systemstatus findet man z.B. hier:
https://www.powershellgallery.com/packages/SpeculationControl/1.0.2/Content/SpeculationControl.psm1

Den Code in die Powershell kopieren (als Administrator starten) , mit Return abschliessen und anschliessend das Programm mit dem Befehl
Get-SpeculationControlSettings
ausführen.

Oder man kann den Befehl auch wie folgt permanent mit folgendem Befehl in der Eingabe installieren:
Install-Module -Name SpeculationControl

und danach den Status des PC wie zuvor mit Get-SpeculationControlSettings abfragen
 
Zuletzt bearbeitet:
Guten Tag, ein vielleicht hilfreicher Beitrag zu den Meltdown und Spectre Patches.

Wer will sich mit so einem Mist beschäftigen?

Einfache Frage: welcher moderne Prozessor leidet nicht mehr unter den Updates, weil er einfach keine Probleme mit Spectre etc hat? Denn wer sich jetzt einen NEUEN performanten Rechner zulegen will, will damit nichts mehr zu tun haben. :)
 

Ähnliche Themen

jodelfredi
Antworten
11
Aufrufe
647
Hella
Hella
crytsalball
Antworten
10
Aufrufe
533
crytsalball
crytsalball
moonbooter
    • Danke
  • Artikel
Antworten
3
Aufrufe
2K
moonbooter
moonbooter

Oft gelesene Themen

Zurück
Oben