Re: Disk cache

MooPolice@xxxxxxxxxxxxxx wrote:
>> Greetings all,
>>
>> I have done some experiments on libtorrent and Transmission, comparing
>> the effectiveness of their client-side caching and download scheduling
>> algorithms.
>>
>> I put the results (with graphs) on Wikipedia at:
>>
>> http://en.wikipedia.org/wiki/BitTorrent_performance
>>
>> I hope that you'll find it a worthwhile read.
>>
>> Regards,
>> Radu.
>>
> 
> Nice work.

Thank you.

> But I think a 1:1 (peer:seed) is the most unrealistic test enviroment.
> I would say that you need at least 100 peers to make such tests
> including a few seeds.
> 
> The only reason my client switches to full allocation mode is then
> a file selection is made (means there is more than one file inside the 
> torrent).
> And because there are several files which will be written to
> and read from more seeking occurs naturally.

I chose this very simple test case, with two expectations:

1. It should be easiest to compare expected behaviour vs. measured
behaviour. In a torrent with 100 peers, and possibly many disjoint
swarms, it's much more difficult to formulate an expected behaviour.

2. It makes it easy to study the upper-bound of a swarm's efficiency. A
bigger swarm would be less efficient than the 1:1 swarm I am using.

I think it's worthwhile improving the ideal case as much as possible,
while not breaking the protocol, of course. I think allowing the torrent
to be more susceptible to failure is unnacceptable. I would aim to at
least maintain the torrent's reliability, while improving the local disk
access efficiency.

If the upper bound were showing very good efficiency, there would be
cause to look into more realistic scenarios, but when the upper bound
shows such poor performance, I don't see what benefit you see to
studying more realistic swarms.

Depending on when you looked at wikipedia, you may have missed a late
addition I made, which is the graph of the unix utility "strings"
running on the same 585MB file. Since "strings" does no seeks, and reads
data sequentially, it is as effective as can be. I included this as a
reference for how I would expect the effectiveness of a torrent client
in a perfect swarm to behave.

There's about 99.5% room for improvement in the ideal 1:1 torrent, but
less than 0.8% in more realistic torrents. Would you not agree that the
biggest bang for the buck is to improve the ideal case first?

I am not familiar with the inner design of the various clients, so maybe
you can help me here; What swarm configuration will allow your clients
to shine (brighter than the 1:1 case :) ) in terms of disk-access
efficiency?

Any comments are welcome.

Radu.




-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642