Apparent protocol-machine bug, new top priority

[Achim Gratz]

Fred Wright via devel writes:
> I get a kick out of you guys fussing over "thermal stability" when the
> largest source of time error is the interrupt latency in timing the PPS
> signal.

The median interrupt latency shows up as an additional offset on top of
other such offsets.  The variability on that latency gets filtered
pretty nicely by ntpd, especially the long tail at large latencies.
Now, interrupts never have been a particularly strong point for ARM, I
give you that.

> Just because you can't see the error in the graphs doesn't mean
> it isn't there. :-)

Again, that number isn't materially affecting the frequency stability,
only the time offset.  If you look at that, you will quickly find that
your assertion of thermal effects getting dominated by the interrupt
latency is wrong.

> On the Beaglebone, it's typically around 15us with the
> CPU running at 1GHz, going up to around 42us at 300MHz.  It's directly
> measurable because the "real" PPS timing is via counter capture, with a
> total capture uncertainty (the equivalent of NTP RTT) of typically 583ns
> at 1GHz and 1083ns at 300MHz.

If you have histograms, I'd like to see them.  But that seems to be in
the right ballpark.  Note that you could do something similar by running
the PPS capture on the VC4 instead of ARM subsystem, but that part of
the rasPi is woefully under-documented.  In principle the hardware
should allow capturing PPS at up to 250MHz and sending the timestamp via
mailbox to the ARM is not timing-critical at all.

If you wanted to eliminate that, you'd better use an FPGA or some other
microcontroller that has capture units and hardware timestamps for the
NIC.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds