Deluge is a greedy bandwidth-eating monster

[davibe]

I have the same problem usin svn version on osx.
You can "solve" it by setting lower global connection limit.
When I use a value around 100 works fine for me but.. downloads are slower of course (unless you're lucky finding good sources)

I don't know how to disable ipv6 on osx, so I can't confirm the last post, but I don't think that's the problem.

The post title is wrong, it's not a badwidth problem.

[hypermute]

I'd like to confirm this problem, once again.

Since Deluge 0.5.5 the connection recovers a few minutes after having shut down the client. The previous version killed my wired connection completely until I rebooted my router (FRITZ!Box Fon WLAN 7050 ). See also: wifi crash with feisty + 3.4-1

Now, the connection "only" becomes damn slow sometimes. Currently there are not more than two torrents at the same time, one seeding and one downloading. I tried to limit global connections to 50, to no avail. DHT is on. UPnP, NAT-PMP, uTorrent-PeX are off.

[medigeek]

I had this problem since day 1 I started using the bittorrent network. Any client I tried (BitComet, μTorrent, rTorrent, Deluge), GNU/Linux or Windows, I was facing this same thing. I've named this as "bandwidth choking": HTTP is mostly or entirely not responsive when the bittorrent is active.

So I have reasons to believe it's not the program itself that's faulty, but something else. When pausing or closing Deluge torrent, the http becomes responsive again in a matter of seconds or in a couple of minutes.
When I was using Windows and μTorrent, I had to restart the router to get the HTTP working again.

It could be because some malicious people are attacking or port-probing you for weak spots to exploit your computer, who knows! All I know is that with Deluge this thing is happening less often

[gazpachoking]

It sounds like traffic shaping may help you guys out. I use ctshaper as it is quite easy to set up and integrate with an iptables firewall. Then you just tune a couple variable for your downlink and uplink speed... voila! Before I installed ctshaper Pinging google.com was giving me an average of 1000ms with about 20% of the packets dropped (while running torrents), after I installed it a ping to google is always under 100ms with no dropped packets. Hope this helps.

[RyosukeFC]

I used to have this problem until I choked my outbound to 25KByte/sec or less (my limit seems to be about 85-90KByte/sec), and set the maximum upload slots per torrent to 2.Then I set the max global connections to some randomly high number (20000 commonly), and bind to a port like 21-23, 80, etc. that Comcast won't suspect as a torrent port, and I can run either rtorrent (my favorite BT client hands-down) or uTorrent (if I'm in Windows and not grabbing anything suspicious) or whatever, and with 7 simultaneous downloads (the limit I gave) in uTorrent or 15+ simultaneous with rtorrent, I can happily max out my inbound at 1MByte/sec+ and still surf comfortably. I know Comcast is evil and everything, but mmm, 8Mbit/sec...

I haven't been able to try Deluge, since despite claiming to offer a "native", "overhead-free" client, it still requires python and boost. Python isn't significantly less bloated than JAVA (which the Deluge devs and myself both agree to hate), and Boost won't compile correctly on OpenSuSE (my distro of choice) because the Boost people think they need to compile jam using a precompiled jam bootstrapper binary, which segfaults immediately. And yes, I tried adding Boost packages from the SuSE buildservice, but they don't have even a fraction of the Boost libraries available.

So while Deluge looks pretty and seems to offer what I want out of a torrent client (despite being built on top of libtorrent (like sharktorrent, transmission, etc.) rather than libtorrent (like rtorrent)), I'll have to continue on with my trusty rtorrent for the forseeable future.

Note to Deluge devs: Could you possibly provide a statically-compiled monolithic executable? At least then I could try the program. I'd really appreciate it. Pretty please?

[RyosukeFC]

Amusingly though, I can still set the upload cap (under rtorrent anyway) as high as like 60-65KByte/sec before I have any noticeable trouble browsing.

Also, I should mention, I'm not going through a router (yet, I don't own one anymore).

[hypermute]

Maybe that's the solution:

I had lowered up- and download settings, as well as slots etc. with no avail. As a last resort, before trying traffic shaping, I then changed the ports from a high value to a lower one and forwarded them accordingly, abandoning port ranges. It now looks something like this:

Before:
TCP & UDP: 9000 - 9001

After:
TCP & UDP: 12354

Everything is fine. I can browse the web again, although the up/down/slot/connections settings are still conservative. I will try tuning them later.

Right now I'd like to thank you all for your comments.
hypermute

[hypermute]

I can browse the web again, although the up/down/slot/connections settings are still conservative. I will try tuning them later.

Everything is fine, fine, fine.