[gentoo-amd64] Recent clock problems

[gentoo-amd64] Recent clock problems

[Mark Knecht]

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.

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.

QUESTION 2: date

date only sets a software clock, correct? Is this all the system uses
after boot?

QUESTION 3: hwclock -w

This is supposed to write the time in the system's software clock into
hardware, correct?

QUESTION 4:

Does ntpd actually update the system clock, or is it another layer yet
on top. If I use ntpd and then do hwclock -w does an accurate time get
written to the hardware clock?

   Thanks in advance for your help.

cheers,
Mark

-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Recent clock problems

[Bob Slawson]

Mark Knecht wrote:
> 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.
>   
First thing to do is to check that the symlink `/etc/localtime' still
points to a valid timezone data file.  For instance:

$ ls -l /etc/localtime
lrwxrwxrwx 1 root root 30 Jan 21 21:52 /etc/localtime ->
/usr/share/zoneinfo/US/Eastern

works well where I live.  When I have clock problems, this symlink is
almost always the problem.


In /etc/conf.d/clock,  I have CLOCK="UTC", CLOCK_SYSTOHC="yes" , and
CLOCK_OPTS="".

BobS


-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Recent clock problems

[Mark Knecht]

On 2/11/06, Bob Slawson <bslawson@frontiernet.net> wrote:
> Mark Knecht wrote:
> > 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.
> >
> First thing to do is to check that the symlink `/etc/localtime' still
> points to a valid timezone data file.  For instance:
>
> $ ls -l /etc/localtime
> lrwxrwxrwx 1 root root 30 Jan 21 21:52 /etc/localtime ->
> /usr/share/zoneinfo/US/Eastern
>
> works well where I live.  When I have clock problems, this symlink is
> almost always the problem.
>
>
> In /etc/conf.d/clock,  I have CLOCK="UTC", CLOCK_SYSTOHC="yes" , and
> CLOCK_OPTS="".
>
> BobS
>

Hi Bob,
   /etc/localtime seems to be OK:

mark@lightning ~ $ ls -l /etc/localtime
lrwxrwxrwx  1 root root 39 Aug 30 10:29 /etc/localtime ->
/usr/share/zoneinfo/America/Los_Angeles
mark@lightning ~ $

My clock settings seem similar, other than the UTC/local question

CLOCK="local"
CLOCK_OPTS=""
CLOCK_SYSTOHC="yes"

   Are you able to clarify about what to write into the clock when
using fist date and then hwclock? For instance yesterday I did these
commands:

date 021008002006
hwclock -w

But this morning (Feb. 11th) when I booted the clock came up saying
Feb. 9th. so I had to write it again after booting.

NOTE: The problem happens using both UTC and local so it's actually
not caused by that.

NOTE 2: I also see that system time is off by 2 minutes from what I
get from the over the phone time system. Normally they have been very
close so it seems that ntpd is not doing it's job right now either....

I suppose this could be a bad battery or something like that but this
is my newest system and is only about 6 months old so I doubt it.
Also, I had this problem for about 3 months on my old laptop when
support for that chipset came out. I'm therefore assuming it's really
a Linux problem of some type.

A bit more debug info:

lightning ~ # hwclock --debug
hwclock from util-linux-2.12r
Using /dev/rtc interface to clock.
Last drift adjustment done at 1139675735 seconds after 1969
Last calibration done at 1139675735 seconds after 1969
Hardware clock is on local time
Assuming hardware clock is kept in local 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 10:51:26
Hw clock time : 2006/02/11 10:51:26 = 1139683886 seconds since 1969
Sat Feb 11 10:51:26 2006  -0.686794 seconds
lightning ~ #


Thanks,
Mark

-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Recent clock problems

[Nicolas MASSÉ]

Hello,

On Saturday 11 February 2006 18:41, Mark Knecht wrote:
> 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.
>

The question is quite simple :
- If you have a windows on the same computer, you must choose "local"
- else it's better to choose UTC (did you notice that your clock is adjusted 
twice during the daylight switch when you have two windows on the same 
computer ?)

>    Thanks in advance for your help.
>
> cheers,
> Mark

Nicolas MASSE
-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Recent clock problems

[Hemmann, Volker Armin]

On Saturday 11 February 2006 18:41, Mark Knecht wrote:
> 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.
>
> 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.

it does not really matter which one you choose.

>
> QUESTION 2: date
>
> date only sets a software clock, correct? Is this all the system uses
> after boot?

man date says 'system time'. which is the 'software clock'

>
> QUESTION 3: hwclock -w
>
> This is supposed to write the time in the system's software clock into
> hardware, correct?

yes

>
> QUESTION 4:
>
> Does ntpd actually update the system clock, or is it another layer yet
> on top. If I use ntpd and then do hwclock -w does an accurate time get
> written to the hardware clock?
# If you want to sync the system clock to the hardware clock during
# shutdown, then say "yes" here.

CLOCK_SYSTOHC="yes"

btw, removing /etc/adjtime will help, if your clock behaves funny.
yes

you should open /etc/conf.d/clock and set this:
-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Recent clock problems

[Bob Slawson]

Mark Knecht wrote:
> Hi Bob,
>    /etc/localtime seems to be OK:
>
> mark@lightning ~ $ ls -l /etc/localtime
> lrwxrwxrwx  1 root root 39 Aug 30 10:29 /etc/localtime ->
> /usr/share/zoneinfo/America/Los_Angeles
> mark@lightning ~ $
>
> My clock settings seem similar, other than the UTC/local question
>
> CLOCK="local"
> CLOCK_OPTS=""
> CLOCK_SYSTOHC="yes"
>
>    Are you able to clarify about what to write into the clock when
> using fist date and then hwclock? For instance yesterday I did these
> commands:
>
> date 021008002006
> hwclock -w
>
> But this morning (Feb. 11th) when I booted the clock came up saying
> Feb. 9th. so I had to write it again after booting.
>
>   
Are you using ntpd?  If so,  does ntp-client run correctly during boot? 
This is the preferred way to set the system clock.  If ntpd is running,
what does `ntpq -p' output?  Does `rc-status default' indicate both
ntp-client and ntpd as 'started'?

> NOTE: The problem happens using both UTC and local so it's actually
> not caused by that.
>
> NOTE 2: I also see that system time is off by 2 minutes from what I
> get from the over the phone time system. Normally they have been very
> close so it seems that ntpd is not doing it's job right now either....
>   
ntpd is definently not working then.  ntpd gives up if the local clock
is too far off of network time, that is where ntp-client becomes useful
at bootup.


BobS


-- 
gentoo-amd64@gentoo.org mailing list

[gentoo-amd64] Re: Recent clock problems

[Duncan]

Mark Knecht posted
<5bdc1c8b0602110941y446deb24qc519fcb40298136a@mail.gmail.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.

> QUESTION 2: date
> 
> date only sets a software clock, correct? Is this all the system uses
> after boot?

Short answer, yes, to both.  The hardware clock only gets reset when you
reset it, and it's not used for keeping time while the system is running.

> QUESTION 3: hwclock -w
> 
> This is supposed to write the time in the system's software clock into
> hardware, correct?

The key word there is /supposed/.  Can you tell I've gotten rather
frustrated with it? =8^P

Here's a hint:  It's /much/ easier to figure out how to use the Gentoo
scripts and configuration, and call the initscript manually to reset the
hardware clock if necessary, than it is to get the sequence of steps
correct to set the hardware clock correctly, getting the toggle and the
local time offset correct all at the same time.  I don't know whether it's
because the hwclock command line is unnecessarily obtuse, or what, but
what one would /think/ would be a simple, logical process, just /isn't/!

So.  Set the Gentoo configuration, then turn off dhcpd if it's on and set
the (system/software) clock, then issue the command /etc/init.d/clock
restart, and it should first set the hardware clock from the software
clock (as if its shutting down), then set the software clock from the
hardware clock (as if the system is booting up).

The settings you need, at least in the baselayout-1.12.0-pre series, are
all in /etc/conf.d/clock.  baselayout-1.11.x may have had a couple of
these settings in either /etc/rc.conf or /etc/conf.d/rc, as I seem to
remember some setting there, but they aren't there now.

If you want to keep your hardware clock set for localtime, set
CLOCK="local" in the config file.  CLOCK_OPTS should normally remain
blank.  I'd certainly suggest you leave them so if this is at all useful
to you, as I had little enough success setting the thing right manually
that I wasn't /about/ to try and screw with things here, and if this is
useful, than you know no more than I do about it! =8^P

Perhaps the most important setting is CLOCK_SYSTOHC (system to hardware). 
You most likely want this set to "yes", as once you get things configured,
ntpd will be keeping things adjusted for you and you'll be able to let it
correct the hardware clock at shutdown.  In any case, you'll probably want
it set yes to allow you to properly set the hardware clock this time, then
you can turn it back to no if you wish.

Ensure the Alpha options are both set "no", as they should be unless you
screwed with them desperately trying to get things to work.

As I said above, once that's done, ensure dhcpd is off, and restart the
clock system service (it'll probably warn you that your stopping a boot
level service, but it shouldn't hurt, I do it here to set my clock).  The
clock boot script should then magically accomplish what was SO
FRUSTRATINGLY DIFFICULT to get right, manually.

Assuming there's nothing seriously wrong with your system, that should get
things back to being relatively accurate.  If it doesn't, there are a
couple of possible causes.  If the clock is going crazy, say running
double-speed when the system is up, it's a system timer problem.  You'll
need to find some way to regulate your kernel so it keeps time properly,
and dhcpd won't be able to help as the problem will be to drastic.  The
solution there involves possible kernel bootline switches, and/or finding
the proper driver for your chipset so the kernel has a reliable hardware
timer it can sync against.

If your hardware clock keeps resetting to January 1 of 2000, or some other
date, or if it goes random (not off by a fixed offset, which would
indicate UTC/local issues again/still) it's possible you have a battery
going dead, tho that really shouldn't be happening yet with amd64 boards. 
Maybe it was shorted out or something and lost a whole bunch of juice at
once, or maybe you have a bad timing capacitor or something.  This can be
bad news, because it often indicates you are about to start having other
problems, like the BIOS not retaining its settings over a shutdown, and
the like.  Get ready to buy a new mobo.  However, if it's just the clock
going bad, you can usually use ntp to correct the system once at boot and
then keep things regular while running.  It'll just be irritating if you
boot up for maintenance and don't go online or start ntp as your time
could be way off, but anyway...

> QUESTION 4:
> 
> Does ntpd actually update the system clock, or is it another layer yet
> on top. If I use ntpd and then do hwclock -w does an accurate time get
> written to the hardware clock?

I don't like the term "system" clock in this context, because it's
ambiguous as to whether you are referring to hardware or software.  That's
why I used system/software clock or the like a couple times above, to make
it absolutely clear which I was referring to.

That said, "system clock" normally refers to the software clock that the
system uses while running, and yes, ntpd /does/ update it directly --
well, sort-of.  <g>  Don't worry, the confusion is normal and under the
circumstances entirely understandable, but there's a logical explanation
that makes sense once you understand what's going on.

Here's the deal.  ntpd was developed to be used in situations where
various running programs might be making critical assumptions about the
system time -- namely that it always moves forward, never backward.  To
have the time move backward, if the machine's an online server in some
applications, would be /very/ /bad/!  Thus, by default and if at all
possible (if the time isn't off by days or years), ntpd will normally
choose to /skew/ the time, adjusting how fast the machine advances time by
a few parts per million, rather than stepping it either forward or
backward by seconds/minutes/hours/days/whatever at a time.

On Linux, the kernel is actually responsible for keeping time, and has a
userland API that ntpd uses to skew the time, telling the  kernel to
measure say 999 998 instead of 1 000 000  ticks if the clock is slightly
fast, until real time catches up, or 1 000 005 ticks instead of 1 000 000,
if the clock is slightly slow and needs to catch up to real time.  So,
yes, ntpd /is/ adjusting the time, but ideally, not fast enough that
anything can really notice it.

Note also that ntpd keeps track of how far your system has drifted from
the rest of the world, each time it checks in, and uses that to tweak
system clock speed accordingly.  If you go adjusting the clock yourself
while ntpd is running, it's going to think something's drastically wrong
with the system that it gained or lost so much time so fast, and will
REALLY put the screws on that skew, thereby REALLY screwing up the system
for a few days, as ntpd adjusts the clock first one way, then the other,
until it figures out the real drift of the system once again.  This is why
I said turn off ntpd before you go screwing with the clock, even the
little bit of setting the hardware clock from the software clock and then
the software clock from the hardware clock, as you do by running
/etc/init.d/clock restart, because even the 100th of a second leap that
might happen setting the time between the two, would be enough to screw up
ntpd's calculations and set your time swinging that much more than it
should, for a day or two.  Once it knows how accurate your system is on
its own, ntpd can make it /really/ accurate, to single milliseconds within
the day, but it can't do it if you keep screwing with the time yourself! 
ALWAYS turn ntpd off when you go screwing with the clock, for /whatever/
reason!

FWIW, if you've been screwing with the clock enough to mix up ntpd and
just want it to start over from scratch, shut it down (of course), and
remove it's drift file, located by default on Gentoo at
/var/lib/ntp/ntp.drift (I think, mine's in /etc/ntp/drift, as set in
/etc/ntp.conf, but if the ntp.conf.orig I have here is correct, Gentoo's
default is that /var location).

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.  If you look in the logs, probably 15
minutes to a couple hours  later (assuming it has had time to get
familiar with the system and how much it normally needs adjusted), it will
say it's properly synced to its satisfaction, having skewed the system
(software) clock by an appropriate degree, and then set out to maintain
that sync over the longer term.

Do note that there's an ntp-client config file in /etc/conf.d also, which
you can use to tweak settings if desired.  However, Gentoo's policy of
setting things up so they "just work" if possible, is as usual in force
here, and it should need no changes from you to work properly, once the
initscript has been added to the proper runlevel, of course.

Once you have it set up correctly, your system will boot and once the
internet connection is up, ntp-client will start and do any "gross"
adjustment necessary to the system time.  After it's done, ntpd will run
and keep your system very accurately synced with the rest of the world,
timewise.  When you shutdown, if you have clock configured to do so, it
will sync the hardware clock to the software clock that ntpd has been
managing so well while the system was up, keeping the hardware clock
fairly accurate as well, even when you only boot to no-net single-user
mode or whatever for system maintenance.

One more thing to cover:  If you suspend your system, you will want to
ensure that ntpd is shut down before suspend, and ntp-client and ntpd are
restarted after resume.  Again, this  ensures that ntpd is only tracking a
running system, so doesn't get any strange and unnecessary jerks in its
idea of how the system is keeping time, thereby keeping it as accurate as
possible, which is the idea, after all!  =8^)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Recent clock problems

[John Myers]

[-- Attachment #1: Type: text/plain, Size: 574 bytes --]

On Saturday 11 February 2006 10:51, Mark Knecht wrote:
> I suppose this could be a bad battery or something like that but this
> is my newest system and is only about 6 months old so I doubt it.
> Also, I had this problem for about 3 months on my old laptop when
> support for that chipset came out. I'm therefore assuming it's really
> a Linux problem of some type.

You might still try the battery though. IIRC, they're not exactly expensive, 
and you could just have a poorly manufactured one.

-- 
# 
# electronerd, the electronerdian from electronerdia
#

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

[gentoo-amd64] [SOLVED] Recent clock problems

[Mark Knecht]

On 2/11/06, Duncan <1i5t5.duncan@cox.net> wrote:
> Mark Knecht posted
> <5bdc1c8b0602110941y446deb24qc519fcb40298136a@mail.gmail.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@gentoo.org mailing list

Re: [gentoo-amd64] Recent clock problems

[Barry.SCHWARTZ]

[-- Attachment #1: Type: text/plain, Size: 1124 bytes --]

Mark Knecht <markknecht@gmail.com> wrote:
>    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.

I would guess ntpd, which is part of why I use net-misc/openntpd
instead of regular ntpd (which I used to use).

The battery doesn't have to be bad, it just has to be making a poor
connection, so you might try taking it out and putting it back
in. This sometimes clears up other problems as well, by power-cycling
parts that don't normally get power-cycled. (I had to do it once after
a BIOS flash upgrade.)

-- 
Barry.SCHWARTZ@chemoelectric.org   http://www.chemoelectric.org
Esperantistoj rajtas skribi al Bojo ĉe chemoelectric.org.
  'Democracies don't war; democracies are peaceful countries.' - Bush
  (http://www.whitehouse.gov/news/releases/2005/12/20051219-2.html)

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-amd64] [SOLVED] Recent clock problems

[Barry.SCHWARTZ]

[-- Attachment #1: Type: text/plain, Size: 643 bytes --]

Mark Knecht <markknecht@gmail.com> wrote:
> 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.

The constant changes in what ntp requires are the main reason I
switched to openntpd.

-- 
Barry.SCHWARTZ@chemoelectric.org   http://www.chemoelectric.org
Esperantistoj rajtas skribi al Bojo ĉe chemoelectric.org.
  'Democracies don't war; democracies are peaceful countries.' - Bush
  (http://www.whitehouse.gov/news/releases/2005/12/20051219-2.html)

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-amd64] [SOLVED] Recent clock problems

[Hemmann, Volker Armin]

On Saturday 11 February 2006 23:14, Mark Knecht wrote:
>
>
> 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.)

the hardware clock is what you set in your bios.

>
> Can I check this somehow, like going into BIOS?

yes, that is exactly where it is sitting.

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

please don't forget to remove /etc/adjtime if you change settings.
In fact, it does not hurt to remove it regularly, especially if you add 
ntp-client to your default runlevel.

>
> 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.

some time ago, you installed ntp, and you run it and it was ok.
today ntpd is the server daemon, for syncronizing several machines of a 
network, ntp-client the part, that sets your clock.
please run ntp-client and forget ntpd.

>
> Thanks Duncan! As usual your answers are very through and well
> written

and sometimes he is wrong, but his postings are so long that most people don't 
bother to search for the errors.

-- 
gentoo-amd64@gentoo.org mailing list

[gentoo-amd64] Re: [SOLVED] Recent clock problems

[Duncan]

Hemmann, Volker Armin posted
<200602112357.00015.volker.armin.hemmann@tu-clausthal.de>, excerpted
below,  on Sat, 11 Feb 2006 23:56:59 +0100:

> today ntpd is the server daemon, for syncronizing several machines of a 
> network, ntp-client the part, that sets your clock.
> please run ntp-client and forget ntpd.

That's not exactly correct.  Correct that ntpd is a server that /can/
serve to sync a number of machines, but in so doing, it keeps /far/ better
time than simply stepping the clock with ntp-client will do.  ntp-client
is a single-shot deal that syncs your time with whatever server you are
syncing to every time you run it -- that's  it.  ntpd will, once it knows
how your computer behaves time-wise, be able to keep your computer much
more accurate than it'd be on its own, even without a net connection or
external time source to syncronize with -- and much more accurately than
ntp-client can do as well, because ntp-client is doing jerky adjustments
only when its run, while ntpd does gradual but constant tweaking to keep
the system exactly where it needs to be, time-wise. Once it knows how your
computer runs, and has adjusted accordingly, it only uses occasional
external synchronization, to ensure nothing you've done has /changed/ the
way it syncronizes.

It's all in the ntp documentation, available to be read by anybody with an
interest in the subject or a need to know how it works.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Recent clock problems

[Paul de Vrieze]

[-- Attachment #1: Type: text/plain, Size: 3185 bytes --]

On Saturday 11 February 2006 20:39, Hemmann, Volker Armin wrote:
> On Saturday 11 February 2006 18:41, Mark Knecht wrote:
> > 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.
> >
> > 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.
>
> it does not really matter which one you choose.

Local clock has issues with daylight saving time, so if possible (i.a. no 
windows on the machine, or you don't care about it's clock) use UTC time 
in the hardware clock. UTC time does not change about.

>
> > QUESTION 2: date
> >
> > date only sets a software clock, correct? Is this all the system uses
> > after boot?
>

After boot, the system clock is gone. The system clock is maintained by 
the operating system while the system runs. When shutting down the 
current system time is written to the hardware clock, this time is then 
retrieved when booting. In this retrieval the contents of /etc/adjtime 
are taken into account to correct for systematic drift of the hardware 
clock.

Hardware clocks, especially the cheap kind that's in a computer, are not 
known for their acuracy. This lack of acuracy is rather constant for a 
particular clock though. It is called systematic drift. As it is 
predictable it can be corrected. This does however assume that the system 
clock is more correct than the hardware clock.

When you have clock issues, the systematic drift is often completely 
mistaken. It is then often safe to remove /etc/adjtime and let hwclock 
forget it's history (it's incorrect anyway). It will be recreated 
automatically. (Do remember though that if you run it manually, you must 
specify -utc to indicate the usage of utc for the system clock).

> > QUESTION 3: hwclock -w
> >
> > This is supposed to write the time in the system's software clock
> > into hardware, correct?
>
> yes

or "hwclock -systohc"

>
> > QUESTION 4:
> >
> > Does ntpd actually update the system clock, or is it another layer
> > yet on top. If I use ntpd and then do hwclock -w does an accurate
> > time get written to the hardware clock?

ntpd only sets the system clock, not the hardware clock. If the clock is 
acurate (ntpd is running properly and the clock servers are acurate 
themselves), "hwclock -systohc" will set the hardware clock properly. 
Given that you have configured things properly that is.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-amd64] Recent clock problems

[Hemmann, Volker Armin]

On Monday 13 February 2006 10:04, Paul de Vrieze wrote:


> >
> > it does not really matter which one you choose.
>
> Local clock has issues with daylight saving time, so if possible (i.a. no
> windows on the machine, or you don't care about it's clock) use UTC time
> in the hardware clock. UTC time does not change about.

well, I am living in the MET timezone.
My setting is 'local', my bios clock is set to the local time.

I had never problems with daylight saving time...  I must doing something 
wrong....
-- 
gentoo-amd64@gentoo.org mailing list

[gentoo-amd64] Re: Recent clock problems

[Duncan]

Hemmann, Volker Armin posted
<200602131434.19508.volker.armin.hemmann@tu-clausthal.de>, excerpted
below,  on Mon, 13 Feb 2006 14:34:19 +0100:

> well, I am living in the MET timezone.

LOL!  For a moment I read that as "the NET timezone"!

I suppose that'd have to be Swatch's 1000-beat/day time, which is
zeroed on UTC.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Recent clock problems

[Dmitri Pogosyan]

Is your /etc/localtime points to the right time zone ? 
 
e.g, for me 
 
/etc/localtime -> /usr/share/zoneinfo/Canada/Mountain 
 
 
> On Monday 13 February 2006 10:04, Paul de Vrieze wrote: 
>  
> > > 
> > > it does not really matter which one you choose. 
> > 
> > Local clock has issues with daylight saving time, so if possible (i.a. no 
> > windows on the machine, or you don't care about it's clock) use UTC time 
> > in the hardware clock. UTC time does not change about. 
>  
> well, I am living in the MET timezone. 
> My setting is 'local', my bios clock is set to the local time. 
>  
> I had never problems with daylight saving time...  I must doing something  
> wrong.... 
> --  
> gentoo-amd64@gentoo.org mailing list 
 
 
 
-- 
Dmitri Pogosyan            Department of Physics 
Associate Professor        University of Alberta 
tel 1-780-492-2150         412 Avadh Bhatia Physics Labs 
fax 1-780-492-0714         Edmonton, AB, T6G 2J1, CANADA 
 
 
-- 
gentoo-amd64@gentoo.org mailing list

[gentoo-amd64] [OT] Swatch's internet time

[Simon Stelling]

Duncan wrote:
> I suppose that'd have to be Swatch's 1000-beat/day time, which is
> zeroed on UTC.

Wrong, it's zeroed on CE(S)T, as Switzerland (since Swatch is a swiss company)
lies within that time zone.

-- 
Simon Stelling
Gentoo/AMD64 Operational Co-Lead
blubb@gentoo.org
-- 
gentoo-amd64@gentoo.org mailing list

[gentoo-amd64] Re: [OT] Swatch's internet time

[Duncan]

Simon Stelling posted <43F0C297.3050507@gentoo.org>, excerpted below,  on
Mon, 13 Feb 2006 18:32:07 +0100:

> Duncan wrote:
>> I suppose that'd have to be Swatch's 1000-beat/day time, which is
>> zeroed on UTC.
> 
> Wrong, it's zeroed on CE(S)T, as Switzerland (since Swatch is a swiss company)
> lies within that time zone.

Thanks for the correction.  I was /sure/ it was UTC, or I certainly would
have put an AFAIK or other qualifier in there, but it seems I was /surely/
wrong!

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Re: Recent clock problems

[Tres Melton]

[-- Attachment #1: Type: text/plain, Size: 5058 bytes --]

On Sat, 2006-02-11 at 13:07 -0700, Duncan wrote:
> Mark Knecht posted
> <5bdc1c8b0602110941y446deb24qc519fcb40298136a@mail.gmail.com>, excerpted
> below,  on Sat, 11 Feb 2006 09:41:20 -0800:
> 
> > Hello,
...
> > QUESTION 4:
> > 
> > Does ntpd actually update the system clock, or is it another layer yet
> > on top. If I use ntpd and then do hwclock -w does an accurate time get
> > written to the hardware clock?
> 
> I don't like the term "system" clock in this context, because it's
> ambiguous as to whether you are referring to hardware or software.  That's
> why I used system/software clock or the like a couple times above, to make
> it absolutely clear which I was referring to.
> 
> That said, "system clock" normally refers to the software clock that the
> system uses while running, and yes, ntpd /does/ update it directly --
> well, sort-of.  <g>  Don't worry, the confusion is normal and under the
> circumstances entirely understandable, but there's a logical explanation
> that makes sense once you understand what's going on.
> 
> Here's the deal.  ntpd was developed to be used in situations where
> various running programs might be making critical assumptions about the
> system time -- namely that it always moves forward, never backward.  To
> have the time move backward, if the machine's an online server in some
> applications, would be /very/ /bad/!  Thus, by default and if at all

From the ntpd man page:
This may on occasion cause the clock to be set backwards if the local
clock time is more than 128 s in the future relative  to  the  server.
In some  applications,  this  behavior  may  be unacceptable. If the -x
option is included on the command line, the clock will never be stepped
and only slew corrections will be used.


> possible (if the time isn't off by days or years), ntpd will normally
> choose to /skew/ the time, adjusting how fast the machine advances time by
> a few parts per million, rather than stepping it either forward or
> backward by seconds/minutes/hours/days/whatever at a time.
> 
> On Linux, the kernel is actually responsible for keeping time, and has a
> userland API that ntpd uses to skew the time, telling the  kernel to
> measure say 999 998 instead of 1 000 000  ticks if the clock is slightly
> fast, until real time catches up, or 1 000 005 ticks instead of 1 000 000,
> if the clock is slightly slow and needs to catch up to real time.  So,
> yes, ntpd /is/ adjusting the time, but ideally, not fast enough that
> anything can really notice it.
> 
> Note also that ntpd keeps track of how far your system has drifted from
> the rest of the world, each time it checks in, and uses that to tweak
> system clock speed accordingly.  If you go adjusting the clock yourself
> while ntpd is running, it's going to think something's drastically wrong
> with the system that it gained or lost so much time so fast, and will
> REALLY put the screws on that skew, thereby REALLY screwing up the system
> for a few days, as ntpd adjusts the clock first one way, then the other,

man ntpd:  ... once the clock  has  been  set,  an  error greater than
1000s will cause ntpd to exit anyway.

> until it figures out the real drift of the system once again.  This is why
> I said turn off ntpd before you go screwing with the clock, even the
> little bit of setting the hardware clock from the software clock and then
> the software clock from the hardware clock, as you do by running
> /etc/init.d/clock restart, because even the 100th of a second leap that
> might happen setting the time between the two, would be enough to screw up
> ntpd's calculations and set your time swinging that much more than it
> should, for a day or two.  Once it knows how accurate your system is on

man ntpd:  ... about 2,000 s for each second the clock is  outside  the
acceptable range.  ... 

In spite of the above precautions, sometimes when large frequency errors
are present the resulting time offsets  stray  outside  the 128-ms
range  and  an  eventual  step or slew time correction is required. If
following such a correction the frequency error is so large that the
first sample is outside the acceptable range, ntpd enters the same state
as when the ntp.drift file is  not  present.  The  intent  of  this
behavior  is  to quickly correct the frequency and restore operation to
the normal tracking mode. In the most extreme cases ( time.ien.it comes
to mind), there may be occasional step/slew corrections and subsequent
frequency  corrections.  It helps in these cases to use the burst
keyword when configuring the server.

------------------------
Just had a couple of issues with that.  :)


> -- 
> Duncan - List replies preferred.   No HTML msgs.
> "Every nonfree program has a lord, a master --
> and if you use the program, he is your master."  Richard Stallman in
> http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html
> 
> 
Cheers Duncan,
-- 
Tres Melton
IRC & Gentoo: RiverRat

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[gentoo-amd64] Re: Re: Recent clock problems

[Duncan]

Tres Melton posted <1140023157.10822.32.camel@thor.tres.org>, excerpted
below,  on Wed, 15 Feb 2006 10:05:57 -0700:

> Just had a couple of issues with that.  :)

Thanks for the detail corrections! =8^)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


-- 
gentoo-amd64@gentoo.org mailing list