Apparent protocol-machine bug, new top priority

[Fred Wright]

On Mon, 25 Sep 2017, Achim Gratz via devel wrote:
> Fred Wright via devel writes:
>
> > Can the failure rate be increased by changing the governor settings to
> > make the server slower?  On the Pi that would significantly worsen the
> > time accuracy, but for the purposes of this experiment that should be
> > acceptable.
>
> You mean dropping the CPU frequency?  That's maybe worth a shot, but I
> run the rasPi 3B at 600MHz currently for thermal stability and don't see
> any problems there.  I still think it is rather contention at the NIC
> that triggers the behaviour, but the real problem is that there is no
> recovery happening.  So maybe just testing the rate limiting branch
> directly with test packets would hreveal what's going on, but I don't
> know if there's a facility to produce them.

Perhaps, but it's a fairly easy experiment to try.

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.  Just because you can't see the error in the graphs doesn't mean
it isn't there. :-) 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.

Fred Wright