[bittorrent] IO bound
joris.guisson at gmail.com
Thu Apr 12 13:05:00 EDT 2007
On 4/12/07, Carsten Otto <c-otto at gmx.de> wrote:
> Hi there!
> My university has a 10 GBit/sec connection where I have access to (at
> least) 1 GBit/sec. My experiments with various PCs and Bittorrent
> clients indicate that the speed is dominated by the power of the
> underlying disk system. Our FTP server has the same problem, 12 disks in
> a RAID 5 (old 3Ware controller) only delivers about 25-30 MByte/sec
> via FTP and HTTP (many different users, higher peeks possible).
> With a newer but smaller RAID system I can get 11 MByte/sec with
> bittorrent, older systems top at around 6 MByte/sec. I'd be happy to
> push Debian with more than (aggregated) ~15 MByte/sec.
Wow, I want that kind of bandwith
> Long story short, delivering torrents from the disk is no good solution
> for me. Buying lots of RAM unfortunately is no solution, neither.
> Is there a client or at least some well-thought algorithm that solves
> this problem?
Ramdisk maybe ? Create a ramdisk and copy the data in there, then
import with your preferred client. That way there is no disk involved
at all, and your biggest bottleneck is gone.
> One idea is to fake the message telling other clients what my client
> has. This way I could offer as many chunks as my RAM can take, after a
> while (when speed drops? constant time? other criteria?) the RAM is
> refilled with other chunks. Of course every kind of fake is no good idea
> in general, but for torrents where additional speed can help the "real"
> seeders this should be OK.
Euhm, why would HAVE messages have any impact upon which chunks are
loaded into RAM ?
> As a modification one could try to find out which chunks are needed
> most, but according to a discussion from 2004 and several other reasons
> this seems to be impractical.
Most clients probably download the rarest chunks first, those might be
the ones you want to keep into memory.
> Feel free to write your opinion, even if you dislike this idea :)
> PS: Of course it is possible to use the disk with a second client on the
> same machine, so that one client offers "little" (< 2 GByte) very fast
> (out of RAM), the other client has everything from disk, but is slower.
> Carsten Otto
> c-otto at gmx.de
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
> -----END PGP SIGNATURE-----
> BitTorrent mailing list
> BitTorrent at lists.ibiblio.org
More information about the BitTorrent