Arch Linux

Joe_Arch

Member

Registered: 2008-11-27

Posts: 67

rTorrent much slower than Deluge[SOLVED]

I've been trying to configure rTorrent properly, but I must be missing something. I think I'm forwarding ports correctly, since Deluge is getting 10-100X the speed with the same range. I'm encrypting my traffic. I don't know what else it could be. Perhaps one of you guys could take a look at my .rtorrent.rc file and see if I'm unwittingly crippling rTorrent?

# This is an example resource file for rTorrent. Copy to
# ~/.rtorrent.rc and enable/modify the options as needed. Remember to
# uncomment the options you wish to enable.

# Maximum and minimum number of peers to connect to per torrent.
#min_peers = 40
max_peers = 52

# Same as above but for seeding completed torrents (-1 = same as downloading)
#min_peers_seed = 10
max_peers_seed = 50

# Maximum number of simultanious uploads per torrent.
max_uploads = 8

# Global upload and download rate in KiB. "0" for unlimited.
download_rate = 0
upload_rate = 0

# Default directory to save the downloaded torrents.
directory = /home/joe/torrents/

# Default session directory. Make sure you don't run multiple instance
# of rtorrent using the same session directory. Perhaps using a
# relative path?
session = /home/joe/.session/

# Watch a directory for new torrents, and stop those that have been
# deleted.
#schedule = watch_directory,5,5,load_start=./watch/*.torrent
#schedule = untied_directory,5,5,stop_untied=

# Close torrents when diskspace is low.
#schedule = low_diskspace,5,60,close_low_diskspace=100M

# Stop torrents when reaching upload ratio in percent,
# when also reaching total upload in bytes, or when
# reaching final upload ratio in percent.
# example: stop at ratio 2.0 with at least 200 MB uploaded, or else ratio 20.0
#schedule = ratio,60,60,"stop_on_ratio=200,200M,2000"

# The ip address reported to the tracker.
#ip = 127.0.0.1
#ip = rakshasa.no

# The ip address the listening socket and outgoing connections is
# bound to.
#bind = 127.0.0.1
#bind = rakshasa.no

# Port range to use for listening.
port_range = 50000-50100

# Start opening ports at a random position within the port range.
#port_random = no

# Check hash for finished torrents. Might be usefull until the bug is
# fixed that causes lack of diskspace not to be properly reported.
check_hash = yes

# Set whetever the client should try to connect to UDP trackers.
#use_udp_trackers = yes

# Alternative calls to bind and ip that should handle dynamic ip's.
#schedule = ip_tick,0,1800,ip=rakshasa
#schedule = bind_tick,0,1800,bind=rakshasa

# Encryption options, set to none (default) or any combination of the following:
# allow_incoming, try_outgoing, require, require_RC4, enable_retry, #prefer_plaintext
#
# The example value allows incoming encrypted connections, starts unencrypted
# outgoing connections but retries with encryption if they fail, preferring
# plaintext to RC4 encryption after the encrypted handshake
#
encryption = allow_incoming,try_outgoing,enable_retry

# Enable DHT support for trackerless torrents or when all trackers are down.
# May be set to "disable" (completely disable DHT), "off" (do not start DHT),
# "auto" (start and stop DHT as needed), or "on" (start DHT immediately).
# The default is "off". For DHT to work, a session directory must be defined.
# 
 dht = auto

# UDP port to use for DHT. 
# 
# dht_port = 6881

# Enable peer exchange (for torrents not marked private)
#
peer_exchange = yes

#
# Do not modify the following parameters unless you know what you're doing.
#

# Hash read-ahead controls how many MB to request the kernel to read
# ahead. If the value is too low the disk may not be fully utilized,
# while if too high the kernel might not be able to keep the read
# pages in memory thus end up trashing.
#hash_read_ahead = 10

# Interval between attempts to check the hash, in milliseconds.
#hash_interval = 100

# Number of attempts to check the hash while using the mincore status,
# before forcing. Overworked systems might need lower values to get a
# decent hash checking rate.
#hash_max_tries = 10

Last edited by Joe_Arch (2009-03-12 23:49:43)

muczyjoe

Member

From: Szeged (Hungary)

Registered: 2007-05-16

Posts: 45

Website

Re: rTorrent much slower than Deluge[SOLVED]

download_rate = 0
upload_rate = 0

You don't limit upload speed. You should set speeds, as you set in deluge.

tjwoosta

Member

Registered: 2008-12-18

Posts: 453

Re: rTorrent much slower than Deluge[SOLVED]

rtorrent is actually the fastest torrent client that ive ever used in linux

my first advice is to read the wiki (if you havn't already)

http://wiki.archlinux.org/index.php/Rtorrent

next i suggest you read this awesome info about optomizing bittorrent connections  (it may all seem like old news at first glance, but just give it a quick read and i think you might learn some things)

http://torrentfreak.com/optimize-your-B … oad-speed/

lastly i will share my rtorrent config file 

keep in mind that your settings should be different depending on your bandwidth, port, etc ( its all in that last link)

so here is my bandwidth results at speakeasy speed test

Last Result:
Download Speed: 2852 kbps (356.5 KB/sec transfer rate)
Upload Speed: 703 kbps (87.9 KB/sec transfer rate)

and here is my config

# This is an example resource file for rTorrent. Copy to
# ~/.rtorrent.rc and enable/modify the options as needed. Remember to
# uncomment the options you wish to enable.

# Maximum and minimum number of peers to connect to per torrent.
#min_peers = 40
max_peers = 85

# Same as above but for seeding completed torrents (-1 = same as downloading)
#min_peers_seed = 10
max_peers_seed = 35

# Maximum number of simultanious uploads per torrent.
max_uploads = 12

# Global upload and download rate in KiB. "0" for unlimited.
download_rate = 340
upload_rate = 65

# Default directory to save the downloaded torrents.
directory = /home/common/Torrents/Downloads

# Default session directory. Make sure you don't run multiple instance
# of rtorrent using the same session directory. Perhaps using a
# relative path?
session = /home/awesome/.session

# Watch a directory for new torrents, and stop those that have been
# deleted.
#schedule = watch_directory,5,5,load_start=./watch/*.torrent
#schedule = untied_directory,5,5,stop_untied=

# Close torrents when diskspace is low.
schedule = low_diskspace,5,60,close_low_diskspace=100M

# Stop torrents when reaching upload ratio in percent,
# when also reaching total upload in bytes, or when
# reaching final upload ratio in percent.
# example: stop at ratio 2.0 with at least 200 MB uploaded, or else ratio 20.0
#schedule = ratio,60,60,"stop_on_ratio=200,200M,2000"

# The ip address reported to the tracker.
#ip = 127.0.0.1
#ip = rakshasa.no

# The ip address the listening socket and outgoing connections is
# bound to.
#bind = 127.0.0.1
#bind = rakshasa.no

# Port range to use for listening.
port_range = 49173-49173

# Start opening ports at a random position within the port range.
# port_random = no

# Check hash for finished torrents. Might be usefull until the bug is
# fixed that causes lack of diskspace not to be properly reported.
check_hash = yes

# Set whetever the client should try to connect to UDP trackers.
#use_udp_trackers = yes

# Alternative calls to bind and ip that should handle dynamic ip's.
#schedule = ip_tick,0,1800,ip=rakshasa
#schedule = bind_tick,0,1800,bind=rakshasa

# Encryption options, set to none (default) or any combination of the following:
# allow_incoming, try_outgoing, require, require_RC4, enable_retry, prefer_plaintext
#
# The example value allows incoming encrypted connections, starts unencrypted
# outgoing connections but retries with encryption if they fail, preferring
# plaintext to RC4 encryption after the encrypted handshake
#
encryption = allow_incoming,try_outgoing,enable_retry

# Enable DHT support for trackerless torrents or when all trackers are down.
# May be set to "disable" (completely disable DHT), "off" (do not start DHT),
# "auto" (start and stop DHT as needed), or "on" (start DHT immediately).
# The default is "off". For DHT to work, a session directory must be defined.
# 
dht = auto

# UDP port to use for DHT. 
# 
dht_port = 49162

# Enable peer exchange (for torrents not marked private)
#
peer_exchange = yes

#
# Do not modify the following parameters unless you know what you're doing.
#

# Hash read-ahead controls how many MB to request the kernel to read
# ahead. If the value is too low the disk may not be fully utilized,
# while if too high the kernel might not be able to keep the read
# pages in memory thus end up trashing.
#hash_read_ahead = 10

# Interval between attempts to check the hash, in milliseconds.
#hash_interval = 100

# Number of attempts to check the hash while using the mincore status,
# before forcing. Overworked systems might need lower values to get a
# decent hash checking rate.
#hash_max_tries = 10

good luck

Joe_Arch

Member

Registered: 2008-11-27

Posts: 67

Re: rTorrent much slower than Deluge[SOLVED]

Thanks for your help guys. Let's see, I'm

17,999 kb/s down
5616 kb/s up

which means I am 2,250 KB/s down and 702 KB/s up, if I'm doing my math correctly. So I should set my limits to be roughly 2,130 down 560 up? I will do that, and see if it makes a difference. I didn't bother to set limits earlier, since I figured 1.5 kb/s isn't going to choke out my network much

I followed the advice on that optimization link you sent me. Here's my new rc file:

# This is an example resource file for rTorrent. Copy to
# ~/.rtorrent.rc and enable/modify the options as needed. Remember to
# uncomment the options you wish to enable.

# Maximum and minimum number of peers to connect to per torrent.
#min_peers = 40
max_peers = 700

# Same as above but for seeding completed torrents (-1 = same as downloading)
#min_peers_seed = 10
max_peers_seed = 700

# Maximum number of simultanious uploads per torrent.
max_uploads = 70

# Global upload and download rate in KiB. "0" for unlimited.
download_rate = 2130
upload_rate = 560

# Default directory to save the downloaded torrents.
directory = /home/joe/torrents/

# Default session directory. Make sure you don't run multiple instance
# of rtorrent using the same session directory. Perhaps using a
# relative path?
session = /home/joe/.session/

# Watch a directory for new torrents, and stop those that have been
# deleted.
#schedule = watch_directory,5,5,load_start=./watch/*.torrent
#schedule = untied_directory,5,5,stop_untied=

# Close torrents when diskspace is low.
#schedule = low_diskspace,5,60,close_low_diskspace=100M

# Stop torrents when reaching upload ratio in percent,
# when also reaching total upload in bytes, or when
# reaching final upload ratio in percent.
# example: stop at ratio 2.0 with at least 200 MB uploaded, or else ratio 20.0
#schedule = ratio,60,60,"stop_on_ratio=200,200M,2000"

# The ip address reported to the tracker.
#ip = 127.0.0.1
#ip = rakshasa.no

# The ip address the listening socket and outgoing connections is
# bound to.
#bind = 127.0.0.1
#bind = rakshasa.no

# Port range to use for listening.
port_range = 50000-50100

# Start opening ports at a random position within the port range.
#port_random = no

# Check hash for finished torrents. Might be usefull until the bug is
# fixed that causes lack of diskspace not to be properly reported.
check_hash = yes

# Set whetever the client should try to connect to UDP trackers.
#use_udp_trackers = yes

# Alternative calls to bind and ip that should handle dynamic ip's.
#schedule = ip_tick,0,1800,ip=rakshasa
#schedule = bind_tick,0,1800,bind=rakshasa

# Encryption options, set to none (default) or any combination of the following:
# allow_incoming, try_outgoing, require, require_RC4, enable_retry, #prefer_plaintext
#
# The example value allows incoming encrypted connections, starts unencrypted
# outgoing connections but retries with encryption if they fail, preferring
# plaintext to RC4 encryption after the encrypted handshake
#
encryption = allow_incoming,try_outgoing,enable_retry

# Enable DHT support for trackerless torrents or when all trackers are down.
# May be set to "disable" (completely disable DHT), "off" (do not start DHT),
# "auto" (start and stop DHT as needed), or "on" (start DHT immediately).
# The default is "off". For DHT to work, a session directory must be defined.
# 
 dht = auto

# UDP port to use for DHT. 
# 
# dht_port = 6881

# Enable peer exchange (for torrents not marked private)
#
peer_exchange = yes

#
# Do not modify the following parameters unless you know what you're doing.
#

# Hash read-ahead controls how many MB to request the kernel to read
# ahead. If the value is too low the disk may not be fully utilized,
# while if too high the kernel might not be able to keep the read
# pages in memory thus end up trashing.
#hash_read_ahead = 10

# Interval between attempts to check the hash, in milliseconds.
#hash_interval = 100

# Number of attempts to check the hash while using the mincore status,
# before forcing. Overworked systems might need lower values to get a
# decent hash checking rate.
#hash_max_tries = 10

No luck so far, only about 15 KB/s down

EDIT: Ok, 150kB up, 35 kB down. Much better, but still nowhere near Deluge

EDIT 2: EDIT HARDER: Ok this other torrent is 150 down. This is much better. But deluge, on the same torrent, gives me 800 KB down. Grrr...... what the heck is going on?

Last edited by Joe_Arch (2009-03-12 01:06:03)

WhiteMagic

Member

Registered: 2007-03-01

Posts: 85

Re: rTorrent much slower than Deluge[SOLVED]

I had a similar problem which was due to the fact that the ports I used for rtorrent were not passed through my router, after forwarding them to my machine the speed went up significantly. Deluge didn't have the problem since it used UPNP which as far as I know rtorrent doesn't. If you already forward the ports used by rtorrent this won't help.

aelfie

Member

Registered: 2009-02-12

Posts: 5

Re: rTorrent much slower than Deluge[SOLVED]

It seems odd that you are using a port range of 100 and then not using port random.  Are you forcing encryption on deluge?  When downloading with rtorrent are you getting l L and r R connections (on the peers screen under the C in C/RE/LO)?

Joe_Arch

Member

Registered: 2008-11-27

Posts: 67

Re: rTorrent much slower than Deluge[SOLVED]

I had a similar problem which was due to the fact that the ports I used for rtorrent were not passed through my router, after forwarding them to my machine the speed went up significantly. Deluge didn't have the problem since it used UPNP which as far as I know rtorrent doesn't. If you already forward the ports used by rtorrent this won't help.

Hmm, I thought I was forwarding ports correctly, but my logic in that was that deluge also worked. If deluge doesn't need ports forwarded, maybe it's a port forwarding problem. I'll look into that. Maybe I'll set rtorrent to a port I know isn't forwarded and see if performance degrades.

tjwoosta

Member

Registered: 2008-12-18

Posts: 453

Re: rTorrent much slower than Deluge[SOLVED]

http://www.canyouseeme.org/

this link will show you if the port is really open or not

Joe_Arch

Member

Registered: 2008-11-27

Posts: 67

Re: rTorrent much slower than Deluge[SOLVED]

Ok, thanks for the help everyone. First off, aelfie, I switched rtorrent to opening ports at random. As for Deluge, encryption is enabled but not forced. Should it be forced? And rTorrent is giving me mostly l and some L. I see no r or R at all.

tjwoosta: thanks for that link! That's very helpful. So, here is where the plot thickens. That link can't see my ports that I thought I opened (reason: connection timed out). So I went to check my router settings -- Deluge had opened up some ports since I last configured my router! The site didn't recognize those ports (reason: connection refused), but I copied the configuration to open up another port on my router, and this one the site says is good. I started up a fresh torrent with the port I know to be open, and Deluge gets a d/l speed of about 500kB/s. I close deluge and restart the torrent in rTorrent (now aimed at the right port) and....checking now.....790 KB/s.

Hell yeah

So I guess it was just a port forwarding problem. The range I thought I had forwarded wasn't (I told the router to open the range just a bit differently than how deluge set it up).

Thank you so much guys

Ranguvar

Member

Registered: 2008-08-12

Posts: 2,577

Re: rTorrent much slower than Deluge[SOLVED]

If encryption is forced, you lose compatibility with old clients that don't do encryption. There shouldn't be a speed loss, as your / your peers' connections should be the bottleneck _by far_. It's more for getting around annoying ISPs than security - doubt it helps at all with the latter, MoBlock or PeerGuardian would be far more helpful.

Check the Vuze/Azureus wiki page on settings for speed (forgot the exact page title) - it's helpful for all clients, and it's good advice.

aqamar

Member

Registered: 2008-09-01

Posts: 49

Re: rTorrent much slower than Deluge[SOLVED]

http://infinite-source.de/az/az-calc.html

maybe help for the settings of the rtorrent.rc...