Performanten Silent Rechner für Audiobearbeitung / Gaming / Office

B

bitheat

Gast
Servus,
erbitte Kaufberatung für einen sehr performanten Silent Rechner bezüglich der Haupt Komponenten (CPU, Mainboard, RAM, ...).

Suche eine silent CPU/Mainboard Kombination für Audiobearbeitung / Gaming / Office mit
  • möglichst geringen DPC Latenzen (also gute Mainboard/BIOS Kombination, gute Treiber, die die CPU nicht zu lange belegen)
  • hoher Single Thread Performance (mindestens 3.5 GHz Basis Takt) wegen Cubase VST/VSTi
  • hoher Gesamtleistung
  • ECC RAM (am liebsten wegen höherer Datenintegrität)
  • performante NVMe SSD (1 TB)
Mainboard möglichst ohne Chipset Lüfter.
Dazu passender CPU Kühler (Tower) mit hoher Kühlleistung, aber geringer Geräuschentwicklung.
Nice to have: Thunderbolt, wegen RME UFX+ Recording Interface (unterstützt Thunderbolt und USB3.0).

Vor 5-6 Jahren war es diese Kombination für mich:
  • Intel Xeon E5-1650v4 (Broadwell EP)
  • Supermicro X10SRi-F
  • Noctua NH-U14S (mit Kit für Narrow ILM)
  • Noiseblocker NB-eLoop B12-P (läuft auch bei 5V an wegen 5/9/12V Umschalter des Fractal Design Define XL R2; passt auch auf den etwas größeren Noctua Kühler gut drauf; einer der wenigen Lüfter, die mit der Lüftersteuerung des Supermicro IPMI's klarkommen)
Derzeitiger Build siehe hier: https://www.tonstudio-forum.de/blog...permicro-X10SRi-F-Xeon-E5-1650v3-Komponenten/

Vorhandene Komponenten, die möglichst alle noch verbaut werden sollen:
  • OS: Windows 10 Pro
  • Gehäuse: Fractal Design Define XL R2
  • Silent Gehäuselüfter: 4x be quiet! Silent Wings 3
  • PSU: Seasonic Prime Ultra Titanium 850W ATX 2.4
  • GPU: MSI GeForce RTX 2070 SUPER Gaming X Trio
  • USB3: Sonnet Allegro Pro USB3.0 PCIe, 4x Fresco Logic 1100 Chipset (kompatibel zu RME UFX+ Recording Interface)
  • SSDs: Samsung 860 EVO 1TB, Samsung 850 EVO 1TB, Samsung 850 Pro 512GB
  • HDDs für Backup, intern: Western Digital WD Red Plus 10TB extern: Seagate Desktop HDD 10TB, Seagate Desktop HDD 4TB
Rein von der hohen Leistung und Single Thread Performance her müsste man jetzt eigentlich ein Ryzen3 basiertes System holen.
Ich denke da an einen Ryzen 9 5950X. Viel teurer sollte die CPU auch nicht werden.
https://www.cpubenchmark.net/cpu.php?cpu=AMD+Ryzen+9+5950X&id=3862

Mehr als 16 Kerne würde ich auch ungern verwenden, weil Cubase 11 Pro und Games nicht gerade dafür bekannt sind, die Last auf so viele Kerne gut verteilen zu können. Ich denke bei 12-16 sollte langsam Schluss sein und man sollte mehr ein Augenmerk auf einen höheren Basis Takt und höhere Single Thread Performance legen, falls es CPU hungrige VST/VSTi's gibt.

Vielen Dank für Eure Zeit und Unterstützung im Voraus.
 
bitheat schrieb:
weil Cubase 11 Pro und Games nicht gerade dafür bekannt sind, die Last auf so viele Kerne gut verteilen zu können
Deshalb würde ich da eher 8, maximal 12 in Erwägung ziehen.
bitheat schrieb:
möglichst geringen DPC Latenzen
AMD-GPU.
bitheat schrieb:
ECC RAM (am liebsten wegen höherer Datenintegrität)
Problematisch. Hier auf CB gibt es auch recht wenige, die ECC auf AM4 am laufen haben. "Normale" AM4 Boards unterstützten das nicht offiziell.
Ich würde mich an deiner Stelle eher auf Systeme mit DDR5 gedulden, die haben alle ECC.
 
  • Gefällt mir
Reaktionen: bitheat
Wie wäre es bspw. mit einem 2690v4?
https://www.ebay.de/sch/i.html?_from=R40&_nkw=xeon+2690+v4&_sacat=0&_sop=2
Es klingt so, als wäre deine Plattform ein guter Kompromiss für deine Ansprüche. Also könnte man sie weiter verwenden und die CPU verbessern.

Oder womöglich könnte die Aufrüstung noch bis zum Launch von "Alder Lake" warten, falls das für dich eine Option ist.

Den ganz großen Hammer mit einer rund 1000€ CPU zu schwingen, ist natürlich immer möglich.
Zen 3 ist ohne Frage eine empfehlenswerte Anschaffung.
 
  • Gefällt mir
Reaktionen: bitheat
Zwirbelkatz schrieb:
Wie wäre es bspw. mit einem 2690v4?
https://www.ebay.de/sch/i.html?_from=R40&_nkw=xeon+2690+v4&_sacat=0&_sop=2
Es klingt so, als wäre deine Plattform ein guter Kompromiss für deine Ansprüche. Also könnte man sie weiter verwenden und die CPU verbessern.

Oder womöglich könnte die Aufrüstung noch bis zum Launch von "Alder Lake" warten, falls das für dich eine Option ist.

Den ganz großen Hammer mit einer rund 1000€ CPU zu schwingen, ist natürlich immer möglich.
Zen 3 ist ohne Frage eine empfehlenswerte Anschaffung.

Hatte ich auch schon mal überlegt, aber eine höhere Anzahl Kerne bringt mich im Bereich Single Thread Performance nicht weiter.

https://www.cpubenchmark.net/cpu.php?cpu=Intel+Xeon+E5-2690+v4+@+2.60GHz&id=2780
Wegen des niedrigeren Basis Takts von nur 2.6 GHz liefert diese CPU nur 2047 im Passmark Score für Single Thread Performance.
Da bin ich vermutlich mit meiner CPU besser aufgehoben. 3.6 GHz Basis Takt lt. Datenblatt und in meinem System permanent auf 3.8 GHz auf allen Kernen, wenn ich im Supermicro BIOS Turbo (und EIST) aktiviere.

Bei AVX2 Befehlssatzerweiterungen (bei Cubase in Verwendung) sinkt dann der Takt von 3.8 GHz auf die gleichen 3.5 GHz wie bei meiner vorigen Haswell CPU (E5-1650v3).

Ich fürchte, dass dann der Takt von der 2690 auch noch ein Stückchen runtergehen wird.
 
bitheat schrieb:
Wegen des niedrigeren Basis Takts von nur 2.6 GHz liefert diese CPU nur 2047 im Passmark Score für Single Thread Performance.
Das ist sicherlich richtig. Bezogen darauf hier eine umfangreiche Liste - inklusive Takt jedes Kerns.
https://en.wikipedia.org/wiki/List_of_Intel_Broadwell-based_Xeon_microprocessors

bitheat schrieb:
Bei AVX2 Befehlssatzerweiterungen (bei Cubase in Verwendung) sinkt dann der Takt von 3.8 GHz auf die gleichen 3.5 GHz wie bei meiner vorigen Haswell CPU (E5-1650v3).
Da bin ich etwas überrascht, dass du scheinbar von einem v3 auf einen v4 aufgerüstet hast.

Was AVX anbelangt, bin ich nicht sattelfest. Ich hatte das bislang als Domäne von Intel interpretiert. Somit würde Zen3 zwar 16 schnelle Kerne bieten, jedoch bin ich mir in der Leistung bezogen auf AVX nicht sicher.

Durch die gute Selektierung des 5950x hat er viele Kerne und einen hohen Takt.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: bitheat
ghecko schrieb:
Deshalb würde ich da eher 8, maximal 12 in Erwägung ziehen.

16 Kerne sind schon ok , bloss relativ teuer im Moment...

ghecko schrieb:
Problematisch. Hier auf CB gibt es auch recht wenige, die ECC auf AM4 am laufen haben

Es funktioniert eigentlich problemlos, wenn das Board es unterstützt.

Hab es selbst auf zwei Asus-Board und einem Gigabyte-Board getestet
(mit 1700X; 3600; 5950).


PS: Da es ECC-RAM ja nur in niedrigeren Taktkraten gibt, könnte Dir der große Cache bei Zen 3 helfen...
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: bitheat
Zwirbelkatz schrieb:
Das ist sicherlich richtig. Bezogen darauf hier eine umfangreiche Liste - inklusive Takt jedes Kerns.
https://en.wikipedia.org/wiki/List_of_Intel_Broadwell-based_Xeon_microprocessors

Ich hatte mir damals auch alle Möglichen solcher Übersichten angesehen.
Für meine Begriffe war der E5-1650er der Sweetspot, ,mit hohem Takt, mit dem auch Gamen möglich war.

Dann wurden die Haswell CPUen durch Spectre/Meltdown unter Windows 7 fürchterlich ausgebremst.
Unter Windows 10 ists etwas besser geworden nachdem in Win10 das Fontrendering als User Prozess aus dem Kernel ausgelagert wurde (wenn ich mich recht erinnere).
Es hieß, dass die neueren Broadwell Modelle entweder von Spectre/Meltdown selbst oder von den firmware updates her nicht so sehr in der Performance betroffen seien. Möglicherweise daher auch noch leicht höhere Preise für die v4 CPU.

Die E5-1650v3 konnte ich noch problemlos zusammen mit der nVidia GTX980 verwenden. Als ich dann aber die RTX 2070 super holte, hatte ich bei X4 Foundation (2.x, 3.x) den Eindruck, dass ich die GPU nicht so gut ausgelastet bekam. Weswegen ich mit Process Lasso Pro nachhalf und X4 auf 5 von den 6 CPU cores fest pinnte.

Zwirbelkatz schrieb:
Da bin ich etwas überrascht, dass du scheinbar von einem v3 auf einen v4 aufgerüstet hast.

Ich hatte einfach nur die Gelegenheit, günstig eine E5-1650v4 in den eBay Kleinanzeigen schiessen zu können. Die ermöglicht 200 MHz schnelleren Speichertakt für ECC RAM.

Alles in allem nicht so DER wahnsinnige Unterschied, aber ich hatte vor einem Jahr beschlossen, das System hier noch was länger zu betreiben, bis es wirklich mal wieder eine interessante HW gibt.

Und da ich schon mal mit den GPU leicht gegen den Performance Pöller gelaufen war, ging dann doch der Basteltrieb mit mir durch und ich wollte dann einfach schauen, was die v4 bringt.

Es ist nicht viel im Bereich Performance .. ok ... obwohl ich sagen muss, mit aktiviertem Turbo rennt das Bienchen permanent mit 3.8 GHz !! Ohne overclocking auf einem Server Mainboard.

Und der Wahnsinn ist, haltet Euch fest, rund 10° C geringere Temperaturen bei Broadwell im Vergleich zu Haswell.

Im Moment bei Energieprofil Höchstleistung und einfach nur beim Tippern im Browser: 34°C. Wenn ich dann noch auf ausgeglichen oder niedriger einstelle, dann kommste grad mal auf die 30°C. Und selbst unter Prime95 bleiben die Temperaturen noch recht lange unter 60°C und kommen dann leicht drüber.

Im Moment ist es ja leider so, dass AMD und Intel sich "koste was es wolle" ausstechen möchten.
Bei dem Fight geht es um alles und um Energieeffizienz schert sich da leider niemand mehr.
Nun .. und ne 80-90°C heiße CPU möchte ich eigentlich nur ungern im System haben seufz.

Zwirbelkatz schrieb:
Was AVX anbelangt, bin ich nicht sattelfest. Ich hatte das bislang als Domäne von Intel interpretiert. Somit würde Zen3 zwar 16 schnelle Kerne bieten, jedoch bin ich mir in der Leistung bezogen auf AVX nicht sicher.

Durch die gute Selektierung des 5950x hat er viele Kerne und einen hohen Takt.

Habs auch nur per Zufall bemerkt, weil die v4 CPU mit Cubase auch nur 3.5 GHz lieferte.

Jedenfalls wollte ich mal schauen, ob der Zeitpunk schon gekommen ist, um ggf zu upgraden, aber ich denke ich warte noch ein Weilchen auf DDR5 und dann möchte ich auch gerne Thunderbolt mit dabei haben, falls es mal mit Audio und USB3 irgendwelche Probleme geben sollte (-> UFX+, 188-channel Interface mit MADI).

Und wo ich selbst noch kucken muss, inwieweit Cubase AVX2 oder AVX512 Kommandos unterstützt. ich glaube AMD unterstützt nur AVX2, aber nicht AVX512 oder so ähnlich. Und ich weiß nicht genau, ob das hohe Relevanz für Audio Verarbeitung in Cubase hat.

Ich denke ich warte einfach mal auf DDR5 und was da sonst noch so kommt.

Jetzt hat auch schon jemand irgendwelche Spectre Problemchen bei Ryzen 3 gefunden, vielleicht hat AMD hier auch zu viel optimiert, bin mal gespannt, was sich noch so alles offenbart.

Damals haben die Firmware updates jedenfalls unter Windows 7 eine Menge Performance gekostet: https://www.tonstudio-forum.de/blog...-CPU-Microcode-Upgrade-against-Spectre-EN-DE/

Und Windows 10 hatte unter anderem lange genug selber noch Performance Probleme im Memory Management System, weshalb ich den Umstieg auf 10 noch lange hinauszögerte und da nervte die deutliche schlechtere Performance mit Spectre / Meltdown upgrades: https://www.tonstudio-forum.de/blog/index.php/Entry/84-Windows-10-better-than-Windows-7-EN-DE/

Ich hoffe das bleibt mir beim nächsten HW Kauf einigermaßen erspart, aber wer kann das schon wissen ;)
 
bitheat schrieb:
Für meine Begriffe war der E5-1650er der Sweetspot, ,mit hohem Takt, mit dem auch Gamen möglich war.
Jo, als "V1" & "V2" gabs die schon extrem preiswert, bevor die Ryzen den Markt aufgerollt haben.
Wenn man denn ein x79-Mainboard hatte.

bitheat schrieb:
Nun .. und ne 80-90°C heiße CPU möchte ich eigentlich nur ungern im System haben seufz.
Da klingt in den Tests schlimmer, als es letztlich ist. Man hat einige Möglichkeiten, den "Verbrauch gesamt" zu reduzieren. Die Prozessoren laufen offenbar mit deutlich höherer Spannung, als das unbedingt notwendig wäre.
Auf dem 5800x teste ich derzeit mit 1,15 Volt für 4,4GHz. Anstatt 1,4x Volt für geringfügig höheren Takt. Obs jederzeit stabil ist, wird sich noch zeigen.

bitheat schrieb:
Ich denke ich warte einfach mal auf DDR5 und was da sonst noch so kommt.
Hinsichtlich DDR5 und ECC:
https://www.pcgameshardware.de/CPU-...-DDR5-und-PCIE-50-Hoffnung-fuer-HEDT-1369937/
Kann man sich zumindest einmal ansehen, was da gezeigt wird.
 
  • Gefällt mir
