Speed limit / throttle network usage

[slothbag]

I noticed the other day Bitcoin was maxing out my upload bandwidth on ADSL. Probably due to sending the block chain to fellow bitcoin users ( I had about 65 connections at the time )..

The ability to limit / throttle the network usage like most other p2p programs would be beneficial. Otherwise I have to ensure I close the Bitcoin application to keep it from killing my upload.

[m4rcelofs]

+1 to that!

Bitcoin is currently using all my upload speed, which actually means sometimes I can't even browse! Closing BitCoin solves the issue, but it's not really beneficial to the network...

[NvrBst]

+1 as well.

I have a 60KB/s upload limit on my ADSL, and bitcoin.exe is killing my upload so bad at times that I cannot even browse internet very well. Some extra information:

I usually have ~32 connections in bitcoin. Receive seems to be fine. After 10 mins the current bitcoin.exe connections have downloaded about 100kB each, but, download is usually not as limited as upload.

After about 10 mins the current bitcoin.exe connections use about 100kB upload each, but, there are ~3 which uses ~1MB+. This comes to over 10kB/s average (not much average wise). But I suspect when those 1MB+ guys are going it uses 100% of the upload and just drops down to 7.5kB/s average after that part is done.

Preferably I'd like to limit upload to 2kB/s to 5kB/s on my current connection.

EDIT: I'm using bitcoin 0.3.24-beta

[Trupik]

I have hosted public bitcoin node 24/7 for over a year now on my home linux server. It is causing me a considerable packet loss on the line and it is getting worse over time, as the chain grows. Please, add bandwidth limiting to the bitcoind. Otherwise I will have to shut down the node, because my internet connection is getting unusable.

[luke-jr]

QoS is really a router job, but I guess reliable routers aren't too common :/

[neofutur]

one more +1, also needing this, or a way to have bitcoind use a shared blockchain ( see http://bitcoin.stackexchange.com/questions/3199/read-only-blockchain-in-bitcoind-patch-ideas and https://bitcointalk.org/index.php?topic=71542 ) , even better than just throttle imho

also,waiting foran option in bitcoind, you could have a look at 3 userspace bandwidth limiting tools : http://monkey.org/~marius/pages/?page=trickle , http://klicman.org/throttle/ and http://stromberg.dnsalias.org/~strombrg/slowdown/

[laanwj]

No +1s here please. I think we all agree it is a good idea for a P2P program to have configurable limits.

It's not realistic to require people to move this to a router. Especially on a VPS you don't really have much control over routing.

However, this feature has currently no priority for the core developers. If you want to speed up this issue, help with the implementation.

Edit: and I suggest trying out thin clients such as Electrum, which claim to use much less bandwidth and 'share' a block chain on a supernode.

[Diapolo]

Perhaps unrelated, but you guys could (for Windows) try out cFosSpeed if your connection get's laggy because of uploads.

[rebroad]

For MS Windows, I can suggest NetLimiter as a nice piece of software, albeit commercial. I'd have thought linux has various QoS options available, doesn't it?

[nadrimajstor]

When you use P2P application (e.g. torrent client) you are always presented with some form of information and/or customizing options regarding the nature of P2P communication and its bandwidth consumption.
With BitCoin client this is not so obvious and lead me to false belief that BitCoin is not heavy on network traffic.
Sporadic internet hogs was always attributed to flaky ISP until I hunted down that actually BitCoin client was the culprit (filling up all of upload bandwidth).
For the sake of less tech savvy users, please make obvious and easy option to, at least, add -nolisten argument when starting client.

[heynando]

issue was created 2 damn years ago. What is going on dev guys? Why this has not been patched yet? Don't you guys see the urgent necessity of such feature?

it's so stupid to not implement this ASAP cuz it does give a bad look to the whole app and community, since it fucks up people's internet, and a lot of them are not into technical stuff, which basically means, bad program -> uninstall..

[laanwj]

You misunderstand how open source development works. We work on this in our
spare time so we decide for ourselves what is important and want to spend
time on.

If you want something to be very badly implemented it is your
responsibility to make that happen, not ours.

Can you contribute to solving this issue?

Or are you willing to pay to have the feature implemented? You could offer
an bounty.

[gmaxwell]

I don't, fwiw, see an urgent need for such a feature— and until some extra components are developed such a feature would be harmful for the network: if you set a low throttle your peers need to switch to pulling blocks from someone else when you are slow. (Also an issue absent a throttle but many people setting a throttle would make it worse)

Right now it's better for traffic constrained nodes to just disable listening. This will largely have the desired effect, doesn't risk adding problems, and is an already available option.

[sipa]

I think the issue here is much more that it is not obvious to a new user that by default your node will provide blocks to the network. Disable listening would indeed mostly fix that, but it's far from obvious.

[lucb1e]

If I don't forward my port, can't other clients download from me? The client makes outgoing connections in order to receive blocks. In BitTorrent outgoing connections are also used for uploading it seems, and it makes sense because this keeps the network much more alive. Does Bitcoin do the same, upload blocks to connected nodes if you didn't portforward?

[gmaxwell]

Nodes don't announce themselves as accepting connections until they are mostly caught up... so you'd only be forwarding on new blocks, which isn't a tremendous amount of data.

[lucb1e]

I am caught up with the block chain, that's not the issue here. But I would be forwarding new blocks to connected peers regardless of whether my port is forwarded? Because that might result in an upload job of 1.5MB for a new block, if all connected nodes don't have the new block yet.

[cjastram]

"Nodes don't announce themselves as accepting connections until they are mostly caught up... so you'd only be forwarding on new blocks, which isn't a tremendous amount of data."

Nevertheless, it saturates my uplink. I am on DSL with no other options, and it is a solid 50-70 kilobyte (not kilobit) upload, making the connection completely unusable for anything else. Someday, Google Fiber will bring me a giant fat pipe and this won't be a concern, but since I live in a fairly rural area, it is not likely for a while.

This lack of upload control harms the network because I turn the whole node completely off unless I am actually engaging in a transaction. Wouldn't it be better to have a slow node than no node?

[heynando]

seems like the devs think everybody has googlefiber, this is a shame, really, there's X types of internet services around the world with Y upload/download limits. Forcing the user to do something that will harm its own internet is an outrageous decision.

Not to mention that, once the user finds out what is hammering its internet, the most common decision is kill the program who is causing the problem and abandon it, or use it as low as possible, it becomes a bad thing instead of a good thing. This is bad marketing. This disappoints me in so many ways.

How am i going to recommend this to a friend knowing that later the same friend will come to me and say "hey remember that program you told me to use? it was messing with my internet, making it very slow, i couldn't even see a utube video in piece, bad call dud". That's the least that could happen, and this is just a simple example.

Like cjastram just pointed out, better to HAVE a slow node than NO node at all. If the devs were intelligent enough to create such an futuristic and advanced code, i'm sure they already know everything we are pointing out here, no more words, i'm done.

[gmaxwell]

@XcaninoX so, you're saying you turned off listening as advised and it's using 70kbytes/sec outbound?

[sipa]

Personally, I think upload throttling as-is is a bad idea, at least until we improve the block sync mechanism. If you happen to hit a throttled node when syncing, syncing will be slow.

Instead, I think we need a "non server" mode (some checkbox, perhaps asked on first startup), which disables serving (historic) blocks, disables listening (by default) and disables NODE_NETWORK (so nodes don't announce themself as full noes). This means people can still do the validation and relaying part of being a full node, but without the bandwidth implications of serving the full chain.

Later, such a non-server mode could be turned into a pruning mode, where historic blocks aren't even kept on disk.

[cjastram]

Personally, I think upload throttling as-is is a bad idea, at least until we improve the block sync mechanism. If you happen to hit a throttled node when syncing, syncing will be slow.

Of course, but isn't the sync slow if you hit a node that has limited bandwidth? You don't magically get a fast sync just because you don't allow nodes the ability to throttle. The problem is that if you don't allow throttling, then you get no node because people just turn it off.

After a while of people just turning it off, then you start getting massive sync load on the system because people need to sync hundreds (or thousands) of blocks whenever they want to do a BTC transaction. Instead of the lightweight sync load that happens in realtime, you have a small (but significant) number of people that require loads of bandwidth all at once.

Hence the problem. If we could just leave BitCoin turned on at low bandwidth, then we wouldn't have the sync issue.

Instead, I think we need a "non server" mode (some checkbox, perhaps asked on first startup), which disables serving (historic) blocks, disables listening (by default) and disables NODE_NETWORK (so nodes don't announce themself as full noes). This means people can still do the validation and relaying part of being a full node, but without the bandwidth implications of serving the full chain.

Maybe. I don't know what my upload bandwidth saturation actually is, whether it is transaction confirmations or other peoples' block syncs.

Later, such a non-server mode could be turned into a pruning mode, where historic blocks aren't even kept on disk.

Let's try to not over-engineer a simpler solution?

[sipa]

@cjastram That is actually my point: I think it's better for people who do cannot or don't want to serve historic blocks to not do that at all, and not even advertize on the network that they do. If we enable bandwidth throttling without that, the chance of accidentally hitting a slow node would increase, while if we remove those nodes from the pool altogether, the chance for that decreases.

People fully shutting down nodes because it saturates their data link is of course bad. Throttling or disabling serving would improve that, but you're close to the resources you're willing to spend, perhaps you shouldn't run a full node in the first place.

Just relay of new transactions and blocks is typically quite low bandwidth - it's just when you get hit by a node that is syncing from scratch that you suddenly get an upload burst.

About over-engineering: the ability to run a pruned node is an inevitable evolution somewhere in the future, in my opinion, and it would also imply a solution to your problem anyway.

[jgarzik]

FWIW, I respectfully disagree, and think the easiest solution is to offer an optional upload (i.e. send or write syscall) throttle. A download throttle is less useful: You cannot really control the amount of incoming remote data; ceasing read(2) will cause good guys to throttle eventually, but bad guys always have a technique or three that will flood incoming anyway. And in the field, users care less about limiting their download speed than they do limiting their upload speed.

It is a common knob on other P2P data serving apps, so I would ACK a properly implemented upload throttle w/ knob.

[sipa]

@jgarzik My point is that we're currently better off with less serving nodes, if that means those nodes are faster. Once we have headers-first, and parallel chain fetching, things are different, and probably anyone willing to contribute a bit of upload is useful.

[slothbag]

OP here, its been a while since creating this issue and for the past 2 years my bitcoin-qt client has very rarely maxed out my upload so I didn't think too much about it.

But recently, in the last month or two I have noticed that my upload or sending data out is quite often completely maxed! I have a decent connection, something like 300-500KB/s upload. Luckily i've managed to catch it most times and I open up a network monitoring tool and kill the ports in question (always bitcoin-qt). I have to be careful because if it ran at that speed for a long period of time, not only would my net be slow but it will quickly consume my data quota.

So now instead of running a full node for ~8 hours a day I let it sync with the network and then shut it down.

If I had a throttle option, I would set it at something like 50KB/s upload.. this is faster than I ever use when downloading the latest blocks (CPU bound).

I think this is a problem, I would like to run a full node, but will not while it consumes 100% of my upload majority of the time.

[gmaxwell]

@slothbag Have you disabled listening?

[slothbag]

No I haven't. I actually would like to contribute as a full listening node.
If I'm gonna disable listening then i might as well not bother and just let
it sync and then shut it down.

On Wednesday, March 6, 2013, Gregory Maxwell wrote:

@slothbag https://github.com/slothbag Have you disabled listening?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/273#issuecomment-14491575
.

[gmaxwell]

@slothbag As a non-listening node you are still a contributor to the network— validating and forwarding transactions and new blocks, preventing partitioning... but you won't use much bandwidth. A rate limit while serving historic blocks would be very damaging to the network right now, it is actually better that you do not run a node than serve historic blocks with a rate limit. ... but better still to run without listening.

[rebroad]

@laanwj An upload limit per ASN might also be a useful feature - would help distribute the blockchain more fairly rather than allowing one ASN to use up all of the allowance. Also, using ASNs to calculate eviction of peers would be a good step towards protecting against bogons.

[laanwj]

Yes using the ASNs makes sense for a few things, including evictions and throttling. Though the practical problem that came up last time is that the ASN database is too large to include as-is. Maybe it could be approximated/encoded in some efficient way for querying though. Or maybe leave downloading it up to the user and make it optional.

[rebroad]

@laanwj oh, I had thought the outbound node selection logic was already using ASNs, but perhaps not - there is something there to "spread" the net wider though - perhaps worth a closer look at the logic to see if it's suitable to be used in the absence of an actual ASN database.

[earonesty]

I think the new sync code does a better job of distributing the load among peers. Throttling should be less of an issue now.

[andrelam]

@earonesty it seems it still is.

[jlopp]

Technically, this issue has been addressed with the addition of the "maxuploadtarget" config parameter. Not sure if that parameter has been exposed in the GUI, though.

[jonasschnelli]

maxuploadtarget has not yet been exposed to the GUI.
Also, once we have libevent for the p2p layer, network throttling should be a low hanging fruit.
Though, I personally think, network throttling should be done a layer deeper then the application layer (router level), since, the application does not know what else – running in the same network – requires bandwidth.

[pabloarod]

I'm using the v5.9.6 still no peer control, as someone said there are software and routers that can control traffic in a network but i found that the number of connections seem to be the problem, Bitcoin appear to open to many connections so no even the internet explorer can display a web page,
Looking in the tabs, i found General View, Send, Receive and Transactions. Is there a threat to link the program with the client torrent, integrating it or something like that? in other to control this type of things that are not really of interest of bitcoin?

[andronoob]

@jlopp maxuploadtarget doesn't solve the bandwidth spike problem. Solutions for this problem already exist, for example, NAFC, which is supported by eMule years ago. But sure, NAFC has its own limitation, it cannot know what other devices which share the same Internet connection are doing.

[Ratief]

Long ago I started watching this thread hoping that some day someone would add options for this. In the mean time I found my own solution. I use iptables and rate limit the connections. This works well for me.

I'm on Ubuntu. I added this to /etc/ufw/before.rules. Tweak as you see fit.

Rate limit bitcoin

-A ufw-before-output -p tcp --sport 8333 -m state --state ESTABLISHED -m limit --limit 30/sec --limit-burst 150 -j ACCEPT
-A ufw-before-output -p tcp --sport 8333 -m state --state ESTABLISHED -j DROP
-A ufw-before-output -p tcp --dport 8333 -m state --state ESTABLISHED -m limit --limit 30/sec --limit-burst 150 -j ACCEPT
-A ufw-before-output -p tcp --dport 8333 -m state --state ESTABLISHED -j DROP

[Hypocritus]

(Unfortunately, without being able to understand the full context of what I had written, and without being able to verify the significant contributions which I have made and continue to make to open source projects, my username is labeled as demanding, free-loading, and rude in the following post. An attempt to use humor to dispel the awkwardness of receiving a personal rebuke to a non-personal inquiry failed to win the hearts of the over-controllers of this eight-year-old open github issue. I now wonder if this update I am presently making will also be condemned or censored. There are many stellar examples to be considered of developers responding gracefully and without presumption to the lowly, poorly-written inquiries of new users who have zero posts logged with a given project; of which I have been the personal beneficiary, and therefore left with the option a) to expound, b) to appropriately respond or c) to withdraw without feeling personally attacked)

