mf22 Posted February 26, 2008 Report Posted February 26, 2008 Seeding with utorrent has a limitation, because even set the "number of upload slots per torrent" >= 25 , for a torrent with more peers (commonly I use 50 -100 peers/torrent) the seeding is really for 21... 25(max) peers.So can have connection with 100 peers, but seed for 21. In "Detailed info... Peers tab" in "MaxUp" column appear different speeds for 21-25 peers, and for number that exceeds it - 120.All versions of utorrent have this problem.The same problem has Azureus or Bittorrent.One of the few torrent cliens with no such of this problem is deluge (http://deluge-torrent.org/). With deluge, for one torrent with 100 kB/s upload limit and 50 slots/ torrent, the seeding is for 50 peers with aprox. equal speed (1-3 kB/s). But deluge for Windows (it was developed for Linux) is not so stable like utorrent.
DreadWingKnight Posted February 26, 2008 Report Posted February 26, 2008 Upload slots cycle differently between different clients. An upload slot that just moved from one peer to another may appear to be 2 upload slots.Additionally, there are settings that open additional slots if your bandwidth in use hasn't reached a certain percentage of your limit total.
mf22 Posted February 26, 2008 Author Report Posted February 26, 2008 For same torrent with 50 peers, I mentioned above about detailed info, the same peers (identified with IP) with 120 "MaxUp" and in "Flags column have "u" in utorrent, with another client - past a few seconds- their up is ok and seed to them.The problem is: utorrent is not capable to seed simultaneus to more than 21 peers?
Firon Posted February 26, 2008 Report Posted February 26, 2008 U means actually seeding. u is not.And µTorrent will ignore stupidly high upload slot settings and use its own calculated limit (based off your upload cap).In other words, you're spreading your upload too thin.
mf22 Posted February 26, 2008 Author Report Posted February 26, 2008 Thanks, Firon & DreadWingKnight!For downloading is ok to set more conections/torrent in order to increase dl speed. With 150 conections/torrent (for torrents with more seeders) I dl up to 2 MB/s. My remark about peers with "u & 120" was in order to show the difference between µTorrent and deluge, for example. The same peers accept seeding. Total upload speed/torrent is quite the same, but µTorrent divides it for 21 peers and for peers that exceed show "u & 120". In time some peers could be prefered to seed at one time, but simultaneous seeds are for 21-25.For one torrent with 400 seeds & 2000 peers (constantly for 2 weeks) I try to seed with all my ul speed (244 kB/s), and I observe the difference between different bittorrent clients. For seeding torrents is useful to connect more than 21 peers?Currently I use 3 instances of µTorrent 1.8 (b.8205) - different instances for private trackers, public trackers, my uploads - with different settings for conections, ports, numbers of peers/torrent, upload slots, ... . Thanks for your work!
jewelisheaven Posted February 27, 2008 Report Posted February 27, 2008 You can verify the number of upload slots uT uses by enabling the Debug column in the main torrent pane. The last number is the number of upload slots for a specific torrent. The columns you are referring to MaxUp and MaxDown under the Peers tab are for byte throughput, 120 up and 600 down are the defaults with no traffic.
Firon Posted February 27, 2008 Report Posted February 27, 2008 The thing is, it's actually not -more- efficient to seed to 50 people at once. It's more efficient to send pieces to less people and let them spread the pieces out themselves.
Switeck Posted February 27, 2008 Report Posted February 27, 2008 50 people, each with 90% of different 4 MB pieces of a large torrent have nothing to share to each other.How long will it take you to upload 4 MB x 50 people?That could be how long it takes for the FIRST person to have anything to share to someone else!
mf22 Posted February 28, 2008 Author Report Posted February 28, 2008 With 200 KB/s & 50 peers (up/speed/peer ~ 4kB/s) in 17 min. But not upload the same piece of 4 MB to all 50 peers! In 17 min 50 peers have different pieces to seed (to spread them out). For a torrent with 2000 peers on public trackers is efficiently seeding for few peers (after the completion of the download, they haven't binding to seed on their turn)?!Globally, seeding 1 torrent with 200 kB/s for 24 hours -> 16.5 GB/day = 4219 pieces of 4 MB.My last question: For seeding torrents is useful to connect more than 21 peers (or set 21 max num peers/torrent & 21 upload slots and seed for all of them) ?
Switeck Posted March 1, 2008 Report Posted March 1, 2008 "But not upload the same piece of 4 MB to all 50 peers!"That's not what I meant.Yes, after over 1/4 an hour somebody else will have something to share...but not until then! The amount of time to get the first complete piece out to ANYONE increases drastically as you increase upload slots.Do note that real-world conditions (such as your 50 upload slots example) will probably cause your line to be so crippled that fewer than 20 will be downloading from you faster than 3 KB/sec. Probably 10-20 will be struggling to get 1 KB/sec from you. A few may still get completed pieces at least slightly quicker than 4 KB/sec, but the vast majority won't...resulting in lots of peers getting partially completed pieces, at least on a per-hour basis.The best efficiency gets completed pieces out to the fastest uploading peers as soon as possible and let THEM worry about getting duplicates of those pieces out to everyone else. The problem is, as a seeder, you cannot tell how fast peers are uploading to other peers. So a higher upload slot amount (than 'best efficiency') is necessary...but still probably fewer than half of what uTorrent's automatic upload slots limiter forces on you.You should allow at least slightly more connections per torrent than upload slots simply because some peers may not be constantly requesting torrent pieces from your seed...even though your seed is willing and able to upload to them immediately. There are other peers on hostile ISPs that will spontaneously disconnect or be forced to sit idle even when connected to you...so even more connections per torrent are needed to actually use the upload slots per torrent you select!
funchords Posted May 27, 2008 Report Posted May 27, 2008 (I realize this is a very old thread, but the comment is important. This reply is for reference.)Another very good reason not to have more than 3-4 upload slots per torrent is because doing so makes your computer respond more slowly to signs of congestion. This means that you'll get repeat congestion indications and your speeds will drop farther than they would otherwise need to. Also, since the BitTorrent protocol works best when it can find the least-congested links, having 25 upload slots will make uTorrent (or any other BitTorrent-based client) take longer to find the least-congested paths (best peers). With 25 upload slots, BitTorrent is likely going to go into reciprocating transfers with poorer peers than it would with 3-4 upload slots. -Robb (currently trying to get the word out that uTorrent and others are not designed to "game" congestion control because it was designed to use upload slots conservatively).
Switeck Posted May 27, 2008 Report Posted May 27, 2008 If you are only running 1 torrent at a time with 100 KiloBYTES/second dedicated upload speed, then it is ok to go with 10 upload slots...because that's 10 upload slots TOTAL since there's only 1 torrent. Once even a second torrent is started, upload slot max per torrent really needs to be reduced...possibly even as low as to 4 upload slots per torrent.The optimistic upload slot (O symbol under flags in uTorrent's peers window) roams around randomly and is not always active yet counts against the max upload slots per torrent limit. So even if you set upload slots to 5 per torrent, it's not uncommon for only 3-4 upload slots to be active at least for short periods -- longer if dealing with hostile ISPs! On top of that, of the 3-4 upload slots active, often 1 of them will be going at <2 KiloBYTES/second each. This is why I suggest setting upload slots as high as 10 with 100 KiloBYTES/second dedicated upload speed when running only 1 torrent at a time.If you are firewalled and/or on a hostile ISP like I am (on ComCast Cable ISP in USA), then using a tiny bit more upload slots may work out...such as 5-7 instead of 3-4 -- BUT best results can only be determined through trial-and-error!In ANY case, you should NEVER allow more total upload slots (this is upload slots PER torrent TIMES total active torrents) to be so great in number that EACH upload slot cannot get at least 1 KiloBYTES/second. To be a good peer or seed, EACH upload slot really needs to get at least 3 KiloBYTES/second...higher if possible.Due to poor reciprocation from many BitTorrent clients...setting higher than 10-20 KiloBYTES/second per upload slot for downloading torrents doesn't help your download speeds alot.Seeding torrents can use fewer (and FASTER!) upload slots than downloading torrents, because you don't care about peers uploading back to you...only to each other!
mf22 Posted October 26, 2008 Author Report Posted October 26, 2008 The old problem of "limitation" resolved in newer versions of µTorrent! For my same upload speed (2 Mbps) µTorrent allocate 27-28 upload slots for 1 active torrent. I don't use this all the time; for 10-20 active torrents is useful 5-10 upload slots. But in some cases, this setting works well: I started uploading of one torrent (size=920 MB, 256 KB - size of pieces). Loaded torrent in 2 instances of µTorrent (µTorrent - 1.8.1 & BitTorrent 6.1.1), established upload limit for each instance at 115 kB/s and µTorrent allocated 21 upload slots for each instance. In 2 hours with 42 connected peers (21/instance) I obtained 20 another seeders. And that's all, continued with standard settings. Thanks for your great work!
Switeck Posted October 26, 2008 Report Posted October 26, 2008 So long as each upload slot can reach (but doesn't always have to...) 3 KB/second, all is good.
Recommended Posts
Archived
This topic is now archived and is closed to further replies.