Re: [chrony-dev] PPSAPI: kernel consumer

[Bill Unruh <unruh@xxxxxxxxxxxxxx>]

On Tue, 9 Feb 2010, Alexander Gordeev wrote:

> ÿÿ Mon, 8 Feb 2010 13:45:11 -0800 (PST)
> 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> ÿÿÿÿÿÿÿÿÿÿ:
> > >
> > > 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.
>
> I still don't get the philosophy/complexity problems. BTW I don't have
> any code to add to chrony.
>
> I hope other chrony developers will still consider adding kernel
> consumer support a valuable feature or maybe just add it to allow the
> user to choose the possibilities.

No, you want others to add the code. But adding the code will make chrony more
complex. And if I understand what you mean by the kernel consumer support (
which I may very well not-- where is it written up so I can read it and
understand it) the mode of operation is not really compatible with the way
chrony does things. To make the two compatible would, I suspect, require
pretty extensive alteration of chrony.

I had a quick look at the code you have suggested adding to the kernel, and am
really bothered by a bunch of hard loops you have in there waiting for some
time to occur or some event to happen. That stikes me as a real waste of
computer resources. The cpu is spinning its wheels for up to a second waiting
for an event to happen. Surely you should be using interrupts (times
interrupts or parallel port interrupts) not busy loops doing nothing but tying
up the computer so nothing else can be accomplished either.

I also am confused about the philosophy. Why not just run a line from the
primary GPS ( with a buffer amplifier) to the various other computers, rather
than  having one computer strobe the parallel line, and the others responding
to that?

What kind of accuracy are you hoping to get and why? I strongly doubt that you
can control/stamp anything on your system to better than 1us accuracy, just
because of the kernel overhead, etc.






> > > 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.
>
> I'll try it, thanks.

Try using poll level 2 instead of 4 and see if it improves your convergence
while not destroying your accuracy.

>

--
William G. Unruh   |  Canadian Institute for|     Tel: +1(604)822-3273
Physics&Astronomy  |     Advanced Research  |     Fax: +1(604)822-5324
UBC, Vancouver,BC  |   Program in Cosmology |     unruh@xxxxxxxxxxxxxx
Canada V6T 1Z1     |      and Gravity       |  www.theory.physics.ubc.ca/