Poor performance on a private GigE network.

[BillBroadley]

I'm distributing 30-60GB directories to 40-220 servers in support of reseach related simulations.

I'm using 10.9.*.* for this network. I tried unsuccessfully to use trackerless torrents and DHT, but didn't succeed. I'm interested in any info related to that if anyone has it working.

So I installed opentracker, ctorrent, and transmission-2.52.

Just to test I had everything working I ran:

Code: Select all

server$ transmission-create -o transmission.torrent -c "test of transmission" -t http://10.9.0.1:6969/announce data

Then ran a tracker:

Code: Select all

$ ./opentracker -i 10.9.0.1 -A 10.9.0.1

Then setup a seed:

Code: Select all

server$ ctorrent transmission.torrent 

Then tried a client:

Code: Select all

client$ ctorrent transmission.torrent 
...
Announce: http://10.9.0.1:6969/announce
...
Download complete.

Said download of 2GB takes a few seconds to get going and peaks around 95MB/sec and finishes in 24 seconds or so.

Now if I seed with transmission:

Code: Select all

server$ transmission-daemon -a 10.9.0.1 --no-dht --no-lpd --no-utp --no-portmap -i 10.9.0.1 -f -w .
server$ transmission-remote 10.9.0.1 -a ./transmission.torrent --debug --no-portmap --no-dht --no-utp --no-pex --no-lpd -w .

Then on the client:

Code: Select all

client$ transmission-daemon --no-dht --no-lpd --no-utp --no-portmap -f -w .
client$ transmission-remote 127.0.0.1 -a /tmp/transmission.torrent --debug --no-portmap --no-dht --no-utp --no-pex --no-lpd -w . -c incoming

The result takes 280 seconds:

Code: Select all

[17:38:55.135] data Queued for verification (verify.c:260)
[17:43:38.412] data State changed from "Incomplete" to "Complete" (torrent.c:2042)

I was a bit surprised to see transmission some 11-12 times slower.

Any recommendations for speeding up transmission?

I tried adding cache with -e 1024, but it didn't seem to help. Still over 10x slower, around 8MB/sec:

Code: Select all

client$ transmission-remote 127.0.0.1 -t all  -i | egrep "Download Speed|Percent D"
  Percent Done: 86.9%
  Download Speed: 8.37 MB/s

Does transmission assume max network speed is 10Mbit?

[rb07]

You're missing all the speed limit options, I'm not sure but I think in that case transmission-daemon uses some defaults which are set at 100 KiB/s (both upload & download).

You can check that with 'transmission-remote -si', the last few lines tell you if the speed is limited, and to what.

You can change the limits, or disable them, with either transmission-remote (on a running daemon), or with parameters when starting the daemon (that's why we usually have a start-up script, to set all the options to something sane for our environment).

[BillBroadley]

Code: Select all

server$ transmission-remote -si

LIMITS
  Peer limit: 240
  Default seed ratio limit: Unlimited
  Upload speed limit: Unlimited  (Disabled limit: 100 kB/s; Disabled turtle limit: 50 kB/s)
  Download speed limit: Unlimited  (Disabled limit: 100 kB/s; Disabled turtle limit: 50 kB/s)

client$ transmission-remote 127.0.0.1 -si

LIMITS
  Peer limit: 240
  Default seed ratio limit: Unlimited
  Upload speed limit: Unlimited  (Disabled limit: 100 kB/s; Disabled turtle limit: 50 kB/s)
  Download speed limit: Unlimited  (Disabled limit: 100 kB/s; Disabled turtle limit: 50 kB/s)

I'm all for a startup script/configuration file... once things are working. Looks like I might well be hitting the bug/ticket #4402 mentioned above. Is updating to the current subversion repo likely to help? Is the patch in #4402 likely to still apply to the current stable release 2.52?

[rb07]

Is updating to the current subversion repo likely to help?

No.

Is the patch in #4402 likely to still apply to the current stable release 2.52?

Looks too old, so let's try:

Code: Select all

$ patch -p0 -i overflow-2.diff 
patching file libtransmission/peer-io.c
Hunk #1 succeeded at 978 (offset -1 lines).
patching file libtransmission/torrent.h
patching file libtransmission/peer-msgs.c
Hunk #1 succeeded at 1676 (offset 1 line).
patching file libtransmission/bandwidth.c
Hunk #5 succeeded at 301 (offset -4 lines).
Hunk #6 succeeded at 343 (offset -4 lines).
Hunk #7 succeeded at 361 (offset -4 lines).
Hunk #8 succeeded at 373 (offset -4 lines).
patching file libtransmission/peer-io.h
patching file libtransmission/bandwidth.h
patching file libtransmission/peer-mgr.c
Hunk #2 succeeded at 3037 (offset -1 lines).
patching file libtransmission/webseed.c
Hunk #1 succeeded at 512 (offset 3 lines).
Hunk #2 succeeded at 522 (offset 3 lines).
patching file libtransmission/webseed.h
patching file libtransmission/transmission.h
Hunk #1 succeeded at 652 (offset 1 line).
Hunk #2 succeeded at 663 (offset 1 line).
Hunk #3 succeeded at 1227 (offset 1 line).
patching file libtransmission/session.c
patching file libtransmission/session.h
patching file libtransmission/torrent.c
patching file gtk/details.c

It did patch fine, now I would be interested to know if it solves your problem...

[BillBroadley]

Upon closer inspection it looks like #4402 was only triggered if you were using up/download limits. I'm not.

I applied the patch, it looked to apply cleanly.

I did a make clean, make, make install.

I verified that which transmission-daemon/remote found binaries with current datestamps (to insure I'm not mistakenly using the old binaries.)

No improvement:

Code: Select all

 
  Download Speed: 8.37 MB/s
  Download Speed: 8.37 MB/s
  Download Speed: 8.37 MB/s
  Download Speed: 7.32 MB/s
  Download Speed: 7.00 MB/s
  Download Speed: 6.37 MB/s
  Download Speed: 6.61 MB/s
  Download Speed: 6.87 MB/s
  Download Speed: 7.43 MB/s
  Download Speed: 7.79 MB/s
  Download Speed: 4.19 MB/s

Using rtorrent takes 22 seconds to download 2048MB (93MB/sec) and another 8 seconds to verify the checksums.

Ctorrent numbers are similar (and mentioned above). So it seems like the linux kernel, disk system, and network are pretty healthy.

If anyone wants to try to replicate this you just need 2 machines on a GigE switch:

Code: Select all

$ mkdir data
$ cd data
$ for i in `seq 1 8`; do dd if=/dev/urandom of=$i bs=16384 of=16384; done # create 8 256MB files.
$ cd ..
$ transmission-create -o transmission.torrent -c "test of transmission" -t http://10.9.0.1:6969/announce data # or suitable IP for tracker.

[BillBroadley]

Yes, but that was version 2.33, maybe there's been a regression since then.

Rtorrent, ctorrent, and a some tweaks I made to an example in libtorrent-rasterbar all get 90MB/sec or so.

Seems unlikely it's part of my environment, but I'd be happy to provide extra testing or information if it would be helpful.