Re: [chrony-dev] Slow bootup with git

[Bill Unruh <unruh@xxxxxxxxxxxxxx>]

On Wed, 25 Apr 2012, Håkan Johansson wrote:

> On Wed, 25 Apr 2012, Bill Unruh wrote:
>
> >  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.
>
> Could the measurement series be done with increasing accuracy?  And also the 
> stepping?
>
> For the first good measurement to be done, we expect no knowledge on where 
> inside one second the turnover comes.  So polling is required fully during

IF the rtc can trigger an interrupt, then you know as well as can be done when
the turnover comes.  If not then yes, you have to poll.

> that second.  Except one can use a timeout of say 10 ms between each read, 
> leaving most of the CPU to other start-up processes, if there are things 
> willing to run in parallel before system time has been set.  After one 
> successful good read (i.e. not first), we know within which 10 ms bin the 
> turnover is.  For subsequent measurements, a timeout is set up to not wake us 
> up until just before a small margin before the expected time (10 ms bin first 
> time), and then during that bin polling is done at 100% CPU.  Good statistics 
> is not obtained faster, but chrony becomes light on CPU use.

I believe it is actually done something like that if stepping is necessary.
But it is all done in the kernel I believe, not by chrony.
o

Remember that the system clock is liable to be way out (years) on intial boot.
Ed is wanting to use chrony to set the clock intially, not hwclock.


> For the initial stepping, would it make sense to have 2 (or even 3) points of 
> stepping?  After the 3rd measurement above the time (but not rate) should be 
> well known, such that any big step / slew can be performed / initiated 
> already then.  Further measurement are to get the rate correct, and the

No. Youeither have the rate of the rtc already from previous runs, or you just
assume its rate is correct. You use the net, gps to set therate of thee system
clock, not the rtc.

> correction of that in the background after say perhaps another 8 s will only 
> make other processes see a small slew.  (It can of course happen that the 3rd 
> measurment misses the point, and one has to wait for the 4th turnover...)
>
> Would it make sense to think of setting basically the second correct 
> immediately, before any polling?  Only useful if time is really off, and some 
> start-up processes would be happy with that accuracy / allow the big slew 
> coming out of the next pointsetting after 3 s.
>
> Cheers,
> Håkan
>
> >  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