Suggestion: Increase MAX_OUTBOUND_CONNECTIONS for initial syncing if node accepts incoming connections. #9800

I am setting up a node and I notice that the initial sync is slow and I am not fully using my CPU nor my bandwidth. (CPU load averages in 50% and Bandwidth averages 40Mbps out of 300Mbps available).

I believe that when a node is doing the first blockchain syncing it needs more outbound connections, for example, 16.

To avoid using too many peers and too many resources I propose only increasing MAX_OUTBOUND_CONNECTIONS to 16 temporarily when the node is doing its initial syncing and only if port 8333 is open and accepting connections (to encourage nodes to be reachable).

This would not harm the network as it would only be during the initial syncing and It would speed up it while encouraging owners to accept incoming connections.

"I am not fully using my CPU nor my bandwidth" often this is an indication that you're disk is saturated. In cases where people really are on sufficient hardware (which pretty much means high -dbcache and memory usage, not fast disks), we might consider having smarter logic to limit the timeout necessary to kick peers, though probably only during IBD.

On February 19, 2017 10:51:15 AM EST, i-rme notifications@github.com wrote:

I am setting up a node and I notice that the initial sync is slow and I am not fully using my CPU nor my bandwidth. (CPU load averages in 50% and Bandwidth averages 40Mbps out of 300Mbps available).

I believe that when a node is doing the first blockchain syncing it needs more outbound connections, for example, 16.

To avoid using too many peers and too many resources I propose only increasing MAX_OUTBOUND_CONNECTIONS to 16 temporarily when the node is doing its initial syncing and only if port 8333 is open and accepting connections (to encourage nodes to be reachable).

This would not harm the network as it would only be during the initial syncing and It would speed up it while encouraging owners to accept incoming connections.

-- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/bitcoin/bitcoin/issues/9800

@TheBlueMatt thanks for your response. Im running it on a desktop pc, the hard drive supports up to 40MB/s (320Mbps) so that is not the issue here. I want to clarify that I am not complaining about slow IBD, just pointing out that might be some setting that limits my IBD speed.

The ideal would be that my hardware or my connection bottletrottle the process. That would assure the best speed possible.

@i-rme I assume you are running 0.13.2, in which case you can expect some speedups by switching to 0.14.0 (planned to be released in about two weeks).

See #9787 for a summary of the speedups as well as #8610 (comment)

On Sun, Feb 19, 2017 at 5:06 PM, i-rme notifications@github.com wrote:

@TheBlueMatt thanks for your response. Im running it on a desktop pc, the hard drive supports up to 40MB/s (320Mbps) so that is not the issue here. I want to clarify that I am not complaining about slow IBD, just pointing out that might be some setting that limits my IBD speed.

The ideal would be that my hardware or my connection bottletrottle the process. That would assure the best speed possible.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

@MarcoFalke I am already running 0.14 rc1, and I want to thank all developers for improving Bitcoin Core and in particular by assume-valid block feature.

I believe that the problem is that just 8 peers cant max out my hardware or my bandwidth.

Then it should change peers until they can, it does this now, but it's a known area for improvement. More peers really isn't the solution here. There are many nodes on the network that can serve blocks out faster than any existing hardware can index them. :)

"Im running it on a desktop pc, the hard drive supports up to 40MB/s (320Mbps) so that is not the issue here" if you're running on a desktop hard drive then that is almost definitely your bottleneck after the first 150-200k blocks. It isn't a question of your drive's sequential throughout (the number you quoted), but a question of seek latency, which is usually rather high.

On February 19, 2017 11:05:55 AM EST, i-rme notifications@github.com wrote:

@TheBlueMatt thanks for your response. Im running it on a desktop pc, the hard drive supports up to 40MB/s (320Mbps) so that is not the issue here. I want to clarify that I am not complaining about slow IBD, just pointing out that might be some setting that limits my IBD speed.

The ideal would be that my hardware or my connection bottletrottle the process. That would assure the best speed possible.

-- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: https://github.com/bitcoin/bitcoin/issues/9800#issuecomment-280928571

Closing this, as said: the solution is not to add more outgoing peers but choose better peers.