Jump to content

Switeck

Established Members
  • Posts

    24,331
  • Joined

  • Last visited

Everything posted by Switeck

  1. Larry Lock, As far as the consumer connection you're posting on is concerned: http://forum.utorrent.com/viewtopic.php?id=46778 ...more specifically this in that thread: http://forum.utorrent.com/viewtopic.php?pid=362432#p362432
  2. No, that's Cox's BURST speeds in the speed test. Your real sustainable upload speed may be only about 1/2 to 1/5th as much.
  3. Step said, "I don't know may be it don't matter but I see how peers connecting and then immediately disconnects even when they have less 10% done" ...is a classic example of an ISP disrupting BitTorrent traffic. A bad/misconfigured software firewall or bad networking hardware could remotely cause this too.
  4. Step, can you tell me if you're having troubles with tracker updates in v1.8.5? Without more information about where your connection failures are occurring, your report is sadly useless.
  5. Trystian, test with uTP *AND* Teredo/IPv6 disabled...chances are your networking is too weak to handle them.
  6. If you get a green light in uTorrent, you shouldn't need more than probably 15 minutes at worst to get half of the peers/seeds on the torrent connected to you. I'm inclined to believe your ISP may be hostile...
  7. I often hit max speeds within 2 minutes of starting uTorrent. But I only have ~10 running and ~40 stopped torrents.
  8. Your upload speed maxes out around 60 KB/sec? (not a good idea to tell uTorrent to upload faster than your line allows.) net.max_halfopen = 8 should be sufficient unless you have other problems. Do you always get a green light (unfirewalled) in uTorrent?
  9. Unlimited upload speed can cause problems. v1.7.7 may not hammer whatever real upload max you have, causing it to drop less in speed when your ISP forcibly corrects it. So you're allowing up to 50 outgoing peer/seed ip connections at once (net.max_halfopen), and creating 20 new outgoing ones per second (bt.connect_speed). This does not count however fast you're also getting incoming connections. I would imagine all those connection attempts (which use mostly upload) would reduce how much of the torrents you can upload. The disk cache settings are bizarre. Reduce memory when cache isn't needed? It'd only use 32 MB max, the default max. Disk read caching is completely disabled?
  10. Step, what are your uTorrent settings? (as shown by CTRL+G Speed Guide and any advanced settings you've changed from default) It'd be nice to know what they are to see if/why they're not working...
  11. ISPs count overheads against max bandwidth limits. Some are overprovisioned -- they say you get a 1.5 megabit/sec download line, but actually allocate 1.6-2 megabit/sec so even after overheads you're likely to get 1.5 megabit/sec usable download bandwidth. These estimated overheads can and have caused limit overruns. People would set upload speed limit really low and just by downloading quickly the upload max limit was exceeded.
  12. Working as designed. The communication traffic necessary to maintain the connections grows in direct proportion to the download or upload speed. Previously, it was hidden because it's a natural part of TCP connections. Now, with net.calc_overhead set to true by default...uTorrent tries to estimate the overheads. The figures aren't exact, they might even be off by +/-50% for all I know, but they do represent the significant reply traffic generated by downloading quickly.
  13. That is because you have so little upload relative to max download.
  14. Vuze would be essentially a dead BitTorrent client *IF* the BitTorrent portions of Vuze are no longer being bugfixed and new BT features are not being added. It would be a dead client if the company associated with it fails/shuts down. (Though some 3rd party could resurrect the source code and update it.)
  15. If there's big speed differences between v1.8.4/v1.8.5 stable, v2.0 beta, and v2.1 alpha ...it's probably due to uTP/Teredo support. Both are disabled by default (though uTP incoming is allowed) in v1.8.4 and v1.8.5.
  16. A couple extra speeds were added by the uTorrent v2.0 beta.
  17. Healy, If you have 300+ peers trying to connect to you, they will try and retry your ip about once per minute. This means roughly 5 peers trying to connect per second. I don't know what I'm looking for, because your conditions are probably a rare combination in some way...so I don't have any answers yet. What uTorrent settings are you using, as shown by Speed Guide (CTRL+G) as well as any advanced settings you've changed?
  18. Healy, I feel like there's some important information we're missing or overlooking. What is your software firewall/s and Antivirus/s? What Windows OS? How many torrents do/did you have running? ...And roughly how many total seeds/peers were on these torrents? A very high incoming connection rate could noticeably increase both download and upload values in the Speed graph window/tab, but they would not increase how fast you're downloading/uploading torrents.
  19. Healy, disable uTP *AND* restart uTorrent. Set net.calc_overhead to false. Try redoing your other settings based on the 2nd link in my signature.
  20. Synbios, try disabling uTP connections.
  21. There are Vuze versions which can run both DHT types to bridge the gap, so there is even LESS reason to impliment Azureus DHT.
  22. .39 mbit/sec upload => 384 kbit/sec upload settings, so use them.
  23. Yes, bt.tcp_rate_control = false What about disabling uTP outgoing?
×
×
  • Create New...