[time-nuts] Cheap jitter measurements

[Trevor N.]

Bob kb8tq wrote:
>Hi
>
>Without the ability to put out a “known good” time pulse there is no quick way to 
>check NTP. GPS modules suffer a similar issue. They put out a pulse and a 
>“correction” (sawtooth error) to tell you what they just told you. Doing the same 
>sort of thing with NTP may be possible. 
>
>Indeed the process of correcting this sort of data is open to a bit of debate. It does 
>give you a way to get around the “hey, all I can do is 300 ns” issue. With GPSDO’s
>the correction is part of the standard firmware. It would be nice if one of the NTP 
>guru’s popped up with an equivalent process. 
>
>One *could* monitor various bits and pieces of the OS’s timing generation system. 
>Somehow that does not seem quite as much fun as looking at the whole result all
>at once. Indeed it might be the only way to get it all worked out.
>
>Bob

Linux has a pps output driver (pps_gen_parport), but  I've never used
it. A while back  I added an output mode to the Linux pps_parport
driver: 
https://github.com/retroman/pps_parport_polled 
that I will eventually get around to using with the palisade(trimble)
NTP driver.

My modified driver's polled input mode has an input-to-echo delay of
1.16 to 1.93 microseconds (measured with an old Keithley 775 counter)
on my machine which has a parallel card attached directly to the pci-e
port on a sandybridge processor.  Interrupt mode echo delay is 3.8 to
4.3 microseconds when the machine is lightly loaded with occasional
spikes of 5 to 7 us. When the machine is idle delay falls to
3.5-4.1us.
Port read and write delays are equal at about 820ns each. I think that
pci-express always uses 'split transactions'  so reads can sometimes
seem to take only half the time depending on the input pulse time
relative to the start time of a read request.  Delays increase to
~1200ns when attached to the chipset pcie ports.