Uhrzeit auf die Millisekunde

[Crazymodder]

Perfekt so reichts mir Danke
Ihr seit echt geil

[Jelly]

In der SDK hab ich folgende nützliche Funktion gefunden:

Zitat von SDK:

High-Resolution Timer

A counter is a general term used in programming to refer to an incrementing variable. Some systems include a high-resolution performance counter that provides high-resolution elapsed times.


If a high-resolution performance counter exists on the system, the QueryPerformanceFrequency function can be used to express the frequency, in counts per second. The value of the count is processor dependent. On some processors, for example, the count might be the cycle rate of the processor clock.

The QueryPerformanceCounter function retrieves the current value of the high-resolution performance counter. By calling this function at the beginning and end of a section of code, an application essentially uses the counter as a high-resolution timer. For example, suppose that QueryPerformanceFrequency indicates that the frequency of the high-resolution performance counter is 50,000 counts per second. If the application calls QueryPerformanceCounter immediately before and immediately after the section of code to be timed, the counter values might be 1500 counts and 3500 counts, respectively. These values would indicate that .04 seconds (2000 counts) elapsed while the code executed.

QueryPerformanceFrequency gibt die Frequenz an, mit der ein Counter (QueryPerformanceCounter) hochgezählt wird. Die Frequenz f ist prozessorabhängig, und 1/f gibt die Genauigkeit an. Auf meinem System ist f z.B. 3579545, und ich hab somit eine maximale Genauigkeit von 279 ns.
Mit QueryPerformanceCounter liest du den aktuellen Wert aus. Die Differenz von 2 Aufrufen gibt dir die Anzahl der Ticks an. Diesen Werte geteilt durch die Frequenz gibt dir die Differenz in Sekunden aus.

[QuickAndDirty]

Guter Beitrag Jelly.
Das habe ich bis jetzt noch nicht gewust.
Dieser Counter wird nicht von irgendwelchen Stromspar modi beeinflusst?

[Jelly]

Zitat von QuickAndDirty:

Dieser Counter wird nicht von irgendwelchen Stromspar modi beeinflusst?

Das weiss ich nicht. Aber sollte dem so sein, so müsste doch der über QueryPerformanceFrequency ermittelte Wert sich ändern, oder?

[Sidorion]

Die Funktion NOW ist auf die Millisekunde genau (da sie intern (BS) auch mit GetTickcount usw hantiert), manche Werte lassen sich aber nicht darstellen.
Zur Erklärung: TDateTime ist im Prinzip ein einfacher Double-Wert, in dessen Ganzzahlteil die Tage seit Wasweisichwann dargestellt werden, im Nachkommateil die Millisekunden seit 0 Uhr. Eine ms ist sozusagen ein 86400000stel eines Tages, also 1,157407407...*10^-8.
Da eine ms schon einen periodischen Dezimalbruch darstellt, ist die Warscheinlchkeit sehr hoch, dass auch ein vielfaches davon periodisch (auf Basis 10). Dieser Wert muss zudem binär dargestellt werden (Basis 2), was die Stelligkeit stark erhöht.
Da nun bestimmte Millisekunden den Darstellungsbereich(Genauigkeit) eines Doubles sprengen muss gegebenenfalls gerundet (Basis 2) werden. Diesen gerundeten Wert kann man dann aber halt nur mit einem Fehler zurückwandeln.
Es ist also nicht die Funktion ungenau, sondern das Ergebnis, was aber im Prinzip auf das Gleiche rauskommt.

[Hawkeye219]

Hallo,

Zitat von Jelly:

GetTickCount hingegen ist auf die msec genau.

Wir sollten hier besser von "Auflösung" sprechen, denn Genauigkeit <> Genauigkeit.

Gruß Hawkeye

[Jelly]

Ja. Deshalb hab ich anschliessend nochmal GetPerformanceFrequency und GetPerformanceCounter aufgeführt.

[QuickAndDirty]

das Basisdatum in delphi ist der 30.12.1899 00:00
Vor dem Komma sind ganze tage nach dem Komme sind Stunden,Minuten, Sekunden udn angebliche "Millisekunden"
um Rundungsfehler zu minimieren.
Da Fließkomma zahlen mit zunehmendem Betrag ungenauer (schlechter aufgelöste nachkommastellen )werden kann das wirklich auch
die Darstellung ein probelem sein.

[WS1976]

Hallo Siderion,

ich muss dir leider widersprechen und zwar heftig.
Now und alle damit zusammenhängenden Datum-Uhrzeitquellen hängen am Timertick Interrupt.
Dieser wird alle ca 55ms ausgelöst. Dmentsprechend wird der Wert von now erhöht.
Die Genauigkeit der Zeitmessung hat also überhaupt nichts mit der mathematischen Auflösung
und deren Problematik zu tun, sonder hängt einfach damit zusammen, dass nur ca alle 55msec gezählt
wird. Die Auflösung ist damit beschränkt.
Etwas anders stellt sich die Sache mit QueryPerformanceFrequency dar. Da diese Funktion jedoch nicht auf jedem System zur Verfügung steht kann man sie getrost vergessen.

Grüsse

[TStringlist]

Hm, der Umfragesteller sprach ja auch nur vom Auslesen einer Uhrzeit, nicht aber von irgendwelchen Stoppzeiten o. Zeitdifferenzen. Das wäre natürlich schon etwas anderes gewesen ...und das dann vieldiskutierte NOW wäre in der Truhe geblieben

Und von daher: Wenn es dem Threadmaker aber tatsächlich nur um eine solche normale Uhrzeit ging (was ja vllt. nicht unbedingt so sein muss), dann wäre natürlich auch die Nutzung von "QueryPerformanceCounter" nur relativ. Denn dann bliebe ihm immer noch das Problem, wo er eine exakte Anfangszeit herbekommt, welche dann nämlich ebenfalls auf die Millisekunde genau zu sein hätte. Selbst wenn er die Atomzeit aus dem Internet abfragen würde, könnte er wohl nicht sicher sein, dass da nicht auch noch einige Millisekunden Übermittlungsverzögerung mit drin sind.


@WS1976

55ms, vielleicht früher mal? Heute scheinen es jedenfalls eher Perioden a 16ms zu sein.

@Jelly: "GetTickCount hingegen ist auf die msec genau.“

Das Result von GetTickCount ändert sich übrigens auch nur alle 16 Millisekunden!