why is 1.2 so much slower for me?

[splintax]

I'm not having any problems with µT v1.2.

Just the same as all the other versions.

The BitTorrent spec is open. Unless I'm missing something, regular downloads from a regular torrent don't run at faster speeds cos you're using a 'better' client. Some clients may have default settings that are bad for your particular connection, but it's not that that client is worse.

[ReP0]

I'm not having any problems with µT v1.2.

Just the same as all the other versions.

The BitTorrent spec is open. Unless I'm missing something, regular downloads from a regular torrent don't run at faster speeds cos you're using a 'better' client. Some clients may have default settings that are bad for your particular connection, but it's not that that client is worse.

I'm glad that you are not having problems but to answer your question you are really missing something. Software by it's nature is a complex thing. Let me just say that the implementation of the spec is what matters. The spec tells you how what messages clients use to intercommunicate with each other. It does not specify how you code it. So if you have a problem under some use cases in your overall design/implementation if can lead to performance problems where it does not stop the client from working but can lead to speed issues such as some of us have come across. So simply put just because a client follows a spec doesn't imply that all clients will perform at the same speed etc even if you tweaked that clients settings to optimal performance.

[splintax]

Alright. Let me ask you two questions then, since you seem to know what you're talking about.

1. How come my µT works fine if the software is flawed?

2. Shouldn't a poorer implementation result in a less efficient program in terms of CPU/RAM usage, not in terms of download speed? (Excluding the +/- 5 or so KiB/s you might expect from this.)

[chaosblade]

Well if the implementation and behavior of network related code is bad, of course speeds would suffer. I totally believe this isnt the case with uTorrent though, as other users DO achieve superb performance.

[BlackLion]

Well if the implementation and behavior of network related code is bad, of course speeds would suffer. I totally believe this isnt the case with uTorrent though, as other users DO achieve superb performance.

Well said and thank you.

[Kludge]

still consistantly maxxing out (110-115KB/sec down) and 20-22KB/sec upload... AZureus is pretty much a thing of the past now... Used it once the other day to download something with a load of nasty drone peers sending bad data (µTorrent didn't seem to kick these connections (probably not sending bad data because or Protowall v2 running))

Still thumbs up from me!

[boo]

Hmm, yes, the slow speed in µTorrent doesn't appear to all, but still,

many that has correct settings has reported this =

* slow speed

* shifting speed (1.2)

* there are many seeds and peers, but you can't connect to anyone.

So something must be wrong somewhere.

[ColdArmor]

I think it is a little better 1.2.1 BETA (Get it on the Download Page - http://utorrent.com/download.php) Out of 3 torrents my speeds were pretty okay... still really jumpy though.

[Kludge]

Grabbing 121Beta now and will continue to test... Been doing a bit of observative work on torrents that work EXTREMELY well in AZ, but very poorly in uTorrent 1172/12. I have noticed that in both cases the tracker has handed out very few peers to me, but AZureus excels in download speed, mainly because of the amount of peers it acquires by Peer Exchange...

Im sure i read, that this is in the works for µTorrent, which is excellent... BUT only one thing... There is talk of Peer Exchange causing Private trackers a lot of problems because Peer Exchange clients are introduced into the swarm and are then "legit" as far as i can tell

Since i cannot see uTorrent supporting this at the moment, i have no idea WHY it has been banned on certain sites

[splintax]

Peer Exchange via DHT is what BitComet, µT and the regular BT client use.

Azureus uses its own different trackerless network.

The private tracker I'm on automatically flags torrents as 'private' when it is uploaded. There is an option to do this in all torrent makers I know of, including the one integrated into µT. Private torrents will not be shared via DHT.

[Kludge]

Nope, I know for sure that uTorrent respects this... Other clients are somehow bypassing this mechanism... I have tested µTorrent myself on a private tracker with a privately flagged torrent, and DHT status is "Not Allowed"... which is great... But unfortunately, It seems as though some clients are bypassing this private flag

[Ultima]

Which clients might they be? There aren't very many clients that support DHT (a majority don't).

[Firon]

It's not correct to call it peer exchange, peer exchange is a completely different protocol extension. DHT is akin to making every user on the network a tracker.

Ultimate: probably the hacked ones, and old versions of BC (which had DHT before the private flag was implemented)

[Kludge]

Read somewhere that BitSpirit, and another one got over the filelist.org's need to sign up.. And im pretty sure that BitSpirit doesn't support DHT, its a very old client.. Will have to try find the post that gives the two clients that did, or at least used to download data, even though the usual precautions were taken.. Its 4am.. time to sl-_-p

[Ultima]

BitSpirit does support DHT. Also, while its last release occurred back in August, you can't really call that "old," since Azureus' last release was back at the end of June.

[ReP0]

Alright. Let me ask you two questions then, since you seem to know what you're talking about.

1. How come my µT works fine if the software is flawed?

2. Shouldn't a poorer implementation result in a less efficient program in terms of CPU/RAM usage, not in terms of download speed? (Excluding the +/- 5 or so KiB/s you might expect from this.)

Flaws come in many shapes. Not all of them result in an application working incorrectly (at least not at first glance) and not all show up as CPU usage or RAM usage nor do they have to effect all users in the same way. I work on network apps for a living and alot of problems I see when I'm debugging complex internet apps is simple mistakes often can reduce the a program to a crawl for some people while others it's fine. It's usually corner cases they the developer doesn't anticipate or hit while normal testing is underway. For example have a timeout set (internally in the apps) fractionally too low and for most people in the US it will not have an effect where most seeding takes place and hence low latency. However move out to Australia say for example where there is more latency and the program may timeout packets and request them again unecessarily evey so often. Have enough of these and it can slow you down significantly. Similarly in bitorrent such latencies/timeout conflicts may lead to you not getting a response from your peer fast enough and it snubbing you or vice-versa you kicking it off for not sending you packets fast enough. What you end up doing is eliminating alot of clients unecessarily except those who are close to you thus statistically reducing your chances of attaining higher speeds due to limited selection. All this is hypothetical and I'm not saying such problems exist in utorrent. It's more of an educational excercise to demonstrate how some people can have issues and others don't while the program seems to be getting data in all cases. There are alot more scenarios such as this but I think it's enough to demonstrate and explain why a program can seem to work correctly for some and not for others totally or at a slower rate.

Again I'll state that this is all hypothetical and I'm not saying it applies to utorrent specifically. I'm just simply answering how it may be possible.

[splintax]

Okay, thanks for that info, it was pretty.. educational And I can see that you're not bashing µT saying 'it's a bad client because it doesn't work as well as Azureus for me', which is what a lot of people with speed problems seem to be doing without investigating their settings.

By the way, I know you said everything was hypothetical there.. but I'm in Australia, and I'm not having problems..

[Kludge]

@ Ultima: I didn't know BitSpirit had DHT implemented, I wonder what standard/protocol it uses, as i know that there are at least 2, AZureus's, and Bitcomet's.. I believe µTorrent supports the latter implementation (Mainline) ? Don't see many BitSpirit peers about, so i presumed it was very old, My apologies

@ReP0: Indeed very educational, and it helps explain to those less understanding about things that its not all a clients fault Nice one

[splintax]

This info is on the FAQ - here - although it could be a little more detailed.

Basically, all clients use the same DHT except Azureus.

[ScubaSteve]

speeds not so jumpy anymore but ive still yet to see it get over 40kB/s on pub trackers. even when loads of other ppl are downloading at well over 100kB/s using azureus/bitcomet. i know it depends on the peers u connect to but i always used to be able to get maxxed speeds on pub torrents using azureus. Most likely due to the Azureus DHT and userbase being so damn good.

private trackers its ok on. its like somehow azureus and bitcomet dont want to upload fast to µTorrent.

[Kludge]

I can't say i've observed that myself, alway seen a varied spread of peers and different client types, mostly AZureus 2304 & Bitcomet 0.60, but not limited to, also seen quite a few BitTornado & ABC peers which is nice

Not tested latest beta yet as im using the bloated AZ to finish a few downloads that µTorrent only connected to a maximum of 10 peers(!) even though i specified more. Upon running the same torrent in AZ2305 b70 i noticed it immediately had more peers, but source-wise, they were almost all peer-exchange peers... That would, (of course) explain it

[BlackLion]

Alright. Let me ask you two questions then' date=' since you seem to know what you're talking about.

1. How come my µT works fine if the software is flawed?

2. Shouldn't a poorer implementation result in a less efficient program in terms of CPU/RAM usage, not in terms of download speed? (Excluding the +/- 5 or so KiB/s you might expect from this.)[/quote']

