Opened 11 years ago
Last modified 10 years ago
#4565 reopened Bug
Other network traffic slows down terribly or stops altogether
Reported by: | MechMK1 | Owned by: | |
---|---|---|---|
Priority: | High | Milestone: | None Set |
Component: | Transmission | Version: | 2.41 |
Severity: | Normal | Keywords: | speed |
Cc: | meokey1000@… |
Description
My network is capeable of about 1 MB/s download and about 300 kB/s upload, but as soon as one torrent is active (up- and downloading), my download speed is immediately cut down to about 100 kB/s, even though my down-speed of the torrent is about 20 kB/s. Almost 90 % of my download speed is wasted or lost somewhere. As soon as all torrents are paused, speed raises to 1 MB/s again.
Change History (9)
comment:1 follow-up: ↓ 2 Changed 11 years ago by jordan
- Resolution set to invalid
- Status changed from new to closed
comment:2 in reply to: ↑ 1 Changed 11 years ago by x190
Replying to jordan:
A good rule of thumb is to set your upload limits in Transmission to 80% of what your ISP allows.
Have you ever thought of incorporating auto-bandwidth detection and limiting into Transmission. I believe µTorrent does this and it might even be more effective for users than µTP esp. if it was configurable.
comment:3 Changed 11 years ago by thuerrsch
I've been having the same problem since upgrading my server from Ubuntu Natty to Oneiric a couple of days ago. With transmission-daemon running, total network I/O is far above the limits set in Transmission and two to three times higher than the effective amounts of data transferred by Transmission.
I've been running transmission-daemon pegged at 700 kB/s downstream, 70 KB/s upstream (correspoding to about 70 percent of my total bandwith) for about two years while always enjoying very responsive internet access for other applications. After the upgrade to Oneiric, however, the same limits will choke my connection completely, with dramatically lower effective throughputs reported by Transmission. Switching to turtle mode with much lower limits makes my internet connection useable again, but even then the effective bandwith used by the daemon is only a fraction of the data actually sent and received. The bandwith used by my server (as reported, for example, by byobu) drops to almost zero right after stopping transmission-daemon. The problem occurs with the transmission-daemon 2.33 packages from the official Ubuntu repositories as well as with the 2.41 packages from the PPA. Both releases run just fine under Natty.
MechMK1, which OS do you use? If it's Ubuntu and if your problems began after upgrading to Oneiric like mine, this issue should definitely be looked into.
comment:4 Changed 11 years ago by MechMK1
I am using MacOS X 10.7
comment:5 Changed 10 years ago by kerrichandler
- Resolution invalid deleted
- Status changed from closed to reopened
- Version changed from 2.41 to 2.76
Transmission Version: 2.76 OS: OS X 10.6 ISP download rate: 500 KB/s ISP upload rate: 80 KB/s Transmission download rate: 200 KB/s Transmission upload rate: 20 KB/s Maximum global connections: 10 Maximum connections for new transfers: 10 No peer exchange (PEX) No distributed hash table (DHT) No local peer discovery Prefer encrypted peers Prevent peers in blocklist Disabled Micro Transport Protocol (muTP) Port is opened properly on my router
When transmission is open, I am able to connect to peers and download torrent data just fine, provided I already have the .torrent file on my computer. However, I am unable to use the internet in other ways. For example, ping www.google.com times out. This happens whether or not I am downloading or uploading data, which is already limited to manageable amounts.
This does not happen with muTorrent on the same OS, which I just installed to isolate the problem. I can spam my connection with unlimited up/down speeds and it still doesn't break ping. It also does not happen with muTorrent in Windows on the same machine. I read a comment in the forums saying that if other clients work then the user should just use the other clients. The reason I want to use Transmission on OS X is that I like the interface, it provides good file and torrent management, it is open source, and it provides access to blocklists. However, in the process of writing this post I have started using muTorrent because it doesn't break the internet for other things.
There may be an interaction with other software on my OS. I have LittleSnitch? installed. I am not willing to turn off LittleSnitch?. I can't think of anything else that could be doing this. I have been using Transmission for several years, but something has changed somewhere along the line that made it break. I switched from Tiger to Snow Leopard at some point, and I think that was the beginning of the end. I have a strong feeling that it's a regression in Transmission but I did not put in the effort to do a binary regression search.
Interestingly, Transmission even breaks muTorrent. As soon as I close Transmission, muTorrent starts working.
comment:6 Changed 10 years ago by livings124
- Version changed from 2.76 to 2.41
comment:7 Changed 10 years ago by kerrichandler
- Summary changed from Other network traffic slows down terribly to Other network traffic slows down terribly or stops altogether
comment:8 Changed 10 years ago by meokey
- Cc meokey1000@… added
- Priority changed from Normal to High
- Version changed from 2.41 to 2.77
I confirm the bug with Transmission 2.77 (14031) on Ubuntu.
Every single time when I start up Transmission, it slow down the whole LAN, and incrase ping time more than 10X, and sometimes cause package loss. And when I stop the transmission daemon, the LAN is back to normal.
comment:9 Changed 10 years ago by livings124
- Version changed from 2.77 to 2.41
One common issue is that if you fill your outbound bandwidth with upload data, that can choke out other outbound messages. For example HTTP requests, slowing down your web browsing.
A good rule of thumb is to set your upload limits in Transmission to 80% of what your ISP allows.
More help for this issue can be found in the forums. I'm going to close this ticket because the cause appears to be a configuration issue rather than a bug.