Archived

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

Firon

µTorrent 3.1 Release Candidate 11

Recommended Posts

"Move completed downloads to:" doesn't update the Save Directory column:

http://img341.imageshack.us/img341/3773/savedirectory.th.jpg

Still present in 26495.

WindowMenu opened on Update Tracker:

http://img573.imageshack.us/img573/9633/windowmenu.th.jpg

Select a not empty category in category list, right click on Torrents and click on Update Trackers.

Still present in 26495.

bye

Share this post


Link to post
Share on other sites
New client up and officially release candidate now!

We believe we've fixed the 99% issues' date=' but please let us know if it's still happening.[/quote']

I'm unsure what sparse actually does, but it's not enabling itself on Windows 8 (WinNT v6.2) so you may want your check to be a greater than ">" instead of an equal to.

Also, should it be enabled when using an SSD, or doesn't it make a difference?

Currently, we don't support Windows 8. We haven't tried it at all.

It'll cause less writes, so yes, good to enable on an SSD.

Share this post


Link to post
Share on other sites

also a gui bug: when looking at a torrent with no label in "No Label" category, then change it's label... It still remains in No Label category unless I go to another category and then return to "No Label".

Share this post


Link to post
Share on other sites

i was running 3.01 .. and decided to try this new RC1 ...

after install .. - not sure what happened (maybe it crashed ?) .. but torrents were screwed up.. instead of 2800 or so i had only 2499 (among which few hundred were "Error:...", on which i noticed were some torrents that i already deleted . .and have taken files off this hard drive..

not knowing what to do.. i end up .. deleting all those Error ones.. after which the difference between what i had before and now was like about 500 or so ...

Then i went to that %AppData%\uTorrent dir and noticed all of the torrents that missing there on top (if sorted "sort by date" (or something like that)...

so i put 3.01 back (and never by the way happened to me like that before.. i often change versions from 1 to 2 from 2 to 3 etc.. usually to the newest one (or the one that i happen to like (unlike some people who still stay with 1.82)

in any case.. - i am not big expert with all that.. - so i ended up doing those 500 or so - manually / by hand / one by one loaded them back in utorrent .. either in the "Stopped mode" .. or in "Seeding mode" (as they were there previously ..

Firstly i RAR them in one RAR file.. and then UnRAR then in a separate dir (not to mix up wiith other 2300 torrents)

Took me long time - but i think i put them all back now .. could have been worse .. i described my problem about this HERE btw: http://forum.utorrent.com/viewtopic.php?id=109074

.. and does anyone know,

Is there a limit on how many .torrents one can keep in uTorrent?

Like if i have in my uTorrent - around 2800 (probably more than half simply in a "Stopped" mode, never downloaded yet.. and the rest downloaded and are in Seeding or Queued Seed mode) .. is it OK to have that many there?

and if it's OK .. what's there limit anyhow? (if there is one of course) .. or what's recommended?

Seems to be working anyhow .. with that many .torrents loaded in uTorrent :)

Thanks

Running Vista (32 bit) by the way

Share this post


Link to post
Share on other sites

Firon

Currently, we don't support Windows 8. We haven't tried it at all.

But won't you tell me why all the builds before 26419 worked well on Win8, and all subsequent don't?

Share this post


Link to post
Share on other sites
But won't you tell me why all the builds before 26419 worked well on Win8, and all subsequent don't?

Maybe it is due to this change:

-- 2011-11-22: Version 3.1 Release Candidate 1 (build 26495)

- Change: enable windows disk cache for writes by default. Improves write performance, especially with sparse files

- Change: enable sparse files by default on win7 (disabled on vista because of filesystem bugs). This should fix most disk-overload issues

You can try revert these settings, see what happens

Share this post


Link to post
Share on other sites

rafi

You can try revert these settings, see what happens

I would try if RC1 let me at least install itself ;)

So first I have to migrate back to 26419...

Share this post


Link to post
Share on other sites

I guess it will not be that easy. Changing of a default setting will auto-set in a new release. You can just set them intentionally so in 26419, and confirm. Or try a clean install to see if it is maybe some other setting .

Share this post


Link to post
Share on other sites
Amazed you've gone to RC1 with fundamental issues like hashfails and slow rechecks!

All still happening.

Because BT devs are more interested in adding bloat crap to uTorrent then fixing issues and improving optimization.

Why the hell cant we have a light version that resembles the real utorrent and keep all this other stuff like streaming and stuff to the PLUS version?

Share this post


Link to post
Share on other sites

one more bug to mention (since all versions I believe)

I have my directories setup in an unorthodox manner.

put new downloads in "c:\downloads\__incomplete__"

move completed downloads to "c:\downloads"

store new torrents in "c:\downloads\__torrent__"

of 1000 torrents downloaded, bout 50 don't get moved from "c:\downloads\__incomplete__" to "c:\downloads"

It's surely not because I have explorer in that folder so it gets locked out, no. This is on a 'server' where nothing else runs. I did notice that, "starting" the torrent then "stopping" it again helps.

If I were to guess what the problem is, the file was probably seeding the exact same time it completes (tries to move folder)

Share this post


Link to post
Share on other sites
deleted

You mean the whole RC1? ;)

My post, but yeah, RC1 too ... :) I am not worried, they'll refresh it soon enough... and I'll get a chance to restore the deleted one... :P

Share this post


Link to post
Share on other sites

thanks for all the feedback on 3.1 so far. These are the theories we're working on right now. Feel free to comment on this if you have some relevant evidence that may contradict this.

The disk subsystem appears to be slow, which causes a number of symptoms:

1. Stuck at 99.9% (which is a special case to mean "we're done downloading, now we're just waiting for all the pieces in the write cache to be flushed to disk"). This mode has been changed to be an explicit torrent status. It will even tell you the number of disk jobs left to be flushed (this is in the next release, as soon as firon gets around to putting it up).

2. stuck at checking 0%, similarly, if the disk subsystem is slow, the read jobs won't return very soon and may get stalled for quite a while. There was also a GUI bug causing checking torrent specifically to be a bit messed up (also fixed in the coming RC2). Also, keep in mind that we only check one torrent at a time, if you force recheck all your torrents, it's only expected that one of them actually are moving. I think it would make sense to make this torrent state more explicit as well, by making the idle ones say "queued checking" or something.

Now, why would the disk io subsystem be slow (or even lock up?). I'm not entirely sure. If anyone get a legitimate hang, where there's no disk activity and uT is still not able to flush, please dump the process, record its build number and post it here so I can figure out what it's doing.

There are however a few factors that we've seen that may contribute to the disk io being slow:

1. sparse_files are not used by default. This means, whenever you start downloading a 5 Gig file, the first flush to disk will block, and windows will write 2.5 Gigs of zeroes to the filesystem on average. This can take quite a while on a normal laptop hard drive, several minutes actually. When windows is doing this, it's holding up uT's disk thread, causing disk overload to reach 100% (as soon as the write cache fills up). There's no clear communication in the UI that this is going on, and it may appear to be a bug. I think the first thing to do is to improve user messaging of what's going on. We've also turned on sparse files by default on win7+, this will eliminate the up-front cost of downloading a large file.

2. with vista, uTorrent will set its disk I/O priority level to below normal. This is to not interfere with interactive applications that may need more urgent access to the disk. If another application is doing a lot of consistent disk I/O, on vista and win7, uTorrent is likely to get much lower rate of disk operation completion. Especially when shutting down this might be annoying, since persistent disk I/O from other applications may stall the utorrent process from terminating indefinitely. One we we're mitigating this is to bump our I/O priority back to normal once we start the shutdown sequence, and flushing the cache.

3. files used to be opened in unbuffered mode when being written to, by default (this change was introduced somewhere in 2.2 or 3.0 iirc). Benchmarks on a win7 laptop suggests that this would impact write speed negatively. We've changed the default for this back to what it was pre 2.2, to not open files for writing in unbuffered mode.

We made a few improvements to the disk I/O subsystem before the RC, mostly simplification and deleting logic that wasn't necessary, as well as fixing a bug introduced a few months earlier causing it to flush the whole write cache every second or so. The flushing bug would severely harm the write performance of the 3.1 betas. There was a significant seed performance improvement too. Previously, we would throw away the pieces that we downloaded as they were written to disk, and if a peer would request them, we would read them back in again. Now, we're avoiding that extra read step and just put the buffers straight into the read cache.

Another improvement in 3.1 is a GUI refresh overhaul. This is all behind the scenes. We used to update the GUI in a way that did not scale very well with the number of torrents. If anyone ever tried to add 20000 torrents to uT, they probably know what I'm talking about. Our goal with 3.1 is that it should easily handle that many torrents, and now the GUI is. The one remaining issue that we're working on right now is to be able to save resume data for that many torrents, without allocating a gig of ram and stalling the GUI while saving it. This GUI overhaul is what's causing most of the GUI bugs that you've been seeing, where torrents sometimes aren't updated in the download list properly, or aren't removed when they should. The new scheme is a bit more complicated, because all changes are edge-triggered, and we might have missed some of the edges.

Share this post


Link to post
Share on other sites

Those HD related settings work best for me now:

22360639.th.png

25940320.th.png

Edit:

Here is the side-effect of some of the modified settings (win7/32bit, 1-on-1 download over LAN, v 3.01 (at 3.1 settings), HD write speed = ~60MBps):

With the above optimal settings: a smooth ~57MBps speed, very close to the HD write limit speed. During the whole time - the uTorrent cache queue is almost empty. I guess Windows takes care of the cache, nicely ...

31301301speedcacheoptim.th.png

With the above settings EXCEPT the advanced->Disk Cache->diskio.flush_files = true (the default):

The flushing is every ~1 minute and drops the speed to about half. During those events, uTorrent cache is being used, filled up, and being flushed.

31301301speedcacheoptim.th.png

With the above settings EXCEPT the advanced->Disk Cache->diskio.coalesce_write_size = 2MB (the default):

The uTorrent cache queue is now always full, and handling the this cache-Q causes speed drop of about 17MBps (-30%)

31301301speedcacheoptim.th.png

With the above settings EXCEPT the advanced->Disk Cache->diskio.cache_stripe = 128 (the default):

I have absolutely no idea what this parameter is (no, no hint in the help file for a few parameters...), but is causes a ~-10% speed drop.

31301301speedcacheoptim.th.png

Firstly, I think that all the above will have almost no effect at lower speeds!

That being said, regardless, the "evidence" shows, that whenever uTorrent cache is being involved, it does not help improve data rate by a more efficiently handling the HD I/O at high speeds. Since the default parameters (like the 2M size) seem to have had better results in 1.8.5, it is possibly only some "improvement" coded during those years that causes this.

So, I can just hope it will be found and removed ASAP... ;)

Share this post


Link to post
Share on other sites

Tho this night be better handled off-line, here are a few notes that can shed more light...

These are the theories we're working on right now. Feel free to comment on this if you have some relevant evidence that may contradict this.....improve user messaging.....

Here we go... and having more user-messages, maybe also logged info is always good for troubleshooting...

The disk subsystem appears to be slow

No arguing here... ;)

