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

  • Ersteller synthpark
  • Erstellt am
daß die audiobuffer vom asiotreiber getriggert werden ist klar (asio callback über treiber)
aber da existieren viel mehr timings in einer daw, die nicht darüber ablaufen

natürlich ist es immer eine frage der implementierung und die kann uns nur steinberg verraten bzw sollte uns egal sein und wir messen eben das ergebniß für uns individuell und nutzen das, was uns mehr bringt

aber das problem mit queryperformancecounter habe ich selbst schon zu hauf in meinen anwendungen gehabt und weiß genau was da passiert, wenn es falsch läuft - da ist ein größerer aufwand, der getrieben werden muß um dies wieder zu kompensieren (thread pinning, calibration, auslastungserhöhende vorgänge)

es gibt natürlich noch den DX-multimediatimer der sehr genau ist.. das ist wieder ein anderes thema.

//edit
auch in GS gehen die meinungen außeinander:
http://www.gearslutz.com/board/music-computers/835600-hpet-high-precision-event-timer-off.html

was dort in post #6 technisch beschrieben wird, kann ich so bestätigen
 
  • Danke
Reaktionen: akl
mittlerweile bin ich auch am überlegen wie sich der latencymon aufs system auswirkt mit seinen messungen
da existiert ja der spruch "wer misst, misst misst"
und der ist in diesem fall nicht so ganz abwegig, da wir auf dem selben system, was wir messen möchten, ein tool laufen lassen, das mit den selben ressourcen und gegebenheiten das system misst, auf dem es läuft.
von daher stell ich mal folgende überlegungen in den raum:

- wie misst latencymon eigentlich die vergangene zeit der einzelnen prozesse/timings? welche system api wird hierbei verwendet? wie akkurat ist diese?

- wie wirkt sich die nutzung dieser api (zeitmessung) auf die systemlast wiederum aus bzw auf die interrupt pollings die je nachdem ob sie mit HPET oder RTC laufen, sich anderst auswirkt?

- kann es eine art gegenkompensation geben, bei der ich verfälschte messwerte bei besserer/schlechteren kernelzeiten bekomme? - sprich, durch weniger hochauflösende oder akkurate timing messmethoden bessere ergebnisse? dies könnte man durch real world benchmarkings mit der daw testen und das system mit dem belasten wofür man es optimiert

- HPET kann sich wohl negativ auf die kernelzeiten durch vermehrte interrupts auswirken, wenn sie excessiv genutzt wird - aber wenn man diese nicht zulassen will und HPET auschaltet, wird auf jedenfal ein fallback stattfinden - und zwar auf RTC oder andere hardwarenahe timer, die letztendlich eine geringere auflösung haben - dadurch fängt man sich dann bei vielen applikationen, die auf zeitmessungen oder waittimes aufbauen viele probleme ein, wenn sie dementsprechend "unkompensiert" implementiert wurden - oder sie benötigen dadurch einen erhöhten rechenaufwand, da jetzt andere konstrukte greifen, die wiederum die systemlast in die höhe treiben -> ergo es kommt je nach anwendung drauf an, ob man HPET ausschalten sollte, oder nicht. falls man den pc nur für die daw verwendet, und die daw keine probleme mit inakkuraten timings hat (und auf DX multimediatimer oder hardware getriggerte callbacks setzt) kann man es also abschalten - aber sobalt irgend eine anwendung jittering, fps drops, audio/videosync offset usw aufweist, kann man hier den übeltäter finden.

bei midi habe ich noch im hinterkopf, daß das midiinterface (die ganz alten wohl nicht) die midipakete selbst mit timestamps versieht - man kann ja in diversen DAWs auswählen ob systemzeit verwendet werden soll oder nicht - hier ist sicherlich der zusammenhang mit den HPET in verbindung zu bringen, bei dem sich in manchen konstellationen die midipakete an die falsche timeposition im projekt der daw platzieren.

im asio protokoll ist ein audiobuffer übrigends nicht mit timestamps versehen
d.h. es wird auch irgendeine systemzeit verwendet, wenn man diese samples nun einem absoluten zeitpunkt zuordnen will (und den mit midi oder video syncen muss)

