They tweeted that node can sync 2670000 block in 11 minutes.
it means it could sync as archive node? Grin takes normally 3-4 days to finish.
It also matters if this is the speed for an average node or for example with a fast PC with many fast peers on a local fast network. Would be interesting to look how their sync works.
mwc-node/core/src/core/pmmr/segment.rs at master · mwcproject/mwc-node · GitHub
Looks like they copied Parallel Initial Block Download (PIBD) from Grin, perhaps they increased the segment size, line 359
segment_size += 8 + 32;
What do you think @Yeastplume, is there any downside for increasing segment size? Perhaps slower node might have connection time outs?
As is stated in the lines above line 359 copied from Grin, there is still a lot of room to optimize/increase speed. PIBD is just a very good new sync method and yes, if optimized, it can be very fast! I think that is the main take away.
Couldn’t a dynamic approach be considered?
Depending on how much the respective node yields.
I think this was in the planning, either make it a setting or some sort of auto tuned speed.
In reality it might be difficult because each peer might have a different speed. So basically you should ask you peer first, 1) what is your max allowed segmentation size, 2) Then send me segments in that size. It also begs the question how a node knows what speed it can handle, it might also be different for nodes within the same country compared to nodes that have to transfer across the globe.
The only thing I know is that it is worth taking the 80% 20% approach here. With some minor optimizations (20% of the work) we can probably get a great improvement (80% of what theoretically could be achieved.
2 Likes