Genaue Systemuhr ohne ntp?

[Ulidor]

Unter Lenny hatte ich dank ntpdate immer eine sehr genaue Systemzeit. Nun unter Wheezy möchte ich - einfach so als Tick von mir - eine genaue Systemzeit ohne Zugriff auf externe Dienste hinbekommen.

Ist das bei einem PC, der pro Tag nur zwischen wenigen Minuten und wenigen Stunden eingeschaltet ist, überhaupt möglich?
Standardmäßig wird ja bei jedem Herunterfahren die Systemuhr in die HW-Uhr geschrieben und dabei /etc/adjtime neu geschrieben.

Ich hatte Wheezy vor ca. 100 Tagen installiert. Die Abweichung hatte sich in der Zeit schon auf 40 Sekunden addiert.

[Cae]

Naja, du kannst dir eine Atomuhr hinstellen, mehrere lokale Rechner zu einem lokalen NTP-Pool zusammenbauen oder etwas in der Richtung. Im Prinzip könnte man bestimmen, wie stark die Standardabweichung ist und entsprechend nachregeln. Nur kann die Toleranz der Uhr von der Systemlast, der entstehenden Wärme, der Windrichtung, vom Luftdruck oder vom Wasserstand in der Kaffeemaschine abhängen. Mit ein paar Rechnern im lokalen Pool sollten sich aber schon deutlich bessere Werte als bei der Einzelmaschine erreichen lassen.

Gruß Cae

[yeti]

Naja, du kannst dir eine Atomuhr hinstellen, (((...)))

...oder einfacher einen DCF77-Empfänger...

...oder einen GPS-Empfänger... der empfängt auch die Zeit und ein günstig ergatterter GPS-Empfänger (mit Bluetooth- oder USB-Anschluß) ist oft billiger als DCF77-Uhren mit Druckerport-, USB- oder RS232-Anschluß...

[Alternativende]

Hmh ja wir haben hier auch eine GPS Uhr im Einsatz, allerdings sind die Dinger nicht ganz billig.

[Meillo]

[...] eine genaue Systemzeit ohne Zugriff auf externe Dienste hinbekommen.

Wie du anhand der anderen Beitraege erkennen kannst ist das nicht moeglich. Wenn deine Uhr selbst nicht genau genug ist, wovon auszugehen ist, dann musst sie sie zwangslaeufig irgendwie abgleichen. Ob das ueber NTP oder GPS oder sonstwie passiert ist ja letztlich kein grosser Unterschied. In jedem Fall nimmst du einen externen Zeitdienst zur Hilfe.


Wenn es dir aber um ein total isoliertes System geht, dann ist auch egal ob deine Uhr richtig geht oder nicht, denn in dem isolierten System liefert sie die einzige und damit reale Zeit.

[roli]

Hi,

Unter Lenny hatte ich dank ntpdate immer eine sehr genaue Systemzeit. Nun unter Wheezy möchte ich - einfach so als Tick von mir - eine genaue Systemzeit ohne Zugriff auf externe Dienste hinbekommen.

es ist zwar eher philosophisch, aber wie soll das gehen?
Die genaue, sprich gesetzliche Zeit für D, gibt's nunmal nur bei der PTB, was immer ein externer Dienst ist. Natürlich kannst du auch dem Wecker auf deinem Schreibtisch/der nächsten Kirchturmuhr vertrauen, aber genügt das deiner Anforderung an Genauigkeit, wenn du deinen Rechner dagegen abgleichst?

[rendegast]

Standardmäßig wird ja bei jedem Herunterfahren die Systemuhr in die HW-Uhr geschrieben und dabei /etc/adjtime neu geschrieben.

Benutze zBsp. 'adjtimex -p', bei mir

Code: Alles auswählen

$ ./adjtimex_1.29-2.2_i386/sbin/adjtimex -p
         mode: 0
       offset: 0
    frequency: 2492750
...

und etwas später:
$ ./adjtimex_1.29-2.2_i386/sbin/adjtimex -p
         mode: 0
       offset: 0
    frequency: 2493002
...

und etwas später:
$ ./adjtimex_1.29-2.2_i386/sbin/adjtimex -p
    frequency: 2484652
...

$ ./adjtimex_1.29-2.2_i386/sbin/adjtimex -p
    frequency: 2512251
...

hier hat chrony zugeschlagen und den Gang der Systemuhr geändert.

