enormous outgoing bandwidth with Satoshi client v0.9.1.0-g026a939-beta (64-bit)

[ttyson]

I've been running the Satoshi client for a while now and I wanted to ask about the bandwidth it consumes.  I'm maintaining a full block list and instantiating the client with the following parameters:

./bitcoin-qt -datadir=/mnt/Backup/Bitcoin -dns -externalip=xxx.xxx.xxx.xxx -txindex -splash -noupnp -dnsseed

In the debug screen I can see that I'm currently connected to 55 other nodes and over the last week I've sent out over 15GB/day of data.

http://s25.postimg.org/ty7gg0c5b/screenshot.png

Is this expected?  It seems like a lot.  Does anyone have any thoughts or comments?

Best,
Tony

[1713922010]

1713922010

[1713922010]

1713922010

[1713922010]

1713922010

[zvs]

Is this expected?  It seems like a lot.  Does anyone have any thoughts or comments?

Best,
Tony

That's nothing abnormal.  You just had some people that needed the blockchain connected to you..

When I ran my node with 700'ish connections, bitcoin used up about 2.5TB upstream a month (I was also appearing on the dns seed list though, so lots of new users)

if you've had your node up for a long time, then that could possibly be the cause, re: rotating into the seed list

ed:   see how high up you are on http://luke.dashjr.org/programs/bitcoin/files/charts/seeds.txt , i'm not sure of the exact criteria it uses on the dns seed list, but I'm pretty sure it rotates nodes in and out & maybe the top 10% or so?

[Meuh6879]

set the cache to 10MB (and not 100MB).

[zvs]

set the cache to 10MB (and not 100MB).

he's uploading to other ppl, how would changing the cache work?

if you need to decrease your upstream being used, use something like netlimiter or drop your # of connections

[trout]

ed:   see how high up you are on http://luke.dashjr.org/programs/bitcoin/files/charts/seeds.txt ,

I checked this, and among the top IPs there's a swiss guy who runs Satoshi client version 0.9.99 
Is he just having fun with the source code,  Or is 1.0 in the works and he's testing it?
(another option: he's from the future)

[zvs]

ed:   see how high up you are on http://luke.dashjr.org/programs/bitcoin/files/charts/seeds.txt ,

I checked this, and among the top IPs there's a swiss guy who runs Satoshi client version 0.9.99  
Is he just having fun with the source code,  Or is 1.0 in the works and he's testing it?
(another option: he's from the future)

0.9.99 is just the latest git build @ https://github.com/bitcoin/bitcoin ....  I guess you'd call it a 'beta' version, so it has the different version #

everything you see here after commit fa2b42533a367e756c6df25168f6cac63536dbc2 (i think... apr 9 + for sure) on April 8th is stuff that isn't in the "official" bitcoin client yet

https://github.com/bitcoin/bitcoin/commits/master

[gweedo]

Code:

X.X.X.X:8333                                  1   1398729146   99.83%  95.67%  93.38%  84.47%  58.60%  298204  00000001  70002 "/Satoshi:0.9.1/"

I made the list WOOWOOO

I currently serve a huge amount of the blockchain, and it is normal. The blockchain is ~17gb and many people are downloading the blockchain so it will be a lot.

[DeathAndTaxes]

To OP it isn't abnormal although the experience from node to node can vary significantly by luck.  When bootstrapping nodes don't use any sort of advanced peer negotiation and load balancing protocol (i.e. bittorrent) and thus will slam the first well connected peer that reliably supplies blocks.  If a large number of new nodes connect to you then you are going to have high upstream bandwidth usage (unless limited by some third party tool).  This isn't a criticism just an observation.  There are more important improvements needed but as bitcoin grows the bootstrapping and node load balancing portion of the protocol will also need to improve.  Looking at how bittorrent handles peer selection and load distribution is probably a good starting point.

[gmaxwell]

Looking at how bittorrent handles peer selection and load distribution is probably a good starting point.

Fairly poorly in the absence of a centralized tracker.

There is a complete implementation of a better fetch mechanism for bitcoin since last year: https://github.com/sipa/bitcoin/tree/headersfirst  It works quite well and avoids slamming just a single peer or being slow because a peer is slow. It couldn't make it into 0.9 due to a lack of testing as it's a rather big change. Instead its slowly being broken into staged commits. Hopefully, if this interests you, you'll be able to help with testing when more is needed.

[DeathAndTaxes]

Looking at how bittorrent handles peer selection and load distribution is probably a good starting point.

Fairly poorly in the absence of a centralized tracker.

There is a complete implementation of a better fetch mechanism for bitcoin since last year: https://github.com/sipa/bitcoin/tree/headersfirst  It works quite well and avoids slamming just a single peer or being slow because a peer is slow. It couldn't make it into 0.9 due to a lack of testing as it's a rather big change. Instead its slowly being broken into staged commits. Hopefully, if this interests you, you'll be able to help with testing when more is needed.

Thanks I will take a look.