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:

Zitat von Shark99 (Beitrag 1040636)

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 :mrgreen:

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

Delphi-Quellcode:

   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 :stupid:
[/OT]

[Uwe Raabe]

Zitat:

Zitat von jfheins (Beitrag 1040678)

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

Gibt's schon: Industrieminute

Ich hatte mal mit sowas zu tun. Du glaubst gar nicht, wie lange man in so einem Fall mit Leuten über Zeiten diskutieren kann ohne hinterher zu einem Konsens zu kommen.

[Luckie]

Zitat:

Zitat von Shark99 (Beitrag 1040640)

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:

Zitat von Luckie (Beitrag 1040692)

Zitat:

Zitat von Shark99 (Beitrag 1040640)

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.

[himitsu]

was man machen kann, das ist, solange die Operation kürzer ist, als die "Zeitscheibe", bzw. zusammenhängende Rechenzeit, welche einem Windows im Moment gewährt:

Delphi-Quellcode:

Sleep(0);
MachWas;

Wenn MachWas nun also weniger Zeit benötigt, als die oftmals vorliegenden 22 ms, dann wird es mit sehr hoher Wahrscheinlichkeit zusammenhängend ausgeführt.

Sleep 0 gibt die Rechenzeit an Andere Programme ab und fast sofort, wenn das eigene Programm wieder dran, beginnt die Abarbeitung von MachWas, welches somit fast die volle Zeit zur Verfügung hat.

Ohne das Sleep könnte es ja sein, daß das Programm schon fast seine komplette Zeiteinheit aufgebracht hat, MachWas kurz vorm Ende gestartet wird und somit mitten in MachWas Windows die Kontrolle an einen anderen Thread/Programm abgibt.

[p80286]

War Da nicht vor einiger Zeit ein thread in dem Tickcount für solche Messungen als untauglich bewertet wurde?

Da ich's nicht brauche habe ich die Alternative vergessen.
Aber wie schon oben erwähnt MUSS es so genau sein?

Gruß
K-H

[himitsu]

GetTickCount arbeitet aktuell mit einem ~16 ms-Intervall.
> z.B. QueryPerformanceCounter

[hathor]

AVERAGE RESOLUTION - bei WIN XP ca. 15.620 msec, bei meinem WIN 7 64Bit: 1 msec!
Kann jemand was dazu schreiben?
Was kann man damit anfangen? Der Wert ist sehr CPU-Last-abhängig.

Delphi-Quellcode:

unit Unit1;

interface

uses
  Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
  Dialogs, ExtCtrls, StdCtrls;

CONST
  Floating = 255;

type msecs = real;

type
  TForm1 = class(TForm)
    Label1: TLabel;
    Timer1: TTimer;
    procedure Timer1Timer(Sender: TObject);
  private
    { Private-Deklarationen }
  public
    { Public-Deklarationen }
  end;

var
  Form1: TForm1;

implementation

{$R *.dfm}

function Strip(L,C:char;Str:string):string;
{L is left,center,right,all,ends}
var I :  byte;
begin
   Case Upcase(L) of
   'L' : begin       {Left}
            while (Str[1] = C) and (length(Str) > 0) do
               Delete(Str,1,1);
         end;
   'R' : begin       {Right}
            while (Str[length(Str)] = C) and (length(Str) > 0) do
               Delete(Str,length(Str),1);
         end;
   'B' : begin       {Both left and right}
            while (Str[1] = C) and (length(Str) > 0) do
               Delete(Str,1,1);
            while (Str[length(Str)] = C) and (length(Str) > 0)  do
               Delete(Str,length(Str),1);
         end;
   'A' : begin       {All}
            I := 1;
            repeat
               if (Str[I] = C) and (length(Str) > 0) then
                  Delete(Str,I,1)
               else
                  I := succ(I);
            until (I > length(Str)) or (Str = '');
         end;
   end;
   Strip := Str;
end;  {Strip}

