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

[synthpark]

Die Standard Einstellung ist bei Latencymon ist die Interrupt Latenz .

Das sind Probleme der Hardware im zusammenspiel mit Windows .

Zu der Kernel Latenz die du hier angesprochen hast und der Problematik kannst du gerne etwas dazu sagen , wir hören.

steht weiter oben, siehe AKLs Postings.

 

[stronca]

Hi,so habe jezt auch mal ein Test gemacht.Habe voher noch mein System Optimert mit der Anleitung von Tchibo.Würde gerne jezt wissen ob ich alles Richtig gemacht habe oder doch noch was nachbessern muss.Danke

 

[Ash-Zayr]

Ich fürchte, da kann man sein windows totoptimieren und wird die Werte von Tchibo nicht erreichen; ich nehme an, das hängt einzig und allein mit der RME Hammerfall zusammen...."ASIO in hardware gegossen", wie die so schön werben, und das scheint zu stimmen!

Was mich mal interessiert in die Runde gefragt: geht ihr jedes mal vor Arbeit mit der DAW in diese tief versteckte erweiterte-erweiterte-erweiterte-erweiterte Windows-Einstellung und ändert von "Programme" auf "Hintergrunddienste"?? Habt ihr jemals sehen können, dass dieses Option die Latenz im Sequencer positiv beineflusst oder aber hier diese gemessenen Latency Werte? Ich nicht, ich lasse immer auf Programme, was ja dem normalen Werkeln am PC sonst entspricht inkl. Games. hmm....

Ash

 

[Kuno]

Über diese Einstellung habe ich nun schon die unterschiedlichsten Dinge gehört.
Einige behaupten, das System wäre performanter mit "Programme", die anderen sagen "Hintergrunddienste".
Ich war bislang zu faul, das wirklich mal auszuprobieren und wage zu bezweifeln, daß das einen großen Einfluss hat.

Ich fürchte, da kann man sein windows totoptimieren und wird die Werte von Tchibo nicht erreichen; ich nehme an, das hängt einzig und allein mit der RME Hammerfall zusammen...."ASIO in hardware gegossen", wie die so schön werben, und das scheint zu stimmen!

Könnte auch einfach am Board liegen.
Sowas lässt sich leider immer schwer vorher sehen.

 

[akl]

Die Standard Einstellung ist bei Latencymon ist die Interrupt Latenz .
[..]

Aber nur in höheren Versionen von LatencyMon, weil sich in Windows 8 was geändert hat. Da kann man bescheuerterweise die Kernel Latenz auf einmal nicht mehr messen.

Das bedeutet nicht, dass die Kernel timer Latenz auf einmal nicht mehr so relevant wäre.

Und nochmal als Empfehlung. Wer sich dem Thema annähern möchte, sollte sich wirklich mal die Muße nehmen und wenn es sein muss das ganze 20 mal durchlesen auch unter zur Hilfenahme von LEO dictionary.

- Siehe unten copy paste (1) "About DPCs and ISRs -
http://www.resplendence.com/latencymon

Ich versuche mich nun mal mit einer möglichst einfachen Übersetzung / Erklärung.

Die Prozesse in einem System werden von einem Task Scheduler verwaltet. Es gibt Prozesse unterschiedlicher Priorität. Den Prozessen mit höherer Priorität räumt der Prozesscheduler mehr CPU Zeit ein. Es gibt besonders priviligierte Prozesse die durch einen Hardware Interrupt so schnell wie möglich auf einer CPU initiiert werden, die halten sofort alles an, was vorher auf der CPU lief, egal wie hoch deren Prozeßpriorität war.

Das sind die sogenannten Interrupt Service Routinen (ISR). Ein wichtiges Ereignis ist zum Beispiel Daten von einem i/o Port eines Gerätes abholen ehe der Puffer dort überläuft und Daten verloren gehen. Diese ISRs können selber noch weitere Prozesse aufstarten, die sogenannten Deferred Prozedure Calls, die mit hoher Wahrscheinlichkeit auf der gleichen CPU ausgeführt werden.

