64Hz

Hallo,

wenn ich via CWinApp (MFC) einen Timer laufen lasse, wird dieser
nicht schneller als 64Hz. Das hat mich bisher seltend gestört.

Über die WinAPI ::SetTimer komme ich leicht auf 500 Hz.

Ist das eine normale Erscheinung ?

Danke für Hinweise.

Auf 500 Hz kannst du nur kommen wenn du timeBeginPeriod aufrufst.

Hallo,

Das ist ja ganz was neues, erstmal danke für den Hinweis,
denn diese Funktion habe ich noch nie wo gesehen.

In ersten tests, hat die Auslösung von timeBeginPeriod(1)
und sein pardon keinen Effekt gezeigt, mein CWnd Timer schafft
nur 64Hz.

Die Application hat ein eigen erstelltes ActivX
im Dlg. Auch bei dekommentierug alle Aufrufe in OnTimer
bleibt die frequenz immer bei ~64Hz.

Andere W32 API's mit eigener MessageLoop kommen lässig auf
500Hz bis 800Hz verwendet mit OpenGL.

Ich werde nun eine Leere MFC Dlg base anwendung machen und
das mal erforschen.

Dabke für Hinweise
gruß
K.

dot

Was genau bedeuten 500Hz für dich? Und lass die Finger von timeBeginPeriod, das ist böse...

Da gibt es ja die totale FreakShow zu dem Thema:

http://www.geisswerks.com/ryan/FAQS/timing.html

Was 500 Hz bedeuten, das ist die Anschlagfrequenz die ich mit
einem simplem W32 Timer erreiche, in einer w32api mit eigener
MessageLoop.

Ich möchte auch nicht das System manipulieren, und wenn ich meine
Anwendung mehrmals starte , kann ich 10 mal 64Hertz erreichen, wovoan ich
auch gebrauch mache, es geht hier um Bildverarbeitung, inzwischen liefern
Kameras nicht nur 30 Bilder/ s sondern auch gerne 100Hz .

Ich habe Maschinensteuerungen wo viele Kameras mit 30Hz auf einer 16Kern CPU
Objekte bewerten, alles kein Problem. Aber meine API mit seinem DLG und dem ActivX schafft stehts nur maximal 64Hz.. Ich hätte mir zumindest gedacht das Dieser Wert je nach auslastung schwanken würde, nö er bleibt mit leichtigkeit
erhalten, ohne das ich CPU Last erzeuge, also da muss doch mehr gehen ?

Ich versuche natürlich nicht in der Reg rumzuhacken oder ähnliches da die Software breitbanding eingesetzt wird. Dennoch wundert mich diese Begrenzung
und werde dann mal eine alternative Messung machen mit einer neuen MFC App

Kompiliert vür XP

Gruß
K

Es kann auch seine das eine andere Anwendung timeBeginPeriod aufgerufen hat und du dadurch so eine hohe Frequenz erhälst - das ist nämlich systemweit. Denn bei SetTimer aus der WinAPI ist auch nur 16 ms das höchste was man bekommt, wenn man nix ändert.

Ah das sind ja dann die 64Hz 1000[ms]/16[ms] Ich mache dort
in WM_TIMER lediglich ein Invalidate, worauf OpenGL eine Scene neu
Rendert und dessen MicroFrameCounter locker 500Hz in OnPaint
anzeigt. Ich zerlege gerade die Vorrichtung und
berichte woher die 500Hz kommen.

Okay also da scheint was faul zu sein, ich erhalte zwar hohe Frequenzen
der Timer scheint aber hier in einer Dauerbesprechung zu sein, da
er nicht reagiert auf auf Zeitänderungen. Dennoch ist die CPU Last bei 400Hz
gegen null.

Hier vom Test da ist was faul glaube auch das mehr als 64Hz nicht normal sind.

http://visiongrid.de/Wrong.jpg

hustbaer

dot schrieb:

Und lass die Finger von timeBeginPeriod, das ist böse...

timeBeginPeriod mag "böse" sein, ist aber manchmal nötig.
Und sooo "böse" ist es dann auch wieder nicht.

dot

Mir ist noch kein Fall untergekommen, wo timeBeginPeriod() tatsächlich nötig gewesen wäre und das hier ist ziemlich sicher auch keiner. Wann immer nur möglich, sollte es vermieden werden und es ist sehr wahrscheinlich, dass man, selbst in den Spezialfällen, an die du vermutlich gerade denkst, mit MMCSS besser beraten wäre...

hustbaer

Mach mal nen tearing-freien Present mit D3D9 im Windowed-Mode unter Windows XP.
Klar, geht auch ohne timeBeginPeriod(), nur dann kann man nimmer mit Sleep() Rechenzeit abgeben, und braucht dadurch bei 60 FPS 100% CPU Leistung auf einem Core.

Oder poll ne Hardware die keine Interrupts auslösen kann mit < 15ms Intervall.

ps: ich weiss auch nicht wieso timeBeginPeriod() bei Spielen o.ä. böse sein soll. Böse ist es wenn das ein Hintergrund-Prozess macht, der immer mitläuft, und dadurch den Stromverbrauch des Systems im Idle unnötig hochtreibt. Aber wenn ich grad was mache (Spiel spielen, Video gucken, ...) was sowieso schon ordentlich zulangt ... => egal?

dot

timeBeginPeriod() erhöht im Prinzip den Heartbeat des Systems, was dazu führt, dass der Scheduler wesentlich öfter aufgerufen wird, was nicht nur nutzlos Energie verschwendet, sondern generell unnötigen Overhead erzeugt. Insbesondere wenn Anwendungen wie Spiele oder ein Videoplayer laufen, willst du deine CPU normalerweise eher möglichst produktiv einsetzen und indem du mit timeBeginPeriod() die Anzahl der Kernel Mode Switches pro Sekunde um ca. Faktor 15 erhöhst, erreichst du mit Sicherheit eher das Gegenteil...

Mag sein, dass du mit Tearing in Windows XP da einen Fall hast, wo dies tatsächlich die einzige Möglichkeit ist, Symtome zu lindern (hab mit dem Problem nicht genug Erfahrung, um das zu beurteilen). Eine wirkliche Lösung des zugrundeliegenden Problems wird timeBeginPeriod() aber rein prinzipiell nicht liefern und unter aktuellen Versionen von Windows gibt es wie gesagt bessere Möglichkeiten (abgesehen davon, dass ab Windows Vista mit aktiviertem DWM auf einem Monitor sowieso kein Tearing mehr auftreten kann)...