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

[Ed W <lists@xxxxxxxxxxxxxx>]

On 21/11/2011 13:40, Miroslav Lichvar wrote:
> On Wed, Nov 16, 2011 at 11:06:27AM -0800, Bill Unruh wrote:
>> On Wed, 16 Nov 2011, Miroslav Lichvar wrote:
>>> Polling interval was fixed to 64 seconds, the number of samples is
>>> around 30-40. With higher jitter or more stable clock (longer Allan
>> So that is about 1800 sec. which looks to be something like that period
>>
>> I suppose not surprizingly, since the linear least squares fitting would eliminate
>> any higher frequencies.
> I think there is not much chrony can do here to eliminate higher
> frequencies besides using a shorter polling interval and increasing
> the maximum number of samples.
>

As you have clearly started to push the boundaries of curve fitting
here, have you considered switching to some kind of Kalman filtering
technique?  Implemented correctly this can potentially simultaneously
incorporate the updating of the estimate and tracking the estimated
error.  I haven't thought about it enough, but it might also make it
simpler to incorporate exotic ideas such as more active changes in
measurement intervals in response to changing estimated error..? 

For those not familiar, the Kalman filter is essentially an optimal
linear estimating technique assuming certain conditions on the inputs,
the most interesting of those conditions being that they have gaussian
error.  The most common implementation you might see would be the phase
locked loop. (which is approximately what we are implementing with
Chrony I think?)


Cheers

Ed W

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