[drizek]

So i've been reading the Anandtech article on the front page, and basically due to the way SSDs work the reason why we get stuttering is because they have to move a bunch of data around before they can do random writes. Using IOmeter you can test the latency of the drive doing random writes, and the bad SSDs take about half a second to write 4KB.

You can download Iometer here for windows and linux, and probably osx too if you compile it yourself.

Anandtech did their benchmarks doing 100% 4KB random writes to 8gigs of sectors and 3 outstanding IOs per target. We should probably scale that down a bit considering the size of our drives.

What I can't figure out though is how to set the number of sectors to be used. The app is kinda confusing since you have to input sectors instead just plain GB. I am playing around with it on my desktop for now, but if someone figures it out please post so we can get a standard set of options and so everyone else can benchmark their drives too.

I think these benchmarks should explain why so many people complain of stuttering on the 4GB STEC and the 64GB Runcore.

[mcwafflestix]

This is definitely a point of interest; I hope we can get some good comparative numbers on the STECs and the Runcores, as well as any other drives out there.

Given that these drives fit securely in the "budget" sector, I suspect that they all may have the same issue as to high latency random small writes, but only testing will tell us for certain.

One thing; does anyone know what the controller chip is on the Runcore and on the STEC?

Still waiting on my 32GB Runcore...

[gospeed.racer]

Someone needs to set a "standard", so everyone benchmarking will use the same settings so our benchmarks can be compared.

[drizek]

I still can't figure out how to use it. How do you define the number of sectors?

[bjd223]

Just a word to the wise with IOMeter. Don't go crazy and run the benchmark a bunch of times. Because when you delete files off your SSD the blocks are not emptied until you either write something there or completely rebuild the os install. So if you run IOMeter say 10 times you could potentially fill every block on your drive, which could cause performace issues when you actually need to write random IO.

They do make specific SSD based software that tries to clean up these unwanted full blocks. Don't get me wrong it is okay to run once or twice, but the sooner you fill those blocks the sooner your performance will degrade.

Also most SSD manufactors are including 'spare blocks' to help eliviate this problem from happeneing. As an example Intel's high end (mostly for server) SSD offerings; a 80 GB drive is only formattable to 64 GB, because that many blocks are allocated as spares for fast writing.

[drizek]

I just ran it on my 4GB STEC. I left the number of sectors at 0 and let it just use the whole drive. I had 310mb of free space, so I guess that should be the standard... just because.

To use it, open if up, click on WOrker 1 under the name of your computer and then select the ssd on the right. If it is in use then it will be yellow with a line through it, if it is not in use then it will be blue.

Either make sure that you have only 310mb of free space on the drive or figure out how many sectors add up to 310mb, and enter that number under maximum disk size. Set the # of Outstanding I/Os to 2(anand used 3 to simulate vista, but most of us are using a less sucky operating system so I think 2 will be good).

Then go into Access specifications and press "New". Here set it up to be 4KB, 100% Write, 0% Read, and 100% Random, and pick a name for it. Select your newly created profile and click the arrow to move it to the left column.

Go into Results Display, set the update frequency to 10 seconds, click the Run button and go your for lunch. The numbers should stabilize after some minutes. Lets let it run for 30 minutes(not including the time it takes to prepare your hard drive). Click Stop after the test has run for half an hour. We are interested in Average Response time and Maximum Response Time.

Ideally the average should be 1ms or less and dthe maximum should be in the teens. This is most likely NOT going to happen though. On JMicron drives the numbers are 500ms average and upto 2000ms maximum(ie. your computer will freeze for 2 seconds while it waits to do a write).

This will use up all your available disk space, so make sure that you close any open programs that may be trying to write to the disk.

[drizek]

I think filling up our drives is inevitable. I only have 4GB to work with. Installing linux will use 2GB, installing windows will use the other 2GB and now all the sectors have been written to at least once. I'm not sure if it even possible to do a secure erase on them either since the intel utility only works with SATA.

[drizek]

So my results on the 4GB STEC are

6.8 IOs per second
0.03MB/s
Average response time of 294.39ms
Maximum response time of 1039.49ms

That is basically about the same, slightly better, than what Anand tested their Dual JMicron drives to be. It certainly isn't a great number, but it is definitely better than the first generation, single controller JMicron drives.

Anyone else running it?

[jergarmar]

Originally Posted by drizek

So my results on the 4GB STEC are

6.8 IOs per second
0.03MB/s
Average response time of 294.39ms
Maximum response time of 1039.49ms

That is basically about the same, slightly better, than what Anand tested their Dual JMicron drives to be. It certainly isn't a great number, but it is definitely better than the first generation, single controller JMicron drives.

Anyone else running it?

Wow, those are pretty terrible numbers. I'm curious about two other SSDs: obviously the Runcore (which tests suggest are much faster at the important 4K random writes -- like 1.8-2.5 MB/sec instead of this terrible .03 MB/sec) but also the SuperTalents. SuperTalent's SSD does NOT have good random 4k writes, but some people have claimed that it doesn't stutter as much -- so maybe their latency is a bit lower than the STEC.

Also, as drizek mentioned, the numbers for the STEC are quite close to the JMicron numbers from that (awesome) article. If it's not the same controller, I might guess it's based on that controller.

[pr6srm]

If you read UnaClocker's work on his hard drive activity light mod here, you will know that the Runcore uses a JMicron JM20330 PATA => SATA chip. However, he doesn't state if he knows what the NAND controller is and unfortunately I can't find any photos that show the NAND controller chip on the runcore.

I took the stickers off my stock SSD to have a look and it would appear that the STEC 8GB one has A Samsung 819-822 controller.