DPC Latency Checking Tools - was erreicht Ihr für Werte?

[synthpark]

http://www.thesycon.de/deu/latency_check.shtml

Mit diesem Tool kann man angeblich die Echtzeitzfähigkeit austesten.

Mit meinem alten Desktop Rechner erreiche ich folgende erste Graphik.

Mit meinem viel neueren Samsung Chronos7 I7 Laptop sieht es schlechter aus.
Der Rechner zickt aber in der Praxis weniger rum.

Jetzt habe ich aber gelesen, daß eigentlich viel niedrigere Werte machbar sind,
in der Gegend von bis 100 Mikrosekunden. Meint Ihr, dass ist notwendig?


Was erreicht Ihr für Werte? Und fuer welches System (Laptoptyp, Desktop mit Motherboardangabe etc. ...). Vielleicht koennen wir hier einen aufschlussreichen Vergleich machen.





PS Ich suche das BIOS F5 fuer mein GAP35DS4 Mainboard, Revision 2.0 oder 2.1 (ich seh leider die Revisionsnummer nicht). Damit sollen viel bessere Werte erreichbar sein.

 

[slowhand73]

nimm mal den Latency Monitor und der zeigt dir auch die Programme an, die die starke Latenz verursachen.

 

[synthpark]

nimm mal den Latency Monitor und der zeigt dir auch die Programme an, die die starke Latenz verursachen.

ah ich hinke hinterher. Werde ich gleich mal ausprobieren, danke!

Trotzdem ist der Latency Checker nicht schlecht, um mal zu sehen, was machbar ist.

Hier ist noch eine Seite mit aktueller Performance.

http://www.anandtech.com/show/7426/evga-x79-dark-review/5

 

[Beatback]

Bei dir sind ganz schöne Ausschläge vorhanden...
Hast du denn Timos ganze Ratschläge durchgefüht?
http://www.timos-welt.de/win7/Windows_7_PC_als_DAW_optimieren.pdf

Bei mir hat es auch noch mal einiges gebracht den HPET (High Precision Event Timer) im Bios abzuschalten.
System: Win 7 64Bit Prof., Gigabyte H77 Board , I7 2600 , 16GB Ram

 

[Kuno]

Mit meinem viel neueren Samsung Chronos7 I7 Laptop sieht es schlechter aus.
Der Rechner zickt aber in der Praxis weniger rum.

Unter Windows 8 zeigt der Checker noch keine richtigen Werte an.

Siehe hier:
http://www.thesycon.de/deu/latency_check.shtml



Bevor du jetzt so eine aufgeblähte Liste abarbeitest, um dein System zu "optimieren", check mal unter den Energiesparoptionen die Settings für den Prozessor. Wenn der automatisch runter takten darf, kann das die Realtime-Audio-Performance beeinträchtigen.

 

[synthpark]

ne aufgeblähte Liste abarbeitest, um dein System zu "optimieren", check mal unter den Energiesparoptionen die Settings für den Prozessor. Wenn der automatisch runter takten darf, kann das die Realtime-Audio-Performance beeinträchtigen.

hab die Energiesparoptionen auf 100% Auslastung. Aber das Board mit seinem Bios macht Stress.
Oder die Graphikkarte. Mit dem Latency Monitor Programm siehts noch schlechter aus. in dem Moment, wo ich das Snipping Tool nehme, um den Screenshot zu machen, hat das Ding anscheinend zugeschlagen und die Werte geschrottet.

Hat jemand Ahnung von diesen hard Pagefaults? Ich habe extra die Auslagerungsdatei abgeschaltet, aber das bringt nichts.

 

[synthpark]

Bei dir sind ganz schöne Ausschläge vorhanden...
Hast du denn Timos ganze Ratschläge durchgefüht?
http://www.timos-welt.de/win7/Windows_7_PC_als_DAW_optimieren.pdf

Bei mir hat es auch noch mal einiges gebracht den HPET (High Precision Event Timer) im Bios abzuschalten.
System: Win 7 64Bit Prof., Gigabyte H77 Board , I7 2600 , 16GB Ram

Anscheinend gibts Probleme mit dem BIOS, älteres Motherboard Gigabyte P35 DS4 Rev 2.x seit Version 6. Ich muss jetzt den Support kontaktieren, weil das ältere V5 nicht DL-bar ist.

Neues Board und Prozessor würde komplett neuen Rechner bedeuten, ohne UAD1 und PCI HDSP Soundsystem etc, also 2 PCI Karten, dann müßte ich gleich das Netzteil tauschen, Graka, das macht alles keinen Sinn.

