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-requ...@chrony.tuxfamily.org with "unsubscribe" in the subject. For help email chrony-dev-requ...@chrony.tuxfamily.org with "help" in the subject. Trouble? Email listmas...@chrony.tuxfamily.org.