Why Are So Many Users Hitting Their Bandwidth Limit? Solved It! What You Can Do.
Assuming the relevant section in the Steem White Paper is still valid, I have discovered something. I have been trying to ask around and even tried to find the relevant formulas in Github, but I prefer to deal in formulas than codes!
Anyway, in the White paper there is a section that states:
4.2.1 Example Implementation
Let B equal a user's average bandwidth at time T. Let W equal the number of seconds per week, and let N equal the size of the new transaction that occurred S seconds after T. Given this information the blockchain can calculate the new average bandwidth for a user as:
Bnew = MIN (0,B * (W-S) / W) + N * S / W
Tnew = T + S
Each user is entitled to an average weekly bandwidth of:
Let U = the user 's SP
Let S = the total number of SP
Let R = the current reserve ratio between 1 and Rmax
Let C = the maximum block size capacity set by witnesses
Let L = the total blocks per week
Let M = C * L * R
Allocation = M * U / S
A user would be entitled to an average bandwidth of M * U / S. Any time a transaction would cause the user's average to go above this threshold they would be unable to transact until enough time passes to lower the average.
The network can increase the reserve ratio, anytime blocks are less than half the target capacity and decrease it anytime they are more than half. The algorithm used to adjust R is designed to react quickly to decrease the reserve ratio when there is a surge in demand, while acting slowly to increase the reserve ratio in period of low demand.
The minimum reserve ratio is 1, and the maximum reserve ratio should be calculated to prevent small stakeholders from consuming all of the available bandwidth. If no one is using the available bandwidth then the reserve ratio can grow until a user with just 1 satoshi of the currency is able to transact every single block.
Let's look at this more closely:
Allocation = (C * L * R * U) / S
So if the total number of SP increases across the ecosystem, the allocation per user decreases. If the user's own SP is lower, then the allocation is lower. But look at this one: if the current reserve ratio is low, then the average allocation drops.
And each user's allocation is calculated as an average over a week. But we are seeing users with modestly large SPs bumping up against their bandwidth limits. I suspect the drop in the reserve ratio to be the main cause. In the 15 minutes taken to write this it has risen from a value of 229 to 243. I cannot see a place to fetch historical recent data, but I see from old articles that it was once 20,000! The White Paper mentions a value of 200, so these numbers are x100, meaning the current reserve ratio is really 2.43.
But this formula delivers a double blow because if the total SP is rising due to reinvestment at the same time as the reserve ratio is dropping, this can lead to a precipitous drop in our average allocated bandwidth. If the rise in recent claims (article care of @biophil) are mainly cashed out, then it is just the reserve that is having the major effect.
It's very recent rise in the last few minutes is no doubt due to so many people being locked out due to hitting their bandwidth limit. As this reserve ratio rises, more of your weekly allocation will rise above the bandwidth used and you can interact again.
The real question now is what is causing the drop in current reserve ratio?
I think we know.
What can you do at the moment if you are still getting a bandwidth limit message?
Your allocated bandwidth is calculated across 7 days, so look at all your current interactions - the simplest way is at steemd.com/@yourusername. Then, at least for now, adjust down your activity so as to lower your average use. Without any dramatic increases to the reserve ratio network traffic, this will take a few days to clear up.
(And, if I'm completely wrong about this, then I'm ready to eat humble pie... with extra cream!)
ADDENDUM (18 July 1 am local time)
The reason for the bandwidth limit errors is the current_reserve_ratio but it is not a financial parameter, it is purely a network traffic parameter. With the help of some witnesses we located the code that activates this parameter.
The reason that it has happened so suddenly rather than gradually is that the ratio only drops if the network traffic hits over 50% of capacity. The ratio drops so as to slow down the traffic, which has happened. It has also limited interactions and voting, but it does not target specific activities - it is purely about the number of actions logged to the blockchain.
The consensus has been to increase the block size - this should already be showing some improvements. In the medium term, witnesses will check their traffic stats to find out what has caused this steady increase in traffic.
Thanks to @personz (who found the crucial bit of code), @neoxian and @gmuxx for talking this through with me while many others were offline. Thanks to @ausbitbank for pointing out an error and to @aggroed for talking over some solutions.
Thanks for your patience.
Update
Follow-up article: The Bandwidth Game - Join Now - Win 20,000 CRR!
The bandwidth limit seems like a feature disguised as a bug. It effectively caps even a whale's ability to spam.
I have yet to hit a bandwidth limit and I'm essentially a daily steemer. FWIW.
It is absolutely necessary to limit bandwidth based on many variables. I'm sure the formula will evolve over time.
Thank you for posting this, I have seen multiple posts about this recently and it happened to me a few times yesterday as well. Finding information about it was not easy, every post I found regarding this was unsure of why it was happening! I'm glad there seems to be an easy solution!
One comment/correction to this: "But this formula delivers a double blow because if the total SP is rising due to excessive self-voting (self-mining)"
The SP does not rise faster due self-voting/mining, but instead due to things like: choosing between 50/50% or 100% power up, or powering up intentionally, which is at anyone's discretion.
But I give you the props due just looking at it and exposing. =)
In my view, another way to resolve this is either adjusting the blockchain coin cap, or/and by increasing the block size (which eventually will have to happen).
You're right, let me edit - I forgot to mention reinvest in SP to yield exponential returns.
Thanks for all the details. Can you explain this reinvestment point a bit more please?
If you read the new Addendum, you will see this is probably less important - probably! However, as the total SP of the system increases so everybody's max bandwidth decreases, so reinvesting rewards in SP will move the bandwidth down, whereas cashing out will move it up.
Don't forget that after HF19 the function is now linear. So yielding more SP does not represent an exponential effect anymore.
Thanks for this post! But I’m kind of confused with my situation. I used steemit a lot before (I even posted a blog) but it’s always on the 80-90% threshold. I wasn’t using steemit a lot today but I recently logged on to the steemit app and now it showed -20% bandwidth. Is this reasonable?
Hi @rycharde, I think your concern is somehow being addressed:
https://github.com/steemit/steem/issues/1257
Yes, we have been discussing it in the chatrooms.
Thanks for your help there.
Of course the bandwidth limits are hit due to dropping reserve rate (what else could it be, after all). The core question then is why exactly the reserve rate is dropping which you did not mention, so let me add a bit to your explanation.
Imagine the situation where there are a total of 1000 Steem users total each with 1 SP on their account. Suppose the total network bandwidth is 200 posts per day.
If everone wanted to post, each SP would be entitled to just 0.2 posts a day - this would correspond to a reserve rate of 1 and be overall quite inconvenient.
Suppose that initially just five users are posting two times a day, hence the network only sees 10 posts a day. This 20 times lower than its actual throughput, so the network adjusts the reserve rate to 20 and every SP becomes entitled to 0.2*20=4 posts a day. So far, so good, the limits are above average use for everyone.
Now, suppose that June 2017 comes and a horde of newcomers floods in. Let's say, 30 newcomers each with SP=0.05 join the club. A typical newcomer is eager to start posting daily right after registration and given the original rate it can do so (0.05 * 30 = 1.5 posts per day). However, as soon as 40 daily post attempts onto a 200 ppd bandwidth arrive, the network scales the reserve rate down from 20 to 200/40=5, which means each SP becomes entitled to just about 1 post a day - this is uncomfortable for the old users who needed 2 posts per day, and useless for the new ones, who now have a 0.2 post per day limit.
Note that nowhere along the way there was actually even a risk of going over the bandwidth - 40 posts per day would perfectly fit through the system, yet everyone still suffers.
Why? Because the posting intensity is, in reality, disproportional with the user's SP holdings, while in the bandwidth model it is.
If you think of it, this is a conceptual flaw in the system. Instead of allocating bandwidth preferentially to SP owners it, in fact, it should be given to active creators of valuable content, who are often different people. The rate limiting idea is meant to stop spam, yet it treats all content equally, and from this perspective a bunch of valuable posts from newcomers are indistinguishable from spam.
Instead, it should take the upvotes and reputation into account. Wouldn't it make sense if a whale with low upvote, no reputation and not much network use would be allocated less bandwidth than a valuable contributor, even if the latter has 0.01 SP.
After all, collaborative filtering can usually filter spam much better than capital requirements. On the contrary, the current system allows a whale to spam as much as they want, regardless of content quality.
In addition, the whole voting-bot and various lottery nonsense only makes things worse, as a lot of bandwidth is spent on non-content-related stuff.
I appreciate the way you explained this. 🍹
So a question is: can this be adjusted to be more healthy, towards quality content producers, as you described?
Wish my upvote was worth more to you. It stinks being a plankton!! ❓🐠❓
Well, at the moment the whole design of the system assumes that everything is proportional to SP, so it is certainly not trivial to just change this logic to something else. nor is it even clear how an alternative distribution logic should be designed without people trying to game it in some way.
So if anything, this is can only be a long-term idea. I do hope it eventually comes to the developer team and causes at least some discussion or thought.
True!
Well, here's to being the change you want to see in the world!
Thanks you - should have asked you hours ago!
But I was also getting bandwidth problems.
The bots!
I think it would be nice to discuss this with some actual Steem developers but so far I have no clue how to reach any of those. I think I should try reposting this to #steem-dev, but so far any of my questions there seem to be ignored as if they just did not exist.
One thing I have learnt is that mathematicians are needed to check the formulas and algorithms that underpin this platform - programmers and witnesses have different skills.
In this case, the formula is quite simple but it is the feedback loops that need to be considered. Amazingly, most ppl had never looked at this parameter, the current_reserve_ratio.
In my opinion the whole reserve rate logic is quite sane in general, the problem is only in the fact that it is only proportional to SP instead of something more content-related and dynamic like "recent reputation gains". Adding "number of upvotes in the last week" to the mix could seriously improve the situation.
Another possibly useful idea would be to separate financial transaction bandwidth (where the whales might indeed need some preference) from content bandwidth (where reputation and upvotes should matter more than SP).
I do not see where a feedback loop is being a problem here. Do you simply mean the big "rich get richer" loop where having a lot of SP lets you earn more SP faster?
I have been thinking it would help to have an additional and different way of voting for quality that doesn't involve SP. For example a point system based on a 1 to 5, 1 being low and 5 high that would be summed in addition to the SP votes and that would be used to determine the listing of trending posts. That way the people reading the post would determine it's quality. This would need to have a protection against bot use.
Do you know anything regarding Steem being designed to maintain a value similar to the US$? That would mean that there would be a mechanism present that when the price rises above a dollar to start another mechanism to devalue a Steem to maintain a US$ parity ideal.
I do not believe that more precise feedback would help much. The experience of most social networks shows that people rarely care to provide more feedback than a "like" or a "dislike". In the olden days there were social networks where people could rate photos by setting 1..5 stars, and as far as I understand, most people would either put 5 stars or ignore the photo. 1 star would correspond to "flagging".
In principle, there is nothing wrong with counting upvotes perhaps weighing them. If there were no extrinsic motivations for upvoting, it would be a decent indicator of content quality.
Unfortunately, and somewhat paradoxically, the financial incentivization system of Steemit, although conceived in the hope of raising content quality, plays a lot against this goal to a large extent, forcing way too many people to focus their efforts bluntly gaming the system rather than expressing themselves creatively.
This is even worse with curation rewards, where the current system motivates "curators" to upvote posts based on their author and current upvote numbers, not caring to read them through.
There are many secondary indicators of quality (how many people read the post out of those who saw it, and how many people out of those who read it upvoted it, how much total time people spent on the post, how many comments it attracted), and rewarding the curators for being able to predict a mix of such indicators could, in fact, force people to actually pay attention to the content, rather than the current upvote $ number. Same for the authors.
Steem is not designed to maintain a value pegged to dollar. Steem Dollar is (although it's not perfectly stable, as you may note).
this is so true "In addition, the whole voting-bot and various lottery nonsense only makes things worse, as a lot of bandwidth is spent on non-content-related stuff."
I'm a newcomer trying to make good content, and today is the first time I wanted to post daily and that happened to me. I still don't get this things. Is kinda unfair .
This is irritating to me too, I post original content that isn't short nor spammy nor a simple meme and my comments are usually well thought out and typed out as opposed to the usual "Nice" or "Good post" sort of comment and for someone like me to run into the bandwidth cap it makes me want to yank hair out. I was focusing on Steemit because I figured it'd be nice but lately I'm regretting not posting straight to minds and ignoring Steemit :( I'm rather put off.
Good to know thanks. I would upvote the article but I read somewhere that upvotes are only paid for the first seven days of curaton. Is that correct?
Yes, thanks - but feel free to upvote this comment! :-)
After I wrote the above article, the bandwidth algorithm was changed to be more flexible. Are you experiencing bandwidth limitations?
I did get a bandwidth timeout yesterday actually! How did you know? I have a bot voting for me so I temporarily disabled it while my account recovers lol 😊
A quick msg - I'd love to reply to everyone but am really busy trying to find a solution with witnesses. I'm also afraid of hitting another max bandwidth limit! I will definitely reply to everyone as soon as possible. It's already 11 pm here as I write, so I may even need some sleep! Thanks!
hobble hobble ;)
well that upvote got you some of the way to the top.
a couple more should do the trick.
:-) thanks. believe it or not, at one point I saw the rewards total halve in a couple of hours! That was not nice.
The reserve ratio is currently up to about 800 - was often around 400 and I've seen it as low as 240 or so. It should be at 20,000.
Thank you for the information .<3
Just published a follow-up article: The Bandwidth Game - Join Now - Win 20,000 CRR!
I hope fewer of you are getting bandwidth exceeded errors now.
Cool find. Thanks for doing the research for us. I don't think I could have ever figured all that out, amazing job!
Thank you very much! Upvoted your comment.
Actually, things seem to be operating more smoothly.... dare I say it!! perhaps changing the MVP parameter is now allowing the CRR to rise more smoothly.