Skip to content
July 25, 2008 / steve8

How I figured out my OCZ Core 64GB SSD

a 275USD 64GB SATA2 Solid State Drive with Reads up to 120-143MB/sec and Writes up to 80-93MB/sec with a seek time less than .35ms? That’s what OCZ claims, and that is what got me interested, but I soon realized it wasn’t so straightforward.

Read into it:

OCZ Core 64GB SSD WD640AAKS (2-platter) hdd-cache enabled
read_HDTune_Benchmark_OCZ_CORE_SSD read_HDTune_Benchmark_WD6400aaks
oczreadio wdreadio
Notice above that the data placement on the disc essentially does not matter, other than being noisy, its fairly flat.In the IO meter test the performance does not improve much as you allow multiple outstanding IOs, this makes sense when you are dealing with almost negligible access times. Notice above the quadratically decreasing transfer rates, this is because of the linear relationship of speed and distance of the head from the center of the disc.. (the graph is non linear because data density per radial distance increases as you get further from the spindle (longer tracks).)In the IO meter test Notice that the drive benefits heavily with the use of Outstanding IOs, this allows the drive to read in such a way that is not as random, optimizing the order of the reads, among other things.


Here you see both drives approach their Average Read Throughput (as measured by HDTune) as the request size gets large enough (minimizing frequency of seeks). This is exactly what we would expect, and the rotating hard disc needs an enormous data size (>256MB) to make seeks insignificant, while the OCZ SSD only needs 8MB, impressive!

I know HDTune gives us an average seek time, but lets just say we didn’t trust HDTune, or we wanted more precision than the 1 significant figure it gives us on the SSD.

Let’s take random read throughput for a very large data size as an excellent measure of average read STR.

drive: random read throughput with a 512MiB data size. (iometer)
OCZ Core SSD 125 MiB/sec = 128,000 KiB/sec
WD6400AAKS 85 MiB/sec = 87,040KiB/sec

Now let’s take that as the average STR, and use it to measure average random seek times:

  IOps read of 0.5KB data read/sec time spent reading/sec time left seeking/sec time per random read seek
OCZ Core SSD 2220 1110 KB 1110/128000=0.00867 0.991328 0.447ms
WD6400AAKS 77.77 38.885 KB 38.885/87040=0.0004467 0.99955325 12.85ms

note that our average random read seeks and throughputs nearly matched what HDTune found.

Just for kicks, lets use our calculated numbers for avg STR and random read seek times, to see how well the predict performance:


Looks good, lets look at it on a log scale:


So on the read side of things, everything now makes sense, and this is a very impressive drive, what’s next?



‘write it down’, or, ‘the good, the bad, and the ugly’:



OCZ Core 64GB SSD WD640AAKS (2-platter) hdd-cache enabled
write_HDTune_Benchmark_OCZ_CORE_SSD write_HDTune_Benchmark_WD6400aaks
oczwriteio wdwriteio
Something seems fishy here with HDTune, the graph just doesn’t look right.the iometer results are pitiful, maxes out at 4 IOs per second, LOL, WTF?does enabling write-back cache in windows help?:


No it doesn’t.

these normal or boring results come at a relief after seeing the OCZ write results.
The HDTune graph is again as expected.It’s interesting in the IOmeter results is that the rotating disc does not seem to benefit from outstanding IOs for writes, as it did with reads, this is probably because the write-cache is doing its job very well, essentially yielding the same benefits as accumulating multiple outstanding IOs can yield.


Interesting that performance with any number of outstanding IOs less than(or equal to) 256 with cache enabled is roughly equal to the performance with 256IOs with cache disabled. well 256 chunks of 64KB is 16MB, exactly the size of the cache on this disc… So the disc cache yields similar benefits of having 16MB of outstanding IOs… this is to be expected, but nice to see.

Let’s see the random write throughput as data request size gets very large, should approach the average write STR as reported by HDTune:


Now it’s the totally reversed situation, the SSD needs a much larger data size before it gets good random write data throughput.

While the situation with the WD6400AAKS seems pretty normal, the SSD’s throughput blows away HDTune’s measurement of average STR as the transfer request size gets over 64MB. Something is definitely fishy.

HDTune was fairly accurate with read STR and read access time, lets see what happens when we trust HDTune’s numbers to predict random write performance:


… and here in log/log:


Here we see HDTune’s numbers predict the rotating disc results reasonably well, but totally fail to explain the SSD’s performance in random writes.

Let’s calculate random write seeks as we did before with reads:

drive: random write throughput with a 512MiB data size. (iometer)
OCZ Core SSD 72.768 MiB/sec = 74,514 KiB/sec
WD6400AAKS 85 MiB/sec = 87,040KiB/sec

Now let’s take that as the average STR, and use it to measure average random seek times:

  IOps writes of 1/2 KiB data write/sec time spent writing/sec time left seeking/sec time cost per random write
OCZ Core SSD 4.07 2.035 KiB 2.035/74514=0.0000273 0.9999726 245.7ms
WD6400AAKS 143 71.5 KiB 71.5/87040=0.000821 0.9991587 6.99ms
write cache disabled
58.6 24.3 24.3/87040=0.000279 0.997210 17.06ms

OCZ Core’s result seems unbelievably bad, while the spinning discs number seems ok, if not a bit high after disabling write cache, which makes sense.

I understand you probably would never want to disable write cache, but the result with it disabled is important for understanding performance, and thus being able to predict performance across other data use scenarios.

Now, lets see if these numbers explain the strange reality of performance with the SSD:


That’s pretty close, but can’t help but see the SSD predictions are still off a bit.

Note the 245ms random write seek time, while useful and, well, easy to understand, is not exactly how it works, after-all SSDs don’t have heads to seek.

If my understanding is correct, this SSD makes small writes by first finding a block or “cluster”, then reading in the entire cluster, then making changes to the buffered data from the cluster, and then writing the modified data as an entire cluster to the SSD.

So on tiny writes, the drive needs to read the entire cluster into memory, make the change, then write it to the flash, we have been referring to this wasted time as a seek, because we are familiar with it as a way to understand hard drive performance… but maybe we need to think a bit further:

on writes tiny compared to the cluster size, 1 entire cluster will be read into memory, the data manipulated, then written back… but as the write size gets significant relative to cluster size, there’s a good chance you will have to read/write 2 clusters, even if the data is smaller than a cluster… if you start to write 1KiB at the last bit of a cluster, you will write 512Bytes on one cluster, and 512Bytes on the next cluster.. basically paying 2 penalties of reading/writing data that you don’t care about.

As the data size gets very large relative to cluster size, you must read/write all clusters, but the first and last cluster are likely partially data you don’t care about, and hence you will pay a tax up to two times the cluster size.


Here we see it does make sense after all, since a write can pay up to 2 full “seek times” to make the transaction.

Random Write seeks/access time/penalty/tax options (for this drive 1 penalty is 245.7ms):

  1. for writes very small compared to the cluster size, almost always 1 full penalty is paid, the time-cost to read and write the entire cluster.
  2. for writes sizes that are an exact multiple of the cluster size, it is possible to pay 0 time in penalty, assuming the write starts at the exact beginning of a cluster. (highly unlikely), but this is essentially what happens in the middle of large writes, no tax is paid on all clusters other than the first and last in each sequential write.
  3. for significantly large writes (compared to cluster size) time-cost is 0-2 penalties, the penalty will probably be 1 partial at the start of the write, and 1 partial at the end, because its unlikely the start or end will be exactly the start or end of the corresponding clusters, those partials could be good or bad, depending on how much of the start and end clusters is your data, or existing data that you don’t care about.
  4. For a horribly fragmented drive, where free space is sparse, the penalties for a large write could be as numerous as the number of clusters on the disc! This situation is highly avoidable, and very unlikely.

Theoretically all writes have a 0-2 penalty tax, but its highly unlikely a tiny write will be written just at the end of the cluster, requiring a second cluster to finish the write, and on very large clusters you are likely paying 2 partial penalties, but if it’s very large, the time becomes insignificant. For this SSD, we see that around an 8MiB request size, writes pay a tax larger than 1 penalty cost:


Here we see that certain data sizes pay a higher average cost to make a random write, particularly 4MiB to 256MiB.

A quick and dirty estimate of the OCZ Core cluster size:

1 full time-penalty-cost of a random write = cluster-size/avg-write-throughput + cluster-size/avg-read-throughput

for this drive:

245.7ms = cluster-size/72.768 + cluster-size/125


cluster-size = 11.3 MiB, this should over-estimate the actual size..

and again, I am just doing this to get a ball-park figure…

maybe it’s 4MiB, maybe its 8MiB don’t know for sure.

Normal rotating disc drives have a “cluster-size” of 512bytes, (yes bytes).






The above analysis while interesting, is probably unnecessary for getting a reasonably clear idea of the performance of this SSD.





So, know what you are getting into here…

This OCZ MLC Core 64GB SSD is a fantastic drive for properly configured desktop users, read-heavy servers, and it’s even ok for large writes, but the drive is horrendously terrible for small random writes… here are the specs I claim are accurate:

OCZ Core SSD read write
average STR throughput 125MiB/sec 73MiB/sec
typical random access penalty 0.43ms 246ms
idle power use ~1W  
load power use <3W  

for reference, the specs I claim for the 7200 rpm rotating disc drive I used for comparison:

WD6400AAKS read write
average STR throughput 85MiB/sec 85MiB/sec
typical random access penalty 13.6ms 17ms
idle power use ~6W  
load power use ~9W  

If you buy this drive for desktop use in windows vista, make sure to use a page file on a different disc, or disable it altogether, not a bad solution since ram is so cheap these days…

Also, disable ‘System Protection’ and any other service that will write to the disc a lot.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: