search

y500 / libtorrent

Automatically exported from code.google.com/p/libtorrent
0 stars 0 forks source link

Download speed regression. 1.0.2 compare to 0.16.16 version. #687

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago 
 We are using libtorrent in our application, a week ago we decided to update libtorrent from 0.16.16 to 1.0.2 version, but there is some problems. 
 if we select to download just first few pieces in torrent, torrent_handle::num_peers and num_seeds stays at value = 10. But old 0.16.16 version shows 50-60 peers/seeds with exactly the same selected pieces to dowload. When we select all pieces to download then seeds growing up to 50-60 as it should be. Can you help us to solve this issue, maybe we must change some settings or something else? 1.0.2 was builded with the same flags as 0.16.16.

Original issue reported on code.google.com by xcdix...@gmail.com on 19 Oct 2014 at 11:47

GoogleCodeExporter commented 8 years ago 
Hello, 

We have the same problem  in our  torrent stream project.

If we need to download   few pieces(parties)  of file  when  use "torrent 
stream method" then peers are not going . 

But if we download standart method all is ok.

This is critical problem for streaming. Please fix it or tell us how to patch.

Original comment by erik.car...@gmail.com on 22 Oct 2014 at 6:52

GoogleCodeExporter commented 8 years ago 
Is the problem that peers are disconnected when you think they shouldn't be? or 
is libtorrent just not connecting to as many peers? (the alerts you get should 
tell you).

could one of you provide logs, ideally logging=verbose 
(TORRENT_VERBOSE_LOGGING)?

what does "peers are not going" mean exactly?

Original comment by arvid.no...@gmail.com on 22 Oct 2014 at 7:29

GoogleCodeExporter commented 8 years ago 
logs 0.16.18 - https://www.sendspace.com/file/ccfn8e
logs 1.0.2 - https://www.sendspace.com/file/tg0jk1

0.16.18 build flags: 

bjam --abbreviate-paths --without-python --disable-deprecated-functions 
toolset=gcc link=static boost=source variant=release dht-support=logging 
deprecated-functions=off logging=verbose upnp-logging=on -j 4 -d+2

1.0.2 build flags:

bjam --abbreviate-paths --without-python --disable-deprecated-functions 
toolset=gcc link=static boost=source variant=release dht=logging 
deprecated-functions=off logging=verbose upnp-logging=on -j 4 -d+2

both versions tested on http://rutracker.org/forum/viewtopic.php?t=4811562 
torrent. During test 1.0.2 shows 0 peers, 0.16.18 - about 20 peers at start.

Original comment by xcdix...@gmail.com on 24 Oct 2014 at 9:48

GoogleCodeExporter commented 8 years ago 
maget link for test torrent:
magnet:?xt=urn:btih:6667809878730F2B950B850324A9BF4306C0FE8C&dn=Poselentsy.2014.
WEBDLRip.by.%d0%94%d1%8f%d0%b4%d1%8f_%d0%9b%d1%91%d1%88%d0%b0.avi&tr=http%3a%2f%
2fbt2.rutracker.org%2fann%3fuk%3dwQK6UnqpJn&tr=http%3a%2f%2fretracker.local%2fan
nounce

Original comment by xcdix...@gmail.com on 24 Oct 2014 at 9:55

GoogleCodeExporter commented 8 years ago 
strange

0.16.18: libtorrent configuration: 
rel_performancetimer_pools_verboselog_resolvecountries_nodeprecate_dht_ext_

1.0.2: libtorrent configuration: performancetimer_nodeprecate_

but build flags are the same, maybe it's the problem?

Original comment by xcdix...@gmail.com on 24 Oct 2014 at 11:39

GoogleCodeExporter commented 8 years ago 
that configuration symbol just capture ABI altering configuration options. I've 
been working on making the ABI more stable, and reduce the configuration 
options altering it (because this is a big source of usability problems).

I'll take a look at the logs and this torrent tonight, thanks!

Original comment by arvid.no...@gmail.com on 24 Oct 2014 at 5:31

GoogleCodeExporter commented 8 years ago 
I can't really reproduce this. From your logs, it looks like all the IPs you 
get from the tracker fail to be connected to. when this happens, can you 
re-announce to the tracker, and does it still fail?

Does this problem happen reliably? and does it work reliably in 0.16.16?

Original comment by arvid.no...@gmail.com on 26 Oct 2014 at 7:21

GoogleCodeExporter commented 8 years ago 
Does this problem happen reliably? yes, it does. Works fine in 0.16.16, but 
1.0.2 fails to connect. Maybe we are using some api that cause this 
disconnects, but 0.16.16 works fine.

Original comment by xcdix...@gmail.com on 27 Oct 2014 at 12:11

GoogleCodeExporter commented 8 years ago 
tested on the same code, but different rasterbar versions.

Original comment by xcdix...@gmail.com on 27 Oct 2014 at 12:12

GoogleCodeExporter commented 8 years ago 
0.16.18 works fine too.

Original comment by xcdix...@gmail.com on 27 Oct 2014 at 12:13

GoogleCodeExporter commented 8 years ago 
If we look at peer 212.74.196.11#28873: new version disconnects with error_code 
'uninteresting upload-only peer', but old version continues to download. Same 
with other peers.

Original comment by xcdix...@gmail.com on 28 Oct 2014 at 3:49

GoogleCodeExporter commented 8 years ago 
One more interesting thing. 0.16.18 version doesn't disconnects from peer if it 
sends to us 'have' responses with pieces that we don't interested in. 
Furthermore, 0.16.18 starts to download pieces from peers that wasn't send 
'have' message with that index. But new version just trust to 'have' responses 
and disconnects with 'uninteresting upload-only peer'. I think there is a main 
problem. You can clearly see it in my attached logs.

Original comment by xcdix...@gmail.com on 29 Oct 2014 at 7:19

GoogleCodeExporter commented 8 years ago 
are you sure your piece or file priorities aren't set to 0? (i.e. not wanted). 
Or perhaps upload_mode is set to true?

when you add these torrents, do you have any resume data that may carry such 
state with it?

you can verify the state of the torrent by calling torrent_handle::status() and 
inspect the torrent_status object returned.

Original comment by arvid.no...@gmail.com on 30 Oct 2014 at 8:19

GoogleCodeExporter commented 8 years ago 
yes, all pieces are set to 0. Just first 10 pieces selected to download. This 
case works fine in 0.16.18. upload_mode = false. Resume data is empty. 
torrent_handle::status() == downloading

Original comment by xcdix...@gmail.com on 30 Oct 2014 at 9:58

GoogleCodeExporter commented 8 years ago 
Seems we have the same problem. Old version (before 1.0.0) connects to more 
numbers peers than new one (after 1.0.0) when torrent downloading partially 
(choosed only some chunks for downloading). I obtained the logs so it's the 
same problem libtorrent disconnets from peers with error 'uninteresting 
upload-only peer'.

Original comment by drizt@land.ru on 7 Nov 2014 at 2:43

GoogleCodeExporter commented 8 years ago 
thanks for the report! I've extended the priority unit test to cover the case 
in the logs and fixed the bug. The fix is commit [10475] in branches/RC_1_0 and 
will soon be in trunk as well. Please let me know if this does not fix the 
issue.

Original comment by arvid.no...@gmail.com on 9 Nov 2014 at 1:00

GoogleCodeExporter commented 8 years ago 
thank you, i will check it soon.

Original comment by xcdix...@gmail.com on 11 Nov 2014 at 1:19