Re: [gentoo-amd64] Recent clock problems

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

[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

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

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

[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

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