rafi

Total # of connections - seems strange... (I'm not sure this is the place for this issue, since it may concert 1.9 as well, so feel free to move it. ) I have set as maximum connections (for this test) - 300 per torrent and 900 overall . - When I download one torrent - it gets to about ~220 connections (max DLs Q = 1) - Then I set the max DLs Q to 2 - and activate another download - at this point I expect to have double the amount of total connections, but - after a while, this is what I get: The total remains the same - ~200 or ~100 per torrent. What can be the problem ? some kind of bug ?

will it be available concurrently for 1.9 ?

Can't you read ? Firon just said they reverted back to build 153 due to problems... And to your issue - maybe one of your RSS feeds/filters downloads it ? edit: just got this debian here too... edit2: GFree- the first 'question' was aimed at those commenting about the "old" build #...

the issue on my system occurred when I had 3-4 downloads going. Maybe the upload due to download overhead + upload slots chocked it... (1500/150 connection)

so, it's bad news for uTP ... at least calc_overhead is more or less correct... I hope for download tasks uTP is more efficiant... the claim is that uTP is better with not blocking your other Internet traffic on your PC. I'm not sure it's so with this Alfa ( yet... ) at least on my poor 1500/150 connection...

KSU, calc_overhead should make the limits you've set - be obeyed better. I think it should also display more currently the real traffic-rate (including overhead). So, not *seeing* this DL rate, does not mean it doesn't exist ... 1. measuring with an external tool - will give you indication of what is really the rate out there (and not just closing your eyes/viewer...) 2. when you switch to TCP (yes, stop and restart the torrent) , you can see which is better (less overhead...). They might be similar ...

it means that for 84K upload uTorrent use 12K overhead using the uTP protocol (if he is not mistaken) . Things you can probably do: 1. measure this with some external tool (see if it calculated it right or wrong) 2. set net.calc_overhear to false, see if this made it calculate this so ... 3. turn uTP off (see first post) and see if my theory was correct... I'm sure your efforts Will be much appreciated by the devs...

no, thanks ...

why don't you just wait like the rest of us ?... (you can get back to 1.8.2 for the time being like I did ...)

was there any Brain damage ? ... this doesn't work, since only the router (and not any individual PC application) can manage the network QoS/load .

I don't think there is such thing as uTP (which is UDP...) priority on a public network. You can control it only on your own PC. And why don't you just try to use 1.9 instead ? ...

shnur: it I knew what's the deal here on 1.8.2 - I wouldn't ask.... do YOU know ? so, 0 = 255 ok. 3 = 10 , and the "5" (TCP only) ? ...

I've just installed it and it was 0 as default... !? why do we have to guess... it's simpler to just write it down at the first post here (0/1/2/3=...)

what is the value for the standard support for both uTP & TCP ?

I have defined max of 200 connected peers per download, I have 1 download going and I get ~150 connected peers, then I see the connectING statistics drops to 0 (or close) . For testing I increased the max # of peers to 500, and immediately got ~10-12 connectING uTP/TCP peers. See screen-shots. Why is that ? I expect to see none 0 number of connecting peers all the times as long as I don't reach my defined max. Does this indicate some kind of bug ?

two issues: 1) New: uT is not keeping the download speed limit on individual torrent in the following case: - limit the torrent and download - pause the torrent for a minute - continue with a "good" torrent, at this point, the speed rockets, and only after a minute or so - returned to the set limit. I guess there is some math problem in this scenario 2) Old: effecting of Internet traffic when 3-4 torrents are downloading (~200-300 connections, 14K UL limit, 20K max UL, XP SP2 patched to 100 connections/sec) This issues was already mentioned. I just wanted to add another aspect/side-effect - when you have RSS on (like I do...) and about 8-10 feeds, when there are those 3-4 downloads going, the RSS scanner itself starts issuing time-out messages for most feeds, and cannot get to scan them. As soon as I pause/stop the downloads it regains conciensnes...

Did you have your download/upload limits set to anything ?

opsss... , my mistake...

Kurahashi: wrong thread... http://forum.utorrent.com/viewtopic.php?id=49813&p=20

Do you see any issues with the 18K Upload limit ? When I had 4 torrents downloading, I had to reduce the limit so to be able to use the browser.

Gerg, I have already reported this issue here: http://forum.utorrent.com/viewtopic.php?pid=388486#p388486 . I'm not 100% sure, but it's what I get on netmeter... it's seems more like spikes of higher upload rates, not constantly. Let him try and see... edit: .. and on the other hand - I can be completely off course here...

sound like my kind of connection... with similar problems... Try set the limit lower and re-check. I think the limit is not being obeyed accurately.

in uTP - is the uTP header effected by the encryption setup same as in TCP ?

the horrible +10msec ping delay ? ... just kidding .... anything new with the issue of following more closely the UL limit ? PS/edit: With our poor connections here (~20KB max) when I set it to 14, it reaches it from time to time and get web pages not to open ... (yes, in spite of the UDP theory...)

he probably wants to disable it ...