Jump to content

1.7b2539: too many concurrent peer sessions


Recommended Posts

Editted: I got units mixed up as pointed out by Switeck

I think uTorrent 1.7 Beta (build 2539) starts too many concurrent peer sessions (and downloads too many concurrent pieces) when downloading a torrent. I have seen this problem in earlier versions of the beta as well and have seen this problem over a number of weeks before deciding to post. I have not used uTorrent 1.6.x.

Each concurrent peer session must take overhead and so reduces my real download rate and increases the total time to download the torrent. What happens is for a piece to quickly download blocks to about 2/3 complete and then it slows right down getting the remaining blocks. When a piece reaches about 2/3 complete, a new piece is started. I have seen this behavior repeated for torrents of one or more files and for torrents where pieces are of 4MByte and 256kByte and different number of blocks per piece

As an example, I am downloading a single file with about 700 pieces where each piece is 512kBytes and has 32 blocks to each piece. For a bandwidth of 16kBytes/s, I have about 15 concurrent pieces (and peer sessions) of which 2 pieces are being downloaded quickly and the remaining 13 very slow.

In the 'Pieces' tab, I have:

# pieces # blocks downloaded

5 31

2 30

3 29

1 28

1 27

1 23

1 13

1 4

In the 'Peers' tab, I have one peer downloading about 3kBytes/s and then then 3 more above 1kBytes/s and the remaining at sub 1kBytes/s. Roughly 5 are at 0.1kBytes/s.

This problem occurs during the time my Internet Provider 'shapes' my download bandwidth during 'peak' times. When 'shaped', my download bandwidth is 16kBytes/s can be over 150kBytes/s during non-peak. My upload bandwidth is never affected.

Is uTorrent 'tuning' itself and trying to apply parameters gathered during 'non-peak' and high download bandwidth to the 'peak' times and low-download bandwidth?

Link to comment
Share on other sites

Download/upload speeds in µTorrent are in KiloBYTES/sec, not kilobits/sec.

1.5 megabits/sec of download bandwidth is about 160 KiloBYTES/sec download speed.

Low upload bandwidth can make it seem like you have major download problems too.

...So what is your settings overall in µTorrent (as shown by Speed Guide CTRL+G) and what is your upload bandwidth max?

Link to comment
Share on other sites

Switeck you are right. It must of been before my morning cup of coffee when I wrote that post. I did get bits/s and bytes/s mixed up. Rather than post what would be 95% the same again, I editted the original post.

There is nothing functionaly wrong with uTorrent and I eventually get the Torrent downloaded. I simply find the number of concurrent sessions odd and I would think that the overhead for the number of concurrent sessions would be eating into the limited bandwidth. Also, it takes time for the first pieces to be completely downloaded and uploading for that torrent to begin. I would have expected two or three concurrent sessions for such limited download bandwidth.

There is no issue with the upload bandwidth as it is not shapped and could be happily uploading at 50kBytes/s at any time of the day. Download bandwidth is shaped before midnight and after 8am. Opening so many sessions is fine with the unshaped speed.

I do limit the upload bandwidth to 30kBytes/s or 70kBytes/s (depending). This allows at least 20% overhead capacity for uploads. Are you suggesting that I limit the download (currently set to 'unlimited')?

Link to comment
Share on other sites

No, limiting download speed seems to make µTorrent behave really poorly. :(

(It's a bug of sorts, but also a limitation of how TCP/IP works.)

µTorrent is/was definitely bad about starting lots of pieces without getting around to finishing them...leaving them open to hostile ips to give you bad data to fill up nearly complete pieces -- making them fail hash test of course!

Link to comment
Share on other sites


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

  • Create New...