-
Notifications
You must be signed in to change notification settings - Fork 787
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Change Bandwidth Reserve Ratio Algorithm #1257
Comments
@mvandeberg will this help low SP users to have a bit more chance for voting? |
Yes, because the current algorithm is too aggressively increasing SP requirements for sustained usage. We are not concerned if low SP users are prevented from voting or posting once and a while. But they should be able to log in for 30 minutes, comment and vote on some things and not worry that they will run out of bandwidth. Before we release this new algorithm we will do some comparative analysis between both algorithms to verify that it fixes the immediate problem. |
Many thanks. Do you have a tentative timescale, assuming the analysis is positive? |
This will be included in 0.19.1. We are aiming to have a prerelease branch up asap. |
Are there any other changes planned for 19.1? |
Anything that has been merged to master since 0.19.0. I have not compiled the release notes for 19.1, but will do so before a tagging a prerelease branch. |
Your reasoning that bandwidth is to prevent the rewards pool from fulling draining is incorrect. The rewards allocation algorithm prevents that itself. Bandwidth is purely to prevent the blockchain from being spammed. Most chains rely on transaction fees. We don't specifically because we don't want Steem to be pay to play. However, we cannot have a single rate that controls every account or else those that create multiple accounts would be at an advantage. The only logical choice to rate limit based on stake (Steem Power). This argument applies to other aspects of the Steem blockchain as well. |
Understandable. Steem has a lot of moving parts. I do not try to reprimand, but educate, on the ins and outs of Steem. |
This sounds like a reasonable fix. Great reaction. I am currently trying to see how Can you link the branch/pr this gets worked on here, once it is started so we can review and discuss changes? |
This description of the algorithm is high level. Implemented, the sign of the distance is preserved. I am testing locally right now. |
Related #1250 |
Ahh that makes sense then. I'll review the code later today and see if I can find any problems. |
|
Are we taking advantage of any AVX specific support on the code? |
|
It is unlikely that the index will exist and the object will not (it has the be the first time the plugin is loaded and has not yet received a block). Nonetheless, I am adding a check there to have consistent behavior in all circumstances. I am changing the default value for |
Currently the reserve ratio decreases too quickly (can only decrease by half) which results in a sawtooth pattern at equilibrium.
Instead, we propose changing the reserve ratio as a function of the distance between the average block size and 25% of the max block size.
Long term, the desired block size should be independent of the max block size, but that will require another witness parameter to vote on and we want to get this change out asap.
Once a minute the reserve ratio will be adjusted based on the distance from 1/4 of the max block size (normalized to 1/4 of the max block size).
distance = |( average_block_size - ( max_block_size / 4 ) ) / ( max_block_size / 4 )|
Then, the reserve ratio will be adjusted up or down by
reserve * distance / (distance + 1)
. At most, the reserve ratio can decrease to 1/4 the current value (when average block size is the max block size) and can increase to 3/2 the current value (when the average block size is 0). Most cases, the average block size will be close to 1/4 the max block size and the adjustment will be small in either direction.This satisfies the original design goal of aggressively decreasing the reserve ratio under high use to prevent spam as soon as possible but allows for fine adjustments when the average block size is not changing over time.
The text was updated successfully, but these errors were encountered: