kokobaroko Posted November 29, 2008 Report Share Posted November 29, 2008 something is off with upload, maybe its not counting peer exchange and DHT as trafficI set upload limit to 40KB/s and it still saturates my 65KB connection (local peers off)it shows 12KB/s upload on the graph while NetMeter shows saturated upload Link to comment Share on other sites More sharing options...
Greg Hazel Posted November 29, 2008 Report Share Posted November 29, 2008 Can you capture a Wireshark log of when that's happening? Link to comment Share on other sites More sharing options...
Troller Posted November 29, 2008 Report Share Posted November 29, 2008 I tested with only uTP on and problem was there with only TCP it's not but then I'm limited like hell and when I PAUSE all torrents the transfer goes on!!! it does not stop completely Link to comment Share on other sites More sharing options...
Ultima Posted November 29, 2008 Report Share Posted November 29, 2008 Pausing a torrent has never caused it to stop using bandwidth immediately. It attempts to complete whatever pieces it's in the middle of transferring before it actually stops. Link to comment Share on other sites More sharing options...
kokobaroko Posted November 29, 2008 Report Share Posted November 29, 2008 I ran wireshark with statictics IO Graph window openWhen I set upload limit to 50KB/s Utorrent limits TCP upload to 50KB/s , but still uploads additional 5-15KB/s UDP. even with bt.transp_disposition set to 5 - TCP onlyso its set to 50KB max, netmeter shows 57KB, and at the same time wireshark shows 50KB TCP + 7KB UDPgreen(edit, I wrote red while i was thinking green) is more less 50KB, bt.transp_disposition set to 5 Link to comment Share on other sites More sharing options...
Greg Hazel Posted November 29, 2008 Report Share Posted November 29, 2008 That extra UDP traffic could be the DHT. Turn on net.calc_overhead as well, that should make uT more accurate. Link to comment Share on other sites More sharing options...
kokobaroko Posted November 29, 2008 Report Share Posted November 29, 2008 net.calc_overhead was on beforehmm, just found out peer exchange is always on, even when its not turned off in settings anyway yes, it looks like uTorrent is not counting DHT traffic into account when limiting upload with bt.transp_disposition = 5 and DHT off there is no UDP traffic and utorrent shows more or less accurate upload speed, so that worksnow Im trying bt.transp_disposition = 255, DHT off, peer exchange off (tho its still turned on under torrent tracker status tab, maybe a bug?)as you can see utorrent tab never hits 50KB limit, yet my upload is saturated (64KB/s, my isp limits it at ~64-75KB/s) Link to comment Share on other sites More sharing options...
Troller Posted November 29, 2008 Report Share Posted November 29, 2008 in my case now i see 92k down 280 k up in the client and my monitoring software tells that i have 140k down and 392k up !!! I'll check those things in settings toughI only checked this so far: bt.transp_dispositionI had the net calc thing on false! by default now let"s see how that changes thingsStill I have a 50-70k difference between my monitoring app shows and what utorrent! Link to comment Share on other sites More sharing options...
kokobaroko Posted November 29, 2008 Report Share Posted November 29, 2008 again about peer exchange, turning it off in settings only rworks for SEEDED torrents , those show nice "not allowed" under Tracker tab, but torrents that are downloaded show peer exchange as "working"last screenie, 1.8.1 with DHT enabled and 50KB limit setmuch less UDP even with DHT enabled and keeps nice smooth ~50KB/s .. well more like 55KB/s, but still its a lot smoother Link to comment Share on other sites More sharing options...
Troller Posted November 29, 2008 Report Share Posted November 29, 2008 in 1.81 I was unable to get the uTP to work, my issues are with the newest beta 13521 build Link to comment Share on other sites More sharing options...
Ver Greeneyes Posted November 29, 2008 Report Share Posted November 29, 2008 I've tried build 13485 but it seems to take complete control of my connection after a few minutes, making me unable to browse the web even from my laptop (both are connected to the same router). This seems to happen regardless of what I set bt.transp_disposition to (I've tried 255 and 5). µTorrent continues to function on both machines, however. (my laptop was using 1.8.1 at the time) This problem did not exist in 1.8.1. Should I try build 13520? This is not a problem I've seen mentioned here, so I'm not sure if it would help. (Also I'd rather not try 1.9 again until this problem is fixed, as I'm heavily reliant on having internet access - but if you think it'll help I'll take one for the team) Link to comment Share on other sites More sharing options...
Ultima Posted November 30, 2008 Report Share Posted November 30, 2008 Try 13520 for a few minutes (to get the logs, doing as the instructions say in the first post). More logs should help in analyzing real-world behaviors that may not have been caught in internal testing. Link to comment Share on other sites More sharing options...
Ver Greeneyes Posted November 30, 2008 Report Share Posted November 30, 2008 Here you go. I hope this isn't too big, it took a while for a pattern to emerge. Upload speeds fluctuated between ~75kiB/s and ~105kiB/s - normally I can easily do 175kiB/s. As before, browsing the web became impossible only a few minutes after starting µTorrent.By the way after closing µTorrent, explorer.exe was using about 125MiB and maxing out a core. I kept an eye on it and watched as it slowly (very slowly) returned to ~40MiB before CPU utilisation finally dropped. This took perhaps 30 minutes, during which the system slowed to a crawl. Link to comment Share on other sites More sharing options...
arbitel Posted November 30, 2008 Report Share Posted November 30, 2008 Tested build 13485 for few days. Everything seems okay but only a few problems which are kinda annoying.1) When bt.trans_disposition is set to 255, the uTorrent.exe tends to lag alot and the cpu usage skyrocketed. When I set it back to 0, everything went back to normal. I wonder if that makes any difference in downloading speed cause I don't really notice.. ?2) When bt.trans_disposition is set to 255, the Tracker status keeps on showing 'updating' and I guess that is what causing the cpu usage hog. Any idea guys?Thanks for the wonderful uTorrent.Regards,arbitel Link to comment Share on other sites More sharing options...
Troller Posted November 30, 2008 Report Share Posted November 30, 2008 The 13520 build instantly locked up for me with 100% cpu usage. I think something is about the new uTP protocol and with the 521 build I get cpu spikes. And even without that 50-70k that utorrent does not count as traffic somehow, it's far more better then the 1.81 version where I was totally limited to 10k upload. Link to comment Share on other sites More sharing options...
osm0sis Posted November 30, 2008 Report Share Posted November 30, 2008 Both of those are only meant to capture the traffic in logs, might explain the CPU.. 13485 is the actual current alpha still. Link to comment Share on other sites More sharing options...
Switeck Posted November 30, 2008 Report Share Posted November 30, 2008 Tested build 13485 on Win XP Pro AND Win 98SE. Both experienced freezing on exit where the exe remained in memory 5+ minutes after the GUI disappeared. (I noticed this using Process Explorer.)I also see essentially impossible ips in Peer Lists (from right-clicking in the Peer window of an active torrent, Copy Peer List, and pasting into notepad).I also copied this from uTorrent's LOGGER, confirming these ips are attempted:[2008-11-29 21:22:07] 0.56.58.0:12389 [utp]: Connecting: source: T[2008-11-29 21:22:16] 0.116.101.105:13413 [utp]: Connecting: source: TThese "appear" to originate from the tracker, but since I've used these trackers before...it seems unusual for them to only now start having trouble. Link to comment Share on other sites More sharing options...
Gonzo68 Posted November 30, 2008 Report Share Posted November 30, 2008 I did install build 13485 got no crash or bug but download/upload speed went down too much and i went back to 1.8.1 I will wait until a couple of more build come up before thinking to install it back Link to comment Share on other sites More sharing options...
GTHK Posted December 1, 2008 Report Share Posted December 1, 2008 Copied this from my Logger after some RSS feed matches:[2008-11-30 20:42:45] 灨Ɔw Download from RSS|stuff2.avi has started downloading.[2008-11-30 22:12:48] 㬠¶w Download from RSS|stuff1.avi has started downloading. Link to comment Share on other sites More sharing options...
Simon Morris Posted December 1, 2008 Report Share Posted December 1, 2008 A comment from BitTorrent on UTP:Firon posted already about UTP:******uTP, the micro transport protocol. This UDP-based reliable transport is designed to minimize latency, but still maximize bandwidth when the latency is not excessive. We use this for communication between peers instead of TCP, if both sides support it. In addition, we use information from this transport, if active, to control the transfer rate of TCP connections. This means uTorrent, when using uTP, should not kill your net connection - even if you do not set any rate limits.******Just to re-iterate and offer a few more details (there's some pretty wild press reports popping up):Firon described uTP completely accurately. uTP is the result of a couple of years of work to try to make a Bittorrent protocol that works better on the internet. The switch to uTP is at this point purely experimental, but the design objective (counter to some reports in the press) is actually to offer better congestion control than TCP offers, but maintain the same level of performance (speed). Better congestion control is good for everyone – for users (VOIP, Gamers etc.) as well as for ISPs. Same performance is what users have come to expect from their BitTorrent application – unless we can offer the same performance, then people will switch to a different BitTorrent client. (In reality we may be able to offer faster speeds too in many circumstances, but this is a byproduct and not the main objective.)uTP is our UDP-based implementation of the BitTorrent protocol. Normally BitTorrent is implemented on top of TCP which is the standard congestion control mechanism for the internet. It so happens that the congestion control mechanism inside TCP is quite crude and problematic. It only detects congestion on the internet once "packet loss" has occurred – i.e. once the user has lost data and (probably) noticed there is a problem. The problems of TCP are fairly well known in technical circles, but it doesn't get fixed as TCP is one of those protocols that is implemented in every OS, client and server, on the internet. Co-ordinating a giant upgrade is a very long process. Because BitTorrent publishes the world's most popular BitTorrent clients AND because these clients are talking mostly to each other (not to web servers), then we have an opportunity to detect end-to-end congestion and implement a protocol that can detect problems very quickly and throttle back accordingly so that BitTorrent doesn't slow down the internet connection and Gamers and VOIP users don't notice any problems. This is our objective. This is great news for users of the internet and even for ISPs as it should mean that people make far more efficient use of internet bandwidth, but don't over-use it to destruction. If uTP is successful, then internet congestion due to BitTorrent protocol could become a thing of the past. Of course there are many other applications that use the internet and they may also cause congestion, but we can only control what we do. Having said that, given that some press reports suggest that BitTorrent traffic constitutes half of all traffic on the internet, our technology might have a profound impact. We're trying to do our bit to be responsible citizens on the internet. While uTP is for now a proprietary BitTorrent protocol, we are also co-chairing an IETF group to address these issues. Hopefully that will lead to solutions that can be standardized and broadly adopted in due course. Simon MorrisVP Product ManagementBitTorrent, Inc. Link to comment Share on other sites More sharing options...
Harold Posted December 1, 2008 Report Share Posted December 1, 2008 So is there any chance that 'interested parties' will be shown how the uTP protocol works before it's a full-blown IETF standard? Link to comment Share on other sites More sharing options...
gritzko Posted December 1, 2008 Report Share Posted December 1, 2008 There are some IETF talks by Shalunov http://shlang.com/talks/20080528-BitTorrent-position-IETF-P2P.pdfhttp://shlang.com/talks/20080528-ietf-p2pi-BitTorrent-slides.pdfThe general line is that they are using their previous BitTorrent DNA developments on delay-based congestion control. DNA protocol is kinda proprietary and secret as well... but the whole stuff looks like a lightweight implementation of TCP over UDP with delay-based congestion control and probably some P4P-like topology hints in the future.Still, declaring they wanna it be a standard and keeping it sikrit at the same time is kinda strange. Link to comment Share on other sites More sharing options...
DreadWingKnight Posted December 1, 2008 Report Share Posted December 1, 2008 I don't blame anyone for not wanting a beta product to be widespread. Until it's stabilized and fully functional, they have every right to keep is secret. Link to comment Share on other sites More sharing options...
kokobaroko Posted December 1, 2008 Report Share Posted December 1, 2008 >Better congestion control is good for everyonebefore _any_ congestion control can be implemented uTorrrent must first start to count traffic correctly, currently it forgets about half the UDP packets it sends Link to comment Share on other sites More sharing options...
Harold Posted December 1, 2008 Report Share Posted December 1, 2008 Many thanks, gritzko It doesn't say very much, but it's somethingBut, seeing as the actual protocol seems to be secret (and rather hard to reverse-engineer, I don't expect to pull that off before the RFC is released, unless it really takes half a year or something), is there any idea when it might be ready? Of course I'm not expecting any promisses, but it'd be nice to have some kind of idea as to when it might be ready.. Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.