Wie hoch ist die Genauigkeit von now?

[RSE]

Hallo!

Liefert die Funktion "now" die Zeit betriebssystemunabhängig in Millisekundengenauigkeit?

[Euklid]

Liefert die Funktion "now" die Zeit betriebssystemunabhängig in Millisekundengenauigkeit?

Bei Now bin ich mir nicht sicher. Ev. steht was in der Pascal-Referenz?

Wenn es dir weiter hilft: Die Funktion "Gettickcount" misst die Zeit ganz sicher systemunabhängig im Millisekundenbereich.

Viele Grüße, Euklid

[RSE]

Das hilft, thx!

[marcov]

Hallo!

Liefert die Funktion "now" die Zeit betriebssystemunabhängig in Millisekundengenauigkeit?

Systemabhaengig. Auf Windows NT basierte windowses etwa 1ms, auf win98 1/18.2 s. Auf Unix: weiss ich nicht, und eben dann, machine (architectur) abhaengig.

gettickcount is NT specifisch

[RSE]

Das heißt, dass es keine sichere und systemunabhängige Methode gibt, die Zeit auf Millisekunden genau zu messen? Ich könnte das für meinen Mediaplayer echt gut gebrauchen.

[marcov]

Das heißt, dass es keine sichere und systemunabhängige Methode gibt, die Zeit auf Millisekunden genau zu messen? Ich könnte das für meinen Mediaplayer echt gut gebrauchen.

Nein. Genauigkeit und Resolution sind oft auch Teuer, so das es nicht eine universelle definition gibt, und das ist warum wir das nicht mal versuchen zu unterstuetzen. Multicore und CPU/chipset Throttling wird das in zukunft noch schwieriger machen.

[RSE]

Das finde ich sehr unschön. Gerade im Medienbereich wäre es doch sehr hilfreich. So bleiben mir nur die Funktionen, die das Medienframework (unter Win DirectShow) zur Verfügung stellt. Ich hatte gehofft, im Player selbst im millisekundenbereich zeitabhängige Funktionalität hinzufügen zu können.

[monta]

Aus Interesse, ich hab von Mediaplayern keine Ahnung, aber wo kommt es da auf 1ms an?

[Christian]

Ich bin der überzeugung die unix timer und auch die date funktion sind immer millisekundengenau. Unter windows ist GetTickCount millisekundengenau. Die Lazarus GetTickCount basiert auf unixen auf Now so das diese immer Millisekundengenau ist. Höhere Genauigkeit ist allerdings sehr schwer zu erreichen.

[marcov]

Das finde ich sehr unschön. Gerade im Medienbereich wäre es doch sehr hilfreich.

Aber Medien (und ihre APIs) sind schon nicht Plattformunabhängig. Man soll ohnehin dieselbe Timing (resolution, Kalkulations verfahren) als die Codec frameworks (Gstreamer, DirectShow) nutzen.
Das ms Timing vernuenftig functioniert mit DirectShow ist logisch, ist auch meistens NT abhaengig. Vielleicht functioniert Gstreamer erst nicht mit ms.

So bleiben mir nur die Funktionen, die das Medienframework (unter Win DirectShow) zur Verfügung stellt. Ich hatte gehofft, im Player selbst im millisekundenbereich zeitabhängige Funktionalität hinzufügen zu können.

Die vernünftige Loesung konnte sein um Timing zu abstrahieren nach Plattform und/oder backend. (zb es kann anders sein auf dasselbe Plattform wenn man ein ander backend nutzt. Und Phonon kommt auch nach Windows)

[marcov]

Ich bin der überzeugung die unix timer und auch die date funktion sind immer millisekundengenau. Unter windows ist GetTickCount millisekundengenau. Die Lazarus GetTickCount basiert auf unixen auf Now so das diese immer Millisekundengenau ist. Höhere Genauigkeit ist allerdings sehr schwer zu erreichen.

Aus der FreeBSD Gettimeofday (now() primitive on Unix) manpage:

The resolution of the system clock is hardware dependent,

Das ist auch logisch, weil das vom hardware Uhr resolution abhaengt. Etwas anders ist zu Teuer.

Und die PC hardware Uhr ist programmierbar, und hat oft eine feste Verhaeltniss zum Scheduler clock. Es kontte zb anders sein auf realtime Linux distributionen.

[RSE]

Momentan stütze ich mich für die Wiedergabe komplett auf DirectShow. Die einzige Stelle, an der es mich momentan schon interessiert ist die Geschwindigkeitsmessung für die Wiedergabe. Wenn die ein bisschen langsamer reagiert ist es wenig kritisch. Etwas Zeitkritischer ist da die Überwachung vom Progress. DShow sendet bei Audiodateien sehr oft eine Progress-Message. Bei jeder dieser Progress-Messages, überprüfe ich, ob auch der Progress-Counter der Mediendatei einen Fortschritt zeigt. Wenn nicht, dann schmeiße ich sie aus meiner Playliste. Das sollte nicht erst im Sekundenbereich erkannt werden. Ich hatte überlegt an dieser Stelle eine Zeitmessung einzubauen anstatt einer Zählung der Progress-Events ohne Progress im Medium. Diese Zeitmessung müsste natürlich auch entsprechend genau sein.

Später könnte es noch zeitkritischer werden (das weiß ich aber noch nicht sicher), falls ich aktiv in den Progress eingreifen will. Im PAL-Bereich dominieren Framerates von 25fps, bei NTSC dominiert 23,976fps, Film hat 24fps. Die Computerdisplays laufen im Normalfall aber mit 60Hz. Da könnte ein aktiver Eingriff zu einer besseren Bildqualität führen, speziell bei 25fps-Medien. Nur als Szenario, ob ich so etwas implementiere ist noch sehr ungewiss.

[mschnell]

Auf Unix: weiss ich nicht, und eben dann, machine (architectur) abhaengig.

AFAIK, System- und arch- abhängig und (natürlich) beim Erstellen der Kernels konfigurierbar.

AFAIK: Bei PC-Linux früher 10 mSek und heute 1 mSek.

-Michael