rafi

two issues: 1. updating with tracker scrape I open a torrent, and then start to download it (manually). It looks like at this point - the seeds/peers list is NOT being updated at all by the active tracker(s). ONLY after the first update of the tracker (like 30-60 seconds later) the "scrape OK" message appears and seeds/peers lists are being updated and seen in the main view. I'm not sure exactly under what conditions this happen but it seems that this happens mostly when another download and seeding tasks are active or also when you start uT program and DLs are starting then. A tracker problem ? a uT issue ? Just messages getting lost in the Internet ? ... 2. keeping to the download limit when in uTP mode only It looks like uT is still setting the DL speed to 15-20% below the set limit (uTP only mode) edit: and bug reported on IRC: http://forum.utorrent.com/viewtopic.php?pid=413323#p413323 edit(2): ... and a dump from a crash that just occured ... XP/SP2 ; operation: selected two seeding torrent -> stop -> & immediatly - delete+delete data on both ... http://www.mediafire.com/?zxz12yxoux5

An interesting issue! Can 1.8.3 serve as a kind of 1.9 "replacement" as far as uTP is concerned ? hmmm... this can be an interesting experiment I say - yes, try this on this beta and make it so that ~5%-10% of the upgrades will set 15 as the default.Then issue another release that either cancel it or goes to 100% if successful

hmmm.. still... no crashes on XP ... nice ... btw, I'm confused - how come I see in uT higher DL speed with calc_overhead ON then when I set it to OFF (actual ext. measured speed is the same) ? shouldn't it be the opposite ?

to what might be a similar crash ?

@hermanm: http://forum.utorrent.com/viewtopic.php?pid=411970#p411970

NOT confirmed over here (XP/SP2)

about the memory issue - I cannot confirm it. On XP SP2 - I have both releases consume about 19.5M RAM.

is it a 1.8.3 issue or was it in 1.8.2 as well ?

trying again uTP only & TCP only in the latest release: still differ in DL speed ... By rafi_d

a small request: can you fix the issue of RSS downloader not setting the correct "added on" time in the next beta ? it's really a small thing but messes up the torrents' order, and sorting (being sometimes a day early). If we want the RSS feed-item time, lets' have a dedicated column for it, and not the "added on" column. Thanks you

