June 2009 BitTorrent Client Shoot-Out

Test torrent: http://www.linuxmint.com/torrent/LinuxMint-7.iso.torrent (697.15 MB)

Methodology: Each client used its default, out-of-the-box settings. The stopwatch began when the LinuxMint torrent was added, and stopped when it finished downloading. The tests were executed one at a time, each right after the previous, to help ensure each test's swarm was roughly the same. uTorrent's test was run on a Windows Vista box; the rest were on Fedora 10 box. Both boxes were connected to the net through the same otherwise-idle router. Of course, a compeletely full test would run each client multiple times in an unchanging swarm. If you have the time, and an immutable swarm, I'd like to hear from you. ;)

Full disclosure: I'm one of the Transmission developers. I didn't skew the tests or results in any way -- If I had, Transmission's upload amount wouldn't've been so bad -- and used a public .torrent so that anyone can retest.

Client GUI? Download
Time
Avg. DL Speed CPU Seconds Used Memory:
RES[1]
Amount
Uploaded
Memory:
VIRT[2]
Memory:
SHR[3]
Seeders and Leechers
known by
the Tracker[4]
Deluge 1.1.6
(Total)[5]
Yes 7m 50sec 1.48 MB/s 0.33.88 78 MB 8.2 MB 955 MB 44 MB 314, 44
Deluge 1.1.6
(Daemon only)[6]
No 7m 50sec 1.48 MB/s 0.23.83 31 MB 8.2 MB 418 MB 26 MB 314, 44
KTorrent 3.2.1 Yes 11m, 9sec 1.04 MB/s 0:47.32 58 MB 1.2 MiB 690 MB 21 MB 308, 48
rTorrent 0.8.4 No Gave up after 20m.
Got 350.4 MB
0.29 MB/s 0:06.55 16 MB Unknown[7] 182 MB 14 MB 298, 49
Transmission 1.71 (GTK+) Yes 8m 5sec 1.44 MB/s 0:12.66 30 MB 128 KB 481 MB 13 MB 323, 48
Transmission 1.71 (Daemon) No 6m, 29s 1.79 MB/s 0:13.82 8.6 MB 896 KB 167 MB 2.8 MB 309, 43
uTorrent 1.8.2 Yes 10m, 29sec 1.06 MB/s Unknown[8] 10.5 MB[9] 58.4 MB Unknown[8] Unknown[8] 250, 35
Vuze 4.2.0.2 +
Java 1.6.0_10
Yes 9m 15sec 1.26 MB/s 1:42.58 38 MB 9.09 MB 1,336 MB 349 MB 287, 54

Winners:

Losers:

Notes:

Footnotes:

  1. RES is Resident size. This is the non-swapped physical memory a task has used.
  2. VIRT is the total amount of virtual memory used by the task. It includes all code, data and shared libraries plus pages that have been swapped out.
  3. SHR is the amount of shared memory used by a task. It simply reflects memory that could be potentially shared with other processes.
  4. Seeder + Leecher counts are included to show that the swarm was mostly homogenous during the tests.
  5. Deluge's latest release, 1.1.8, isn't available prebuilt on my Fedora 10 box. This row shows total CPU and memory use of deluge and deluged.
  6. This is taken from the same test run as the previous row. Deluge and deluged are separate processes so, it's easy to tell how much CPU and memory is used by each.
  7. I forgot to check. :/
  8. I don't know how to measure these on Vista.
  9. Source: Task Manager. I don't know if this is a fair comparison to RES or not.

Screenshots!