[Merged by Bors] - Increase default target-peer count to 80

[AgeManning]

Increase the default peer count from 50 to 80

[AgeManning]

Potentially lets hold off on this. It may be more efficient to increase the default peer count that this PR.

Further analysis will steer the course of action here.

[AgeManning]

I have been spending a bit of time trying to quantify the bandwidth use and performance based on some of our default parameters.

This is quite difficult to do, because there is a lot of random fluctuation in bandwidth between each beacon node restart. To get good statistical results, we need to adjust the parameters and let them run over a few days for a number of nodes to get a single reliable data point.

The fluctuation comes because each restart gives a random selection of nodes and a random number of gossipsub mesh peers that lie within the min/max counts for each topic. Its only after a long period of time, once our pruning system has a chance to steadly select out all the peers we want that we can properly measure the effect of these parameters. The effect will also differ (I expect the variance of the change to grow) based on validator count. Nodes that are subscribed to all subnets should have a greater benefit to fine-tuned parameters than nodes without validators at all. All this is to say, is that choosing parameters requires a lot of data points which will take a lot of time.

We can make educated guesses however, with fewer samples based on what theoretically we expect to occur.

The parameters we want to tune are:

• Target peer count
• Network Load

In theory, the bandwidth should be directly proportional to the number of mesh peers in gossipsub. Gossipsub is by far the most network heavy protocol and data we send/recv is mostly due to mesh peers. The mesh peer count is solely governed by network-load and not the peer count. So in theory we can increase our target peer count, with minimal increase in bandwidth. There will be an increase in the overhead of IWANT/IHAVE and flood publishing of messages to a larger peer set along with some extra RPC overhead such as STATUS and an increase in probability of getting out-of-sync peers which we have to send blocks to.

The benefit of a higher peer count however is that we have a greater selection of peers to collect and store and spread across all our subnets. Collecting peers across all subnets prevents us from having to perform any discovery requests and gives us a greater chance of not missing any attestations due to lack of peers on a subnet. It also allows us to find more useful peers faster because our target overhead of peer count (10%) is larger.

With all this aside I've done some simple tests with a single node (for consistency). This node is subscribed to all subnets. I found no statistical difference (there was a large variance in the bandwidth) between a peer count of 50 and 80. I saw a 20% increase in bandwidth between a network load of 3 to 4 and a 10% decrease from 3 to 2. I noticed no significant difference in block delay times.

These seem consistent with the theory. So given all of the above, and the countless hours I've spent looking at Lighthouse network metrics, I'd propose the following:

• Leave network-load as is, untouched
• Change our default peer count to 80 <- I think we'll gain a lot with minimal downside.

Of course if someone wants to do some more rigourous analysis, i'm all for it. What we think: @divagant-martian @pawanjay176 @michaelsproul @paulhauner ?

[divagant-martian]

Metrics seem fine, the only difference I see is the memory usage, by around +500M. But it looks stable

[michaelsproul]

Can we change the title and description of this PR to accurately reflect what it does? i.e. increase default peer count to 80

[michaelsproul]

I edited the PR description too (as it becomes the commit message)

[AgeManning]

bors r+

[bors]

Pull request successfully merged into unstable.

Build succeeded:

• arbitrary-check
• cargo-audit
• cargo-fmt
• cargo-udeps
• check-benchmarks
• check-consensus
• clippy
• debug-tests-ubuntu
• dockerfile-ubuntu
• ef-tests-ubuntu
• eth1-simulator-ubuntu
• no-eth1-simulator-ubuntu
• release-tests-ubuntu
• release-tests-windows
• state-transition-vectors-ubuntu