polyakov at slyserver.com
Sun May 11 08:49:42 UTC 2008
Jerker Nyberg wrote:
> The machines run Scientific Linux 5.0 with Linux kernel
> 2.6.18-8.1.15.el5. The file system is ext3fs, but I don't think the
> file system matter in this case. (One reason I play with this is for
> learning about distributed parallel file systems, but I side stepped
> into wondering why bittorrent is slower than I thought it should be.)
> I use default setting for rtorrent version 0.8.0 and seed 124 GByte
> data in 56 torrents.
That's RHEL5 clone, right? I've had same problems with disk IO on
CentOS5, also RHEL5 clone.
Please see `iostat -kx 1` output, look at rrqm/s column, to see if it's
actually merging IO requests, mine was not doing it. I solved it by
building custom 188.8.131.52 kernel. I also switched FS type (to reiser4,
after trying xfs and ext3fs), but I think custom kernel did the trick.
> Shouldn't memory usage depend on the number of peers not the
> bandwidth? But I guess there is usually a correlation between the two.
Right, as you usually have one chunk mapped for every peer. At 200
mbit/s and average rate 10 kb/s it's like 2000 connections.
> I will start upp the hashing again (it takes ages - how do I get
> rtorrent to store the hashes?) and see how many peers I get.
You don't need hashing more than once with a proper setup...
More information about the Libtorrent-devel