Reaktionen: bitheat
bitheat schrieb:
Bei dem Fight geht es um alles und um Energieeffizienz schert sich da leider niemand mehr.
Nun .. und ne 80-90°C heiße CPU möchte ich eigentlich nur ungern im System haben seufz.
gerade der 5950X ist schon ab werk ziemlich effizient. kann man aber durch verwenden des "Eco modus" noch steigern, wobei der dadurch deutlich mehr leistung verliert als die anderen Zen3-CPUs. CB hatte das im test zu Zen3 gebencht.

die ausgelesenen temps bei AMD und Intel sind nicht direkt miteinander vergleichbar. wirklich "schlimm" ist hier bei Zen3 nur der 5800X, liegt daran dass hier viel strom durch ein einzelnes 7nm-chiplet geprügelt wird.
 
  • Gefällt mir
Reaktionen: bitheat
Danke, aber Energiesparmodi sind für mich nicht so sehr interessant.

Beim Recording ist Energiesparen nicht angesagt. Da muss ich immer mit dem Energieprofil Höchstleistung arbeiten und am besten auch CPU core parking deaktivieren, damit die DPC Latenzen möglichst niedrig sind. Nur so kann ich auch unter Last mit kleineren ASIO Buffersizes im Bereich 32, 64, 128 samples @44.1 kHz arbeiten, damit die RTL (Round Trip Latency) über USB (also vom recording interface zur DAW und zurück) unter 10ms bleibt. Gerade beim Arbeiten mit virtuellen Instrumenten (VSTi) ist das erforderlich.
 
