Hardware clock

[Derek Martin]

On Sun, 21 Nov 1999, amc wrote:

> 
>   thanks, Derek, for the mini-course on time !

NP :)

>   my /etc/adjtime contains:
>   0.000000 938642353 0.000000

Ordinarily I don't like to quote manpages in messages (since it should be
easy enough for the user to read them themselves), but since you don't
have it, here's the relevant part of the discussion from the hwclock
manpage:


       It works like this: Hwclock keeps  a  file,  /etc/adjtime,
       that  keeps  some  historical information.  This is called
       the adjtime file.

       Suppose you start with  no  adjtime  file.   You  issue  a
       hwclock  --set  command  to  set the Hardware Clock to the
       true current time.  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 hwclock --set command to set
       it back 10 seconds.  Hwclock updates the adjtime  file  to
       show the current time as the last time the clock was cali-
       brated, and records 2 seconds per day  as  the  systematic
       drift  rate.  24 hours go by, and then you issue a hwclock
       --adjust command.  Hwclock consults the adjtime  file  and
       sees  that  the  clock  gains  2 seconds per day when left
       alone and that it has been left alone for exactly one day.
       So  it  subtracts  2  seconds from the Hardware Clock.  It
       then records the current time as the last time  the  clock
       was  adjusted.   Another  24  hours  goes by and you issue
       another hwclock --adjust.  Hwclock does  the  same  thing:
       subtracts  2 seconds and updates the adjtime file with the
       current time as the last time the clock was adjusted.

       Every time you calibrate (set) the clock (using  --set  or
       --systohc  ),  hwclock  recalculates  the systematic drift
       rate based on how long it has been since the last calibra-
       tion, 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.


I suggest you also see the manpage for adjtime -- you may need to install
the adjtime package if you didn't.  I assume Alpha Linux has this or else
I suspect that /etc/adjtime would not exist.  But maybe I'm wrong there...

The first number is the most important one... it's the assumed drift rate.
Yours appears to be zero, which means that the system should not adjust
the system time.  This is probably fine, unless there's something
seriously wrong with your system's hardware clock.

>   i recently set up  ntpd.
>   the only difference i note is the linux clcok is changing
>   (more than it used to) compared to the clock on my intel box.

Unless you're talking about significant numbers (like more than a few
seconds per day) this is fine... Intel's hardware clock isn't too
accurate, which is the point of all that adjtime stuff in the rc scripts.
It's trying to adjust the time to account for inaccuracies of the hardware
clock.

>   it actually looks backwards !
>   why should the hardware clock be _set_ by the system (linux) 
>   that just _got_ its time from the hardware clock ?
>   but you're saying the algorithm is something like set the current time
>   to the ave. of the last 2 boots ?

Yeah, I can see how you would think that, but if you think about it, it
does make sense.  At least on my system (intel) the first thing it does is
set the system clock to the hardware clock, with the --adjust option. This
adjusts the hardware clock to the drift rate, and then sets the system
time.  Since I use UTC time, it then does a second setting of the system
time to change to UTC time.  This clearly is not the most efficient method
to do this, but in theory, this should work fine...

In most cases, if you are not using UTC the first setting of the system
time should be the ONLY one... Then again, I'm going on the intel rc
scripts, yours may look completely different if you're on an Alpha.  I
can't say... I don't have one.

<PONTIFY>
I don't like the way redhat does this in their rc scripts, it could have
been written more efficiently.  Furthermore, I don't think they should do
it AT ALL by default, since it presents the opportunity to really screw up
a new user.  But I have a lot of complaints about RedHat's rc scripts.
Many of the ones I've looked at have been lazy hacks...
</PONTIFY>

-- 
Derek D. Martin
Senior UNIX Systems/Network Administrator
Arris Interactive
derek.martin at ne.arris-i.com


-
Subcription/unsubscription/info requests: send e-mail with
"subscribe", "unsubscribe", or "info" on the first line of the
message body to discuss-request at blu.org (Subject line is ignored).