Topic: Limiting upload bandwidth in Satoshi bitcoin client (Read 4907 times)
Nice this is good
The free version of netbalancer can limit up to 3 programs.
learn to search. there are at least 3 threads about this.
Gotta love a helpful post like this one
I'd like to ask if there is any way to configure the standard Satoshi bitcoin blient (current running v0.7.x) to limit its upload bandwidth. If not, are there any plans to introduce it in a future release such as v0.8? Do any of the other clients offer bandwidth limiting?
My service is 10mbit/s download and 0.5mbit/s upload. There are occasions when external nodes connect to my client and start to download the blockchain. This saturates my upload bandwidth (about 50kbytes/s) and my internet latency skyrockets (ping times in the 2000-3000ms range consistently, when normally they would be 20-30ms). During these times, internet browsing and other internet activity becomes virtually unusable.
If I notice this happening, I exit the client and my internet latency returns to normal. If there was a way to limit the bitcoin client's upload bandwidth, this problem should be mitigated.
My service is 10mbit/s download and 0.5mbit/s upload. There are occasions when external nodes connect to my client and start to download the blockchain. This saturates my upload bandwidth (about 50kbytes/s) and my internet latency skyrockets (ping times in the 2000-3000ms range consistently, when normally they would be 20-30ms). During these times, internet browsing and other internet activity becomes virtually unusable.
If I notice this happening, I exit the client and my internet latency returns to normal. If there was a way to limit the bitcoin client's upload bandwidth, this problem should be mitigated.
Why not using Electrum ?
... so even if (or especially if) you have a network rate limiter, it's probably best to set listen=0 so your ratelimited transmission doesn't cause a slow sync for someone else.
Thanks for the info; this will help. 
There is not yet a way to limit it inside bitcoind/bitcoin-qt itself, though it's something that will be done in the future.
Virtually all the bulk users is new users sucking down the chain from you— there has been a _ton_ of new nodes added lately, so it's more obvious than ever. You can prevent this by setting listen=0 in bitcoin.cof or -listen=0 on the commandline. This will prevent inbound connections, and since only nodes which have most of the chain will listen for outbounds this will mostly opt you out of feeding new clients.
Simplistic network rate limiters don't do anything to tell your peers they should pull from someone else instead, and the Bitcoin software itself isn't yet smart enough to figure it out... so even if (or especially if) you have a network rate limiter, it's probably best to set listen=0 so your ratelimited transmission doesn't cause a slow sync for someone else.
Cheers.
Virtually all the bulk users is new users sucking down the chain from you— there has been a _ton_ of new nodes added lately, so it's more obvious than ever. You can prevent this by setting listen=0 in bitcoin.cof or -listen=0 on the commandline. This will prevent inbound connections, and since only nodes which have most of the chain will listen for outbounds this will mostly opt you out of feeding new clients.
Simplistic network rate limiters don't do anything to tell your peers they should pull from someone else instead, and the Bitcoin software itself isn't yet smart enough to figure it out... so even if (or especially if) you have a network rate limiter, it's probably best to set listen=0 so your ratelimited transmission doesn't cause a slow sync for someone else.
Cheers.
yes, there's also discussion on that on github. the reason is something along the lines of not easy to implement.
This should be one of the highest priority issues, yet it's marked as "priority low". Something as simple as (limit upload to X kb/sec) would solve this. I would fix it myself if I had the resources (money, time).
Edit: thanks for the issue link, I've added my voice to the noise.
Better to leave network bandwidth limiting to the tool designed just for it, or qos settings in your router, than have bitcoin itself try to handle that. On Windows one could use Netlimiter and cap the upload speed only on the bitcoin process.
yes, there's also discussion on that on github. the reason is something along the lines of not easy to implement.
This should be one of the highest priority issues, yet it's marked as "priority low". Something as simple as (limit upload to X kb/sec) would solve this. I would fix it myself if I had the resources (money, time).
Edit: thanks for the issue link, I've added my voice to the noise.
learn to search. there are at least 3 threads about this.
They all say the same thing, either:
- install rate limiting software (I've been down that road before, no thanks)
- use trickle (I'm not on Linux, and trickle isn't on cygwin)
- reduce maximum number of connections (which just reduces the likelihood of saturation, it can still occur)
The default client should have limiting support built-in, otherwise only people with fast and high-capacity Internet connections can ever use Bitcoin (or at the very least, be a full node, increasing network security). I can only run the client a few hours a day now.
edit: https://github.com/bitcoin/bitcoin/issues/756
learn to search. there are at least 3 threads about this.
They all say the same thing, either:
- install rate limiting software (I've been down that road before, no thanks)
- use trickle (I'm not on Linux, and trickle isn't on cygwin)
- reduce maximum number of connections (which just reduces the likelihood of saturation, it can still occur)
The default client should have limiting support built-in, otherwise only people with fast and high-capacity Internet connections can ever use Bitcoin (or at the very least, be a full node, increasing network security). I can only run the client a few hours a day now.
learn to search. there are at least 3 threads about this.
I just got hit with this, where my connection will occasionally become literally unusable for chunks of time due to the bitcoin and litecoin clients. Shutting them down instantly fixes the problem. I think this means I can no longer be a fulltime full node. The clients need some way to throttle bandwidth. (Due to geographical constraints my connection is limited to 8 Mbps/800 Kbps.)
This is just one reason why the default client is still known as *beta*; it is nowhere near ready for prime-time. I'd love to run it full-time, but this bandwidth issue makes that impractical. Honestly, the effort to configure our routers to throttle upstream bitcoind traffic is something that shouldn't be necessary.
I just got hit with this, where my connection will occasionally become literally unusable for chunks of time due to the bitcoin and litecoin clients. Shutting them down instantly fixes the problem. I think this means I can no longer be a fulltime full node. The clients need some way to throttle bandwidth. (Due to geographical constraints my connection is limited to 8 Mbps/800 Kbps.)
I found that limiting maxconnections to a small value (12 or so) in bitcoin.conf or on the command line helps a lot with limiting its bandwidth. See https://en.bitcoin.it/wiki/Running_Bitcoin for ways to set maxconnections.
The real culprit is bufferbloat. The network buffer between your high-speed LAN and the low-speed WAN is too large and has inadequate queue management, causing high latency (measured in seconds) when it fills up. The offending buffer might be in your router or in your modem or in your ISP's switches. Depending on where the buffer is, you may or may not be able to do anything about it. QoS in your OS or router can mitigate the problem, though.
The real culprit is bufferbloat. The network buffer between your high-speed LAN and the low-speed WAN is too large and has inadequate queue management, causing high latency (measured in seconds) when it fills up. The offending buffer might be in your router or in your modem or in your ISP's switches. Depending on where the buffer is, you may or may not be able to do anything about it. QoS in your OS or router can mitigate the problem, though.
Hate to necro a thread but as this is only a couple months old I'd like to bring it back up as a concern. I'm having this issue now, my flatmates are complaining about the internet being slow and shutting off bitcoin-qt fixes it.
What spot in the code should I look in to rate-limit the upload and then can someone hold my hand through building bitcoin QT with this new feature?
What spot in the code should I look in to rate-limit the upload and then can someone hold my hand through building bitcoin QT with this new feature?
I figured as much, but thought I'd ask. Thanks, zvs.
I'd like to ask if there is any way to configure the standard Satoshi bitcoin blient (current running v0.7.x) to limit its upload bandwidth. If not, are there any plans to introduce it in a future release such as v0.8? Do any of the other clients offer bandwidth limiting?
My service is 10mbit/s download and 0.5mbit/s upload. There are occasions when external nodes connect to my client and start to download the blockchain. This saturates my upload bandwidth (about 50kbytes/s) and my internet latency skyrockets (ping times in the 2000-3000ms range consistently, when normally they would be 20-30ms). During these times, internet browsing and other internet activity becomes virtually unusable.
If I notice this happening, I exit the client and my internet latency returns to normal. If there was a way to limit the bitcoin client's upload bandwidth, this problem should be mitigated.
My service is 10mbit/s download and 0.5mbit/s upload. There are occasions when external nodes connect to my client and start to download the blockchain. This saturates my upload bandwidth (about 50kbytes/s) and my internet latency skyrockets (ping times in the 2000-3000ms range consistently, when normally they would be 20-30ms). During these times, internet browsing and other internet activity becomes virtually unusable.
If I notice this happening, I exit the client and my internet latency returns to normal. If there was a way to limit the bitcoin client's upload bandwidth, this problem should be mitigated.
the only way to deal with this right now is to set QoS... i think windows has some built-in QoS, also some (most?) routers
i used to use netlimiter (for windows)
I'd like to ask if there is any way to configure the standard Satoshi bitcoin blient (current running v0.7.x) to limit its upload bandwidth. If not, are there any plans to introduce it in a future release such as v0.8? Do any of the other clients offer bandwidth limiting?
My service is 10mbit/s download and 0.5mbit/s upload. There are occasions when external nodes connect to my client and start to download the blockchain. This saturates my upload bandwidth (about 50kbytes/s) and my internet latency skyrockets (ping times in the 2000-3000ms range consistently, when normally they would be 20-30ms). During these times, internet browsing and other internet activity becomes virtually unusable.
If I notice this happening, I exit the client and my internet latency returns to normal. If there was a way to limit the bitcoin client's upload bandwidth, this problem should be mitigated.
My service is 10mbit/s download and 0.5mbit/s upload. There are occasions when external nodes connect to my client and start to download the blockchain. This saturates my upload bandwidth (about 50kbytes/s) and my internet latency skyrockets (ping times in the 2000-3000ms range consistently, when normally they would be 20-30ms). During these times, internet browsing and other internet activity becomes virtually unusable.
If I notice this happening, I exit the client and my internet latency returns to normal. If there was a way to limit the bitcoin client's upload bandwidth, this problem should be mitigated.
Jump to: