Re: How much do we care about high-load scenarios?

On 13/09/2016 16:25, Eric S. Raymond wrote: Not a crazy idea, but I lean against it. My problem is that threading is a serious defect attractor (as we have in fact seen in the async-DNS code). I would not tar all threading architectures and designs with the async-DNS threading code brush.

✘minpoll=maxpoll=2

Yo All! I have some solid results on minpoll=maxpoll=1. That gives a poll time of 2 seconds. When minpoll=maxpoll=0 works Ill be testing that. UNtil thne I'll be testing other values. First, the good news. On a Raspberry Pi 3B, with Uputronics hat, minpoll=maxpoll=1 is much better than

Re: How much do we care about high-load scenarios?

Gary E. Miller : > > I'd prefer to bias towards architectural simplicity unless and until > > field reports force us to optimize for the high-load case. > > If NTPsec is to seriously challenge NTP Classic, it must outperform > NTPsec at the bleeding edge. In the NTP case that is

How much do we care about high-load scenarios?

Mark: Heads up! Your input requested. Hal and I were having an off-list argument. It started here: Hal: But maybe we should have a separate thread per refclock to get the time stamp. ... Me: Not a crazy idea, but I lean against it. My problem is that threading is a serious defect attractor