Für eine Audio Applikation, die auf einer CPU oder einem CPU Kern läuft bedeutet dies, dass sie so lange nicht weiter ausgeführt werden kann, bis sowohl ISR als auch DPC komplett abgearbeitet worden sind.

Der Prozess Scheduler kann da nichts dran machen, weil sowohl ISR als auch DPC einen höheren Interrupt Request Level (IRQL) haben. Diese Low Level Routinen sind in einem System halt so wichtig, dass man ihnen eine sehr hohe Priorität einräumt, dass sogar ein Audio Prozess erst einmal warten muss.

Und das ist auch gut so, denn Daten müssen garantiert und schnell genug von und zu ihren i/o ports befördert werden, sonst gibts noch viel grössere Probleme, als dass Audio ins Wanken kommt.

Darum ist es sehr wichtig, dass Interrupt Service Routinen (ISR) und Deferred Procedure Calls (DPCs) möglichst schnell abgearbeitet werden, damit das Gesamtsystem immer noch responsiv bleibt (und auch Audio Streaming nicht ins Stocken kommt - auch bei kleineren ASIO Buffern - )

Die ISR und DPC sollten immer so schnell wie möglich abgearbeitet werden können und allerhöchstens bis zu rund 100µs dauern. Aber je weniger desto besser !

Wenn die Laufzeit solch wichtiger Prozesse tendenziell zu lange dauert, dann können Audio Programm einfach nicht mehr schnell genug den Datentransfer zum Audiodevice (read/write) hinbekommen.

Darum ist es sehr interessant zu wissen, wie gering der Wert für die Kernel timer Latenz ist.

Damit sollten diese Werte von LatencyMon klarer sein:
kernel timer latency ... current
kernel timer latency ... highest
Highest ISR routine execution
Highest DPC routine execution time

Im BIOS kann man bestimmte Einstellungen machen, dass gewisse Dinge per se weniger ausgebremst werden. Am besten man geht von den "Optimized Defaults" des Herstellers aus.
- C-States deaktivieren
- Speedstep deaktivieren
- Spread Spectrum deaktivieren, damit die Base Clock nicht schwankt (wegen Einhaltung von Normen zu besseren Elektromagnetischen Verträglichkeit)
- Disk Controller sollten im AHCI mode laufen

