Jump to content

µTorrent 3.1 Release Candidate 11


Firon

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

Link to comment
Share on other sites

  • Replies 448
  • Created
  • Last Reply

Top Posters In This Topic

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.

Link to comment
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

Link to comment
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

Link to comment
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?

Link to comment
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)

Link to comment
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.

Link to comment
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... ;)

Link to comment
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...

Link to comment
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

Link to comment
Share on other sites

Archived

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


×
×
  • Create New...