Unacceptably high disk usage/performance lag Windows 8

SNGX1275

Posts: 10,615   +467
I think this is a sata issue or a BIOS setting or perhaps just a Windows 8 bug...

Basically this happens:
bvAUKpQ.png


I recently installed Windows 8 and finally some free time to get Steam installed. Installed Steam and am copying over my Steam directory (Disk 2, K) from my Win 7 to where I installed Steam this time (Disk 0, C). This is the same physical computer as I had Win 7 on prior.

What has changed since Win 7 is I thought since I was doing a fresh install, I would turn on AHCI in the BIOS and do it proper rather than IDE emulation or whatever it is called. But now crap like this happens. I googled a bit a week or 2 ago trying to figure it out and basically all that I could gather is either a hard drive is dying or it is an NCQ problem. Hard drive is not dying, I've ran plenty of diagnostics on it, and plus, it has less than 200 powered on hours at this point.

Now I turned off NCQ on ALL my drives just to see if the problem went away. It didn't, but I think it may have improved a little.

Device manager doesn't show any yellow "!" for anything.
DKx0dww.png


Obviously this is completely unacceptable. Ideas on what to change to make it behave normally? Hopefully I'm missing something obvious, I've never used AHCI on a system before, mostly because when I had a system capable of it I was on XP and didn't want to load 3rd party drivers. Then for Vista and 7 I simply forgot before installing to switch it in the BIOS. I remembered this time for 8, but I'm really regretting it now.

Edit: Here is another image, further on in the copy, to show it doesn't get any better and it wasn't a 'small files don't transfer fast' issue. http://I.imgur.com/UTDo69u.png
 
I was gonna give you an updated AHCI driver from Intel but noticed you are running Core 2 Duos, so it probably wont be compatible. I am confused, does this occur in Win 7?
 
It didn't. I ran Vista, and then 7 on that hardware without issue. But I never ran AHCI always had it as IDE.
 
You could try an experiment and set the system drive back to IDE mode.

Just be sure you've enabled the IDE drivers in the registry prior to doing
that:

http://www.ocztechnologyforum.com/f...e-Ide-Ahci-n-m-raid-mode-without-reinstalling

If you blue screen, then you didn't enable all of the IDE drivers correctly, but have no fear,
just set the drive back to AHCI mode in BIOS and your system should boot again.

I suspect the problem is with the GBB36X driver. I can't find any evidence that there is an actual port of this driver specific to Windows 8. A switch to IDE mode would probably confirm that theory, since I don't think a storage controller would be used in IDE mode.

Other things to check are that your "Standard SATA AHCI Controller" is the correct and BEST/latest driver for your hard drive controller.

Also, you could check to make sure there are no weird/unknown/unexpected Class, Filter, or Co-installer drivers for the hard drive controller or the storage controller, or any extraneous file-system drivers in non-plug-n-play drivers.

But if I had to bet, I'd bet the GBB36X driver is the issue.
 
Hmm; When copying from K->C
the progress shows ~45 minutes (or 2700 seconds) estimated to move 4,729 items (25.1GB)

2700sec/4,729 objects is only 0.57 seconds per object & the progress says that's 9.36MB/sec
(so this appears to large file sizes, approx 2/sec or 4.8mb each on an average).
The 2228ms avg response time is disturbing.

Yea, disk C is at 100% - - but SOMETHING has to be the limiting factor and in this case, it's the target disk.

Perhaps you expectations are too high. Do you have any emperical data showing better hd performance?

(at least the K & C are on different SATA channels as a c:\foo ->c:\bar copy would be yanking the disk arm all over the place).
 
Had another thought; Swap data movement direction, aka C:-> K:\ and note which disk is the bottleneck.

If K:\ is saturated, then that demonstrates the extra overhead of write vs read; otherwise C:\ is truly the problem
 
Thanks guys, next reboot I'll switch back to IDE and see what happens. Here it is happening with another drive, although it is not as bad, there were periods of fast transfer.Interestingly the ST2000DL001 drive is still involved.



I'm trying to replicate the problem between 2 other drives that are not C or X. I thought for sure that I could, but haven't been able to do so yet.
 
Update with some bad news.

Switched bios from this:
JCBuDbL.jpg


To this:
oXE1lSz.jpg


That got me a BSOD reboot when loading Win 8.

So I switched it back and now it isn't booting at all. After POST and this screen (sorry its blurry but I think any details are still readable):
28LTdYJ.jpg


I just get a black screen, meanwhile the hdd activity light on the front of the case is on solidly.
 
There are a couple of things I've done in that situation (yes I have been there before).

1) Boot with logging (F8 after bios screens). Doesn't always show everything you need to know but it can show where it gets to before the lockup. You may/may not be able to get here. Worth a shot in any case. Easier to fix when you know which exact driver is locking.

2) If you have a Hiren's bootcd handy, you can boot into an environment where you can get local disk access and most importantly, registry access. You can then do the modifications to the registry to fix AHCI configuration such as pointers to the right drivers for boot etc.

Can be tedious but when AHCI is working properly, MUCH better than IDE. Certainly recommend trying to plough through and work out what's going on...
 
Some odd things happened. I figured the AHCI to IDE couldn't have screwed things up too bad, but as noted above it wouldn't try to boot. Since it didn't seem like it would have been too screwed up I booted from my Win 8 dvd and choose to repair the system, then went to advanced and picked its automatic repair, I started that around 11:30pm last night and it seemed to be progressing really slowly. I went to bed around 2am with it still on attempting repairs.

Woke up this morning and it was on the install screen for Windows 8 (what you are first presented with when booting off the dvd/usb). I just rebooted only to notice my OS drive didn't show up on the SATA AHCI BIOS screen, that didn't look good. Obviously it didn't boot then, so I panicked and pulled the drive and put it in my SATA->USB dock connected to another computer. Everything looked good there. Put it back in main PC, rechecked all the connections and booted up. BSOD shortly after Win 8 started to load. Something about missing registry entry I think. Rebooted with Win 8 dvd, did the automatic repair again and it went really quickly. Rebooted, it took a long time on the Win 8 splash screen but now I'm back in business with a functional Win 8 system. Highly doubt the original issue is fixed but at least I can use the computer again without a complete reinstall.
 
Some odd things happened. I figured the AHCI to IDE couldn't have screwed things up too bad, but as noted above it wouldn't try to boot. Since it didn't seem like it would have been too screwed up I booted from my Win 8 dvd and choose to repair the system, then went to advanced and picked its automatic repair, I started that around 11:30pm last night and it seemed to be progressing really slowly. I went to bed around 2am with it still on attempting repairs.
The boot repair feature imho is abysmal and has had a very low success rate for me. It won't fix an IDE -> AHCI setting change either. Not sure what it does exactly but I think the only thing it does is check the boot.ini and that there is an active partition.

AHCI to IDE... would have expected that to work but having said that, setting up AHCI should've worked fine too...

Have you tried updating your BIOS? Maybe there is a controller firmware update that resolves your AHCI issue?
 
AHCI to IDE there is something not right with these in the BIOS. BIOS update might work but then again if wasn't implemented correctly you might not see the huge benefits in using AHCI like you would expect on a newer system. Do you know what your FSB (front side bus) speed is? Older system prior to the next gen CPU are vast improvement.
 
The boot repair feature imho is abysmal and has had a very low success rate for me. It won't fix an IDE -> AHCI setting change either. Not sure what it does exactly but I think the only thing it does is check the boot.ini and that there is an active partition.

AHCI to IDE... would have expected that to work but having said that, setting up AHCI should've worked fine too...

Have you tried updating your BIOS? Maybe there is a controller firmware update that resolves your AHCI issue?

I know, I've never been impressed with Windows' repair, even with XP the repair that is first presented to you is not the way to try and fix anything. I figured things were bad when it didn't finish right away. I'm really surprised the 2nd attempt got it fixed enough to boot again.

