Jump to content

µTorrent 1.4.2 beta 435


Firon

Recommended Posts

  • Replies 1.1k
  • Created
  • Last Reply

Top Posters In This Topic

Rafi, as far as I know based on my observations, uTorrent has the following capabilities using these two settings bt.prio_first_last_piece/bt.always_prio_rare:

1. Request first/last + 50% availability pieces

2. Request 50% availability pieces

3. Request first/last + rarest only (not sure because bt.always_prio_rare may override bt.prio_first_last_piece)

4. Request rarest only (that's what I use)

Not sure about the following but I think that regardless of settings, it will always request the very first piece on 50% availability, once that piece is complete, settings kick in as normal. Also based on my observations, it appears that first/last will request 3/4 first/last pieces.

uTorrent also has the ability to request individual files. It does not have the ability to select individual pieces. The closest you can come to is select the file you wish to DL, unselect the files you don't want, while both settings are set to first/last + no rare.

Link to comment
Share on other sites

Rafi, any function that gives priority to one piece over another except rarest will cause performance to drop, by how much depends on the extent of the function.

Let's put this in perspective.

Let's say I ask only for pieces 1-10 when there are 100 pieces. Because I only ask for pieces 1-10, I can only ask them from the limited number of peers that have those pieces. Also, because I will only have pieces 1-10, I can only trade them with peers that don't have them, also a limited number of peers. In short, since I only want 10% of the torrent, I can only trade with 10% of peers, perhaps even less than that. So yes, it will cause a degradation in performance.

I understand what situation would call for such a function. A torrent where the content is a single file that can be sampled by playing only the beginning. I consider this type of torrent to be very inefficient because it doesn't include a short sample file that you can select individually from the complete file(s). I prefer to get torrents that include a short sample file and where the complete file(s) is compressed in multiple RAR files with an SFV check file. I suggest you look for a better source of torrents where the uploaders understand this.

Link to comment
Share on other sites

remember to check your TCPIP.sys and see if it's been unpatched!

Potentially idiotic question (sorry!):

Does this only apply to people who have overriden the default number of half-open (pending) connections in µTorrent? I thought the default prevented µTorrent from hitting the max of 10, making it unnecessary to patch. Is LvlLord's patch optional or mandatory when using µTorrent's default configuration?

Link to comment
Share on other sites

Rafi, as far as I know based on my observations, uTorrent has the following capabilities using these two settings bt.prio_first_last_piece/bt.always_prio_rare:

1. Request first/last + 50% availability pieces

2. Request 50% availability pieces

3. Request first/last + rarest only (not sure because bt.always_prio_rare may override bt.prio_first_last_piece)

4. Request rarest only (that's what I use)

Should those two settings be used in tandem (assuming you're using one or the other)?

Link to comment
Share on other sites

Question to Martin Levac :

Are you saying that "always_prioritize_rare" will not decrease speeds in normal, healthy swarms?

And thus should be on by default for everyone ?

I have experienced the reversed effect; speeds getting lower than normal. I really believe this option should be used when there are a ratio of less than 1:20 (seeds:peers).

Link to comment
Share on other sites

Archived

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


×
×
  • Create New...