ich komme nicht mal an die Revisionsnnummer des Mobo ran, so ein Shit. Das ist hinten, da muss man gleich den Rechner auseinanderbauen. Im Bios steht nichts und Analyisesoftware zeigt nichts an.

hier schreibt einer vom Problem des Gigabyte Mainboards.

http://forums.hexus.net/scan-care-hexus/136117-gigabyte-ga-p35-ds4-motherboard-dpc-spikes-rma.html

Da hab ich mir damals einen State-Of-The-Art Rechner gekauft und das Ding hat's nie richtig gebracht! Total ärgerlich. Wegen irgendwelcher Biosgeschichten.

 

[synthpark]

was da einer schreibt:

die board-revision lässt sich NIE zuverlässig per software auslesen (es gibt schlicht keinen mechanismus, der das erlaubt - daten können nur aus dem bios ausgelesen werden, und so gut wie immer ist eine bios-version für mehrere board-revisionen bestimmt). im handbuch wird diese auch seltenst erwähnt, da die meisten board-revisionen kein neues handbuch erforderlich machen und oft das handbuch allenfalls um einen handzettel ergänzt wird, falls es doch mal der fall sein sollte.

insofern ist das board selbst die erste und einzige anlaufstelle, wenn es um das ermitteln der board-revision geht. meist findet sich die angabe zwischen den pci-slots oder zusammen mit weiteren angaben in einer ecke des boards.

ru,
cirion

Ist doch alles zum Kotzen mit den Rechern.

edit

Anhand von Fotos hab ich die Revision 2.0 ermittelt.

 

[synthpark]

Ei, ich hab ein Bios Update auf 13 gemacht und siehe da ...

 

[boggiboggwursdt]

Habe auch mal mein System mit dem Programm getestet, weil auch ich in unregelmäßigen ABständen Soundaussetzer habe.

Habe keinen Screenshot gemacht, aber die "Current Latency" schwankt bei mir recht stark; Minimal sind Werte um die 70µs, Maximalausschläge habe ich bis ~350µs.

Habe daraufhin mal mein System mit Latency Monitor untersucht und folgende Werte erhalten wie auf den Screenshots zu sehen. Den "Conclusion-Text" schreibe ich mal hier rein, vielleicht kann jemand damit was anfangen:

_________________________________________________________________________________________________________
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:08:28 (h:mm:ss) on all processors.


_________________________________________________________________________________________________________
SYSTEM INFORMATION
_________________________________________________________________________________________________________
Computer name: MUSIK-PC
OS version: Windows 7 Service Pack 1, 6.1, build: 7601 (x64)
Hardware: MS-7693, MSI, 970A-G43 (MS-7693)
CPU: AuthenticAMD AMD FX(tm)-8350 Eight-Core Processor
Logical processors: 8
Processor groups: 1
RAM: 16332 MB total


_________________________________________________________________________________________________________
CPU SPEED
_________________________________________________________________________________________________________
Reported CPU speed: 4000,0 MHz
Measured CPU speed: 3103,0 MHz (approx.)

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 USER PROCESS LATENCIES
_________________________________________________________________________________________________________
The interrupt to process latency reflects the measured interval that a usermode process needed to respond to a hardware request from the moment the interrupt service routine started execution. This includes the scheduling and execution of a DPC routine, the signaling of an event and the waking up of a usermode thread from an idle wait state in response to that event.

Highest measured interrupt to process latency (µs): 414,194640
Average measured interrupt to process latency (µs): 7,398534

Highest measured interrupt to DPC latency (µs): 244,472114
Average measured interrupt to DPC latency (µs): 2,888597


_________________________________________________________________________________________________________
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): 97,2360
Driver with highest ISR routine execution time: USBPORT.SYS - USB 1.1 & 2.0-Porttreiber, Microsoft Corporation

Highest reported total ISR routine time (%): 0,082044
Driver with highest ISR total time: hal.dll - Hardware Abstraction Layer DLL, Microsoft Corporation

Total time spent in ISRs (%) 0,163061

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): 355,6740
Driver with highest DPC routine execution time: USBPORT.SYS - USB 1.1 & 2.0-Porttreiber, Microsoft Corporation

Highest reported total DPC routine time (%): 1,061995
Driver with highest DPC total execution time: USBPORT.SYS - USB 1.1 & 2.0-Porttreiber, Microsoft Corporation

Total time spent in DPCs (%) 1,381308

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: explorer.exe

Total number of hard pagefaults 437
Hard pagefault count of hardest hit process: 235
Highest hard pagefault resolution time (µs): 5021,6330
Total time spent in hard pagefaults (%): 0,003076
Number of processes hit: 6


