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?

[Luckie]

Zitat von 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.

Weißt du wie lange 160 Millisekunen sind? Ein menschlicher Wimpernschlag dauert ca. 100 Millisekunden (laut Wikipedia). Und jetzt überleg noch mal, ob du die CPU-Auslastung wirklich so genau anzeigen können musst.

Eine Zeitscheibe unter Windows NT hat eine länge von 22 Millisekunden. das heißt ein Thread bekommt für 22 Sekunden Rechenzeit zugeteilt. Dann wird zum nächsten Thread, abhängig von der Priorität gewechselt. Gibts du bei Sleep einen Wert unter 22 Millisekunden an, gibt der Thread den Rest seiner Zeitscheibe sofort ab und kehrt in den zuteilungsfähigen Zustand zurück und kann, wenn er wieder dran ist Rechnzeit zugeteilt bekommen.

[jfheins]

Zitat von Luckie:

Zitat von 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.

Weißt du wie lange 160 Millisekunen sind? Ein menschlicher Wimpernschlag dauert ca. 100 Millisekunden (laut Wikipedia). Und jetzt überleg noch mal, ob du die CPU-Auslastung wirklich so genau anzeigen können musst.
Eine Zeitscheibe unter Windows NT hat eine länge von 22 Millisekunden.

Wie sinnvoll das ist, ist irrelevant. Wenn das System mit einer Genauigkeit von 20ms arbeitet, dann möchte man diese Genauigkeit auch gerne bekommen. Das ist ja nichts anderes als wenn eine Waage mit "Fehler: +- 20g" beworben wird,du tust ein 1kg Stück drauf und bekommst 1,16kg angezeigt. Da würdest du dich auch wundern
Aber wie gesagt, die Abweichung liegt nicht an Windows sondern am Fehler in der Rechnung - OSI Layer 8 Problem

[Luckie]

Nein, die Zeitscheibe ist nur 22 Millisekunden lang. Wann dein Thread wieder Rechenzeit bekommt, hängt vom Scheduler ab, wie viele andere Threads laufen und mit welcher Priorität. Hast du im System einen Thread mit der höchsten Priorität (Zeitkritisch), kannst du dich mit deinem Programm dumm und dämlich warten.