1.8.1 Release Candidate 1 (build 12549)

[Greg Hazel 0]

uTorrent 1.8.1 beta (build 12130) crashes on Vista 32 Ent. sp1

http://www.mediafire.com/?mzc4sgjijgi

Hm. Fixed, thanks!

[ile89 0]

I wonder why uTorrent said "There is no new versio available at this time" when i tried to update and there was indeed new version. This has happened in the past. I'm not using any proxy settings and my firewall doesn't block utorrent. This has happened with the builds 12024 and 12083. I had to manually download the installer and install the latest build.

[osm0sis 1]

this has been mentioned several times in this thread, and elsewhere:

it takes a day or two for the betas to go up on the updater. the betas go to the forum first.

[rafi 213]

For some reason, I have the feeling that uTorrent does not stabilizes around the maximum number pf peers defined per torrent. I have set it to 200, and got around 150 . I'm now trying to set it to 300, and getting around 200-220. Available seeds/peers for that torrent is now ~ 1700/5000. Is there some issue with the # of connections+limit algorithm ?

PEX + DHT are on.

[Greg Hazel 0]

What if you set it to 20?

[rafi 213]

20 ? ... are you sure ? isn't it too small a value for any deductions ? ... I'll try and edit the result it into here

edit:

well, for 20 it reaches 20 in a few seconds and stays with 20 ... BUT ... my poor DL speed is 15K instead of ~100K with 200 ....

What does this means for you ? I think your algorithm should let me decide how to reach my best speed, and I should be able to trust uT to reach the max values I set for # of peers.

[Firon 3]

You're also on a horrible ISP, so I really don't trust anything you report with regards to this. Anyone on a non-Israeli ISP have similar results? Also recall that the tracker only gives you so many peers, and that a lot of connections do fail for one reason or another.

[rafi 213]

edit(2):

If you ask me, my ISP is not relevant to this issue (yes, he is terrible, but the best we have here...) . And you don't have to trust my report(s), you can try it yourself and try understand the symptom, and deduct why uT does not reach the specified max peers. Yes, avarage peers' speed IS slow here (~1-8K also due to 200-300 msec latency to the US). So what ? uT should handle this situation as well as it does connecting to closer/faster peers.

and here is a speed<->peers graph for you (alus... ):

[moogly 0]

Hello.

I have a question about feature isp.bep22 in build 12130. I understand it's protocol to discover local peers (networking sense) and reduce traffic costs for ISP.

Is it the same concept of Ono plugin for Vuze/Deluge (measurements from content distribution networks CDNs) or the P4P protocol developed by the Yale University (and tested on Verizon network with Pando) ?

What are the differences with Ono or P4P protocol ? That seems very promising like feature !

[ile89 0]

I'm not sure if this is a bug with utorrent (build 12132) but all my torrents are doing this. When torrent updates tracker status automatically it stays on "updating". If i do manual update before tracker status updates automatically, it updates but after one of the torrents updates automatically it stays on "updating".

[Greg Hazel 0]

edit(2):

If you ask me, my ISP is not relevant to this issue (yes, he is terrible, but the best we have here...) . And you don't have to trust my report(s), you can try it yourself and try understand the symptom, and deduct why uT does not reach the specified max peers. Yes, avarage peers' speed IS slow here (~1-8K also due to 200-300 msec latency to the US). So what ? uT should handle this situation as well as it does connecting to closer/faster peers.

and here is a speed<->peers graph for you (alus... ):

http://img60.imageshack.us/img60/1875/73963900nt7.png

http://img60.imageshack.us/img60/73963900nt7.png/1/w697.png

