LatencyMon wurde als Meßtool für den Bereich Audioverarbeitung geschrieben unter dem Hintergrund, dass es bei Audio-Anwendungen mit real-time Anforderungen aufgrund von schlechten Treibern oder schlecht eingestellten Systemen (BIOS Einstellungen, Hintergrundprozesse, ...) zu Audio Aussetzern kommen kann.

Darum induziert LatencyMon schon von sich aus eine (somit "standardisierte") Systemlast, die der Last einer DAW (Digital Audio Workstation, zB Cubase, etc) gleichkommen soll.

Inwieweit es Sinn macht, darüber hinaus noch weitere Last zu generieren, sei dahingestellt. Problematisch sehe ich hier vor allen Dingen, dass diese Werte dadurch nur schlechter vergleichbar sind.

Was den Nutzen dieser Liste weiter schmälert ist, dass es keine Filtermöglichkeiten gibt.

Ich würde beispielsweise gerne nach einem aktuellen Laptop Modell mit geringer DPC schauen, das für die Audiobearbeitung gut geeignet wäre. Die zusätzliche Systemlast macht das zunächst einmal schlecht mit Werten vergleichbar, die man selber schon mal im IDLE Betrieb gemessen hat, um zu sehen, welche Grundlast an DPC ein System alleine schon hat, wenn sonst keine andere Applikation läuft.

Dann würde ich gerne eine gewisse Vorauswahl treffen können, was die CPU Leistung und die HW Ausstattung anbelangt. Also mindestens 16 GB DRAM, mindestens 2TB SSD, ein dedizierter AMD oder nVIDIA Grafikchip, Thunderbolt/USB4 ...

Aber das alles ist leider nicht möglich, man müsste sich also mühevoll von unten nach oben durcharbeiten und sich selber per Hand eine Excel Tabelle erstellen, was vom Zeitaufwand her sehr aufwändig wäre.

Es wäre schön, wenn diese Informationen in Form einer Datenbank verfügbar gemacht würde und bei den DPC Messungen der "geringste", der "höchste" und der "recurring peak Wert" für DPC Latenzen vermerkt würde im IDLE Betrieb.

Oder man sollte zumindest dabeischreiben, von wann ein Gerät ist, wieviel es zum Testzeitpunkt gekostet und vielleicht noch CPU, GPU, DRAM, SSD Größe dabeischreiben.

Wird der LatencyMon-Testlauf im Akku- oder im Netzbetrieb durchgeführt?

Ich habe nämlich gerade eine interessante Beobachtung gemacht: Der Treiber ACPI.sys, unter Audioanwendern gefürchtet ob seiner DPC-Zicken, führte bei meinem neuen Surface Laptop 5 im Akkubetrieb zu DPC-Latenzen oberhalb von zwei Millisekunden, was den Rechner für Echtzeitanwendungen eigentlich disqualifiziert. Ein weiterer Test im Netzbetrieb zeigte allerdings einen ganz zahmen und zurückhaltenden ACPI.sys, die höchsten Latenzen von gerade einmal 0,7ms hatte ein anderer Treiber zu verantworten. Der gleichzeitig laufende Demosong in Ableton Live klang dabei super cremig (Selbstverständlich über ASIO-Treiber an entsprechendem Equipment).

Quote from: phranky on November 17, 2020, 15:41:54
1. Waren USB-Geräte an die Notebooks angeschlossen?
2. Wurden die Windows- und Programmeinstellungen im Auslieferungszustand belassen?

USB Geräte sollten keine angeschlossen sein, maximal eine Maus oder ext SSD können wir nicht ausschließen das manche Tester am Gerät hatten. Programmeinstellungen sind im ausgeglichenen Modus (oder eben Standard).

Daß Dell dabei die Goldene Himbeere weiter behält, wundert mich nicht. Wäre es für Bürorechner, macht nichts. Aber für allwetter XPS, "premium" Laptop? Und die Workstation auch dabei. Spielen das Geld und moderne, starke und flotte Hardware keine Rolle?

Tausend Dank für diesen DPC-Latenz-Vergleich! Danach suche ich seit Jahren.
Nach meiner Erfahrung haben angeschlossene USB-Geräte und Windows-Einstellungen großen Einfluss auf DPC-Latenz-Peaks. Zwei Fragen zu euren Messverfahren:
1. Waren USB-Geräte an die Notebooks angeschlossen?
2. Wurden die Windows- und Programmeinstellungen im Auslieferungszustand belassen?

Würde mich über Antwort freuen :)
Besten Dank!