“Address Not Found
http://www.google.com could not be found. Please check the name and try again.”

“Connection Interrupted
The document contains no data.”

Back to good ol 1.6….

2.0 version is quite naive in handshaking.

1.8.5 will be very generous with the generous peers.

With 1.8.5 I can upload my max 1MB while download 400-500 MB(or even more if there is a super generous peer) on an open tracker.

2.0 version sleeps, I hardly could upload 500kB/s while download 80-100 kB/s.

They say this is because of stability issues and will up this to 20 at a time in later builds.

But yea, this does sound good. I know as a newb, I’d turn on all the logging and see all the “chattering” – and yea, the bittorrent protocol sure is “noisy” – sending all these “Hey I got this, Ok, nope, I don’t need this, send me this piece, OK, go here for this piece, OK, this guy is choked, try this guy instead….”

All consumes a lot of un-necessary bandwidth…

I honestly think these “messages” could be moved to UDP, and leave the file transfers to TCP (for the speed)….since I’ve read UDP is not a “guaranteed transfer” – BUT, on the flip-side, UDP file transfer has a lower bandwidth footprint.

But it’s kind of a “shot in the dark” – in UDP, your client says “send this here” but since UDP is extremely basic, there is no “checking” or “verifying” that the data actually made it to where it’s supposed to be.

But, the badnwidth usage is a big plus.

µTP
.. not uTP

its MICRO(µ) not YOU(u)!
big difference!

I have over 7 pc’s in this room, and 18 total in my home, at times if I want to grab a file from my local pc’s and I am lazy to login/dir change/copy/paste/etc/etc.. I will just grab the .torrent file and transfer it via uTorrent.

I have been running beta 2.0.17290 since it was released, I have had 0 crashes atm. I cant say its faster, just more stable.

When it comes to speed, I run as few torrent files(transfers/downloads) as possible. When I notice that my full d/l bandwith is at -10% then I will look at the number of seeds check out the peers and the max that they can send, if they are all maxed then I just make my active number of downloads higher.

Some major tweaks to the uTorrent settings can “keep you” at 100% download rate.

If you run into DISK OVERFLOW ERROR, a serious problem I had in 1.85 was solved by messing with buffers and at that time I was sending data to a 1.5tb usb drive. USB=slow, now I save to mt internal drive or to memory (8gig installed, set aside 4gig for utorrent) then dump file to usb when complete. (power outage will wipe memory and you will have to restart all…) Use that at caution, small files is best, put large movies direct to you drive. set iTorrent buffers from 24mb upto 128mb or 256mb.

Allow same ip = true
bt.enable tracker = true
bt multiscrape = true
first last piece = false
compact allocation = false
ban threshold = 24
gui date = false
here is a big one… rss_update_interval = 4200… why ping rss feeds and waste bw.

You can play with QOS in your router to bump your local network traffic (linksys makes it easy).

Set your windows QOS to 1% if you run 100% torrents vs streaming video(hulu etc).

*** the above settings work for me, your best settings my be different, check out the uTorrent boards for some quality setups.

# of seeds makes uTorrent faster… Do your part and have a good upload/download ratio, Torrents work only when everyone helps each other.

Play Nice :)

You consider uTorrent bloated??!?

It’s a fine example of tight code! It’s an extremely efficient, yet surprisingly full-featured app.

Go play with iTunes if you want to get a grip on what bloat is!

I’m very curious about uTorrent 2.0, but will wait for the private trackers I use suggest we switch to it.

I don’t want my torrent client to try and save my ISP money/bandwidth.

Seriously, BitTorrent Inc. once said (IIRC, during uTorrent acquisition) that it will use uTorrent as a platform to develop proprietary extensions to BitTorrent protocol. Well, if uTP is standartised and open, as one (non)-troll said here, it might not be the case. Still, there are safer (in terms of proprietary control) clients, such as Deluge.

What will ya say to that, pal?

Use cfosspeed or other traffic shaping software with tcp if you want the ultimate surf experience and maxed out up- and download.

If you want the behavoir as in 1.8.5 go to advanced options

bt.transp_disposition: 13
bt.tcp_rate_control: false

and you are again good to go! Have fun

20% reduction in speed, and some of you are cheering about it? C’mon.

The bad: uTorrent 2.0 is uploading and downloading at approximately 20 percent less speed than before.

However the idea seems to be to give the torrent traffic the lowest priority in your computer. Other clients can still connect though if it is only a change in the buffers of your own client.

How it solves congestion elsewhere i dont know but probably because less packets are sent saying “try again later”.

As mentioned in post 35, the improvements especially noticeable if on a dsl connection. On a friends adsl connection the improvement isn’t as obvious, but then BT never seemed to effect his browsing as much before. I’d never swap though, it’ll be years until adsl can match current dsl speeds here in the UK.

I’m really worried about version 2.0 however i know that soon the private torrent sites will ban the 1.x series of uTorrent and I’ll be forced to upgrade anyway

f uTP

in my case i would have to run through a vpn if i allowed 20 tcp/ip half open connects in the client cause my isp has a limiting filter rigamajig ,, 30 or 40 he told me??

also vista sp2 and win7 has no limit ,, been removed by ms

Considering your client is blocked from almost every major tracker you might aswell upgrade now..

The more torrents you have active, the more overhead you use keeping them active and so the less ACTUAL bandwidth you have to distribute data. It’s one of the amusing things about most private trackers, that they ‘suggest’ you configure your clients as poorly as possible. Their guides don’t help, but hinder, because they are based on a poor knowledge of how the protocol works.

“The overall goal of the uTP congestion control is to use one way buffer delay as the main congestion measurement, as well as packet loss, like TCP. The point is to avoid running with full send buffers whenever data is being sent. This is specifically a problem for DSL/Cable modems, where the send buffer in the modem often has room for multiple seconds worth of data. The ideal buffer utilization for uTP (or any background traffic protocol) is to run at 0 bytes buffer utilization. i.e. any other traffic can at any time send without being obstructed by background traffic clogging up the send buffer. In practice, the uTP target delay is set to 100 ms. Each socket aims to never see more than 100 ms delay on the send link. If it does, it will throttle back.

This effectively makes uTP yield to any TCP traffic.”

Extremely ingenuous, and most competent clients should start implementing that, just like DHT. By the way, this is no “EEE” as some random troll said – The whole stack is detailed there, and any mildly competent programmer should be able to implement and start using that.