logo       

Re: Disk cache: msg#00004

network.bit-torrent.libtorrent

Subject: Re: Disk cache

Hi, I've been a long time in this mailing list but never got much time
to investigate libtorrent's internals. So, sorry if I say anything
stupid.

On 4/9/06, Arvid Norberg <c99ang@xxxxxxxxx> wrote:

[snipped]


> 1. seeding on a high speed connection will make the hard drive seek a
> lot back and forth, just to do short reads.
>
> 2. downloading on a high speed connection will make the hard drive
> seek a lot back and forth.
>
>
> For 1, one assumption that can be made is that if block 0 is
> requested from a piece, it's very likely that many more blocks from
> that piece will be requested soon. So caching the entire piece at
> once would probably be a good idea.
>
> This is exactly what a normal OS' disk cache does. It reads ahead
> into the cache. So I don't really see any benefit if caching this at
> application level. One possible optimization would be if the disk
> cache could be bypassed so that only one piece was cached (since the
> disk cache in the OS may cache more than the piece we're reading
> from). This would be hard to do, and especially hard to do in a
> platform independent manner.


Although I believe that it isnt worth just for this, I dont think that
making it in a platform independent manner would be very hard. POSIX
and Windows have flags to inhibit OS caches at least.

[snipped]

> Is there any points having a cache at all?

IMHO, it is only possible to answer this with tests and see how better
a cache could perform the I/O operations.
I believe that other assumption could be that rarest blocks could stay
in cache longer too, since they should be requested more often from
peers.
FWIW, Boost reviewed and accepted asio, a library for asynchronous
I/O. It supports only sockets operations for now, but probably soon it
will support files as well, which could have some impact in easy of
use and CPU usage.

BitComet has this statistics in one torrent I'm downloading:

Disk Read Statistics: Request: 38982 (freq: 2.1/s), Actual Disk Read:
2542 (freq: 0.1/s), Hit Ratio: 93.4%
Disk Write Statistics: Request: 9986 (freq: 1.2/s), Actual Disk Write:
184 (freq: 0.0/s), Hit Ratio: 98.1%

It seems like pretty good numbers. Although we cant really know what
Disk Write means here...

>
> thanks.
> --
> Arvid Norberg

best regards,
--
Felipe Magno de Almeida


-------------------------------------------------------
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&kid0944&bid$1720&dat1642


<Prev in Thread] Current Thread [Next in Thread>
Google Custom Search

News | FAQ | advertise