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 |
 |
 |
 |
 |
| 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 |
 |
 |
 |
 |
| 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 |
| WD6400AAKS 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):
- 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.
- 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.
- 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.
- 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.
This entry was posted on Friday, July 25th, 2008 at 20:50 and is filed under it. Find similar posts by selecting any of the following tags: it, ssd, storage. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.
on 26.07.2008 at 17:20 stephen wrote:
this was done on an intel ich9r sata controller in windows vista sp1 x64
on 27.07.2008 at 00:54 BOMBOVA wrote:
Very well presented…. a good reference.. a list of the non vital write to disk services, that can be reduced, would be an asset… I am going to get a pair, for silent running, and now i know the limitations,…
Thanks Stephen, very well presented… Ralph G. Vancouver metro bc.ca
on 27.07.2008 at 08:13 Marc wrote:
i wonder if those fishy write results are caused by ICH9R issues. Is there any way you could test the SSD on an Areca (or any other good Sata/SAS raid controller)? I also think that the cache on those controllers would negate any problems you would have with the small writes but even with write cash disabled it would be interesting to see the results. Nice review btw but I’m not 100% convinced yet that the problem lies with the drive, it could be a controller issue.
on 27.07.2008 at 12:25 dave wrote:
What about the ATTO results from this page (small :
http://benchmarkreviews.com/index.php?option=com_content&task=view&id=200&Itemid=1&limit=1&limitstart=6
Writing small blocks does not seem so bad after all and they used ICH9R too…
or is this totally different compared to random write?
I wonder what OCZ has to say to this, I’ll post your results to their forum and see what happens :)
on 27.07.2008 at 13:05 stephen wrote:
my results and his do not conflict,
ATTO measures sequential performance, not random.
as you can imagine writing small chunks of data sequentially is very different than writing small chunks of data at random locations on the disc. The latter requires random write seeks.
on 27.07.2008 at 20:00 dave wrote:
Okay, thanks for clearing that up Stephen.
I still don’t understand why any SSD would have such problems with random write seeks
and on the other hand work perfectly with random read seeks (0.43ms is about 500 times faster!).
Is this caused by writing larger cells than reading (10MB compared to 512Bytes)?
And why does the WD-HDD write faster than it reads?? I’ve seen this behaviour with other “conventional” HDDs too…
on 27.07.2008 at 20:06 Fredrik wrote:
Do you use the drive in AHCI or IDE(Compatible) mode? Do you have write caching enabled for the drive? Apparantly these are two possible settings that might interfere with the drive’s performance. Even if you’re already aware of this perhaps you could let us know that it’s not due to a AHCI/caching problem.
The AHCI/IDE setting should be available somewhere in your BIOS. The write caching is available in Windows’ Device Manager.
on 27.07.2008 at 22:40 stephen wrote:
I have a place in ther article testing the various caching options on the SSD.
on 28.07.2008 at 06:14 John wrote:
good to see someone focus on random write performance – we all know read performance on SSDs are great and generally no problems there, but write performance is the final thing that needs to be addressed (esp on MLC drives, i think SLC arent so bad, would be good to see same benchmarks done with the sata ii SLC ocz/samsung drive)
on 28.07.2008 at 06:16 dave wrote:
I just got an answer in OCZ’s forum, RyderOCZ replied:
“SSD’s are not going to be fast in Random Writes.. it is a known fact.”
I wonder if this is the case for both SLC and MLC…
on 28.07.2008 at 10:40 Pixy Misa wrote:
Thank you! Finally, a review from someone who knows how to test drive performance!
The results are somewhat horrifying, though. Sure, random writes are the Achilles’ heel of MLC flash, but 250ms?! That’s… Unimpressive. (A thousand adjectives came to mind there, most of them unprintable.)
I have one of these on order; now I don’t know whether to cancel or to independently confirm your results. I’m planning to test on Linux, which shouldn’t make any difference, but we shall see.
At least we know why OCZ doesn’t publish proper performance data.
on 28.07.2008 at 11:38 Pixy Misa wrote:
Turns out OCZ do publish proper performance data – they just didn’t have it last time I visited their site. Full specs here. (PDF)
Now, there’s the question of why their published figures are 100x faster than yours. Something is certainly screwed up somewhere!
just got an answer in OCZ’s forum, RyderOCZ replied:
“SSD’s are not going to be fast in Random Writes.. it is a known fact.”
Yeah, I just saw that. A non-answer if ever I saw one. Don’t think RyderOCZ realised the difference between “not fast” and “horrendously terrible”.
I’ll post on OCZ’s forums as well and see if they’ll be a bit more forthcoming.
on 28.07.2008 at 12:31 Pixy Misa wrote:
Just thinking about it some more, the 250ms latency doesn’t make sense in light of the 46MB/sec sequential write figure. It would have to be using 16MB blocks for those two numbers to match, and I thought flash erase blocks were more like 128KB. (I actually went to find a datasheet to check this, but they’ve been disappeared. Samsung have taken all of theirs offline, as have Micron and Toshiba. Googling on “nand flash datasheet” found some, and confirmed 128KB as the block size, with a 2ms typical block erase time.)
I understand that the numbers you got are the numbers you got, but maybe there’s a reasonable explanation – and a fix.
on 28.07.2008 at 13:04 stephen wrote:
Pixy Misa: the sequential write figure i claim for the ocz core ssd is 73MiB/sec, not 46.
and the reasonable explanation is a huge “flash erase blocks” of 4MiB or 8MiB
on 28.07.2008 at 13:18 Pixy Misa wrote:
and the reasonable explanation is a huge “flash erase blocks” of 4MiB or 8MiB
Yeah, but that would be crazy.
Doesn’t mean it’s not true, but it’s a bizarre way to build a flash chip, let alone an SSD. Performance would be terrible. You’d get results like, well, the results you got. ;)
I don’t know. I guess I’ll have to wait until my drive shows up so I can replicate your tests. Once I’ve done that, I’ll pop back and let you know what I find.
on 28.07.2008 at 19:35 Michael wrote:
WD6400AAKS
read
write
average STR throughput
76MiB/sec
85MiB/sec
Are you sure? That doesn’t really add up, read and write performance (sustained) have to be the same since the only two factors defining the performance are the linear media velocity (depending on the track position) and the media area density, and if anything, writes should be a bit slower than reads.
Best Regards,
Michael
on 28.07.2008 at 20:49 stephen wrote:
hey michael, you are spot-on… I am aware of the geometry of rotating discs defining STR throughput, STR is linear proportional to radial distance of the head from the center of the spindle.. etc… etc..
The results you repeated in your comment are the throughput of iometer with 512MB reads and writes respectively…
I wasn’t paying too much attention to them, as the SSD was the focus of my attention, let me double check those results
thanks for reading.
on 28.07.2008 at 21:25 stephen wrote:
Thanks for the catch, i reran some tests on a WD6400AAKS i had lying around, not the same one, but regardless the STR numbers came out very close to writes, which is in line with what we should expect… article updated.
thanks.
on 28.07.2008 at 22:13 Pixy Misa wrote:
Someone pointed out to me that OCZ also used IOmeter for their random write tests, which just adds to the weirdness. I’ve posted to OCZ’s support forum with some questions, but no response as yet.
on 29.07.2008 at 01:09 stephen wrote:
http://www.ocztechnology.com/ssd/OCZ_Core_Series_SSD_SPEC.pdf
you mean these test results?
notes:
i saw some iometer results on pg6, notice it doesnt say R. Write (R. = random), so it’s likely sequential performance.
the only random write data they have is with HD Bench (not iometer), but more importanly they use 100MB request sizes… minimizing the importance of the “seek” penalty.
seems like they were tip-toeing around the hard facts when creating this spec-sheet..
funny, if not intentionally misleading.
on 29.07.2008 at 04:50 John Christian wrote:
What a brilliant analysis. I have been waiting for the dawn of SSD and its finally here! But these random writes of small files seems to be a terrible blow for this OCZ Core series, since many will be using these drives especially in the belief that they will speed up swap in Vista/XP and when they work with large Photoshop projects (perhaps it still does if that writes larger chunks of data). Anoter application I can think would slow it down to halt would be any torrent client as I assume they also write smaller chunks?
Hmm, I recently ordered one because the initial benchmarks show that its very fast, but now I am wondering wheter to cancel. You see, my desktop doesnt necessary have lots of small writes, the system has 4 GB of ram and seems to have little swap file activity, and I think perhaps this drive would still make my system feel faster especially for booting and starting applications.
At least it should be farily fast to take down and bring out of hibernation, since that is one huge block of data written?
on 29.07.2008 at 10:20 dave wrote:
I think NCQ (or sth. similar) would reduce writing small random blocks by arranging them consecutively,
for example when two applications try to write small blocks at the same time.
This was originally invented for conventional HDDs, but would make much sense here too.
That means of course, if random writes are really so slow and this is not a firmware / driver problem.
Maybe OCZ might solve this mystery, I’m still waiting for someone to answer Pixy Misa’s forum post at OCZ ;)
on 29.07.2008 at 10:38 stephen wrote:
NCQ arranges io’s in order of location, so the head can make many small seeks in a monotonic sequence, rather than going back and forth from one edge of the platter to the other, notice NCQ doesn’t change the locations of IOs, just the order in which they are read/written.
this concept makes little sense for this SSD, unless it were to move the location of the writes all in 1 cluster on the SSD (so all the writes can share the time-penalty), but that is often impractical in real-life… a random write is a random write, not a random re-arranged to be sort-of sequential.
on 29.07.2008 at 11:44 dave wrote:
Hmm okay, you’re right, my mistake ;)
So I guess writing small files sequentially (that is 1 cluster per file) is not faster than writing them randomly?
At least using mechanical drives this would increase performance similar to NCQ, If I’m not mistaken…
on 29.07.2008 at 12:37 Michael wrote:
Stephen
Thanks for re-running the tests. Nice work you did overall and also your comment on NCQ is dead on. The one issue I still have is the use of HDTune. If you look at the data, you will notice that the burst transfers are lower than any of the sustained transfer rates. From a technical point of view, that is not possible unless there is some major extrapolation and rounding of the data going on – and in that case, the results actually invalidate the test algorithms.
This is in line with the deiscrepancies you see between expected results and “real” data from HDTune. I am not trying to say that the numbers are all wrong, rather it appears that HDTune skews some of the results according to what it expects from the behavior of HDDs – and unfortunately this does not apply to SSDs.
A good example for the same thing is to run HDTach (large transfers) and then run the same drive in “Full Test” mode. What you’ll see is that the sawtooth transfer completely goes away and is replaced by a straight line across the entire array. There is still the problem that the benchmarks use the arithmetic mean to average between small and large file transfers so the numbers come out a bit lower than the actual performance of the drive – just as a caveat.
Also, even though I am not posting in that function, I am employed by OCZ, just don’t want to leave anybody in the dark about that. I also used to work for Seagate as part of the SATA / SATA2 taskgroup, specifically on NCQ enabling.
Anyway, keep up the good work!!
on 29.07.2008 at 16:10 stephen wrote:
I agree with you for the most part, and that is why i essentially ignored HDTunes results in my analysis. I think its calculating STR accross the drive with a small enough data size so the random-write penalty sometimes distorts the readings…
obviously the burst results is also bogus.
regardless, as i said i ignored HDTune in my analysis (after showing how bad it’s numbers predicted performance).
I stand by my conclusions with confidence, It isn’t the result of some benchmark’s (HDTune) anomaly.
on 29.07.2008 at 17:18 Michael wrote:
No, .. I am with you, what I wrote was meant for clarification only. SSDs have some weaknesses with random writes, especially in the type of pattern done by benchmarks that can potentially result in write buffer overflow and then “error / retry” scenarios because the buffers aren’t flushed yet. If the samples are small enough, then the calculated performance (I/O per sec) will also show really low numbers unlike the case in HDDs where you have a larger write cache.
There is still some work to be done until SSDs will be optimized for “perfect harmony” with the controllers but it is getting there.
on 29.07.2008 at 23:09 stephen wrote:
i have seen many forums claiming my analysis invalid because of HDTune’s weird results…
this is odd, as I do not base any of my results on HDTune reults.
-stephen
on 30.07.2008 at 01:17 Chris wrote:
Disabling AHCI and switching to IDE Mode will disable NCQ on any SATA II HDD you are using as well, also other cool features such as Hot Plugging require the controller to be in AHCI mode. If the this SSD really has issues with AHCI it’s a step backwards in technical standards and really a bad excuse for the vendor due to an obviously unfinished implementation. I also find SanDisk comments about Vista not being SSD compatible ridiculous, if it is so they could have said that more than a year ago already, I only see this as a bad excuse as they probably face the same problems as OCZ and don’t want to blame AHCI for it but instead look for something that is blamed by everyone and everything anyway :P
Also I am wondering why your WD6400AAKS has such inconsistent read performance. I also tested it here at ICH9R:
http://www.overclockers.at/storage_memory/user-test_kampf_der_333gb_platter_5_platten_von_wd_197941
on 30.07.2008 at 12:00 Newbie wrote:
I read somewhere that the cluster size for SSD should be much larger to correct these problems with small files writing. Something like 64K instead of 512bytes for a standard HDD ?
Maybe I am totally wrong, but…
on 30.07.2008 at 14:10 dave wrote:
And where exactly did you read this? 64K is quite much, every small file would take at least 64K of your disk space…
I got my OCZ yesterday and will try to bench it with IO Meter soon, especially Random Writes ;)
I did not notice any delays or disadvantages of this SSD compared to a normal HDD.
Here some test results from an older version of SiSoft Sandra (2007.5.11.35):
sequential read: 134MB/s
random read: 120MB/s
sequential write: 46MB/s
random write: 23MB/s
I don’t think this benchmark is very significant, but at least random writes are faster than on my second HDD ;)
on 30.07.2008 at 14:16 stephen wrote:
even 64kB for a file system cluster size, would be very small compared to the “cluster size” of this SSD which is multiple MiB.
on 30.07.2008 at 15:01 Michael wrote:
Dave, run the latest version of Sandra, make sure you have SP1 (vista) installed and after the installation, reinstall the chipset drivers because SP1 seems to nuke the chipset drivers that were installed before the service pack.
I just ran Sandra “before” and “after” and the “before” data are about the same as yours, whereas the “after” data get me some 55 MB/s sequential writes, the random writes are about the same — just a tad higher but that could be just the variability between different runs.
on 30.07.2008 at 17:20 Smirnoff wrote:
You all do understand that ICH9/!0 have issues with SSD drives, Pointless benching them on anything other than a proper raid card.
on 30.07.2008 at 18:25 stephen wrote:
as far as i know that is inaccurate, and why use a raid card if you aren’t using raid, in my benchmarks i was not using any raid.
intel ich9/10 are probably the best in class and industry standard for sata controllers…
on 03.08.2008 at 23:35 Fredrik wrote:
Are you able to verify these results on a different system (so as to remove any doubt this being due to compatibility issue I mean)?
on 09.08.2008 at 18:56 turquoiseowl wrote:
Excellent article. Thank you. I came across it because I’m experiencing ‘horrible’ real world performance with my new RAID 0 OCZ Core configuration.
Sure, read performance is smokin, but copying a folder of a few thousand small files onto the drive is very slow (once the write cache is filled up), as is Visual Studio linker output.
When copying the files to the drive, Performance Monitor on the physical drive (C) homes in at around 6MB/s write performance after a few seconds into the operation. The small files are then written in small bursts with pauses in between. Overall system responsiveness then grinds to a halt until the write is complete.
I’ve not tried DBMS write performance yet.
System is a failry old Gateway GA-K8NS Athlon 64 X2
NVidia nforce3 chipset
RAID 0 on the inbuilt nvidia controller (128K stripe size) 2 x OCZ Core 128GB
ATTO benchmark figures are impressive but highly misleading as to typical real world performance:
Read (Sequential): ~199MB/s max
Write (Sequential): ~120MB/s max
(Note that originally I had stripe size set to 64K but changed it to 128K after I couldn’t even record DVB TV onto the drive anymore. That more-or-less doubled the sequential write performance.)
Very disappointed given the cost of these two drives. Wondering about this MFT file system driver:
http://managedflash.com/home/index.htm
on 10.08.2008 at 13:07 stephen wrote:
a perfect implementation of 2 drive raid0 will effectively double the cluster size (or erase block size) of the SSD, but (ideally) not the random write latency…
While you might say its ok, since the STRs are doubled, in the real world its not quite double, and there is a bit of overhead in any raid system…
I imaginet he real-world result for a raid zero configuration of these SSDs will be somewhat worse than a single drive for small random writes.
I have not tested this in-house though.
Ideally we want smaller “ssd cluster size”, not larger.
on 11.08.2008 at 10:23 Danny Nilsson wrote:
I can only agree that SSD is a slow experience when using it as boot disk, and from ocz website i think they soon will run out of excuses for what is the problem. I looked at Guru3D review. i think OCZ must have payed them alot to make this review. because all they write is how lightning fast it feels to be running on SSD
on 11.08.2008 at 10:33 Danny Nilsson wrote:
another thing i don´t understand with SSD having problems with AHCI and NCQ. As i can see if your try running HDtune and press info. the NCQ feature is not enable. and would mean the bios will not use a feature on a disk if it doesnt exist, how could this be a problem than?
on 11.08.2008 at 11:23 stephen wrote:
yeah, honestly i think the stuttering as a boot drive in windows is because many programs do make small writes to the disc, not very many, but if the latency for writes is a significant part of a second, well it will be noticible.
on 16.08.2008 at 23:34 chris wrote:
Great work, thank goodness I didn’t buy one of these… I’m surprised they put this product out in the market with such terrible random write performance – so terrible that windows blocks for several seconds at a time for different tasks. Quite misleading by OCZ if you ask me…
Now let’s see if their v2 just announced after 1 month increases perf here so that it is actually a usable replacement for traditional HDDs…
Perhaps intel’s SSDs that were just announced will have better small random write perf.
on 23.08.2008 at 20:18 Esko Luontola wrote:
I just installed one of these OCZ SSD’s as my primary drive (WinXP and all programs), and because of the random write problems I already had to switch from Firefox to Opera. I experienced staggering on Firefox 3 every now and then, even with disk cache disabled (browser.cache.disk.enable=false).
In this case, fortunately I had good alternatives for a web browser (Opera was my browser-of-choice in the days of Opera 3.5 to 6, before Firefox was released), but I’m worried that soon I’ll be stuck with a random-write-heavy program which does not have good alternatives.
Maybe it is possible to use symbolic links to put the often randomly written files to a traditional HDD, and have everything else on a SSD drive. But this requires the use of tools like Process Explorer and File Monitor from Sysinternals to find out what are the files which are being written, which means lots of manual work (and creating symbolic links on Windows is not too simple either).
Since slow random writes are typical to all SSDs, a more long-term solution (in addition to SSD technology getting better) would be needed, for example a file system which avoids random writes. It would be nice to have benchmarks of ZFS on SSD compared to other file systems on SSD when using random-write-heavy programs. The copy-on-write design of ZFS converts random writes to sequential writes, which should solve the random write problem of SSDs (copy-on-write possibly creates more file fragmentation, but with SSDs file fragmentation is anyways no problem). Then we just need ZFS support for Windows. As far as I know, nobody is yet doing it (and I don’t think that I would have time to learn Windows driver development, although it did pop into my mind today – porting ZFS would be an interesting project).
on 26.08.2008 at 11:39 Erik wrote:
SSDs will work better if you guys use Vista instead of XP, hey, something Vista is good for :)
XPs IO is strictly queue based but Vista use a priority model which means the system doesn’t halt and waits for one io operation like a really slow DVD read(or SSD write).
Since SSDs uses heavy wear-level techniques I wonder why they haven’t implemented something like this for small random writes and translate them to sequential writes.
1.Request (buffering) of random (re)write of 100 small files at different parts of the SSD
2.Lock files in MBR
3.Transform them to sequential write and write it on SSD
4.Change MBR to point at newly written files
5.Unlock MBR files
Wearlevel algorithms should already do this to some extent since it will not let the SSD rewrite the same file to the same place all the time.
Hence a benchmark with purely random writes to specific hard drive sectors is not based on what happens in a “real world scenario”.
This would solve most of the scenarios of the problems with random writes and improve performance a lot.
on 31.08.2008 at 05:27 John wrote:
yes good point you make – i suspect it is nothing more than rush to market and minimising development cost (which would be significant factor in a low volume product) by just doing the bare minimum – with no random->sequential remapping of the writes or anything except the bare minimum wear levelling.
the intel SSD on the other hand, with the 2-3k random write IOPS look like they have done exactly as you suggested.
on 01.09.2008 at 10:21 Jketzetera wrote:
Erik,
Does not what you are suggesting require the SSD itself to be filesystem/filestructure/file aware (how else would it do the determinations you are suggesting)? As far as I understand today’s SSDs are not aware of the filesystem and what you are suggesting needs to be implemented on the operating system level to work.
on 02.09.2008 at 10:41 stephen wrote:
I think many of the comments here and elsewhere are missing the point, the random write penalty is actually a partial cluster write penalty,
it is very similar to the raid5 partial-stripe-write penalty
converting random writes to sequential writes wont help unless you store all the writes until you have a full cluster to write, but what happens when there are no empty clusters? what happens when you want to write a few bits on a large file, would you fragment the file just to avoid a “random” write? and would that really work?
the real *fix here is to have a drive with smaller clusters, the current gen ssd’s that i looked at have a several MiB cluster size, so a partial write means reading several MiB into a buffer, changing the bits desired, and writing the entire cluster. if it was several KiB instead of MiB, it wouldnt be nearly as severe… more akin to Raid5 penalties
on 03.09.2008 at 07:55 Esko Luontola wrote:
I figured out a way how to cope with programs which do lots of random writes.
First use Filemon (http://technet.microsoft.com/en-us/sysinternals/bb896642.aspx) to monitor all writes to your SSD drive. Keep it running in the background. Then when you notice that your programs stagger because of lots of random writes, look at Filemon’s log and see that which program is doing the writes, and more importantly, what are the files that it is writing.
Then use Link Shell Extension (http://schinagl.priv.at/nt/hardlinkshellext/hardlinkshellext.html) to create a junction for the folder where all the writes are being done, so that the junction will point to a folder on a traditional HDD.
I managed to solve the staggering of Firefox and Opera (with its “remember content on visited pages” and “disc cache” enabled) by placing “C:\Documents and Settings\MyUsername\Local Settings” on a traditional HDD. I created a junction at C:\SCRATCH-DISK pointing to F:\SCRATCH-DISK, and under F:\SCRATCH-DISK I have folder “F:\SCRATCH-DISK\Documents and Settings\MyUsername\Local Settings” where I moved all the files under “C:\Documents and Settings\MyUsername\Local Settings” (must be done when logged in as another user). Then I created a junction from “C:\Documents and Settings\ORFJackal\Local Settings” to “C:\SCRATCH-DISK\Documents and Settings\ORFJackal\Local Settings”. So now the Local Settings folder has quick random writes, and I can add other junctions as needed. If I need to move the scratch space to another drive, I can do it simply by chancing the junction at C:\SCRATCH-DISK (so no need to change every program-specific junction).
on 03.09.2008 at 18:27 vol7ron wrote:
I was curious if anyone has had a chance to benchmark a STEC products, such as the Mach8 or the IOPS: http://www.stec-inc.com/product/zeusiops.php
The pricetag is approx. $8-11k (20080903), but I was curious what their random-writes were. Their sustained facts are:
MB/s • 220/115
IOPS • 46,000/16,000
So I was curious if 1) the 220/115 sustained was just reporting peaks, or if it was truly the mean and 2) is it possible that they are seeing a much higher random read/write numbers, maybe something like 90/80. If so, this would be good news as it’s always the big names that catch on a little later.
on 04.09.2008 at 15:28 RM wrote:
Excellent write-up. Thanks for taking the time to provide in-depth analysis that the bigger sites so often lack. Great job.
on 12.09.2008 at 09:51 asdf wrote:
>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.
That is the only way it can work, because you can only erase flash in blocks. It’s not a problem, however. In most real life situations, the SSD is still nearly as fast as a good hard disk when writing. What you should use a SSD for is storing data that is written rarely and read back often. In that case, it beats any kind of “spinning” disk by orders of magnitude.
on 17.09.2008 at 04:06 The Fiddler wrote:
Excellent analysis.
I don’t know if you have seen this, but anandtech has published a review that confirms your findings: http://www.anandtech.com/cpuchipsets/intel/showdoc.aspx?i=3403&p=7. They claim this is a problem with the JMicron controller used in most MLC drives, as the Intel SSDs do not suffer from the issue.
These are horrifying results, as they essentially render these drives useless for day-to-day usage. Thanks for taking the time to test and publish your results :)
on 17.09.2008 at 04:22 jb wrote:
You can’t beat a spinning disk by “orders” of magnitude – that would mean 100X or 1000x faster. The interface limit is 300Mb/s (or is it MB?). You might beat the read performance of a spinning disk by two or three times but that isn’t even one order of magnitude!
Real world boot times for example are improved between 15 and 50% so maybe 2x performance.
on 18.09.2008 at 21:51 laurence wrote:
I figured out, from a test on anandtech(http://anandtech.com/cpuchipsets/intel/showdoc.aspx?i=3403&p=17), that the jmicron-controller used in this and several other ssd’s, has a buffer of only 16KB. That means he has to read and rewrite in bursts of 16KB, potentially giving additional overhead…
If I’m not mistaken, they use 8 chips in parallel, so if a single chip has an erase block of 128KB, 8 of them should have an erase-block of at most 1MB. So, there’s a lot of additional stalling somewhere…
But why is that controller apparently trying to rewrite every erase-block you’re writing to, apparently even if it’s still empty? It shouldn’t need to erase empty erase-blocks…. Or is this some file-system-issue as well(keeping filesystem-structure-data in every block)? Or what are its speeds in empty erase-blocks?
This drive has more issues than just big erase-blocks.
on 21.09.2008 at 14:26 stephen wrote:
jb, actually you can beat spinning discs by orders of magnitudes,
current unbuffered writes/reads on spinning discs have ~10ms access times
ssd tech promises <0.1ms access times
Laurence, the issue is essentially a partial cluster write, so it has to read the first and last cluster of most writes, because its unlikely to start or stop at the beginning or end of a cluster respectively.
on 27.09.2008 at 08:09 Esko Luontola wrote:
I managed to improve the OCZ Core performance in Windows by disabling NTFS’s updating of last access times, because those updates cause lots of random writes even if you were not modifying any files. Only one registry modification is needed: http://www.howtogeek.com/howto/windows/speed-up-disk-access-by-disabling-last-access-updating-in-windows-xp/
This especially speeded up operations which scan the drive contents. For example, Locate32 (http://www.locate32.net/) and JDiskReport (http://www.jgoodies.com/freeware/jdiskreport/) used to freeze my computer for a minute or two when they scanned my C:\ drive (running OCZ Core v1). But after this tweak both of the programs run in almost no time. Also starting up Windows (and more than a dozen programs which start automatically on startup) appears to have speeded up some.
So here is a recipe on how to avoid OCZ Core’s pitfalls:
1. Find out which programs do many random writes (with Sysinternals Filemon – http://technet.microsoft.com/en-us/sysinternals/bb896642.aspx), and move the files being modified to a traditional HDD. Use junctions and symbolic links (HardLinkShellExt – http://schinagl.priv.at/nt/hardlinkshellext/hardlinkshellext.html) when the path can not be changed (e.g. “C:\Documents and Settings\\Local Settings”).
2. Disable the file system’s updating of last access timestamps (http://www.howtogeek.com/howto/windows/speed-up-disk-access-by-disabling-last-access-updating-in-windows-xp/)
on 02.10.2008 at 14:21 vol7ron wrote:
I would like to add that in the last month I’ve learned a lot about the different SSD technologies, which includes the difference between SLCs and MLCs, the difference between the old OCZ and OCZ v2, but really what the main issue is with MLCs and what Intel has done to combat it.
While minimizing writes is a cure to a symptom, it does not cure the disease. If you really want to speed up the non-Intel MLC SSDs out there on the market, you will need a better write manager, rather than minimizing your OS writes. A good write manager is Managed Flash Technology (MFT): http://www.easyco.com/zx1285301141358249458/mft/index.htm
Only, this software costs $150 at the minimum. However, if we push this in the open-source community, perhaps someone can develop a free version.
Again, this would also not cure the disease, it’s more of a vaccine. The true answer is to align the OS block write size with the Nand block size. As the true problem isn’t writing to the SSD, it’s how it’s writing and the efficiency involved – evident by sequential write speeds. The issue is from writing to half-empty blocks, or the like, where the whole thing needs to be read and re-written to.
Tweaks to minimize writing is only a temporary help, but hopefully can be avoided in the future.
on 20.10.2008 at 18:53 rus-transit wrote:
I perform hard testing my OCZ Core SSD (v1).
And got the similar result.
It’s not possible post there all result,
but more impotant сonclusion can be demostrated.
For some low level testing I use ‘h2benchw.exe’.
(simple and power tools, but no so evident)
So…
Sustained transfer rate (block size: 128 sectors):
Reading: average 84231.5, min 83721.6, max 84261.2 [KByte/s]
Writing: average 23869.9, min 18634.8, max 36217.7 [KByte/s]
Random access read: average 0.19, min 0.15, max 0.24 [ms]
Random access write: average 223.17, min 1.37, max 903.72 [ms]
In addition to terrible write access (> 200 ms)
OCZ Core has low linear write speed: 23MB/s.
This results confirm by careful low level testing by ‘HD Tach’ and ‘Everest’.
This results confirm by real long write test in XP SP3, Vista SP1, SUSE 9.
Just generate long file. For example by ‘dd’
dd if=/dev/zero of=dump bs=64k count=128k
(under windows you can use ‘dd’ from ‘cygwin’).
Real linear write speed some different depending on
system cashe policy, cluster size and ‘dd’ parametrs
but not so significantly.
Under XP tests with min=1 and max=128 cluster size = (from 512B to 64KB).
Tests were spent on clear NTFS partition.
Results: 18 ~ 30 MB/s
May be some limitation are imposed by chipset in my notebook (i945PM ICH7).
But when I set block size 128KB in Everest,
I got 78MB/s average linear write speed.
128KB… its size OCZ recomended for RAID stripe size.
I think 128KB – size of flash page in OCZ Core.
‘Stripe size 128KB’ may be good idea for RAID controller in desktop,
but in win notebook it not realy.
64KB – max cluster size for NTFS.
Theoretically FAT32 support 128KB cluster for HDD with sector size >512B,
but OCZ Core firmware emulate 512B sector size.
Theoretically path of solution:
1. OCZ update firmware to emulate 1024B sector size : )
2. Microsoft do something for optimize SSD performance (I hope not only for Vista).
3. Using third party soft as MFT.
I think (3) is good way.
Let be large cashe. Now RAM is cheap and
2,5″ HDD are is better protected from sudden miss of power supply in notebooks.
Ideal variant: OCZ will develop and release such software.
OCZ is more interested in this : )
on 26.10.2008 at 00:18 D111 wrote:
Well done.
What is missing from the test is a through discussion of how legacy OS (Microsoft Vista and XP, most distros of Linux) and Applications (most common applications like Microsoft Office0 have been optimized for HDD speed, namely with things like:
-superfetch
-prefetch
- pagefile (as mentioned in article)
and other things like background defragging (Vista is the worst offender) and Indexing that just generates huge numbers of unnecessary little bitty file writes that brings out the worse of SSD performance.
Given the read speeds of even the lowest cost SSD, read caching makes absolutely no sense and background defragging also makes no sense given its conflict with wear leveling.
A detailed list of tweaks (and discussion of how to work around these issues with legacy OS and Applications) is available on the OCZ site here:
http://www.ocztechnologyforum.com/forum/private.php
What most SSD users do not appreciate is that an SSD is a fundamentally different technology, with very different performance envelopes.
Legacy OS and Apps (and Microsoft’s most modern product, up to Vista SP1) simply have no easy way of recognizing that it is running on an SSD, and it needs to “turn off” the built in fixes to help HDDs work faster, but kill SSD performance.
Until that were to happen, the only way it can be done is via manual tweaks, which is what we have assembled at OCZ’s link above.
It is interesting to note that these tweaks work for all SSDs, including the much higher priced X.25 from Intel.
Another route is to buy a software fix called MFT (Managed File Technology) from a firm called easyco.com that basically, works around these issues in using the host’s resources.
What I found is, with my tweaks, I managed to not only speed up a Core V1, but an Asus-Phison “SSD” in a eeePC 1000 to work at near 7200rpm 2.5″ drive speeds.
But it took a lot of patience, a lot of time diagnosing the problem with filemon and procmon (Microsoft Technet Utilities), then selectively moving the worst offenders in terms of little file writes to a RAM drive if it cannot be disabled, to make the SSD shine where it is best — random reads.
Good work…. now tell us how your SSD performed with the tweaks above!
on 26.10.2008 at 00:25 D111 wrote:
Hey, there was an error:
The proper link in the above post, if you can edit it, is:
http://www.ocztechnologyforum.com/forum/showthread.php?t=42487
Solved: Freezing and Stuttering in SSD drives.
Thanks
on 05.11.2008 at 09:04 rus-transit wrote:
D111 wrote:
What is missing from the test is a through discussion of how legacy OS (Microsoft Vista and XP, most distros of Linux) and Applications (most common applications like Microsoft Office0 have been optimized for HDD speed, namely with things like:
-superfetch
-prefetch
-pagefile
…
http://www.ocztechnologyforum.com/forum/showthread.php?t=42487
All recomendation was applied.
Once more: notebook, ICH7, WinXP SP3.
Useless…
On ICH7 (notebook) linear write speed for OCZ Core V1 not more 28MB/s.
Only low level raw write by 128k block – 78MB/s.
But on ICH9 (desktop) with Vista,
without any OS customization,
moreover in RAID (not IDE) controller mode
I got ~ 68MB/s linear write speed.
OCZ create 2.5″ SSD for new desktop : )
and some new notebooks.
on 15.11.2008 at 03:43 Thomas wrote:
I can totally confirm the horrible random write speed with my RAID0 of transcend ssds.
on 24.12.2008 at 21:16 s4e8 wrote:
just like RAID disk, unalign partition has some write performance penality. most time, first partition will start at sector 63. So write block never aligned to SSD internal block, sometimes you need erase 2 SSD block for single write.
on 22.03.2009 at 13:50 User Experience - SSD - Patriot Warp 32GB » random process | charlie 2.0 wrote:
[...] Day sale, I picked up a Patriot Warp 32GB SSD for $50 after MIR. While I had read all about the stuttering issues associated with the JMicron controller-equipped MLC SSDs, I reasoned that for $50, the potential [...]