[Merged by Bors] - sync, blocks: request blocks when tortoise crossed local threshold #4826
Conversation
|
bors try |
dshulyak
changed the title
tryBuild failed: |
Codecov Report
@@ Coverage Diff @@
## develop #4826 +/- ##
=========================================
- Coverage 76.9% 76.9% -0.1%
=========================================
Files 261 261
Lines 29621 29637 +16
=========================================
+ Hits 22783 22792 +9
- Misses 5392 5394 +2
- Partials 1446 1451 +5
|
|
bors try |
tryBuild failed: |
|
bors try |
tryBuild failed: |
|
bors try |
tryBuild succeeded! The publicly hosted instance of bors-ng is deprecated and will go away soon. If you want to self-host your own instance, instructions are here. If you want to switch to GitHub's built-in merge queue, visit their help page. |
|
@countvonzero need to add a test, but please take a look. i think it is more robust than the previous version |
|
bors try |
tryBuild failed: |
|
bors try |
tryBuild succeeded! The publicly hosted instance of bors-ng is deprecated and will go away soon. If you want to self-host your own instance, instructions are here. If you want to switch to GitHub's built-in merge queue, visit their help page. |
| return &types.ErrorMissing{MissingData: types.MissingData{Blocks: missing}} | ||
| select { | ||
| case <-ctx.Done(): | ||
| case msh.missingBlocks <- missing: |
There was a problem hiding this comment.
this approach still relies on ProcessLayer being triggered by some component.
currently there are two components (proposal builder and state syncer) that calls TallyVotes(), which cause the tortoise to verify a layer. only state syncer will call ProcessLayer and cause the block to be fetched.
is it possible to tie the block fetching with TallyVote instead? tho that may delay generating block proposals.
or maybe TallyVote() should be called with OnBallot() (too expensive?) and cause the blocks to be fetched more frequently?
There was a problem hiding this comment.
it is also called by block builder (check ProcessPerHareOutput), i would prefer not to add it to the tortoise. maybe at some point when i remove ProcessLayer alltogether
There was a problem hiding this comment.
is it possible to tie the block fetching with TallyVote instead? tho that may delay generating block proposals.
or maybe TallyVote() should be called with OnBallot() (too expensive?) and cause the blocks to be fetched more frequently?
it makes sense to tie with local threshold, it is bigger change though. and this is needed semi-urgently
|
bors try |
tryBuild succeeded! The publicly hosted instance of bors-ng is deprecated and will go away soon. If you want to self-host your own instance, instructions are here. If you want to switch to GitHub's built-in merge queue, visit their help page. |
|
bors try |
tryBuild succeeded! The publicly hosted instance of bors-ng is deprecated and will go away soon. If you want to self-host your own instance, instructions are here. If you want to switch to GitHub's built-in merge queue, visit their help page. |
|
bors merge |
…4826) closes: #4824 - first improvement is to register peers that supported blocks, otherwise we will be guessing from whom to request the block - and when mesh is called by sync or block builder it may send request to fetch blocks from registered peers. previously it would do so only in sync code path, which is less robust and might be delayed by fork finder
|
Pull request successfully merged into develop. Build succeeded! The publicly hosted instance of bors-ng is deprecated and will go away soon. If you want to self-host your own instance, instructions are here. If you want to switch to GitHub's built-in merge queue, visit their help page. |
bors
bot
changed the title
…4826) closes: #4824 - first improvement is to register peers that supported blocks, otherwise we will be guessing from whom to request the block - and when mesh is called by sync or block builder it may send request to fetch blocks from registered peers. previously it would do so only in sync code path, which is less robust and might be delayed by fork finder
…pacemeshos#4826) closes: spacemeshos#4824 - first improvement is to register peers that supported blocks, otherwise we will be guessing from whom to request the block - and when mesh is called by sync or block builder it may send request to fetch blocks from registered peers. previously it would do so only in sync code path, which is less robust and might be delayed by fork finder
…pacemeshos#4826) closes: spacemeshos#4824 - first improvement is to register peers that supported blocks, otherwise we will be guessing from whom to request the block - and when mesh is called by sync or block builder it may send request to fetch blocks from registered peers. previously it would do so only in sync code path, which is less robust and might be delayed by fork finder
closes: #4824