Broadcast repeated new view messages to speed up high QC sharing #2042
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
In some cases where the entire network is down, many nodes will have disjoint values of their high QC. The only way for them to sync the high QCs up is to wait for a supermajority of nodes to become the leader of a missed view, meaning it receives `NewView` messages from everyone else and can updates its own high QC. To speed this up, we now broadcast `NewView`s. We still send the first `NewView` message directly to the leader, but we broadcast repeated messages. We also change the `NewView` processing logic to ensure nodes will update their high QC based on received messages, even if they are not the leader of the view.
|
Bencher Report| Branch | broadcast-newviews |
| Testbed | self-hosted |
Click to view all benchmark results
| Benchmark | Latency | Benchmark Result nanoseconds (ns) (Result Δ%) | Upper Boundary nanoseconds (ns) (Limit %) |
|---|---|---|---|
| process-empty/process-empty | 📈 view plot 🚷 view threshold | 9,386,100.00 (+2.81%) | 10,484,576.84 (89.52%) |
| produce-full/produce-full | 📈 view plot 🚷 view threshold | 1,957,800,000.00 (-8.36%) | 2,904,582,435.22 (67.40%) |
86667
reviewed
Dec 19, 2024
86667
approved these changes
Dec 19, 2024
JamesHinshelwood
added a commit
that referenced
this pull request
Dec 22, 2024
PR #2042 added `NewView` broadcasting, but it didn't change anything because nodes ignored `NewView`s that were not sent via a direct request. In fact that PR made network recovery worse, since the leader would no longer see repeated `NewView`s. This PR just adds the handler for broadcasted `NewView`s.
JamesHinshelwood
added a commit
that referenced
this pull request
Dec 22, 2024
PR #2042 added `NewView` broadcasting, but it didn't change anything because nodes ignored `NewView`s that were not sent via a direct request. In fact that PR made network recovery worse, since the leader would no longer see repeated `NewView`s. This PR just adds the handler for broadcasted `NewView`s.
github-merge-queue bot
pushed a commit
that referenced
this pull request
Dec 22, 2024
PR #2042 added `NewView` broadcasting, but it didn't change anything because nodes ignored `NewView`s that were not sent via a direct request. In fact that PR made network recovery worse, since the leader would no longer see repeated `NewView`s. This PR just adds the handler for broadcasted `NewView`s.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
In some cases where the entire network is down, many nodes will have disjoint values of their high QC. The only way for them to sync the high QCs up is to wait for a supermajority of nodes to become the leader of a missed view, meaning it receives
NewViewmessages from everyone else and can updates its own high QC.To speed this up, we now broadcast
NewViews. We still send the firstNewViewmessage directly to the leader, but we broadcast repeated messages.We also change the
NewViewprocessing logic to ensure nodes will update their high QC based on received messages, even if they are not the leader of the view.