@bitheat:
mit dem ganzen audiokram und latenzen etc kenne ich mich überhaupt nicht aus. der "Eco-Modus" senkt einfach nur das PPT, die CPU darf unter last also weniger strom schlucken. wirkt sich auch sowas da schon negativ aus?
 
Da müsste ich mich auch erstmal einlesen und mein "fundiertes Halbwissen" auf Vordermann bringen, was dieser Eco Modus überhaupt macht ;) Danke auf jeden Fall es zu erwähnen, aber ich denke das wird noch ein Weilchen dauern, ehe ich dazu was passendes finde ... Eben hatte ich auf die schnelle nicht gefunden.

DPC Latenzen kann man beispielsweise mit LatencyMon messen und dabei Treiber ausfindig machen, die CPU Cores zu lange in Beschlag nehmen. Du weißt vielleicht, dass low level routinen nicht durch den normalen Prozess Scheduler von der Ausführung auf einem Core unterbrochen werden können. Im Treiber ist programmiert, wann der einen CPU Core wieder freizugeben hat. Da gibts gute und schlechte Treiber.
Sollte in der Zwischenzeit ein Audio Prozess für einen solchen Core scheduled sein und der Core nicht schnell genug freigegeben werden, dann kann er zu Audio Verlust / Knacksern kommen.

Diese DPC Latenzen steigen, wenn man beispielsweise Energiesparfunktionen wie z.B. C-States oder C1E aktiviert hat, weil es dann noch zu zusätzlichen Verzögerungen kommt, falls ein Core erstmal aus einem Schlafzustand wiedererweckt werden muss. Je tiefer der Schlafzustand ist, desto länger dauert es, bis der Kern zur Verfügung steht.

