Apparent protocol-machine bug, new top priority

[Fred Wright]

On Sun, 24 Sep 2017, Eric S. Raymond via devel wrote:
> Achim Gratz via devel <devel at ntpsec.org>:
> > Eric S. Raymond via devel writes:
> > > Now that iburst has been fixed - and Achim reports seeing this problem
> > > with iburst off - this pretty much has to be an issue deeper in the
> > > protocol machine.  (I guess we should count our blessings and
> > > congratulate Daniel that there haven't more of these since the big
> > > refactor.)
> >
> > I have gathered more observations: it is almost always the rasPi 1B+
> > that kicks out its local clients and it seems to happen more often while
> > it's busy with other stuff, so I think it somehow has to do with the
> > speed of the NTP packets relative to the processing capabilities.
> > Whether that happens because packages are retried (and then kicking off
> > the rate-limiting) or packages getting the wrong source attached I don't
> > know.

I presume "packages" was meant to be "packets".

> I'll try to reproduce on my RPis.

Is there some kind of stress-test program that can be used to induce this
kind of problem?

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.

Fred Wright