Merkwürdigkeit mit Sleep()

[Shark99]

Code:

Delphi-Quellcode:

var t1,t2: TDateTime;
begin
    t1 := now;
    Sleep(1000);
    t2 := now;
    ShowMessage('time passed (ms): '+inttostr(round((t2-t1)*100000000)));
end;

Ich habe eigentlich erwartet dass ein Sleep(1000) etwa 1000ms dauert (vielleicht paar ms mehr).

In dem kleinen Beispielcode vergeht jedoch auf meinem System 1160.

Hat jemand eine Erklärung dafür?

Wie kann ich wirklich exakt 1 Sekunde warten?

[hathor]

Mit folgendem Code kannst Du herausfinden, was Dein BS (WIN XP, WIN732, WIN764) auf der vorhandenen Hardware (Solo,Duo) bei Sleep() an Zeit "verbraucht":

Delphi-Quellcode:

procedure TForm1.Button1Click(Sender: TObject);
var a, b, c: Int64; r: real; i: Integer;
begin
For i:=0 to 20 do
BEGIN
  QueryPerformanceFrequency(a);
  QueryPerformanceCounter(b);
  Sleep(i);
  QueryPerformanceCounter(c);
  r:= (c - b) * 1000 / a;
  Memo1.lines.add('Sleep('+IntToStr(i)+') = '+ FloatToStrF(r, ffFixed, 12, 5)+' msec');
  Application.ProcessMessages;
END;
end;

Eine bessere SLEEP-Funktion:

Delphi-Quellcode:

procedure DelayQPC(t: cardinal);
var  a, b: Int64;
Begin
    QueryPerformanceFrequency(b);
    QueryPerformanceCounter(a);
    b := a + (b * t) div 1000;
    While a < b do QueryPerformanceCounter(a);
end;

Aufruf z.B:
DelayQPC(1000);

Test mit DelayQPC:

Delphi-Quellcode:

procedure DelayQPC(t: cardinal);
var a, b: Int64;
Begin
    QueryPerformanceFrequency(b);
    QueryPerformanceCounter(a);
    b := a + (b * t) div 1000; //10000 für 0.1 msec
    While a < b do QueryPerformanceCounter(a);
end;

procedure TForm1.Button1Click(Sender: TObject);
var a, b, c: Int64; r: real; i: Integer;
begin
For i:=1 to 20 do
BEGIN
  QueryPerformanceFrequency(a);
  QueryPerformanceCounter(b);
  DelayQPC(i*100);
  QueryPerformanceCounter(c);
  r:= (c - b) * 1000 / a;
  Memo1.lines.add('Sleep('+IntToStr(i*100)+') = '+ FloatToStrF(r, ffFixed, 12, 5)+' msec');
  Application.ProcessMessages;
END;
end;

[Medium]

Zitat von Shark99:

Wie kann ich wirklich exakt 1 Sekunde warten?

Unter den gängigen Windows Varianten: Garnicht. Diese zeitliche Präzision bieten praktisch nur darauf ausgelegte sog. Echtzeit (Betriebs-)Systeme, und das Thema hatten wir schon gefühlte 100 Mal in der DP .
Ganz im Groben erreicht man auf normalen OSs Genauigkeiten so um +/- 0-30ms, je nach Methode. Wofür musst du derart exakt eine Sekunde haben?

[Shark99]

Ich will ein mal Pro Sekunde den CPU Verbrauch anzeigen. Da Windows kein Echtzeit Betriebssystem ist, habe ich mit einer Abweichung gerechnet, allerdings mit 10ms, nicht 160.

[Shark99]

DelayQPC scheint auf dem ersten Blick eine Alternative zu sein, aber ich glaube es würde mehr CPU Zeit kosten als es ein Sleep tut.

Dazu gibt es noch diese Warnung bei MSDN:

QueryPerformanceCounter remarks

On a multiprocessor computer, it should not matter which processor is called. However, you can get different results on different processors due to bugs in the basic input/output system (BIOS) or the hardware abstraction layer (HAL).

[Medium]

Warum muss das SO exakt sein? Schwankungen von 200ms dürften kaum auffallen, und für gewöhnlich ist CPU-load nicht gerade das, wo man so penibel ist als User. Man schaut max. 3-4 Sekunden hin, bekommt einen gewissen Eindruck, und das langt meist schon. Ob das jetzt perfekt regelmäßig tickt, wäre mir zumindest relativ worscht
Und wie du schon bemerkt hast, legen Methoden die den Mess-Thread nicht schlafen legen, merkbar auf eben den gemessenen Wert drauf. Der Vorteil von Sleep ist, dass man die Verantwortung für's "wecken" an den Scheduler abgibt, und der ist zwar nicht so arg genau, dafür aber sehr ressourcenschonend. Ganz ehrlich: Wenn es bloß für die Anzeige von CPU Load ist, scher dich nicht weiter um die paar ms. So wichtig ist diese Info nicht, als dass man dafür viel Zeit, und schon garnicht merkbar CPU-Time verwenden sollte.

[Shark99]

Ist eigentlich TTimer genauso ungenau, oder sind die Ungenauigkeiten unterschiedlich?

[Medium]

Der Timer basiert auch auf dem Scheduler, und ist in etwa genau so (un-)genau.

[xZise]

Moin,
was ist wenn du Zeit mal anders misst?

Delphi-Quellcode:

var
  start : Cardinal;
begin
  start := GetTickCount;
  Sleep(1000);
  ShowMessage(IntToStr(GetTickCount - start) + ' ms');
end;

Da ein TTime (und damit auch TDateTime) eine Gleitkommazahl ist, kann ich mir gewisse ungenauigkeiten vorstellen, besonders wenn man die ms davon haben möchte.

MfG
Fabian

[jfheins]

*ggg*

Ich habs

Da hat sich jemand nicht informiert, was ein TDateTime ist. Das hat nichts mit den Gleitkomma-ungenauigkeiten zu tun. (Nette idee, aber Präzision double: 15 signifikante Stellen oder so)

Aber der Code    ShowMessage('time passed (ms): '+inttostr(round((t2-t1)*100000000))); rechnet falsch. TDateTime ist in Tagen. d.h. 1/86400 Tage sind eine Sekunde. Um also aus einem Bruchteil von einem Tag Millisekunden zu machen müsstest du mit 86400000 multiplizieren.

Wenn man deine Rechnung korrigiert werden aus den "1160 Millisekunden" übrigens 1002ms

xZise umgeht das Problem, da er direkt GetTickCount() benutzt, welches Millisekunden misst. Das funktioniert natürlich (Zeitmessung mache ich auch immer so), ist aber nicht die Ursache für das Problem.

[OT]
Vielleicht wird ja mal die Dezimalsekunde eingeführt, sodass ein Tag 10 Stunden hat, mit je 100 Minuten und jede Minute 100 Sekunden
[/OT]