Opened 12 years ago

Closed 12 years ago

#3318 closed Enhancement (duplicate)

Number of used upload slots is too high?

Reported by: Sato Ambush Owned by: Charles
Priority: Normal Milestone: None Set
Component: libtransmission Version: 2.00
Severity: Normal Keywords:
Cc:

Description

While downloading via transmission 2.0 i've noticed something in the inspector pane within the peers tab. the number of peers i am downloading from was around 10 to 15 peers. but the number of peers i was uploading to was also around 15 peers (peeking up to 30 one time). on the downside two third of the peers i was uploading to were idling around with 0 kb transferspeed. therefor only their overhead consumes bandwidth. but the main problem imho is that the described scenario took place on a 6 mbit line (600~700 kb download and 75-80 kb upload bandwidth -no speed caps applied). therefor especially the peers i am uploading to nor the swarm in general don't have much of a benefit from me as a peer i suppose? Wouldn't it make sense to limit the number of slots on the libtransmission side? maybe create some empirical based slot numbers for speed ranges. so if you have a download rate of e.g. 700 kb and a upload rate of 80 kb then apply 10-20 slots for download and 2-4 slots for upload. and adjust it up and down for other bandwidth ranges. but a maximum slot number for downloads and uploads at the upper end. as a suggestion for application there might be two scenarios

1) active global bandwidth limits -> the possible speeds for the line are known therefor the application of the right slot number would be easy

2) not active global bandwidth limits -> transmission could compute based onto the average upload and download speeds which bandwidth range would match and choose the implied slot number group based onto it

Reasonable? Best regards

Change History (2)

comment:1 Changed 12 years ago by User294

If I'm not a complete moron, as of 2.x transmission tries to assign slots based on bandwidth usage and available bandwidth. Actually, as for me, I have a 30 Mbits link, symmetric one (30 mbps up and 30 mbps down). Looks like earlier transmissions were worse on my link. And if some peers are idle, actually, it could be that noone needs your bandwidth at this moment in current swarm. Torrent easily saturates download channels so when you enter swarm, you may have certain issues with finding peers who will be able to consume all your upload bandwirth. However, from my experience, single slot speed should not fall below 1-2 kibibytes per second (so, not more than 30-40 slots for 80kbytes/sec in total should be used). Else TCP tends to stuck. So, limiting slots is a good idea, IF this does not affects ability to fully use link. Let's say, some 2-4 peers may fail to consume 80 kbps at all. Imagine that there is 100 other peers ULing to same peer. 40 kb/s * 100 = 4Mb/s = 40Mbit/s. Even I am with my FAST link would fail to consume 40 kbps from 100 peers at once. So, actually, 2-4 slots can be too few for 80 kbytes/sec link.

Anyway, there is "upload-slots-per-torrent" parameter in settings.json config file, it defines maximum amount of upload slots per torrent. So you can adjust maximum slots to get what you want I guess. For example, adding smth like "upload-slots-per-torrent": 100, allows me to have up to 100 UL slots per torrent, which is a great idea when you can UL whole 30 mbps at once so ppl have chance to actually consume them. I guess you can tweak this value to see what fits your needs ;)

comment:2 Changed 12 years ago by charles

  • Resolution set to duplicate
  • Status changed from new to closed

This is a duplicate of #2997

Note: See TracTickets for help on using tickets.