Archived

This topic is now archived and is closed to further replies.

Firon

µTorrent 2.0 released

Recommended Posts

I would also like to tack on as another colorblind user that is having a really hard time with the new status icons. I do think it odd that I can replace the toolbar icons and the program icon (though the new RC deleted all of my old bitmaps including these two) but no other set.

Share this post


Link to post
Share on other sites

Yahoo translation:

xacox:

Hello: I am seeding torrent with version 2.0 build 17624, and appears raising and lowering simultaneously, the problem it is that I am the initial seed. he will be bug?

bigred: I'm sure that in the next RC the user's skins would be available again, and we can all enjoy the old GUI we got used to...

http://www.utorrent.com/skins

http://forum.utorrent.com/viewtopic.php?pid=441821#p441821

Share this post


Link to post
Share on other sites

i have the same problem as xacox, but im not a initial seeder tough, just a normal peer.

the speed graph used to look like a mountain landscape until i disabled the bandwidth management in the bittorrent settings section. now the graph is a straight line going along my max ul/dl speed values.

everyone experiencing the same speed problems should try the same

Share this post


Link to post
Share on other sites

Another vote for bad icons. They aren't just ugly, but the quality isn't great... it's a bit like they haven't been designed for such a small form, more like resized to fit.

Share this post


Link to post
Share on other sites

I have the same problem as xacox and unforgiven_sh. My download speed graph is in a saw-tooth format (sometimes), like now at this moment. That's why I came to this forum. Thanks.

Share this post


Link to post
Share on other sites

Having read a bit about how uTP works, i would assume that's expected behaviour, the algorithm throttling transfer speeds according to network delay, but don't take my word on that :P

I don't know what's the real problem here though, do you want a nice graph?

Share this post


Link to post
Share on other sites

I've found, for at least the last two builds, that utorrent randomly decides to hog all the cpu indefinitely.

no file checking taking place, I come home to find everything appearing normal, just much slower.

I'd get more info, but as that pc doesn't have a monitor, and this bug makes VNC/RDP excruciating, it'd be tricky :)

Win 7 x64. uT build 17624

Share this post


Link to post
Share on other sites

2.0 shows you overhead used for uploads and downloads now by default. This will make it look like it's exceeding your limiter, but it's actually not. It's behaving exactly the same as 1.8.5.

It's just showing you the TRUE bandwidth consumption. It makes the graphs look a lot less smooth as a result. :P

Share this post


Link to post
Share on other sites

well, as I remember - the calc_overhead will not cause the display to show over the limit. It will just INCLUDE the overhead in the rate display (with the data). This was it's main purpose - to not overflow your connection with the overhead, but always have the WHOLE traffic obey the limits. The small side effect will be showing some non zero numbers when there is no data transfer.

And there should be not change from the behavior (with calc_overhead = true) in 1.8.x except for it being the default now...

Share this post


Link to post
Share on other sites

We rolled back the behavior where it throttles traffic to not exceed the limit due to overhead. It was bugged and too close to release.

Now it behaves more like 1.8.x.

Share this post


Link to post
Share on other sites

RE: #64

Yeah the way it shows the limiter is confusing. If I set it to limit to 20kB/s then i want that to be the actual, real limit of any and all data going through, is that so hard?

I have to share bandwidth with a roomate, I have to make sure I'm not hogging any bandwidth, I achieve this through knowing what my limit is, in real terms.

I set it to 13kB/s right now and it's reporting 23kB/s... that is a pretty big difference when you don't have a lot of upload speed.

Share this post


Link to post
Share on other sites

Since we're talking about the net.calc_overhead option, there is something I've been wondering about:

If I want to see only the data that the tracker sees (the data that the tracker uses to calculate my ratio), should I set net.calc_overhead to false?

I want to see the uploaded data, downloaded data, and rate that the tracker is seeing and I want my ratio and all data calculation in µTorrent to match what the tracker is seeing. Does net.calc_overhead affect uploaded MB, downloaded MB or just the rate?

Also, just to clarify because I've heard it said both ways on the forum: Does net.calc_overhead show an estimate of the overhead or the actual overhead. It would be helpful if the formula for calculating the overhead would be posted here.

Thanks!

P.S. Happy Holidays to everyone!

Share this post


Link to post
Share on other sites

>If I want to see only the data that the tracker sees (the data that the tracker uses to >calculate my ratio), should I set net.calc_overhead to false?

for the data RATE - yes , for the data #s - no

>Does net.calc_overhead affect uploaded MB, downloaded MB or just the rate?

no, just the rate

>Does net.calc_overhead show an estimate of the overhead or the actual overhead.

combined: ~5% for TCP + exact for uTP/UDP

IMHO ...

Share this post


Link to post
Share on other sites

Rafi, Firon JUST said that the functionality you are looking for is still bugged, so they rolled back to the old throttling method (where it limits transfer speeds, but does not take into account protocol overhead).

Share this post


Link to post
Share on other sites

@Zarggg: I quote:

"- Fix: download/uploader limiter issues in build 17539"

This issue is critical for all users (like myself) that has an asymmetric connection with very load upload bandwidth (like 1500/150 Kbit-ps). That's what the calc_overhead was designed to solve (and people can choose not to use it).

I expect that in an RC, being similar to the final, this will be solved (and it seems to work OK in 1.8.x).

Since 2.1 is due only in a very long time, I still say - solve it here and now. For me this version is useless w/o it!

Share this post


Link to post
Share on other sites
Guest
This topic is now closed to further replies.