Re: [gentoo-user] Getting a valid /etc/adjtime while using ntpd ?
On Friday 18 Mar 2016 06:01:17 Bill Kenworthy wrote: > On 18/03/16 05:59, Bill Kenworthy wrote: > > On 18/03/16 05:14, Alan McKinnon wrote: > >> 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 /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 >> --- > >> > >> 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? > > > > Have you looked at adjtimex ... its in portage > > > > > > From the man page ... > > "For a standalone or intermittently connected machine, where it’s not > > ossible to run ntpd, you may use adjtimex instead to correct the sys-tem > > clock for systematic drift. > > > >There are several ways to estimate the drift rate. If your > > > > computer can be connected to the net, you might run ntpd for at least > > several hours and run "adjtimex --print" to learn what values of tick > > and freq it settled on. Alternately, you could estimate values using as > > a reference the CMOS clock (see the --compare and --adjust switches), > > another host (see --host and --review), or some other source of time > > (see --watch and --review). You could then add a line to rc.local > > invoking adjtimex, or configure /etc/init.d/adjtimex or > > /etc/default/adjtimex, to set those parameters each time you reboot." > > > > Used it at one time for dialup which approximates your condition. > > > > BillK > > forget it ... I forgot that's where you started from ... must be getting > old :( Nobody mentioned net-misc/chrony. Would it be more appropriate for this use case? -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Getting a valid /etc/adjtime while using ntpd ?
On 18/03/16 05:59, Bill Kenworthy wrote: > On 18/03/16 05:14, Alan McKinnon wrote: >> 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 /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 > --- >> >> 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? >> >> > > > Have you looked at adjtimex ... its in portage > > > From the man page ... > "For a standalone or intermittently connected machine, where it’s not > ossible to run ntpd, you may use adjtimex instead to correct the sys-tem > clock for systematic drift. > >There are several ways to estimate the drift rate. If your > computer can be connected to the net, you might run ntpd for at least > several hours and run "adjtimex --print" to learn what values of tick > and freq it settled on. Alternately, you could estimate values using as > a reference the CMOS clock (see the --compare and --adjust switches), > another host (see --host and --review), or some other source of time > (see --watch and --review). You could then add a line to rc.local > invoking adjtimex, or configure /etc/init.d/adjtimex or > /etc/default/adjtimex, to set those parameters each time you reboot." > > Used it at one time for dialup which approximates your condition. > > BillK > > forget it ... I forgot that's where you started from ... must be getting old :(
Re: [gentoo-user] Getting a valid /etc/adjtime while using ntpd ?
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 /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 > --- >> >> 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. > 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, 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 :) BillK
Re: [gentoo-user] Getting a valid /etc/adjtime while using ntpd ?
On 18/03/16 05:14, Alan McKinnon wrote: > 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 /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 --- > > 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? > > Have you looked at adjtimex ... its in portage >From the man page ... "For a standalone or intermittently connected machine, where it’s not ossible to run ntpd, you may use adjtimex instead to correct the sys-tem clock for systematic drift. There are several ways to estimate the drift rate. If your computer can be connected to the net, you might run ntpd for at least several hours and run "adjtimex --print" to learn what values of tick and freq it settled on. Alternately, you could estimate values using as a reference the CMOS clock (see the --compare and --adjust switches), another host (see --host and --review), or some other source of time (see --watch and --review). You could then add a line to rc.local invoking adjtimex, or configure /etc/init.d/adjtimex or /etc/default/adjtimex, to set those parameters each time you reboot." Used it at one time for dialup which approximates your condition. BillK
Re: [gentoo-user] Getting a valid /etc/adjtime while using ntpd ?
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 /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 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. Sometimes correctness really doesn't matter, this looks like one of those. alan
Re: [gentoo-user] Getting a valid /etc/adjtime while using ntpd ?
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 /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 >>> ---
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
Re: [gentoo-user] Getting a valid /etc/adjtime while using ntpd ?
On 03/17/2016 10:59 PM, Bill Kenworthy wrote:
On 18/03/16 05:14, Alan McKinnon wrote:
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 /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
Have you looked at adjtimex ... its in portage
From the man page ...
"For a standalone or intermittently connected machine, where it’s not
ossible to run ntpd,
I /can/ and do run ntpd once everything is up and running.
you may use adjtimex instead to correct the sys-tem
clock
System clock is fine, what I'm after is drift of the RTC clock ("bios
clock"). Ntp does nothing for that, as far as I understand. Now, I'd be
very happy if someone could tell me I've misunderstood.
for systematic drift.
There are several ways to estimate the drift rate. If your
computer can be connected to the net, you might run ntpd for at least
several hours and run "adjtimex --print" to learn what values of tick
and freq it settled on. Alternately, you could estimate values using as
a reference the CMOS clock (see the --compare and --adjust switches),
another host (see --host and --review), or some other source of time
(see --watch and --review). You could then add a line to rc.local
invoking adjtimex, or configure /etc/init.d/adjtimex or
/etc/default/adjtimex, to set those parameters each time you reboot."
Used it at one time for dialup which approximates your condition.
Re: [gentoo-user] Getting a valid /etc/adjtime while using ntpd ?
On 03/17/2016 11:31 PM, Mick wrote: On Friday 18 Mar 2016 06:01:17 Bill Kenworthy wrote: On 18/03/16 05:59, Bill Kenworthy wrote: On 18/03/16 05:14, Alan McKinnon wrote: 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 /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 Have you looked at adjtimex ... its in portage From the man page ... "For a standalone or intermittently connected machine, where it’s not ossible to run ntpd, you may use adjtimex instead to correct the sys-tem clock for systematic drift. There are several ways to estimate the drift rate. If your computer can be connected to the net, you might run ntpd for at least several hours and run "adjtimex --print" to learn what values of tick and freq it settled on. Alternately, you could estimate values using as a reference the CMOS clock (see the --compare and --adjust switches), another host (see --host and --review), or some other source of time (see --watch and --review). You could then add a line to rc.local invoking adjtimex, or configure /etc/init.d/adjtimex or /etc/default/adjtimex, to set those parameters each time you reboot." Used it at one time for dialup which approximates your condition. BillK forget it ... I forgot that's where you started from ... must be getting old :( Nobody mentioned net-misc/chrony. Would it be more appropriate for this use case? I see it also claims to contain an ntp server. I'll check it out.
Re: [gentoo-user] Getting a valid /etc/adjtime while using ntpd ?
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 /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
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." in the
driftvalue, which gives me some hope I'm on to something.
Re: [gentoo-user] Getting a valid /etc/adjtime while using ntpd ?
On Friday 18 Mar 2016 09:38:50 Håkon Alstadheim wrote: > On 03/17/2016 11:31 PM, Mick wrote: > > On Friday 18 Mar 2016 06:01:17 Bill Kenworthy wrote: > >> On 18/03/16 05:59, Bill Kenworthy wrote: > >>> On 18/03/16 05:14, Alan McKinnon wrote: > 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 /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 --- > > 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? > >>> > >>> Have you looked at adjtimex ... its in portage > >>> > >>> From the man page ... > >>> > >>> "For a standalone or intermittently connected machine, where it’s not > >>> ossible to run ntpd, you may use adjtimex instead to correct the sys-tem > >>> clock for systematic drift. > >>> > >>> There are several ways to estimate the drift rate. If your > >>> > >>> computer can be connected to the net, you might run ntpd for at least > >>> several hours and run "adjtimex --print" to learn what values of tick > >>> and freq it settled on. Alternately, you could estimate values using as > >>> a reference the CMOS clock (see the --compare and --adjust switches), > >>> another host (see --host and --review), or some other source of time > >>> (see --watch and --review). You could then add a line to rc.local > >>> invoking adjtimex, or configure /etc/init.d/adjtimex or > >>> /etc/default/adjtimex, to set those parameters each time you reboot." > >>> > >>> Used it at one time for dialup which approximates your condition. > >>> > >>> BillK > >> > >> forget it ... I forgot that's where you started from ... must be getting > >> old :( > > > > Nobody mentioned net-misc/chrony. Would it be more appropriate for this > > use case? > > I see it also claims to contain an ntp server. I'll check it out. I have found that when RTC starts playing up the BIOS MoBo battery probably needs replacing. Have you tried changing it/measuring its voltage? -- Regards, Mick signature.asc Description: This is a digitally signed message part.
