• Welcome to Overclockers Forums! Join us to reply in threads, receive reduced ads, and to customize your site experience!

60GB Vertex Benchmarking for Review - need expert advice

Overclockers is supported by our readers. When you click a link to make a purchase, we may earn a commission. Learn More.

I.M.O.G.

Glorious Leader
Joined
Nov 12, 2002
Location
Rootstown, OH
I picked up an SSD over the weekend. I'm going to be doing a review presenting results on both Linux and Windows 7.

The windows 7 part, I'm going to borrow from some of the tests performed by Anand here:
http://www.anandtech.com/storage/showdoc.aspx?i=3535&p=3

Now my question is, since I'll be flopping OS's and putting some time into this, are there any interesting tests you would like to have performed specifically? I plan on using 1.4 firmware, but could run something different if requested.

Also, is there anything on Windows 7 which can produce a bootchart similar to this one:
 

Attachments

  • bootchart.png
    bootchart.png
    35.7 KB · Views: 168
I would like to see a direct comparaison between firmware 1.3 and 1.4(1). I have 3 Vertex 60g and since I flash them to the latest fw performance took a hit. I've read on the ocz forums that they don't recommand to flash back to 1.3
 
They probably don't recommend it because I don't believe 1.3 includes Trim, which means your performance will degrade over time. I could run the test to see what performance is on a fresh drive, but I'd have to note that sticking with 1.3 would be detrimental long term.

Would you still be interested in seeing the results?
 
I believe, but am not certain, that the only differences between the FW are TRIM or GC. I dont believe, for example, 4k random writes were improved. So if I am correct, and I believe I am (IIRC it was the intel drives that got the improvement in 4k writes), the FW used wouldnt make much of a difference unless you are comparing GC vs. TRIM which would be VERY hard to measure accurately or measuring over time where the degredation occurs.

Make sure you do NOT use HD Tach and HD Tune. Those are made for mechanical HDD and their results are incosistent and anomolous, therefore are not valid.

I didnt check the anand article, but I would stick to ATTO and Crystal Disk Mark as they do not use buffered spot-samples for testing and therefore are reliable for SSD benchmarks whereas traditional tests such as IOMeter, HD Tach, HD Tune, and Passmark PerformaceTest do cause unreliable results like I mentioned above.

EDIT: One thing I would like to see are the peformance differences, after TRIM or GC of course, in regards to how much data is on the drive. We always hear, after xx% the performance will degrade. What percent is that specifically for that drive?
 
Last edited:
Earthdog, your golden buddy! I was aware, unspecifically, of concerns such as that - now I know specifically what mistakes not to repeat if I see them elsewhere.

I'm not sure about the performance boost on 4K writes, I thought I read an article from Anand that said OCZ got a boost, but Intel still trounces them in this area.
 
I would definately check that out regarding the 4k writes on OCZ drives. I do know, as you mentioned, Intel trounces them, but recall Intel's FW (not certain if its the latest relase) getting a boost in 4k write/read performance. I recall people on the OCZ forum asking if the newest FW would see these gains and recall Tony or OCZ saying no, but PLEASE confirm first (like I had to mention that you though ;)).

Also note my edit above for a suggestion on testing a quite common sentiment I see a lot...
 
I don't know very much about storage, but PCMark05 might be a good choice to include too. It's got a pretty good hard drive suite.
 
I don't know very much about storage, but PCMark05 might be a good choice to include too. It's got a pretty good hard drive suite.

EDIT: One thing I would like to see are the peformance differences, after TRIM or GC of course, in regards to how much data is on the drive. We always hear, after xx% the performance will degrade. What percent is that specifically for that drive?

I can do both these. Thx.
 
PCMark05 also shows those inconsistencies as HD Tach etc... :(

Other tools discard the need for measuring raw bandwidth speed, and take a 'real world' approach towards comparing product performance. PCMark05 and PCMark Vantage are two products that fit this build, made by Futurmark Corporation, and work (questionably well) for comparing HDD technology against SSD's. Our own test results section in the article demonstrated that SSD's cannot be benchmarked accurately with PCMark05 or Vantage. I haven't nailed down why these two test suites yield unreasonable results among SSD products, but there comes a point when you trust your eyes more than a benchmark.

http://benchmarkreviews.com/index.p...k=view&id=270&Itemid=38&limit=1&limitstart=11

You can see this is where I reguritated some of the info I posted above from. ;)
 
Sweet, less work!

Preliminary testing with a trimmed drive at 81.7% capacity:

4096000000 bytes (4.1 GB) copied, 20.5535 s, 199 MB/s
4096000000 bytes (4.1 GB) copied, 20.3481 s, 201 MB/s

Preliminary testing with a trimmed drive at 62.2% capacity:

4096000000 bytes (4.1 GB) copied, 21.4102 s, 191 MB/s
4096000000 bytes (4.1 GB) copied, 21.3841 s, 192 MB/s

