Disk Overloaded 100%

[panicrooster]

To "jewelisheaven".. if you think that anytime a program freezes means you have something broken you are a loon, and the use of multiple programs can and will cause freezing and crashes. I find it very odd that when ONLY uTorrent crashes and does so on both of my pc's and my older one, no other program does this ever, that somehow I have a broken system. You even said yourself that we should use version 1.8 that fixed the exact problems I stated and others are having, but you will still turn around in the same message and claim people have broken systems. You speak out of both sides of your mouth.

To GTHK.. I do understand what you are saying about the USB and the cache, also that everyone has different systems, etc.. and I also understand what the manual says, but the bottom line is that uTorrent 1.7.7 is unstable and of the many programs I have, which is many, uTorrent 1.7.7 ranks THE LOWEST on stability and tested on multiple pc's. While the cache setup "should" be set a certain way and used.. uTorrent becomes unstable when trying to control this process. With it unchecked and off... I don't have it crash. That's all I was trying to say.

[Ultima]

And yet, many of us have tested it on a wide variety system configurations (different hardware, different softwares, different operating systems), and have had no problems with stability. Shouldn't that mean that we're also allowed to say it ranks among the highest in terms of stability?

I don't mean this 100% seriously; I know µTorrent isn't perfect. The point is, one person's experiences can't necessarily confirm a wide sweeping statement such as yours -- especially if there is plenty of "proof" indicating otherwise.

[GTHK]

The bugs jewel referenced include remote crash bugs, I don't know if there are actually any stability fixes. The removal of tree view from 1.7.7 prevented me from using it at all, I use the alphas/betas. Also, many problems are system specific since µT is well coded (not invincible, but well coded), hence the starting there for troubleshooting by most members. If it were a global bug those of us with well established systems would, most likely, have trouble as well. Many problems that are reported on the forums are caused by other software inappropriately hooking into µTorrent, adding code that doesn't belong, and since many problems are caused by this most troubleshooting starts by looking at other software. In the cases I've seen, in which every known piece of misbehaving software has been removed to no effect, additional research, followed by filling a bug report was recommended. If your having trouble with disk overload or stability, you should make a new thread with an HJT log and a Process Explorer with DLL list log. I think jewelisheaven ignored the possibility it was µTorrents fault because crashes have always, as far as I can tell, been traced to bad hardware/software, not to mention other people who can transfer fast would most likely have reported the same problem. I trust jewels judgement when it comes to software, I'm more of a hardware guy as shown by this forum and a guide I made recently (computers are an ongoing learning process though ). Any software that adds code to µT is behaving inappropriately, buggy drives could be an issue too... you could immediately rule out most conflicting software though by running a VM if you can. If the problem occurs on multiple computers, look for something environmental like you would a disease, common threads such as running the same software, or the same brand NIC's. If all else fails, including forum member advice, it might then be bug report time.

As an aside, I personally would like to see µT's cache options be a bit more automated, by detecting legacy hardware and hardware bottlenecks, and tweaking the cache accordingly so as to slow the transfer rate and hopefully help situations similar to NightPrinces, along with an override and a log entry stating bottlenecks for data transfer, of course. µT is already being coded to warn of some buggy misbehaving software, why not report hardware bottlenecks as well? Maybe someone can search the feature request forum and request it if it hasn't been done already, not me though, due to a combination of laziness and having stuff to do .

...Holly crap that was long... in conclusion, the best thing you can do is to work with the people here to eliminate known and unknown factors (in a new thread), and bug report if recommended to do so, this way if there is a bug, it can be fixed. Not likely though because others would have most likely reported similar problems, as evidenced by mine, jewels, and Ultimas use, in very different configurations. The only trouble I have had with stables was caused by a retarded firewall component that I had uninstalled, stupid thing was left hooked into my connection by the uninstaller, POS.

[Hedgehog]

I have had the same problem with disc overload and ütorrent.

Have an external disc via USB2 and it had worked nice for a long time.

But suddenly I had the problem with overload. But only with ütorrent, not with Azureus.

Found out the problem was Fsecure and 2 dll modules, fsdfw.sys (v6.16.61.0) and fsndis5.sys (6.16.61.0). When I replaced them with version 6.16.65 the problem was gone.

Anyhow I now have the problem again. Ütorrent download until the buffers are full and then slows down. Parallel I also use Azureus to the same disc and it's transferring without any problems. Both files have now rev 6.16.71 and has been added recently on my dummy.

The Q is: Do Azu and ut use different drivers to write on disc?

[GTHK]

This old thread again? Well, you should post a Process Explorer with DLL list log so that we can check for anything else causing trouble. On the statistics page when showing disk statistics, is it writing to disk at all? Or is it writing to the cache only? How fast are you downloading? USB 2.0 has a theoretical maximum of 60000 KBps.

[Hedgehog]

I didn't find a useful pgm to list active dll.

I have only ADSL and download and transferring to disc is app. 1.7 MB/s as maximum..

With ütorrent the transfer goes up to max for a short while until a number of blocks are in queue and then down to app. 1- 20 kb/s until some blocks are written to disc. It seems that blocks are written in sets. But not all. There are still some in buffer. Then the speed goes up for a while until the queue is full. If I disable Fsecure Virus & Spy supervision all runs normal..

A hint can be when the problem occur fssm32.exe generate a high Cpu-load.

If I use Azureus all works without any problems. I got max speed for my ADSL.

I seems that Fsecure and ütorrent don't like each other. And it's not the first time.

[GTHK]

Ah, it's most likely Fsecures fault then if disabling it fixes this. It's probably scanning µT and ends up blocking it while it does so. Look inside that program, and see if you can find the ability to create exceptions, or find an exceptions list, and add µT.

[Hedgehog]

First. The problem has nothing to do with the external drive. Same problem with IDE and SATA-disc.

Have solved the problem by replacing the two dll with older version 6.16.65. It gaved a better result but the buffer still got overload every second minute. After disabling Write out untouched blocks every 2 minutes it works nice.

[GTHK]

I, didn't say anything about an external drive, second, any program that adds data to another program is behaving poorly.

[Hedgehog]

I know that. I was referring to the first note in this thread.

Some of my early experience of cache-discs.

First time I was testing a "larger" disc with cache was in the middle of 80´s. I had the responsibility of "Modcomp" computers, discdrives and tapestations at ABB/Sweden (ASEA). Normally we used CDC's SMD (67 mByte formatted) discs. And SIC was introduceing a new cachedisc. It also emulated the disccontroller and was connected directly to the I/O-bus. There were 2 algorithms, frequently or recently used. SIC recommended frequently used.

When I did some perfomenstests it work nice for a while and then the access to the disc gone sluggish. The disc has only a few tracks left in the cache.

The reason was. If I booted the system 2 times, the SAL (Stand Alone Loader) on track zero was read twice, the Operationsystem likewise and these tracks had an access-counter of 2. Even if I didn't access them anymore they would stay in cache until power off.

Also the older Classic CPU had a type of cache, designation "Pipeline" (2 x 8 words). Restriction was that you wasn't allowed to modify your code within 8 words ahead.