Well, I proposed a different design for easing in new reflectors (similar in scope to soft-start as I understand it) based on evaluating simple update counters per reflector (and evaluation of only those reflectors with sufficient low-load samples in their history) that would not have introduced any more blocking sleeps and hence very little chance of failing hard. As you can see as a github comment. That is exactly why discussion before implementation has the potential advantage of avoiding pitfalls other already dug themselves out of in the past... (In "real-time" control, blocking actions like "sleep" are generally problematic and it is best not to introduce special code-paths for rare or corner cases, and better to handle them through the common paths and just change as little as possible, in the case of soft-start simply do not change the rates).
But as you have fixed your controller you probably know this already.
Yes, but at 35000.2 = 700Kbs the set thresholds will not work well any more (serialosation delay for a single full MTU packet ~ 1000 (15008)/(7001000) = 17.14ms with a default threshold of 15ms that is kind of bad) and the link is more likely to stay at the minimum. No matter how you slice it users will have to enter meaningful values under some conditions.
About the percentage, all I want to say is that I do not think your rationale is all that much more convincing to me than @CharlesJC's was, but then not my call to make.
As I said, have a special value for "auto-set" and go wild in automatically selecting say what you consider a decent default, but do not force poor souls for which the auto setting does not work to first measure their absolute minimum rate convert that into a percentage and repeat that whole thing should they change the base_rate again.
Well, apparently the 1500 were selected under the assumption this would be a never needed safety mechanism, and as it turns out not so much. Happens during development, but that IMHO is not a rationale for switching to percentages, but for making sure the minimum rate is still useful. And I bet that if you check with Zoom their recommendation is going to be a speed in absolute units per call, and not a percentage of the link's capacity. Which to me indicates that for selecting a lower limit absolute numbers are more useful. I apparently love a) repeating myself and b) flogging a dead horse, as that ship has sailed.
No, you put in a safe minimum of 5000 to allow Skype/Zoom and maybe warn a user if that is above base rate and instruct them to select something lower and warn them of the consequences.... this is not rocket science and going to percentages of base rate is solving none of the tricky issues here as far as I am concerned.
See this is the thing the "some warnings that for slow connections" is the kicker here, and that will work just as well with absolute as with percentage minimums, but it will be far easier for a user to figure out which absolute minimum rate she/he needs for their must-work applications.
This is insulting, and you know it. As I pointed out one of the first thing autorate-lua does is convert the percentage back into an absolute rate, because that is what the controller operates on.
Are you really piping all reflectors though the code at start-up? If so how do you space them out? For production I understand you space the default 5 reflectors out by distributing them roughly over one full cycle time, so when you start with more reflectors, do you space them out over more cycles or are you slamming all of them in in a single cycle?
Here is what I thought about this, instead of running each reflector at (cycle_time)^-1 ping one reflector every XXms, but cycle though a list of reflectors that is considerably longer, so the per reflector repetition rate stays nice and low, but the temporal coverage stays high, allowing you effortlessly to sample from a larger population.
But with this I am truly out for a week unless there are specific questions, promise.
