-
Notifications
You must be signed in to change notification settings - Fork 786
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
V21.3 service release #3140
Merged
Merged
V21.3 service release #3140
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
from 128GB to 256GB
…rge amount of frontiers.
…diately upon receipt.
Up until "recently", a new write transaction was opened to update work on the ledger for every single block. Now with deferred work updates on the block processor, it is no more expensive than processing a new block, so it makes sense to remove this constraint of having been recently dropped. This improves quality of service. The previously implicit check for confirmed dependents (since the election was dropped) is now explicit. The work on the ledger is updated regardless of that check passing. The election is not immediately inserted as *active* anymore, same behavior as the normal election insertion path. Note that if an election is active, the work is **not** updated on the ledger. That behavior also seems desirable. This could be achieved by updating the store after the block is identified as old, directly within `ledger::process`. For post-processing, a flag can be passed to `blockprocessor::process_old`, at which point `active_transactions::restart` can be scrapped since it becomes a simple election insertion + stats update (with a dependents confirmed check). Since this change would touch ledger code I am leaving for others to do it. There's also the question if the confirmed status should be checked within the ledger processing code. Note: only tested via core_test. # Conflicts: # nano/core_test/active_transactions.cpp # nano/core_test/node.cpp # nano/lib/locks.cpp # nano/lib/locks.hpp # nano/node/active_transactions.cpp # nano/node/active_transactions.hpp
…o 280/sec -> 28/sec. This option is also made configurable. Confirm_req batches are used in the bootstrap process and excessive requests to reps can degrade performance and often get dropped. # Conflicts: # nano/node/active_transactions.cpp # nano/node/confirmation_solicitor.cpp # nano/node/nodeconfig.cpp # nano/node/nodeconfig.hpp
…ause unnecessary restarting of the bootstrap process.
* Throttled removal of rep crawler targets * Remove recursion
clemahieu
force-pushed
the
frontier_perf_improvements
branch
from
March 17, 2021 16:29
d1f01a3
to
033ad7d
Compare
zhyatt
approved these changes
Mar 18, 2021
clemahieu
changed the title
V21.3 and synchronization improvements
V21.3 service release
Mar 18, 2021
zhyatt
added
documentation
This item indicates the need for or supplies updated or expanded documentation
protocol change
Change to protocol requiring new version
labels
Mar 18, 2021
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
documentation
This item indicates the need for or supplies updated or expanded documentation
performance
Performance/resource utilization improvement
protocol change
Change to protocol requiring new version
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Removes peer-banning. This compounds synchronization delays if the network is already out of sync by disconnecting from good nodes
Requests frontiers by age which will reduce the bandwidth consumed during the frontier comparison process
Rebroadcasting blocks only when an election is active. This will stop block propagation for blocks that don't have an open election.
Removed bootstrap restarting code as ineffective.
Reduce the number of confirmation requests per batch from 20 to 2.
Added an optional flag was added to the frontier request message which requests that the response should include confirmed frontiers rather than the unconfirmed frontiers.