Merkwürdigkeit mit Sleep()

[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]

[Uwe Raabe]

Zitat von jfheins:

[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]

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.

[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 von p80286:

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

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 )?

[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.