Re: [chrony-dev] PPSAPI: kernel consumer

[Bill Unruh <unruh@xxxxxxxxxxxxxx>]

On Tue, 9 Feb 2010, Alexander Gordeev wrote:

> ÿÿ Mon, 8 Feb 2010 09:16:48 -0800 (PST)
> Bill Unruh <unruh@xxxxxxxxxxxxxx> ÿÿÿÿÿÿÿÿÿÿ:
>
> > I think I would strongly advise against adding this feature. It is
> > complex, it does not, if I understand things, fit with the chrony
> > philosopy of operation at all, it would make the code far more
> > fragile.
>
> I can't imagine how can it possibly break things. Until I dive into
> chrony's code maybe. But I'm not sure that it can happen soon.

Any time you make code more complex you make it more fragile. Bugs creap in.
And especially when the design philosophy of chrony is so so different from
the design philosophy of your addition. 
>
...

> very simple and thus predictable. We need code to be predictable because
> we run a hard real-time environment for distributed simulation.
> chrony is surely more complex. Also my code outperforms chronyd in

Then run your code. Adding your code to chrony will make chrony even more
complex.

> convergence speed at least. But please do not think that I want to lower
> value of chrony.

Lower the poll interval. It looks to me like your code is  effectively using a poll
level  of 1 ( ie testing every second) instead of the usual refclock poll
level of 4. Just run chrony with a lower poll interval and see how it responds.

Doing this you decrease the response time, but also increase the random error
( a shorter effective interval over which chrony can average the rate to knock
down the rate error-- you will effectively double the rate error.)
It is a tradeoff. Now, chrony usually does not have a chance to hold 64 prior
measurements because temp changes cause the rate to change deterministically
before 64 intervals have been collected. Running at a shorter poll interval may
make chrony more responsive and not decrease the accuracy. Try it.