die ganze geschichte ist wirklich von vorne bis hinten eine wissenschaft für sich und kann keineswegs pauschalisiert werden
 
Auf meinem System habe ich das Problem, dass ich bei aktiviertem HPET beim Benutzen eines USB-Audiointerfaces alle 10 Sekunden einen CPU-Peak auf einem Kern von 60% habe.

Das war wohl schon unter XP mal ein Problem, was mit einem Patch behoben wurde. Unter Win7 war das Phänomen dann wieder da.

Ich hatte zwei andere USB-Interfaces anderer Hersteller ausprobiert, was keinen Unterschied machte. Sobald irgendwelches Audio über das Interface ausgegeben wurde, waren die Peaks da. Nicht nur bei ASIO, sondern auch, wenn der MediaPlayer oder Windows selbst Sounds abspielte.

Mit Einbau einer PCIe-USB-Karte waren die Peaks auf 30% gesunken, aber immer noch alle 10 Sekunden da.

Erst seit dem Abschalten des HPET sind diese weg.
 
Als ich den Trouble mit dem schlechten Mainboard hatte MSI P55 GD65, hatte ich damit Stück für Stück mein System von ca 220 µs auf zumindest akzeptable (ich glaube) 80 µs gebändigt bekommen.

Dann kam der Nachfolger P55A GD65, den ich mir holte, damit USB3 und SATA6 direkt möglichst nahe am Chipset integriert sind und ich nicht alles komplett neu holen musste (CPU, RAM, etc).

Und dann die Offenbarung, viel bessere Werte als vorher und auch keine Probleme mehr mit Aussetzern. Das hat mir mehr Headroom gegeben, dass ich keine Probleme mehr mit Knacksern etc hatte bei ASIO Buffer Einstellungen im Bereich von 128 - 256 Samples.

Man kann jetzt natürlich alles in Frage stellen. Aber ich muss sagen, das tool hat mir bei 2 Dingen konkret geholfen

1. einen Treiber zu finden, der zu viel Latenz verursacht (alte version von Logitech setpoint)

2. überhaupt Unterschiede festzustellen, was passiert, wenn ich dies und das einstelle.

Aber ich würde mich natürlich auch freuen, wenn ich genau wüßte, wie die das machen. Vielleicht steht dazu was auf deren Webseite, aber so viel Lust hatte ich auch nicht, da noch weiter zu wühlen. Vielleicht hast Du ja den notwendigen Elan ;-) Das fänd ich schön.
 
Die 4.2 Latencymon ist nirgends erhältlich....hat wer einen seriösen link?
 
Ist dir der Link von akl nicht seriös genug? Tsss...
 
sorry, hatte nur seinen link zur 6er Version gesehen! Danke für den Hinweis....;)
 
Eine konkrete Frage hinsichtlich Notebooks:
Habe gerade einen i3 Notebook fürs Drumrecording (8 Spuren Aufnahme plus eine Stereospur) hergerichtet.
Ich nutze Cubase LE 7, dafür vollkommen ausreichend, und die CPU langweilt sich, habe den LIve Forever Demo Song bei 128 samples mit ASIO4ALL-Treiber (später kommt ein USB Focsurite 18i20 dran.) problemlos am Laufen.

Nun habe ich das Problem mit CPU Spikes mit LatencyMon und dpclat geprüft.
Erstmal den ganzen Hotkey-Mist, Launch-Treiber und WLAN deaktiviert.
Erst nach dem ich den Akku physisch rausgenommen habe, sind die Werte praktisch gut.

Das kann es doch aber nicht sein, kann man diesen ewigen Battery Check von Win 7 nicht umgehen (Energieoptionen sind auch auf Höchsleistung)?

Wer hat dieses Problem, ohne Akku rausnehmen, lösen können?
 
Im Gerätemanager findest du unter Systemgeräte einen Treiber für den ACPI-Akku. Deaktivieren sollte helfen, allerdings kennt das OS dann den Akkustand nicht mehr.
 
