-
Notifications
You must be signed in to change notification settings - Fork 2.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
modify Reactor priorities #5826
Conversation
blockchain/vX reactor priority was decreased because during a normal operation (i.e. when the node is not fast syncing) blockchain priority can't be the same as consensus reactor. Otherwise, it's theoretically possible to slow down consensus by constantly requesting blocks from the node. NOTE: ideally blockchain/vX reactor priority would be dynamic. e.g. when the node is fast syncing, the priority is 10 (max), but when it's done fast syncing - the priority gets decreased to 5 (only to serve blocks for other nodes). But it's not possible now, therefore I decided to focus on normal operation (priority = 5). evidence and consensus critical messages are more important than mempool, hence they are increased by 1 (from 5 to 6). statesync reactor priority was changed from 1 to 5 to be the same as blockchain/vX priority.
Codecov Report
@@ Coverage Diff @@
## master #5826 +/- ##
==========================================
+ Coverage 60.03% 60.04% +0.01%
==========================================
Files 263 263
Lines 23834 23834
==========================================
+ Hits 14309 14312 +3
+ Misses 8018 8009 -9
- Partials 1507 1513 +6
|
statesync/reactor.go
Outdated
@@ -34,7 +34,7 @@ var ( | |||
MsgType: new(ssproto.Message), | |||
Descriptor: &p2p.ChannelDescriptor{ | |||
ID: byte(SnapshotChannel), | |||
Priority: 3, | |||
Priority: 2, |
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.
@erikgrinaker do I understand correctly that sending snapshots are 1/3rd less important than sending chunks? or it should be vice versa? maybe we should just assign 5
to both channels?
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.
Higher priority is better, right? So snapshot metadata is 3 times more important than chunks. This is because chunks are large and restoration is time-consuming, while snapshot metadata is tiny and requested in real-time, so it should have priority.
We probably want chunks to have low priority in general, for the same reason. It shouldn't have priority above e.g. consensus.
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.
Higher priority is better, right?
right
consensus/reactor.go
Outdated
@@ -156,7 +156,7 @@ func (conR *Reactor) GetChannels() []*p2p.ChannelDescriptor { | |||
}, | |||
{ | |||
ID: VoteChannel, | |||
Priority: 5, | |||
Priority: 6, |
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.
Could maybe consider even 7 here. Priorities are sort of weighted during packet sending, so that if one channel has 6 and another har 5 then the 6 channel gets 6/11 packets sent while the other gets 5/11 (if I'm reading this right).
This needs a backport onto 0.34.x and then I will cut a new RC! |
blockchain/vX reactor priority was decreased because during the normal operation (i.e. when the node is not fast syncing) blockchain priority can't be the same as consensus reactor priority. Otherwise, it's theoretically possible to slow down consensus by constantly requesting blocks from the node. NOTE: ideally blockchain/vX reactor priority would be dynamic. e.g. when the node is fast syncing, the priority is 10 (max), but when it's done fast syncing - the priority gets decreased to 5 (only to serve blocks for other nodes). But it's not possible now, therefore I decided to focus on the normal operation (priority = 5). evidence and consensus critical messages are more important than the mempool ones, hence priorities are bumped by 1 (from 5 to 6). statesync reactor priority was changed from 1 to 5 to be the same as blockchain/vX priority. Refs #5816
blockchain/vX reactor priority was decreased because during the normal operation (i.e. when the node is not fast syncing) blockchain priority can't be the same as consensus reactor priority. Otherwise, it's theoretically possible to slow down consensus by constantly requesting blocks from the node. NOTE: ideally blockchain/vX reactor priority would be dynamic. e.g. when the node is fast syncing, the priority is 10 (max), but when it's done fast syncing - the priority gets decreased to 5 (only to serve blocks for other nodes). But it's not possible now, therefore I decided to focus on the normal operation (priority = 5). evidence and consensus critical messages are more important than the mempool ones, hence priorities are bumped by 1 (from 5 to 6). statesync reactor priority was changed from 1 to 5 to be the same as blockchain/vX priority. Refs #5816
blockchain/vX reactor priority was decreased because during the normal operation
(i.e. when the node is not fast syncing) blockchain priority can't be
the same as consensus reactor priority. Otherwise, it's theoretically possible to
slow down consensus by constantly requesting blocks from the node.
NOTE: ideally blockchain/vX reactor priority would be dynamic. e.g. when
the node is fast syncing, the priority is 10 (max), but when it's done
fast syncing - the priority gets decreased to 5 (only to serve blocks
for other nodes). But it's not possible now, therefore I decided to
focus on the normal operation (priority = 5).
evidence and consensus critical messages are more important than
the mempool ones, hence priorities are bumped by 1 (from 5 to 6).
statesync reactor priority was changed from 1 to 5 to be the same as
blockchain/vX priority.
Refs #5816