I have written a few updates to The Bandwidth Game - Join Now - Win 20,000 CRR! and to Why Are So Many Users Hitting Their Bandwidth Limit? Solved It! What You Can Do, so this is a quick recap of the latest information.
The developers of Steemit have opened a Github issue #1257 and are working on resolving the problem. The current algorithm that led to the "bandwith limit exceeded" errors that we are seeing needs to be changed. This is not a small matter as one algorithm impacts on other algorithms within the system.
If you scan the correspondence between developers on Github, you will see that one problem is that the formula that activates the drop in current_reserve_ratio is nested within the core code, which means that even witnesses cannot touch it or change it. This looks likely to be moved out of the core code and into a witness plugin; this means, I believe, that if the new algorithm needs tweaking, that this can be done through witness consensus rather than another code rewrite.
I quote from Vandeberg on Github
This satisfies the original design goal of aggressively decreasing the reserve ratio under high use to prevent spam as soon as possible but...
So this decrease in the current_reserve_ratio is a mechanism to protect the network from any overload; this could be internal, such as spam or excessive bot activity, or even external, such as a DDoS attack. The precise nature as to why it was activated will, hopefully become clearer once traffic is back up to "normal".
However, Vandeberg goes on to say that the changes to this algorithm,
... allows for fine adjustments when the average block size is not changing over time.
This just restates that control of the parameters will be with the witnesses, once the new algorithm goes live.
So, just to make this clear, the mechanism did what it was supposed to do: it limited the system's whole bandwidth in response to what the system thought was excessive spamming behaviour. The problem, which is now being fixed, is that the regeneration to full bandwidth is far too slow.
In my opinion, this is happening because the underlying behaviour has not changed, so the total bandwith is actually saw-toothing up and down rther than climbing quickly. This is going to be the a major issue for community discussion very soon: what is the nature of spam on Steemit and can we afford to allow it?
We are all subject to the same algorithm and to the same restrictions on our bandwidth use. Yes, if you have more Steem Power it does help, but only in proportion to your SP. Remember that the CRR is currently about 1% of the maximum, so this remains the most important factor. No, this has nothing to so with the price of Steem, unless this has resulted in a huge overload of buyers and sellers - extremely unlikely, this is a network traffic issue, not a financial one.
The developer of SteemD has very quickly added a very useful feature so you can all see how much bandwidth you have available, both as a percentage and in actual bytes. Go to steemd.com/@yourusername and you can see the data on the top left of the page. If you keep this page open and do some activity, such as a new post or comment or vote, then look back and see how that has affected your bandwidth. Remember that total bandwidth is still increasing slowly, so you will see your numbers move both up and down based on activity.
I hope this is helpful. There will be a public announcement from the Steemit team as soon as the new algorithm has been tested and is ready to be implemented.
Thank you.
Things move quickly! The second I published this article, I noticed that the CRR has dropped massively to 98! Do not panic! I suspect this has been done on purpose. Let me explain, the algorithm to regenerate the CRR back up to its default normal value of 20,000 (meaning 100% system bandwidth) includes a special case in that if the CRR falls below 100, then the regeneration algorithm goes into a "quick restart mode". This means that it should now regenerate at a much higher speed. Let's watch and see...
We need to make the max_virtual_bandwidth calculations 128-bit.
That calculation has been overflowing its 64-bit value. This is now possibly the number one source of this bandwidth problem. The CRR algorithm is still being changed, but the cause of the problem may well be just a code bug!
