Topic: Blockchain Erratic Sync Speed - Why? (Read 1440 times)

From my experience you also have to delete peers.dat for a successful "kick".

Glad that helped.

I believe it can be programmatically disabled.  I will look into that.

Edit:
I went to look at the code and it appears someone added some os x specific code in the plist to disable app nap a few days ago. So perhaps this will resolve it in a future update.

Most likely it's a slow peer.  If this happens it may last for hours if the connection to the slow peer stays up.  You can "kick it" to get it going faster by shutting down Bitcoin-Qt and restarting it.  This has usually worked for me if I have been off-line for a few days and am trying to catch up.

If you are downloading from scratch you might try the bootstrap.dat torrent, particularly if you already have experience with torrents and have a bittorrent client installed on your computer.  See https://bitcointalk.org/index.php?topic=145386.0

Disabling AppNap seems to have solved the problem.  Thanks for the tip.

With AppNap throttling enabled, bootstrapping would have taken weeks.

I am guessing there is a way for software to tell the OS not to throttle it with AppNap.  I could see not including such an 'extra' in Bitcoin Core for security and stability reasons.  Making it clear to the user that AppNap can severely limit the bootstrapping process I think would be a good idea.  not sure where the warning should go.

App nap was not disabled.  But now it is.  Thanks.  I was plugged in the whole time, it would be slightly strange for process to be throttled in such circumstances, but I suppose there is the issue of heat buildup, and maintaining UI responsiveness in the foreground.  I'll see if it makes a difference.


I guessed that as well.  That is why I isolated my systems form the internet, and made them connect to each other.  Both have fast SSDs.  The bottle neck really should have been the CPU in the bootstrapping machine.

I'm guessing slow peer (bitcoin only syncs with one peer at a time, and doesn't always chooses the fastest) or busy HDD

Do you have "app nap" turned off? (In Finder, do a "get info" and then make sure you have prevent app nap checked).

I controlled some variables and the problem still persisted.

I set still client that is still bootstrapping to connect=192.168.1.100, that being the static local address of another computer running a full node.  It certainly pulled in the blocks fast, at about 1 MB/s.  That only for three minutes or so before the sync ground to a halt.  I restarted the program, and sure enough, another solid run of data transfer, maybe for six or seven minutes, then it stopped.

Here is a graph of my CPU.  It shows about 30 minutes of history.  Bitcoin was the only thing running.  I quit the program twice and restarted twice over the course of the graph.  It let the computer idle for a minute in between.  Starting from the left, about 20% into the graph, there is a short lull, followed by the biggest chunk of CPU thus far.  That was when I restarted the client.  Then there is a break in CPU effort, after the client has started, but before it was crunching blocks.  Then there is a period of block processing, before it reverts to a very low intensity state, with not much syncing.

After ~8 minutes of mostly idling, I restated again (the middle point of the graph).  The same pattern repeats, though this time it processed blocks for ~7 minutes or so.




I even unplugged the WAN cable.  Each client showed one connection, one outbound, one inbound.  They were just talking to each other.  Again, the syncing went fast for a few minutes, then mostly stopped.

I have seen basically the same behavior just running the client stock, connecting to larger bitcoin network, and running it modified, to only connect to local hosts.

Recently I synchronized a new node from scratch and observed a similar behaviour. The debug.log was filled with entries "UpdateTip" then suddenly it stopped and some time later it started again. My theory (out of thin air) is that it stops when the connection to the node serving blocks to us is interrupted. I don't know what condition makes the daemon restart the process again.

The blockchain synchronizes quickly when Bitcoin Core is first started, but after some time, maybe an hour or so, it slows to a crawl.  I can’t find the bottle neck.

This behavior is occurring under good testing conditions.


Computer: MacBook Pro 3.1, 2.4 Ghz Core 2 Duo, 4 GB RAM, 250GB SSD

OS: Mavericks 10.9.5 - Clean Install.  Bitcoin Core 9.3 is the only non-packaged software.

Internet: 25 / 5 mbps cable (comcast).

All settings are essentially stock.  I turned on the software firewall, then turned it back off.  Filevault 2 has been activated.

Description:  I did a clean install of the OS last night on a brand new hard drive.  I encrypted the drive and immediately proceeded to download Bitcoin Core 9.3 to test it out, and to test out the current blockchain total download time.

The client has been running for about 7 hours now, and currently has 16 inbound and 8 outbound connections, but it seems like nothing is happening. The block count in the debug window hasn’t budged in 5 minutes

CPU is 80% idle.  RAM is only about 50% full.  Network - 20 KB /s.

Then, as I am writing this, the data rate flowing into the computer surges to ~1.0 MB/s, the CPU starts processing, and the block count is flying upwards.  It is currently requesting blocks from September, 2011 era.

Now, just a couple of minutes and 1,000 blocks later, the computer is receiving only ~50 KB/s, the CPU is idle again, and the block count is not increasing, not even slowly.  It is stuck at block 143,882.

Next I quit and restart Bitcoin Core.  Almost instantly blocks start processing again, and downloading at 500 - 1,000 KB/s.  Within a minute or two, it has 1 inbound connection and 8 outbound.

I have observed the same thing happening on other Macs running 10.9.5.

Does anyone have a good explanation for this behavior?  It almost seems like my client just happens to be connected to 8 peers, none of which are willing to share any blockchain data.  If that is the case, I am surprised it wouldn’t do a more active search for sources of fast blocks.