Switeck

The router is retaining UDP ips that have long since timed out, and choking on that. It's a piece of junk. Can you install Tomato or DD-WRT on it? (And then reduce TCP and UDP timeout delays.) You can disable most if not all UDP-generating traffic by uTorrent...but you may be unable to connect as well to other peers/seeds. DHT, maybe Local Peer Discovery, Bandwidth regulation (uTP peers/seeds!), Resolve IPs, Teredo/IPv6 uses UDP.

Think of the person on the other end of the connection. If you're uploading on average less than 1 KB/sec, the whole system won't work very well if EVERYONE does that. Indeed, if you only get 120 KiloBYTES/second download max then 50 connections should be enough. bt.connect_speed: default is 5 ...means attempt up to 5 outgoing peer/seed ip connection attempts per second. Figure the amount that could attempt without other limits in just 5 minutes -- 1500 ips! ...And previously the default was 20 per second! net.max_halfopen=8 is a limiter on how many in-progress outgoing connection attempts to have at once. Otherwise, you might reach global max connections or per torrent max connections with in-progress attempts to dead ips.

123459, Yes, it is still incorrect. 60 KB/sec upload speed max spread between 10 torrents is 6 KB/sec per torrent. But splitting that again up to 10 upload slots per torrent reduces that to 0.6 KB/sec upload speed per upload slot. It is best to upload at LEAST 3 KB/sec per upload slot. ul rate 60 global con max 200 connected peers 50 slots per torrent 3 (You've got the box checked to allow more.) active torrents 6 active downloads 5 bt.connect_speed=2 net.max_halfopen=8 net.calc_overhead=True or False...test to see which works best for you.

Smith6, make a new message thread in Speed Problems forum. List your measured down and up speeds for your connection, connection type, and follow 1st link in my signature for troubleshooting.

A public torrent with 1 slow-ish seed often has nearly every peer finish downloading around the same time. They often quit within 0-12 hours of that but still get recorded as "part" of the swarm incorrectly by either the tracker or other peers/seeds for days. (Mainly by peers/seeds via PEX or DHT.) So if you're on a public torrent that claims 80 seeds, don't expect to connect to more than 40. Even on private torrents reporting 80 seeds, don't expect to connect to more than 70 -- some may have reached global or per torrent max connections. I screwed up, indeed if there's only 2 reported peers...then the seeds (and those peers) can only upload to you and the peers. But that's only for that torrent! They may also be running 5+ other torrents and/or have priority/upload speed max set for this torrent really low. Even if not, then an "average" ADSL or Cable line that has only ~60 KB/sec max upload speed is certainly splitting it thin if it's running 5 torrents with 4 upload slots each. That's 18 or 19 total upload slots. 60 KB/sec / 18 upload slots = 3 1/3 KB/sec each Even if they only had 2 other torrents with 4 upload slots each, then there'd still be 10 upload slots active...so: 60 KB/sec / 10 upload slots = 6 KB/sec each No joke -- if "ordinary" seeds are seeding multiple torrents, you're not going to get a lot from them even when you ARE downloading from them. So if all 82 sources upload to you, that's about 500 KB/sec combined download speed. That should be enough for ordinary video playback but not enough for upper-end HD video. The risk to private trackers is probably minimal, as they typically have ratio enforcement, very few firewalled peers/seeds, and higher-than-average (by FAR for some!) upload speeds per seed. The risk to public torrents depends on the 1.accuracy of the torrent's stats (how many reported seeds/peers), 2.firewall ratio, 3.average upload speeds, and 4.whether seeds stick around to seed at least 1:1 after downloading. 1.I've seen numerous times where reported seeds/peers were at least a magnitude higher than available seeds/peers were really there. Some reported seeds/peers were even blatantly impossible ips, such as 255.255.255.255 or 0.0.0.0! Any estimate for whether a torrent swarm can sustain heavy leeching may be doomed to failure due to lack of real seeds. 2.Many ADSL ISPs give out modem-routers to their unwitting customers. Antivirus products now often include software firewalls. Software firewalls often have to be explicitly configured to allow incoming connections. Wireless and Satellite ISPs are almost always hopelessly firewalled. Lastly, a large percentage of broadband customers have routers. In all, it's not unreasonable to assume at LEAST 40% are firewalled on public torrents...some hopelessly so. My guess is the firewalled percentage is probably >50%. 3.With few ISPs giving more than 1 megabit/second upload speeds even on their "premium" speed tiers, most people have less than 120 KB/sec usable upload. ISPs may throttle BitTorrent uploads heavily, at least to other ISPs. People may lower upload speed max as well to only a small fraction of their line's max. Or they may run lots of torrents at once. Or they may have lots of upload slots PER torrent. Or they may allow lots of peer/seed connections at once. 4.On public torrents, seeding duration seems to be limited to only a few hours after completion for the vast majority of seeds. Seldom is there any appreciable number of seeds (despite tracker/peers reporting so!) except on super-popular torrents. In the BitTorrent protocol original specification, seeds were sources of LAST resort -- to be used only for pieces no peers have. By demanding a common piece instead of a rare one from the seed, the seed is spending its bandwidth but not increasing the torrent's availability. If the seed or other seeds leave, the rare piece gets rarer and the sequential downloader has not offset that by doing its part. Sequential downloading rewards bad behavior and punishes good behavior. ...because those that initially seek rare pieces will likely have nothing to offer them, and likewise will get little-to-nothing in return. If the sequential downloading isn't as fast or faster than video playback, it's nearly unworkable. For HD video, this can require download speeds faster than the average upload speed max for most ADSL and cable lines. This means it cannot scale so that everyone can do it UNLESS everyone seeds heavily after they're done downloading, which sadly isn't the case. In short, HD video sequential downloading is pretty much unworkable on public torrents even with very favorable seed-to-peer ratios. If you're doing sequential downloading on something besides video, then much lower download speeds would "work"...but likewise there's fewer and weaker reasons to do so. For multi-file torrents, do-not-download and High/Normal/Low priority can cover those cases well enough already. A torrent that's mis-marked as private on a public tracker is even worse off from sequential downloading and hit and runners. A feature that will *ONLY* work well with private trackers has nearly nil chance of being implemented. Example of 1 BitTorrent peer (out of 4 peers) using high priority on Beginning/Ending of each file in a torrent: http://img197.imageshack.us/img197/5263/bitcometpeerpresent.png There are also hints of sequential downloading across the whole torrent, with the far left side availability being much higher than the right.

flak, What you're seeing is an artifact of uTP connection failures and high reconnect rates by other clients. Your end first establishes an outgoing uTP connection to them...at some point it gets disrupted/fails/breaks/etc. Then the other end makes an outgoing connection to you, using of course regular TCP instead of uTP...because they're NOT set up to make outgoing uTP connections.

Fadeout, that's with net.calc_overhead set to false?!

"if I were on a torrent with 80 seeds and 2 peers, it is extremely unlikely that sequential downloading by either or both of the peers would result in the torrent's death." Initial seeding scenarios often have the majority of peers become seeds almost at the same time. And very shortly afterwards, probably more than half the new seeds leave. Many of the remaining seeds may be slow, firewalled, or conditionally slow if on hostile ISPs. The reported seed/peer numbers can also be artificially inflated due to miscounting caused by multiple ips to describe a single peer/seed. Typically this is when they have both a IPv4 and IPv6 (via Teredo) address. Considering the default settings for uTorrent is to allow up to 50 connections per torrent and have 4 upload slots per torrent, that means on a busy torrent a seed could be connected to 40 peers but only uploading to 4 -- 1/10th (10%) of all of them. On top of that, their average upload speed per upload slot is likely to be less than 3 KB/sec. To recap: 80 seeds + 2 peers Only 50% of the seeds remaining just minutes after being last seen. On average, about 50% are firewalled. Maybe 20% are on hostile ISPs or have really pathetic max upload speeds. Maybe 25% of the ips are duplicates of the same seed/peer. Each averages about 3 KB/sec upload per upload slot, but only uploads to a particular peer maybe 1/10th of the time. 82 total peers+seeds x 50% remaining x 50% unfirewalled x 80% not on hopelessly hostile ISPs x 75% aren't duplicated ips x 3 KB/sec upload speed x 10% = About 3.69 KB/sec upload from all that. All that talk about redundancy assumes uTorrent can know when someone will quit. It doesn't.

spapok had bt.connect_speed set to 2000 outgoing peer/seed connection attempts per second. I said ideally bt.connect_speed shouldn't be over 10, not that 20-50 were "hostile"...they are just likely less efficient and waste more bandwidth by more quickly retrying dead and firewalled peer/seed ips. uTorrent v2.0 betas recently reduced the default value of bt.connect_speed from 20 per second to 5 because they use uTP and Teredo connections which are not limited by net.max_halfopen limits. (uTP and Teredo uses UDP packets which are never in a half open state.) Otherwise, uTP alone (which is enabled outgoing by default in v2.0) could easily have 200-300 in-progress uTP connection attempts at the same time...potentially flooding marginal consumer routers and wireless connections.

spapok, Your advanced settings are hostile and should not be suggested to anyone. bt.connect_speed is the number of outgoing peer/seed connection attempts PER SECOND. Ideally, this shouldn't be over 10. net.max_halfopen defaults to 8 for a reason. 800 is too much! Incoming connections are not counted as part of bt.connect_speed or net.max_halfopen. net.utp_target_delay is how much uTorrent is allowed to increase your connection's pingtimes. 4000 milliseconds (4 seconds) will make internet access very laggy. You are probably on ADSL and have your upload speed max (as shown in your first picture) set far beyond what is possible for your connection. Most ADSL ISPs don't even give 1 megabit/second upload speed max.

TheMeekGeek, Find out if TekSavvy is available in your area. As for reducing usage, use my conservative settings guide and limit the number of torrents you download and upload monthly. Disabling DHT, Local Peer Discovery, and Resolve IPs in uTorrent may help a little as well.

Yes, they probably should use even MORE conservative settings...since the connection is shared. Do note that splitting the upload even 2 ways means each one effectively gets less than half if both are running at once.

No, the setup guides are so conservative on free upload that they should be fine as they are...and this is just a temporary bug.

cosmo87rg, go read about the cause here: http://forum.utorrent.com/viewtopic.php?id=65277

ccw said, "When ram cache is over 1800 MB, it suffers from not responding." The problem is, that's 1800 MB ram used by the cache...but doesn't count the ram uTorrent is using to keep track of everything in the cache...nor does it count uTorrent's other ram use. If you have a lot of torrents loaded (like 20+), uTorrent could still exceed 2 GB ram usage and crash.

gendouhydeist, my settings chart contains *MANY* settings. So telling me you've used them really tells me nothing. I know nothing about the capabilities of your internet connection as well.

gendouhydeist, your conditions? Hostile ISP? Few torrents? Few seeds/peers on those torrents? Private torrents/trackers? Even if the problem is a uTorrent bug, knowing the conditions that make it WORSE might help the developers.

Daetlus, Extreme settings, local peers, DHT, and even overhead estimation can cause uTorrent to use more upload than it's allowed to use for uploading torrent parts to peers.

Do you mean we should write 1-4 or simply 1, 2, 3 or 4 on that field? Pick one between 1-4. YacmanGarnd, I'm hoping you really do have at least 4 KiloBYTES/second upload...at least if nothing else is going on. That's dial-up speeds, but may be all you have. So try this: maximum upload rate = 4 kb/s global maximum number of connections = 40 maximum number of connected peers per torrent = 30 number of upload slots per torrent = 1 maximum number of active torrents = 1 maximum number of active downloads = 1 You'll get fewer but hopefully better seeds/peers connections.

Your speed test showed only ~2 megabit/sec download max. To reach 215 KiloBYTES/second download in uTorrent, you would need in excess of: 215 x 8 (bits per byte) = 1720 kilobits/second / 1024 (kilo per mega) = 1.68 megabit/second download. You won't be getting much faster than that because not every bit uTorrent receives is part of the torrent. And your upload max was terrible.

1st link in my signature, slow speed section. (It's mentioned in my guide also!) Lower net.max_halfopen in uTorrent back to 8. That article is incorrect...half open limit is how many at once, not how many per second. Also reduce bt.connect_speed from 20 per second to 1-4 per second. That is how many peer/seed ips to try to connect to per second -- it doesn't include incoming peers/seeds. If you lowered your upload speed to only 30 KB/sec, at the *LEAST* you should also lower your upload slots per torrent from 6 down to 2. Otherwise, you'll be uploading extremely slowly to others and they could snub you and refuse to upload back to you later.

1st link in my signature, slow speed section.

GabrielSylar, how fast are your speed test results on the seed box? YacmanGarnd, you need to do the speed tests with EVERYTHING else stopped/closed.

I don't know what sort of blocking methods those access points are using, but they're probably to blame for your problems rather than ComCast. Using a proxy for the tracker updates might help. Teredo/IPv6 might even work for a very few incoming IPv6 connections on very busy torrents. uTP might even help...

donwolfani, the original poster failed to realize the torrents were private torrents. He probably wasn't using a proxy. He may have been on ComCast, but conditions have changed for the better for most with respect to if/how ComCast throttles/disrupts BitTorrent traffic. I am on ComCast as well, and do not experience a BitTorrent block by them.