Make channel prioritization based on number of messages in channel (vs number of bytes sent) #2954
Labels
enhancement
New feature or request
low-priority
needs-information
Waiting for additional information or feedback
p2p
Feature Request
Summary
Channel.RecentlySent
is used for choosing priority of a channel. Currently channel selection is done as channel with the minimumchannel.RecentlySent / channel.Priority
ratio. Every packet message increaseschannel.RecentlySent
by the proto-encoded packet size.channel.RecentlySent
gets lowered by 20% at everyUpdateStats
window (which is just a 2 second timer).BlockGossip is consensus time critical, and has very large packets. Its current priority weight is 10, vs vote's 7, hasVote's 1, and mempool's 5. Its packets are block parts which are large. This guarantees block gossip will always be the lowest prioritized packet out of all packets, since its recently sent will always be very large (in the 100kb's), which is problematic for fast block gossip. Any of the vote messages or mempool messages to a peer will outcompete block part gossip in the prioritization.
This matches behavior observed that we never hit our bandwidth flow rates in production and that block gossip just occurs slowly.
Instead channel.RecentlySent should first off be based on the number of packets on a channel, not the bandwidth size.
Problem Definition
This should greatly increase the prioritization of block gossip.
Proposal
channel.RecentlySent should first off be based on the number of packets on a channel, not the bandwidth size.
The text was updated successfully, but these errors were encountered: