2010-09-07 4 views
25

Leute, in meiner Anwendung verwende ich clock_gettime(CLOCK_MONOTONIC), um die Delta-Zeit zwischen den Bildern (ein typischer Ansatz in gamedev) und von Zeit zu Zeit bin ich mit Blick auf eine seltsame zu messen Verhalten von clock_gettime(..) - zurückgegebene Werte sind gelegentlich nicht monoton (dh prev. Zeit ist größer als aktuelle Zeit).Linux clock_gettime (CLOCK_MONOTONIC) seltsame nicht-monotones Verhalten

Derzeit, wenn ein solches Paradoxon passiert, überspringe ich einfach den aktuellen Frame und beginne mit der Verarbeitung des nächsten.

Die Frage ist, wie kann das überhaupt möglich sein? Ist es ein Fehler in der Linux-POSIX-Implementierung von clock_gettime? Ich benutze Ubuntu Server Edition 10.04 (Kernel 2.6.32-24, x86_64), gcc-4.4.3.

+0

Betreiben Sie es zufällig in einer virtualisierten Umgebung? – caf

+0

Nein, keine Virtualisierung – pachanga

Antwort

22

man clock_gettime sagt:

CLOCK_MONOTONIC_RAW (seit Linux 2.6.28; Linux-spezifisch)

Ähnlich CLOCK_MONOTONIC, sondern bietet Zugriff auf eine reine Hardware-basierte Zeit, die nicht unterworfen ist NTP-Anpassungen.

Da CLOCK_MONOTONIC_RAW ist nicht Gegenstand von NTP Anpassungen, ich denke CLOCK_MONOTONIC sein könnte.

Wir hatten ähnliche Probleme mit Redhat Enterprise 5.0 mit 2.6.18 Kernel und einigen spezifischen Itanium-Prozessor. Wir konnten es nicht mit anderen Prozessoren auf dem gleichen Betriebssystem reproduzieren. Es wurde in RHEL 5.3 mit etwas neueren Kernel und einigen Redhat Patches behoben.

+0

Danke für den Tipp. Eine weitere Lektion für mich - niemals absolut vertrauen sogar die zuverlässigsten Bibliotheken :) – pachanga

+0

Interessant. Aber laut http://markmail.org/thread/54bb663vi47kjxnu soll sogar CLOCK_MONOTONIC nicht springen können. Also sollte es nicht immer mindestens zunehmen? – Thomas

+0

Es sagt, die Uhr kann schwenken (kann rückwärts IIUC gehen), so könnte es sinken. –

6

Versuchen Sie CLOCK_MONOTONIC_RAW.

4

Sicher klingt wie ein Fehler für mich. Vielleicht sollten Sie es in Ubuntu's bug tracker melden.

+5

Bug-Tracker sind nett, und so Bugs einzureichen (was jeder tun sollte), aber sie sind unpopulär, weil Programmierer JETZT Korrekturen wünschen. Im Allgemeinen werden Upstream-Fehler erst lange nach der Programmierung des Großteils eines Projekts behoben, und Sie müssen Personen unterstützen, die die Upstream-Bibliotheken ohnehin nicht für längere Zeit aktualisiert haben. :( –

+0

So traurig, so wahr ... – pachanga

21

Sieht aus wie eine Instanz von

commit 0696b711e4be45fa104c12329f617beb29c03f78 
Author: Lin Ming <[email protected]> 
Date: Tue Nov 17 13:49:50 2009 +0800 

timekeeping: Fix clock_gettime vsyscall time warp 

Since commit 0a544198 "timekeeping: Move NTP adjusted clock 
multiplier to struct timekeeper" the clock multiplier of vsyscall is updated with 
the unmodified clock multiplier of the clock source and not with the 
NTP adjusted multiplier of the timekeeper. 

This causes user space observerable time warps: 
new CLOCK-warp maximum: 120 nsecs, 00000025c337c537 -> 00000025c337c4bf 

Siehe here für einen Patch. Dies wurde in 2.6.32.19 aufgenommen, wurde aber möglicherweise nicht vom Debian-Team (?) Rückportiert. Sie sollten es überprüfen.

-1

Es ist ein Linux-Fehler. Keine Anpassung in einer monotonen Uhr kann es rückwärts gehen lassen. Sie verwenden einen sehr alten Kernel und eine sehr alte Distribution.

Edit: Sind Sie sicher, dass Sie den Rahmen überspringen müssen? Wenn Sie clock_gettime erneut aufrufen, was passiert?