Jump to content

µTorrent 2.0 beta 17539


Firon

Recommended Posts

Rafi,

Being that I cannot follow what you're saying in confusion...I reckon you misunderstood me.

As-is, with net.calc_overhead=true ...if someone was already downloading at >500 KB/sec and they set their upload speed limit to 10 KB/sec, the only way to stay under that upload limit is to actually upload nothing from the torrent/s running. Even then, the real overheads would probably overrun 10 KB/sec upload speed. When actually attempted, I'd expect download speed to drop considerably due to SYN-ACK starvation. I don't have any pretty answers for this.

...But uTorrent probably should prioritize SYN-ACKs over everything else. Going to uTP or Teredo/IPv6 won't solve that either...since both have feedback mechanisms that will ALSO stall under the same conditions. I've heard download speed is now regulated by uTorrent by slightly delaying ACK replies, so some of the logic to prioritize SYN-ACKs may already exist in uTorrent.

Link to comment
Share on other sites

  • Replies 751
  • Created
  • Last Reply

Top Posters In This Topic

It is not a bug.This indicates that those buttons can't be used(will have no effect) under the current circumstances.

If you select a running torrent the Up,Down arrows,Start,Pause,Stop buttons will become active because they can manipulate the selected torrent.But if you have no torrents selected those buttons will not do anything if they are pressed so they are inactive untill you select something to manipulate with them.

I hope you understood my long explanation. :P

Link to comment
Share on other sites

Switeck:

Rafi,

Being that I cannot follow what you're saying in confusion...I reckon you misunderstood me.

Well, I think I got you now... :) We are talking about two different cases, and might have a different approach/philosophy to 'life' (in the BitTorrent net...)

Case a: a uTorrent user that has a good wide-band connection, descent upload, BUT is a leecher , and limit it to, say, 15K.

Case b: another user that is being screwed by his ISP and has a 10:1 DL/UL connection (say 1.5M/20K like many do around where I live.) He tries to share and give the 60-70% UL he can, but he likes to still be able to use the rest for surfing and such, and he also limit the UL to 15K .

I referred to case b (and I think - you referred to case a), where the calc_overhead "invention" intended to ensure a real free 40% of upload-bandwidth. In case a - I couldn't care less if his DL rate is being screwed... he can simply increase the UL limit to avoid this.

You've probably tried to help the 'case a' guy out, by making calc_overhead false...

Remember the enforced 6:1 DL/UL ratio uTorrent had in case of lower UL limit ? actually anti-leach control ? well, now , that it is gone, I also consider this calc_overhead "side-effect" of limiting the DL in case of setting low UL limit - as a similar control (though, a voluntary one) ... As such, it should also be set to TRUE by default, and we should not be recommending to modify it...!

Link to comment
Share on other sites

@ rati - true... I'm the case "b", and my net speed is 12:1 (3Mb/s down & 256Kb/s up)... and web surfing with uT 1.9 & 2.0 is very annoying, because it take all upload speed and upload limit to 15KB/s didnt work properly, to give 50% speed to other programs like Mozilla Firefox etc... ;)

Link to comment
Share on other sites

For me, utorrent don't seems to understand at all the upload limit. I set it to 50kb/s, it's uploading with 88 kb/s... Lol, anyway, it seems that setting it to 10kb/s makes utorrent to upload only something like 50kb/s what's just the right number for me :)

Link to comment
Share on other sites

Virtual_ManPL,

Reduce uTorrent's overhead traffic...

DISABLE: UPnP, NAT-PMP, DHT (both kinds), Local Peer Discovery, Resolve IPs (right-click in PEERS window of a torrent)

Reduce global and per-torrent connection max to 50 and 30.

Reduce bt.connect_speed to 1-4.

Leave net.max_halfopen set at 8.

If your upload max is set to 15 KB/sec, you can have 2 torrents active at once...without too much trouble. Just make sure upload slots per torrent are only 2 or 3.

Link to comment
Share on other sites

Virtual_ManPL,

Even seeding the same torrents indefinitely and only very slowly downloading new torrents (and removing most of them after seeding to ~2:1)...it's possible to get an increase in peer/seed traffic to your computer. Some arbitrary threshold gets crossed in bad networking hardware/software, and then things quickly go from bad to worse.

I did some testing with the ubuntu test torrent...and noticed I was getting about 1000 incoming connections PER MINUTE while it was running. That's potentially 10 times as much as typical consumer networking crap can handle. Most people don't look...or wouldn't know what to look for.

Your problem quickly goes from being an annoyance to intolerable. I don't have a definite answer...whether it be uTorrent bugs introduced in v1.9/v2.0, OLD bugs in uTorrent that got "tripped" by other conditions, bad networking stuff, hostile ISP, etc. Multiple reasons are definitely possible and likely. :(

I've previously stated (my first post on this thread in fact) that unless you make some settings changes in v2.0, results currently will likely be less-than-stellar. v2.0 operates under different pretenses (than v1.8 and earlier) on how to handle and display bandwidth overheads, and that can be painful with low-end broadband's lack of upload. Rafi and I have differing views over what likely needs to be done to fix that. (...as we're looking at different ends of the problems caused by it.)

Rafi,

The dilemma is caused entirely by what to do with overhead traffic that we know is there but is currently purely estimated. (BearShare years ago tracked that separately from regular downloads and uploads...and could be limited separately.) Tying overheads into "regular" download/upload forces uTorrent to throw one thing out or another when upload is limited "too low" to handle both download-related ACK packets on the upload side OR torrent upload traffic. If the upload limit is treated as a "soft" limit as previously, then it can be exceeded -- possibly causing trouble for web surfing. But if it's treated as a "hard" limit, something has to give.

Delaying ACK replies would slow download speed some...but which upload packets should be more important than others? uTorrent mostly hands that off to Windows to let IT worry about it. :P How much other BitTorrent-related upload traffic could be delayed or just plain dropped to keep the actual upload close to the set upload limit? This I don't know...I don't even know if there's any appreciable "savings" to be had!

Max download at the expense of upload is not a good goal. But the settings that uTorrent's Speed Guide suggests are partly to blame for it. They are optimized heavily for DOWNLOADING and give only token consideration to seeding (by limiting upload slots...semi-low).

Link to comment
Share on other sites

thx for info ;)

