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

[Ed W <lists@xxxxxxxxxxxxxx>]

On 28/11/2011 10:15, Miroslav Lichvar wrote:
> On Fri, Nov 25, 2011 at 10:39:33AM +0000, Ed W wrote:
>> On 25/11/2011 10:12, Ed W wrote:
>>> 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..? 
>> Hmm, some googling shows that this is a fairly well discussed idea in
>> academic circles.  I found this article enlightening
>>
>> http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.163.7440
> Interesting. It seems this could be used to improve our temperature
> compensation code to determine the coefficients automatically, but
> does it apply to the more common case without temperature data?
>
> I know two places in the chrony code which might benefit from some new
> ideas. The sample weight calculation and the pruning of old samples.
>

My reading of the paper was actually that the author concluded that
Recursive Least Squares had similar performance to Kalman, but without
the requirement to figure out a covariance matrix.  Isn't this what you
are already using in chrony for computation?

It is an interesting paper though and very thorough (and only one of
several I could hit with a quick google search), but it seems to cover
all the main problems and give decent conclusions on what is a state of
the art solution for each.  For example if we assume his summary of
oscillator cuts is accurate, then you can see a bunch of curves that
seem to summarise the general problem fairly well and probably we can
make a guess as to the range of clocks we are likely to see in real use
given the assumed low cost.  It also seems possible to make a guess at
the "off" time and temperature of many machines and I guess it would be
possible to use that to make a better estimate of clock drift while
"off" if that were an important goal...

My original reasoning for Kalman was only that I thought it might make
it simpler to incorporate changes in measuring period, but there are
plenty of increased complexities as a result, so in conclusion doesn't
look like a win...? A few other papers I found suggested that kalman can
give increased accuracy in the event of having a larger number of
points, but underperformed in the event of fewer points and most papers
concluded that a hybrid approach would be necessary (assuming you turn
the computer off ever).  Oh well...

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.