_________________________________________________________________________________________________________
PER CPU DATA
_________________________________________________________________________________________________________
CPU 0 Interrupt cycle time (s): 34,863118
CPU 0 ISR highest execution time (µs): 74,9980
CPU 0 ISR total execution time (s): 3,638803
CPU 0 ISR count: 496756
CPU 0 DPC highest execution time (µs): 283,6630
CPU 0 DPC total execution time (s): 9,898020
CPU 0 DPC count: 3153446
_________________________________________________________________________________________________________
CPU 1 Interrupt cycle time (s): 18,400586
CPU 1 ISR highest execution time (µs): 86,74850
CPU 1 ISR total execution time (s): 0,294666
CPU 1 ISR count: 54270
CPU 1 DPC highest execution time (µs): 307,62950
CPU 1 DPC total execution time (s): 4,323584
CPU 1 DPC count: 218679
_________________________________________________________________________________________________________
CPU 2 Interrupt cycle time (s): 10,183187
CPU 2 ISR highest execution time (µs): 60,201750
CPU 2 ISR total execution time (s): 0,436031
CPU 2 ISR count: 75909
CPU 2 DPC highest execution time (µs): 230,1110
CPU 2 DPC total execution time (s): 6,212941
CPU 2 DPC count: 314204
_________________________________________________________________________________________________________
CPU 3 Interrupt cycle time (s): 20,471796
CPU 3 ISR highest execution time (µs): 76,329250
CPU 3 ISR total execution time (s): 0,302910
CPU 3 ISR count: 55244
CPU 3 DPC highest execution time (µs): 343,56950
CPU 3 DPC total execution time (s): 4,574226
CPU 3 DPC count: 223407
_________________________________________________________________________________________________________
CPU 4 Interrupt cycle time (s): 14,511917
CPU 4 ISR highest execution time (µs): 72,51050
CPU 4 ISR total execution time (s): 0,319310
CPU 4 ISR count: 54684
CPU 4 DPC highest execution time (µs): 272,6640
CPU 4 DPC total execution time (s): 4,428379
CPU 4 DPC count: 227262
_________________________________________________________________________________________________________
CPU 5 Interrupt cycle time (s): 12,950307
CPU 5 ISR highest execution time (µs): 73,787250
CPU 5 ISR total execution time (s): 0,305638
CPU 5 ISR count: 55447
CPU 5 DPC highest execution time (µs): 355,6740
CPU 5 DPC total execution time (s): 4,502317
CPU 5 DPC count: 233163
_________________________________________________________________________________________________________
CPU 6 Interrupt cycle time (s): 20,419692
CPU 6 ISR highest execution time (µs): 88,0360
CPU 6 ISR total execution time (s): 0,331001
CPU 6 ISR count: 58770
CPU 6 DPC highest execution time (µs): 314,9110
CPU 6 DPC total execution time (s): 7,280064
CPU 6 DPC count: 489049
_________________________________________________________________________________________________________
CPU 7 Interrupt cycle time (s): 27,145443
CPU 7 ISR highest execution time (µs): 97,2360
CPU 7 ISR total execution time (s): 0,998881
CPU 7 ISR count: 164440
CPU 7 DPC highest execution time (µs): 299,334750
CPU 7 DPC total execution time (s): 14,920470
CPU 7 DPC count: 720998
_________________________________________________________________________________________________________


Vor allem diese usbports.sys machen offenbar große Probleme, dabei hab ich außer dem Audio-Interface, dem Cubase-Dongle und meiner Maus gar keine USB-Geräte angeschlossen! Also praktisch nur die "Grundausstattung" zum Recorden...

 

[boggiboggwursdt]

Hat irgendwer Rat?

 

[Beatback]

Hast du denn aktuelle USB Treiber?
Bei AMD haben die doch manchmal Extrabausteine für USB 3.0 drauf .
Neue Chipsatztreiber evtl wenn die USB Ports im Chipsatz mit drin sind.

 

[boggiboggwursdt]

Hab sowohl die USB 3.0-Treiber, als auch nen Chipsatztreiber instaliert. Bei beiden habe ich die aktuellste Version von der Mainboardhersteller-Homepage gezogen.

Hatte bis vor kurzem mit einem Intel Quad 4x2,4GHz und Cubase SL3 recordet; als Karte hatte ich die uuuralte Hoontech DSP2000. Auf diesem Krepel-System lief alles wesentlich besser als jetzt das neue System. Wegen Win7 und allgemein besserer PC-Leistung erfolgte dann der Umstieg. Recordingmäßig war das (bisher) ein Fehlgriff. Gibts denn (ein bißchen OT) irgendwo Anleitungen, welche HArdware sich gut verträgt fürs Recorden? Gibt ja auch Firmen, die nur Recording-PCs anbieten, meist so ab 1,5k € aufwärts - ich meine die kochen auch nur mit Wasser?

Bin ein wenig erschrocken, dass man mit moderner Hardware solch Performanceprobleme haben kann. Ich dachte mehr Leistung = besseres Recorden, und dass Hardware irgendwelche Standards erfüllen muss, die eine "gewisse" Kompatibilität bieten.

Andererseits hab ich gehört, dass mein Interface (Komplete Audio 6) auch gerne Probleme mit Knacksern und Soundaussetzern macht; allerdings wird hier immer nur NVIDIA als problematisch beschrieben, und ich hab ja ne ATI-GraKa...

 

[saki]

Hi,habe auch mal ein test gemacht.Aber anscheined habe ich ein kleines problem auch bei mir.Aber ich denke hier sind user die das besser beurteilen können.Danke

 

[akl]

@synthpark: Ich habe mich mit dem Thema lange beschäftigt.

Ich hatte ein MSI P55 GD65. Trotz "idealen" (reviewten) BIOS Einstellungen und Windows Tuning habe ich mit einer i7 860 CPU keine besseren Werte als 64 µs erreicht.

Die 64µs aber auch nur mit Cubase und dem Modus für optimierte Audioleistung. Da fummelt dann Steinberg selber irgedwo noch im System rum und baut sich ua. auch ein eigenes Energieprofil. Nebenbei wird auch für die Laufzeit von Cubase das CPU Core Parking disabled, so dass alle threads der CPU permanent am Laufen sind. Das habe ich bei mir in Windows inzwischen permanent eingestellt.

Dann fiel mir im Urlaub auf einer über 7 Jahre alten Gurke mit AMD Athlon 64 (4600 oder so) Prozessor auf, dass da die Kernel Latency Werte mit 1µs wesentlich besser waren. Mit meinem schnelleren System zuhause hatte ich keine Chance, das zu erreichen.

Nach Kauf des Nachfolger Mainboards MSI P55 GD65A mit leichten Änderungen (das "A" macht den Unterschied) kam dann die Offenbarung. Der Nachfolger des Boards wurde anscheinend irgendwie optimiert, nebenbei gesagt habe ich mir das geholt, weil ich Sata 6 und USB3 Support mit auf dem Board integriert haben wollte, weil externe Komponente am Sata Bus nicht die gewünschte Performance brachten.
Nun und siehe da ... 1-2 µs waren mit dem Nachfolger meines alten Boards auf einmal möglich. Der Rest vom Equipment ist genau das gleiche geblieben.

Dann habe ich noch ein paar andere wichtige Beobachtungen gemacht. Folgende BIOS Einstellungen wirken sich sofort sehr negativ auf die Kernel Latency aus
- Speed Stepping .. ich betreibe deswegen den Rechner mit 2.8 GHz konstantem Takt
- C-States .. sobald man die aktiviert, dann hat man gleich über 60µs drauf

Mit Latencymon habe ich auch herausgefunden zu der Zeit, dass der Logitech Mousetreiber (setpoint) aus dieser Zeit auch extrem CPU resourcen frass ... bei den neueren ist das nicht mehr der Fall. Der neue Logitech Treiber harmoniert prima mit einer G400.

Ich hoffe, das hilft Dir weiter.

Hier mal meine aktuellen Werte. Man sieht auch dass der LatencyMon andere Dinge zu checken scheint oder die Werte anders interprätiert als der DPC Latency Checker... Ich finde der LatencyMon ist das Tool mit den meisten Möglichkeiten und gefällt mir besser.

 

[saki]

So habe,noch mal was nach gebessert an mein system und hier das rezultat.Ich hoffe es passt alles.

 

[akl]

@saki:

Ich sehe gerade, anscheinend gibt es schon eine höhere Version von LatencyMon... die reporten das irgendwie anders oder hast Du Windows 8 ?

 

[saki]

Windows 7benuzte ich 64bit.

 

[akl]

Wenn man Windows 7 hat kann man weiterhin sein System basierend auf den feiner granulierten kernel Timer Werten messen, das kann man in LatencyMon 6 umstellen.

Bei diesen Werten kann man wesentlich besser sehen, ob da das Board / BIOS spinnt.

Wenn man nur auf Process Level misst bekommt man IMHO nicht so viel mit.

Dazu gibt es auch folgende Erklärung von der Firma. Klar, wegen Windows 8 sahen die sich gezwungen auf Process Level weiterzumessen, aber sie waren ja so vorausschauend, das konfigurierbar zu machen.

http://www.resplendence.com/latencymon_interrupt2process

 

[saki]

So habe noch mal ein test gemacht.