-
Notifications
You must be signed in to change notification settings - Fork 249
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
Improve sync from DSN #1793
Improve sync from DSN #1793
Conversation
beea722
to
a1076dc
Compare
Fixed a bit tricky concurrency issue around ordered acquisition of permits in previous revision, now seems to work fine |
@@ -319,15 +256,15 @@ where | |||
downloaded_blocks += 1; | |||
|
|||
if downloaded_blocks % 1000 == 0 { | |||
info!("Imported block {} from DSN", block_number); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It was an indicator of the importing progress. Can we add a similar message somewhere?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You'll see usual sync speed reporting, this is on my machine with sync from DSN:
2023-08-10 17:25:19.419 INFO tokio-runtime-worker substrate: [Consensus] ⚙️ Syncing 12.4 bps, target=#59922 (6 peers), best: #50026 (0x4a90…cf38), finalized #9199 (0xa7b7…02b7), ⬇ 3.8kiB/s ⬆ 83 B/s
a1076dc
to
15fe6f5
Compare
… nothing to import anyway
Found that it still pulls unnecessary segment header under certain circumstances. |
…pace#1791 autonomys/subspace#1786 autonomys/subspace#1787 autonomys/subspace#1785 autonomys/subspace#1783 autonomys/subspace#1761 autonomys/subspace#1782 autonomys/subspace#1784 autonomys/subspace#1778 autonomys/subspace#1776 autonomys/subspace#1762 autonomys/subspace#1772 autonomys/subspace#1777 autonomys/subspace#1767 autonomys/subspace#1775 autonomys/subspace#1768 autonomys/subspace#1771 autonomys/subspace#1760 autonomys/subspace#1766 autonomys/subspace#1742 autonomys/subspace#1765 autonomys/subspace#1770 autonomys/subspace#1764
…pace#1791 autonomys/subspace#1786 autonomys/subspace#1787 autonomys/subspace#1785 autonomys/subspace#1783 autonomys/subspace#1761 autonomys/subspace#1782 autonomys/subspace#1784 autonomys/subspace#1778 autonomys/subspace#1776 autonomys/subspace#1762 autonomys/subspace#1772 autonomys/subspace#1777 autonomys/subspace#1767 autonomys/subspace#1775 autonomys/subspace#1768 autonomys/subspace#1771 autonomys/subspace#1760 autonomys/subspace#1766 autonomys/subspace#1742 autonomys/subspace#1765 autonomys/subspace#1770 autonomys/subspace#1764
There were several issues with sync from DSN, I'm surprised it worked at all 🙈
So first I removed initial sync from DSN mode. It doesn't seem to be required anymore since we can discover when node is not synced in runtime just fine.
Then turned out
while block_number - best_block_number >= QUEUED_BLOCKS_LIMIT.into() {
was buggy since neitherbest_block_number
was updated nor blocks were imported in between, essentially making this an infinite loop in case blocks are small enough to accumulate more than 2048 blocks in one segment.Then turned out node was showing 0 peers on Substrate level due to pruned peers responding with no blocks when requested, but when we skip requests we can maintain connections, so I decided to start with paused sync mode and wait for networking to come alive and kick in DSN sync before anything else.
Last commit adds concurrency for piece retrieval, allowing to pull pieces at over 100 Mbps speed easily, making everything move much faster.
As the result sync from DSN should be much less broken than before.
Code contributor checklist: