-
Notifications
You must be signed in to change notification settings - Fork 1.7k
Expose config max-round-blocks-to-import #9439
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Overall LGTM, just some minor grumbles.
@@ -98,6 +98,7 @@ pub struct ImportBlockchain { | |||
pub with_color: bool, | |||
pub verifier_settings: VerifierSettings, | |||
pub light: bool, | |||
pub max_round_blocks_to_import: usize, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We probably don't need to add this field here and just use the default (12). Same below for Export*
structs.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
--max-round-blocks-to-import
is a valid args for ImportBlockchain
and Snapshot
commands anyway, so I think it would be better to include them there, just in case it caught people in surprise? For example, --max-round-blocks-to-import
do have (small) impact because the execution would call import_verified_blocks
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is a valid option indeed, I just assumed it wouldn't make much of a difference without networking. I'm OK with keeping it configurable.
@@ -62,6 +62,7 @@ pub struct SnapshotCommand { | |||
pub file_path: Option<String>, | |||
pub kind: Kind, | |||
pub block_at: BlockId, | |||
pub max_round_blocks_to_import: usize, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same as above, I think we only need to add this for the RunCmd
.
Did you experience any performance improvements/decreases defaulting from 4 to 12? |
@ngotchac No. Not sure how to benchmark this. |
Nothing really precise here, but just looking empirically how fast can you sync to block #N I guess? I think it won't change much though. |
Are you still working on this? |
…-max-round-blocks-to-import
@5chdn Fixed! Didn't realize there were merge conflicts! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm
@@ -785,6 +785,10 @@ usage! { | |||
"--stratum-secret=[STRING]", | |||
"Secret for authorizing Stratum server for peers.", | |||
|
|||
ARG arg_max_round_blocks_to_import: (usize) = 12usize, or |c: &Config| c.mining.as_ref()?.max_round_blocks_to_import.clone(), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Doesn't it fit more into Performance
section?
please rebase on master 🙈 |
…-max-round-blocks-to-import
Fixes #9320.
parity-ethereum imports blocks in rounds. If at the end of any round, the queue is not empty, we consider it to be "importing" and won't notify pubsub. On large re-orgs (10+ blocks), this is possible.
max_round_blocks_to_import
number from4
to12
.--max-round-blocks-to-import [S]
. With unstable network conditions, it is advised to increase the number. This shouldn't have any noticeable performance impact unless the number is set to really large.