Topic: Bitcoin client upload saturating my DSL connection. (No bandwidth throttling ?) (Read 12751 times)
June 15, 2014, 04:12:51 AM
Bitcoin client downloaded data is too large, it is a hassle.
June 02, 2014, 12:22:36 PM
Give the drop in number of nodes I think this might be a reason / solution.
February 18, 2013, 09:46:59 AM
In linux you can use a tool called "trickle" to limit your bandwidth like this:
That will limit its upload to 50kb/s
Code:
trickle -u50 bitcoind
That will limit its upload to 50kb/s
So useful even now, half year later, I dug this from google. Thanks!
Is there anything equivalent to trickle for cpu usage?
February 17, 2013, 11:30:02 AM
In linux you can use a tool called "trickle" to limit your bandwidth like this:
That will limit its upload to 50kb/s
Code:
trickle -u50 bitcoind
That will limit its upload to 50kb/s
So useful even now, half year later, I dug this from google. Thanks!
Is there anything equivalent to trickle for cpu usage?
January 11, 2013, 06:53:46 AM
In linux you can use a tool called "trickle" to limit your bandwidth like this:
That will limit its upload to 50kb/s
Code:
trickle -u50 bitcoind
That will limit its upload to 50kb/s
So useful even now, half year later, I dug this from google. Thanks!
Is there anything equivalent to trickle for cpu usage?
$ man nice
January 11, 2013, 06:50:16 AM
In linux you can use a tool called "trickle" to limit your bandwidth like this:
That will limit its upload to 50kb/s
Code:
trickle -u50 bitcoind
That will limit its upload to 50kb/s
So useful even now, half year later, I dug this from google. Thanks!
Is there anything equivalent to trickle for cpu usage?
January 11, 2013, 05:37:05 AM
In linux you can use a tool called "trickle" to limit your bandwidth like this:
That will limit its upload to 50kb/s
Code:
trickle -u50 bitcoind
That will limit its upload to 50kb/s
So useful even now, half year later, I dug this from google. Thanks!
October 24, 2012, 06:12:01 PM
If You are behind NAT then don't open incoming 8333 port (disable UPnP in bitcoin settings) and bitcoin will connect to max of 8 nodes. Just that simple, just that clean!
Thanks all for your numerous "Just that simple" solution.If you haven't noticed, I'm inquiring about a solution for the general public.
The general public has their bitcoin client behind a NAT without a forwarded port and therefore only 8 connections. Those who know how to open a port know who to limit the bandwidth using an external program.
But it would be neater to have it integrated in the client itself.
Quote
use netlimiter
Net Limiter occupies NDIS driver interface and introduces additional problems.you can disable/enable the netlimiter drivers at will
October 24, 2012, 02:18:35 PM
If You are behind NAT then don't open incoming 8333 port (disable UPnP in bitcoin settings) and bitcoin will connect to max of 8 nodes. Just that simple, just that clean!
Thanks all for your numerous "Just that simple" solution.If you haven't noticed, I'm inquiring about a solution for the general public.
Can you answer to this guy's problem two post up ?
I've noticed too that bitcoind is saturating my upload speed, and I don't even have port forwarding from my gateway linux machine to the 'internal' linux server where I have bitcoind running.
Seems pretty poor design to not have it in the client already to limit upload bandwidth like bittorrent etc. has done for YEARS.
...
Seems pretty poor design to not have it in the client already to limit upload bandwidth like bittorrent etc. has done for YEARS.
...
October 24, 2012, 02:10:48 PM
If You are behind NAT then don't open incoming 8333 port (disable UPnP in bitcoin settings) and bitcoin will connect to max of 8 nodes. Just that simple, just that clean!
Thanks all for your numerous "Just that simple" solution.If you haven't noticed, I'm inquiring about a solution for the general public.
The general public has their bitcoin client behind a NAT without a forwarded port and therefore only 8 connections. Those who know how to open a port know who to limit the bandwidth using an external program.
But it would be neater to have it integrated in the client itself.
Quote
use netlimiter
Net Limiter occupies NDIS driver interface and introduces additional problems. October 24, 2012, 10:17:56 AM
If You are behind NAT then don't open incoming 8333 port (disable UPnP in bitcoin settings) and bitcoin will connect to max of 8 nodes. Just that simple, just that clean!
Thanks all for your numerous "Just that simple" solution.If you haven't noticed, I'm inquiring about a solution for the general public.
The general public has their bitcoin client behind a NAT without a forwarded port and therefore only 8 connections. Those who know how to open a port know who to limit the bandwidth using an external program.
But it would be neater to have it integrated in the client itself.
like i said a month or so ago in this thread, i use netlimiter
there are also free utilities that will do the same thing for windows
or you can use the QoS that comes with windows, I believe.. or should at least be on your router/DSL modem/whatever
October 24, 2012, 09:08:23 AM
If You are behind NAT then don't open incoming 8333 port (disable UPnP in bitcoin settings) and bitcoin will connect to max of 8 nodes. Just that simple, just that clean!
Thanks all for your numerous "Just that simple" solution.If you haven't noticed, I'm inquiring about a solution for the general public.
The general public has their bitcoin client behind a NAT without a forwarded port and therefore only 8 connections. Those who know how to open a port know who to limit the bandwidth using an external program.
But it would be neater to have it integrated in the client itself.
October 23, 2012, 08:55:21 PM
1. Multi-homed machine; Bitcoin has it's own IP address
2. HTB to throttle bandwidth on that interface or configure your gateway to limit it's bandwidth.
2. HTB to throttle bandwidth on that interface or configure your gateway to limit it's bandwidth.
October 23, 2012, 01:38:12 PM
In linux you can use a tool called "trickle" to limit your bandwidth like this:
That will limit its upload to 50kb/s
You rock! This is exactly what I need.Code:
trickle -u50 bitcoind
That will limit its upload to 50kb/s
EDIT: Looks like trickle only supports dynamically linked executables. Looks like my bitcoin-qt is statically linked:
Code:
rune@rune-desktop:~$ ldd /usr/bin/bitcoind
not a dynamic executable
not a dynamic executable
I'm using the PPA version (0.7.0-precise1). Which version are you using?
In linux you can use a tool called "trickle" to limit your bandwidth like this:
That will limit its upload to 50kb/s
Sorry but what about adding a way to set connection limiting setting of bitcoin.conf to the UI ?Code:
trickle -u50 bitcoind
That will limit its upload to 50kb/s
This is ridiculously weird.
And NO I am not editing my conf file nor am I going to install Linux for this.
Thanks HeavyMetal for trying to help
October 22, 2012, 09:52:28 PM
If You are behind NAT then don't open incoming 8333 port (disable UPnP in bitcoin settings) and bitcoin will connect to max of 8 nodes. Just that simple, just that clean!
Thanks all for your numerous "Just that simple" solution.If you haven't noticed, I'm inquiring about a solution for the general public.
Can you answer to this guy's problem two post up ?
I've noticed too that bitcoind is saturating my upload speed, and I don't even have port forwarding from my gateway linux machine to the 'internal' linux server where I have bitcoind running.
Seems pretty poor design to not have it in the client already to limit upload bandwidth like bittorrent etc. has done for YEARS.
...
Seems pretty poor design to not have it in the client already to limit upload bandwidth like bittorrent etc. has done for YEARS.
...
October 22, 2012, 08:46:17 PM
If You are behind NAT then don't open incoming 8333 port (disable UPnP in bitcoin settings) and bitcoin will connect to max of 8 nodes. Just that simple, just that clean!
October 22, 2012, 11:29:57 AM
There has to been numerous speed limiting algorithm developed for eMule and uTorrent.
Here's more. :
http://bittorrent.org/beps/bep_0029.html
http://tools.ietf.org/html/draft-ietf-ledbat-congestion-00
Here's more. :
http://bittorrent.org/beps/bep_0029.html
http://tools.ietf.org/html/draft-ietf-ledbat-congestion-00
Quote
...μTP eliminates this problem by being better at only using bandwidth when there is no other traffic competing, and automatically slowing or stopping BitTorrent transfers before network connections seize up.
...
It does this by being able to detect congestion on a network based on how long a packet takes to be sent from one peer to the next. If things start to take longer, then μTP adjusts the rate of sending accordingly....
...
It does this by being able to detect congestion on a network based on how long a packet takes to be sent from one peer to the next. If things start to take longer, then μTP adjusts the rate of sending accordingly....
September 21, 2012, 06:06:05 PM
Trying 'trickled' and then 'trickle' for the process. More often that not bitcoin will run for a bit and then die. Looking at 'bitcoind getinfo' shows that it has no connections. It seems to try to find connections and then exits. namecoind exits really very quickly.
Anyone else have luck with the 'trickle' traffic shaper?
UpdatE: Also noticed that bitcoind doesn't keep synchronized to the network, even though it shows as having connections, when run via 'trickle'. If I run it normally, it synchronizes just fine.
Anyone else have luck with the 'trickle' traffic shaper?
UpdatE: Also noticed that bitcoind doesn't keep synchronized to the network, even though it shows as having connections, when run via 'trickle'. If I run it normally, it synchronizes just fine.
September 21, 2012, 03:59:25 PM
I've noticed too that bitcoind is saturating my upload speed, and I don't even have port forwarding from my gateway linux machine to the 'internal' linux server where I have bitcoind running.
Seems pretty poor design to not have it in the client already to limit upload bandwidth like bittorrent etc. has done for YEARS.
Got to try 'trickle', that might work well.
Seems pretty poor design to not have it in the client already to limit upload bandwidth like bittorrent etc. has done for YEARS.
Got to try 'trickle', that might work well.
August 28, 2012, 06:53:46 PM
Start with the command line option -maxconnections=X, where X is the largest number of other peers you want to maintain connections with. This won't prevent one of the clients wanting to get the whole blockchain from you, but it will lower the chance.
August 27, 2012, 12:34:50 PM
Just disable upnp and/or stop forwarding the bitcoin port from your router, this limits you just listening to 8 connections.
Currently I leave the client closed and when I want to make a transaction it take as little as 2 min to catch up. I prefer to broadcast my transaction to 60+ connection than 8.Given how trivial to implement is what I ask please stop the OS / router patches recommendation . Thank you.
I leave my client closed and it doesn't have to catch up if I'm sending funds. Otherwise I start it and leave it overnight about once every couple weeks.
August 26, 2012, 02:53:18 PM
Just disable upnp and/or stop forwarding the bitcoin port from your router, this limits you just listening to 8 connections.
Currently I leave the client closed and when I want to make a transaction it take as little as 2 min to catch up. I prefer to broadcast my transaction to 60+ connection than 8.Given how trivial to implement is what I ask please stop the OS / router patches recommendation . Thank you.
You can tell bitcoin-qt to not use upnp from within the gui, also I don't see how 60 connections is better to broadcast a transaction v 8 connections, using only 8 also increases anonymity. You can also tell bitcoin-qt to use a tor proxy from within the gui.
August 25, 2012, 03:58:56 PM
In linux you can use a tool called "trickle" to limit your bandwidth like this:
That will limit its upload to 50kb/s
Sorry but what about adding a way to set connection limiting setting of bitcoin.conf to the UI ?Code:
trickle -u50 bitcoind
That will limit its upload to 50kb/s
This is ridiculously weird.
And NO I am not editing my conf file nor am I going to install Linux for this.
Thanks HeavyMetal for trying to help
August 25, 2012, 03:50:01 PM
Just disable upnp and/or stop forwarding the bitcoin port from your router, this limits you just listening to 8 connections.
Currently I leave the client closed and when I want to make a transaction it take as little as 2 min to catch up. I prefer to broadcast my transaction to 60+ connection than 8.Given how trivial to implement is what I ask please stop the OS / router patches recommendation . Thank you.
August 25, 2012, 12:36:59 PM
Just disable upnp and/or stop forwarding the bitcoin port from your router, this limits you just listening to 8 connections.
August 24, 2012, 07:31:58 PM
In linux you can use a tool called "trickle" to limit your bandwidth like this:
That will limit its upload to 50kb/s
Sorry but what about adding a way to set connection limiting setting of bitcoin.conf to the UI ?Code:
trickle -u50 bitcoind
That will limit its upload to 50kb/s
This is ridiculously weird.
And NO I am not editing my conf file nor am I going to install Linux for this.
Thanks HeavyMetal for trying to help
August 24, 2012, 07:27:49 PM
In linux you can use a tool called "trickle" to limit your bandwidth like this:
That will limit its upload to 50kb/s
Code:
trickle -u50 bitcoind
That will limit its upload to 50kb/s
August 17, 2012, 12:00:08 PM
It might be possible under CLI but there is no such feature in the QT Version.
...By the way, the clients cannot endlessly ask for blocks: there is a hardcoded limit of 500 blocks per session per IP address. ...
2112 meant that the block-sending peer limits the block rates, not the block-requester, so rogue clients have good/smart clients to stop them.
However, if I'm reading the code correctly, it looks like 500 block hashes per request-message can be sent (via an inv response to getblocks). Actual block data seems to only be limited to 50,000 blocks per request (or transactions, since this message can be used to fetch them too.)
This is my first time looking at the code, so I could be wrong. There could also be lower-level rate-limiting not visible in the referenced sections of code.
August 17, 2012, 09:21:14 AM
Botnets of rogue clients don't care about limits.
I doubt about any botnets pretending to be the Bitcoin clients. About the only botnet-like thing that I could correlate with with running a Bitcoin (and Litecoin) client were probes for misconfigured and easily exploitable home routers with remote configuration port open.On the other hand Bitcoin has a mechanism for statistically spreading p2p connections globally over /16 subnets. You may be running your bitcoin client on an ISP that has none or very few other bitcoin clients within the same /16 netmask.
I observed this on one of my office ISPs which gave us several disjont /28 subnets. Depending on which IP range I exposed my client I would've gotten vastly different numbers of incoming connections. But they are were legitimately behaving.
August 17, 2012, 09:03:06 AM
It might be possible under CLI but there is no such feature in the QT Version.
...By the way, the clients cannot endlessly ask for blocks: there is a hardcoded limit of 500 blocks per session per IP address. ...
I don't think it's normal to put at risk users Internet's connections reliability for a feature so basic and easy to add.
There is more menus and sections in the GUI than there are settings to configure.
August 17, 2012, 05:09:01 AM
It might be possible under CLI but there is no such feature in the QT Version.
...By the way, the clients cannot endlessly ask for blocks: there is a hardcoded limit of 500 blocks per session per IP address. ...
I don't think it's normal to put at risk users Internet's connections reliability for a feature so basic and easy to add.
There is more menus and sections in the GUI than there are settings to configure.
August 16, 2012, 06:23:25 PM
It might be possible under CLI but there is no such feature in the QT Version.
It works both with bitcoind and bitcoin-qt. You can set it in bitcoin.conf. The flag is:maxconnections=125
with 125 being the default value. Set it to 9 or 10 if you have bandwidth caps.
By the way, the clients cannot endlessly ask for blocks: there is a hardcoded limit of 500 blocks per session per IP address. If you are really pushed into limiting your bandwidth usage then put "listen=0" in the .conf file and set the maxconnections to less than the default 8 outgoing connections.
Be aware that Satoshi bitcoin client does not check the spelling of the configuration flags and does not inform you about the ignored flags. This is entirely by design.
August 16, 2012, 05:20:06 PM
Quote
This is almost a security concern as rogue clients could endlessly request upload of the block-chain and saturate thousands of people's slow connections.
yeah, I've had this happen. I'm not sure if it's intentional or not, though.
but there have been several occasions where i've had one IP receiving data at 300k/s + for hours (this on my dedicated server, not home connection)
August 16, 2012, 03:35:18 PM
It might be possible under CLI but there is no such feature in the QT Version.
https://en.bitcoin.it/wiki/Running_Bitcoin#Bitcoin.conf_Configuration_File
August 16, 2012, 03:24:59 PM
You won't see me running a node until I can at least control the number of connections.
(for obvious reasons, one of them being; not able to use my home connection reliably)
(for obvious reasons, one of them being; not able to use my home connection reliably)
You can actually set the number of connections, but I don't know enough about it to tell you how to do it. You could 'nice' the process, and that would slow it down somewhat.
"Nice" is for Linux, and affect the CPU aspect only.
This is almost a security concern as rogue clients could endlessly request upload of the block-chain and saturate thousands of people's slow connections.
August 16, 2012, 03:21:53 PM
You won't see me running a node until I can at least control the number of connections.
(for obvious reasons, one of them being; not able to use my home connection reliably)
(for obvious reasons, one of them being; not able to use my home connection reliably)
You can actually set the number of connections, but I don't know enough about it to tell you how to do it. You could 'nice' the process, and that would slow it down somewhat.
August 16, 2012, 03:16:55 PM
...
i use software called NetLimiter to limit the upstream available to the bitcoin client (amongst other things)
Thanks for the tip, I'd use my router QOS feature if I was concerned. Just wont be running it.i use software called NetLimiter to limit the upstream available to the bitcoin client (amongst other things)
You won't see me running a node until I can at least control the number of connections.
(for obvious reasons, one of them being; not able to use my home connection reliably)
Also, It's not written anywhere what port it is using, although it has a "Map using UPnP" feature which nobody security conscious should be using.
Oh and the "Help" menu provide no help whatsoever. Not that I needed any, apart for knowing what port I should forward. (8333, I know)
August 16, 2012, 05:43:01 AM
yes, it is normal.
i use software called NetLimiter to limit the upstream available to the bitcoin client (amongst other things)
i use software called NetLimiter to limit the upstream available to the bitcoin client (amongst other things)
August 14, 2012, 11:50:18 PM
During four days the bitcoin-qt.exe has uploaded 2.5gb of data and received 128mb.
It totally saturate my upload thus bottlenecking download too. Pings of 260ms
I had 58 connected peers.
A: Is this normal ?
B: How trivial is it to add a bandwidth limiting feature ?
C: Why not a connection limiting feature too, ? I would think 40 connection is enough for me.
It totally saturate my upload thus bottlenecking download too. Pings of 260ms
I had 58 connected peers.
A: Is this normal ?
B: How trivial is it to add a bandwidth limiting feature ?
C: Why not a connection limiting feature too, ? I would think 40 connection is enough for me.
Jump to: