headers
Andrew Greig | 2 Nov 12:49

Re: fragmentation

ghrt wrote:
> i have noticed that valknut (and earlier versions, too) seems to 
> unnecessary fragmentate a file which is downloading.
> for example, in a file there are 3 blocks and 2 running downloads.
> when the 3rd download is started, it doesn't begin with the third 
> block, but at a new location in a middle of the others too.
> 
> this makes the downloading lasts longer, because at the end of a small 
> block is stops and tries to connect again, and the others may be busy 
> as well.
> 
> why can't begin at an "unused" start of an existing block? (those 
> three blocks were quite large, each aprox.  200megs)
> 
> thanks
> ghrt

My observation is that when starting additional downloads, Valknut finds the biggest incomplete 
block and starts in the middle of it.  This gives the download as large chunk to get before it needs 
to reconnect for another block.  However its probably not optimal when there is another download 
working on that block, as it 'cuts in front' of the existing download and fragments what was a 
contiguous piece.

Beginning a new download at the start of an existing fragment is probably a good idea, as this would 
tend to 'clean up' smaller fragments first and tackle big chunks later.  This would be the opposite 
of the current method, where the big chunks get started first, leaving many small fragments for the 
'end game' which is the problematic last few percent of the file.  How this would actually effect 
overall download efficiency is hard to judge.

Regards,
(Continue reading)

Permalink | Reply |
headers
ghrt | 2 Nov 13:28
Picon

Re: fragmentation

Pe data de Mar 02 Noi 2004 13:49, a-ţi scris:
> My observation is that when starting additional downloads, Valknut
> finds the biggest incomplete block and starts in the middle of it. 
> This gives the download as large chunk to get before it needs to
> reconnect for another block.  However its probably not optimal when
> there is another download working on that block, as it 'cuts in
> front' of the existing download and fragments what was a contiguous
> piece.

whether is optimal or not depends on the speed of the other download; 
if are of equal speeds middle is the answer, if it's a lower speed 
tail is best, and so on.

i don't know how to pre-determine the speed of the future download 
(the speed setting in client may not be accurate), so it will always 
be a guess. i thing the middle is ok.

what is bad is that, even when exists another "idle" fragment, (little 
or big), this isn't choosed as a starting point.
>
> Beginning a new download at the start of an existing fragment is
> probably a good idea, as this would tend to 'clean up' smaller
> fragments first and tackle big chunks later.  
No tackle big chunks later, what i say is that if there is a chunk 
which is not being downloaded, it could start at its beginning, 
regardless of its size (it could be the biggest cunk left as well).

> This would be the 
> opposite of the current method, where the big chunks get started
> first, leaving many small fragments for the 'end game' which is the
(Continue reading)

Permalink | Reply |

Gmane