Re: [chrony-dev] [GIT] chrony/chrony.git branch, master, updated. 1.25-pre1-18-g20a4340

[Miroslav Lichvar <mlichvar@xxxxxxxxxx>]

On Mon, Apr 11, 2011 at 03:09:54PM -0700, Bill Unruh wrote:
> On Mon, 11 Apr 2011, Ed W wrote:
> >This probably seems rash since you are obviously in the conservative
> >release category: however, I would have preferred this release to be
> >(say) 1.29 with a bunch of prior releases plus bug fixes to get us to
> >where we are now...
> 
> You can always download the git yourself.

Yes, you can download tarballs directly from gitweb. It should be
always compilable and "usable". I try to avoid breaking things and if
there are more complex changes, I push them at once.

> >The point was more that I tend towards "more frequent" releases with a
> >sweet spot around the 2-3 month interval.  The justification being that
> >few users will test anything other than "releases" (even as a developer
> >I find it massively more convenient to work mostly with "releases", and
> >more than a few source packages overwhelms my spare capacity.
> 
> Releases are supposed to be stable things, not works in progress.

I agree, chrony is a mature project, when there is a new release made,
I think the users expect it to be well tested.

But I also agree that we could have already made a release or two.

John, what do you think about this?

> It would also be good to get someone to study the advantages and disadvantages
> of chrony vs ntp-- especially the disadvantages ( I do not know of any). Does
> it go unstable under certain circumstances? I do not think so but do not know.

One of the disadvantages of chrony's clock discipline that I know of
is the large frequency error when slewing (adjtime uses up to 500 ppm
rate), in my tests the RMS frequency error is up 10 times worse than
with ntpd in the same conditions. This could be a problem if you are
measuring short time intervals. Of course, if we had our own slewing
code in kernel, as ntpd does, it would improve a lot.

> Why is chrony so muchmuch better than ntpd in many situations? It is just its
> far more rapid response to changes caused say by thermal fluctuations? or is
> there some other reason?

I think it's the adaptive time constant and ability to change it
quickly what makes chrony so much better in some situations.
Interestingly, when the number of samples is fixed to 64, the response
is quite similar to ntpd's PLL.

You can experiment with the clknetsim simulator
(http://mlichvar.fedorapeople.org/clknetsim/). There is not much
information about the tests I did, let me know if you want to know
the details or exact configuration I have used.

-- 
Miroslav Lichvar

---
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.