I, too, have noticed that sometimes KTorrent would not connect to nearly as many peers as it recognizes exists, while Azureus or uTorrent would.

I've been in swarms with 20 seeds where Azureus would connect to 18 or more, while KTorrent would only connect to 1 or 2.

Why isn't KTorrent trying to connect with more?

Dunno, but on torrents for kubuntu, when there aren't any leechers yet and it's basicly the (bittornado?) tracker is the only one seeding here, KTorrent can' t make a connection to the seeding tracker.(i think it showed up as three seeding sources instead of just one) It comes with authentication failures while other peers are done in a sec. Maybe this is caused by the same problem?

stoeptegel wrote:Dunno, but on torrents for kubuntu, when there aren't any leechers yet and it's basicly the (bittornado?) tracker is the only one seeding here, KTorrent can' t make a connection to the seeding tracker.(i think it showed up as three seeding sources instead of just one) It comes with authentication failures while other peers are done in a sec. Maybe this is caused by the same problem?

I will take a look at this tracker, I will see if I can run one locally. From the sound of things there are some clients we somehow not connect properly to.

I have also noticed that azureus announces a couple of times in a row at the start of a torrent, each time with a couple of minutes in between, probably to get enough peers. Maybe we should do that to ?

George wrote:I have also noticed that azureus announces a couple of times in a row at the start of a torrent, each time with a couple of minutes in between, probably to get enough peers. Maybe we should do that to ?

I didn't felt much for it in another topic recently, but that was because it was heading in a thought of maximizing the number of connections.
I dunno, it really depends on the kind of peers in swarm how much peer are needed to get effective, and also how many sources the tracker supplies, which sometimes really isn't that much. Announcing 5, 5 and 10 minutes and stopping earlier when we detect we have enough sources (comparing the scrape data with current connections, 50% limit?) would be ideal i think.

Well, I guess NO, it isn't how many clients we are connected to per se, but IIRC Azureus has an algorithm for swapping out clients who are transferring slowly (or not at all) to try others, and keeping track of who the fastest peers are. Perhaps such a weighting system, or swap peers if speed below X would be good for ktorrent, too.

This problem is illustrated again by http://torrent.fedoraproject.org/torren ... torrent.... On the FC6 torrent, I am connected to like 6 of 300 or so seeds, and 100 or so peers, for a speed of 50 down / 30 up, while uTorrent and Azureus quickly establish connections to more than 50 seeds for 300-400down.

Also, if I manually announce to the tracker at more aggressive intervals, each announce delivers like 10 or so new peer connections, and a slight speed improvement (or a big one, if I hit the jackpot and get a peer with lots of upload potential)... It shouldn't really take bombardment of the tracker to attempt these connections, should it?

edit. nm.

Also, if I manually announce to the tracker at more aggressive intervals, each announce delivers like 10 or so new peer connections, and a slight speed improvement (or a big one, if I hit the jackpot and get a peer with lots of upload potential)... It shouldn't really take bombardment of the tracker to attempt these connections, should it?

Well, you're right. I'm not sure how AZ manages peers, though. I've seen some log messages concerning caching peers or something. Maybe we could check out what they really do there.

Though, more/less AZ and uT probably get more peers via DHT and PEX. KT and both other mentioned clients send tracker request for ~100 peers. Tracker sends them back and that's it.

If you turn off DHT and PEX in both clients (KT and AZ) and try to download the same torrent what happens? Is there a big difference in number of connected peers?

Even without PEX and DHT, these two clients do a better job of connecting to peers than KTorrent, and manage to obtain faster speeds more often than KTorrent.... With KTorrent, it's more of gambling.... after a few start-stop cycles and connecting to a different set of peers, it can match Azureus/uTorrent speeds... but the other two clients do it much more consistently.

I think that while PEX is important and certainly a factor, there's some algorithm difference between how we connect to peers, and that's causing more of the difference.

What i find weird is that this bug only seems to apply to public torrents where lots of leechers are in swarm. With the so called private torrents which more often have way less leechers than the publics, KTorrent connects to almost all peers and speed is just on par with AZ and uT.

It's almost like we're running into a wall of peers who are already on the max incoming connection limit, are therefore don't want to connect to us. Though this wouldn't explain why AZ and uT do a better job, connection-wise.

jdong wrote:This problem is illustrated again by http://torrent.fedoraproject.org/torren ... torrent.... On the FC6 torrent, I am connected to like 6 of 300 or so seeds, and 100 or so peers, for a speed of 50 down / 30 up, while uTorrent and Azureus quickly establish connections to more than 50 seeds for 300-400down.

I have tried this torrent without DHT. I get to 40 with the first announce, the second increases the number to 60. Third announce gets me over 90 peers. Azureus seems to get less peers on the same torrent, it only got to 15 after the first announce.

Seeders / Leechers seem to be distributed pretty equally.

This is with the current SVN version.

EDIT: I tried it with another torrent with 6000 leechers and 3000 seeders and after the first announce I only get to 13 leechers.

Y'all are just complaining that ktorrent doesn't help you leech as much as Azureus does? You don't get my sympathy... The concept of bittorrent falls over when you don't maintain a 1:1 ratio. Ktorrent maintains a 1:1 ratio in my experience.

However, in light of some recent findings, people having trouble with download speeds might also try turning off encryption (it seems a bit broken)

Ktorrent maintains a 1:1 ratio in my experience.

And it takes waaay to long to do so.

George wrote:EDIT: I tried it with another torrent with 6000 leechers and 3000 seeders and after the first announce I only get to 13 leechers.

That's why it's weirdness full glory. On one swarm it works just ok, while on another one we have significiant problems to get going. For what i can see, the bigger the swarm the bigger the problem.

I have had an idea that this could be the allowed fast feature. This feature is part of the fast extensions and allows you to tell clients that they can allways download some chunks from you, no matter if you choked them.

This has more or less disappeared from the fast extensions spec, don't know why.

It could be that some peers seeing these allowed fast packets, don't know what it is and drop the connection. In the current SVN version I have disabled this feature.

So if anybody interested can try the current SVN, to see if it still happens with this version. (Note: last weekly snapshot does not contain this change).