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.
Sometimes correctness really doesn't matter, this looks like one of those.
alan
add a cheap gps setup as the reference clock to the server,
That sounds like a real option. I have an old Nokia N900 lying around
with a broken usb-port, so I'd need to solder in a power lead. Any
pointers for how to read time signal from the gps on a maemo system?
or even
better is a dedicated time server (either a real one or a raspberry
pi/gps) on the network if you have internal connectivity. Going super
cheap, but not quite as accurate for me was an arduino and rtc on a
bluetooth pan for when the network was down but I needed a reference (to
power up the real server :).
google "arduino time server" for plenty of options :)
This led me to finding some serial-port connected gps modules.
Serial-ports I have, so this is sounding good. 35 to 40 euro for a gps
device when hwclock and /etc/adjtime should give ballpark-correct time
on boot makes me hate this though.
This reminds me one reason I need a valid time is my DVB-T TV-receiver
card. It should be possible to find a clock source in the broadcast
stream. I'll research that first, while I leave my "adjtime -S 5 " hack
running, even though I still don't know if that makes any sense at all.
At least now there is something different from "0.0000" in the
driftvalue, which gives me some hope I'm on to something.