Ich habe gerade geschaut, ich habe folgende Einträge:
ACPI-Deckel
ACPI-Energiezustandknopf
ACPI-Schalter
ACPI-Thermozone (2mal)
Eingebetteter Microsoft ACPI-konformer Controller
Microsoft ACPI-konformes System

Welcher davon ist jetzt der Richtige?
danke vorab!

Ach ja, Hauptverursacher ist tatsächlich die Akkuabfrage, Hotkey + WLAN eher weniger, aber gerade WLAN erhöht auch noch mal (aber das ist immer noch im grünen Bereich)
 
Ups, unter Geräte-Manager/Akkus sind die u.g. Einträge zu sehen
Welcher ist der Richtige?
 

Anhänge

  • Akku.jpg
    Akku.jpg
    14 KB · Aufrufe: 234
Bin anscheinend blind.
Wo ist denn der link zur 4.2 latencymon-Version?
 
Mal eine kleine Anekdote von mir zum Thema "wer misst misst mist":

Ich habe ein recht freudenspendendes i7-System. Vor längerer Zeit habe ich auch mal den Latency-Checker angeworfen und hatte Latenzen von um die 35 µs. Das ist okay, aber eigentlich nicht das, was das System bringen sollte. "Schuld" war der USB-WLAN-Stick, wenn ich den ziehe, bin ich bei 1-2 µs.

Ich laste das System zwar im Alltag nie richtig aus, aber gerade habe ich mal ein Projekt richtig zugeknallt und bei etwa 95% Last gehabt. Und in diesem Praxisfall machte es keinen Unterschied ob ich mit oder ohne WLAN-Stick unterwegs war, jeder weiter EQ hat die Kiste trotzdem über die Grenze gebracht. Eine Optimierung an der Stelle (also in diesem Fall auf WLAN verzichten oder einen anderen Stick mit besserem Treiber umsteigen) hätte mir überhaupt nichts gebracht.

Vorgestern habe ich inspiriert durch diesen Thread noch mal Latency-Checker angeworfen und hatte auf einmal Latenzen um die 1000 µs und teilweise früber. Eigentlich hätte ich also mit diesen Werten gar nicht arbeiten können, wovon ich aber bisher nichts gemerkt hatte. Ein Gegencheck mit Latency-Monitor brachte mich dann auf die Lösung. Die Werte waren auch sehr schlecht, aber das Ding zeigte auch eine unsinnige CPU-Taktung an und gab auch einen Hinweis darauf aus.

Und siehe da: Ich hatte vor zwei Wochen meinen i7 3820 übertaktet und dann scheinen beide Tools kompletten Blödsinn zu messen. Da hätte ich mir jetzt wochenlang den Wolf optimieren können, besser wäre allerdings gewesen, die alte Weisheit zu beherzigen: "If it ain't broke, don't fix it."

Nach weiteren Tests habe ich dann herausgefunden, dass es scheinbar auch noch einen Zusammenhang damit gibt, wie genau die CPU übertaktet wird (ob nur über den Multiplikator oder auch über den Basistakt und den Teiler). Ich habe das aber nicht weiter untersucht, denn in meinem Fall ist eine Optimierung da sowieso fruchtlos.

Beide Tools sind ganz prima, wenn man bei seinem Rechner ein echtes Problem hat, er also deutlich weniger Leistung in der Praxis hat, als er haben sollte (oder beim Nachbarn hat). Dann kann man damit dem Problem auf den Grund gehen.

Einen fein rennenden Rechner aber nur auf die Werte optimieren zu wollen, halte ich für wenig sinnvoll.
 
  • Danke
Reaktionen: akl
@Rainer
Da bin ich völlig bei Dir, mein Hauptrechner hat so Werte um 60-140µs weit weg von einigen hier gezeigten Werten.
Ist mir aber egal, da ich das machen kann was ich brauche.
Und die CPU-Auslastung und Performanceeinbußen kommen klar vom exzessiven Gebrauch von Effekten und Gedöns :D

