No subject


Fri Apr 23 08:19:56 CEST 2010


Ditto, if you look at the documentation for your receiver HOPEFULLY, it will
also give a number for a delay.  Add the two.

Finally, as you note there is the big question of the delay in IRQ servicing.
There is something going on here in Linux that I dont understand.  The last
time I looked, the 'noise' in these interrupts (that is plot the time of the
timestamp vs the second that it is a timestmap for) was one-sided on
my FreeBSD machine.  This is reasonable, since the timestamp can only
be delayed by the IRQ delays, and not advanced.  On Linux the noise was
symmetric around zero.  I dont understand that, but then I havent looked
at it in a long time.  MABE, with recent changes it is now one sided as
it should be.

In any case, the NTP algorithm SHOULD take care of this, choosing those
timestamps that arrive with the lowest delay, so probably nothing to
do here except try to get better hardware, so the delays are small
to begin with.

As for me, with the antenna up on the roof, and I don't know how much
coax coming down from it (I have that number somewhere), and an
ONCORE receiver, I have delay=65ns in my ntp.oncore.0 file.

With the previous PPS implementation (Ulrich) and the machine I was running
it on, Im sure I could see time errors  of on the order of 200ns, so this 65ns
would have been barely visible.  With the current implementation and machine
the error is more like 1us.  Once things stabalize and EVERYTHING gets into
the kernel distribution, Im going to have to look at that again.
-- 
                                        Reg.Clemens
                                        reg at dwf.com





More information about the LinuxPPS mailing list