Update, May 2010: Patch applicable to rtorrent 0.8.6/0.12.6
Normally rtorrent randomize start of next chunks download position every 64 downloaded chunks (randomize routine). Simply alter this random distribution to be less random. I don't recommend to fix this start position to value 0, as it has negative effects. Avi file has some important data at the end of file, so video player will complain that file is corrupted and you will not be able to seek in this file (while downloading). Also if you have more peers, you will waste bandwidth by downloading same chunk from them.
First, in case ready to download chunk has invalid position (this is default from start), modify this position to be random, but close to position 0. Next, after each randomize routine, this patch will modify download position to value 0 in five from seven times. One times from seven, it will start from the almost end of file (to download avi index). And one times from seven it will start download from random position. From my observations it seems, that its enough to not download same chunk from peers.
Patch is here:
--- libtorrent-0.12.5/src/download/chunk_selector.cc 2009-05-13 15:10:13.000000000 +0200
+++ libtorrent-0.12.5.new/src/download/chunk_selector.cc 2009-12-22 16:38:50.000000000 +0100
@@ -79,13 +79,14 @@
m_sharedQueue.clear();
if (m_position == invalid_chunk)
- m_position = random() % size();
+ m_position = (random() % size()) / 10;
advance_position();
}
uint32_t
ChunkSelector::find(PeerChunks* pc, __UNUSED bool highPriority) {
+ int tmp;
// This needs to be re-enabled.
if (m_position == invalid_chunk)
return invalid_chunk;
@@ -100,8 +101,28 @@
// Randomize position on average every 16 chunks to prevent
// inefficient distribution with a slow seed and fast peers
// all arriving at the same position.
- if ((random() & 63) == 0) {
- m_position = random() % size();
+
+ if ((random() & 31) == 0) {
+
+ tmp = random();
+ switch( tmp % 7 ) {
+ case 0:
+ case 1:
+ case 2:
+ case 3:
+ case 4:
+ m_position = 0;
+ break;
+ case 6:
+ m_position = size() - 20;
+ if (m_position > 0) {
+ break;
+ }
+ default:
+ m_position = tmp % size();
+ break;
+ }
+
queue->clear();
}
Result (there are still some chunks, which are not dowloaded as soon as possible - red arrows, deeper investigastion needed). They are downloaded few minutes later (after few randomize routines). But hey ItWorksForMe(tm):
Thats realy what i was looking for!! In new stable 0.8.9, there is implemented that first and last chunks have higher priorities but this does even more.
ReplyDeleteFor my project, I just commented out:
// if ((random() & 63) == 0) {
// m_position = random() % size();
// queue->clear();
// }
and changed:
if (m_position == invalid_chunk)
m_position = random() % size();
advance_position();
}
to
if (m_position == invalid_chunk)
+m_position;
advance_position();
}
Like that, you get the chunks in a row :)
It works for me because i just have one seeder, if you have more, it is probably not the best solution when you have a look at the comments why they do the randomization:
// Randomize position on average every 16 chunks to prevent
// inefficient distribution with a slow seed and fast peers
// all arriving at the same position.
But thanks anyway for the hint, it helped me a lot!
Hi Anon,
ReplyDeletethanks for comment. Actually I was trying pure linear download, but as you said, it had negative effects with more than one seeds/peers. Also I wouldnt recommend to not have at least few random start positions on private trackers, as there could be some sort of detection :)