function RealToStr(Number:extended;Decimals:byte):string;
var Temp : string;
begin
   Str(Number:20:Decimals,Temp);
   repeat
        if copy(Temp,1,1) = ' ' then delete(Temp,1,1);
   until copy(temp,1,1) <> ' ';
   if Decimals = Floating then
   begin
      Temp := Strip('R','0',Temp);
      if Temp[Length(temp)] = '.' then
         Delete(temp,Length(temp),1);
   end;
   RealToStr := Temp;
end; {RealToStr}

function resolution: msecs;
var t0 : tdatetime;
begin
    t0 := now;
    while now = t0 do ;
    result := msecsperday * (now -t0);
end;


function avgres : real;
var j : integer;
begin
    result := 0;
    for j := 1 to 100 do
       result := result + resolution;
    result := result /100;
end;

procedure TForm1.Timer1Timer(Sender: TObject);
begin
 Label1.Caption:=' Average resolution = '+ RealToStr(avgres,3)+' msec'; //15.620 msec
end;

end.

[xZise]

Zitat:

Zitat von p80286 (Beitrag 1040813)

War Da nicht vor einiger Zeit ein thread in dem Tickcount für solche Messungen als untauglich bewertet wurde?[...]

Es ist nicht super genau, aber es gibt ein relativ gutes Ergebnis für den Aufwand. Wenn man mal eben was testen will, ist der PerformanceCounter schon wesentlich komplexer. Abgesehen davon wurde der ja auch schon genannt.

Und zu den ungenauen Zahlen: Ist es nicht so, dass ein Extended nicht alle Zahlen darstellen kann? Es also zwingenderweise "Sprünge" geben muss? Es kann natürlich sein, dass diese Sprünge < 1 ms sind, aber trotzdem finde ich, den Umgang mit Ganzzahlen angenehmer :P

MfG
Fabian

PS: Gibts nicht sowas wie "SecondsBetween". Das durch Tausend und man dürfte das richtige Ergebnis bekommen, oder (egal ob Industrieminute oder nicht :D )?

[Medium]

Die Genauigkeit der Zeitdarstellungen ist bei weitem gut genug. Das "Problem" ist einfach, dass der Windows Scheduler CPU Zeit an die Prozesse verteilt, und jedem Prozess ein Minimum an Zeit gewährt, die sog. kleinst mögliche Zeitscheibe. Die ist unter verscheidenen OSs unterschiedlich, aber die Essenz ist die selbe: Es ist NIEMALS gesichert, dass dein Prozess nach exakt N Millisekunden wieder an die Reihe kommt. Derartige Zusagen treffen, wie gesagt, nur Echtzeit-Betriebssysteme.

Man kann sich drehen und wenden wie man will, man wird in der "Consumer"-Windowswelt immer damit rechnen müssen, keine millisekundengenauen Scheibchen zu bekommen. Das kann per Zufall mal sein, aber damit rechnen darf ich einfach nicht. Egal mit welcher Methode. End of story.

[jfheins]

Leute ich will ja nicht rechthaberisch sein, aber ihr diskutiert jetzt schon seit ein paar Posts über ein Thema das zwar entfernt etwas mit der Ursprungsfrage zu tun hat, aber total überflüssig ist.

Der Threadersteller wollte eine Sekunde stoppen. Hat das versucht und 1160ms herausbekommen weil er aus Versehen bei der Anzeige 16% auf den eigentlichen Wert draufgeschlagen hat.

Dass GetTickCount() immer noch eine Ungenauigkeit von 10-20ms hat, ist zwar richtig - hat aber mit dem Ursprungsproblem nichts zu tun.

[Medium]

Du hast zwar prinzipiell Recht, jedoch ist das Ursprungsproblem durchaus durch die Kombination beider Ursachen zu erklären, bzw. reicht die Korrektur der Rechnung allein nicht aus, um zum vom TE erklärten Ziel zu gelangen. Da finde ich es schon sinnvoll das so weit zu tragen, damit sich der TE nachher nicht wundert, warum diese eine Maßnahme dennoch nicht alles prima macht. Jede Wette wir würden das sonst in spätestens 1-2 Tagen in einem neuen Tread genau so tun :D