Flaws come in many shapes. Not all of them result in an application working incorrectly (at least not at first glance) and not all show up as CPU usage or RAM usage nor do they have to effect all users in the same way. I work on network apps for a living and alot of problems I see when I'm debugging complex internet apps is simple mistakes often can reduce the a program to a crawl for some people while others it's fine. It's usually corner cases they the developer doesn't anticipate or hit while normal testing is underway. For example have a timeout set (internally in the apps) fractionally too low and for most people in the US it will not have an effect where most seeding takes place and hence low latency. However move out to Australia say for example where there is more latency and the program may timeout packets and request them again unecessarily evey so often. Have enough of these and it can slow you down significantly. Similarly in bitorrent such latencies/timeout conflicts may lead to you not getting a response from your peer fast enough and it snubbing you or vice-versa you kicking it off for not sending you packets fast enough. What you end up doing is eliminating alot of clients unecessarily except those who are close to you thus statistically reducing your chances of attaining higher speeds due to limited selection. All this is hypothetical and I'm not saying such problems exist in utorrent. It's more of an educational excercise to demonstrate how some people can have issues and others don't while the program seems to be getting data in all cases. There are alot more scenarios such as this but I think it's enough to demonstrate and explain why a program can seem to work correctly for some and not for others totally or at a slower rate.

Again I'll state that this is all hypothetical and I'm not saying it applies to utorrent specifically. I'm just simply answering how it may be possible.

ReP0 you have missed your calling. You should be about ready to take your Bar Exam for the State of California

[slepec]

I'm "testing" (i.e. using excessively) 1.2.1 Beta right now and I'm very .

To all with low speed problems: somebody on this thread suggested lowering the number of active downloads. I listened to the advice of the wise man. Previous it was 5, now is 2. It worked for me. Speeds stopped fluctuating (and are now maxed) and the client stopped freezing. Thanks, wise man!

To the developers: Thumb up! and a pint of beer down the throat!

Keep posting betas, RCs and all you've got. I'll test them all until I die of

torrent flu (the creepiest version of avian flu). Check the consequences...

[image removed (reported as offensive, I happen to agree)]

Cheers, mates!

Brain cost nothing, it's the idea that counts...

[Kludge]

Good to hear there are a lot of users that are REALLY trying µTorrent against the competition!

Still testing the latest beta, and its the best version yet

Developers, THANKYOU for being so user/forum driven to make your client the BEST!!!

*gets the beers in*!

[ColdArmor]

Yeah latest beta is the coolers.