Re: [chrony-dev] [GIT] chrony/chrony.git branch, master, updated. 1.26-26-g9a01ccc

2011-11-15 Thread Miroslav Lichvar
On Tue, Nov 15, 2011 at 10:32:28AM -0800, Bill Unruh wrote: > >The graphs of the clock offset now look much nicer too: > >http://mlichvar.fedorapeople.org/tmp/chrony_corr.png > > Why the large jump in time offset at the beginning with the new procedure. > That looks suspicious. Also the

Re: [chrony-dev] [GIT] chrony/chrony.git branch, master, updated. 1.26-26-g9a01ccc

2011-11-15 Thread Miroslav Lichvar
On Tue, Nov 15, 2011 at 10:28:31AM -0800, Bill Unruh wrote: > > I am a bit confused both about the reason for and the details of this > alteration. chrony determines both the offset error and the frequency error. The main reason is that adjtime() slews at a fixed rate of 500 ppm. On the graphs

Re: [chrony-dev] [GIT] chrony/chrony.git branch, master, updated. 1.26-26-g9a01ccc

2011-11-15 Thread Bill Unruh
One of the issues with ntpd that started me being interested in this whole timing stuff, and chrony was the presence of what seemed like oscillations in the data. In this latest one, I again see oscillations, with about a 3000s period. Do you have any idea what those could be? How long is the

Re: [chrony-dev] [GIT] chrony/chrony.git branch, master, updated. 1.26-26-g9a01ccc

2011-11-15 Thread Bill Unruh
On Tue, 15 Nov 2011, Miroslav Lichvar wrote: On Tue, Nov 15, 2011 at 06:55:18PM +0100, g...@tuxfamily.net wrote: Add corrtimeratio directive The corrtimeratio directive controls the ratio between the duration in which the clock is slewed for an average correction according to

Re: [chrony-dev] [GIT] chrony/chrony.git branch, master, updated. 1.26-26-g9a01ccc

2011-11-15 Thread Bill Unruh
I am a bit confused both about the reason for and the details of this alteration. chrony determines both the offset error and the frequency error. It corrects the frequency error immediately, and then adjusts the frequency to eliminate the offset error. I am not sure what the reason is behind