headers
Stas Khirman | 9 Dec 2006 10:41
Picon

Perfomance under VC8

(I think that it already had been noticed in this list, but apparently no
specific solution had been suggested.)

Problem: When compiled under VC8 ( VS 2005) with debug support, LibTorrent
consume all available CPU. No similar behavior had been observed for VC7 or
GCC builds.

Discussion: VC8 introduced very extensive ( and expensive) build-in iterator
tests. (Interesting to note - some of these test will be active event in the
release mode -
http://msdn2.microsoft.com/en-US/library/aa985965(VS.80).aspx). As result,
LibTorrent invariant checks became extremely expensive operation ( as called
in every method entry point). However, switching-off boundary tests or
another build-in iterations debug support is not an option, as they are very
helpful to debug. 

Solution: Apparently, the major "CPU hog" is a piece re-count algorithm
inside peer_connection::check_invariant (peer_connection.cpp). I suspect (
didn't check it in depth yet) MS made some memory-optimization in
vector<bool> implementation that results in expensive checked iterator. The
simples fix is to put #ifndef _WIN32 brackets around this portion of code: 

peer_connection::check_invariant()
......
#ifndef _WIN32
		if (t->valid_metadata())
		{
			int piece_count = std::count(m_have_piece.begin()
				, m_have_piece.end(), true);
			if (m_num_pieces != piece_count)
(Continue reading)

Permalink | Reply | 1 comment |
headers
MooPolice | 9 Dec 2006 17:56
Picon
Favicon

Re: Perfomance under VC8

> (I think that it already had been noticed in this list, but apparently no
> specific solution had been suggested.)
> 
> Problem: When compiled under VC8 ( VS 2005) with debug support, LibTorrent
> consume all available CPU. No similar behavior had been observed for VC7 or
> GCC builds.
> 
> Discussion: VC8 introduced very extensive ( and expensive) build-in iterator
> tests. (Interesting to note - some of these test will be active event in the
> release mode -
> http://msdn2.microsoft.com/en-US/library/aa985965(VS.80).aspx). As result,
> LibTorrent invariant checks became extremely expensive operation ( as called
> in every method entry point). However, switching-off boundary tests or
> another build-in iterations debug support is not an option, as they are very
> helpful to debug. 
> 
> Solution: Apparently, the major "CPU hog" is a piece re-count algorithm
> inside peer_connection::check_invariant (peer_connection.cpp). I suspect (
> didn't check it in depth yet) MS made some memory-optimization in
> vector<bool> implementation that results in expensive checked iterator. The
> simples fix is to put #ifndef _WIN32 brackets around this portion of code: 
> 
> peer_connection::check_invariant()
> ......
> #ifndef _WIN32
> 		if (t->valid_metadata())
> 		{
> 			int piece_count = std::count(m_have_piece.begin()
> 				, m_have_piece.end(), true);
> 			if (m_num_pieces != piece_count)
(Continue reading)

Permalink | Reply | 0 comments |
headers
James Longstreet | 10 Dec 2006 23:37
Picon
Favicon

building libtorrent with XCode - undefined symbols

Hello,

I'm attempting to build libtorrent on OS X under XCode.  I've got an  
XCode project for boost, which builds correctly, generating  
libboost.a, libboost_filesystem.a, libboost_date_time.a,  
libbost_thread.a, libboost_regex.a, and libboost_program_options.a.   
I have these included in my libtorrent XCode project.

Linking gives these undefined symbols:

ld: Undefined symbols:
__ZNK10libtorrent3aux12session_impl11listen_portEv
__ZNK10libtorrent3aux12session_impl18extensions_enabledEv
__ZN10libtorrent3aux12session_impl12add_dht_nodeEN4asio2ip14basic_endpoi 
ntINS3_3udpEEE
__ZN10libtorrent3aux12session_impl12find_torrentERKNS_10big_numberE
__ZN10libtorrent3aux12session_impl16close_connectionERKN5boost13intrusiv 
e_ptrINS_15peer_connectionEEE
__ZN10libtorrent3aux12session_impl17connection_failedERKN5boost10shared_ 
ptrIN4asio19basic_stream_socketINS4_2ip3tcpENS4_21stream_socket_serviceI 
S7_EEEEEERKNS6_14basic_endpointIS7_EEPKc
__ZN10libtorrent3aux12session_impl20connection_completedERKN5boost13intr 
usive_ptrINS_15peer_connectionEEE
__ZN10libtorrent3aux12session_impl11add_torrentEPKcRKNS_10big_numberERKN 
5boost10filesystem4pathERKNS_5entryEbi
__ZN10libtorrent3aux12session_impl11add_torrentERKNS_12torrent_infoERKN5 
boost10filesystem4pathERKNS_5entryEbi
__ZN10libtorrent3aux12session_impl11set_peer_idERKNS_10big_numberE
__ZN10libtorrent3aux12session_impl12add_dht_nodeERKSt4pairISsiE
__ZN10libtorrent3aux12session_impl12get_torrentsEv
(Continue reading)

Permalink | Reply | 2 comments |
headers
Arvid Norberg | 11 Dec 2006 02:11
Picon
Picon
Favicon

Re: building libtorrent with XCode - undefined symbols


On Dec 10, 2006, at 23:37, James Longstreet wrote:

> Hello,
>
> I'm attempting to build libtorrent on OS X under XCode.  I've got an
> XCode project for boost, which builds correctly, generating
> libboost.a, libboost_filesystem.a, libboost_date_time.a,
> libbost_thread.a, libboost_regex.a, and libboost_program_options.a.
> I have these included in my libtorrent XCode project.
>
> Linking gives these undefined symbols:
>
> ld: Undefined symbols:
> __ZNK10libtorrent3aux12session_impl11listen_portEv
> [...]
> I can't tell from the mangled names exactly what it's not finding,
> but it appears to be missing some boost stuff.  Any suggestions?

It looks like you forgot to include libtorrent/src/session_impl.cpp  
in your project.

Did you try the project file in cvs head?

--
Arvid Norberg

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
(Continue reading)

Permalink | Reply | 1 comment |
headers
James Longstreet | 12 Dec 2006 02:53
Picon
Favicon

Re: building libtorrent with XCode - undefined symbols


On Dec 10, 2006, at 7:11 PM, Arvid Norberg wrote:

> It looks like you forgot to include libtorrent/src/session_impl.cpp
> in your project.
>
> Did you try the project file in cvs head?

Ah.  Didn't realize there was one in CVS, been a while since I updated.

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Permalink | Reply | 0 comments |
headers
Stas Khirman | 12 Dec 2006 22:38
Picon

Removed torrent_handle::metadata() ?

I just realized that current CVS version has removed
torrent_handle::metadata() method. On the other hand, you keep
torrent_handle::has_metadata(). What was a reason? 

Stas

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Permalink | Reply | 1 comment |
headers
Florin Braghis | 12 Dec 2006 22:45
Picon

Max Torrents, Max Connections, Url-Seeds

Hi, 
I was wondering - what happens when max_connections is reached and a new torrent is added to the session ? 

I have not checked it, but it seems that if many torrents (50+) are active and a new torrent is added,
libtorrent refuses to connect to new peers and uses just the url seed (new torrents have a url seed).

About url-seeds:

There are two ideas I was thinking of:
- In order to decrease load on the url-seed, it would be nice if libtorrent dropped the url-seed when enough
seeds are available (eg. 10+) in the swarm.

- It would be interesting to have a max-block-size for the url-seed. On fast connections (10Mbps or more),
256 or 512kb blocks are too small and put stress on the url-seed, by creating additional http requests /
connections. 
Currently, max-block-size is the same for url seeds and peers and most clients don't accept blocks larger
than 512kb. 

Thanks, 

Florin

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Permalink | Reply | 1 comment |
headers
Arvid Norberg | 13 Dec 2006 15:26
Picon
Picon
Favicon

Re: Removed torrent_handle::metadata() ?


On Dec 12, 2006, at 22:38, Stas Khirman wrote:

> I just realized that current CVS version has removed
> torrent_handle::metadata() method. On the other hand, you keep
> torrent_handle::has_metadata(). What was a reason?

The reason why metadata() was removed is because the peer_connection  
was re-factored to separate the metadata extension into a plugin  
using the new plugin interface. This resulted in the actual metadata  
to be moved into the extension (since it is only used by that  
extension). The way to get the equivalent metadata from a handle now  
is to generate it from the torrent_file(). i.e.

std::vector<char> metadata;
entry info = h.get_torrent_info().create_torrent()["info"];
bencode(std::back_inserter(metadata), info);

To some extent the peer_connection (and dependencies) still need to  
be aware if there actually is any metadata, and function without it.  
So has_metadata() still makes sense. At least now it's possible to do  
another plugin that receives the metadata (from azureus dht for  
example).

--
Arvid Norberg

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
(Continue reading)

Permalink | Reply | 0 comments |
headers
Arvid Norberg | 13 Dec 2006 15:32
Picon
Picon
Favicon

Re: Max Torrents, Max Connections, Url-Seeds


On Dec 12, 2006, at 22:45, Florin Braghis wrote:

> Hi,
> I was wondering - what happens when max_connections is reached and  
> a new torrent is added to the session ?

all torrents are supposed to have at least 2 connections reserved for  
them, if (num_torrents * 2 < max_connections) then the connection  
count will exceed the limit. There's a allocate_resources() function  
that is responsible for balancing out the number of connections  
allowed between the torrents.

> I have not checked it, but it seems that if many torrents (50+) are  
> active and a new torrent is added, libtorrent refuses to connect to  
> new peers and uses just the url seed (new torrents have a url seed).
>
> About url-seeds:
>
> There are two ideas I was thinking of:
> - In order to decrease load on the url-seed, it would be nice if  
> libtorrent dropped the url-seed when enough seeds are available  
> (eg. 10+) in the swarm.

This is something I've been thinking about as well. There are many  
different kinds of conditions one can think of, download speed from  
non-http-seeds for example.

> - It would be interesting to have a max-block-size for the url- 
> seed. On fast connections (10Mbps or more), 256 or 512kb blocks are
(Continue reading)

Permalink | Reply | 0 comments |
headers
Oliver Jetter | 14 Dec 2006 01:34
Picon
Picon

Problem to run DHT mode

Hello,

I tested the LibTorrent "client_test" in tracker mode and everything worked
fine. After that I wanted to test LibTorrent "client_test" in trackerless
DHT mode and I wasn't able to run it till now.
My situation is a little bit special one as I try to run the DHT and
BitTorrent network within our local LAN for research reasons. So I adapted
the source code and added a local IP address as bootstrap node. When
starting several instances on one computer with different ports (some seeds
and some lechers), the DHT is created correctly and all nodes join the DHT.
But whenever a node tries to announce for the torrent I get the error
"invalid incoming packet: invalid size of info-hash".
I had a closer look at it but couldn't find anything to solve the problem
till now. The size of the invalid info-hash is 40. When I log the info-hash
to the log files the invalid info-hash is represented as string (e.g.:
b9d1e1ffcf739953ddb315f89c8011d5d6686853) but all others ids are represented
as binary data.
Has anyone an idea what happens?
Thanks for any response.

Thanks,

Oliver

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
(Continue reading)

Permalink | Reply | 1 comment |

Gmane