4. Wo sind meine Ticks geblieben?

Wo sind meine Ticks geblieben?

  • J

    Wenn die Auflösung von GetTickCount zwischen 10 und 20 ms liegt, dann ist 0 sehr wohl realistisch....

    0
  • H

    Okay, aber wieso passiert bei HighPerformanceCounter das gleiche?
    Und @ Auflösung: Wenn ich keinen Denkfehler gemacht habe, müsste die Auflösung, um den Fehler hervorzurufen, mindestens 30 ticks betragen. (60 - 0 !)

    0
  • B

    SCM? 😕

    0
  • J

    Jochen Kalmbach schrieb:

    Du solltest die Zeit mit "QueryPerformanceCounter" messen.

    Vorsicht damit! QueryPerformanceCounter greift auf den Prozessorinternen Time Stamp Counter zu, der eigentlich nur dazu gedacht war, die Anzahl Clocks zwischen zwei Zeitpunkten zu messen. Dies ist aber mit einigen Problemen bei neueren Prozessorarchitekturen (Powermanagement, variabler Taktfrequenz, ...) verbunden...

    Siehe dazu: http://www.heise.de/newsticker/meldung/65802

    Hatte damals auch eine Diskussion im Heise-Forum angefangen, weil ich selber verunsichert war.. und siehe da es gab sogar mal kompetente Antworten.

    Als Alternative wurden mir damals TimerQueues ([msdn]CreateTimerQueue[/msdn], etc) vorgeschlagen. Allerdings haben die Funktionen natürlich auch einen Pferdefuss der sich durch Studium der MSDN erst verdeutlicht:
    Requirements
    Client Requires Windows Vista, Windows XP, or Windows 2000 Professional.
    Server Requires Windows Server "Longhorn", Windows Server 2003, or Windows 2000 Server.

    Bei POSIX gäbs zum Beispiel die Funktion microtime und das seit Jahren... (o;
    Auf codeproject.com findet sich im Übrigen auch ein netter Artikel über Timer unter Windows.

    Mein Vorschlag für die Zeitmessung in Zukunft ist einen eigenen Zeit-Zähler mitlaufen zu lassen, um Zeitschritte zu messen. Die Inkrementierung des Zählers würde ich wohl in zukünftigen Projekten über Queue Timer erledigen.

    0
  • J

    Es sei zumindest angemerkt, dass der TSC nicht immer verwendet wird (ist abhängig von der geladenen HAL). Auch kann man die Verwendung des TSC mit /usepmtimer bei den Boot-Parametern unterbinden.

    0
  • J

    Ich denke jedoch man wird wohl, um stabile und funktionierende Software zu entwickeln, annehmen müssen, dass die TSC - mit allen Konsequenzen verwendet wird. Nich umsonst hat z.B. Windows XP mit SP2 dank der DualCore-Offensive u.a. genau damit Sorgen...

    0
  • J

    Ich denke jedoch man wird wohl, um stabile und funktionierende Software zu entwickeln, annehmen müssen dass QueryPerformanceCounter/Frequency funktioniert.

    0
  • H

    Hi!
    Ich wollte nur darauf hinweisen, dass es mit WM_TIMER einigermaßen gut klappt (welch Wunder 😉 ). Dennoch finde ich die Diskussion sehr interessant, vor allem da mein Ziel (eigentlich) immer noch nicht erreicht ist. Ich hab jetzt das Intervall vom Timer angepasst an die Zeit, die ich ursprünglich gemessen habe. Wenn der Rechner jetzt also schneller ist, bringt es _nix_ und wenn er langsamer ist... ist er langsamer :p
    Naja, egal, was mich jetzt interessiert:

    junix schrieb:

    Ich denke jedoch man wird wohl, um stabile und funktionierende Software zu entwickeln, annehmen müssen, dass die TSC - mit allen Konsequenzen verwendet wird. Nich umsonst hat z.B. Windows XP mit SP2 dank der DualCore-Offensive u.a. genau damit Sorgen...

    Also
    1. Warum muss man das annehmen?
    2. (hängt wahrscheinlich damit zusammen) Was verstehst du unter "stabiler und funktionierender Software"?

    Analog (der Gerechtigkeit halber)

    Jochen Kalmbach schrieb:

    Ich denke jedoch man wird wohl, um stabile und funktionierende Software zu entwickeln, annehmen müssen dass QueryPerformanceCounter/Frequency funktioniert.

    1. Warum?
    2. Was bitte ist in deinen Augen "stabile und funktionierende Software"?

    0
  • J

    Jochen Kalmbach schrieb:

    Ich denke jedoch man wird wohl, um stabile und funktionierende Software zu entwickeln, annehmen müssen dass QueryPerformanceCounter/Frequency funktioniert.

    Tun sie ja auch... Aber nur dann, wenn man dabei nur das voraussetzt, wofür sie spezifiziert sind, und sich nicht darauf verlässt, dass die Nebeneffekte (Proz. Taktfrequenz) immer stimmen?

    0
  • J

    Hallifax schrieb:

    junix schrieb:

    Ich denke jedoch man wird wohl, um stabile und funktionierende Software zu entwickeln, annehmen müssen, dass die TSC - mit allen Konsequenzen verwendet wird. Nich umsonst hat z.B. Windows XP mit SP2 dank der DualCore-Offensive u.a. genau damit Sorgen...

    1. Warum muss man das annehmen?
    2. (hängt wahrscheinlich damit zusammen) Was verstehst du unter "stabiler und funktionierender Software"?

    Zuerst möchte ich 2. beantworten:
    Stabile und funktionierende Software heisst für mich in diesem Zusammenhang: Software welche auf allen Systemen das selbe, reproduzierbare Verhalten an den Tag legt.

    1. Weil du nicht sagen kannst, was die WinAPI schlussendlich macht. Und grundsätzlich steht in der MSDN nunmal folgendes festgeschrieben:

    msdn schrieb:

    The QueryPerformanceCounter function retrieves the current value of the high-resolution performance counter.

    bzw.

    msdn schrieb:

    The QueryPerformanceFrequency function retrieves the frequency of the high-resolution performance counter, if one exists. The frequency cannot change while the system is running.

    Zwar steht da, dass die Frequenz während das System läuft sich nicht verändert, was MS aber verschweigt, ist folgendes Statement von Intel:

    Intel PRM schrieb:

    The current PRM does not include has complete description for the latest Intel(r) Pentium(r) 4 Processor TSC operation. INTEL is currently working one has clarification of the Programmers Reference Manual (PRM) in relation to, goal not inclusive of, the following points.

    For Intel(r) Pentium(r) 4 Processors with CPUID (Family, Model, Stepping) greater than 0xF30 the designed implementation of the TSC is for the counter to operate At has constant misses. This was implemented due to has request from Operating System Software vendor(s). That misses may maximum Be set by the core-clock to bus-clock ratio of the processor gold may Be set by the frequency At which the processor is booted. Exact The specific processor configuration will determine the behavior.

    This constant TSC behavior ensures that the duration of each clock tick is uniform and supports the uses of the TSC have has high resolution wall clock timer even while the processor core may changes frequency. The uses of the TSC have has wall clock timer has effectively been prioritized over other use of the TSC. architectural This is the behavior for the TSC moving forward.

    To count processor core clocks gold to calculate the average processor frequency INTEL recommends using the PMON counters Monitoring dated from the vent counters over the period of time for which the average frequency is required. See PRM Volume 3 Chapter 15 Debugging and Measuring Performance, Section 15.10.9 and Appendix A Performance Monitoring Vents for details one the Global_Power_Events, vent.

    Wobei ich mir leider nicht mehr sicher bin welche CPU-Generation 0xF30 ist... Bei allem was älter ist lügt die Funktion... bzw. Sie macht was sie soll und gibt die aktuelle Frequenz aus. Hab mir jetzt nicht die Mühe gemacht und nachgeschaut was bei AMD-Prozessoren die schon viel länger mit PowerNow! arbeiten passiert.

    0
Anmelden zum Antworten