1. Running the trim command when the drive is at 62.2% capacity
2. Writing data until it's 81.7% full
3. Running the same tests as above, without running trim:

4096000000 bytes (4.1 GB) copied, 25.8703 s, 158 MB/s
4096000000 bytes (4.1 GB) copied, 23.4927 s, 174 MB/s
4096000000 bytes (4.1 GB) copied, 26.4292 s, 155 MB/s

The command used to produce the garbage data and run these tests:

Code:
sync;time bash -c "(dd if=/dev/zero of=ff bs=8k count=500000; sync)"
 
If I am reading that right, this is showing that statement to be false?

I also recall hearing something about the space the drive needs to use TRIM/GC. Can you push up the used space a bit?
 
This test requires 4.1GB free to run. The partition it's running on only has 3.8GB available. The root partition only has 3GB available. So it'd be difficult to get the drive much more full, and still be able to perform the test. Maybe I'll look at fine tuning this for the final product - it would just require adjusting the count value.

Also worth noting, TRIM is being performed for the above tests thru the use of wiper.sh on Linux. TRIM is NOT supported by linux yet. I'm not certain if wiper.sh has any available space constraints compared to firmware/OS based TRIM/GC.

The implications of the results above are that free space does not have a large impact on performance, and that a fuller drive does not necessarily mean a slower drive. The testing isn't robust enough to say anything concrete. I'd be interested in finding a reliable source that claims SSD's suffer from being near capacity.
 
I will look for something reputable. Hopefully its not just forum propogated BS that I and many other got hooked with. I want to say its b/c TRIM or GC doesnt have 'room to run' but I could be WAY off on that.

I went ahead and started a thread at OCZ to ask. Hopefully Tony, RyderOCZ, HDCHOPPER, or someone along those lines that I personally know we can trust to give the right information out will respond. Here is that thread for reference: http://www.ocztechnologyforum.com/forum/showthread.php?p=476953#post476953

Also, another good SSD test is AS-SSD. Here is the results thread at OCZ: http://www.ocztechnologyforum.com/forum/showthread.php?t=66483

EDIT: Well good golly, that was a quick answer:
RyderOCZ said:
Absolutely.

If a block of Nand is not "free" then the controller has to read/erase/write. If a block of Nand is "free" then you can just write. Therefore, with little or no free Nand, you have a slow down.
 
You already got a response. My thoughts - if you run TRIM, isn't the block in essence "free" again?

If free space has an effect and what he says is true, then it must be due to how TRIM is implemented, and with a more full drive you are more likely to hit a block that is not "free".

Altogether, I'm not sold - which means I'll have to put in the testing time for a concrete answer. He's talking theory, and it seems there are variables unaccounted for - if TRIM is always running, regardless if the disk is full or empty, a relatively similar number of blocks should be considered "free" in the available disk space.

Chances are about 99% Ryder knows more than me about this, so I'd yield to him on understanding it however. I'm just saying it doesn't make sense on the surface, and I'll take it for truth once I see it for myself or once that behavior is demonstrated.
 
Maybe its that Open source...stuff... you are working with? ("I kid, I kid")

Do you want to post in that thread asking or can you word that so I can copy/paste it in there as a question based of your thought process and initial results?

This could be some solid information for your little review/article or for the SSD thread info thread we will (eventually) have here...
 
Hey, my review already has a napolean complex! It's not little! :mad:

Posted up over there, we'll see if we get any more detail... Either way, it will be interesting to see the results on win7 compared to this open sauce stuff.
 
Time to bring this back in, from the OCZ thread:

Checkout these results - at this point, I'm comfortable saying, with a high degree of confidence, that a trimmed drive using wiper.sh very near its full capacity does not suffer any performance degradation worth mentioning or worrying about. Any degradation experienced in non benchmark situations, unlike my testing here, is from the implementation of TRIM in firmware/OS. Refer also to my earlier results.

Preliminary testing with a trimmed drive at 87.3% capacity (93.9% capacity upon completion of the test):

4096000000 bytes (4.1 GB) copied, 20.917 s, 196 MB/s
4096000000 bytes (4.1 GB) copied, 20.9674 s, 195 MB/s
4096000000 bytes (4.1 GB) copied, 22.1089 s, 185 MB/s
4096000000 bytes (4.1 GB) copied, 20.4842 s, 200 MB/s

And just to be clear, more tests on a trimmed drive at 62.9% capacity:

4096000000 bytes (4.1 GB) copied, 20.4235 s, 201 MB/s
4096000000 bytes (4.1 GB) copied, 22.7503 s, 180 MB/s
4096000000 bytes (4.1 GB) copied, 21.9374 s, 187 MB/s

These tests aren't very tightly controlled, other applications running, etc, however I think the premise is clear regardless - drive capacity has little impact on performance for a trimmed SSD. Results on Win7 in comparison will be interesting, I'll keep you guys posted once I have an article ready.
 
Back