Linked by Thom Holwerda on Thu 27th Sep 2012 19:36 UTC
Apple I bought a brand new iMac on Tuesday. I'm pretty sure this will come as a surprise to some, so I figured I might as well offer some background information about this choice - maybe it'll help other people who are also pondering what to buy as their next computer.
Thread beginning with comment 536900
To view parent comment, click here.
To read all comments associated with this story, please click here.
WereCatf
Member since:
2006-02-15

Well, you're talking laptop drives, which are often much slower than desktop equivalents due to much slower 5400RPM and a much smaller platter at the rim such that fewer bits fly under the heads per rotation. Your conclusion is absolutely true. However I was wondering about a HDD rig built for performance.


Well, the desktop drives I have are in striped RAID so the values reported by HDtune Pro are reflective of that. I still decided to run a benchmark for you, they still show what they need to although transfer rate reported is higher than it would otherwise be. These are 7200RPM 3.5" drives. Also, these are in use in the sense that my Windows - installation resides on them. I did kill all unnecessary background - processes, though, and let the system idle for a while before starting the benchmark.

First, I did two runs with the stroke - option on, ie. I limited the benchmark to the 8 gigabytes of outermost edge of the platters:
http://dl.dropbox.com/u/11811685/stripe1.png
http://dl.dropbox.com/u/11811685/stripe2.png

Then I disabled stroke and let it do the whole thing through:
http://dl.dropbox.com/u/11811685/stripe3.png

As you can see the seek times are consistent with what they should be for a 7200RPM drive and the graph shows quite nicely how transfer rates drop the closer to the center of the platters you go while seek times rise. On a non-RAID setup this would be much sharper, though, do keep that in mind! Also, as you can see even with two 7200RPM drives in striped RAID the system barely manages 200MB/s.

Does this answer your question? Also, I expect atleast a thank you :/

I have to admit thought that 500MB/s seems hard to beat, heck I don't think my (bargin priced) motherboard could even support that data rate.


SATA II supports up to around 300MB/s, SATA III is required for the 500MB/s+ speeds.

See https://en.wikipedia.org/wiki/Serial_ATA#Revisions

Reply Parent Score: 2

Alfman Member since:
2011-01-28

Werecatf,

"Also, as you can see even with two 7200RPM drives in striped RAID the system barely manages 200MB/s.

Does this answer your question? Also, I expect atleast a thank you :/ "

Yes, thank you for performing the experiment!

Were you surprised to see that much jitter in your graph? For all I know that could be normal. I expected the HDDs to do better. My own drives do an average 150MB/s at the edges, which would theoretically yield 300MB/s bandwidth in a raid. I'm guessing your disks could be slower due to a lower bit density and/or fewer platters. Or maybe your raid itself is a bottleneck?


With 15K disks, the bandwidth should double assuming no other component bottlenecks. So in theory 500+MB/s would be achievable using a raid of high performance drives.

Of course, it's futile for an HDD to compete with SSD on seek latency, which in my opinion is THE killer feature for SSD. HDD spindle speed is an inherent bottleneck. Although I've often blamed operating systems for over-reliance on small files during bootup. If these were packed in a 300MB archive, the OS could read everything into ram easily within 3-4s. The OS would rebuild the archive automatically based on self-assessed dependencies... this is totally tangential to our discussion, sorry.

I'll close by acknowledging your point, which is that SSDs are a win on performance.

Reply Parent Score: 2

WereCatf Member since:
2006-02-15

Were you surprised to see that much jitter in your graph?


The jitter is because the disks are in use. There's slightly less jitter on the disks that aren't in use, but there is still lots of jitter. Jitter is indeed perfectly normal, there is no way to avoid it -- it is simply a side-effect of the drives being mechanical objects.

My own drives do an average 150MB/s at the edges, which would theoretically yield 300MB/s bandwidth in a raid. I'm guessing your disks could be slower due to a lower bit density and/or fewer platters. Or maybe your raid itself is a bottleneck?


They do around 125MB/s individually, but I can't test them individually now unless I unpair the RAID and that would require relocating all the data somewhere else and all that. Not worth it.

With 15K disks, the bandwidth should double assuming no other component bottlenecks. So in theory 500+MB/s would be achievable using a raid of high performance drives.


Aye, that is true. But 15K disks aren't cheap, you'd save money just by buying two el cheapo SSDs and setting them up for RAID mirroring so that if one dies the other one will still function. Replacing the broken one wouldn't cost much, and you'd get the benefit of less heat, less noise and lower seek times. Also, as I said, even 15K disks have seek times at around 2-3 milliseconds, whereas SSDs generally have something around 0.02ms.

If these were packed in a 300MB archive, the OS could read everything into ram easily within 3-4s.


That is how many liveUSB/CD - systems work: they load the image to memory and only then execute its contents. This improves boot-up by several orders of magnitude, although it requires more memory.

The OS would rebuild the archive automatically based on self-assessed dependencies... this is totally tangential to our discussion, sorry.


No need to be sorry, plus I agree with you. Alas, I am not aware of any OS that is actually capable of doing that. It also doesn't seem like a feature worth putting much effort into anymore as flash-based storage media won't go away anymore. It's actually much more likely that in the future all mechanical drives will also incorporate some flash-media for OS-files and/or cache, something that completely eliminates the need for such an archive.

Reply Parent Score: 2