"No matter the black cat white cat, can catch the BUG is a good cat", from Bandwidth Limit Exceeded talking about Bandwidth Limit Exceeded

"No matter the black cat white cat, can catch the BUG is a good cat", from Bandwidth Limit Exceeded talking about
Bandwidth Limit Exceeded

If you have never heard of witnesses and do not know what role the witnesses play in the STEEMIT network, then look at my article:

📌 focus on the end of the article / witnesses, how to vote for the witness and set up a witness vote

Assuming you have some knowledge of the witness, then you may be in doubt, what is the relationship between the witness and the cat?
This is from the previous few days to send an error frequently, that is Bandwidth Limit Exceeded

For this error, I have written two analysis articles:

Look at Bandwidth overruns from code and how to avoid and solve
Steemd.com has been blessed by friends who have been tortured by Bandwidth Limit Exceeded

The first article is not far from the level of the article, completely from the user's point of view, because I think that the system-related information we can not change, we can only change our own. So come to the conclusion that: increase vshares accounted for (buy buy buy), or reduce your average bandwidth occupied (etc., minus). Do not say the second way to reduce the number of operations, reduce the length of the text brought about by the many unhappy, the way one is not to STEEM into a network of money first? (Is not it?

The second article, I know that the original Bandwidth Limit Exceeded is caused by a BUG, ​​the BUG called overflow (Overflow), the BUG caused max_virtual_bandwidth becomes very little, which led to the normal operation of the user is limited.
How to deal with BUG

So since there are BUG, ​​and we repair the BUG, ​​and then upgrade to the new version, like a chant?
Things are not that simple.

In my experience of N-Year code, I did not have to repair the old BUG to introduce new BUG, ​​especially for a complex system. There is a vocabulary called pull the hair and move the whole body, if rush to upgrade may fall into repair BUG-> upgrade -> generate a new BUG-> repair BUG-> upgrade -> generate a new BUG cycle.

@gtg updated today's Witness log
One of the words is very interesting: We've got trouble, we've made it double

In his article, it was mentioned that when the Bandwidth Limit Exceeded problem occurred, one of the witnesses suggested that the maximum_block_size be modified to: 131072 to achieve the purpose of raising max_virtual_bandwidth:

Dgp.max_virtual_bandwidth = (dgp.maximum_block_size * dgp.current_reserve_ratio * STEEMIT_BANDWIDTH_PRECISION * STEEMIT_BANDWIDTH_AVERAGE_WINDOW_SECONDS) / STEEMIT_BLOCK_INTERVAL;

From the top of the formula, looks like no problem.
However, when you respond to the call and modify maximum_block_size, you find that the problem remains (or becomes more serious)

Then, found that the problem is overflow, we have the maximum_block_size back to: 65,536

So if you use the official release of the new code to upgrade it? This is of course one of the options, but if there is a new BUG introduction, there is no back to change the maximum_block_size parameter so simple.
Cat clan also war

Said so much, you may ask, what is the relationship between this and the cat? Is it, how to see and the cat can not be related.

In fact, one of the witnesses has proposed and implemented a very interesting solution, that is, to solve (avoid) the problem of Overflow, and no need to rush to upgrade the node, would it be the United States?

The idea of ​​this program is to send some extra content to steem by pulling the average_block_size when the overflow is about to happen. In 0.19.0 and previous versions, changes in average_block_size will be applied to current_reserve_ratio, which is described as follows:

  / **
   * Average block size is updated every block to be:
   *
   * Average_block_size = (99 * average_block_size + new_block_size) / 100
   *
   * This property is used to update the current_reserve_ratio to maintain approximately
   * 50% or less utilization of network capacity.
   * /
  Int32_t average_block_size = 0;

  / **
   * Any time average_block_size <= 50% maximum_block_size this value grows by 1 until it
   * Precipitation STEEMIT_MAX_RESERVE_RATIO. Any time average_block_size is greater than
   * 50% it falls by 1%. Upward policies happen once round, downward adjustments
   * Happen every block
   * /
  Int64_t current_reserve_ratio = 1;

So long content, high average_block_size, let it be greater than 50% maximum_block_size will reduce the current_reserve_ratio, let it return, and thus avoid causing Overflow

Said so much, where is the cat?
In fact, it is a very long reply to the use of a variety of cat map.

For example, from the following sources:
Http://www.ascii-art.de/ascii/c/cat.txt
Https://github.com/melaniecebula/cat-ascii-faces
Http://textart.io/art/tag/cat/1

For example, this goods (STEEMIT line high problem, fat cat high, but still very fat):
Why use cat diagram

In fact, I do not know why the cat map
Or because: "regardless of the black cat white cat, can grab the mouse BUG is a good cat?"
to sum up

Bandwidth Limit Exceeded problems plagued many new and old customers
STEEMIT official and many witnesses have acted
@ber With a deep understanding of the code, with the cat to avoid the overflow (Overflow) problem

Was originally a very wonderful thing, after writing that did not show the wonderful, but also failed to explain the relevant technical issues, it is limited capacity. But I still decided to send out, so that we understand the smooth operation of STEEM behind the witness to the people to do the pay. This is to witness people, let us pay tribute to them!