Du benutzt in der bisherigen Schilderung keine externe Korrektur.
Somit geht das System davon aus, daß es selbst richtige Uhrzeit hat.
Es korrigiert zum einen beim Herunterfahren die BIOS-Uhr,
zum anderen notiert es diese Korrektur in /etc/adjtime.
Anhand dieses Vermerks wird beim nächsten Start mit der ausgelesenen BIOS-Zeit eine "korrekte" Systemzeit ermittelt und benutzt,
aber wiederum läuft dann die Systemzeit wieder mit Standardparametern, ohne tick/frequency-Korrektur.

Somit bekommst Du einen systematischen Fehler.


Dieser Fehler ist nebenbei gar nicht so groß, 40sek/100Tage ~ 0,4sek/86.400sek ~ 1/200.000.
Einer darauf beruhenden tick/frequency-korrigierten Systemuhr würde ich unter den gegebenen Umständen
(tägliches Ein/Aus, teilweise nur Minutenlang) nach 100 Tagen aber nicht trauen.
Auch nicht, wenn der Rechner immer durchgelaufen wäre.

Schwankungen der Abweichung von -0,1sek/Tag bis +0,9sek/Tag sind ja auch noch denkbar,
eventuell sehr wahrscheinlich (vielleicht nicht in der Größe, vielleicht auch größer? ).
Aber wenn bei einer solcherweise eingestellten Systemuhr die tägliche ntp-Kontrolle nur noch eine Korrektur von 1/100sek vorschlägt/durchführt,
wäre es schon prima Ergebnis.

[cosmac]

hi,

Wenn deine Uhr selbst nicht genau genug ist, wovon auszugehen ist, dann musst sie sie zwangslaeufig irgendwie abgleichen.

... oder eine bessere kaufen und nie wieder abgleichen. Meinberg z.B. hat für fast jeden Bedarf an Genauigkeit etwas passendes. Wenn es mir z.B. egal ist, ob die Uhr nach 20 Jahren um 3 Sekunden daneben ist, muss ich nicht einmal das beste Modell nehmen

Ob das ueber NTP oder GPS oder sonstwie passiert ist ja letztlich kein grosser Unterschied. In jedem Fall nimmst du einen externen Zeitdienst zur Hilfe.

Naja, es gibt immer noch Rechner, die keine Netzwerkverbindung haben können oder dürfen.

Würde eine Sonnenuhr denn auch einen externen Dienst nutzen? Die Langzeitstabilität wäre ja perfekt (jedenfalls solange UTC noch Schaltsekunden benutzt). Und mit dem DS3234 Uhrenchip und wenigstens ein paar Sonnentagen im Monat sollte der maximale Fehler unter 5 Sekunden bleiben.

[Ulidor]

Erstmal vielen Dank für die interessanten Beiträge!

Eine externe Referenz nutze ich eigentlich doch, nämlich meine Funkuhr an der Wand.
Ich hatte mir das in etwa so vorgestellt, wie es in der Manpage von hwclock steht. Also, dass ich die BIOS-Uhr - und ich nehme an, auch die Systemuhr(?) - zweimal in nicht zu geringen Abständen nach meiner Funkuhr stelle und dann ab und zu Korrekturen mit hwclock --adjust durchführe, so dass ich dann am Ende eine möglichst genaue autark laufende Systemuhr hätte.

Aber vermute ich richtig, dass das nur einen Sinn hätte, wenn der Rechner längere Zeit - also wenigstens ein paar Tage oder besser Wochen - am Stück laufen würde? Denn je länger der Rechner an einem Stück läuft, umso genauer lässt sich die Drift ermitteln. Oder verstehe ich da was falsch?

Über adjtimex hatte ich auch schon was gelesen. Mir ist aber nicht ganz klar, wie man das (ohne ntp) einsetzt und ob das nicht ziemlich aufwendig und kompliziert ist. Und müsste ich dafür irgendwelche Skripte in init.d verändern?

[rendegast]

adjtimex hat einen Testmodus '--compare' / '--adjust', siehe 'man adjtimex'.
Dieser gibt dann auch direkt die Korrektur aus für 'adjtimex [-t ...] -f ...' oder stellt sie gleich '--adjust'.
Plätze dafür wäre sowas wie rc.local.

Im Standard vergleicht es die Systemuhr mit der RTC-Uhr (naja, zudem muß eventuell der Zugriff auf die RTC erst ermöglicht werden),
es kann auch ein Server angegeben werden:

Code: Alles auswählen

