Timer-Drift-Problem in C++(n Funktions-Aufrufe pro Sekunde)

[Albert (Gast)]

Hallo,

ich benötige für eine Win32-Konsolenanwendung(Visual C++ 2008 Express) 
eine bestimmte Anzahl von Zeitstempeln pro Sekunde. Die Abstände der 
Zeitstempel sollen durch die Angabe von Millisekunden festgelegt werden.

Meine Versuche, dieses Ziel mit einfachen Timern zu lösen, waren bislang 
erfolglos. Sowohl SetTimer als auch WaitableTimer haben offenbar eine 
gewisse Drift, die über kurz oder lang dazu führt, dass immer wieder mal 
ein Zeitstempel zu wenig erzeugt wird.

Ein Beispiel: Ich stelle das Intervall auf 100ms und sollte daher 10 
Zeitstempel pro Sekunde erhalten. Alle paar Sekunden erhalte ich jedoch 
nur 9 Zeitstempel pro Sekunde, da die Drift dazu führt, dass die 
einzelnen Zeitstempel immer wieder mal um ca. 15ms verzögert erscheinen 
und sich dies auch auf die nachfolgenden Zeitstempel auswirkt, so dass 
der 10. Wert dann irgendwann durch den Überlauf bei 999ms zur 
nachfolgenden Sekunde gehört. Stelle ich das Intervall auf 20ms, erhalte 
ich immerhin noch 49 Messungen pro Sekunde. An mangelnder 
Geschwindigkeit meines Systems bzw. dem Code im Timeraufruf kann es 
somit nicht auscchließlich liegen. Bei z.B. 250ms funktioniert das ganze 
wunderbar 4 mal pro Sekunde exakt ohne Drift, obwohl statistisch doch 
auch da irgendwann eine Verzögerung zum Tragen kommen müsste?!?

Mir ist klar, dass Windows kein Echtzeit-Betriebssystem ist und es geht 
mir auch nicht um auf eine Millisekunde genaue Zeitstempel. Ich suche 
vielmehr nach einer einfachen Lösung, um eine Funktion möglichst 
periodisch aufzurufen. Wenn die Millisekunden der einzelnen Zeitstempel 
dann im niedrigen zweistelligen Bereich schwanken, würde mich das nicht 
stören, so lange in jedem von mir festgelegten Millisekunden-Intervall 
genau ein Funktionsaufruf erfolgt.

Wirken sich Verzögerungen bei einem Timeraufruf immer auch auf die 
nachfolgenden Timeraufrufe aus? Oder ist das Programm fehlerhaft?

#include <stdio.h>
#include <tchar.h>
#include <iostream>
#include <Windows.h>
#include <conio.h>

using namespace std;
SYSTEMTIME now;

int _tmain(int argc, _TCHAR* argv[])
{
    int count = 0;

    HANDLE hTimer = NULL; 
    hTimer = CreateWaitableTimer( 
        NULL,
        FALSE, 
        NULL);

    SYSTEMTIME time;
    GetSystemTime(&time);
    time.wSecond += 1; 
    FILETIME ftime;
    SystemTimeToFileTime(&time, &ftime);


    if(!SetWaitableTimer(
        hTimer,
        reinterpret_cast<LARGE_INTEGER*>(&ftime),
        100,
        NULL,
        NULL,
        0))
    {
            cout << "SetWaitableTimer failed" <<  GetLastError() << endl;
    };

    
    while(WaitForSingleObject(hTimer, 5000) == WAIT_OBJECT_0){
  ++count;
      GetSystemTime( &now );
  printf ("%02d.%02d.%02d.%01d",now.wHour, now.wMinute, now.wSecond, now.wMilliseconds);
  printf ("\n");
        if(count+1 > 100){
            break;
        }
    }
        
    CancelWaitableTimer(hTimer);
    CloseHandle(hTimer);
  system("PAUSE");
    return 0;
}

Ich könnte jetzt natürlich einen Timer mit möglichst kurzer 
Periodendauer programmieren, der dann unter Berücksichtigung der 
eigentlich gewünschten Periodendauer ständig prüft, ob er in der 
jeweiligen Periode bereits einen Zeitstempel ausgegeben hat - aber ist 
das wirklich notwendig bzw. kann mir ein Timer nicht genau diese Arbeit 
abnehmen?

Gruß,
Albert

[Reinhard R. (reinhardr)]

Hi,

ich Frage mich ob dein Timer driftet oder ob gelegentlich ein Event 
"verschluckt" wird. Wirf mal einen genauen Blick auf die Zeiten die dir 
dein Programm auswirft. Für einen simplen Test würde ich einfach 
GetTickCount() anstatt GetSystemTime() verwenden und immer die Differenz 
zum vorherigen Schleifendurchlauf ausgeben.

Interessant wird es dann zu sehen, ob die Werte immer >=100ms sind, oder 
ob sie im Zeitmittel bei 100ms mit gelegentlichen Ausreißern von n*100ms 
sind. In einem Histogramm sollte man das relativ gut sehen können, so 
lange der Jitter im Vergleich zur Periodendauer nicht zu groß wird.

Das erste Szenario (immer >= 100ms) würde darauf hindeuten dass der 
Timer zwar 100ms läuft, aber dazu noch diverser Overhead kommt den das 
Betriebssystem nicht berücksichtigt. Das wäre aber imho ein 
Armutszeugnis für einen Timer den man periodisch starten kann.
Ich vermute mal dass du unter Windows schon relativ große Chancen hast 
dass gelegentlich der Prozess nicht zuverlässig alle 100ms zum Zug 
kommt. Du kannst auch versuchen die Priorität deines Prozesses im 
Taskmanager zu erhöhen und möglichst alle ungenützten Programme zu 
beenden.

Gruß,
Reinhard

[Peter II (Gast)]

du könntest auch die Zeit anbragen und den nächsten Zeitpunkt berechnen, 
also nicht immer stur 100ms warten.

[Reinhard R. (reinhardr)]

Ich habe dein Programm geringfügig modifiziert ausprobiert:

  DWORD last_tick = 0, now_tick = 0;
  while(WaitForSingleObject(hTimer, 5000) == WAIT_OBJECT_0)
  {
    now_tick = GetTickCount();
    printf("%d\n", now_tick - last_tick);
    last_tick = now_tick;

    ++count;
    if(count > 1000){
      break;
    }
  }

Der Timer tut eigentlich dass was er soll. Er driftet nicht davon - bei 
1000 Werten war der Mittelwert +/- 10µs vom Sollwert entfernt. Die 
Standardabweichung bewegte sich in der Größenordnung 7ms. Was ich dabei 
interessant fand, war dass es immer nur eine handvoll diskrete Werte gab 
die immer wieder auftauchten, siehe das angehängte Pseudohistogramm 
(x-Achse nicht skaliert!).
Wenn der Timer mal nicht rechtzeitig zum Zug kommt, was bei mir so ab 
25ms der Fall war, läuft er gleich danach noch einmal durch. Im 
Extremfall, mit eingestellten 5ms, sieht die Ausgabe dann in etwa so 
aus:
0
0
16
0
0
15
0

Um auf deine Situation zurückzukommen: Wenn du in einer Sekunde mal nur 
9, statt 10 Zeitstempeln bekommst bedeutet das, dass du in einer anderen 
dafür 11 bekommst. Wenn du Pech hast, bekommst du eine Weile lang gar 
nichts, aber dann dafür eine Menge identischer Zeitstempel.

Wirf mal einen Blick auf die Multimedia Timer von Windows, vielleicht 
helfen die dir ja weiter:
http://msdn.microsoft.com/en-us/library/windows/desktop/dd743609.aspx


Gruß,
Reinhard

[Rufus Τ. F. (rufus)]

Die von Reinhard vorgeschlagenen Multimediatimer sollten weiterhelfen.

Einerseits lässt sich mit denen die Timergranularität des Schedulers von 
den üblichen 10 msec auf eine msec verringern (mit timeBeginPeriod), 
andererseits bieten die auch Funktionen an, in einem definierten Takt 
eine Rückruffunktion aufzurufen (mit timeSetEvent) - und das 
funktioniert erheblich stabiler und zuverlässiger als das, was der 
Threadstarter da schildert.

Auch wenn die Dokumentation timeSetEvent als obsolete bezeichnet, man 
kann sie verwenden.


Worauf Du allerdings achten solltest, ist, daß die aufgerufene 
Rückruffunktion nicht allzuviel Rechenzeit verbraucht. Bedenke auch, daß 
sie in einem anderen Threadkontext läuft als Dein Hauptprogramm.

[Reinhard R. (reinhardr)]

> timeBeginPeriod

Dazu spuckt Google einen interessanten Artikel aus:
http://www.geisswerks.com/ryan/FAQS/timing.html

[Albert (Gast)]

Hallo,

vielen Dank für eure Hilfe erstmal. Von Reinhard inspiriert habe ich 
noch ein paar Tests gemacht. Neben dem Zeitstempel gebe ich noch die 
aktuelle Timer-Runde sowie die zeitliche Differenz zwischen zwei 
Timer-Aufrufen aus:

#include <stdio.h>
#include <tchar.h>
#include <iostream>
#include <Windows.h>
#include <conio.h>

using namespace std;
SYSTEMTIME now;
  DWORD time1, time2;

int _tmain(int argc, _TCHAR* argv[])
{
    int count = 0;

    HANDLE hTimer = NULL; 
    hTimer = CreateWaitableTimer( 
        NULL,
        FALSE, 
        NULL);

    SYSTEMTIME time;
    GetSystemTime(&time);
    FILETIME ftime;
    SystemTimeToFileTime(&time, &ftime);

    if(!SetWaitableTimer(
        hTimer,
        reinterpret_cast<LARGE_INTEGER*>(&ftime),
        100,
        NULL,
        NULL,
        0))
    {
            cout << "SetWaitableTimer failed" <<  GetLastError() << endl;
    };

    time1=GetTickCount();
  time2=time1;

    while(WaitForSingleObject(hTimer, 5000) == WAIT_OBJECT_0){
  ++count;

  
  time2=GetTickCount();
  GetSystemTime( &now );
printf ("%02d.%02d.%02d.%03d - ",now.wHour, now.wMinute, now.wSecond, now.wMilliseconds);
printf ("%03d - %d\n", count, time2-time1);
time1=time2;
if(count+1 > 200){
            break;
        }
    }
        
    CancelWaitableTimer(hTimer);
    CloseHandle(hTimer);
  system("PAUSE");
    return 0;
}

Die folgenden Werte habe ich dann als Ergebnis erhalten:

