Transmission

Yes, small linux can be downloaded by this link. Another strange example:

magnet:?xt=urn:btih:dd69a19900555be4a0bde87a4f10cd83f7e4c1d8

This links shows 60+ seeds, some of them with bogus %% (85000%, for example), but it doesn't start download for 4+ hours. Web interface shows "Magnetized ...

I've added some downloads with magnet links which contains only "btih" shceme -- no file names, no trackers, only info hash, like this one:

magnet:?xt=urn:btih:F89D3F16E27D0D52B99B13896269E911631C8159

And transmission-daemon 2.32 with good external IP doesn't download anything in 6 hours. I know ...

Yep, of course
But I have not time yet top play with it

Latest version (=8.2 what blacklion used for his measurements) supports these fcntl() params may look useful:

F_READAHEAD
Set or clear the read ahead amount for sequential access to
the third argument, arg, which is rounded up to the nearest
block size. A zero value in arg turns off read ahead ...

Are you saying that FreeBSD has no posix_fadvise() API call, or that FreeBSD doesn't have any similar calls (such as an fcntl + F_RADVISE) that could be used instead? The code is in tr_prefetch() at https://trac.transmissionbt.com/browser/trunk/libtransmission/fdlimit.c#L242 and currently has ...

I'll try this change. But I want to note, that calling gettimeofday() / clock_gettime() so often is not have any usefulness even in case where here IS bandwidth management.

Humm...
(1) RPC thread should not be blocked by I/O in other thread -- FreeBSD has true kernel-supported threads, not ...

According to callgrind, bandwidthPulse() is on very top too, most of it inclusive time is made by reconnectPulse() via tr_torrentNext().
makeNewPeerConnections() with calls to getPeerCandidates() and qsort() and comparePeerCandidates().

I've done some ad-hoc profiling of 2.30b4 on FreeBSD 8.2. Please note, it is not a Linux system, but I think, conclusions are common for these systems.

System: Coe2Duo E4500, 4Gb memory, 1GiB Intel NIC, 64-bit system, dedicated router to ISP connection (so, this system doesn't perform any NAT or ...

Yep, I've reverted my fix and added this one -- it works!

I'll repeat profiling of 2.30b4 at this weekend.

2.30b4 works for 10 hours with 12-14% of CPU.

But it is still very unresponsive for GUI ("transmission-remote --list" takes about 30 seconds, Transmission Remote GUI 3.1 sometimes complains about timeouts and reconnects), and it has some problems with trackers: always 2-3 torrents are in state ...

3 hours, massive upload, 13-15% of CPU, no anomalies. Looks good. It spends slightly more than "normal" 2.22, but doesn't start to consume ALL CPU.

Other suspicious evbuffer_pullup() usages (all other usages seems to use evbuffer_get_length() together with evbuffer_pullup()):


daemon/remote.c:1764
fprintf( stderr, "Unexpected response: %s\n", evbuffer_pullup( buf, -1 ) );

libtransmission/announcer-http.c:216
fprintf( stderr, "Announce ...

Now I'm starting experiments with fixed 2.30b4.

This patch helps me:


--- libtransmission/announcer-http.c.orig 2011-04-30 04:58:23.000000000 +0400
+++ libtransmission/announcer-http.c 2011-05-05 14:29:40.000000000 +0400
@@ -115,6 +115,7 @@
evbuffer_add_printf( buf, "&ipv6=");
tr_http_escape( buf, ipv6_readable, -1, true );
}
+ evbuffer_add ...