grin
grin copied to clipboard
mimblewimble
Initial header sync (request headers from fast peers or avoid slow peers)
The initial sync feels slow. We request headers in chunks of 512 from random connected peer. Sometimes we hit a slow peer and the latency introduced in even a few requests from a slow peer makes the header sync feel slow.
It might be nice to track peer speeds and make a better decision in terms of prioritizing faster peers as we proceed with the header sync.
We already track download rates at some level of granularity (not entirely sure what we do today) as we display this on the TUI - so we may already collect enough information to make this decision around which peers are best to request headers from.
The slowness comes from relying on multiple peers for a synchronous process. The best approach is to just select a single peer to download headers from, and only switch if that peer gets too slow. Grin++ does this, and I just did a header sync in 4 minutes compared to the 10-20 minutes it can sometimes take on grin.
Was having a little look at this. As well as using a single peer for header downloads Grin++ will only wait 12 seconds if a requested header has not been received before retying then banning the peer. Whereas Rust implementation waits 120 seconds.
I'm wondering if multiple peers can be faster than connecting to one slow peer (if the average speed is faster than the single peer).