11.38.42.796 - 001 - 0
11.38.42.890 - 002 - 94
11.38.43.000 - 003 - 109
11.38.43.093 - 004 - 94
11.38.43.203 - 005 - 109
11.38.43.296 - 006 - 94
11.38.43.390 - 007 - 94
11.38.43.500 - 008 - 109
11.38.43.593 - 009 - 94
11.38.43.703 - 010 - 109
11.38.43.796 - 011 - 94
11.38.43.906 - 012 - 109
11.38.44.000 - 013 - 94
11.38.44.093 - 014 - 94
11.38.44.203 - 015 - 109
11.38.44.296 - 016 - 94
11.38.44.406 - 017 - 109
11.38.44.500 - 018 - 94
11.38.44.609 - 019 - 109
11.38.44.703 - 020 - 94
11.38.44.812 - 021 - 110
11.38.44.906 - 022 - 93
11.38.45.000 - 023 - 94
11.38.45.109 - 024 - 109
11.38.45.203 - 025 - 94
11.38.45.312 - 026 - 110
11.38.45.406 - 027 - 93
11.38.45.515 - 028 - 110
11.38.45.609 - 029 - 93
11.38.45.703 - 030 - 94
11.38.45.812 - 031 - 110
11.38.45.906 - 032 - 93
11.38.46.015 - 033 - 110
11.38.46.109 - 034 - 93
11.38.46.218 - 035 - 110
11.38.46.312 - 036 - 94
11.38.46.421 - 037 - 109
11.38.46.515 - 038 - 94
11.38.46.609 - 039 - 93
11.38.46.718 - 040 - 110
11.38.46.812 - 041 - 94
11.38.46.921 - 042 - 109
11.38.47.015 - 043 - 94
11.38.47.125 - 044 - 109
11.38.47.218 - 045 - 94
11.38.47.312 - 046 - 94
11.38.47.421 - 047 - 109
11.38.47.515 - 048 - 94
11.38.47.625 - 049 - 109
11.38.47.718 - 050 - 94
11.38.47.828 - 051 - 109
11.38.47.921 - 052 - 94
11.38.48.031 - 053 - 109
11.38.48.125 - 054 - 94
11.38.48.218 - 055 - 94
11.38.48.328 - 056 - 109
11.38.48.421 - 057 - 94
11.38.48.531 - 058 - 109
11.38.48.625 - 059 - 94
11.38.48.734 - 060 - 109
11.38.48.828 - 061 - 94
11.38.48.921 - 062 - 94
11.38.49.031 - 063 - 109
11.38.49.125 - 064 - 94
11.38.49.234 - 065 - 109
11.38.49.328 - 066 - 94
11.38.49.437 - 067 - 110
11.38.49.531 - 068 - 93
11.38.49.640 - 069 - 110
11.38.49.734 - 070 - 93
11.38.49.828 - 071 - 94
11.38.49.937 - 072 - 110
11.38.50.031 - 073 - 93
11.38.50.140 - 074 - 110
11.38.50.234 - 075 - 93
11.38.50.343 - 076 - 110
11.38.50.437 - 077 - 94
11.38.50.531 - 078 - 93
11.38.50.640 - 079 - 110
11.38.50.734 - 080 - 93
11.38.50.843 - 081 - 110
11.38.50.937 - 082 - 94
11.38.51.046 - 083 - 109
11.38.51.140 - 084 - 94
11.38.51.250 - 085 - 109
11.38.51.343 - 086 - 94
11.38.51.437 - 087 - 94
11.38.51.546 - 088 - 109
11.38.51.640 - 089 - 94
11.38.51.750 - 090 - 109
11.38.51.843 - 091 - 94
11.38.51.953 - 092 - 109
11.38.52.046 - 093 - 94
11.38.52.140 - 094 - 94
11.38.52.250 - 095 - 109
11.38.52.343 - 096 - 94
11.38.52.453 - 097 - 109
11.38.52.546 - 098 - 94
11.38.52.656 - 099 - 109
11.38.52.750 - 100 - 94
11.38.52.859 - 101 - 109
11.38.52.953 - 102 - 94
11.38.53.046 - 103 - 94
11.38.53.156 - 104 - 109
11.38.53.250 - 105 - 94
11.38.53.359 - 106 - 109
11.38.53.453 - 107 - 94
11.38.53.562 - 108 - 110
11.38.53.656 - 109 - 93
11.38.53.750 - 110 - 94
11.38.53.859 - 111 - 109
11.38.53.953 - 112 - 94
11.38.54.062 - 113 - 110
11.38.54.156 - 114 - 93
11.38.54.265 - 115 - 110
11.38.54.359 - 116 - 93
11.38.54.468 - 117 - 110
11.38.54.562 - 118 - 94
11.38.54.656 - 119 - 93
11.38.54.765 - 120 - 110
11.38.54.859 - 121 - 93
11.38.54.968 - 122 - 110
11.38.55.062 - 123 - 94
11.38.55.171 - 124 - 109
11.38.55.265 - 125 - 94
11.38.55.359 - 126 - 93
11.38.55.468 - 127 - 110
11.38.55.562 - 128 - 94
11.38.55.671 - 129 - 109
11.38.55.765 - 130 - 94
11.38.55.875 - 131 - 109
11.38.55.968 - 132 - 94
11.38.56.078 - 133 - 109
11.38.56.171 - 134 - 94
11.38.56.265 - 135 - 94
11.38.56.375 - 136 - 109
11.38.56.468 - 137 - 94
11.38.56.578 - 138 - 109
11.38.56.671 - 139 - 94
11.38.56.781 - 140 - 109
11.38.56.875 - 141 - 94
11.38.56.968 - 142 - 94
11.38.57.078 - 143 - 109
11.38.57.171 - 144 - 94
11.38.57.281 - 145 - 109
11.38.57.375 - 146 - 94
11.38.57.484 - 147 - 109
11.38.57.578 - 148 - 94
11.38.57.687 - 149 - 110
11.38.57.781 - 150 - 93
11.38.57.875 - 151 - 94
11.38.57.984 - 152 - 109
11.38.58.078 - 153 - 94
11.38.58.187 - 154 - 110
11.38.58.281 - 155 - 93
11.38.58.390 - 156 - 110
11.38.58.484 - 157 - 93
11.38.58.578 - 158 - 94
11.38.58.687 - 159 - 110
11.38.58.781 - 160 - 93
11.38.58.890 - 161 - 110
11.38.58.984 - 162 - 93
11.38.59.093 - 163 - 110
11.38.59.187 - 164 - 94
11.38.59.296 - 165 - 109
11.38.59.390 - 166 - 94
11.38.59.484 - 167 - 93
11.38.59.593 - 168 - 110
11.38.59.687 - 169 - 94
11.38.59.796 - 170 - 109
11.38.59.890 - 171 - 94
11.39.00.000 - 172 - 109
11.39.00.093 - 173 - 94
11.39.00.187 - 174 - 94
11.39.00.296 - 175 - 109
11.39.00.390 - 176 - 94
11.39.00.500 - 177 - 109
11.39.00.593 - 178 - 94
11.39.00.703 - 179 - 109
11.39.00.796 - 180 - 94
11.39.00.906 - 181 - 109
11.39.01.000 - 182 - 94
11.39.01.093 - 183 - 94
11.39.01.203 - 184 - 109
11.39.01.296 - 185 - 94
11.39.01.406 - 186 - 109
11.39.01.500 - 187 - 94
11.39.01.609 - 188 - 109
11.39.01.703 - 189 - 94
11.39.01.796 - 190 - 94
11.39.01.906 - 191 - 109
11.39.02.000 - 192 - 94
11.39.02.109 - 193 - 109
11.39.02.203 - 194 - 94
11.39.02.312 - 195 - 110
11.39.02.406 - 196 - 93
11.39.02.515 - 197 - 110
11.39.02.609 - 198 - 93
11.39.02.703 - 199 - 94
11.39.02.812 - 200 - 110

