How long it takes to Sync when running a node on a new computer?? #833
Assignees
Labels
Comments
|
Connected with #823 Glad to hear some explanation about underlying implementation |
|
Blocks pulled from bootstrapping are not considered active. I believe the primary issue is DB and disk performance. |
|
@PlasmaPower Thank you for reply, I noticed that there is a modification in V12 that to check if the block is recently arrived, if it is not ,it will not add to election list, Is this what you said "Blocks pulled from bootstrapping are not considered active." ? BTW, it seems the Sync on my PC works very slowly and nearly no progress in the last two days, My PC with i5 CPU and SSD disk, Any idea what is go on? |
|
It's always been that way. We have just changed around the exact mechanics of it recently |
|
You could try restarting the wallet. I'm not sure what's going wrong in your specific case. Logs may help. |
|
it goes to this status in 5 hours |
|
may be related #748 (a new-old performance issue even on fast SSDs) |
|
Restart this wallet， log shows as blow: |
|
@PlasmaPower It seems like most of the blocks pulled from bootstrapping will be checked as "gap_previous" or “gap_source”, then these blocks will be kept in the unchecked_cache until the missing "previous" or "source" was received and checked successfully, and then they can been re-processed. But how can the network make sure this node will definitely re-received the missing "previous" or "source" blocks for no nodes are rebroadcasting them? |
The node already has the missing blocks in unchecked but it hasn't processed them yet. |
|
@PlasmaPower |
|
When a block is processed, any blocks that depend on it (and were previously missing that block) are processed next. |
|
@PlasmaPower Back to the former question: "how can the network make sure this node will definitely re-received the missing "previous" or "source" blocks for no nodes are rebroadcasting them?" |
|
It simply pulls all blocks of other nodes. If those nodes have a block, they will have its dependency. |
|
@PlasmaPower Thank you, Yes, the mechanics works. The current state of my node is that all the blocks in my node is 832555 + 7621827 = 8,454,382 ,while the blocks of whole network is 8,791,060, which means there are 300000 blocks not pulled from other node, and it seems the following 300000 blocks download very slowly. What's reason may be ? Any idea how to accelerate it ? |
|
With the changes added recently in V17.0 with regards to Lazy Bootstrapping and improvements with fork resolution, I believe this issue is resolved in V17.0. Please re-open if this issue persists with V17 ! Thanks ! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Description of bug:
Hi, I have been running a NANO node with version 12.1 for a week but it seems still not sync finished, the wallet shows the block number like 719499(7479560), So I am wondering how long it may take to sync when running a node on a new computer?
I checked part of the nano code, as I can see the two number shows on the wallet like the pic above, the first number is the Blocks which has been verified and the second one is the Blocks which has been pulled from other nodes but not verified yet --- saved the unchecked_cache in the code. And it seems all the Blocks in the unchecked_cache need to verified again and then saved, each block verify need to broadcast 4 times with a period of 16 seconds, so roughly it does will take a long time to verify all the blocks and will also create a lot network broadcast pressure, is it really necessary to run a full procedure to verify all the blocks again on every new launch node ?
Please correct me if the understanding is wrong, thank you so much!
Steps to reproduce the issue:
Describe the results you received:
A week passed, but still on sync.
Describe the results you expected:
I am wondering how long to sync when running a node on a new computer?
Additional information you deem important (e.g. issue happens only occasionally):
Environment:
Windows
logs
The text was updated successfully, but these errors were encountered: