1 |
On Saturday 11 February 2006 20:39, Hemmann, Volker Armin wrote: |
2 |
> On Saturday 11 February 2006 18:41, Mark Knecht wrote: |
3 |
> > Hello, |
4 |
> > Just in the last week or so my AMD64 machine has started to |
5 |
> > exhibit problems with the clock. Maybe it's a hardware problem, or |
6 |
> > possibly it's some new ntpd issue after updates. At boot time it |
7 |
> > seems to be coming up with semi-random times. This is causing me to |
8 |
> > ask a few questions and try to learn a bit more about how this |
9 |
> > actually works under Linux. Thanks in advance. |
10 |
> > |
11 |
> > QUESTION 1: UTC vs. local |
12 |
> > |
13 |
> > In /etc/conf.d/clock I can choose UTC vs. local. Does this refer to |
14 |
> > the time I set in the hardware clock or something else? Nominally |
15 |
> > it's easier sitting here in California to set the hardware clock to |
16 |
> > California time. Is there any problem with doing this? If I |
17 |
> > understand the comments I should be using 'local' but the default |
18 |
> > seemed to be UTC. |
19 |
> |
20 |
> it does not really matter which one you choose. |
21 |
|
22 |
Local clock has issues with daylight saving time, so if possible (i.a. no |
23 |
windows on the machine, or you don't care about it's clock) use UTC time |
24 |
in the hardware clock. UTC time does not change about. |
25 |
|
26 |
> |
27 |
> > QUESTION 2: date |
28 |
> > |
29 |
> > date only sets a software clock, correct? Is this all the system uses |
30 |
> > after boot? |
31 |
> |
32 |
|
33 |
After boot, the system clock is gone. The system clock is maintained by |
34 |
the operating system while the system runs. When shutting down the |
35 |
current system time is written to the hardware clock, this time is then |
36 |
retrieved when booting. In this retrieval the contents of /etc/adjtime |
37 |
are taken into account to correct for systematic drift of the hardware |
38 |
clock. |
39 |
|
40 |
Hardware clocks, especially the cheap kind that's in a computer, are not |
41 |
known for their acuracy. This lack of acuracy is rather constant for a |
42 |
particular clock though. It is called systematic drift. As it is |
43 |
predictable it can be corrected. This does however assume that the system |
44 |
clock is more correct than the hardware clock. |
45 |
|
46 |
When you have clock issues, the systematic drift is often completely |
47 |
mistaken. It is then often safe to remove /etc/adjtime and let hwclock |
48 |
forget it's history (it's incorrect anyway). It will be recreated |
49 |
automatically. (Do remember though that if you run it manually, you must |
50 |
specify -utc to indicate the usage of utc for the system clock). |
51 |
|
52 |
> > QUESTION 3: hwclock -w |
53 |
> > |
54 |
> > This is supposed to write the time in the system's software clock |
55 |
> > into hardware, correct? |
56 |
> |
57 |
> yes |
58 |
|
59 |
or "hwclock -systohc" |
60 |
|
61 |
> |
62 |
> > QUESTION 4: |
63 |
> > |
64 |
> > Does ntpd actually update the system clock, or is it another layer |
65 |
> > yet on top. If I use ntpd and then do hwclock -w does an accurate |
66 |
> > time get written to the hardware clock? |
67 |
|
68 |
ntpd only sets the system clock, not the hardware clock. If the clock is |
69 |
acurate (ntpd is running properly and the clock servers are acurate |
70 |
themselves), "hwclock -systohc" will set the hardware clock properly. |
71 |
Given that you have configured things properly that is. |
72 |
|
73 |
Paul |
74 |
|
75 |
-- |
76 |
Paul de Vrieze |
77 |
Gentoo Developer |
78 |
Mail: pauldv@g.o |
79 |
Homepage: http://www.devrieze.net |