µTorrent 1.8.3 beta 15619

[clumba]

Getting close to RC here.

Hooray! :cool:

[5618]

Ok, it seems I have solved my RSS issues caused by going from the 1.8.2 stable to the (last 2) 1.8.3 beta(s).

The problem was caused by the (new?) "Custom Alias" settings in the "Edit Feed" dialog. By default the checkbox was checked with a blank editbox. This was causing the feed's name to be ignored and its URL to be used instead.

Furthermore, this also caused (for some weird reason) label settings in the "RSS Downloader" dialog to be ignored and the URL title (blank custom alias) to be used instead.

Also, this prevented edited data in the aforementioned "Add to Favorites" RSS popup dialog from being saved.

[rafi]

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...

[Richard Choi]

@5618: so the issue is fixed for you now? I am unclear as to the specific issue you are/were encountering...

[Switeck]

Releasing uTorrent v1.8.3 as a release candidate is a little premature until this is fixed:

http://img522.imageshack.us/img522/3038/utorrentoceanwaves2.png

http://img524.imageshack.us/img524/4208/utorrentthrottling3.png

Greg is working on it, but his current build caused an unknown crash while running but idle (no active torrents.)

[jewelisheaven]

Your wavy upload pertains to the single-upload-slot thread? I've been getting equal speeds on either beta client... then again I haven't tested them as thoroughly.

Certainly they wouldn't put out a version which still crashes... when idle

[rafi]

rchoi: so the issue is fixed ...?

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

[jewelisheaven]

This has been reported before, I guess, but... strange things happen, with a call stack I don't recognize when you stick a very large comment into uT.

ntoskrnl.exe!ExReleaseResourceLite+0x1a3

ntoskrnl.exe!PsGetContextThread+0x329

ntoskrnl.exe!FsRtlInitializeFileLock+0x83f

ntoskrnl.exe!FsRtlInitializeFileLock+0x87e

win32k.sys+0x2ef2

win32k.sys+0x1aca

win32k.sys!EngQueryPerformanceCounter+0x5af

ntoskrnl.exe!ZwYieldExecution+0xb78

ntdll.dll!KiFastSystemCallRet

utorrent-1.8.3-beta-15289.upx.exe+0x3c4ca

utorrent-1.8.3-beta-15289.upx.exe+0x502e9

Sample file Large Comment un-RAR it.

[5618]

@Richard Choi

The problem is with upgrading from 1.8.2 to 1.8.3. The RSS feeds can now be edited to have a custom alias. However, I (obviously) did not have any before and despite that, the checkbox for 'use custom alias' is still checked by default and its associated editbox blank. The results is that the feed's broadcasted name is ignored and its URL is used as a name.

Furthermore, in the RSS filter setup, if I leave the 'label' option blank it would previously add a filtered torrent to the category "No Label". However, now it will simply ignore an empty editbox and add the torrent with the RSS feed's name as label instead. So either an empty label field should add torrents under the No Label category again OR the option to not use a label should be added to the dropdown label menu in the RSS Downloader dialog.

[Switeck]

jewelisheaven said: "Your wavy upload pertains to the single-upload-slot thread?"

Yes for one. The 2 pictures show totally unrelated problems. They look similar because both have upload falling to 0. Were both unrelated problems happening at once, I'm sure results would be worse.

The 2nd picture was when uTP connections were spontaneously failing+disconnecting and killing the total upload speed momentarily because of how uTorrent regulates upload while uTP connections are present.

[Richard Choi]

Thanks for the help... I will fix this.

Edit:

@rafi: I used your .dat and did not have filter/label problems... it seemed to properly apply the labels specified by the favorites for any downloaded torrents.

@5618: When 1.8 was released, we made it default to use the feed name for pre-1.8 feeds instead of using the feed's metadata, because users may have expected the alias to be the URL. The change in 1.8.3 to automatically apply the feed's name as a label was requested by the users, so it was added. Perhaps it makes sense to add an advanced option for this behavior to turn off...

[rafi]

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

[Simon100]

uTorrent 1.8.3 beta 15289 cannot seem to get to full speed even on highly seeded linux iso torrents. As soon as I drop back to last stable release, I can then saturate my connection.

[jewelisheaven]

.. Are the peers connecting via UTP? Compare uT usage with Task Manager. What is the difference in speed data observed? (You may need to go to Select Columns and turn on Bytes sent/received per interval)

[rafi]

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 ...

[lbdude]

using 1.8.3 beta 15289

Windows 98SE

1 GHz Gateway 512MB 40GB HD

I have noticed , when I close utorrent , usually my computer stops responding, I have to restart.

I believe, its not only the newest release behaving like that , but I can't say, when or which release is problematic.

