speeds go up and down

[BatKnight_79]

net.calc_overhead is disabled by default in 2.0

Greg Hazel, do you have any idea then on why the calc enabled forces the speed to go so down?

Bat

[Greg Hazel]

net.calc_overhead is not quite ready yet. That's why we defaulted it to disabled in 2.0.

[ausrex]

Thanks Greg

Have made the change you advised, will look forward to stable enjoyment now Thank you for your time!

[SupremeUltimatum]

(for those who's still not fixed)

Try only one torrent download at a time. Utorrent tends to download one at max speed, then lowers it to make the other one max. In short, it takes turns, unless you set the bandwidth allocation.

[epsiL0n]

Had the exact same problem since the later builds of 1.8.5. Needed to change bt.transp_disposition from 15 to 5 (i.e. set to TCP/IP only) to stop jigsaw speeds and get all my bandwidth to be used without constantly dropping to zero every several minutes.

Upgraded to 2.0, and the massive ups and downs were back. Again, changed bt.transp_disposition to 5 AND disabled "Bandwidth Management" in Bittorrent Preferences (which disables uTP)

It worked for me in 1.8.5 version (build 17414). Thank you. Meanwhile i will try other solutions, trying reenable uTP.

Cyas

[konstrukt]

I, too, am having upload speed problems. I had 1.8.5 and had bt.transp_disposititon set to 5 and all worked fine.

Upgraded to 2.0 and performance (upload) is varying greatly. I have a 50mbit fiber upload and I'm the only seeder and just hovering around 1MB/s, even thou the peers I'm connected are more than adequate to max out my 50mbit.

I tried bt.transp to 15 and to 5 and can't seem to figure out what to do. Any suggestions is appreciated.

[Firon]

Can you try setting an upload cap? One that is appropriate for your connection (assuming you have 50/50).

If that doesn't help, can you try disabling bt.tcp_rate_control?

[konstrukt]

Yes, I have that disabled already. Im also at bt.transp 15

EDIT: and my upload cap is set to 5MB/s

[Hyphenation]

I had the same problem. Both download and upload went up and down in regular spikes.

After trying a few things, what fixed the problem was:

- enabling "bandwidth management",

- setting "bt.tcp_rate_control" to "false"

- and setting a maximum download rate (I set it at 500 kB/s).

The maximum upload rate was at 37 kB/s for the whole time.

As soon as I hit "Apply" the Speed graph spiked and was pinned to the top of the graph for the rest of the download (around half an hour).

Of course, I have very limited knowledge of how all this works, so it might have been a fluke. However, if your maximum download rate is set as 0 (zero), then you could try and see if setting it changes anything.

[Switeck]

Even more confusing examples of "ocean wave" speed behavior:

http://forum.utorrent.com/viewtopic.php?id=68694

[adhoc]

Also having the same problems. Tried all the answers on offer, the one which made the difference was disabling

net.calc_overhead. Now rock steady.

Thanks to everyone

[Blinding]

I started getting these same symptoms last week. Thought it was my ISP. I made the changes in this discussion and my bandwidth is back to normal! No udp which is a shame.

Could this be triggered by some previous non-standard setting we happen to have in common? At various times people have suggested tweaking this or that and those stay set even after the need passes. I am considering deleting utorrent and installing the latest version fresh.

[Switeck]

Lots of people have "bad" settings in uTorrent which cause it to attempt lots of connections. The excess overheads causes uTP to perform worse which in turn causes uTorrent to rate limit TCP peers/seeds much lower as well.

[Blinding]

I wiped out my install of utorrent, including program and setting directories, and installed from scratch. Then I configured only the settings I knew like port, directories, bandwidth, and number of open connections. I was immediately back in the north atlantic (download speed going up and down in waves).

Based on other forum postings I cleared "Enable Bandwidth Management" and I was back to normal. Note that this does not take effect immediately. I had to stop and restart utorrent though I think if I had been patient enough the existing connections would have finished and it would have stabilized.

Switeck, could you be more specific in what you mean by "bad settings that attempt lots of connections"? What do I need to crank back?

[rafi]

My observations:

- using 2 uT instances (2.01), on the local loop-back (two ports)

- uTP download

- using a filter to use only one IP V4. All other IPs (V6) are filters but are on the peers list.

My impression - uT maybe simply disconnecting from the only connected peer in favor of other IP, thus cycling other peers that are not downloading. It should NOT disconnect from any peer unless it STARTS downloading from a different one.

[RobinRichard]

Upgrade to the latest beta.. Your problem will be solved!!! Trust me, it works!!

(Also put "bt.tcp_rate_control" to FALSE)

[rafi]

did you look at the screenshots at all ? it IS the latest beta and it IS FLASE.

[mrs.yasir]

Heyy i am new here..can u plz tell me y are the files taking ages to download??? and speed is also goin up and down but not morethan 20 kb/s

also tel me where is the icon of bandwidth??

[Switeck]

mrs.yasir, your ISP may disrupt/throttle BitTorrent heavily, your LAN networking may be bad (especially router!), you may be using bad uTorrent settings, there's some uTorrent bugs associated with uTP and uTorrent bandwidth management that makes things worse, and those torrents may just lack good seeds/peers and be slow for their own reasons.

1st and 2nd links in my signature.

[Blinding]

When I run netstat -n I do not see any UDP connections listed. Should I? I checked that the router has both TCP and UDP forwarded via upnp. (Windows XP sp3).

[rafi]

there is no such thing as a "UDP connection" at the system level. UDP is connectionless. It's all at the application (uTorrent) level .

[Blinding]

If "Enable bandwidth management" is set to true then won't the other end regulate bandwidth regardless of what other changes I make on my end?

What I mean is that if I change "bt.tcp_rate_control" or utp_target_delay on my end it will control how my end limits bandwidth. But the peers sending me data might still limit based on how they see the connection. I am thinking that the low download rates I am seeing are the peers limiting based on their connection rather than my utorrent doing any limiting.

Thus it might be inappropriate settings on the peers rather than anything I did on my end. I have my upload and download limits set to a small fraction of the available bandwidth but I know from experience that many people set no or too large limits.

[rafi]

you are right. There is little you can do for your download, since it's up to your remote seeds/peers to regulate their UL speed. Since the solution to this is for ALL your uTP peers to upgrade to the upcoming 2.01 (2.0's uTP being a bit broken), you are left with one practical option - just uncheck bittorrent->"bandwidth management" (or set advanced->bt.trasp_disposition = 13, for passive uTP) and wait for the next update-2.01-release.

