search

danielmcclure / bitcoinj

Automatically exported from code.google.com/p/bitcoinj
Apache License 2.0
0 stars 1 forks source link

Sync is randomly slow #601

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
This appears to be a problem with the Bitcoin P2P network. Aaron Voisine has 
also seen this with BreadWallet on iOS so it doesn't seem to be a bitcoinj 
issue. The symptom is that sometimes it'll take forever the sync with the block 
chain, unlike normal when it can sync in a few seconds flat (usually 1-2 
seconds per day of history).

Likely culprits:

* Larger blocks mean more Bloom FPs. But we have adaptive FP rate selection in 
bitcoinj and sometimes sync is fast, so this probably isn't it.
* A sudden influx of slow nodes. Possible but no obvious reason why that'd be 
the case.
* More traffic/usage of Bitcoin == more load on nodes. I suspect that a node 
gets super slow if there are two SPV clients syncing from it simultaneously. 
We're breaking traffic records every week at the moment as Bitcoin is in the 
middle of its organic winter growth season. So it stands to reason that the 
network is getting bogged down due to more clients trying to filter the chain.

What might help is if we notice and avoid slow nodes. This needs care though to 
avoid the case where a node is serving a single client fast, another jumps on, 
and then both simultaneously decide to split and clients just end up bouncing 
around the network. We need some hysteresis so if a node starts out being slow 
it's abandoned faster than if it's fast, then slow.

We should probably write a simple client based on WalletTemplate that can 
gather statistics about chain sync speed, and do some experiments with our own 
node to see if load imbalances are the issue.

Original issue reported on code.google.com by mh.in.en...@gmail.com on 19 Jan 2015 at 5:49

GoogleCodeExporter commented 9 years ago 
I keep an eye on the network traffic on my machine and have noticed that 
sometimes when syncing you get a 50% on / 50% off network pattern. This is 
consistent with the core node you are talking to multitasking your request with 
some other one from some other SPV client. You get 500 blocks or so. Then a 
wait. Then another 500 and so on.

I have seen it once or twice in the last month out of probably hundreds of 
connections.

Original comment by jimburto...@gmail.com on 19 Jan 2015 at 6:08