On 17/03/2016 22:02, Håkon Alstadheim wrote:
> On 03/17/2016 02:03 PM, Bill Kenworthy wrote:
>> On 17/03/16 20:26, Alan McKinnon wrote:
>>> On 17/03/2016 08:50, Håkon Alstadheim wrote:
>>>> I have a server SUPPOSED to be running 24/7, but every once in a while
>>>> during a prolonged absence the box will go down. The Real Time Clock
>>>> will drift, and in the rush to get the box up again I let everything
>>>> boot up automatically and get both wrong time on the main systems, and
>>>> different times on the various systems.
>>>>
>>>> My setup has a main server which does NTP, but with no direct link to
>>>> the outside. Router&firewall /have/ to be booted booted later (dumb
>>>> setup, don't ask), after which I can finally get correct time from NTP.
>>>>
>>>> NTP initiates "11 minute mode", which makes /etc/adjtime useless as far
>>>> as I understand. Anybody have a /correct/ way to account for RTC drift
>>>> on a box running ntpd? Right now I have a ---file in
>>>> /etc/cron.d/time-bad like so:
>>>> * * * * * root adjtimex -S 5 >/dev/null 2>&1 </dev/null
>>>> ---
>>>>
>>>> Combined with an old-fashioned setup for hwclock during boot and
>>>> shutdown. This feels really wrong, and I have no idea what I am doing.
>>>>
>>>> TLDR: Anybody have a /correct/ way to account for RTC drift on a box
>>>> running ntpd?
>>>>
>>>>
>>>
>>> When the box was off, all questions of accurate ntp tracking are moot.
>>> ntp is designed around the idea that every second happens but from your
>>> machine's point of view they didn't happen since it was powered down.
>>>
>>> I would go the really simple route and force ntpdate to run once during
>>> boot up before ntpd is started, thereby avoiding the entire issue.
> Why can't I have proper drift information for my RTC ("bios clock") ?
> The old way ( where "system-time as set by ntp" minus "RTC time"
> gives "drift-value" written to /etc/adjtime ) used to work perfectly
> for me for several years. Is there no canonical way of getting that
> these days?
>
> My problem is that my WAN connection can not be brought up until well
> after the main server is up (stupid I know, but rearranging things
> entails a major overhaul). Thus a bios clock without drift information
> gives me a choice between ntpdate (which messes up my logs) and ntp with
> incremental adjustments (which might leave clocks wrong for several days).
>
> I really need the logs to be on the same clock for all systems. Don't
> ask, just assume I know why it's called bleeding edge . I also really
> need sub-minute accuracy on all clocks. I suppose I should try running
> ntpdate on everything once the WAN connection is up, just to see how bad
> the mess is.
I think your answer will be "the mess will be horribly bad".
Now that I understand your problem better, I don't know how to solve it.
If man pages don't provide a solution (and there must be a way to do it
surely) then James' idea of a cheap external time source sounds good.
On time sources, for the life of me I cannot understand why those in
computers suck so badly. The name-no brand one on my wrist, costing 30
bucks from a dodgy Chinese dude on the street corner, is easily accurate
to a second a month. It gets bumped, whacked a lot, immersed in water
frequently and subjected to temperatures sub-zero up to 40 deg C + in
direct African sunlight (hot enough to damage LCDs and make them bleed).
And it stays about a second a month, despite being cheap junk and
running off a shitty battery.
So why are the ones in my computer about as accurate as a sundial
without a reference? Always wondered about that.
--
Alan McKinnon
alan.mckin...@gmail.com
