[LinuxPPS] LinuxPPS 5.3.2 strange behaviour

[Cirilo Bernardo]

On Wed, Oct 1, 2008 at 3:40 AM, George Spelvin <linux at horizon.com> wrote:
[snip]
> What's odd is that the slower computer that this one replaced,
> using the same GPS clock and an earlier version of linuxpps,
> caught it just fine.
>
> After all, I expect the system to have much less than 10 us of
> timing jitter _on average_.
>
> I can program the clock to lengthen it, but should that be necessary?
>
> I might try a different PCI slot with a different interrupt.
>

This is not an issue of jitter; jitter is the pulse-to-pulse variation
in a time interval.  This is simply a matter of interrupts being
missed; the most common source of that is that another interrupt was
generated while the interrupt is still blocked (interrupt processing
routine did not finish its job).   You can check if this is the case
by hacking the serial processing routine to print a counter plus
'start' plus the state of the DCD pin (high/low) when the routine is
entered (an interrupt was detected) - then print the counter plus
'end' plus state of DCD pin before leaving (and increment the
counter).

You can't just say "but this board is faster than the older board"
because processor speed is only one factor - you also have CPU load,
numerous other interrupts, and processing time within the serial code
all contributing to latency.  If an interrupt is shared that's even
worse; the handlers have to test if their hardware had generated the
interrupt and if your handler (serial port driver in this case) is
called last, then there can be quite a bit of time lost depending on
the behavior of the other drivers.

Since one of the edges of the PPS signal is inferior for timekeeping
purposes due to the usually unspecified tolerance on the pulse width,
just ensure that your circuit is generating the interrupt on the good
egde and that the pulse is long enough to avoid mising interrupts if
you really want to look at the timing of the inferior edge.

- Cirilo