Bitcoin Forum
December 08, 2016, 12:11:59 PM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 [2]  All
  Print  
Author Topic: Getting the chain faster - more than 8 outbound connections  (Read 4359 times)
dooglus
Legendary
*
Offline Offline

Activity: 2002



View Profile
March 28, 2012, 02:00:07 AM
 #21

Trying a 4th time with a bigger ram disk is getting speeds somewhere between rc4 and rc5 writing to disk.  So in this case it seems that the speed of the peers I'm connected to does make a big difference.  It could be the major contributing factor to the difference in slope of the lines in the above graph in fact - it just so happened that the first time I used a ram disk I connected to a very fast peer.

1481199119
Hero Member
*
Offline Offline

Posts: 1481199119

View Profile Personal Message (Offline)

Ignore
1481199119
Reply with quote  #2

1481199119
Report to moderator
1481199119
Hero Member
*
Offline Offline

Posts: 1481199119

View Profile Personal Message (Offline)

Ignore
1481199119
Reply with quote  #2

1481199119
Report to moderator
1481199119
Hero Member
*
Offline Offline

Posts: 1481199119

View Profile Personal Message (Offline)

Ignore
1481199119
Reply with quote  #2

1481199119
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1481199119
Hero Member
*
Offline Offline

Posts: 1481199119

View Profile Personal Message (Offline)

Ignore
1481199119
Reply with quote  #2

1481199119
Report to moderator
finway
Hero Member
*****
Offline Offline

Activity: 714


View Profile
March 28, 2012, 02:34:42 AM
 #22

As I've said before in another thread, the initial synchronisation process consists of three steps:
  • Downloading the data: limited by your and your peer's network speed
  • Maintaining the database: mostly limited by disk latency
  • Verifying the chain: limited by CPU speed

Before 0.6.0, maintaining the database almost always outweighed the other two. With 0.6.0rc5 the caching settings have been tweaked, resulting in a remarkable speedup for the database. This means that now the downloading time may indeed become significant, and it may be worth looking at improving the download process, for example downloading from several peers at once.

Increasing the number of outgoing connections will not help you get the chain faster: even when you use 0.6.0rc5, the chain is still downloaded from a single peer, and frequently still not the slowest step. In fact, increasing this number is a bad idea for the network, as peers with open incoming ports are not too abundant.

Yes, the networking now is the bottleneck! 

ohforf
Full Member
***
Offline Offline

Activity: 126


All your Bitcoin are belong to us


View Profile
March 28, 2012, 06:04:36 AM
 #23

I wonder if its possible to distribute a Blockchain File thats almost up to date, using Bittorrent Technology ?
This would help new Users to get up and running as fast as technically possible.
Of course, the BT client should be part of the Bticoin Client to make it easy to use.

The fool who knows his foolishness, is wise at least so far.
But a fool who thinks himself wise, he is called a fool indeed.
Revalin
Hero Member
*****
Offline Offline

Activity: 728


165YUuQUWhBz3d27iXKxRiazQnjEtJNG9g


View Profile
March 28, 2012, 06:13:47 AM
 #24

Yes, though your node still needs to either a) verify all the transactions or b) trust the md5sum of the downloaded data.  Doing A is still going to take a while; B violates the ideal of decentralization.

The existing protocol can easily stream data fast enough for A.  If the current bottleneck is the network, the client just needs to download blocks with simultaneous streams from multiple peers.

      War is God's way of teaching Americans geography.  --Ambrose Bierce
Bitcoin is the Devil's way of teaching geeks economics.  --Revalin 165YUuQUWhBz3d27iXKxRiazQnjEtJNG9g
dooglus
Legendary
*
Offline Offline

Activity: 2002



View Profile
March 28, 2012, 07:31:22 AM
 #25

Yes, the networking now is the bottleneck! 

I ran the test again, only this time I set the client to connect to a machine on the LAN which has the whole blockchain already.  I got the same shaped graph again, but faster again.  The bandwidth used was around 500 to 700kB/s constantly, which is about a 20th of what's available.  The CPU wasn't maxed out on either machine, and neither was the disk access.  So I've no idea what the bottleneck is now.

Once it got to block 168000 the CPU on the local computer started getting maxed out, and the download slowed considerably, because at that point it runs out of known checkpoints, and starts actually validating the signatures in every new transaction.

I also found that while downloading the blockchain, my client never flushes its database logs, and so using a ram disk as the data directory doesn't work unless the ram disk is huge.  When the qt client runs out of disk space, it sometimes crashes, and always shuts down.  I made an emergency bug report here https://github.com/bitcoin/bitcoin/issues/999

