Jump to content

µTorrent 3.2 stable (27568)


Firon

Recommended Posts

  • Replies 1.1k
  • Created
  • Last Reply

Top Posters In This Topic

rafi

Thx, but what can I do now? Which option I can change to make uT use more memory?

I can't use 1500 MB cache - during upload and download uT can hang. 1350 Mb is ok for me, thats all I can do about cache memory in this version of uT.

Also I've noticed that I get best results when diskio.cache_stripe is set to 512 or even 1024 (there many "dummy" reads I guess but some of them hits the target). And diskio.coalesce_write_size with diskio.max_write_queue I use much more than default.

I've got 80/80 mbit and two slooooow HDDs - WD Green (with AAM on 255 (so they got slow seek)), and up to 100 torrents (active up to 30-40 at the same time).

So the default settins is definitely not for me :/ And only with that settings I can see high speeds.

Link to comment
Share on other sites

Thx, but what can I do now? Which option I can change to make uT use more memory?

You are asking me? ... :) My answer is in me settings/sig...

Eventually, what counts is not how large you can set your cache to (I think it is 1800M now) , but how efficient uTorrent is handling file IO. They suppose to try and improve some aspects in the next 3.2.1 release. Till then, you can try the tips here:

http://forum.utorrent.com/viewtopic.php?pid=671702#p671702

Cache is for helping with temporary load conditions, not sustained continuous ones...

Link to comment
Share on other sites

to fixing bugs and finally proper magnets handling and support :P

meh... it is mostly proper right now... maybe one of two "glitches"... like "auto-stopping" the downloading torrent after the meta-data arrives... ;)

Link to comment
Share on other sites

Tried 3.2 after I reverted to 2.2.1 and I'm sad to see that I have the same issue that I had since version 3.1 stable hit. Peers won't connect between tracker updates => I can't have a decent ratio. 2.2.1 and 3.0 worked like a charm and 3.1 until 3.2 are acting up. Tried 1000000000 settings and even trid with the default ones. The same. If the tracker does not update, there's no peer connecting to me. And yes, it's allowed in the firewall and in the antivirus.

Link to comment
Share on other sites

Peers won't connect between tracker updates =

How can you tell? did you enable logging for incoming connections? what did you see on help->show-stats if you delete all trackers and enable DHT, having peers in your list?

Link to comment
Share on other sites

Deathstalker:

The article does not say what the specific proposal is. Is it to remove the cability of adding trackers to a torrent list? What about when creating a torrent? Is it to check the list to insure that the client does not allow the adding of an http: tracker entry for their specific site? What about programs outside the torrent client that allow the user to edit torrent? Is it to provide better handling of errors from the tracker? If I get errors concerning a tracker I remove it (depending on the error).

"overloaded with bogus announcements". I fail to see how the announcements are "bogus" - in a general sense. I can see the point that a request for peers for a torrent that is not in their database can be considered bogus. But that may not have been the intent of the torrent creator. What is the error ratio of valid to bogus requests?

BitTorrent may feel it is not their responsibilty to clean up torrents that are loaded by replacing a specific url with another. It surely would slow the loading of a torrent into a client - and as more trackers change their url - slower again.

I do know a site several months ago that posted they were reducing the number of tracker url(s) to a single url. I did not see them recommend that clients be modified to automatically make that change.

Link to comment
Share on other sites

Deathstalker:

The article does not say what the specific proposal is.

The proposal was to consider implementing this BEP into the protocol:

http://forum.bittorrent.org/viewtopic.php?id=987

That is, to make it so that the tracker can inform the client about it's capabilities, thus avoiding unwanted communication between the two. At least, that is what I've figured.

PS:

Though, this can be a good idea, it does not concern BT alone, but *all* the clients and *all* the tracker sites.

Link to comment
Share on other sites

Here are just a few excerpts from that article....

http://torrentfreak.com/largest-bittorrent-trackers-go-offline-in-protest-120716/

"The issue has been brought to the attention of BitTorrent developers in the past, and two months ago Pirate Bay co-founder submitted an official proposal to the developer forum which is operated by uTorrent’s parent company BitTorrent Inc."

"The proposal is to add a functionality that allows website and tracker owners to inform BitTorrent clients whether connections are allowed or not."

The RIAA and MPAA are supporting OBT's and PBT's strike and hoping it lasts for a long time.

In the long run the RIAA and MPAA will benefit if developers and trackers don't see eye to eye.

Link to comment
Share on other sites

A lot of the problem stems from user stupidity regarding tracker lists.

They are of the delusion that adding a bunch of trackers will help their speeds.

Most of the lists that are out there add a multitude of trackers that:

1> Are down

2> Have been closed for over a year

