Closed antiochp closed 6 years ago
Is this a single message of 500 headers broken out into smaller chunks? How?
@antiochp that is for HeaderSync optimization from https://github.com/mimblewimble/grin/pull/1400
It's not a bug 😃 The requested and received Headers from a single peer is still 511, not changed.
It's cool. How exactly is this working? Are we effectively streaming smaller chunks of headers into the processing pipeline from the adapter?
Thanks @antiochp And Yes, exactly.
BTW, I was planing to do a similar optimization for full sync, the basic idea is using two threads, one is ONLY for downloading, another one is ONLY for processing. and the processing worker thread will accumulate enough blocks to do one time (for better aggregation processing).
But I'm not sure what you will do in https://github.com/mimblewimble/grin/issues/1470, so I suspend the plan.
Can you point me at the code where we break this into batches of 8 headers? Looking at how/where to wire in the header mmr processing. This involves starting a relatively expensive txhashset (or similar) extension, and would benefit from a larger batch size so we could apply many headers at once.
@antiochp
Can you point me at the code where we break this into batches of 8 headers?
https://github.com/mimblewimble/grin/blob/master/p2p/src/protocol.rs#L187
OK - one more question... 😄
If we have 511 headers in a full Headers msg, this breaks out into multiple batches of 8 headers followed by a batch of 7 headers. But what we actually see is a batch of 6 followed by a batch of 1 header.
Why 8,8,8,6,1,8,8,8,6,1
and not 8,8,8,7,8,8,8,7
?
...
Sep 28 15:07:35.216 DEBG pipe: sync_block_headers: 8 headers from 02c3d340 at 94478
Sep 28 15:07:35.225 DEBG pipe: sync_block_headers: 8 headers from 06023fca at 94486
Sep 28 15:07:35.234 DEBG pipe: sync_block_headers: 8 headers from 027e667c at 94494
Sep 28 15:07:35.242 DEBG pipe: sync_block_headers: 6 headers from 0899e5ee at 94502
Sep 28 15:07:35.249 DEBG pipe: sync_block_headers: 1 headers from 09fdfe78 at 94508
Sep 28 15:07:35.337 DEBG pipe: sync_block_headers: 8 headers from 089d6a0c at 94509
Sep 28 15:07:35.348 DEBG pipe: sync_block_headers: 8 headers from 02e7b9bc at 94517
Sep 28 15:07:35.356 DEBG pipe: sync_block_headers: 8 headers from 02b859f3 at 94525
...
Sep 28 15:07:35.869 DEBG pipe: sync_block_headers: 8 headers from 03b6687e at 94989
Sep 28 15:07:35.878 DEBG pipe: sync_block_headers: 8 headers from 0a7be34d at 94997
Sep 28 15:07:35.887 DEBG pipe: sync_block_headers: 8 headers from 04d83a7c at 95005
Sep 28 15:07:35.896 DEBG pipe: sync_block_headers: 6 headers from 0943214d at 95013
Sep 28 15:07:35.903 DEBG pipe: sync_block_headers: 1 headers from 089763d9 at 95019
Sep 28 15:07:36.050 DEBG pipe: sync_block_headers: 8 headers from 044e85ee at 95020
Sep 28 15:07:36.061 DEBG pipe: sync_block_headers: 8 headers from 07b5af0e at 95028
Sep 28 15:07:36.069 DEBG pipe: sync_block_headers: 8 headers from 019497f6 at 95036
Sep 28 15:07:36.076 DEBG pipe: sync_block_headers: 8 headers from 0a704156 at 95044
...
You find one of my remaining issues! 😄 otherwise this splitting is perfect. It's a little bit complex. I know root cause of this, but so far no plan to fix this. Let me try to explain the root cause:
max_header_size
), for up to Cuckoo 36.https://github.com/mimblewimble/grin/blob/master/p2p/src/protocol.rs#L368-L372
let mut final_headers_num = (read_size + reserved.len() as u64) / max_header_size;
let remaining = msg_len - *total_read - read_size;
if final_headers_num == 0 && remaining == 0 {
final_headers_num = 1;
}
look at above 4 lines of code, that's why we always have 1 Header left for the final call.
Closing. Related #1627.
This is on a clean node with a reasonable number of healthy peers.
1) Why are we only receiving 8 headers at a time (and not ~500)? 2) Why are we only receiving them from a single peer?