1 |
Yassen Damyanov posted <4399524F.5050101@×××××××.de>, excerpted below, on |
2 |
Fri, 09 Dec 2005 11:45:51 +0200: |
3 |
|
4 |
> I'm looking for anyone using clockspeed successfully on |
5 |
> amd64. |
6 |
> |
7 |
> I have a success story 2 years ago using it on a Redhat 6 |
8 |
> system to correct a terribly drifting clock. It did a |
9 |
> *perfect* job for me. |
10 |
> |
11 |
> Now I am trying to use it to correct a clock that speeds up |
12 |
> about 1 sec. per hour, this on a Gentoo Linux / amd64 box, |
13 |
> and it does not work for me. |
14 |
|
15 |
[Subject typo corrected. I wouldn't bother except it's likely many never |
16 |
even saw this due to spam filters. Maybe you'll get a better response |
17 |
with it corrected? Worth a try, anyway.] |
18 |
|
19 |
I have no experience with clockspeed. Perhaps someone else will reply |
20 |
that does, but meanwhile, something I've a bit more experience with since |
21 |
I run it myself, I'd guess the more usual solution to that sort of issue |
22 |
is to run ntpd and keep yourself synced with multiple NTP servers |
23 |
elsewhere on the net. Once it has been running a while and established a |
24 |
decent record of how much your local clock drifts, it won't have to |
25 |
connect often to the network, as it'll know how much to adjust without the |
26 |
external input. |
27 |
|
28 |
If you don't want to use those resources, then setting a cron job to |
29 |
run ntpclient restart every hour or two would work, tho the adjustment |
30 |
would be more drastic and could cause issues with anything relying on the |
31 |
system clock not to go backward, even by a second or two. |
32 |
|
33 |
-- |
34 |
Duncan - List replies preferred. No HTML msgs. |
35 |
"Every nonfree program has a lord, a master -- |
36 |
and if you use the program, he is your master." Richard Stallman in |
37 |
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html |
38 |
|
39 |
|
40 |
-- |
41 |
gentoo-amd64@g.o mailing list |