Jump to content

Latest version - Disk overload all the time


lonewolf77

Recommended Posts

  • Replies 156
  • Created
  • Last Reply
Not meaning to sound negative here but alot of people are having this problem and posting about it, it just seems that there is no response on how to fix it or am I just missing the part where it explains how to overcome this issue?

Don't bother updating to "26763" which just came out today..... seems they "FIXED" everything EXCEPT this problem. Same error BS as last build [Flushing Forever]... just be patient !!!!!!

Link to comment
Share on other sites

Just FYI ~ the rollback to uT v. 3.0 build 25460 is working just fine...but I still hope you guys fix that nasty bug soon...! :rolleyes:

Does this build ever get the caching issue ? "disk overloaded" and "flushing forever".... if not what type (speed) is your connection ? I'm on 10/100 cable, "Comcrap" and get 25mb/s down (speed test)..... (2.5MB/s down ave. torrent downloads)

Looking to possibly rollback to a version without this cache problem... any help would be appreciated...

Thanks in advance,

Rush

Link to comment
Share on other sites

Rush, thanks for the testing, will wait further.

No problem bro,

This whole flushing forever thing appears to be related to partfiles. Turn off diskio.use_partfiles.

Thanks again Firon, for acknowledging this issue... looking forward to a fix

Link to comment
Share on other sites

Just to note, it won't fix existing torrents that suffer from it... only newly added ones.

It's a workaround, but we'll work on fixing it properly for the next release.

Got it, will try a new download today at around 2.5MB/s and report back.....

Your the man Firon... no matter what they say about you :)

Thanks,

Rush........ DOT DOT DOT

Link to comment
Share on other sites

I do have a question for you.

Are you skipping large files? In particular, are they >4GB?

We're actually having a bit of trouble reproducing this. Do you have any .torrent files that exhibit this reliably?

Nope I almost always download 1 or 2 torrents at a time .... range between 700MB and 1.4GB.... don't think I ever had close 4GB queued ever.

Here's an example, if this helps.... yesterday after the just installing the newest build I began a download of a 1.39GB file and after the initial start up the speed gradually climbed to my normal healthy torrent speed of between 1.9MB/s and 2.7MB/s (that's about the max on my cable BB connection)

It was flying along while I kept close watch on the write cache status bar... never had more than 2MB hanging in cache (all files were quickly writing to hdd) then out of nowhere at about 90% written to file it just stopped writing to disk completely .... cache climbs rapidly till it hits my predetermined amount (which was 128MB at the time) and you know what happens then. Overloaded 100%, utorrent then slows to what appears to be a built in holding pattern of 10kB/s up and down added together. (this number 9.5 to 10kB/s is well documented in every troubleshooting/bug thread I've read on this issue.)

My disk is on real time defrag and never exceeds 4% fragmentation.... 40% open and optimized prefetch and open space priority defrag once a week.... in other words it's healthy. Tcp is optimized for 10/100 cable and has no issues on any other internet application.

It appears to my untrained non-techie eye that it it is a hit and miss unpredictable bug ie. when cache is normally writing to disk the program is awesome it works exactly as it should (cache will rise slightly and drop as it allocates placement of files to hdd).... something just happens at random intervals with no rhyme or reason and the disk writing "stops dead" sometimes at 10% downloaded sometimes at 90% downloaded. It is appears to not be related to speed although the fast downloads obviously fill a cache quicker than than a 100 to 200 kB/s download...but if there is ZERO files being written to disk and all is hung cache, it is just a slower death, but it still happens.

Sorry about the long post, hope this helps point the author in the right direction, cause without this glitch Utorrent is awesome when all is well.... hate to go to Vuse with the bloated 9.5 MB install and java b.s.

I've asked this question before but no response.... since we all know this is "real" because of the overwhelming amount of complaints.... can you refer me to another version and build number which is proven solid/stable... I can locate most all previous downloads on the net.... just need a number. In the mean time I know this will get a fix soon and I will be back on current "update mode" with speed, stability and the latest utorrent features we are all used to.

Thanks bro,

Rush.........

Link to comment
Share on other sites

Also getting this same issue on 3.1.2, it starts to download, writing to disk. Then shortly after, it starts writing only to cache and disk writes stop.

Have tried to change diskio.use_partfile to *false and diskio.sparse_files to *true.

It's happening on any size torrent including small (350mb) and large (5gb) torrents.

When it does finish downloading, It says Flushing to disk. Sometimes it does do it and eventually clears it, but sometimes it just gets stuck.

Link to comment
Share on other sites

I'm getting faster speeds than ever (advertised download speed, when I don't get disk overload) but I am getting disk overload frequently on the latest stable.

The latest stable does not address this issue...(read fixes next to build numbers when you update)... according to admin... "We're looking into this, but more than likely, a fix won't happen until the next release, since the code is involved and pretty messy. We're rewriting disk i/o anyway for the next version." ....quote by Firon....admin. http://forum.utorrent.com/viewtopic.php?id=114372

I'm not part of the utorrent team but if I were you don't update to new builds expecting this issue to change until a fix for this is announced or listed in build description... these recent updates do address other problems though if they apply to you. If anything you might do what I am going to do and rollback to a 2.xxxxx version as this cache/write issue for me at least makes the 3.1.2xxxxx unstable and unpredictable. (When it's cache is writing to file correctly it flies.... when it stops writing to file it sucks)

IMHO

Rush......................

Link to comment
Share on other sites

The issue only happens when skipping files after it's been added, it seems. If you skip them in the add torrent dialog, you probably won't see this happen.

Now that you mention it... I used to always download the entire torrent with it's 1 file I needed and the 2 or 3 "useless ones" like info, read this, and preview etc. More recently though I un-tick the bloat (for speed and bandwidth issues) and only download my main target file. Not sure how that affects the cache... but then again I don't write code either. Thanks for the tip Firon... still have 3.1.2xxxx installed, will try full download (3-4 files all ticked) maybe 1GB or so at "unlimited speed down" and post results back to this thread.

Rush....

Link to comment
Share on other sites

Update to post #44 ^^^^^^^^^^^^^^^^^^^^

Ver.3.1.2 build 26763

Torrents downloaded...............1

Files downloaded ...................2 of 2

Files skipped .........................0

File size #1.............................2.72 kB

File size#2..............................1.07 GB

Ave, down speed....................453.2 kB/s......poor health (1 bar)

Max down speed....................1.3 MB/s

Cache file size/pre set ............512 MB

Max cache queued..................7.1 MB of 512 MB

Ave. queued ...........................3 MB (approx)

Disk overload error..................none

Flushing to disk delay ..............none

Link to comment
Share on other sites

As far as I can tell this is not related to skipping of files.

For me the error occurs even for single files (of any size). Something about how utorrent writes files to disk must have changed in 3.x

It's not just the downloads slowing down, file-moving to a target folder after a download has finished is also *very* slow. There is a new behaviour for this if I'm not mistaken, in 3.x the file to be moved gets renamed to 'filename.filetype.1' in the folder it is downloading to and then copied over to the destination under the proper file name. I don't think older versions did it that way.

Link to comment
Share on other sites

As far as I can tell this is not related to skipping of files.

For me the error occurs even for single files (of any size). Something about how utorrent writes files to disk must have changed in 3.x

It's not just the downloads slowing down, file-moving to a target folder after a download has finished is also *very* slow. There is a new behaviour for this if I'm not mistaken, in 3.x the file to be moved gets renamed to 'filename.filetype.1' in the folder it is downloading to and then copied over to the destination under the proper file name. I don't think older versions did it that way.

Not sure about your results with one file... but when I was skipping files it gave errors virtually every download. Tried 3 total with 3.1.2xxxxx (not skipping) an it did not happen at all.

I know that's not very scientific but it doesn't really matter ( I need to skip files, to keep my bandwidth usage down), so I rolled back to ver. 2 and so far, no issues either way. So I think your on the right track about this "must have changed in 3.x"

Rush.... :cool:

Link to comment
Share on other sites

http://forum.utorrent.com/viewtopic.php?pid=642856#p642856

Can I ask you to do a simple test:

1. Download these command line utilities that change the priorities:

http://sourceforge.net/projects/iopriority/files/Simple%20Console/

http://gilchrist.ca/jeff/SetPriority/index.html

2. Find out your uTorrent process number (task manager)

3. Start-run-cmd

4. run IOpriority <uT-process-number> 2

5. run setpriority -p32 -t0 <uT-process-number>

See if there is any change :)

[optionally - use "process hacker" to change the low priority threads' priority to Normal]

Link to comment
Share on other sites

Archived

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


×
×
  • Create New...