Hm, well can you prove that a previous version of uT on the same torrent gets a full set of peers? The only change around there recently was the fix to the half-open limiter, which does make connect attempts take a bit longer to time out (but hey, it doesn't bust the half-open limit )

[Firon 3]

Hello.

I have a question about feature isp.bep22 in build 12130. I understand it's protocol to discover local peers (networking sense) and reduce traffic costs for ISP.

Is it the same concept of Ono plugin for Vuze/Deluge (measurements from content distribution networks CDNs) or the P4P protocol developed by the Yale University (and tested on Verizon network with Pando) ?

What are the differences with Ono or P4P protocol ? That seems very promising like feature !

Absolutely nothing like them in implementation. Click on the BEP link and read it. It'll tell you everything.

[Greg Hazel 0]

Hello.

I have a question about feature isp.bep22 in build 12130. I understand it's protocol to discover local peers (networking sense) and reduce traffic costs for ISP.

Is it the same concept of Ono plugin for Vuze/Deluge (measurements from content distribution networks CDNs) or the P4P protocol developed by the Yale University (and tested on Verizon network with Pando) ?

What are the differences with Ono or P4P protocol ? That seems very promising like feature !

Ono specifically pings Akamai and Limelight hostnames, takes the IP it receives and looks for other peers that received the same IP - using their own separate DHT (!). This is of questionable value, since it has more to do with where Akamai and Limelight servers are near you, than the actual speed/cost between you and the other peers in your group.

P4P is a massive, unrealistic project to run an "intelligent" tracker that determines what the best set of connections for a peer should be. No client supports this now, or probably ever.

BEP22 is a simple DNS-based detection mechanism to find a tracker in your ISP. This tracker could return the IPs of caches operated by your ISP, or local peers. The protocol is the same as a regular tracker.

We do have a plan for improved peer selection, based on topology. That will probably use the same DNS lookup mechanism as BEP22, but be a new type of service, independently configurable.

Thanks for your interest!

[rafi 213]

alus:

Hm, well can you prove that a previous version of uT on the same torrent gets a full set of peers? The only change around there recently was the fix to the half-open limiter, which does make connect attempts take a bit longer to time out (but hey, it doesn't bust the half-open limit )

well, 1.8 and 1.7.7 seems to behave the same. So, it might be one of my setups... I remember it was not like that ... I really don't understand it., since it does reach higher connections # (like 220/400) so why is it stuck @~150 when the limit is 200...

[Greg Hazel 0]

alus:

Hm, well can you prove that a previous version of uT on the same torrent gets a full set of peers? The only change around there recently was the fix to the half-open limiter, which does make connect attempts take a bit longer to time out (but hey, it doesn't bust the half-open limit )

well, 1.8 and 1.7.7 seems to behave the same. So, it might be one of my setups... I remember it was not like that ... I really don't understand it., since it does reach higher connections # (like 220/400) so why is it stuck @~150 when the limit is 200...

Well, try increasing it from 20 (where it works fine) by 10 or so at a time, and see where it fails. Keep your rate limit low, to prevent congestion from causing timeouts. The problem might be due to the swarm just not having enough peers, and it might be due to some router limit on number of connections.

[AGE 0]

windows vista sp1 - utorrent 1.8.1 build 12132

what this ..?

[Greg Hazel 0]

windows vista sp1 - utorrent 1.8.1 build 12132

http://img291.imageshack.us/img291/3192/16907810yv5.jpg

what this ..?

Can you PM me the IP and port, and/or send me the torrent? It's probably a variant of "BitSpirit v2 UDP0", but we could be a bit better about the display.

[Sunstep 0]

12132-utorrent.01bc.dmp.rar

[thelittlefire 0]

Do you know what uTorrent was doing when it crashed? I know they can see whatever.. when they debug it, but some context never hurts

[Greg Hazel 0]

12132-utorrent.01bc.dmp.rar

This crash may be due to: Agnitum Outpost Firewall or Agnitum Outpost Firewall Pro or Lavasoft Personal Firewall or Agnitum Outpost Security.

Can you try disabling / uninstalling that, and see if the problem goes away?

[AGE 0]

i send them ...

[hermanm 3]

> - Feature: isp.bep22, default off, inactive for private torrents (see: http://bittorrent.org/beps/bep_0022.html)

Is there a list of ISPs that actually support this feature?

> This is of questionable value, since it has more to do with where Akamai and Limelight servers are near you

I think Ono is worth investigating. Akamai & Limelight will not get it right 100% of the time, but what they determine as a local peer could arguably be leveraged with Bittorrent users. As long as local peer speeds are greater or at least equal, I would prefer connecting to them 70%-80% of the time as opposed to a long distance peer.

[Greg Hazel 0]

> This is of questionable value, since it has more to do with where Akamai and Limelight servers are near you

I think Ono is worth investigating. Akamai & Limelight will not get it right 100% of the time, but what they determine as a local peer could arguably be leveraged with Bittorrent users. As long as local peer speeds are greater or at least equal, I would prefer connecting to them 70%-80% of the time as opposed to a long distance peer.

It's the "as long as local peer speeds are greater or at least equal" part that Ono does not do. Very often, for example on AT&T DSL or Comcast cable, local peers have very slow upload rates. I'd much rather have a peer list of Verizon FIOS, Swedish, and Japanese peers. In fact, a random set is probably better than the local peer set.

[theembryo 0]

"....In fact, a random set is probably better than the local peer set."

Very very true, that...

[DreadWingKnight 310]

VERY few ISPs offer higher speed limits to provider-local traffic. Even fewer than the number of ISPs that provide REASONABLE upload rates for the connection's downstream capabilities.

Until both of those change for the better, the preferences towards provider-local traffic will be detrimental to torrent lifespans AND speeds.