I previously wrote in detail about the bandwidth limitation that was affecting all the Steem users, specially the minnows.
https://steemit.com/witness-category/@drakos/the-bandwidth-limitation-problems-and-solutions
My interest on that matter started around the end of January 2018 where the problem was hitting us the hardest on a daily basis, and the https://steem.chat/help channel was being flooded with frustrated users (notice it's steem.chat now, instead of steemit.chat). Therefore I researched and dug deeper to understand what was happening. The main parameter governing the bandwidth allocation was the reserve ratio, as I covered in my previous post.
Charting the Reserve Ratio and Average Block Size
So I figured I'd collect some data to analyse the movements of the reserve ratio as well the average block size, to see if there was any tangible correlation to help us understand the issue. After days of developing the chart and testing, I started collecting data since 1 February 2018 with 5 minutes intervals. The data is stored in a MySQL database and the chart is powered by Google charts.
The chart is available at https://steemian.info/reserveratio or by clicking the Tools in the navigation bar on the website.
After days and weeks of collecting points, a pattern started to emerge. Although I was expecting to see a direct correlation between the reserve ratio and the average block size, I didn't find any! In fact, while the reserve ratio would fluctuate drastically during the day, from <100 to 20000, the average block size remained relatively around the 16384 bytes threshold (25% of the maximum block size). The average block size sometimes spiked to 19000-20000 but never above that, and it dipped to 12000 and even 5000 at one time! But overall, it stayed around 16000 bytes.
Surely there are mathematical factors (beyond my abilities) behind the algorithm that controls the reserve ratio. Nevertheless the chart showed a daily pattern of rush hours. Every day, roughly between 8:00 and 14:00 EST, the reserve ratio dips below 100, that's where the users experience the worst effects of the bandwidth limitation. The system recovers quickly past 15:00 to go back to more acceptable levels above 1000-2000 and reach its peak at 20000 during the night. And... the cycle starts again on the next day.
Here's the chart for 9 March 2018. It was an exceptional day where the reserve ratio barely dipped below 2000! Smooth sailing for all. As expected, the reserve ratio was cruising at 20000 after 15:00, like all previous days.
(click to enlarge)
And here's the chart for 1-9 March 2018, where we had many days below 100.
(click to enlarge)
According to @roadscape, who's been following this issue very closely for a while now, when the reserve ratio goes below 500 is when we start to see problems. In my observations, when we're below 100 is when the users start to complain.
Interactive Live Chart
The chart is live and interactive with many features to play with. Although I'm collecting data every 5 minutes, I'm showing the points every 10 minutes, otherwise charting weeks of collected points would be too sluggish. The chart will refresh every 5 minutes if you leave it open. By default, the current day is showed but you can customize the chart as follows:
- Click on the dates to select a Start and End period.
- Toggle the Linear (default) or Log Scale. I recommend the logarithmic scale where it's easier to see and analyse the lower reserve ratio values.
- Zoom in/out with the mouse wheel.
- Hover the mouse on the points to show their values.
- Left-click and hold to move horizontally.
- Right-click on the chart to reset.
What Have We Learned?
If you're having daily problems with bandwidth limitations, I proposed several solutions in my previous post. For the users, it's either reduce the weekly transactions and/or power up more STEEM. Now, we have learned there's a third option and it consists of avoiding the rush hours between 8:00-14:00 EST.
Perhaps it's an opportunity to do some real work during the day, and blog on Steemit in the evening. I know it's hard to resist the temptation of Steemit...
Closing Thoughts
I hope you find the chart useful, whether you're a user or a Steem developer. If you have suggestions or any other data/charts you might want, let me know, I'd be happy to oblige.
Thanks to @roadscape for his input about the reserve ratio during my initial research.
Available & Reliable. I am your Witness. I want to represent You.
π³ If you like what I do, consider voting for me π³
If you never voted before, I wrote a detailed guide about Voting for Witnesses.
Go to https://steemit.com/~witnesses. My name is listed in the Top 50. Click 
once.
Alternatively you can vote via SteemConnect
https://v2.steemconnect.com/sign/account-witness-vote?witness=drakos&approve=1
I showed up in January and before I built up any SP I would have negative bandwidth almost daily, even after barely posting or upvoting. For a new user trying to acclimate here, running into bandwidth issues is a deal-breaker, especially since most likely don't even know that bandwidth is a thing or how it works.
This all falls under tricky math so it's awesome you put this together to track the data and make it way more understandable. Hopefully this drives further insights that can be used to solve the bandwidth issues.
It was a rough period for all minnows.
You got a 8.26% upvote from @postpromoter courtesy of @drakos!
Want to promote your posts too? Check out the Steem Bot Tracker website for more info. If you would like to support the development of @postpromoter and the bot tracker please vote for @yabapmatt for witness!
Great research! Having a high volume time frame to avoid reminds me of when cell phone plans had "free nights and weekends" to encourage people to use the service in off-hours.
Really wonderful information You are a wonderful person providing us with great information Well done, my friend
Hey, glad you like it!
I will work on adding it ASAP =)
Very nice post, please give me about the procedures to be professional stamians, I am very happy if you want to give me upvote in every post I, for your willingness and time I thank you. Signed. @zayanfaruk
It's good to see that you care, to take your time to research on how to improve we the users, leaving steemit during the day is really tempting like you said, but we have to try it. Nice post
Thanks. Next thing, dive into the algorithm.
Or at least point towards the algorithm that calculates this in the source. That would help me a bit further.
Why 25% of maximum blocksize?
Why did the witnesses agree on that? :)
At least the top 20 have to answer this.
If they are notable to do so, why are they in the top 20:))
Why not 30%, why not 10%?
I explained the 25% in the previous post. I'm not a professional programmer and not a fan of C, those waters are treacherous for my boat lol. The 25% is not a witness parameter/decision, it's hardcoded in the steem code, it could be tweaked if the developers decide to do it.
Yes, I know it is hardcoded.
But the witnesses decide if a HF is used or not.
Otherwise, they are just the puppets for STINC and the developers.;)
Or isn't this one of the task of the witnesses?
I always thought they would decide, whether to implement something or not in production.
You don't need to explain, just link to the file/line
:)
I believe we should start increasing block size at 5% intervals. I also talked to @roadscape abut this, and the thinking is, the reserve is very volatile, so we need to increase in small increments, say 5%. Then see how it goes at and give time fr RR to balance out as we go.
This talks more about it also https://github.com/steemit/steem/blob/f762f1407f615c8e8fb3d4c9dec2f61801d4d5ee/libraries/plugins/witness/witness_plugin.cpp#L275
Thanks for showing these stats @drakos, great job!
If I'm not mistaken, the algorithm for
current_reserve_ratiois in https://github.com/steemit/steem/blob/master/libraries/plugins/witness/witness_plugin.cppThanks!
That comment is interesting:
* If the reserve ratio is consistently low, then it is probably time to increase * the capcacity of the network.Well, it might be the time right now, to increase:)
Don't worry it's C++ with templates. ;)
As you said before! It's very useful, so this info is gold for the people that begins here.
Thanks for all your help dude, you ROCK!
I'm confused about something, according to Steemd, I still have 99% bandwidth, but Steemit still seems slow to me. I especially notice it when trying to upvote posts, takes around a minute to actually upvote the post.
Or doesn't that have anything to do with the bandwidth? I've tried on multiple connections.
I would think I have enough SP, just powered up to 127 SP.
Those are RPC or website/routing issues, not related to the bandwidth limitation.
Hey, glad you like it!
I will work on adding it ASAP =)
My dear friend @drakos π , thanks you so much for amazing information , And the advice and guidance useful to all members, a third option is best for new members and it consists of avoiding the rush hours between 8:00-14:00 EST , or reduce the weekly transactions.
Good luck my dear friend @drakos πππ
All the best for you ππ
This post has received gratitude of 12.10% from @appreciator courtesy of @drakos!
This is good work @drakos - we need to pay attention to all vital signs of the health of the blockchain.
Your recommendations for avoiding "rush hour" are helpful too.