on 06/04/2010 15:47 Andriy Gapon said the following:
on 30/03/2010 19:43 Andriy Gapon said the following:
do you think that periodic saving of system clock to hardware and making
resettodr
asynchronous are dependent issues? Or are they orthogonal and can be
implemented
independently?
A
on 30/03/2010 19:43 Andriy Gapon said the following:
do you think that periodic saving of system clock to hardware and making
resettodr
asynchronous are dependent issues? Or are they orthogonal and can be
implemented
independently?
A new version of the patch:
on 29/03/2010 17:44 John Baldwin said the following:
On Sunday 28 March 2010 7:45:25 am Dag-Erling Smørgrav wrote:
Peter Jeremy peterjer...@acm.org writes:
A new kthread which sleeps on channel update_rtc. When woken, it
checks to see if it's within (say) 50msec of a second boundary and so,
On Sunday 28 March 2010 7:45:25 am Dag-Erling Smørgrav wrote:
Peter Jeremy peterjer...@acm.org writes:
A new kthread which sleeps on channel update_rtc. When woken, it
checks to see if it's within (say) 50msec of a second boundary and so,
it does a trylock on the (new) RTC mutex. If it
Peter Jeremy peterjer...@acm.org writes:
Traditionally, the (PC) RTC is on the ISA bus (though it's possible it
might use I2C on other architectures or LPC on current PCs).
AFAIK, it's usually on I2C on non-i386 platforms. I2C RTC chips are
dirt cheap and easy to integrate, especially if you
On 2010-Mar-27 01:38:36 +0100, Dag-Erling Smørgrav d...@des.no wrote:
Peter Jeremy peterjer...@acm.org writes:
It's not especially important how regularly the RTC is updated, just
that it _is_ updated. This suggests that an alternative approach
would be for adjtime() / ntp_adjtime() to
What do you think about the following patch or something similar?
Just in case, I am already aware about missing empty lines before the code in
the
new functions. Also, I am aware that the period should be configurable
(sysctl).
Reference:
* Andriy Gapon a...@icyb.net.ua wrote:
What do you think about the following patch or something similar?
Yes, please. :-)
I had an Intel motherboard which had a clock drift. A couple of seconds
a day. When I had to reboot after upgrading/etc, it was not a serious
problem, but say, the system
* Andriy Gapon a...@icyb.net.ua wrote:
+ timeout(periodic_resettodr, NULL, 1800 * hz);
By the way, wouldn't it be a little nicer to use callout(9)?
--
Ed Schouten e...@80386.nl
WWW: http://80386.nl/
pgpz0oTdiuq2Z.pgp
Description: PGP signature
on 26/03/2010 17:12 Ed Schouten said the following:
* Andriy Gapon a...@icyb.net.ua wrote:
+timeout(periodic_resettodr, NULL, 1800 * hz);
By the way, wouldn't it be a little nicer to use callout(9)?
I don't know :-)
I see that timeout is deprecated and is unsafe in some respects, but
Andriy Gapon a...@icyb.net.ua writes:
What do you think about the following patch or something similar?
I've wondered for years why we didn't already do this.
Also, I am aware that the period should be configurable (sysctl).
Why?
Although I can see an argument for a sysctl to turn it on or
on 26/03/2010 17:44 Dag-Erling Smørgrav said the following:
Andriy Gapon a...@icyb.net.ua writes:
What do you think about the following patch or something similar?
I've wondered for years why we didn't already do this.
Also, I am aware that the period should be configurable (sysctl).
Andriy Gapon a...@icyb.net.ua writes:
Dag-Erling Smørgrav d...@des.no writes:
Andriy Gapon a...@icyb.net.ua writes:
Also, I am aware that the period should be configurable (sysctl).
Why?
Because there would always be someone who would want a different value :)
Although I can see an
On 2010-Mar-26 17:30:14 +0100, Dag-Erling Smørgrav d...@des.no wrote:
Andriy Gapon a...@icyb.net.ua writes:
Dag-Erling Smørgrav d...@des.no writes:
Andriy Gapon a...@icyb.net.ua writes:
Also, I am aware that the period should be configurable (sysctl).
Why?
Because there would always be
Peter Jeremy peterjer...@acm.org writes:
At least some versions of Linux also save a RTC drift approximation
and last set timestamp whenever the RTC is updated. This allows the
kernel to better set the system clock from the RTC at boot (ie, our
inittodr()). The downside is that this needs to
Peter Jeremy peterjer...@acm.org writes:
It's not especially important how regularly the RTC is updated, just
that it _is_ updated. This suggests that an alternative approach
would be for adjtime() / ntp_adjtime() to directly call resettodr() if
it's more than P minutes since resettodr() was
16 matches
Mail list logo
