I don’t think likely, but obviously possible. The whole system is too complex to say for sure either way just based on a gut feeling or theoretical mind exercise. The proposal was simple and straightforward enough to easily just give it a try. Pretty much the worst that could have happened is that it does not yield the desired effect. But then, we’d know for sure that some more sophisticated approach is needed. And it is clear that it doesn’t solve the issue all on its own for every zone, e.g., it requires a large fraction of capacity to be available already so that smaller netspeed values result in a sufficiently small share of netspeed, and roughly corresponding lowered load.
It is not that there weren’t enough, and good, proposals how to address the issue in various ways in the past. The challenge with many of them is the amount/complexity of changes they would require, touching and changing core parts of the system logic. With increased effort to implement them, which is the bottleneck. And the potential for destabilizing the system when core parts of the system logic are being changed, in turn needing further effort/time/thought to avoid that, further decreasing the likelihood of implementation.
The proposal to add additional netspeed values below the current minimum on the other hand is extremely simple, just a few additional values in a list that has been modified several times in the past already. Effort would have been limited to a few clicks to accept the PR and deploy it, maybe further tweaking the numbers in the list in the process if there were a strong view, e.g., as to the steps in between. And the proposed change is simple enough to pretty much rule out that it could cause major destabilization of the system. In the worst case, it would not be sufficiently effective in addressing the issue.
Precisely the point: The simplicity and low effort in implementing this, and the low risk, vs. other, more sophisticated and comprehensive solution approaches.
Not sure how that would differ from how people do it today. Certainly I do that whenever I add a new server in a zone I don’t know yet, or where there are external limits such as a bandwidth limit or volume quota where I don’t have an intuition yet as to what netspeed setting would allow me to stay within the limits without wasting capacity.
Same as today.
The unit of the load doesn’t matter, whether one measures it in multiples of bits/second, or in packets per second, or any other unit. The point is that as today, there is at least a rough correlation between the netspeed value, and the resulting load. E.g., halving or doubling the netspeed setting would result in roughly half or double the amount of packets/s or bit/s or CPU cycles, or whatever the limiting metric of a specific system is.
Yes, no change whatsoever on that side in my understanding.
Exactly. And in the worst case, it isn’t, then that server operator is out of luck. But it might still help other server operators with other constraints, and/or in other zones.
And again, the proposed change, and the effort to implement it, and the risk to system stability are so simple/low that it would have warranted at least giving it a try. Especially seeing how long this topic has been open already, and the pain it keeps causing.