Instead of plotting blocks against time, I tried plotting blk00001.dat size against time, and got pretty much a straight line.  It's slow to get started (lots of tiny blocks) and slows down a lot once we hit block 168000 at around 32 minutes, where we run out of checkpoints and have to start checking signatures:


finway
Hero Member
*****
Offline Offline

Activity: 714


View Profile
March 28, 2012, 08:16:24 AM
 #26

Yes, the networking now is the bottleneck! 

I ran the test again, only this time I set the client to connect to a machine on the LAN which has the whole blockchain already.  I got the same shaped graph again, but faster again.  The bandwidth used was around 500 to 700kB/s constantly, which is about a 20th of what's available.  The CPU wasn't maxed out on either machine, and neither was the disk access.  So I've no idea what the bottleneck is now.

Once it got to block 168000 the CPU on the local computer started getting maxed out, and the download slowed considerably, because at that point it runs out of known checkpoints, and starts actually validating the signatures in every new transaction.

I also found that while downloading the blockchain, my client never flushes its database logs, and so using a ram disk as the data directory doesn't work unless the ram disk is huge.  When the qt client runs out of disk space, it sometimes crashes, and always shuts down.  I made an emergency bug report here https://github.com/bitcoin/bitcoin/issues/999

Instead of plotting blocks against time, I tried plotting blk00001.dat size against time, and got pretty much a straight line.  It's slow to get started (lots of tiny blocks) and slows down a lot once we hit block 168000 at around 32 minutes, where we run out of checkpoints and have to start checking signatures:



Seems there are still a lot space of improvement.

dooglus
Legendary
*
Offline Offline

Activity: 2002



View Profile
March 28, 2012, 08:40:28 AM
 #27

Seems there are still a lot space of improvement.

Yes, but where?  If no network, CPU, or hard drive is the bottleneck, what is?

Diapolo
Hero Member
*****
Offline Offline

Activity: 769



View Profile WWW
March 28, 2012, 10:47:11 AM
 #28

Seems there are still a lot space of improvement.

Yes, but where?  If no network, CPU, or hard drive is the bottleneck, what is?

Perhaps Parallelisation in the DB commits and for the Block downloads, cache tuning ... I thought of a DB "defrag" or reorganisation. Perhaps the whole space for the full block download can be reserverd at the start of a chain sync, so that it's alligned on the drive. Only thoughts, without any knowledge of the DB internals ...

Dia

Liked my former work for Bitcoin Core? Drop me a donation via:
1PwnvixzVAKnAqp8LCV8iuv7ohzX2pbn5x
bitcoin:1PwnvixzVAKnAqp8LCV8iuv7ohzX2pbn5x?label=Diapolo
dooglus
Legendary
*
Offline Offline

Activity: 2002



View Profile
March 28, 2012, 03:36:34 PM
 #29

I think maybe it's an issue of network latency.  I send a request for a block, it takes a while to reach the server, the server sends the block, it takes a while to reach me.  Everything's spending lots of short amounts of time waiting for things to go through the network.

I say this because I see about half the download speed when connecting to the LAN wirelessly than I do when using an ethernet cable, even though in neither case is the network connection anywhere near saturated.  Maybe it's a question of ping time.

JoelKatz
Legendary
*
Offline Offline

Activity: 1386


Democracy is vulnerable to a 51% attack.


View Profile WWW
March 28, 2012, 07:24:05 PM
 #30

I think maybe it's an issue of network latency.  I send a request for a block, it takes a while to reach the server, the server sends the block, it takes a while to reach me.  Everything's spending lots of short amounts of time waiting for things to go through the network.

I say this because I see about half the download speed when connecting to the LAN wirelessly than I do when using an ethernet cable, even though in neither case is the network connection anywhere near saturated.  Maybe it's a question of ping time.
I think you're probably right. I wonder if it would help for the client to request a few blocks at a time. Is its current logic really just to request a single block and then not even request the next block until it has committed the previous?

I am an employee of Ripple.
1Joe1Katzci1rFcsr9HH7SLuHVnDy2aihZ BM-NBM3FRExVJSJJamV9ccgyWvQfratUHgN
Pieter Wuille
Legendary
*
qt
Offline Offline

Activity: 1036


View Profile WWW
March 28, 2012, 07:53:30 PM
 #31

I think maybe it's an issue of network latency.  I send a request for a block, it takes a while to reach the server, the server sends the block, it takes a while to reach me.  Everything's spending lots of short amounts of time waiting for things to go through the network.

