| Re: [chrony-dev] Slow bootup with git |
[ Thread Index |
Date Index
| More chrony.tuxfamily.org/chrony-dev Archives
]
On Wed, 25 Apr 2012, Ed W wrote:
On 24/04/2012 11:17, Miroslav Lichvar wrote:
On Tue, Apr 17, 2012 at 09:07:08AM -0700, Bill Unruh wrote:
> Mind you the rtc should not take 8 sec to read (it will take a couple,
> so
> perhaps most of that time is chrony starting up), so it is not clear
> what is
> happening.
It collects 8 RTC samples to get an accurate offset for the initial
system clock adjustment. I.e. it waits for 1 + 8 RTC interrupts, the
first one is ignored to avoid a kernel bug, which might have been
fixed long time ago. I think decreasing that number to perhaps 2 or 3
should be fine, but I haven't tried it.
Curious why reducing it is ok? What is the current algorithm for reading the
rtc time?
The rtc can only be read on the second. Ie, reading the rtc will give you the
time accurate to the last second. The rtc produces an interrupt when the
second turns over and this can be used to read the rtc accurately but only at
the second turnover. In order to get 8 samples from the rtc, you need to wait
8 seconds. If you only want 3 samples you wait three seconds. As he said,
there is a bug so that you you needed to throw away the first reading as that
interrupt could have been left over from a prior second turnover, and thus
means nothing.
Now, it depends on how accurately you want the rtc time. If you are happy with
just the first reading, you could do that. If you want to average it out so
as to get a really accurate reading -- averaging out some of the noise-- then
you read more times.
I thought I saw a little while back you had some busylooping to try and find
the exact time it rolled? I thought I saw it got removed though - didn't work
out? Potentially that reduces the delay to the minimum possible?
The problem is that the setup of the interrupts on the PC has become a
complete and total mess. Thus the rtc interrupt used to come out on a separate
interrupt line. Then with HPET etc, the rtc interrupt got entangled with the
NMI interrupt and became essentially unuseable. Thus the rtc got polled
instead. Now if you ae willing to use all of the cpu to keep looking at the
rtc to see if it turns over, that can give you good accuracy. If your polling
is less often, then the time of the turnover becomes more inaccurate.
The argument for using chrony to intially set the clock from the rtc has
become weak. For one thing, hwclock ( or rather one of the hwclodk versions)
can now estmate the rtc drift. SEcondly, that drift estimation was never very
good, because of temperature differences between on and off. Thus if the rtc
is out by 10PPM, that is about 1sec/day that the rtc will drift.
I think with boot times coming down there is a desire to try and keep this
number reasonable. Even if we background chrony it still means a step/slew
hitting late in the boot process when it could be done near the start (when
on average we are less clock sensitive)
Thanks for your work on chrony!
Ed W
--
William G. Unruh | Canadian Institute for| Tel: +1(604)822-3273
Physics&Astronomy | Advanced Research | Fax: +1(604)822-5324
UBC, Vancouver,BC | Program in Cosmology | unruh@xxxxxxxxxxxxxx
Canada V6T 1Z1 | and Gravity | www.theory.physics.ubc.ca/
--
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.