# adjtimex -c -h 10.1.5.117
                                      --- current ---   -- suggested --
cmos time     system-cmos  error_ppm   tick      freq    tick      freq
1336459346      -1.397180
1336459356      -1.395894      128.6  10000         0
1336459366      -1.395221       67.4  10000         0    9999   2137975
1336459376      -1.394539       68.2  10000         0    9999   2086412
1336459386      -1.394036       50.3  10000         0    9999   3258287
1336459396      -1.393121       91.5  10000         0    9999    559850
1336459406      -1.392619       50.3  10000         0    9999   3258287
1336459416      -1.391907       71.2  10000         0    9999   1887975
      reference time is Tue May  8 08:43:43 2012
reference time - system time = 1336459423.040 - 1336459423.000 = 0.040 sec
Last clock comparison was at Tue May  8 08:43:34 2012
Kernel time variables are unchanged - good.
System clock is currently not disciplined - good.
Checking wtmp file...
System has not booted since Tue May  8 08:43:34 2012 - good.
System time has not been changed since Tue May  8 08:43:34 2012 - good.
Checking /etc/adjtime...
/sbin/hwclock has not set system time and adjusted the cmos clock 
since Tue May  8 08:43:34 2012 - good.

Are you sure that, since Tue May  8 08:43:34 2012,
  the system clock has run continuously,
  it has not been reset with `date' or `/sbin/hwclock`,
  the kernel time variables have not been changed, and
  the computer has not been suspended? (y/n) [y] 
The estimated error in system time is -999999.99400 +- 0.00000 ppm

Are you sure that, since Tue May  8 08:43:34 2012,
  the real time clock (cmos clock) has run continuously,
  it has not been reset with `/sbin/hwclock',
  no operating system other than Linux has been running, and
  ntpd has not been running? (y/n) [y] 
The estimated error in the cmos clock is -999999.99399577 +- 0.00000006 ppm

Die Systemuhr wackelt herum, um eine über Wochen funktionierende Driftkorrektur zu treffen,
muß da schon Glück dabei sein.

Der Vergleich System<->RTC

Code: Alles auswählen

# adjtimex -c
                                      --- current ---   -- suggested --
cmos time     system-cmos  error_ppm   tick      freq    tick      freq
1336459556      -1.398591
1336459566      -1.397594       99.7  10000         0
1336459576      -1.412308    -1471.4  10000         0   10014   4680850
1336459586      -1.411373       93.5  10000         0    9999    428600
1336459596      -1.410841       53.3  10000         0    9999   3061412
1336459606      -1.410338       50.3  10000         0    9999   3259850
1336459616      -1.409642       69.6  10000         0    9999   1994225
1336459626      -1.408953       68.9  10000         0    9999   2037975

# adjtimex -p
         mode: 0
       offset: 0
    frequency: 0
     maxerror: 16000000
     esterror: 16000000
       status: 64
time_constant: 2
    precision: 1
    tolerance: 32768000
         tick: 10000
     raw time:  1336459632s 613683us = 1336459632.613683
 return value = 5

liefert gerade ähnliche Werte wie der mit dem Zeitserver (in einer anderen Testreihe wurden auch mal 9998 ticks ausgegeben),
die Driften können sich aufheben oder verstärken nach Zufallsprinzip (CPU-Auslastung?),
eine Drift (normalerweise die der RTC) kann viel stärker sein als die andere.

Die per Hand eingegebene Zeit hat wohl eine Genauigkeit von ~ 0,1 Sekunden,
liegt also im Bereich der Drift Deines Computersystems (an- wie abgeschaltet) pro Tag.




Stärkste Auswirkung, die ich mal wegen fehlerhafter Zeiten gesehen habe,
war die verweigerte Anmeldung von win-clients am NT-Server. (bei 1-2h Unterschied)
(Linux hätte das bei einem reboot durch Stellen der RTC erledigt,
bei win ist ein solcher schreibender Zugriff nicht vorgesehen.
Ein Reboot übernimmt also wieder die falsche Zeit aus der RTC und korrigiert erst bei Zugriff auf den NTP
(wenn die Korrektur kleiner als ein Tag ist (im default)).
Schlecht, wenn der Kunde sich direkt nach dem Reboot wieder anmelden will.)

[rendegast]

Jetzt mal eine Betrachtung der Tools und deren Auswirkungen.

Zuerst mal starte ich chrony:

Code: Alles auswählen

