[gentoo-amd64] [SOLVED] Recent clock problems

[Mark Knecht]

On 2/11/06, Duncan <1i5t5.duncan@×××.net> wrote:
> Mark Knecht posted
> <5bdc1c8b0602110941y446deb24qc519fcb40298136a@××××××××××.com>, excerpted
> below,  on Sat, 11 Feb 2006 09:41:20 -0800:
>
> > Hello,
> >    Just in the last week or so my AMD64 machine has started to exhibit
> > problems with the clock. Maybe it's a hardware problem, or possibly
> > it's some new ntpd issue after updates. At boot time it seems to be
> > coming up with semi-random times. This is causing me to ask a few
> > questions and try to learn a bit more about how this actually works
> > under Linux. Thanks in advance.
>
> Those can be quite frustrating.  I'm not a master, but somehow, I've
> managed to bluster my way thru a couple frustrating episodes.
>
> > QUESTION 1: UTC vs. local
> >
> > In /etc/conf.d/clock I can choose UTC vs. local. Does this refer to
> > the time I set in the hardware clock or something else? Nominally it's
> > easier sitting here in California to set the hardware clock to
> > California time. Is there any problem with doing this? If I understand
> > the comments I should be using 'local' but the default seemed to be
> > UTC.
>
> UTC is effectively what used to be called GMT, Universal Time Coordinated
> (I believe French, so looks backward to us English folks), Greenwich Mean
> Time, the time standardized to London, UTC indicating as updated with
> official leap-seconds, according to kdict (just looked it up to be sure to
> get it right).
>
> The continental US is of course 5-8 hours behind UTC, with an adjustment
> for DST in the summer, naturally (that I thankfully don't have to worry
> about here in AZ).
>
> Traditionally, Unix has kept system time in UTC, while MSWormOS kept it in
> local time, so if you are booting between the two, it can /really/ screw
> things up.  Modern Linux has a toggle, but if the toggle gets out of sync
> for some reason, you'll see it jumping back and forth by those several
> hours, as you boot and reset it and reboot.  To get it synced back up can
> be more difficult than you'd expect, because if you don't do all the steps
> in the right order, it either doesn't take, or it takes, but just confirms
> the offset once again.

I think the only thing I'm not clear about here is what is actually in
the hardware clock? If I keep time in UTC then when date tells me 4PM
is the hardware clock holding midnight? (I'm in CA - offset is 8
hours.)

Can I check this somehow, like going into BIOS?

Right now I've set the clock back to UTC and rebooted. This is what I
see now. It has the 8 hour offset:

lightning ~ # hwclock
Sat Feb 11 14:04:13 2006  -0.156743 seconds
lightning ~ # hwclock --debug
hwclock from util-linux-2.12r
Using /dev/rtc interface to clock.
Last drift adjustment done at 1139695116 seconds after 1969
Last calibration done at 1139695116 seconds after 1969
Hardware clock is on UTC time
Assuming hardware clock is kept in UTC time.
Waiting for clock tick...
/dev/rtc does not have interrupt functions. Waiting in loop for time
from /dev/rtc to change
...got clock tick
Time read from Hardware Clock: 2006/02/11 22:04:21
Hw clock time : 2006/02/11 22:04:21 = 1139695461 seconds since 1969
Sat Feb 11 14:04:21 2006  -0.165847 seconds
lightning ~ #

<SNIP>
>
> OK, so what is used to do a time step, if ntpd normally does time skews?
>
> That's ntp-client.  If you have ntp running on your system, you'll
> probably want both ntpd and ntp-client in your default runlevel.
> ntp-client runs before ntpd, and steps the clock to /approximately/ the
> correct time (within 100ms or so).  It's a single-shot run at boot, after
> which ntpd starts, does it's connections to see how far it has to adjust,
> and gets to work doing the skew.

OK, for now anyway this seems to be the solution. I have never run
ntp-client. For whatever reason I've never required it. It seems that
some set of recent updates - ntp or whatever - have now started
requirign that I run it. With this turned on my AMD64 machine is
within a second (the speed at twhich I can hit enter in two
terminals...) of my wife's Gentoo 32-bit machine.

Thanks Duncan! As usual your answers are very through and well
written. It's like a very straight forward class that seems to answer
most all of my questions and leaves me with a lot of certainty that if
I just follow along carefully I'll learn something.

Cheers,
Mark

-- 
gentoo-amd64@g.o mailing list