3> Are duplicates/aliases of other trackers in the list

4> Communicate properly with other trackers in the list in such a way that they're actually one tracker (but are separated in the list like they aren't)

5> Have never been trackers

6> Don't track all torrents

Those lists are the root of the problem.

Link to comment
Share on other sites

Those lists are the root of the problem.

OK, yeah... but I thought that the proposed protocol change was kind of suggested solution to overcome a side-effect of that root-cause - using wrong url's (TCP/UDP).

Link to comment
Share on other sites

Just to relieve some resources.

What resources? A message of a few bytes every few minutes (and longer each time, per the protocol) ? If the tracker really does not work, it will not heart anyone. And a "reject" message is a good solution to stop using an invalid protocol. Just not a solution to the other 6 or so issues that were mentioned above :(

Link to comment
Share on other sites

Much like banning bad ip for sending bad data, do the same for trackers that are known dead. I did think connectible but then that could also be because they need to sign up to the tracker. So know dead ones are better. Store this in a hash value in a non dat file so cannot be deleted or other. Or better code those trackers into each new update of utorrent.

About DHT: I don't use dht unless I need to since it is a waste of bandwidth. And when do use am very happy when 1:1 and get rid of it again asap. I try not to use dht torrents at all.

Maybe I have this wrong, I excuse in advance if don't understand correctly:

DHT last used was I think 300+ connections always open and updating which is a waste of bandwidth and resources. Some sort of management to close those without seed, peers, leechers etc. A way for the dht tracker to inform the client for new dht connection when has a seed, peer, leecher etc if possible to do.

Link to comment
Share on other sites

know dead ones are better

Right, like an exclude/black list (ipfilter-like)... But, I guess processing power is a consideration too. I'm sure that even skipping double URLs/resolved- IPs inside trackers' lists can do some good too.

Link to comment
Share on other sites

Better error handling on the client side would be a big step forward on reduction of traffic. There are several cases where the retry timer shoulld not be set and the tracker disabled:

1. The tracker does not exist (http error 404?).

2. The tracker is not authorized for that specific torrent. (This may be not from a user adding a specific tracker to the list, but rather the tracker removing it torrent because of copyright issues.)

3. The tracker is private and the user is not authorized to use that tracker.

There are very old torrents out there that are still in demand, but (some) trackers inside the torrent no longer exist, or changed their port, changed or added a new protocol - such as udp.). I cannot see how uTorrent (or any client) can handle this unless there was a site that maintained a list of valid and current trackers (perhaps like DHT). Then the list of trackers within a torrent would not be necessary. Creators of a torrent would not be adding old tracker addresses, (Of course all you would need to do to stop sharing is to kill that site - that would only leave DHT.) Until there is a method to insure a valid list of trackers the user must be able to edit/correct the list.

So I would like to see better error handling on the client side. The elimination of duplicate tracker entries. But the user is still able to add trackers - there are to many old torrents out there that are still in demand that do not have valid trackers and are not DHT enabled.

Link to comment
Share on other sites

The elimination of duplicate tracker entries

This should be pretty simple to do. Better yet - first resolve all to IPs, and then do it... :).

I guess even now they actually filter communication from duplicate entries .

Link to comment
Share on other sites

Peers won't connect between tracker updates =

How can you tell? did you enable logging for incoming connections? what did you see on help->show-stats if you delete all trackers and enable DHT' date=' having peers in your list?[/quote']

I don't use public trackers => I don't need DHT. I saw it pretty simple. While the update interval was active, no peer was connecting to me. When I manually updated the tracker, the upload started with 10 mb/s. This occured 10 times in a row => it's not a coincidence. Anyway, staying to 2.2.1 until it will go off the internet. I think there's a setting that does this, but I don't have time to start and test every variation. This behavior occurs with the standard settings.

Link to comment
Share on other sites

A lot of the problem stems from user stupidity

DWK, a lot of car accidents stem from drivers stupidity. That's why car manufacturers install air-bags, seat belts, ABS's etc. And it's not always user stupidity because in many cases, the trackers are already in the torrents. Designers have to design stable products for everyone (including drivers, pedestrians, users, trackers) and I don't see a reason to blame the users.

Link to comment
Share on other sites

Ok Admins! WHY has there been no response?!

At least a *response* could provide a rational for not implementing the request.

Thank you!

http://torrentfreak.com/largest-bittorrent-trackers-go-offline-in-protest-120716/

Oddly enough, the real issue is mentioned in the article itself:

Both OBT and PBT abandoned TCP support to become UDP-only trackers last year. This was done to save resources. However, because many users keep adding HTTP addresses and since many old torrents also include these, both trackers are overloaded with bogus announces.

Bolded for emphasis.

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.


×
×
  • Create New...