As for the BIOS update, I've got the latest, which is several years old. What I don't know how to deal with, or if it can be dealt with, is the SATA AHCI BIOS iSrc version 1.07 (post #9 pic 3) that loads after the motherboard BIOS.
AHCI to IDE there is something not right with these in the BIOS. BIOS update might work but then again if wasn't implemented correctly you might not see the huge benefits in using AHCI like you would expect on a newer system. Do you know what your FSB (front side bus) speed is? Older system prior to the next gen CPU are vast improvement.

I suspected I may have something wrong in the BIOS too, but I can't find anything wrong. But then again, I'm not an expert in this area. Do you see anything that looks wrong in the 2 BIOS pics I have above?

Took a screenshot for your other question:
OgPN0pT.png
 
I don't think that applies since I did a clean install of 8 with AHCI set in the BIOS. I only had temporarly switched the BIOS to IDE as basilirwin suggested. I screwed up and didn't do the registry stuff first though, hence the problems booting. I'm back with a booting system now, so I shouldn't need to mess with the BIOS. Pretty sure everything is the same as it was when I created this thread.
 
I have 3x systems that have this issue. Like the BIOS will not go into AHCI and only works IDE mode base on FSB most prior ones were slower than the ones you get to today are able to handle 10x more.

If you force this in the BIOS then you see what happens. Alway do CMOS Jumper clear or remove the backup watch battery and do a CMOS clear unplug the power helps. Wait 15 to 30 mins to do a full clear. Other than this what they sold everyone on this feature not what it's living up to be.

Buying new systems already from the factory works then again those system have the next Gen CPU, faster FSB, faster RAM beyond 1600MHz, bla, bla..

How was the system in Windows 7 handling on HDD were they same or faster?
 
I've never used AHCI on a system before, mostly because when I had a system capable of it I was on XP and didn't want to load 3rd party drivers. Then for Vista and 7 I simply forgot before installing to switch it in the BIOS. I remembered this time for 8, but I'm really regretting it now.

I have no doubt that the BIOS is set to AHCI and that AHCI is what Windows is seeing. Setting as IDE completely changes how the drives are reported on POST and the Serial ATA AHCI BIOS 1.07 screen never appears (this is normal/makes sense since it is not set to behave that way when you switch to IDE in the BIOS - Exact behavior you'd see in the old days when Maxtor drives shipped with a Promise ATA-133 PCI card because most motherboards at the time were still ATA-33/66). So I know for a fact AHCI is on. Initially I thought it was a driver or configuration issue in Windows, perhaps a Win 8 bug because googling confirms similar (but not identical) issues, or a BIOS configuration problem. I've taken photos of the BIOS (post #9) and I don't see anything I could have screwed up there. Perhaps there is some configuration elsewhere that I have overlooked?

http://www.eightforums.com/performance-maintenance/13390-100-disk-usage.html
http://www.tomshardware.com/forum/4408-73-random-disk-usage-causing-spikes
http://answers.microsoft.com/en-us/...7d?msgId=fe44a3b7-bc84-46c2-95e4-f2756af580ee
https://www.google.com/search?client=opera&q=100 disk usage windows 8&sourceid=opera&ie=utf-8&oe=utf-8&channel=suggest
ect

Answers are the typical ones, you need more RAM, hard drive is dying, its bloat software. I don't believe any of those are in play in my case.


I can re-create the problem by copying files from any drive to Disk 0 (C:\ and X:\). Copying large files from other drives to other drives (Disk 2 to Disk 1 for instance) seems to behave slower than I expect, but not bad enough to complain too much. Just seems a bit odd that writing to one disk at 100% only amounts to a read from the other at 23% - but again, I'm not terribly concerned about this - I think it is probably normal or close to. I really want to solve the transfer to Disk 0 issue though.
LPNHo66.png


What I think is happening is anytime there is a small data read/write to Disk 0, everything is cool, it fits in the disk cache. Once a transfer bigger than the disk cache is initiated though, things go south. Something gets overwhelmed on large data transfers. I think this because simple tasks like web browsing are mostly fine. I have gone back to Opera for a web browser (after briefly switching to Chrome) because in Opera I can change the disk cache locations to something other than Disk 0, Chrome writing to the C drive made it impossible to use at times, huge lags.

This sounds to me then like a drive issue or a driver issue. I don't think it is a drive issue because I cloned this Win 8 over to the brand new 2TB that it is on now, from an old 400 GB drive. The problem happened on the 400 GB drive too.
 
Why are you still using the old MCE forum *.dvr-ms where it now is *.wtv. Are you transferring from HD to HD or over the network to like NAS?

Are you using SSD or HDD?
 
The filename also included the date... November 3rd, 2006. I'm a big college basketball fan and that was my school (division 2) University of Missouri-Rolla at our division 1 big brothers University of Missouri (Columbia). Was recorded when I was running XP-MCE on an old P4 as a media center PC.

Regular hard drives, mechanical.
 
I have no SSDs at all. Never had the issue on any prior OS, but I also never attempted AHCI.
 
What I think is happening is anytime there is a small data read/write to Disk 0, everything is cool, it fits in the disk cache. Once a transfer bigger than the disk cache is initiated though, things go south. Something gets overwhelmed on large data transfers. I think this because simple tasks like web browsing are mostly fine. I have gone back to Opera for a web browser (after briefly switching to Chrome) because in Opera I can change the disk cache locations to something other than Disk 0, Chrome writing to the C drive made it impossible to use at times, huge lags.
hmm;

* Disk Cache <is not> Browser Cache. All the browsers have cache that the user can control and are always related to the
user+browser Application Data. Performance theory suggests that TOO MUCH cache can actually decrease performance as looking for a cache-hit can become excessive. Getting a cache hit ~30-40% is considered a good number.

* Disk cache is frequently on-board to the device and not even stored anywhere in the OS. Your thoughts re large files impacting caching is a good suspicion - - look for a firmware update for the specific C-drive make/model. An alternative test might be to look for a means to disable HD caching altogether.
 
Yes, I know that disk cache and browser cache are different. With Chrome, I cannot change the location of the browser cache, so temporary files (flash video included) are located on C. Big file operations (my guess is bigger than the 32Meg disk cache) cause extreme slowdown problems, so, in moving back to Opera, I can control where the browser temp files go, and I have placed them on a separate physical drive. This prevents the system lag when browsing.

The reason I do not believe it is actually disk related, and more of a sata controller driver issue is because this happened when I had this OS on a 400 gig SATA drive. I now have Win 8 on a 2TB Seagate drive because a 2TB Seagate drive I was using was dying so I RMA'd it. Seeing this as an opportunity to put my OS on a faster drive, I cloned Win 8 from that 400 gig to this 2TB. This 2TB is brand new, I keep my computer on 24/7 under normal circumstances, and as of right now I have 284 power-on hours on the drive. It shipped with the newest firmware they have for the drive (confirmed by doing a firmware check through SeaTools).

My SATA controller in Device Manager just reports Standard SATA AHCI Controller. The details tab hardware ID is PCI\VEN_8086&DEV_2824&SUBSYS_B0051458&REV_02 which googling tells me it is a Intel ICH8 SATA AHCI Controller, that fits with the Intel Serial ATA BIOS screen after the traditional POST (Post #9 pic #3) that I see. I went to Intel's site and couldn't find that driver, and I'm a little skeptical on downloading from any of the 'free driver' sites that pop up in a google search.

So, I think that is my 'next step' in trying to solve this problem, but I need to find a trustworthy download.

Edit - Found the driver on Intel's site. It now reports as an Intel controller in device manager.

Unfortunately it did not fix the problem. I have captured what may be the most telling screen shot yet. It also destroys my disk cache theory.

jhn8NrB.png
 
So, I think that is my 'next step' in trying to solve this problem, but I need to find a trustworthy download.
BRAVO! Good Choice (y)

Q? any chance C & X are different partitions on the same physical drive? that would certainly mess-up the measurements and the
throughput.
 
Back