if the end result is -~20% in DL speed under TCP @ 1.5Mbps (as you can see on the graphs in the 1.8.3 thread http://forum.utorrent.com/viewtopic.php?pid=408454#p408454 ) I think it should be further tuned. ~60-70% of the Internet subscribers here are on 1.5-2.0M speeds with 10% of that - upload .

well, what about the opposite symptom - of only using small packets ... am I mistaken here as well ? ... or there is a logical explanation to this ? ( http://forum.utorrent.com/viewtopic.php?pid=408454#p408454 @ the bottom of the post...)

"no where near the max upload" - why should it be ? you have set a limit to it. what you see in uT graph (which I assume you base your findings on) is not what you really have . You should measure with an external tool to see the traffic *including* the overhead so to deduct if uT works OK. edit(some other bugs): a small RSS issue: ---------------- "added on" should display the time the torrent was added to uTorrent right ? well, when RSS auto-start a download - it seems not to put the correct time. I guess it's some time stamp taken from the feed instead of the local time of starting the download. still - upload limit issue: --------------------- Running with only uTP mode (trans_disposition=10), calc_overhead=true - I tried setting a limit and then zeroing it (no limit). it will not reset to no limit as long as the torrent is running, only stopping and starting the torret - reset the UL limit. NOte: with TCP only - this issue does not exist. By rafi_dBy rafi_d By rafi_d

deleted ..

sounds logical, since the modification to maximize UDP packets was only done to 1.9 and 1.8.3. Most your "other" peers are 1.8.2, that is using smaller packets.

what new installer ? the Ask toolbar installer ? I thought they were beta-testing it on the 1.8.2 tree... so not to bother beta testers with this (yet...) .

what's the default value of - rss.feed_as_default_label ? edit: ok, default is 'true'... I hope it was well tested with 1.8.2 upgrading to 1.8.3 ... edit(2): same test as before (more or less) - still - DL rate is much inferior in uTP then TCP. So please, keep on the good work... and one more - to show possible upload issues (1 DLing torrent, 2 upload slots) : By rafi_d and to another issue - the MTU size optimization: if this was back-ported to 1.9, reading reports from the 1.9 thread makes me wonder if it is really fixed... http://forum.utorrent.com/viewtopic.php?pid=408725#p408725 (from the 1.9 thread) Trying to see the packet sizes while seeding (MTU 1492) , I was not able to catch even one packet of more then 700 bytes. I was expecting some to be near my MTU size. Out of ~68000 packets, most (~62000) were ~250 bytes. few (~650) were ~350 bytes, and some (~20) ~665 bytes

the graphs allready show both uTP and TCP only modes + NetMeter (==task-manager) . Too bad I did not have calc_overhead true (as it should be per it's default) but, it really helps in comparing to the externally measured values... edit: @devs: is it possible for you to add the trans_disposition value in the peers' tab for each uT peer so we can see if the uTP->TCP logic works OK ? as a column or maybe just in debug column ? Or maybe it's not possible to do that ...

cause you firewalled your UDP traffic to this machine's port ? ...

This dat was from May-2008 (the only old one I had) . You might need to install a clean 1.8.2 release (or an older the 5/2008 release) and then upgrade to 1.8.3 edit (2-May): ------------ following this post here: http://forum.utorrent.com/viewtopic.php?pid=405726#p405726 here are more performance tests to see the diff in DL performance uTP (only) performance with and w/o UL limit and then TCP only. this time, it's seems that the conditions were ideal - - uT with 2 slots/torrent 300/800 connections max (not relevant here since not so many were not utilized) , net.calc_overhead - false - still.. 190/19KBps connection - 2 active torrents -- 1 a bit rare, minimal activity -- 1 with very good s/p ratio - DLing/connecting mostly to seeds - very low UL activity, not reaching my ISP cap (so we can unleash the limit for testing... ) comments on the test sequence: (look inside the graphs for more details...) 1: TCP only (bt.trans_disposition=5) , with 10K UL limit - ideal for my package, maximum DL utilization (similar to 1.8.2), about 10K TCP DL overhead (~5%) 2: uTP only (bt.trans_disposition=10) , still with 10K UL limit - DL rate dropped to ~140K (actual 160), erratic behavior, not reaching my connection DL max 3: uTP only (as in 2) , with NO UL limit - DL rate increased to 165K, smooth behavior, actual ~190 K (~15% overhead) capped by my ISP limit 4: as in 1 , but staying with no UL limit . results are similar to 1 BUT a bit less DL speed. My conclusions: Since working w/o UL limit is a luxury I cannot usually afford (when s/p ratio is not so good), we MUST improve the uTP performance when the UL limiter is ON . uTP should reach the TCP performance here, otherwise - I don't see a big benefit in using it (unless it does good when your ISP is capping your P2P traffic ). zooming in... and... just for the record.... this was a VERY untypical torrent-case here... usually, on popular torrent we can get only a fraction of that speed over here.. more like this one: http://img381.imageshack.us/my.php?image=54201736.jpg

Probably not. It happens if you upgrade from 1.8.2, and you had defined your own labels per fav. as well as your own feeds' aliases. Your new change of auto-aliasing feeds with the feeds' URL, was showing as blank but enabled edit box (instead of the old alias, in the feed's edit dialog), and this side effected in the old user label being not used . To emulate it - you have to start with a 1.8.2 version having aliased feeds and fav labels. you can use an old RSS DAT file I have if you like ... http://www.mediafire.com/?rwjk5zzjinf

sounds like an RC breaker to me... lot's of people will complain on ruining their labels ... I remember now, that I also had to manually correct all my labels by adjusting the feed-edit box as you just said ... and didn't bother to report that, cause it feels like no dev is reading this thread these days... probably have their hands full with toolbar issues...

seems like it IS important to Bittorrent. I'm sure that when you'll get 1.8.3/1.9 (now in pre-RC/Beta) they will all be inside, (as they should have been in the first place...) together with the important changes. So, better read and learn from others so to be able to tell what's important and what is not...

an issue with 1.8.3 - the new build 15289 (and maybe older ones too?): setting bt.trans_disposition to 5 (only TCP) seems have strange effect... new connections are fewer and far from the specified max # of connections (like 40-50%) and also the increase rate in connections # is very slow setting it to 15 (TCP+uTP) - seems to improve the issue (like 70-80% of the #, and faster increase rate).

thanks. will try it out. Glad to say that I never encountered any of those crashes ... I thought it was a beta aimed as a platform (base for 1.9) mainly to test issues of uTP ? was/will post #205 be tested here ? I think this 1.8 release will coexist with 1.9 so this issue will manifest itself as more 1.9 users are active. I suggest to tune the uTP speed/limits a bit better ...