[laanwj]

@Hypocritus It's not been implemented because no one did the implementation work, simple as that, that's how it works in open source projects. You just can't demand that others spend time implementing the things you want for free. It's incredibly rude.

[egghead314]

wow such and old thread kinda feel stupid to even post, but still same issue here my internet is being disturbed by running a bitcoin node. i feel pretty strongly on contributing back to bitcoin but at the same time don't want to give up significant performance of my internet connection, so with reluctance another one has set the listen = 0, i wish there were options
:(

[Hypocritus]

Agreed. A key issue is that in the process of a full node being fully unrestricted, there are a few different calls which are made by the client and its peers to the system or the bitcoin network, any one of or series of which could be causing a performance decrease, stall or crash in an almost endless variety of ways on the host machine.

Should a generally unobtrusive and intuitive solution to this issue be found. it would be nice if a) this issue were closed (for the benefit of the denser of us laymen who can't read between the lines), and b) that solution were regularly cited for the relieving sake of those of us who would genuinely and enthusiastically appreciate being able to spend more time building or creating, versus dwindling, searching, or defending (albeit poor) attempts to draw attention to a long-lingering, impacting issue.

And should there be strong reason to maintain this feature as "necessary", such as sound arguments about bitcoin integrity or security, then it would benefit us to have those reasons regularly cited, posted, or linked, and for this issue to be closed.

[droid192]

assuming most run their node on a dedicated device: relax, buy a managed switch for 20-30$, set the ingress/egress rate and be done.
example https://youtu.be/x-Pq27fDfLc?t=764

[verdy-p]

I think that the bset thing to do is to run the node inside a guest VM (including a CLI-oly version of Ubuntu with WSL if you're running on Windows, or a thinner CLI distrib), and tune the hypervisor to place a cap on its bandwidth.

And don't forget to cap also its memory usage: 512MiB for the maxmempoolsize should be largely enough).

This is also the fastest way to shutdown your node rapidly and safely, and restart it (the hypervisor can suspend and create a restartable snapshot much faster than trying to shutdown and restart the BitcoinCore agent in its local OS, something you'll do only occasionnally if you need maintenance of yoru local Linux VM for system/security updates). As a bonus, the hypervisor and its host OS will also offer an additional security protection

[willcl-ark]

This issue was created in 2011, when global average internet speeds according to Akamai were 2.3MBit/s.

Since then global average speeds have increased substantially (according to M-Lab and cable.co.uk) to 34.79MBit/s with many countries having well over 100MBit/s or even 1000MBit/s available to consumers, in conjunction with proliferation of 4 and 5G high speed wireless networks with equivalent speeds.

In the mean time the Bitcoin blockchain has grown from 0.19GB to the current (Oct 2022) ~450GB which puts more strain on network nodes during the IBD phase, something that cannot really be sidestepped in any meaningful way.

Technologies such as compact blocks (BIP152) have been introduced which, for tx-relaying nodes, the authors claim can relay blocks 90% of the time without having to request any missing transactions, sharply reducing the bandwidth spikes reported above which used to occur during moments of new block relay. Note that if user has configured their node to run in -blocksonly mode (to reduce total bandwith by something in the order of ~80% by disablilng transaction relay) they will not be able to benefit from compact blocks bandwidth peak reduction during block relay, as they have no mempool to reconstruct the block from.

In addition to this Erlay is edging towards completion and also claims to reduce bandwidth significantly, although it's currently unclear if it will meet it's initial claim of 40%. More details can be found here.

It is made clear in the comments above that bandwidth limitations on nodes serving historical blocks (listening nodes) is not desirable for the health of the network as a whole, regardless of whether this node wants to feel altruistic by "giving something back to the network".

Therefore I conclude that, unless there is a clear proposal here detailing exactly how bandwidth should be further limited in Bitcoin Core, we should finally close this issue. Because in addition to having on average significantly more bandwidth available today, nodes have the following options available to them to configure depending on their specific circumstances:

Measure	Notes	Reduce total	Limit block spikes
Compact blocks (enabled)	block tx set reconcilliation from mempool	✔️	✔️
maxuploadtarget	limit total upload bandwith per 24h	✔️	❌
-listen=0	no incoming connections	✔️	❌
-blocksonly=1	total bandwith reduction of ~80%	✔️	❌
Reduce maxconnections=	go lower than the default of 10 + 2 outbound peers	✔️	❌
Software bandwidth monitor	e.g. Trickle, per process or interface	✔️	✔️
Router bandwidth monitor	affests all host traffic	✔️	✔️
(Future) Erlay	reduces duplicate relay	✔️	❌

Whilst not all the options are compatible with each other, I believe that there is a working combination here for most operators.

As I understand it there will remain one case which cannot be covered by Bitcoin Core program options alone (i.e. without using software of router bandwidth monitors), which is limiting peak rate during IBD. Bitcoin Core will still see your node use up it's maxuploadtarget quota as soon as it can, before limiting itself.

[maflcko]

Thanks for the summary, going to close for those reasons.

Just some nits:

• -blocksonly=1 is incompatible with compact blocks, so it reduces the average usage, but not spikes
• the trickle software is likely unmaintained and broken
• There is also the setnetworkactive RPC to completely shutdown/reboot the connection manager

[willcl-ark]

Thanks marco, I think I had that info re. blocksonly in the text but it's not clear from the table :)