but you know it will be shame to use other traffic limiter to limit uT limiter (this sentence even make sense ?! lulz) ;D

IMO ppl will use this or stay with uT 1.8 when limiter didnt work like it should, like it's now

or limit upload to 1KB/s to get theirs 15KB/s e.g... it didnt make sense and make this worse for ppl who downloading for me

Link to comment
Share on other sites

I think that no one has any doubt that bugs should be fixed. UL limit should be set and obeyed. 1.9/2.0 seems to need it to be fixed. I'm sure it will be fixed soon, since the 1.8.3 code seems to work OK, and it's the code-base for here too...

The issue of overhead - was attended to, and the "rules" for it were clear - put it WITH the UL data *bellow* the limit, and give it priority (=give the DL the priority). Now, in 1.9/2.0 there is a new factor/parameter - the UDP traffic. It will eventually be ~50% of the total traffic (assuming uT is ~50% of the clients out there...). This should be put into account for the overhead equation. The goal here is the same as before - let other applications live peacefully with BT (while maximizing DL rate). Since the "roomers" are that no limitations might work best for UDP, I guess this is something to try out as well (that is - leaving it out of the overhead equation).

As to "goals" - BT network is for DOWNLOADING stuff. So that's, for me, is the primary goal. Yes, to achieve that, proper upload/seeding IS needed, and is required to work good too...

Properly adjusted settings, Switeck, are surely also needed as means for that goal. If they are wrong - you know the address to contact - the devs. So do your best as you always do ...

So I don't think we disagree on the major issues, just maybe on the "good" anti-leeching side-effect of the calc_overhead ... :)

Link to comment
Share on other sites

Hi

I am not sure if this has been reported or not yet however i notice with the beta i have MASSIVE upload rates listed, even when i am not uploading, I dont think it was anywhere near as bad with uTorrent 1.8.x

Here is a example showing how extreme it can get: http://bayimg.com/image/iadceaace.jpg

My connection is capable of doing a little over 2MB/s. Under this logic if i was downloading at my maximum from a seedbox i would be uploading at over 100KB/s, Due to the way ADSL works if i was uploading that much my download speed would be significantly lower.

My ISP also 'counts' the data i upload, and i am limited on how much i can transfer a month at full speed, therefor this is a pretty serious issue, this is likely used in alot of countries with lesser infastructure.

If this has already been reported, or its a bug, i apologize, im going to outright admit i have not read every post in this thread and dont really intend to.

I understand how overheads work, But this seems awfully extreme and not correct..

Thanks in advance.

Link to comment
Share on other sites

Duideka , do you call 30K (@1M) high overhead ? I counted 30K , since 1 peer was DLing @60K... to test it, you can try setting bt.transp_dispossition to 5 & 10 and test it separately on uTP and TCP (like in 1.8). btw, 1.8 might have not displayed the overhead for you. You can also test the DISPLAY by turning net.calc_ovehead to off.

Also - use external tool for measurmant of the rates on both 1.8 & 2.0

Link to comment
Share on other sites

It's greatful seeing a good discussion! Rafi and Switeck both have very good points.

I don't know who is right or who is wrong, IF ANY.

Fact is: v2 has "a new approach" and, right now, this have to be tried and learned by those users with one eye on the future.

I myself have been got mistaken sometimes, both at my own PC as others for whom I give some care.

After some trial and error I did achive the point, for all. And differs from one user (connection) to another.

Dev's are doing a great job, and v2 is a great work, with extreme knowledge built-in.

So, to start working with the V2, only vaguely remember the principle of operation of previous versions .. and give a chance to learn it all over again....

I'm sure you'll be very happy after all. ;)

Link to comment
Share on other sites

I've been having a problem with the latest beta, but it's more on the software side of things rather than networking. Also, please politely inform me if this is known or not if you can.

When the downloads are actively being in progress, depending on the amount of data that is being transfered, depends on the amount of the CPU useage that is in effect. In return though, it slows down all other applications when downloadind/uploading at healthy speeds. Everything from my internet browser, to media players, to games. But I did not have this problem with the last beta build nor the current live/stable release.

Also, I am running Windows Vista 64-bit, A motorola Surfboard modem, wired to a belkin router. Like I said though, have not had connection issues, it's moreso on the software compatability side of things while it operates in it's enviorment. It downloads just fine, just everything else runs crappy when it's going.

5GB Ram. Nvidia 9800 GTX OC+, and an AMD Phenom 9550 Quad.

Link to comment
Share on other sites

more info:

v.2.0 works much better with switeck`s conservative settings, this was not case with v1.8.4. or 1.8.3 on my wireless, even with poorly seeded torrents. with tcp rate control in advanced settings set to false, somehow i have 5-6 KB better downloads (i have 512/256 kB limitless connection). everything else is default.

question:

bug that shows wrong number of peers is going to be corrected or...?

for example if i have via http or udp tracker 2 peers and 1 via DHT, all together shows 12 peers.

Link to comment
Share on other sites

Firon:

The initial release notes ...

- Change: reduced uTP overhead slightly by ramping up packet sizes at lower rates

Can you/someone elaborate on what is the method here for selecting packet size ? and what is the resulted size ?

Link to comment
Share on other sites

Archived

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


×
×
  • Create New...