Dualcore-Nutzer mit GNU/Linux bitte aufgepasst!

Also, unter GNU/Linux (und uebrigens auch ungepatchten Windows-Systemen) gibt es auf Systemen mit Dualcore-CPUs (zumindest von AMD, Intel weisz ich nicht) das Problem, dass wenn der Kernel den TSC der CPU(s) als Timesource nutzt, die Uhrzeit "springt". Das ist angeblich seit 2.6.14 gefixed, ich kann aber tw. immer noch Spruenge (nicht mehr im Bereich von Stunden in die Vergangenheit und/oder Zukunft, aber trotzdem ein paar Millisekunden) beobachten. Um dem auf den Grund zu gehen wuerde ich hiermit gerne alle Dualcore-User unter GNU/Linux dazu auffordern, mit diesem Script hier:

http://gnulords.org/~colo/src/tsccheck.sh ( http://gnulords.org/~colo/src/tsccheck.sh.asc )

zu ueberpruefen, ob das auf ihrem System auch passiert. In jedem Fall (also egal ob eure Uhr wie gewohnt funktioniert, oder tatsaechlich springt, was der Scriptoutput euch dann wissen laesst) waere es interessant, folgende Daten zu sammeln:

• CPU
• Mainboard(revision) + Biosversion + aktivierte ACPI-Revision
• dmesg-Ringbuffer-Output (insb. Timing-Source)
• Kernel-Config (gzcat /proc/config.gz (wenn Support dafuer im Kernel aktiviert, sonst in /boot/ oder /usr/src/linux/))
• Kernel-Kommandozeile (cat /proc/cmdline)
• Kernel-Version (uname -a)

Danke im Voraus fuer eure Mitarbeit

pit als Timesource ist ziemlich ungenau - ich hab damit Drifts (allerdings nur in eine Richtung, nicht willkuerlich wie zu 2.6.13-Zeiten mit tsc als Timesource) von bis zu 10 Sekunden pro Stunde. Das koennte man zwar mittels ntp korrigieren, ich haette aber trotzdem auch gerne ohne Netzwerk eine vertretbar genaue Zeitangabe.

ein paar sekunden pro woche dürfte zwar nicht *da bomb* sein, aber irgendwo noch im sinnvollen rahmen, wenn du bedenkst daß die woche ~ 0,5 10^6s hat.