Down the Rabbit Hole. "The case of the Bandwidth Bug"

"... we interrupt your regularly scheduled programming with this Breaking News!"

more like, "Breaking News about the Interruption of our Regularly Scheduled Programming"

The past few days are a blur.

I started experiencing the "Bandwidth Exceeded Bug" two days ago, after it had already been happening to many for 24 hours. I became curious to understand what was happening, so I did some searching. That search became a quest. This is both the story of that quest, and a collection of the resources I gathered. There will be a recap for anyone who just wants the highlights, and some of the latest updates I've found.

36 hours into the "bandwidth bug" I was amazed at how little information I could find on what was happening. Rumors and speculation as far as the eye could see. There were a number of posts from users who complained of the bug, but it was very difficult for me to find any solid information.

On steemit chat I heard that the bandwidth issue was somehow tied to the value of steem. Now, I couldn't find anything else to support that information, but I thought "That is a Story!" That's when I started writing Bandwidth limit exceeded. Is the Price of Steem to Blame?

In the comments section of that post was where I started to get some real leads. I began updating that article with newest information I could find by the minute. By the end of the night I got closer to the heart of Steem than I expected after only having had an account here a for a few weeks.

The Short Version.

@rycharde has written, by far, the most informative posts in the bandwidth saga. His latest is no disappointment.

The current thinking is that this sudden spike in bandwidth caused by an experiment_(@netuoso) triggered the algorithm for the current_reserve_ratio (CRR) that is designed to respond to a spam or DDoS attack. The consequences of this CRR algorithm are to immediately halve the network bandwidth.

But as users carried on doing their normal behaviour, completely oblivious that this was happening in the background, they triggered the CRR to continue to fall. Remember, the CRR is designed to protect the network from overloading. In this case, it was not a real overload but a temporary spike. _{@rycharde - Bandwidth Bug Explained}

What do we do? The sky is falling! HAAALP!

For those of us who aren't developers there isn't much that we can do.

There have been a lot of users running into bandwidth limitations recently. The Steemit dev team has been reviewing the issue and is working on changes to the bandwidth formula that will improve the situation. They opened GitHub issue 1257 to improve the formula. and have also already checked in a pull request to change. Based on what has been reported in GitHub, it looks like this will be available soon. _{@timcliff Bandwidth issue Fix in the works. Softfork 19.1}

Know your Witnesses!

Vote for witnesses who responded quickly. Many responded immediately, but were lacking the votes to actually change anything. You decide who is a top witness and those top witnesses are the ones who can quickly resolve issues. So if you vote for witnesses who were quick to react, you put them in a better position for next time an issue occurs and simultaneously send a statement to those who don't.
_{@reggaemuffin Bandwidth Limit - How Witnesses Help You}

I've been on the hunt, trying to figure out which witnesses are responding. As a new user, I haven't voted on too many witnesses yet. I'm still getting to know who they are. But when I see a witness lending thier voice and taking an active approach to an issue that so many are struggling with, it's an easy vote.

Vote, Vote, Vote, Vote!

The first post I saw by a witness on the bandwidth issue was from @someguy123

Over at the Minnow Support Project, we're getting bombarded with users complaining about the bandwidth problems. Turns out it's not just a UI issue, as @personz figured out. [@personzzz is his witness account] _{@someguy123 Dear Witnesses, Please increase your BlockSize}

In above post I find that @someguy123 @personzzz @neoxian and @timcliff are some of the first responder Witnesses on the job. After a little more reading into who they are, it's pretty easy. Vote, Vote, Vote, Vote.

To top it off it turns out @timcliff was proposing the increased bandwidth limits a month ago Updated Witness Parameter. Max Block Size to 131072

@blueorgy is another witness who was pretty quick to respond to our dismay:

With @timcliff's initial post last month & @someguy123's most recent call for witnesses to increase their maximum_block_size parameter. The top 20 witnesses have come to a somewhat consensus and soon, I'm sure, will be an unanimous one. _{@blueorgy -
Witness Consensus Reached for Maximum Block Size}

Last night witness @reggaemuffin also came out with a helpful post on the subject.

In my opinion, these witnesses reacted swiftly to the change and mobilized others (in no particular order):

@personz @gtg @someguy123 @reggaemuffin @liberosist @drakos @lukestokes @timcliff @neoxian @ausbitbank and soon to be witness @rycharde
_{@reggaemuffin - Bandwidth - How Witnesses Help out}

You can check the comments section of that post for more information.

In the Meantime....

You may have noticed. At the top of your page on steemd.com, a new bar has been added which highlights both your Voting Power and your Bandwidth Percentage Available.

Besides watching and waiting for your bandwidth to increase, you can also try avoiding bandwidth intensive tasks. Such as repeatedly editing long posts on Steemit. (that's me) Another thing to avoid, is using bots with long curroration trails. These curroration trails are part of what spikes our bandwidth use, as a community. Also if you are trailing bots who vote a lot it can effect your individual bandwidth level quite a bit.

@alphacore has a good article on how to use less bandwidth!

If you want to keep up with the current reserve ratio check steemdb.com. It's in the bottom right hand corner of the main page.



"normal" should be 20,000!!!!

Please Please Please

Get to know your witnesses, and vote for the ones you feel are best representing you.

@necrophagist has interviewed some of the witnesses mentioned above.

• A moment with @timcliff the steemit sage: a witness awareness interview
• Interview with @someguy123, Witness Awareness Series (Steemit heroes)
• Interview with @neoxian: Witness awareness

Besides that, there is plenty of information in this article for you to Go Down The Witness Rabbit-Hole while you are waiting for your bandwidth levels to rise. :-)

please comment if I left anyone out, or failed to note a signifigant development in the situation.

THANK YOU!!

Soon, I will be back to my regular articles on Social Skills. However, you can expect more updates on this issue as it develops!

So, apparently, the softfork 19.1 has been released and is being implemented by witnesses as we type!

@sc-steemit/Steem-v0-19-1-rc1-Released

See [Easy Witness Voting Guide- Bandwidth Solution - softfork 19.1]