Es handelt sich dabei um Werte im Mikrosekunden-Bereich, die sich aber letzten Endes alle akkumulieren.

Bei einem agilen System belegen die Treiber die CPU Kerne nicht für zu lange Zeit und dann sind am besten auch alle CPU Kerne mit dem maximalen Takt verfügbar. Takt Änderungen von CPUen bewirken auch eine leichte Latenz, weil die CPU erst dann zur Verfügung steht, wenn sie einen anderen stabilen Takt erreicht hat.

Also beim Recording wird es am Problematischsten, wenn Du nicht einfach nur aufnimmst (was man ruhig mit der maximalen ASIO Buffersize machen kann), es wird dann kritisch, wenn Du einmal komplett über USB hin und hermusst.

Und je agiler das system, je weniger Latenzen sich im System addieren, desto besser kannst Du solch eine "near-realtime" Audio load abfrühstücken.

Vom Gaming sind Dir sicherlich auch Mikroruckler und solche Phänomene bekannt. Sehr gerne auch durch Verwendung von mehreren Grafikkarten. Auch hier helfen Tuning Massnahmen, Energiesparen komplett zu deaktivieren, ebenso CPU core parking.

Und was auch helfen kann ist, wenn man den Windows Prozess Scheduler auf "optimale Leistung anpassen für Hintergrunddienste" umstellt. Die Bezeichnung ist ein wenig beknackt. Was da passiert ist, dass jedem Prozess (wie bei Windows Server und Unix Systemen) ein längeres und fixes Zeitquantum zugewiesen wird, so dass ein CPU Core einen Prozess etwas länger an einem Stück - und damit etwas effizienter - abarbeiten kann. Dann gibt es auch weniger Context Switches für die CPU, was einen gewissen Multitasking/Processing Overhead reduziert. Informationen dazu gibt es hier: https://www.tonstudio-forum.de/blog...st-performance-of-background-services-or-not/
 
Ein Bekannter von mir erzählt mir seit Jahren und bei jeder sich bietenden Gelegenheit, dass der einzig wahre Speicher für Musikproduktion DDR1 oder DDR2 war - wegen der Latenzen.

Auf alle Falle hat der 5800x nur 1 sog. CCX. Dort sind alle 8 Kerne drin verbaut. Ein 5900x oder 5950x besteht quasi aus 2x 3600/3700ern. Das sind 2 CCX, die über den Ram kommunizieren müssen. Beziehungsweise über die Infinity Fabric.

Lange Rede: Ob eine monolithische CPU einen Einfluss auf deine Ergebnisse hat, wäre zu prüfen.

15:15 für beide, im fachchinesisch Tennis, würde ich sagen ;)
 
bitheat schrieb:
DPC Latenzen kann man beispielsweise mit LatencyMon messen
Wenn das dein Kriterium ist, dann solltest du mal kucken wie geeignet die Ryzenarchitektur ist für den Einsatzzweck.

Mein Ryzen 5 3500u hatte extreme Latenzzpitzen von bis zu 600ms. Keine Ahnung was mit Latency Mon wirklich gemessen wird und wie relevant die Ergebnisse heutzutage noch sind aber die Testergebnisse waren bei quasi allen Ryzens grauenhaft.

Wie sehr sich die gelösten/nicht gelösten USB Controller Probleme bei den Ryzen 5000 auf das recording auswirken kann ich dir nicht sagen.

Was ich dir aber sagen kann ist, dass beide Zen (+) Geräte die ich im Einsatz habe im USB C zu DP Mode mehrmals pro Tag kurze Aussetzer haben.
 
Zuletzt bearbeitet:
Sorry hat was gedauert, tat mich etwas schwer, die Antwort verständlich zu formulieren und ausserdem hatte ich im Laufe der Monate die Hälfte wieder vergessen. Besonders wie man jetzt messen sollte und welche Werte zu erwarten / schön wären.

Es wäre generell empfehlenswert, dieses Dokument zum Einstieg zu überfliegen, die ist echt klasse geschrieben und bietet einem einen super Einstieg in die Thematik:
https://www.osr.com/nt-insider/2014-issue3/windows-real-time/
Wer nicht so sattelfest in Englisch ist, kann das durch den deepl Übersetzer schicken, am besten ein paar Absätze, zu viel Input mögen die nicht mehr: https://www.deepl.com/

Leider haben sich die Meßmethoden ab Windows 8 seit der Einführung von "dynamic clock ticks" ("dynamischer Takt") geändert (siehe Dokument oben).

Unter Windows 7 gefiel mir die Meßmethode "kernel timer latency" am besten, hier war die Genauigkeit um Faktor 100 höher und zeigte bei meinem System minimale Latenzenwerte bis runter zu 1.75 us ("us" = Microsekunde, sorry die Mikro Taste funktioniert bei mir nicht) an.

Jetzt unter Windows 10 hat man nur noch diese beiden Meßmethoden zur Auswahl:
  • Interrupts to DPC latency:
  • Interrupt to user process latency: liefert bei mir Werte im Bereich:
Interrupt to DPC Latency liefert bei mir in den 2 Minuten Werte im Bereich 130-190us.
Absolutes Minimum: 28us
Höchster Wert: 271us

_________________________________________________________________________________________________________
CONCLUSION
_________________________________________________________________________________________________________
Your system appears to be suitable for handling real-time audio and other tasks without dropouts.
LatencyMon has been analyzing your system for 0:01:59 (h:mm:ss) on all processors.


_________________________________________________________________________________________________________
SYSTEM INFORMATION
_________________________________________________________________________________________________________
Computer name: SUPERMICRO
OS version: Windows 10, 10.0, version 2009, build: 19042 (x64)
Hardware: Super Server, Supermicro
CPU: GenuineIntel Intel(R) Xeon(R) CPU E5-1650 v4 @ 3.60GHz
Logical processors: 12
Processor groups: 1
RAM: 32641 MB total


_________________________________________________________________________________________________________
CPU SPEED
_________________________________________________________________________________________________________
Reported CPU speed: 360 MHz

Note: reported execution times may be calculated based on a fixed reported CPU speed. Disable variable speed settings like Intel Speed Step and AMD Cool N Quiet in the BIOS setup for more accurate results.


_________________________________________________________________________________________________________
MEASURED INTERRUPT TO DPC LATENCIES
_________________________________________________________________________________________________________
The interrupt to DPC latency reflects the measured interval in which a DPC could execute in response to a hardware request from the moment the interrupt service routine started execution.

Highest measured interrupt to DPC latency (µs): 282,90
Average measured interrupt to DPC latency (µs): 2,700038


_________________________________________________________________________________________________________
REPORTED ISRs
_________________________________________________________________________________________________________
Interrupt service routines are routines installed by the OS and device drivers that execute in response to a hardware interrupt signal.

Highest ISR routine execution time (µs): 241,11750
Driver with highest ISR routine execution time: dxgkrnl.sys - DirectX Graphics Kernel, Microsoft Corporation

Highest reported total ISR routine time (%): 0,057633
Driver with highest ISR total time: dxgkrnl.sys - DirectX Graphics Kernel, Microsoft Corporation

Total time spent in ISRs (%) 0,060563

ISR count (execution time <250 µs): 124172
ISR count (execution time 250-500 µs): 0
ISR count (execution time 500-1000 µs): 0
ISR count (execution time 1000-2000 µs): 0
ISR count (execution time 2000-4000 µs): 0
ISR count (execution time >=4000 µs): 0


_________________________________________________________________________________________________________
REPORTED DPCs
_________________________________________________________________________________________________________
DPC routines are part of the interrupt servicing dispatch mechanism and disable the possibility for a process to utilize the CPU while it is interrupted until the DPC has finished execution.

Highest DPC routine execution time (µs): 296,259167
Driver with highest DPC routine execution time: dxgkrnl.sys - DirectX Graphics Kernel, Microsoft Corporation

Highest reported total DPC routine time (%): 0,031393
Driver with highest DPC total execution time: Wdf01000.sys - Kernelmodustreiber-Frameworklaufzeit, Microsoft Corporation

Total time spent in DPCs (%) 0,067003

DPC count (execution time <250 µs): 398762
DPC count (execution time 250-500 µs): 0
DPC count (execution time 500-10000 µs): 1
DPC count (execution time 1000-2000 µs): 0
DPC count (execution time 2000-4000 µs): 0
DPC count (execution time >=4000 µs): 0


_________________________________________________________________________________________________________
REPORTED HARD PAGEFAULTS
_________________________________________________________________________________________________________
Hard pagefaults are events that get triggered by making use of virtual memory that is not resident in RAM but backed by a memory mapped file on disk. The process of resolving the hard pagefault requires reading in the memory from disk while the process is interrupted and blocked from execution.

NOTE: some processes were hit by hard pagefaults. If these were programs producing audio, they are likely to interrupt the audio stream resulting in dropouts, clicks and pops. Check the Processes tab to see which programs were hit.

Process with highest pagefault count: avpui.exe

Total number of hard pagefaults 6614
Hard pagefault count of hardest hit process: 6169
Number of processes hit: 18