# ntpdate -q 10.1.5.117
server 10.1.5.117, stratum 2, offset 0.020446, delay 0.02586
 8 May 09:29:36 ntpdate[11516]: adjust time server 10.1.5.117 offset 0.020446 sec
# ntpdate -q 10.1.5.117
server 10.1.5.117, stratum 2, offset 0.012100, delay 0.02585
 8 May 09:29:50 ntpdate[11673]: adjust time server 10.1.5.117 offset 0.012100 sec
# ntpdate -q 10.1.5.117
server 10.1.5.117, stratum 2, offset 0.005746, delay 0.02585
 8 May 09:30:03 ntpdate[11808]: adjust time server 10.1.5.117 offset 0.005746 sec
# ntpdate -q 10.1.5.117
server 10.1.5.117, stratum 2, offset 0.000468, delay 0.02586
 8 May 09:30:14 ntpdate[11921]: adjust time server 10.1.5.117 offset 0.000468 sec
# ntpdate -q 10.1.5.117
server 10.1.5.117, stratum 2, offset -0.000011, delay 0.02586
 8 May 09:30:26 ntpdate[12056]: adjust time server 10.1.5.117 offset -0.000011 sec
# ntpdate -q 10.1.5.117
server 10.1.5.117, stratum 2, offset -0.000007, delay 0.02585
 8 May 09:30:37 ntpdate[12171]: adjust time server 10.1.5.117 offset -0.000007 sec
# ntpdate -q 10.1.5.117
server 10.1.5.117, stratum 2, offset -0.000017, delay 0.02586
 8 May 09:30:50 ntpdate[12307]: adjust time server 10.1.5.117 offset -0.000017 sec

Innerhalb einer Minute hat chrony die Zeit im Griff.

Was macht nur die RTC-Uhr:

Code: Alles auswählen

Zuerst mal stelle ich sie auf die Systemzeit:
# hwclock --systohc

# /tmp/adjtimex_1.29-2.1_amd64/sbin/adjtimex -c=20
                                      --- current ---   -- suggested --
cmos time     system-cmos  error_ppm   tick      freq    tick      freq
1336462366       0.020275
1336462376       0.021432      115.7  10000   2471106
1336462386       0.022413       98.0  10000   2471106    9999   2599706
1336462396       0.023004       59.2  10000   2471106    9999   5148143
1336462406       0.023972       96.8  10000   2471106    9999   2679393
1336462416       0.024502       53.0  10000   2470131    9999   5553418
1336462426       0.024961       46.0  10000   2470131    9999   6011231
1336462436       0.025507       54.5  10000   2470131    9999   5450293
1336462446       0.026052       54.6  10000   2470131    9999   5448731
1336462456       0.026821       76.8  10000   2470131    9999   3987793
1336462466       0.012174    -1464.7  10000   2470131   10015    153631
1336462476       0.013113       93.8  10000   2470131    9999   2873731
1336462486       0.013880       76.7  10000   2470131    9999   3995606
1336462496       0.014443       56.4  10000   2470131    9999   5329981
1336462506       0.015205       76.2  10000   2470131    9999   4033106
1336462516       0.016176       97.1  10000   2470131    9999   2658106
1336462526       0.016736       56.0  10000   2470131    9999   5356543
1336462536       0.017701       96.5  10000   2470131    9999   2697168
1336462546       0.018260       55.9  10000   2470131    9999   5358106
1336462556       0.019231       97.1  10000   2470131    9999   2662793

Bei dem großen tick-"Sprung" zwischendurch korrigeren wohl kernel oder chrony die RTC-Uhr.

Nun der in man-page angebotene Vergleich mit dem Zeit-Server:

Code: Alles auswählen

# /tmp/adjtimex_1.29-2.1_amd64/sbin/adjtimex -c=20 -h 10.1.5.117
                                      --- current ---   -- suggested --
cmos time     system-cmos  error_ppm   tick      freq    tick      freq
1336462607       0.021952
1336462617       0.022924       97.2  10000   2470131
1336462627       0.023895       97.1  10000   2470131    9999   2662793
1336462637       0.024678       78.2  10000   2470131    9999   3895606
1336462647       0.025647       96.9  10000   2470131    9999   2672168
1336462657       0.026615       96.9  10000   2470131    9999   2675293
1336462667       0.031602      498.7  10000   2462017    9995   2550329
1336462677       0.016562    -1504.0  10000   2462017   10015   2722079
1336462687       0.017117       55.4  10000   2462017    9999   5382804
1336462697       0.017681       56.5  10000   2462017    9999   5315617
1336462707       0.018410       72.9  10000   2462017    9999   4235929
1336462717       0.018967       55.6  10000   2462017    9999   5368742
1336462727       0.019935       96.8  10000   2462017    9999   2668742
1336462737       0.020581       64.5  10000   2462017    9999   4785929
1336462747       0.021074       49.4  10000   2462017    9999   5781242
1336462757       0.021902       82.7  10000   2462017    9999   3593742
1336462767       0.022648       74.6  10000   2462017    9999   4123429
1336462777       0.023413       76.5  10000   2462017    9999   4004679
1336462787       0.024382       96.9  10000   2462017    9999   2664054
1336462797       0.025141       75.9  10000   2462017    9999   4043742
      reference time is Tue May  8 09:40:05 2012
reference time - system time = 1336462805.000 - 1336462805.000 = 0.000 sec
Last clock comparison was at Tue May  8 09:39:57 2012
Kernel time variables are unchanged - good.
System clock is currently not disciplined - good.

Ich erwarte hier unter "suggest" eine Angabe wie unter "current",
zumindest aber keine Schwankungen mehr von 9999/2.000.000 bis 9999/5.000.000
(die Systemzeit ist ja mit dem NTP-Server synchron bis auf Microsekunden,
die Korrektur durch chrony liegt bei freq ~ 10.000).
Die vorgeschlagenen Korrekturen gleichen aber der aus dem vorherigen Durchlauf.

-> Der Test '--compare' des Tools adjtimex ist "speziell",
es wird wohl immer auf die RTC verglichen,
Die vorgeschlagenen Korrekturen zielen auf Synchronisierung der Systemuhr nur mit der RTC?
Es wird bei '-h Zeitserver' kein naheliegender Vergleich NTP-Zeit<->Systemzeit durchgeführt?

Wenn die schwankenden Korrekturen von einer NTP-synchronen Zeit auf die RTC zielen,
heißt das, daß die RTC in dem Maße schwankt.

Hier mittles 'adjtimex -t ... -f ...' eine höhere Ganggenauigkeit des an-/abgeschalteten Systems zu erreichen,
wäre wie durch Drehen des Fahnenmastes das Flattern der Fahne zu verringern.

-> Funkuhr oder gelegentlich per Hand korrigieren.
Eventuell kann aus dem ssid-broadcast eines nahegelegenen wlan die Zeit gezogen werden? Eventuelle Tools dazu aber?

[Ulidor]

Danke, rendegast, für die Ausführungen. Ich muss gestehen, dass ich mich noch nicht so genau in die Thematik eingearbeitet habe. Es scheint aber doch recht aufwendig zu sein. Wahrscheinlich ist es mit z.B. ntpdate doch viel einfacher. Man installiert es, und muss sich um nichts mehr kümmern.

Mir kommt es auch gar nicht darauf an, dass die Systemuhr immer auf die Millisekunde genau geht. Wichtig ist mir eigentlich nur, dass sie auf lange Sicht möglichst nicht mehr als eine Sekunde von der genauen Zeit abweicht. Das ohne NTP zu machen, wäre eigentlich auch deshalb nicht schlecht, weil sich mein DSL-Modem ab und zu nachts mal resettet (wie und warum auch immer) und es dann den Router nicht mehr akzeptiert, so dass ich danach keinen Internetzugang mehr habe. Wenn ich mich da an Lenny richtig erinnere, wartete ntpdate beim Booten dann erstmal eine Weile.

Wie kann man denn aus dem SSID-Broadcast eines WLAN die Zeit ziehen? Bei meinem Router habe ich das SSID-Broadcast abgeschaltet, aber ich kann hier einige WLANs empfangen.

[cosmac]

Wenn ich mich da an Lenny richtig erinnere, wartete ntpdate beim Booten dann erstmal eine Weile.

Inzwischen kommt der ntpd ohne ntpdate aus, aber in per Default wird er wohl auch warten. Deshalb würde ich versuchen 3 bis 5 Server aus dem ntp-pool zu konfigurieren, nur "slew" erlauben und keine besondere Funktion beim Start. Auf die Art sollte der ntpd im Hintergrund auf die Zeit-Server warten. Sobald die Verbindung ein paar Minuten lang steht, wird die Uhr im Kernel gestellt und der stellt nach weiteren 11 Minuten die BIOS-Uhr.

Man könnte auch beim runter fahren mit rdate die Kernel-Uhr stellen und, wenn das klappt, mit hwclock die BIOS-Uhr:

Code: Alles auswählen

rdate -nv de.pool.ntp.org && hwclock --utc --systohc

Da auch rdate einen ziemlich langen Time-Out hat, lohnt sich evt. eine Abfrage, ob das Netzwerk funktioniert.

Wie kann man denn aus dem SSID-Broadcast eines WLAN die Zeit ziehen? Bei meinem Router habe ich das SSID-Broadcast abgeschaltet, aber ich kann hier einige WLANs empfangen.

Welcher AP hat denn eine genau gehende Uhr? Ich würde ja nicht mal meinem eigenen trauen...

[rendegast]

Welcher AP hat denn eine genau gehende Uhr? Ich würde ja nicht mal meinem eigenen trauen...

Gesetzt dem Fall, es existiert überhaupt so eine Möglichkeit (war ja nur so eine Idee von mir),
werden die extrahierten Zeiten einfach verglichen.
Mehrere identische deuten wohl auf eine NTP-Synchronisation (welches zBsp. mein trendnet bietet).

[catdog2]

Welcher AP hat denn eine genau gehende Uhr? Ich würde ja nicht mal meinem eigenen trauen...

Die meisten synchronisieren sich wenn überhaupt per ntp. Eine HW Uhr haben die eher selten.

[Lohengrin]

Du benutzt in der bisherigen Schilderung keine externe Korrektur.
Somit geht das System davon aus, daß es selbst richtige Uhrzeit hat.
Es korrigiert zum einen beim Herunterfahren die BIOS-Uhr,
zum anderen notiert es diese Korrektur in /etc/adjtime.
Anhand dieses Vermerks wird beim nächsten Start mit der ausgelesenen BIOS-Zeit eine "korrekte" Systemzeit ermittelt und benutzt,
aber wiederum läuft dann die Systemzeit wieder mit Standardparametern, ohne tick/frequency-Korrektur.

Ich habe hier genau das Problem. Bisher dachte ich, dass die Drift berechnet wird, wenn ich die Hardwareclock stelle. Deshalb habe ich /etc/adjusttime gelöscht und mit hwclock --utc -w die Hardwareclock gesetzt. Dann stand in /etc/adjtime eine Drift von 0. Leider steht da jetzt wieder eine positive Drift drin.
Erklärung: Beim Runterfahren meint dieses System, dass die Hardwareclock eine Drift von +0.5 hätte und trägt das in /etc/adjtime ein. Würde es das nicht tun, dann hätte ich nicht eine tatsächliche Drift von -0.5.
Wie kann das unerwünschte Stellen der Hardwareclock abschalten?

Ich habe übrigens gerade ntp installiert. Aber es interessiert mich trotzdem, wie es ohne gehen würde.

[cosmac]

hi,

früher habe ich immer das init-Script deaktiviert, seit wheezy gibt es in /etc/default/hwclock die Option HWCLOCKACCESS=no. In beiden Fällen wird aber auch der Aufruf beim booten abgeschaltet, und das hat wahrscheinlich Nebenwirkungen:

# Copies Hardware Clock time to System Clock using the correct
# timezone for hardware clocks in local time, and sets kernel
# timezone. DO NOT REMOVE.
/sbin/hwclock --hctosys (...)

"HWCLOCKACCESS=no" unterbindet diesen hwclock-Aufruf aber, wie jetzt?! Also, trotz der Verbesserungen in wheezy bleibt hwclock rätsel- bis zweifelhaft.

Der Kernel benutzt die lokale Zeitzone für DOS-kompatible Dateisysteme wie FAT, die die lokale Zeit für die Datei-Zeitstempel benutzen. Da das sowieso nicht richtig funktionieren kann (wegen der Sommerzeit), ist es mir egal, ob diese Zeiten um 1 oder um 2 Stunden daneben liegen. Es ist denkbar, dass die Kernel-Zeitzone mit einem anderen Mechanismus eingestellt wird, dann wäre hwclock völlig nutzlos und dieser Absatz gegenstandslos.

Irgendwo steht auch, dass sich hwclock mit ntp nicht verträgt. Na gut, es ist dann überflüssig, weil der Kernel die CMOS-Uhr regelmässig stellt. Aber der Adjust-Mechanismus kommt damit wohl nicht klar -- also: abschalten (ist hier eine der ersten Einstellungen nach jeder Installation).