1 |
On 03/17/2016 10:59 PM, Bill Kenworthy wrote: |
2 |
> On 18/03/16 05:14, Alan McKinnon wrote: |
3 |
>> On 17/03/2016 22:02, Håkon Alstadheim wrote: |
4 |
>>> On 03/17/2016 02:03 PM, Bill Kenworthy wrote: |
5 |
>>>> On 17/03/16 20:26, Alan McKinnon wrote: |
6 |
>>>>> On 17/03/2016 08:50, Håkon Alstadheim wrote: |
7 |
>>>>>> I have a server SUPPOSED to be running 24/7, but every once in a while |
8 |
>>>>>> during a prolonged absence the box will go down. The Real Time Clock |
9 |
>>>>>> will drift, and in the rush to get the box up again I let everything |
10 |
>>>>>> boot up automatically and get both wrong time on the main systems, and |
11 |
>>>>>> different times on the various systems. |
12 |
>>>>>> |
13 |
>>>>>> My setup has a main server which does NTP, but with no direct link to |
14 |
>>>>>> the outside. Router&firewall /have/ to be booted booted later (dumb |
15 |
>>>>>> setup, don't ask), after which I can finally get correct time from NTP. |
16 |
>>>>>> |
17 |
>>>>>> NTP initiates "11 minute mode", which makes /etc/adjtime useless as far |
18 |
>>>>>> as I understand. Anybody have a /correct/ way to account for RTC drift |
19 |
>>>>>> on a box running ntpd? Right now I have a ---file in |
20 |
>>>>>> /etc/cron.d/time-bad like so: |
21 |
>>>>>> * * * * * root adjtimex -S 5 >/dev/null 2>&1 </dev/null |
22 |
>>>>>> --- |
23 |
>>>>>> |
24 |
>>>>>> Combined with an old-fashioned setup for hwclock during boot and |
25 |
>>>>>> shutdown. This feels really wrong, and I have no idea what I am doing. |
26 |
>>>>>> |
27 |
>>>>>> TLDR: Anybody have a /correct/ way to account for RTC drift on a box |
28 |
>>>>>> running ntpd? |
29 |
>>>>>> |
30 |
>>>>>> |
31 |
> Have you looked at adjtimex ... its in portage |
32 |
> |
33 |
> |
34 |
> From the man page ... |
35 |
> "For a standalone or intermittently connected machine, where it’s not |
36 |
> ossible to run ntpd, |
37 |
I /can/ and do run ntpd once everything is up and running. |
38 |
> you may use adjtimex instead to correct the sys-tem |
39 |
> clock |
40 |
System clock is fine, what I'm after is drift of the RTC clock ("bios |
41 |
clock"). Ntp does nothing for that, as far as I understand. Now, I'd be |
42 |
very happy if someone could tell me I've misunderstood. |
43 |
> for systematic drift. |
44 |
|
45 |
> There are several ways to estimate the drift rate. If your |
46 |
> computer can be connected to the net, you might run ntpd for at least |
47 |
> several hours and run "adjtimex --print" to learn what values of tick |
48 |
> and freq it settled on. Alternately, you could estimate values using as |
49 |
> a reference the CMOS clock (see the --compare and --adjust switches), |
50 |
> another host (see --host and --review), or some other source of time |
51 |
> (see --watch and --review). You could then add a line to rc.local |
52 |
> invoking adjtimex, or configure /etc/init.d/adjtimex or |
53 |
> /etc/default/adjtimex, to set those parameters each time you reboot." |
54 |
> |
55 |
> Used it at one time for dialup which approximates your condition. |
56 |
> |
57 |
> |