[js2k6]

i was having much the same problem.

(am running windows 7 ultimate. have been since it was released. have only recently updated to utorrent 2.0)

my torrents would hit a max speed usually between 200 and 550kb/s (depending on the torrent)

it would sit at that speed for a couple of minutes and then drop down to 2kb/s or less.

except mine wouldn't seesaw back up. it would stay slow permanently.

downloaded vuze to test the torrent and they came down straight away without seesawing, consistent 400+kb/s speed. finished the torrent and uninstalled vuze cos its a piece of crap.

wiped all my utorrent settings clean. deleted utorrent.

reinstalled an old copy of 1.8.1

same problem again... speeds spiking, then falling.

so as this forum suggested, i disabled write caching. ran as administrator.

now its fine.

[Guest]

This sort of saw-tooth pattern could be a method of P2P throttling that some ISPs may be trying. File depot sites like RapidShare do the same sort of thing during high-usage times for free users: you'll notice that when you are downloading a file, you'll get ~100KB/s for a couple of seconds, then 0KB/s for a couple, and so on until the file is done (at least for big files). Some ISPs could be testing the same method for P2P traffic during high-usage times rather than simply lowering the speed limit. I don't know if this sort of start-and-stop method is better or worse—from any side (uploader, downloader, ISP)—but I would be interested in an analysis.