Amazingly uTorrent starts up fine, and works pretty good (occasionally got 200kB/sec Transfer rate),

but I'm afraid to close the program.

Anybody has any ideas?

My suspicion is, it has something to do with the HD-writing of all the pieces in the D/L on Exit.

Because, when I make "Pause all Torrents" and wait 1 minute or so, and then "Exit",

it usually works fine without crashing the OS.

[Switeck]

I've had it crash-on-shutdown and take out the OS too with Win 98SE.

Seems to be worse if I've run out of resources beforehand.

...Or if I've been running with LOTS of connections (80+).

Almost certainly it's something else I'm running instead of uTorrent...

Because the v1.8.3 I have often shuts down fine now.

[Firon]

New build up with a very critical bug in uTP fixed. It should work -much- better now that it doesn't try to send packets larger than the MTU. That was very likely why it would wreak havoc on your uploads, since the effect was self-induced packet loss.

[rafi]

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:

jewelisheaven:

The fix was for variable packet sizes to exceed MTU values, heh. ...

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)

kokobaroko:

-My MTU is 1500, but somehow uTorrent kept trying to send 1506 bytes UDP packets. Most of those packets went to one specific peer. By most I mean my Utorrent send 500 1506 bytes UDP packets to one peer, 7 1506 bytes UDP packets to other and 3 to third one.

There were only 2 (two) packets in 1400-1500 range during that time. Im using wireshark filters for this :

udp && (ip.src== my.ip.is.here) && (frame.len > 1400) && (frame.len <1500)

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

[ICleolion]

Somebody needs to take a serious look at net.calc_overhead because having it set to true absolutely destroys the performance of the program.

These variables never change:

bt.trans_disposition = 13

upload globally limited to 15K

1 torrent running (70 connections) from private tracker that will have no trouble maxing out my download, no utp connections have been established however during any of the following.

With net.calc_overhead on:

upload rate is relatively stable but well above the limit set. It is however no where near the max upload rate my line can handle. However my download speed never gets above 500k, which is less than half what my line is capable of.

With net.calc_overhead off:

upload rate is stable and following the limit set. and my download speed pretty much instantly reaches max, and stays there quite stable.

I can switch net.calc_overhead on and off and the change to the performance is extremely quick and v.repeatable.

So in summary, net.calc_overhead set to true is somehow choking my download.

[rafi]

"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

[ICleolion]

Hmm, I think my point may have been missed. What my max download and upload rate is, makes no difference. What my upload is limited to really doesnt make a difference as long as i have limited it to something well below my maximum so as to rule out my upload choking my download (which is why i mentioned that even though the upload rate being reported was higher than the limit i set, it was still no where near my maximum upload, so it choking my download was not the problem). These things never change, everything about my line and settings is fine and the download I had running was capable of maxing out my download. The only thing that changed was turning on and off net.calc_overhead. And as you will see below, I base my findings on what utorrent states in the uploaded and downloaded column.

When its on, my reported upload shoots up (Even though very little data is being transferred to other peers) and doesnt obey the limit i set, and my download rate goes down, never getting above half of my max speed.

When its off, my reported upload comes down (but im sending more data to other peers than i was when running with net.calc_overhead on) and obeys the limit i set, and my download rate maxes out. This happens very quickly. And as soon as i switch net.calc_overhead back on again, my performance suffers quickly again.

Now what is it that net.calc_overhead is doing to affect the performance so drastically?

[fowl]

I did a "Select all" then a right click "force recheck" it stopped all my queued (seeding) torrents and set them to Checked 0.0% (queued for recheck).

Normally when you right click a queued setting torrent it is force recheck disabled and you have to manually "stop" the torrent to recheck it. This is inconsistent. I expected that the items that would have had "recheck" disabled on their context menus would not be acted upon when multiselecting them.

Oh well my disks can take a few hundred GB of thrashing... I'm going to bed now anyway.

Is there anything we (beta testers) should be looking for/testing specifically?

[jewelisheaven]

Confirming ICLeoLion's report. About the performance. net.calc_overhead, ... massive CPU overhead. picture

FTR: net.calc_overhead is the only difference. I'm running bt.transp_disposition = 15

With a set limit of 9, calc_overhead = ON it averages 8.6-8.8, OFF it averages 9.4-9.6. I am only downloading sustained ~ 300 KiB/sec though.

[Ejziponken]

I found a annoying bug that makes auto download impossible!!

I'm using a autodownload script via mIRC and in the version 1.8.3 (build 15358) its not working because everytime it want to download i have to set the location where to put the download. And yes i have the right settings in Utorrent, but its not working anyway. Its working good in the stable 1.8.2 version.

My settings: