summaryrefslogtreecommitdiffstats
path: root/sys-utils/hwclock.8.in
diff options
context:
space:
mode:
authorKarel Zak2014-10-20 11:41:38 +0200
committerKarel Zak2014-10-20 11:41:38 +0200
commite2c1eb9913e9479c7d7009f5f46404fd9c4180f5 (patch)
treecddf2ddb2b60bc84be2ee1269038f54ce780bf06 /sys-utils/hwclock.8.in
parentswapon: add -o <list> for compatibility with mount (diff)
parenthwclock: Add --update-drift option MAN (diff)
downloadkernel-qcow2-util-linux-e2c1eb9913e9479c7d7009f5f46404fd9c4180f5.tar.gz
kernel-qcow2-util-linux-e2c1eb9913e9479c7d7009f5f46404fd9c4180f5.tar.xz
kernel-qcow2-util-linux-e2c1eb9913e9479c7d7009f5f46404fd9c4180f5.zip
Merge branch 'master' of https://github.com/jwpi/util-linux into hwclock
Diffstat (limited to 'sys-utils/hwclock.8.in')
-rw-r--r--sys-utils/hwclock.8.in145
1 files changed, 103 insertions, 42 deletions
diff --git a/sys-utils/hwclock.8.in b/sys-utils/hwclock.8.in
index b11b45c24..d67595521 100644
--- a/sys-utils/hwclock.8.in
+++ b/sys-utils/hwclock.8.in
@@ -61,8 +61,18 @@ in Coordinated Universal Time. See the
option.
Showing the Hardware Clock time is the default when no function is specified.
.TP
+.B \-\-get
+Like
+.B --show
+only with drift correction applied to the time read. This is useful when the
+Hardware Clock is not being periodically updated by something such as NTP's
+11 minute mode or when not using
+.BR --adjust .
+.TP
.BR \-s , \ \-\-hctosys
-Set the System Time from the Hardware Clock.
+Set the System Time from the Hardware Clock. The time read from the Hardware
+Clock is compensated to account for systematic drift before using it to set the
+System Clock. See the discussion below, under \fBThe Adjust Function\fR.
.PP
Also set the kernel's timezone value to the local timezone
as indicated by the TZ environment variable and/or
@@ -74,7 +84,24 @@ The obsolete tz_dsttime field of the kernel's timezone value is set
to DST_NONE. (For details on what this field used to mean, see
.BR settimeofday (2).)
.PP
+When used in a startup script, making it the first caller of
+.BR settimeofday (2)
+from boot, it will set the NTP 11 minute mode time scale via the
+.I persistent_clock_is_local
+kernel variable. See the discussion below, under
+.B Automatic Hardware Clock Synchronization by the
+.BR Kernel.
+.PP
This is a good option to use in one of the system startup scripts.
+.PP
+This option should never be used on a running system. Jumping system time
+will cause problems, such as, corrupted file system timestamps.
+Also, if NTP 11 minute mode is active then
+.B --hctosys
+will set the time incorrectly by
+including drift compensation. Drift compensation can be inhibited by using the
+.B --noadjfile
+option.
.TP
.B \-\-set
Set the Hardware Clock to the time given by the
@@ -315,7 +342,18 @@ with SRM console.
Do everything except actually updating the Hardware Clock or anything
else. This is useful, especially in conjunction with
.BR \-\-debug ,
-in learning about
+in learning about the internal operations of hwclock.
+
+.TP
+.B \-\-update\-drift
+Update the Hardware Clock's drift factor in
+.IR @ADJTIME_PATH@ .
+It is used with
+.BR --set\ or \ --systohc ,
+otherwise it is ignored.
+See the discussion below, under
+.B The Adjust
+.BR Function.
.TP
.BR \-u , \ \-\-utc
@@ -383,11 +421,16 @@ use the TZ environment variable and/or the
.I /usr/share/zoneinfo
directory, as explained in the man page for
.BR tzset (3).
-However, some
-programs and fringe parts of the Linux kernel such as filesystems use
-the kernel timezone value. An example is the vfat filesystem. If the
-kernel timezone value is wrong, the vfat filesystem will report and
-set the wrong timestamps on files.
+However, some programs and fringe parts of the Linux kernel such as filesystems
+use the kernel timezone value. An example is the vfat filesystem. If the
+kernel timezone value is wrong, the vfat filesystem will report and set the
+wrong timestamps on files. Another example is the kernel's NTP 11 minute mode.
+If the kernel's timezone value and/or the
+.I persistent_clock_is_local
+variable are wrong, then the Hardware Clock will be set incorrectly by 11 minute
+mode. See the discussion below, under
+.B Automatic Hardware Clock Synchronization by the
+.BR Kernel.
.PP
.B hwclock
sets the kernel timezone to the value indicated by TZ and/or
@@ -484,8 +527,9 @@ The Hardware Clock is usually not very accurate. However, much of its
inaccuracy is completely predictable - it gains or loses the same amount
of time every day. This is called systematic drift.
.BR hwclock 's
-"adjust" function lets you make systematic corrections to correct the
-systematic drift.
+.I \-\-adjust
+function lets you apply systematic drift corrections to the
+Hardware Clock.
.PP
It works like this:
.B hwclock
@@ -499,8 +543,8 @@ command to set the Hardware Clock to the true current time.
.B hwclock
creates the adjtime file and records in it the current time as the
last time the clock was calibrated.
-5 days later, the clock has gained 10 seconds, so you issue another
-.I hwclock \-\-set
+5 days later, the clock has gained 10 seconds, so you issue the
+.I hwclock \-\-set \-\-update\-drift
command to set it back 10 seconds.
.B hwclock
updates the adjtime file to show the current time as the last time the
@@ -519,30 +563,36 @@ Another 24 hours goes by and you issue another
does the same thing: subtracts 2 seconds and updates the adjtime file
with the current time as the last time the clock was adjusted.
.PP
-Every time you calibrate (set) the clock (using
-.I \-\-set
-or
-.IR \-\-systohc ),
-.B hwclock
-recalculates the systematic drift rate based on how long it has been
+When you use the
+.I \-\-update\-drift
+option with
+.IR \-\-set\ or \ \-\-systohc ,
+the systematic drift rate is (re)calculated based on how long it has been
since the last calibration, how long it has been since the last
adjustment, what drift rate was assumed in any intervening
-adjustments, and the amount by which the clock is presently off.
-.PP
-A small amount of error creeps in any time
-.B hwclock
-sets the clock, so it refrains from making an adjustment that would be
-less than 1 second. Later on, when you request an adjustment again,
-the accumulated drift will be more than a second and
-.B hwclock
-will do the adjustment then.
+adjustments, and the amount by which the clock is presently off. This updated
+drift factor is then saved in
+.IR @ADJTIME_PATH@ .
.PP
-It is good to do a
-.I hwclock \-\-adjust
-just before the
-.I hwclock \-\-hctosys
-at system startup time, and maybe periodically while the system is
-running via cron.
+A small amount of error creeps in when
+the Hardware Clock is set, so
+.I \-\-adjust
+refrains from making any adjustment that is less
+than 1 second. Later on, when you request an adjustment again, the accumulated
+drift will be more than 1 second and
+.I \-\-adjust
+will make the adjustment including any fractional amount.
+.PP
+.IR "hwclock \-\-hctosys"
+also uses the adjtime file data to compensate the value read from the Hardware
+Clock before using it to set the System Time. It does not share the 1 second
+limitation of --adjust, and will correct sub-second drift values immediately.
+It does not change the Hardware Clock time or the adjtime file. This may
+eliminate the need to use --adjust, unless something else on the system needs
+the Hardware Clock to be compensated. The drift compensation can be inhibited
+by using the
+.B --noadjfile
+option.
.PP
The adjtime file, while named for its historical purpose of controlling
adjustments only, actually contains other information for use by hwclock
@@ -585,20 +635,31 @@ your System Time synchronized either to a time server somewhere on the
network or to a radio clock hooked up to your system. See RFC 1305.)
.PP
This mode (we'll call it "11 minute mode") is off until something
-turns it on. The ntp daemon xntpd is one thing that turns it on. You
+turns it on. The ntp daemon ntpd is one thing that turns it on. You
can turn it off by running anything, including
.IR "hwclock \-\-hctosys" ,
-that sets the System Time the old fashioned way.
+that sets the System Time the old fashioned way. However, if the ntp daemon is
+still running, it will turn 11 minute mode back on again the next time it
+synchronizes the System Clock.
.PP
-If your system runs with 11 minute mode on, don't use
-.I hwclock \-\-adjust
-or
-.IR "hwclock \-\-hctosys" .
-You'll just make a mess. It is acceptable to use a
+If your system runs with 11 minute mode on, it may need
+.I hwclock \-\-hctosys
+in a startup script, especially if the Hardware Clock is configured to to use
+the local timescale.
+
+The first user space command to set the System Clock informs the
+kernel what timescale the Hardware Clock is using. This happens via the
+.I persistent_clock_is_local
+kernel variable. If
.I hwclock \-\-hctosys
-at startup time to get a reasonable System Time until your system is
-able to set the System Time from the external source and start 11
-minute mode.
+is the first, it will set this variable according to the adjtime file or the
+appropriate command line argument. Note that when using this capability and the
+Hardware Clock timescale configuration is changed, then a reboot is required to
+notify the kernel.
+
+Don't use
+.I hwclock \-\-adjust
+with 11 minute mode. You'll just make a mess.
.SS ISA Hardware Clock Century value
.PP