[Shark99]

Fand die zusätzlichen Erklärungen sehr interessant, danke!

[HHennig]

Vielleicht helfen dir folgende, wohl undokumentiere API-Funktionen weiter (bisher in keiner Delphi-Unit deklariert):

Code:

function NTQueryTimerResolution(CoarsestResolution : PULONG;
                                FinestResolution   : PULONG;
                                ActualResolution   : PULONG) : longint; stdcall; external 'ntdll.dll';

function NTSetTimerResolution(RequestedResolution : ULong;
                              Set_: Boolean;
                              ActualResolution : PULONG) : longint; stdcall; external 'ntdll.dll';



procedure SetTimerResolutionFinest;
var
  CoarsestResolution:  ULONG;
  FinestResolution:    ULONG;
  ActualResolution:    ULONG;
  RequestedResolution: ULONG;
begin
  NtQueryTimerResolution(@CoarsestResolution, @FinestResolution, @ActualResolution);
  RequestedResolution := FinestResolution;
  NtSetTimerResolution(RequestedResolution, True, @ActualResolution);
end;

procedure SetTimerResolutionDefault;
var
  CoarsestResolution:  ULONG;
  FinestResolution:    ULONG;
  ActualResolution:    ULONG;
  RequestedResolution: ULONG;
begin
  NtQueryTimerResolution(@CoarsestResolution, @FinestResolution, @ActualResolution);
  RequestedResolution := CoarsestResolution;
  NtSetTimerResolution(RequestedResolution, True, @ActualResolution);
end;

begin
  // maximale Resolution setzen
  SetTimerResolutionFinest;

  // make your job...

  // Timer wieder zurücksetzen !
  SetTimerResolutionDefault;
end;

Es sollte damit tatsächlich (evtl. annähernd) Sleep(1) = 1ms sein!

[himitsu]

Wer windows-interne und vorallem undokumentierte APIs verwendet sollte aufpassen, denn diese NtXXX-Funktionen könnten sich auch mal von Windows-Version zu Windows-Version verändern.

PS: Auch Lazarus und der andere C++-Zeugs haben solche undokumentierten APIs bestimmt auch nicht standardmäßig drin.

PPS: Was solch ein Ändern in anderen Prozessen und im System anstellen kann, ist auch noch unbestimmt ... wer weiß was durch sowas nicht mehr richtig funktioniert.
Wenn man Pech hat, dann arbeitet dieser Befehl systemweit.

Abgesehn davon sollten die 1ms nicht wirklich ständig eingehalten werden, da jeder Thread nur ein gewisses Zeitfenster in den CPUs bekommt und dieses ist länger als 1ms, in welcher Zeit andere Prozesse arbeiten dürfen.
(es sei denn dieses verstellt auch noch die Prozesssteuerung vom Windows, welches noch mehr Probleme bereiten könnte)

[HHennig]

Zitat:

Wenn man Pech hat, dann arbeitet dieser Befehl systemweit.

Das ist richtig, es wirkt sich systemweit aus.
Und es ist ebenfalls richtig, die Sache mit Vorsicht anzugehen, also nur genau da wo und genau so lange wie erforderlich mit dem 'getunten' Timer zu arbeiten.

Wir haben bisher keine negativen Auswirkungen auf sonstige Windows-Komponenten feststellen können, während der Laufzeit mit FinestResolution.
Der Erfolg kann aber durchaus situations- bzw. systemumgebungsabhängig sein (was für ein Wort!); wir hatten den Fall, dass zwei Programme das gleiche Funktionsmodul verwendeten, in dem die Timer-Resolution angepasst wurde. Eines der Programme läuft bisher immer noch sehr gut, das andere wollte plötzlich nicht mehr, bis diese Modifikation zurücjgenommen wurde...

Also ganz klar: selbst testen und beobachten (und wenn's geht, freuen :wink:)