_________________________________________________________________________________________________________
PER CPU DATA
_________________________________________________________________________________________________________
CPU 0 Interrupt cycle time (s): 2,575620
CPU 0 ISR highest execution time (µs): 241,11750
CPU 0 ISR total execution time (s): 0,861580
CPU 0 ISR count: 108082
CPU 0 DPC highest execution time (µs): 296,259167
CPU 0 DPC total execution time (s): 0,910351
CPU 0 DPC count: 385133
_________________________________________________________________________________________________________
CPU 1 Interrupt cycle time (s): 0,36640
CPU 1 ISR highest execution time (µs): 0,0
CPU 1 ISR total execution time (s): 0,0
CPU 1 ISR count: 0
CPU 1 DPC highest execution time (µs): 25,539167
CPU 1 DPC total execution time (s): 0,000781
CPU 1 DPC count: 278
_________________________________________________________________________________________________________
CPU 2 Interrupt cycle time (s): 0,439903
CPU 2 ISR highest execution time (µs): 0,0
CPU 2 ISR total execution time (s): 0,0
CPU 2 ISR count: 0
CPU 2 DPC highest execution time (µs): 141,48750
CPU 2 DPC total execution time (s): 0,005403
CPU 2 DPC count: 892
_________________________________________________________________________________________________________
CPU 3 Interrupt cycle time (s): 0,430257
CPU 3 ISR highest execution time (µs): 0,0
CPU 3 ISR total execution time (s): 0,0
CPU 3 ISR count: 0
CPU 3 DPC highest execution time (µs): 93,89250
CPU 3 DPC total execution time (s): 0,000940
CPU 3 DPC count: 209
_________________________________________________________________________________________________________
CPU 4 Interrupt cycle time (s): 0,419752
CPU 4 ISR highest execution time (µs): 0,0
CPU 4 ISR total execution time (s): 0,0
CPU 4 ISR count: 0
CPU 4 DPC highest execution time (µs): 48,578333
CPU 4 DPC total execution time (s): 0,013419
CPU 4 DPC count: 6967
_________________________________________________________________________________________________________
CPU 5 Interrupt cycle time (s): 0,398976
CPU 5 ISR highest execution time (µs): 0,0
CPU 5 ISR total execution time (s): 0,0
CPU 5 ISR count: 0
CPU 5 DPC highest execution time (µs): 67,440833
CPU 5 DPC total execution time (s): 0,001261
CPU 5 DPC count: 285
_________________________________________________________________________________________________________
CPU 6 Interrupt cycle time (s): 0,416828
CPU 6 ISR highest execution time (µs): 0,0
CPU 6 ISR total execution time (s): 0,0
CPU 6 ISR count: 0
CPU 6 DPC highest execution time (µs): 71,926667
CPU 6 DPC total execution time (s): 0,005351
CPU 6 DPC count: 934
_________________________________________________________________________________________________________
CPU 7 Interrupt cycle time (s): 0,395711
CPU 7 ISR highest execution time (µs): 0,0
CPU 7 ISR total execution time (s): 0,0
CPU 7 ISR count: 0
CPU 7 DPC highest execution time (µs): 27,016667
CPU 7 DPC total execution time (s): 0,000274
CPU 7 DPC count: 88
_________________________________________________________________________________________________________
CPU 8 Interrupt cycle time (s): 0,389801
CPU 8 ISR highest execution time (µs): 0,0
CPU 8 ISR total execution time (s): 0,0
CPU 8 ISR count: 0
CPU 8 DPC highest execution time (µs): 53,22750
CPU 8 DPC total execution time (s): 0,003239
CPU 8 DPC count: 549
_________________________________________________________________________________________________________
CPU 9 Interrupt cycle time (s): 0,416883
CPU 9 ISR highest execution time (µs): 4,446667
CPU 9 ISR total execution time (s): 0,001839
CPU 9 ISR count: 7726
CPU 9 DPC highest execution time (µs): 55,150
CPU 9 DPC total execution time (s): 0,001386
CPU 9 DPC count: 277
_________________________________________________________________________________________________________
CPU 10 Interrupt cycle time (s): 0,698039
CPU 10 ISR highest execution time (µs): 3,4650
CPU 10 ISR total execution time (s): 0,002446
CPU 10 ISR count: 8364
CPU 10 DPC highest execution time (µs): 205,6950
CPU 10 DPC total execution time (s): 0,010799
CPU 10 DPC count: 1969
_________________________________________________________________________________________________________
CPU 11 Interrupt cycle time (s): 0,424304
CPU 11 ISR highest execution time (µs): 0,0
CPU 11 ISR total execution time (s): 0,0
CPU 11 ISR count: 0
CPU 11 DPC highest execution time (µs): 54,1850
CPU 11 DPC total execution time (s): 0,004729
CPU 11 DPC count: 1182
_________________________________________________________________________________________________________