1. Stuck at 99.9% ...just waiting for all the pieces in the write cache to be flushed to disk...

The root issues might be:

- For a set-fixed cache size (say 32M) it shouldn't take more then 1-2 seconds in this new "state". When Windows cache is enabled - true, it is out of your control, but it is not THAT buggy...

- when pref->advanced->cache->Write out finished pieces immediately is enabled - there should not be more then a couple of unfinished pieces in the cache, so the other issue might be - why are those still in the cache in the first place? Those should have been written long time BEFORE we are in the "99.9% state"

2. stuck at checking 0%, ...making the idle ones say "queued checking" or something.

Sounds good, as long as the active one is, somehow, visible and not under the scrolled 'hood'...

...why would the disk io subsystem be slow (or even lock up?). I'm not entirely sure.

Regression bugs (uT's/M$'s) ?... Streaming 'add-on' related ? 1.8.5 cache/IO is quite harmless... even on Win7 ;)

1. sparse_files are not used by default. This means, whenever you start downloading a 5 Gig file, the first flush to disk will block, and windows will write 2.5 Gigs of zeroes to the filesystem on average.

Also when General->pre-allocate all files is disabled ?

2. with vista, uTorrent will set its disk I/O priority level to below normal. This is to not interfere with interactive applications that may need more urgent access to the disk. ....bump our I/O priority back to normal once we start the shutdown sequence

Possibly, and very simple to confirm - just look at the HD LED, see if it flashes... :) Hard to believe it is so.

We made a few improvements to the disk I/O subsystem before the RC, mostly simplification and deleting logic that wasn't necessary, as well as fixing a bug...

Great :)

I'll add a few more words/"evidence" in the post above, showing the effect of the modified settings. It can trigger some hints/ideas from people here...

Share this post


Link to post
Share on other sites
2. stuck at checking 0%, similarly, if the disk subsystem is slow...

utchecked0percent.th.png

Stuck at 0% check upon "start download" control, with a previous *.ut! file .

Here is a dump (3.01):

http://www.mediafire.com/?m7dyyf4m1w33cmj

I have a feeling that there is a previous process derived of a closed uTorrent stuck in reading this file ... OR better yet - the >4GB size issue (from the part file) it back again ... :P

Edit:

Also, make sure to investigate why when force rechecking w/o any files - it takes uTorrent forever, instead of 2 seconds... :P

Share this post


Link to post
Share on other sites

I didn't even bother to test any further when I saw that the window that shows the content of a torrent file is still broken and can't remember user resize. RC for what if these small bugs aren't fixed ?

Share this post


Link to post
Share on other sites

Stuck at 99.9% bug happens even when my HDD is doing nothing (idle). When this happens, you can't even exit utorrent, it will stay in process list until you kill it. I've created a dump after I closed utorrent with 99.9% bug and it was still in process list: Click

Share this post


Link to post
Share on other sites

Let's hope that two dumps will be enough to fix it... :) They are just slow in writing the leftover pieces in the cache (try look at your pieces tab). Simple... :P

Share this post


Link to post
Share on other sites
Guest
This topic is now closed to further replies.