[time-nuts] Cheap jitter measurements
Stromeko at nexgo.de
Mon Apr 9 14:19:48 EDT 2018
Bob kb8tq writes:
>> Similarly, the box should be able to give me a pulse at a known time.
> how do you set up NTP to do that?
Not at all, that must be done in the kernel if you want any accuracy at
all. But you could modify an existing device driver (for the LPT port)
to use GPIO instead to give you a PPS out (you'll probably want some
offset to the true second so it doesn't interfere with the PPS input).
I think it'd be best to combine a highres timer with some spin-loop to
keep that PPS pulse closer to the clock (it's been done that way for
other timing critical stuff before, not really a new idea). Or, if it's
only slightly offset from the PPS in anyway, you could piggyback onto
the PPS reception.
> In both cases (pulse in and pulse out) the first step is to ask NTP
> “when was that?”. You still have a pretty big chunk of NTP in the
> middle of the process …. If NTP only “knows” what is happening (or can
> control what is happening) to +/- 300 ns. The guts of your data will
> be limited to the same 300 ns.
That's not quite how that works. The resolution theoretically goes down
to nanoseconds and is ultimately limited by the timer clock. In the
case of the rasPi that means about 52ns, but this is swamped by the
jitter of the interrupt latency. But you can feed NTP better timestamps
if you figure out how to get them; on the Beaglebone you can use the RPU
(Dan Drown has been measuring some latencies that way), on the rasPi you
could use the VC4 (this is tricky business due to insufficient
documentation, but the hardware should be capable of scanning the GPIO
at 250MHz) or even an external TICC.
The other option is to use an MCU (or an FPGA) w/ Ethernet and hardware
timestamping to build a single-purpose NTP stratum-1 box.
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
SD adaptation for Waldorf rackAttack V1.04R1:
More information about the time-nuts