I say this because I see about half the download speed when connecting to the LAN wirelessly than I do when using an ethernet cable, even though in neither case is the network connection anywhere near saturated.  Maybe it's a question of ping time.
I think you're probably right. I wonder if it would help for the client to request a few blocks at a time. Is its current logic really just to request a single block and then not even request the next block until it has committed the previous?

It requests blocks in bulk with a getblock. The result is a large inv announcement of up to a few hundred blocks (corresponding to at most 5 MB at a time). The client responds with a getdata for all unknown blocks, which are sent one by one using block.

The data is really requested in groups of several blocks at a time, but only downloaded and processed one by one. There are several improvements possible here still, though.

aka sipa, core dev team

Tips and donations: 1KwDYMJMS4xq3ZEWYfdBRwYG2fHwhZsipa
dooglus
Legendary
*
Offline Offline

Activity: 2002



View Profile
March 28, 2012, 10:45:03 PM
 #32

I see it sending 500 requests for blocks at a time, and then receiving 500 blocks back, very quickly:

Code:
askfor block 00000000839a8e6886ab   0
[498 lines deleted]
askfor block 000000004ff664bfa7d2   0
sending getdata: block 00000000839a8e6886ab
[498 lines deleted]
sending getdata: block 000000004ff664bfa7d2
received block 00000000839a8e6886ab
SetBestChain: new best=00000000839a8e6886ab  height=1  work=8590065666
ProcessBlock: ACCEPTED
[1494 lines deleted]
received block 000000004ff664bfa7d2
SetBestChain: new best=000000004ff664bfa7d2  height=500  work=2151811449333
ProcessBlock: ACCEPTED

flatfly
Hero Member
*****
Offline Offline

Activity: 938


View Profile
March 30, 2012, 12:39:46 PM
 #33


Is there any selfish thin clients out yet? Something I could easily put on new computers?

For Windows XP & 7, I would strongly suggest to try my portable Electrum builds (latest release, 0.42). Smiley
See here: https://bitcointalk.org/index.php?topic=73651.0
 

1111127SpvabYpoeDoiz5L7QPkfiSh2Q. Only donate if you have a reason to.
phr33
Full Member
***
Offline Offline

Activity: 207


View Profile
March 31, 2012, 09:59:43 AM
 #34

I tried again, this time having ~/.bitcoin/ be a ram disk.

Code:
$ mv .bitcoin .bitcoin.real
$ mkdir .bitcoin
$ sudo mount -t tmpfs -o size=1600M tmpfs .bitcoin

I thought 1600 megabytes would be big enough, but forgot to take the database logfiles into account, and it ran out of space after about downloading 136k blocks in 26 minutes.  The shape of the curve is still the same.  The CPU very rarely was flat out during the download, and so I'm thinking the limit now is how quickly the blocks are coming over the network.  The blocks get bigger with time, so take longer to transmit.



Nice graphs. Thanks!

Just out of curiosity, you don't happen to have data for a pre-v0.6.0 client to add ?

My BTC input: 1GAtPwoTGPQ35y9QugJueum5GzaEzLYjiQ
My GPG ID: B0CCFD4A
deepceleron
Legendary
*
Offline Offline

Activity: 1470



View Profile WWW
March 31, 2012, 05:58:52 PM
 #35

I tried again, this time having ~/.bitcoin/ be a ram disk.

Code:
$ mv .bitcoin .bitcoin.real
$ mkdir .bitcoin
$ sudo mount -t tmpfs -o size=1600M tmpfs .bitcoin

I thought 1600 megabytes would be big enough, but forgot to take the database logfiles into account, and it ran out of space after about downloading 136k blocks in 26 minutes.  The shape of the curve is still the same.  The CPU very rarely was flat out during the download, and so I'm thinking the limit now is how quickly the blocks are coming over the network.  The blocks get bigger with time, so take longer to transmit.
If you want to try something for giggles, set up another Bitcoin "server" machine on your local 1gig+ Ethernet network using PCIe network cards (or verifying the onboard MAC is PCIe), with the blockchain on a RAM disk on that machine too. Then instead of hitting the Internet to connect to a mystery peer, you can use the connect=192.168.0.xxx:8333 option in your bitcoin.conf to connect to only that machine (this is the best way to run multiple Bitcoins behind NAT, BTW.) Have that server be the faster machine, so you know the disk/cpu/ram latency limitations are on the machine downloading the blockchain.

You will probably be able to copy the blockchain files between the machines' ramdisks in about 20 seconds.

You will find that with the network limitation clearly removed, it still takes a few orders of magnitude longer than the network speed.

If the Bitcoin client cached the whole block index in memory, this might save a few disk read operations per blockchain transaction.

Pages: « 1 [2]  All
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!