Allerdings hätte ich schon gewusst bei meinem Notebook, welcher der o.g. ACPI Einträge für Akkus der richtige ist.
Denn wenn ich dies hionbekomme, dann kommen auch keine CPU-Peaks die sich negativ äußern
 
@Rainer: vollste Zustimmung.

Aber irgendwas muss man messen. Sonst kann man Änderungen schlecht bewerten, ob sie in die falsche oder die richtige Richtung gegangen sind.

Schön finde ich, dass Du nochmal die Geschichte mit den verschiedenen Clocks gebracht hast.

Da denke ich bin ich auf dem richtigen Weg, indem ich alles drangesetzt habe, einen festen CPU Takt einzustellen.

Und normalerweise spiegeln die "kleineren Kernel Latency Werte" auch genau das wieder, was sich nach Adam Riese auch ergeben sollte, wenn der Rechner weniger Services und spontan angestartete Prozesse im Hintergrund ausführt.

Und dass gewisse Treiber komplexer sind als andere und damit den Kernen mehr zu tun geben bei jeder Dateneinheit, das ist ja im grunde genommen auch bekannt.

Um nur mal ein Beispiel zu nennen, was ich meine: Firewire Geräte haben mehr Eigenintelligenz als USB Geräte, darum muss sich der OS Kern selber um weniger kümmern. Schnellerer und schlankerer Code ist die Folge.

Man sieht ja auch am Bereich von whitealbum, dass zB bei WLAN über USB 2 komplexe Treiber die CPU mehr beschäftigen.

Aber es stimmt schon .. man muss Messwerte am besten auch immer wieder hinterfragen und gerade in Szenarien, wo sich der Clock / Bezugstakt ändert oder es sogar mehrere Möglichkeiten einer Clock gibt, da muss man schon acht geben.

Performance Messungen waren schon immer ein heisses Thema...

Wie schön, dass es Otto Normalverbraucher idR egal sein kann.

Das "near realtime" Prozessing, das wir alle gerne anstreben, hat es halt in sich.
 
Wenn das Messen der Performance zum Hobby wird , dann ist das nicht gut.
 
Damit stellst Du aber eine sehr große User-Schaft in der PC-Welt in Frage....alle Tuner, OCler und Leute, die Spaß daran haben, an Leistungssteigerung zu tüfteln....nicht weil man unbedingt das Erreichte dann auch ausnutzt oder dringend benötigt, sonder weil der Weg das Ziel ist und man sich freut zu sehen, was möglich ist.....war schon spannend, schon damals 3DMark2001 und das Jahrzehnt danach, seinen PC immer wieder in Frage zu stellen, um noch mehr Punkte zu bekommen.....ein harmloses Hobby....wem es Spaß macht, so what.....gibt ja auch genug Irre, die ihre Opel- und VW-Proll-Kisten ihr Leben lang tunen und da all ihre Zeit und ihr Geld reinstecken....und von Sammlern irgendwelcher Gartenzwerge oder Bierdeckel mal abgesehen....der Mensch muss sich halt beschäftigen, sonst ist das Leben zu lang....;)

Ash
 
Frage der Zielrichtung. In einem Recording Forum, Unterforum "Windows und Musik", erwarte ich als Ziel erstmal, dass unter und mit Windows vernünftig Musik gemacht werden kann. Schon dabei sind die unterschiedlichen Ansprüche anstrengend genug unter einem Hut zu versammeln. Dem einen sind stabile 12 ms Audio-Latenz völlig ausreichend, dem anderen sind 3 ms noch zu viel Verzögerung, entsprechend unterschiedlich ist der Optimierungsbedarf. Ein PC ist ein Werkzeug, ein Auto ein Beförderungsmittel. Natürlich gibt es immer Leute, die die Bastelei daran zum Selbstzweck erheben, aber dann sollte das auch thematisch aus dem Forumstitel erkennbar sein, damit man sich rechtzeitig verpieseln und zwischen ernst gemeinten Hilfegesuchen und masturbativem Optimierungswahn differenzieren kann. ;-)
 
Du musst dich einloggen oder registrieren, um hier zu antworten.

Neue Antworten


Oft gelesene Themen

Zurück
Oben