Opened 9 years ago

Closed 9 years ago

#5337 closed Bug (incomplete)

bandwidth overflow

Reported by: tipper Owned by:
Priority: Normal Milestone: None Set
Component: Transmission Version: 2.77
Severity: Normal Keywords:
Cc:

Description

Debian Linux wheezy (testing) Transmission 2.77 transmission-daemon (WebUI)

I have noticed that running "iftop -nNPBb" (as root) shows that Transmission greatly overflows the bandwidth caps specified in settings.json.

upload cap example: 15 kilobytes -> overflows to 15-30 (30 is the contracted ISP limit) download cap example: 200 kilobytes -> overflows to 200-300 (300 is the contracted ISP limit)

Steps to reproduce:

  1. download 1 magnet that has hundreds of seeders
  2. specify upload and download caps in settings.json
  3. run "iftop -nNPBb" (as root) and you can observe that Transmission will overflow the bandwidth considerably. It even reaches the contracted ISP bandwidth limits.

(No other network-using program is up while testing this.)

I assume this is because the upload and download limits in settings.json are really only seeding limits; they do not include overhead ? Overflowing the ISP bandwidth limit will have the effect of packet loss ?

Programs such as gtk-gnutella allow for specifying both seeding limits and overhead limits.

Attachments (1)

settings.json (2.1 KB) - added by tipper 9 years ago.

Download all attachments as: .zip

Change History (14)

Changed 9 years ago by tipper

comment:1 Changed 9 years ago by vallon

Sorry ... just noticed that #1079 is tracking webseeds not respecting bandwidth controls.

comment:2 Changed 9 years ago by vallon

Similar bandwidth overflow on Mac v2.77.

Even with Prefs/Bandwidth/Global? bandwidth limits of DownloadRate?=5 and UploadRate?=5, and no SpeedLimit?, the rates are (currently) {down} 330.1 KB/s {up} 0.0 KB/s. Also, the per-torrent settings are default (No Limit Download, No Limit Upload, [x] stay within global bandwidth limits).

Might be important to know that the two torrents are webseeds.

comment:3 Changed 9 years ago by jordan

  • Resolution set to duplicate
  • Status changed from new to closed

comment:4 Changed 9 years ago by x190

tipper's ticket appears to be about high overhead not webseeds.

tipper, please confirm whether or not your test torrent(s) contain webseeds.

comment:5 Changed 9 years ago by tipper

  • Resolution duplicate deleted
  • Status changed from closed to reopened

Hi x190,

  1. I use magnets not torrents files.
  2. I always delete all the trackers that the magnet provides and replace them with these udp-only trackers:

&tr=udp%3A%2F%2Ftracker.publicbt.com%3A80&tr=udp%3A%2F%2Ftracker.openbittorrent.com%3A80&tr=udp%3A%2F%2Ftracker.1337x.org%3A80%2Fannounce&tr=udp%3A%2F%2Ftracker.istole.it%3A80&tr=udp%3A%2F%2Ffr33domtracker.h33t.com%3A3310%2Fannounce

AFAIK, those udp trackers are not webseeds. Therefore, this bug is not a duplicate of bug #1079.

comment:6 Changed 9 years ago by x190

tipper, do you use a VPN service? In my experience doing so seems to increase network traffic when using Transmission by quite a bit. This would not be a Transmission issue. Over the course of a month and without VPN, I usually see about a 20% overhead. When monitoring network traffic, there's going to be continual spikes, so I think you would need to get a longer term average to be meaningful.

Is this ticket more of an enhancement request to be able to limit the total of P2P data exchange plus overhead?

comment:7 Changed 9 years ago by tipper

Hi x190. I do not use a VPN service.

Bug vs enhancement ? I guess. It depends on the developers opinion on how Transmission should behave.

comment:9 Changed 9 years ago by jordan

I would expect to see moderate overhead, as the speed limits only apply to piece data. DHT, scrapes, announces, and protocol overhead are not counted in the speed limits.

That said, I'm not seeing anything like the behavior described in comment:2 where up, down speed limits capped at 5 kB/s still yield 300+ kB/s. My first suspicions are that there might be something going on with (1) webseeds, (2) one or more torrent's settings was toggled to ignore the global speed limits, (3) the global speed limits are misconfigured, (4) maybe a blocklist is being downloaded while you're measuring speed limits, etc.

If you are able to reproduce this behavior in a reproducible way on a clean configuration with a well-known torrent that we can all test with, such as http://releases.ubuntu.com/13.04/ubuntu-13.04-desktop-i386.iso.torrent, please let me know.

comment:10 Changed 9 years ago by x190

Ticket Summary: upload cap example: 15 kilobytes -> overflows to 15-30 (30 is the contracted ISP limit) download cap example: 200 kilobytes -> overflows to 200-300 (300 is the contracted ISP limit) This would be basically my observation as well, but only as spikes. However, I guess those regular spikes would be enough to interfere with the usability of other internet applications for some users. Pretty hard to control that behavior, I guess.

Ticket Summary: Programs such as gtk-gnutella allow for specifying both seeding limits and overhead limits.

I wonder how it's done?

comment:11 Changed 9 years ago by jordan

x190, this is a topic we've been over many times, and there are snapshots on launchpad showing Transmission's bandwidth use graphed by time compared to similar bandwidth graphs of Vuze, KTorrent, Deluge, etc... the bottom line is that no app is perfect at this and Transmission is (surprisingly?) better than the others profiled.

So, IMO going over the limit in temporary bursts just goes with the territory, and users wishing to avoid it should use QoS. However the description in comment:2 goes further, saying that Transmission downloads at 330 kB/s when the download speed limit is 5 kB/s. That doesn't sound like a spike to me, which is why I asked for more information about that instance.

comment:12 Changed 9 years ago by x190

comment:2 clearly states that webseeds are involved and thus is totally irrelevant to this ticket.

"Transmission's bandwidth use graphed by time"
How was this measured and was overhead measured as well? A link to the graphs and methodology would be helpful as a future reference.

Version 1, edited 9 years ago by x190 (previous) (next) (diff)

comment:13 Changed 9 years ago by jordan

  • Resolution set to incomplete
  • Status changed from reopened to closed

Closing this ticket as incomplete. If you are able to reproduce this behavior in a reproducible way on a clean configuration with a well-known torrent that we can all test with, such as ​http://releases.ubuntu.com/13.04/ubuntu-13.04-desktop-i386.iso.torrent, please let me know.

x190: as per the measurements/graphs:

HOW TO READ THESE SCREENSHOTS

Each screenshot shows a different BitTorrent client downloading the same Ubuntu ISO torrent with speed capped at 15 KB/s both ways, next to a gnome-system-monitor showing overall network use. As a visual aid I've added a horizontal green line showing the "ideal" of where a constant 15 KB/s would lie on each g-s-m network graph.

If you look at the magnitude and frequency of its deviations from the 15 KB/s goal, you'll see that Transmission actually fares well compared to the competition.

https://launchpadlibrarian.net/55888773/deluge-capped-at-15-up-15-down.png

https://launchpadlibrarian.net/55888856/ktorrent-capped-at-15-up-15-down.png

https://launchpadlibrarian.net/55888861/monsoon-capped-at-15-up-15-down.png

https://launchpadlibrarian.net/55888870/transmission-capped-at-15-up-15-down.png

https://launchpadlibrarian.net/55888935/vuze-capped-at-15-up-15-down.png

Note: See TracTickets for help on using tickets.