Re: [chrony-dev] Slow bootup with git

[Ed W <lists@xxxxxxxxxxxxxx>]

On 23/05/2012 15:37, Miroslav Lichvar wrote:
> On Wed, Apr 25, 2012 at 10:18:13AM +0100, Ed W wrote:
> > I guess then the question is whether increased accuracy of reading
> > is useful beyond 2 samples?  Remember that gaussian error bound
> > decreases fairly slowly with increasing samples (1 / sqrt(n) - ?).
> > Is the reading of 8 samples actually buying us very much?
> It doesn't seem so. The actual applied system clock step includes the
> RTC drift which over longer time intervals has much larger error than
> the measured RTC offset.
>
> BTW, I did some tests with RTC on a Linux 3.3.2 machine with HPET
> enabled. When the RTC interrupt is enabled (RTC_UIE_ON) and every
> following sample collected, there is visible a periodic sawtooth error
> up to 25 ms gaining at 100ppm. When only one sample is collected in
> one period with enabled interrupt, the absolute value of the error is
> the same, but it seems to be uniformly distributed. It seems the RTC
> emulation is somehow reset when the interrupt collection is enabled.

Hmm, well seems like we can eliminate the need for hwclock then.  Given 
a single read we can get decent accuracy to immediately set the system 
clock.  It would make sense to do at least a second read to test for the 
historic problems, but any additional accuracy learned from that could 
presumably be simply shuffled into the estimated clock skew calculation 
and either stepped or skewed while the system continues booting

Is this a reasonable feature request?  hwclock doesn't appear to offer 
anything that chrony doesn't do except an additional dependency and an 
error offset estimate which isn't then integrated into chrony's accuracy 
calculation?

Thanks

Ed W

--
To unsubscribe email chrony-dev-request@xxxxxxxxxxxxxxxxxxxx with "unsubscribe" in the subject.
For help email chrony-dev-request@xxxxxxxxxxxxxxxxxxxx with "help" in the subject.
Trouble?  Email listmaster@xxxxxxxxxxxxxxxxxxxx.