@MaciejBaj Are you sure that adjusting those params is a proper way to fix our current issues? It works fine on 0.9.x.
@4miners the P2P protocol is not compatible with 0.9.x - there is a difference between how the headers are being propagated. It's worth to simulate what's the ratio of reached peers during broadcasts while adjusting maxRelays and broadcastLimit parameters.
@SargeKhan @MaciejBaj @4miners Here is the results of the combinations of different values in an emulated environment.

@MaciejBaj Max relays and broadcast are for blocks, have nothing to do with headers.
@nazarhussain Very nice graph, thanks for the effort to create it. So looks like with current settings (relay: 2, broadcast: 20) more than 1/3 of the network should never get a block? Can you create another graph using 0.9.x version to compare the behavior?
@MaciejBaj Max relays and broadcast are for blocks, have nothing to do with headers.
That's correct, never suggested it does. The tests prepared by @nazarhussain are based on the dedicated script that simulates the network behaviour, not on the real network.
The above graph was generated from am emulated environment which was completely synchronous. I converted it to asynchronous and broadcast in non-blocking mode. And here I get the result.

Based on this diagram we can see around 25% of the network missed the broadcast on 25 broadcast limit and 2 relay limit.
I suggest to change these values to either (40, 2) or (20, 3) for 250 node network.
And for 500 node network, value of (25, 3) or (75, 2) seems reasonable.
@4miners @MaciejBaj Values of MaxRelays and Broadcast Limit is also related to broadcasting transactions not just the blocks.
Closes #2078, #2076, #2073.
Most helpful comment
@SargeKhan @MaciejBaj @4miners Here is the results of the combinations of different values in an emulated environment.