Wenn ich das richtig sehe, driftet mein Timer definitiv: immer wieder 
mal ungefähr +15ms(z.B. in Sekunde 43 und dann wieder in Sekunde 46, 
usw.). In Sekunde 59 führt diese Drift dann zu einem Überlauf bzw. dazu, 
dass nur 9 Zeitstempel angezeigt werden. Was mich jetzt wundert ist, 
dass es bei Dir, Reinhard, anscheinend zu keiner Timer-Drift kommt. 
Könntest Du vielleicht den von mir verwendeten Code auf Deinem Rechner 
testen?

Ich werde mir heute aber auch mal die von euch vorgeschlagenen 
Multimediatimer ansehen.

Gruß,
Albert

[Peter II (Gast)]

@ Albert

hast du eventuell ein AMD DualCore system? Dann die Athlons haben ohne 
das Passen AMD-Tool ein Problem mit dem Timer. Jeder Core hat seinen 
eignen Timer und sie laufen nicht Synchron. Wenn jetzt Windows deinen 
Thread zwischen den Cores verteilt dann kann das durchaus zu diesen 
Problemen kommen. Als abhilfe gibt es von amd den Dualcore optimieren 
oder per software kann man die anwendung fest an einen core binden.

[Albert (Gast)]

Hallo Peter II,

ich habe in der Tat ein AMD Dualcore System(Athlon X2-BE2350). 
Allerdings driftet der Timer auch auf meinem anderen XP-Rechner mit 
Intel T2300 Prozessor.

Viele Grüße,
Albert

[Reinhard R. (reinhardr)]

Hallo Albert,

dein Code funktioniert bei mir so wie er soll ohne Drift, während bei 
dir das offensichtlich der Fall ist. Woher das kommt kann ich nicht 
sagen. Hier läuft ein ein Core2Duo unter W7 x64, kompiliert wurde mit 
VS2010.

Gruß,
Reinhard