Where's My Performance? (Another SATA III n00b)

[maguserroris]

So I've looked through several search results and I'm done wasting my time. I figured I'd get a more concise answer here, at the risk of annoying people with a question that has been answered in bits and pieces here and there.

I have a 500GB SATA 6Gb/s hard drive with 64MB cache @ 7200rpm. I also have an SATA III enabled mobo (Asus M4A87TD/USB3) and Windows 7 Ultimate 64-bit.

I was hoping for better performance rendering to disk (for example with Apophysis,) but I'm seeing times comparable to older, cheaper hard drives. I also noticed in the BIOS the default is set as an IDE configuration instead of AHCI / RAID. Windows will not boot with AHCI enabled.

The Manual indicates that IDE mode is for drives in a PATA storage setup, and AHCI improves performance on random workloads. From this I gather AHCI is great for a system disk, but not necessarily for rendering large files to the disk.

Now that you know what I do know, here's what I don't know (my question: ) "Is it possible to obtain better performance from this drive - if so, what do I do and if not, where does the bottleneck lie?"

Thanks in advance for any and all help with this. =]

 

[thetrivialstuff]

Is this drive your boot drive, or is it a clean place to store data, with no OS or program files on it?

If you're rendering to the same drive Windows is on, it'll probably be slowed by Windows accessing the disk, and by fragmentation (even if it's fully defragged, writing a large file like render output onto a drive that contains lots of small files will go much slower than full sequential write speed on the disk, because NTFS isn't terribly clever about space allocation).

Another thing to watch out for is 4K sector alignment -- a drive that new probably has 4K sectors. If the partitions on it aren't perfectly aligned to the sector boundaries, you're going to take a performance hit. See something like: http://www.anandtech.com/show/2888

Also check what cluster size the partition is formatted to: if it's too small (e.g. 2K), it's going to be slower at writing large amounts of data.

You should also test the raw performance of the drive without going through the filesystem, but to do that requires either not caring about the data that's on it right now, or some things that are easier to do under Linux. If you wanted to non-destructively test raw write speed, you could do something like this:

- boot to Linux off some other drive, e.g. a flash drive or a CD
- do this:

dd if=/dev/sdx bs=4M count=200 of=/tmp/data_from_hd

(how fast that completes will tell you your raw read performance)

dd if=/tmp/data_from_hd bs=4M count=200 of=/dev/sdx

(now we're writing the same data back onto the drive; this'll tell you the write performance)

...where "sdx" is the name of your drive. The above assumes you have 2 GB of RAM or more.

You might need to dump the IO caches in between the read and the write to get accurate measurements; I'm not sure offhand the best way to do that -- but pulling the SATA cable out and sticking it back in would probably work

Anyway, if the raw write performance looks really good, that means your problem is in software (one of the things I mentioned, like sector alignment or cluster size) and you don't need to muck with your BIOS settings or hardware to fix it.

If your raw write performance sucks, you've got a bottleneck somewhere hardware-related and no amount of fiddling in Windows is likely to fix it -- maybe turning AHCI on would help. Windows can probably be made to boot with it turned on; it's just that Windows is really finicky about its I/O drivers. Running the install in repair mode after you turn on AHCI would fix it; there are probably nicer ways of fixing it than that, though.

~Felix.

 

[tecmo34]

To switch to AHCI, follow the steps listed in this Microsoft article ( http://support.microsoft.com/kb/922976 ) or use the fix it tool button, as well.

Once you follow the steps, shutdown, restart up the PC into your BIOS, switch controller to AHCI and save / exit. The PC will boot back up and install the AHCI drivers.

 

[maguserroris]

Thank you both for the replies!

@Felix: Thank you for the insight, these are a few things I hadn't considered. Yes, the drive is the boot drive, so I'll probably end up grabbing another and seeing if Windows isn't one of the issues dampening performance. Should I be using something like exFAT on the drive I'll be rendering to? I have a USB 3.0 external HDD that already uses a much larger cluster size (32K, if I remember correctly) and rendering to it is ~2% faster. (Still NTFS though.) As for testing the performance without going to the filesystem, I actually run LinuxMint alongside windows on this box so I'll definitely test that tonight.

@tecmo34 I will definitely try that and let you know how it goes. Thanks for the valuable tool.

 

[thetrivialstuff]

Should I be using something like exFAT on the drive I'll be rendering to? I have a USB 3.0 external HDD that already uses a much larger cluster size (32K, if I remember correctly) and rendering to it is ~2% faster. (Still NTFS though.)

I'm not familiar at all with exFAT; last I heard it was still sort of experimental -- is it included in mainline Windows now? Wikipedia says it was developed for flash drives, so I'd want to look into it a bit more and see if it does anything that's really flash-optimized (for instance, maybe it assumes that seek time is uniform and therefore stores directory structures in widely separated locations -- which would be bad on a spinning disk).

If it were me I'd format the drive as XFS, which I've found to be a great filesystem for large files and large data transfers. It's actually intended to be used in applications like large renders/processing. On my system it's noticeably faster than NTFS, ext2/ext3, and Reiser (to varying degrees). The tradeoff is the way it handles journalling and committing cached data to disk -- you stand to lose a bit more of the last few minutes of data if the power goes off, than under other filesystems. ...But as you're running under Windows, XFS is probably useless advice

As for testing the performance without going to the filesystem, I actually run LinuxMint alongside windows on this box so I'll definitely test that tonight.

I should add -- I'd feel better about suggesting that dd stuff if you had a current backup of everything before you did it

Do be careful with dd -- the commands I gave *should* be completely non-destructive, but it might not be a good idea to do it to the drive if you're booted to it when you're in Linux Mint. I think it should be safe (since no data should change at any part of the process), and it's something I would feel comfortable doing on my own box, but still -- be careful

~Felix.