Der LatencyMon schlägt glaube ich dann Alarm, wenn ich mich recht entsinne, wenn eine Latenz Spitze von über 1000us (1ms) erkannt wird.

Je kleiner die Werte, desto agiler ist das System, desto weniger wird das System durch andere Tasks (ISR/DPC) ausgebremst.

Das ganze ist wichtig bei Applikationen mit "near-realtime" Anforderungen, weil Windows kein real time OS ist .. es gibt nirgendwo Garantien dafür, wann eine Interrupt Verarbeitung (direkt als ISR oder verzögert als DPC) erfolgt bzw abgeschlossen ist. Oder auch die Verfügbarkeit einer CPU Resource.

Aber auch Mainboard Design, BIOS, Verteilung der IRQs auf CPUen, Programmierung der Treiber (sollten idR nicht länger als 100us lang auf einem core laufen) .. alles das muss am besten stimmen
Soweit ich mich erinnere hat es auch eine zeitlang gedauert, bis der Windows Prozess Schedulter auf die Architektur gewisser AMD CPUen angepasst / optimiert war.
 
Zuletzt bearbeitet von einem Moderator:
Kurzer 2 Minuten Test meines 5950x mit einem Gigabyte x570 Master und 32 GB XMP 3600 non ECC
(Keine Optimierungen außer Schalter Hintergrundienste - viel Gedöns im Hintergrund laufen
inkl. Kaspersky, PrimoCache, Everything, Firefox usw..):


Reported CPU speed: 340 MHz
[..]
Highest measured interrupt to process latency (µs): 435,0
Average measured interrupt to process latency (µs): 10,472110

Highest measured interrupt to DPC latency (µs): 431,50
Average measured interrupt to DPC latency (µs): 1,035948
[..]
REPORTED DPCs
_________________________________________________________________________________________________________
DPC routines are part of the interrupt servicing dispatch mechanism and disable the possibility for a process to utilize the CPU while it is interrupted until the DPC has finished execution.

Highest DPC routine execution time (µs): 288,180
Driver with highest DPC routine execution time: tcpip.sys - TCP/IP-Treiber, Microsoft Corporation

Highest reported total DPC routine time (%): 0,000446
Driver with highest DPC total execution time: ntoskrnl.exe - NT Kernel & System, Microsoft Corporation

Total time spent in DPCs (%) 0,000971

DPC count (execution time <250 µs): 9356
DPC count (execution time 250-500 µs): 0
DPC count (execution time 500-999 µs): 1
DPC count (execution time 1000-1999 µs): 0
DPC count (execution time 2000-3999 µs): 0
DPC count (execution time >=4000 µs): 0


_________________________________________________________________________________________________________
REPORTED HARD PAGEFAULTS
_________________________________________________________________________________________________________
Hard pagefaults are events that get triggered by making use of virtual memory that is not resident in RAM but backed by a memory mapped file on disk. The process of resolving the hard pagefault requires reading in the memory from disk while the process is interrupted and blocked from execution.

NOTE: some processes were hit by hard pagefaults. If these were programs producing audio, they are likely to interrupt the audio stream resulting in dropouts, clicks and pops. Check the Processes tab to see which programs were hit.

Process with highest pagefault count: firefox.exe

Total number of hard pagefaults 8
Hard pagefault count of hardest hit process: 5
Number of processes hit: 3
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: bitheat
Dankeschön, sieht ja von den Werten gar nicht übel aus.

me> Highest measured interrupt to DPC latency (µs): 282,90
me> Average measured interrupt to DPC latency (µs): 2,700038
vs
you> Highest measured interrupt to DPC latency (µs): 431,50
you> Average measured interrupt to DPC latency (µs): 1,035948

Aber ich denke ich warte doch mal lieber auf DDR5 und ob es noch ein paar interessante Boards mit Thunderbolt gibt.
 
bitheat schrieb:
Aber ich denke ich warte doch mal lieber auf DDR5

Ob DDR5 auf dem Desktop vor late 2022 kommt?

Einen internen Thunderbolt-Header hat mein X570 Master sogar. Kann man irgendwie eine Thunderbolt-Karte von Gigabyte dran hängen. Hab mich aber noch nicht weiter damit beschäftigt.
 
  • Gefällt mir
Reaktionen: bitheat
ameisenbaer schrieb:
Ob DDR5 auf dem Desktop vor late 2022 kommt?

Einen internen Thunderbolt-Header hat mein X570 Master sogar. Kann man irgendwie eine Thunderbolt-Karte von Gigabyte dran hängen. Hab mich aber noch nicht weiter damit beschäftigt.

Na ja, hab ja auch noch was Zeit und der Zeitpunkt für eine solche Änderung sollte wohlüberlegt sein angesichts der damit verbundenen Kosten.
 
Zurück
Oben