[bittorrent] IO bound
joris.guisson at gmail.com
Thu Apr 12 14:16:37 EDT 2007
On 4/12/07, Carsten Otto <c-otto at gmx.de> wrote:
> On Thu, Apr 12, 2007 at 07:05:00PM +0200, Joris Guisson wrote:
> > 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.
> There is no need for a RAM disk, as the client could load everything
> into the RAM or the operating system could cache file accesses.
> The problem is the size of the torrent. A DVD image with about 5 GByte
> does not fit into the RAM of my systems. Seeding a CD image with about
> 700 MByte is no problem. Because of this the torrents for the Debian CD
> images are very slow (for me as an uploader), because other peers
> already served the clients (besides, the download is smaller). There is
> no need to serve small files with high speed, a lot of clients already
> do that :)
Buy more RAM :-)
> > Euhm, why would HAVE messages have any impact upon which chunks are
> > loaded into RAM ?
> I'd modify/create/... the client such that the HAVE messages only
> contains chunks that are loaded.
> 1) Randomly (?) load chunks until the RAM is full
> 2) send HAVE message with _only_ these chunks
> 3) Based on some criteria free the RAM and start at 1)
This would have to be done for each peer individually to work
effectively. But this is possible. And you would have to make sure
that you can use one chunk as much as possible at the same time.
If you can send chunk X to a group of peers at the same time by
sending the HAVE for X to those peers at the same time, you only have
to keep it loaded until all peers in the group have downloaded it.
This is certainly a lot more efficient then each client in that group
asking for the chunk at a random moment in time (when there is a good
chance it isn't in memory). It would cut down the number of 'cache
misses' a lot, to borrow a term from the CPU world.
More information about the BitTorrent