Starting monerod with block-sync-size >~ 100 prevents daemon to sync

[kuchta]

Starting monerod with larger block-sync-size than ~100 (tested 200, 500, 1000, 10000) prevents unsynced daemon from synchronizing by going into some strange loop that only prints over and over again:

SYNCHRONIZATION started
91.218.20.4:18080 OUT Sync data returned a new top block candidate: 2552513 -> 3384786 [Your node is 832273 blocks (3.2 years) behind] 
SYNCHRONIZATION started
52.143.116.21:18080 OUT Sync data returned a new top block candidate: 2552513 -> 3384786 [Your node is 832273 blocks (3.2 years) behind] 
SYNCHRONIZATION started
4.227.140.143:18080 OUT Sync data returned a new top block candidate: 2552513 -> 3384786 [Your node is 832273 blocks (3.2 years) behind] 
SYNCHRONIZATION started

.bitmonero/bitmonero.conf:

prune-blockchain=1
sync-pruned-blocks=1
db-sync-mode=fast:async
block-sync-size=100
enable-dns-blocklist=1
bootstrap-daemon-address=auto

[nahuhh]

its a bug that requires either a network upgrade to change, or relaying info to peers about whether they can send > 100.

The max is supposed to be 2048

[kuchta]

Thank you for clarification, @nahuhh. After some time synchronizing with block-sync-size=100 it also went into that loop so I had to restart the process with default (0 == adaptive) which at the moment fetchces just 20 blocks at the time. Is there something else one can to do to speed up the sync?

[nahuhh]

There are serialization limits that effectively add size restrictions to the batches being pulled in. 100 will hit those limits at some point after ringct. Once blocks grow in the future, 20 will also fail.

pr #9494 introduces a dynamic block sync size that will auto-adjust, and #8867 fixes the serialization limits

edit: also re default (0 == adaptive). 0 = 100 pre-V4 and 20 post-V4 (fixed valued based on block heights). Its not truly adaptive until 9494 is approved

[noelportillo]

very good