Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

My SSD (on Windows XP) is working well, however, I get the following strange results from Crystal Mark 2004R3:

236 MB/s for  sequential read
 59 MB/s for  sequential write
168 MB/s for  random read 512KB
151 MB/s for  random write 512KB
 90 MB/s for  random read 64KB
 89 MB/s for  random write 64KB

How it comes that sequential write is much slower than non-sequential? It's only about half as fast as sequential write for my standard HDD. I'm quite sure my partition is properly aligned.

Could anybody post their results? Can anybody explain it?

EDIT

On my SSD, there's a FS with 4kB per cluster and I'm quite sure it's properly aligned, so each cluster corresponds exactly with one sector (a real 4kB sector, not 512B as Windows thinks). Now I see that according to the wikipedia the page size (i.e., the smallest erasable unit) is "often 4–8 kilobytes". The manufacturer doesn't bother with providing the page size in the datasheet.

At least 1/4 of the disk has never been used, so there should be a lot of free blocks allowing the writes to be fast.

EDIT 2

I forgot to say that my drive is Kinston SV100S2/128G.

share|improve this question
1  
What do you mean by non-sequential? You've only posted sequential benchmarks. –  sblair Sep 9 '11 at 23:56
    
I get similar results, but with lower sequential write values (probably due to the relatively poor sequential write performance of my X25-M SSD). –  sblair Sep 10 '11 at 0:06
    
@sblair: Fixed now. –  maaartinus Sep 10 '11 at 0:55
    
Are you running in AHCI or RAID? –  Shinrai Sep 12 '11 at 22:11
1  
@maartinus - It's also possible AHCI and RAID may perform identically. As long as you're not using IDE or a compatibility mode of some sort. I think XP is likely to be the biggest problem, though. –  Shinrai Sep 12 '11 at 22:32
show 5 more comments

2 Answers

This is only a guess - because XP does not support TRIM, your sequential write is going over blocks that once had data on them and needs to erase them before writing them, this will slow down the write performance of the drive.

When you are performing random writes, the drive might be writing to blocks that are truly blank, resulting in faster performance because the drive does not have to perform an erase operation first.

There are utilities for Operating Systems that do not support TRIM that will go through the drive and erase data on blocks that are not storing information for the filesystem.

Wikipedia - TRIM

share|improve this answer
    
I'd guess that TRIM is not necessary (see my edit), but I'm not sure. –  maaartinus Sep 12 '11 at 22:10
    
Did you ever say what drive it is? or am I missing something? Your edit is in the ideal world - it depends on the firmware and controller on the drive too. TRIM is necessary because even though the drive is half empty, if files were deleted or moved, the blocks will not be cleared. But you could have a firmware issue or it could just be how fast the drive is. Let us know what drive it is so we can help you figure out what is going on. –  Dustin G. Sep 13 '11 at 1:27
add comment

http://www.anandtech.com/show/2808/4

Those are pretty typical write speeds of the Intel X25-M.

According to Anandtech, a SSD controller that is optimized for random reads AND writes is expensive to make and implement. Since reads, especially random reads, are by far the operation the benefits the most from SSDs, Intel chose to favor that operation at the expense of writes.

From reading the glowing reviews about the X25, the write speeds has not hurt it. Keep in min these are still much faster than a mechanical harddrive's write speeds.

share|improve this answer
    
The funny thing is that my SSD sequential writes are slower than sequential writes for my normal HD by nearly 30%. They're also slower than non-sequential writes to my SSD, which I can't explain. I agree that writes are not that important. –  maaartinus Sep 12 '11 at 22:15
    
X25-M makes up for it in extremely low failure rate, but I agree that the numbers in the question seem REALLY wrong.. –  Shinrai Sep 12 '11 at 22:20
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.