Es gibt noch mehr Möglichkeiten, aber die möchte ich gar nicht nennen, weil die esoterischer sind, und die o.g. eigentlich schon genug Potential haben, einen deutlichen Unterschied zu erzeugen (schnellere Zugriffszeiten aufs RAM,

Dann vielleicht noch Core Parking disablen und dann sollte sich schon was tun. Wenn eben nicht der Rechner irgendwelche Probleme hat und deshalb schneckig ist. Dem versucht man halt mit den Kernel Latency Messungen auf die Spur zu kommen.

Was an Latency Mon noch wichtig ist, das ist das TAB "Drivers".
Hier kann man sehen welcher Treiber die meisten ISRs und DPCs generieren und vor allem wie hoch die höchste Execution time und die akkumulierte Execution time ist.

Auch das TAB "CPUs" ist wichtig mal anzuschauen. Es zeigt, welche Treiber auf welchem Core die höchste Ausführungszeit hatte (nebst ISR und DPC time und count).

Dann schaut Euch auch mal an, dass immer wieder dieser NDIS Netzwerk Treiber durch hohe Ausführungszeiten ins Auge sticht. Also mein audio real time streaming geht auf jeden Fall immer dann gewaltig baden bzw in den Keller, wenn ich mit Firefox auf verschiedene Webseiten zugreife. ich vermute, dass die Netzwerkzugriffe alleine schon eine Menge Arbeit bedeuten, weil sich die Daten durch verschiedene Kernel Layer quälen müssen.

Hier nun der Orginal Text von der Seite
Fußnote (1): "About DPCs and ISRs
The Windows thread disptacher (also known as scheduler) which is part of the kernel executes threads based on a priority scheme. Threads with higher priority will be given a longer execution time (also known as quantum or time slice) than threads with a lower priority. However the kernel also knows other types of units of execution known as interrupt service routines (ISRs). Devices connected to the system may interrupt on a connected CPU and cause their interrupt service routines to execute. An interrupt can occur on the same processor that an audio program is running on. Any thread that was running on the processor on which an interrupt occured will be temporarily halted regardless of its priority. The interrupt service routine (ISR) is executed and may schedule a DPC (Deferred Procedure Call) to offload an amount of work. The DPC will most likely run immediately on the same processor which means the audio application will halt until both the ISR and the DPC routines have finished execution. That is because ISRs and DPCs run at elevated IRQL which means they cannot become preempted by the thread dispatcher (scheduler). Therefore to guarantee responsiveness of the system, ISR and DPC routines should execute as fast as possible. Guidelines say that they should not spend more than 100 µs of execution time however this is often not reached due to hardware factors beyond the control of the driver developer. If execution time gets too high, the audio program may be unable to deliver audio buffers to the hardware in a timely manner. "

 

[Beatback]

Angeschlossen per USB: eLicenser, Steinborg Midex 8, Tastatur, Maus
Gesteckt per PCI: RME Hammerfall DIGI9652 , Technisat Skystar 2
Onboard-Devices im BIOS aktiviert: NIC, Onboard-Sound, alle USB-Ports, Rest ist deaktiviert.

Ich kann nur sagen Wow!
Ich habe auch alles nach deiner Anleitung durchgeführt aber komme nicht an diese Werte siehe oben...

 

[akl]

Nachtrag: viele Windows Tuning guides haben den Ansatz u.a. die Anzahl der Prozesse auf dem System zu reduzieren, damit nach den nicht unterbrechbaren ISR und DPCs einfah noch genügend Zeit bleibt für Laufzeit und Datenaustauch zwischen DAW / Memory / Platte / Recording Interface.

In Timos guide werden eine menge von Dingen deaktiviert um alleine schon zu verhindern, dass der Aufgabendienst mitten in der Arbeit (Aufnahme oder was auch immer) auf die Idee kommt mal eben irgendeinen schönen cleanup oder sonstwas Dienst zu starten, was dann wieder zusätzliche Disk i/o und somit weitere ISRs und DPCs zur Folge hat, die man aber jetzt nicht haben möchte.

Das gleiche gilt natürlich für viele andere Dinge, Indexdienst, Virenscanner, Defragmentierung, Windows Update ...

Alles DInge die viele viele ISRs und DPCs zusätzlich generieren, die man beim Recorden halt nicht so gerne zusätzlich möchte.

 

[akl]

Über diese Einstellung habe ich nun schon die unterschiedlichsten Dinge gehört.
Einige behaupten, das System wäre performanter mit "Programme", die anderen sagen "Hintergrunddienste".
Ich war bislang zu faul, das wirklich mal auszuprobieren und wage zu bezweifeln, daß das einen großen Einfluss hat.

Ich fürchte, da kann man sein windows totoptimieren und wird die Werte von Tchibo nicht erreichen; ich nehme an, das hängt einzig und allein mit der RME Hammerfall zusammen...."ASIO in hardware gegossen", wie die so schön werben, und das scheint zu stimmen!

Könnte auch einfach am Board liegen.
Sowas lässt sich leider immer schwer vorher sehen.

Hi Kuno, ich habe zu diesem Thema folgendes gefunden.

http://www.microsoft.com/resources/..._perform_usage_assign_resources.mspx?mfr=true

"Click Programs to assign more processor resources to the foreground program than the background program.
Click Background services to assign equal amounts of processor resources to all programs."

Ich denke mit Hintergrundprogrammen können keine Treiber gemeint sein, da die Low Level Routinen (ISR und DPC) eh die höchste Prozesspriorität haben und normale threads einfach stoppen, solange bis ISR / DPC fertig abgearbeitet sind.

Auf anderen Seiten findet man Hinweise darauf, dass mit Hintergrundprogrammen sowas gemeint ist wie zB ein Druckdienst, der im Hintergrund läuft oder ein Service, der Filesharing ermöglicht oder der Indexdienst, was halt nicht vom Benutzer auf dem Desktop aufgestartet wurde.

Cubase ist ein vom Benutzer gestartetes Programm, das im Vordergrund läuft.

Ich vermute, dass die Optimierung für Vordergrundprogramme dazu führt, dass der Cubase Prozess gegenüber Hintergrundprogeammen (Indexdienst, Druckdienst, ...etc...) mehr Priorität bekommt.

Alles was auf Betriebssystemebene abläuft hat eh höhere Prio, ich nehme an, da wird sich eh nichts ändern.

Ich bekomme es aber auch noch nicht auf die Kappe, warum viele immer noch sagen, beim Betrieb einer DAW solle man für Hintergrunddienste optimieren. Letztens kam mal jemand hier im Forum vorbei, der behauptete genau das Gegenteil. Das hat mich auch sehr interessiert.

Aber leider hat er nicht mehr geantwortet und hats nicht begründet.

Generelle Infos zu Prozess Schedulern findet man noch hier, das in diesem Bezug auch noch interessant wäre zu wissen:

http://en.wikipedia.org/wiki/Process_scheduling

 

[akl]

Jetzt wird es richtig kurios.

Wenn ich LatencyMon 6 unter meinem Windows 7 installiere bekomme ich auch auf einmal 11000µs und wenn ich die alte Version LatencyMon 4.2 einfach überinstalliere (ohne reboot), dann bekomme ich nach wie vor 1 - 2 µs kernel Latenz.

Kann es sein, dass uns die neue Version von LatencyMon 6 gefooled hat und noch irgendeinen doofen Bug für Windows 7 hat, nachdem es für Windows 8 erweitert wurde ?!

Also ich bleibe jetzt erst mal wieder bei der alten version von LatencyMon, die bisher immer zuverlässig gearbeitet hat.

Wäre mal interessant zu wissen, ob diejenigen von Euch, die mit LatencyMon 6 so hohe Kernel Latenzen gemessen haben, mit der 4.2-er Version auch wieder im grünen oder grüneren Bereich wärt.

Trotz sauberer deinstallation / reinstallation von beiden LatencyMon versionen ist es nun so, dass ich nur mit der Version 4.2 die "angenehmeren" bzw gewohnten Werte an kernel Latenz bekomme.

Ich vermute nun, dass in LatencyMon v6.0 noch etwas im Unargen ist, vermutlich im Zusammenhang mit den letzten Änderungen zugunsten von Windows 8.

Leider habe ich bei denen keinen Download Link für die ältere Version gefunden. Ich hoffe, ihr habt die alte 4.2er release noch nicht entsorgt. Ansonsten hier von meiner dropbox. Einen Virenscanner habt ihr ja sicher...

https://dl.dropboxusercontent.com/u/96192996/LatencyMon-4.2.exe

Hier der entsprechende Prüfsummenfile:
https://dl.dropboxusercontent.com/u/96192996/LatencyMon-4.2.exe.md5
99b520b262b8852fd24a9f4a94f0d84d *LatencyMon-4.2.exe

Und hier ein Tool mit dem man die Prüfsumme errechnen kann: Hash Check Shell Extension
Dann könnt ihr mit Rechtsklick auf beliebige Datei dafür einen Checksum file generieren lassen
und das Ergebnis mit meinem Original vergleichen.

http://code.kliu.org/hashcheck/

 

[sixten]

Akl sehr gute Arbeit ...

 

[tchibo]

Was mich mal interessiert in die Runde gefragt: geht ihr jedes mal vor Arbeit mit der DAW in diese tief versteckte erweiterte-erweiterte-erweiterte-erweiterte Windows-Einstellung und ändert von "Programme" auf "Hintergrunddienste"?? Habt ihr jemals sehen können, dass dieses Option die Latenz im Sequencer positiv beineflusst oder aber hier diese gemessenen Latency Werte? Ich nicht, ich lasse immer auf Programme, was ja dem normalen Werkeln am PC sonst entspricht inkl. Games. hmm....

Ash

Die Einstellung hat bereits unter XP mit mehr als einem CPU-Kern keine Wirkung auf die Audio-Performance. Sie wurde von MC von RME dokumentiert zu einer Zeit, als Single Core Rechner mit XP der Normalfall waren. Unter Windows 7 ist sie (unschädlicher) Unfug.

Die Empfehlung ist ein gutes Beispiel dafür, dass beim Thema Windows-Optimierung sehr viel Mystik und wenig Fundiertes im Umlauf ist. Das gilt auch für mein PDF - was ich vor 3 Jahren aufschrieb, würde ich heute tw. anders verfassen. Insgesamt stehe ich zwar noch dazu, habe allerdings aufgrund der veralteten Hardware-Erwähnungen auch schon daran gedacht es zu entsorgen.

Inzwischen sind einige gute Tipp-Sammlungen im Netz verfügbar, z. B. auf der Steinberg Homepage. Das war zum Zeitpunkt der Entstehung des Dokuments noch völlig anders. Damals wimmelte das Web vor XP-Ratgebern, und für Win7 gab es absolut nichts, schon gar nicht auf deutsch. Wenige Audio-PC Anbieter hatten ihr Wissen für sich, und Hobby-User schauten in die Röhre. Und da die Empfehlung von RME kam, schrieb sie jeder ab, denn die sind renommiert und zuverlässig. Heute weiss ich es besser, aber da es keinen Schaden anrichtet, siegte bislang meine Faulheit. *g*

Also: Unfug, unnötig, verzichtbar.

 

[Ash-Zayr]

Das hier ist aus dem aktuellen Cubase 7 Handbuch! Auch schon zu Cubase 4 Zeiten war dieser Hinweis im Handbuch; allerdings da noch ohne die Einschränkung, dass es sich auf Systeme mit einer CPU bezieht. Nun ist aber die Frage; meint Steinberg hier wirklich, man solle es anwenden bei einer CPU, also auch ein Quadcore ist eine CPU, und erst bei einem echten Mulit-Sockel System braucht man es nicht mehr machen?

Optimieren der Prozessorleistung (nur Windows)
Sie müssen die Systemleistung für die Hintergrunddienste optimieren, um beim Verwenden von ASIO unter Windows (in einem System mit einer einzelnen CPU) die geringstmögliche Latenz zu erreichen:
1.Öffnen Sie die Windows-Systemsteuerung und wählen Sie »System«.
2.Wählen Sie auf der linken Seite die Option »Erweiterte Einstellungen«.
Der Systemeigenschaften-Dialog wird geöffnet.
3.Öffnen Sie die Erweitert-Registerkarte und klicken Sie im Systemleistung-Bereich auf den Schalter »Einstellungen…«.
Der Leistungsoptionen-Dialog wird geöffnet.
4.Öffnen Sie die Erweitert-Registerkarte und aktivieren Sie die Option »Optimale Leistung anpassen für: Hintergrunddienste«.
5.Klicken Sie auf »OK«, um die Dialoge zu schließen.

Edit: habe gerade geschaut, das Cubase 5 Handbuch hatte ich auch noch; dort steht dieser Absatz ebenso 1:1
Ich hatte mal gelesen, dass ASIO genau so ein Hintergrunddienst, den diese Windows Option meint.

Ash

 

[tchibo]

Probier es einfach aus und mach einen Performance-Vergleich. Du wirst mit ziemlicher Sicherheit keinen Unterschied bemerken, der über die Messungenauigkeit hinaus geht. *g*

 

[tchibo]

Wenn ich LatencyMon 6 unter meinem Windows 7 installiere bekomme ich auch auf einmal 11000µs und wenn ich die alte Version LatencyMon 4.2 einfach überinstalliere (ohne reboot), dann bekomme ich nach wie vor 1 - 2 µs kernel Latenz.

Kann es sein, dass uns die neue Version von LatencyMon 6 gefooled hat und noch irgendeinen doofen Bug für Windows 7 hat, nachdem es für Windows 8 erweitert wurde ?!

Hallo akl,

danke für die Info. Das Verhalten Ist hier reproduzierbar, allerdings nur auf dem i7-Rechner.

Kann es sein, dass die beiden Windows-Updates unschuldig sind wie eine Jungfrau kurz vor dem ersten Pickel, und dass sich das zeitlich mit dem Update des LatencyMon überdeckt hat? Das solltest du bitte aufklären, sonst haben wir ganz schnell das nächste Gerücht im Umlauf.

Viele Grüße
Timo

 

[stronca]

Habe grad noch ein test gemacht mit der version 4 von Latency,krasser unterschied nichts dran gemacht nur die version vn latency benuzt.

 

[Ash-Zayr]

Probier es einfach aus und mach einen Performance-Vergleich. Du wirst mit ziemlicher Sicherheit keinen Unterschied bemerken, der über die Messungenauigkeit hinaus geht. *g*

Ich kann mir vorstellen, dass sich diese Windows Option wahrscheinlich seit Win95 oder 98 bis heute gehalten hat, aber aus einer Ur-Zeit stammt, da Rechenleistung wirklich noch eine wertvolle, knappe Ressource war, die durch sowas tatsächlich zugeteilt werden musste...nach dem Motto " Hardware ist limitiert, lieber user, suche dir aus, welchen Tod Du sterben willst, denn beides, Programme und Hintergrunddienste, kannst Du haben".
Heute ist Rechenleistung im Überfluss vorhanden, selbst bei der Sequenzerarbeit langweilt sich mein 4,5GHz Quad doch zu Tode...insofern wohl wirklich kein Grund, da etwas zuzuteilen, weil einfach alles, was der PC abarbeiten musst, derart schnell/parallel geschieht, dass auch nichts auf das andere wirklich warten muss.
Dein Fazit akzepztiert: ein Relikt aus der PC-Urzeit.,.....das sollte Steinberg dann aber auch mal wissen und so langsam aus ihrem "getting started" herausnehmen.....und Microsoft aus Windows erst recht. Gibt es das denn bei Win 8 auch noch als Option?

Ash

 

[Ash-Zayr]

Mal eine andere Frage: ich hatte gestern noch mal etwas herumoptimiert, obwohl sich mein REchner eigentlich seit Jahren im "optimierten" Zustand befindet....DPC Checker wirft mir im mittel 45 mikrosekunden aus...wäre alles gut....nur alle 15-20 Sekunden dann ein Peak von bis zu 120....das ärgert mich, und das soll weg....habe gestern dann mal gewagt, den HPET zu deaktivieren....was mir auffiel: während das Refresh Intervall des Latency Checkers vorher glatte 1000 waren, waren es mit deaktiviertem hpet dann 967!? Wer kann das erklären? Das macht mir Angst und ist doch Indiz, dass das Deaktiveren den gesamten Rechner und das OS irgendwie aus dem Tritt bringt und die Kiste womöglich gar nicht mehr zuverlässig rechnen kann?
HPET off hat übrigens bei mir keine Verbesserung der Werte gebracht; bzw. wenn dann minimal, so dass ich das mit ausführlichen Tests und Geduld noch mal verifizieren müsste.

Ash

 

[akl]

Wenn ich LatencyMon 6 unter meinem Windows 7 installiere bekomme ich auch auf einmal 11000µs und wenn ich die alte Version LatencyMon 4.2 einfach überinstalliere (ohne reboot), dann bekomme ich nach wie vor 1 - 2 µs kernel Latenz.

Kann es sein, dass uns die neue Version von LatencyMon 6 gefooled hat und noch irgendeinen doofen Bug für Windows 7 hat, nachdem es für Windows 8 erweitert wurde ?!

Hallo akl,

danke für die Info. Das Verhalten Ist hier reproduzierbar, allerdings nur auf dem i7-Rechner.

Kann es sein, dass die beiden Windows-Updates unschuldig sind wie eine Jungfrau kurz vor dem ersten Pickel, und dass sich das zeitlich mit dem Update des LatencyMon überdeckt hat? Das solltest du bitte aufklären, sonst haben wir ganz schnell das nächste Gerücht im Umlauf.

Viele Grüße
Timo

Hallo Timo,

das habe ich gestern Abend auch schon überlegt und es ist tatsächlich so, da hat sich was überschnitten, danke, dass Du es noch mal auf den Punkt gebracht has.

Die hohen Kernel Latenzwerte, die gemessen wurden (>11.000). wurden von LatencyMon 6 verursacht, nicht von den Windows Patches.

Durch das Zurückgehen auf den alten Wiederherstellungspunkt hat sich auch automatisch wieder die alte LatencyMon Version 4.2 recovered. Das blieb unentdeckt und dadurch hatte es den Anschein, als würde das Backout der 2 optionalen Patches das Problem beheben.

Ich werde in dem anderen Thread mal ein EDIT draufsetzen und Entwarnung geben.

Gruß
Andreas

 

[buffi]

@HPET

interresante lecktüre über die timer in hardware/windows

http://msdn.microsoft.com/en-us/windows/hardware/gg463347.aspx

also HPET an lassen, da ressourcenschonender und genauer

wenn man HPET ausschaltet wird QueryPerformanceCounter nicht mehr auf diesen timer zugreifen und einen anderen hardwaretimer benutzen bzw den RDTSC( http://en.wikipedia.org/wiki/RDTSC ), was bei multicoresystemen durch corehopping zu fehlerhaften timerausgaben führt (weil jeder core seinen eigenen counter hat und durch stromsparfunktionen abweichen kann) somit würde das nur bei festgepinnten threads funktionieren (SetThreadAffinityMask)

näheres unter http://msdn.microsoft.com/en-us/library/ee417693(VS.85).aspx

HPET wird erst seit XP SP3 benutzt

wenn man hpet also deaktiviert wird man in die vergangenheit zurück katapultiert
und man landet hier:
http://support.microsoft.com/kb/895980
http://support.microsoft.com/kb/909944

 

[tchibo]

wenn man HPET ausschaltet wird QueryPerformanceCounter nicht mehr auf diesen timer zugreifen und einen anderen hardwaretimer benutzen bzw den RDTSC( http://en.wikipedia.org/wiki/RDTSC ), was bei multicoresystemen durch corehopping zu fehlerhaften timerausgaben führt (weil jeder core seinen eigenen counter hat und durch stromsparfunktionen abweichen kann) somit würde das nur bei festgepinnten threads funktionieren (SetThreadAffinityMask)

Vermutlich ist der einzige Timer, den deine DAW in Sachen Audio benutzt, die Sample Clock deines Interfaces. Sonst würde es ganz einfach knacksen. Ob die DAW bei ihrer samplegenauen Arbeit sich darüber hinaus des HPET bedient, da mystisch mich mal drum kümmern, ich sehe aber wenig Sinn darin, da genauer als samplegenau eigentlich keine Rolle spielt. Ganz genau wissen das aber nur die Programmierer - frag doch mal bei Steinberg & Co an.

Es bleibt die Möglichkeit, dass HPET das MIDI-Timing verbessert. Das hatte ich vor drei Jahren gemessen und zumindest für mein Interface (Midex 8) verneint. Gleichzeitig steigt auf meinem Rechner die knackfrei nutzbare Audio-Puffergröße reproduzierbar um eine Stufe von 1,5 ms auf 3 ms an, wenn HPET aktiviert ist. Das kann aber definitiv ein Einzelschicksal sein. Trotzdem würde ich nicht pauschal dazu raten, HPET zu aktivieren, außer du brauchst es aus anderen Gründen (z. B. Ruckler bei der Video-Wiedergabe, Mikro-Ruckler in Spielen etc).