New Linux Benchmarks Of SilverStone's HDDBOOST

[phoronix]

Phoronix: New Linux Benchmarks Of SilverStone's HDDBOOST

Back in April we reviewed the SilverStone HDDBOOST, which was an innovative product from this manufacturer known for their computer cases that allows you to pair a solid-state drive and a hard drive in an attempt to experience the best of both worlds when it comes to storage performance. The purpose of the HDDBOOST is to increase the disk performance by enabling SSD speeds on the host hard drive while reducing write times to the SSD. From our Linux tests in that article we had a hard time getting this small device to provide any measurable performance gains, but in fact it caused some performance losses. In June, we then had results from SilverStone when they tested it under Ubuntu Linux with the Phoronix Test Suite. Since then we have been trying out a new HDDBOOST unit and it now seems to be working right.

http://www.phoronix.com/vr.php?view=15269

[l8gravely]

So basically, the HDDBOOST still doesn't give you any really useful boost, for the cost. You still need to provide the HDDBoost, as well as your own SSD, right?

So why no just use the SSD for root/var or other highly latency sensitive data, and the rest goes onto the regular HD?

So it's $50 for this, $100 for the SSD and then your disk of say $80 for 1tb. I dunno... the boost just doesn't seem to be there.

[deanjo]

I'd be worried about potential data losses. It's just one more link in the chain to fuck up.

[droidhacker]

The real benefit to combining an SSD with a magnetic disk is in getting better READ speeds out of the thing. Those tests don't seem to distinguish between read and write performance and look to be testing just overall use. I think it would be more useful to test things like random read/write performance and sequential read/write performance. No doubt there are certain applications/configurations that would greatly benefit from this combination of disks, assuming that the algo they use makes sense.

Personally though, I would simply opt for a small SSD + big magnetic disk. Put stuff I want to read fast onto the SSD and call it good. Though in theory, a device like this could be very useful, in practice, a little bit of planning can have a much greater effect on performance.

[droidhacker]

Another thing that should be noted is that the tests are being made against OCZ vertex [ii] SSD's, which don't suffer from the poor write performance typical of lower end SSD's. Try it with one of those 8 or 16 GB SSD's that used to ship with AAO's. Those disks have decent READ performance, but their WRITE performance was abominable. I suspect that this device will probably work VERY well with one of those... probably in the 70% range as suggested by SilverStone's website.

[deanjo]

Who knows, according to Seagate hybrid drives are not quite dead yet. We may some revitalization in this area.

[droidhacker]

In order for a hybrid drive to out PERFORM either an SSD or a spinning disk, there has to be SOME place where each is faster than the other.

Also note that the strength of the hybrid drive isn't necessarily in terms of raw performance (which is all that is considered by these tests), but in performance per $$. I.e., you can ALWAYS make a spinning disk faster by adding in a LITTLE bit of SSD to the mix... same reason as you have several levels of memory cache. You use very slow DRAM as your main memory because 4+ GB of SRAM would bankrupt you, and you stick in a smaller amount of SRAM close to the CPU so that every operation doesn't have to wait 50 clocks for the DRAM.

Now this HDDBOOST thing may or may not in any way resemble a hybrid disk. As I understand it, a hybrid disk may actually work the same as a cache heirarchy, whereas this HDDBOOST *appears* to be more like a selective-RAID0 in that it will select one disk or the other based on which it figures to be the faster disk for the particular operation -- read from the SSD, write to the spinner. Both forms have their application, of course. Not necessarily beneficial in the same situations.

And something about those SQL tests.... in order to ensure data integrity, database servers tend to synchronize very frequently. Remember when firefox initially switched over to sqlite and ended up causing some serious slowness? That problem was fixed by adjusting sqlite to sync less often. SSD's can perform a lot of small sync's much more quickly than a spinning disk because of the lack of latency. Based on the arrangement in the HDDBOOST, the writes are done fast to the spinning disk and then trickled to the SSD, which means that the database commits will be heavily bound to I/O waits due to the sync latency associated with the spinning disk... i.e. the weakness typical of SSD's that HDDBOOST is trying to work around is actually SLOWER DUE to the workaround in this particular case because it makes an incorrect assumption regarding which disk will actually be faster. In database transactions, an SSD will absolutely destroy a spinning disk, but HDDBOOST isn't aware of this being a database server.... so I don't suggest using one of these things on a database server. Better to stick with a straight SSD.

It may be possible to rewrite the HDDBOOST's firmware to make a more intelligent decision about which disk to sync to based on the size of the commit. If this was done, then I suspect that the HDDBOOST will at least not make it much WORSE than single-SSD, and this alone could make the HDDBOOST beneficial for MIXED-USE servers.... at least when combined with a lower end SSD than a vertexII... i.e. if it could handle the database like the vertex (original) and the balance of the tests came out the same, then we'd have a clear winner. Still wouldn't out do the vertexII though, since that SSD beats the spinning disk in every test... and there are therefore no cases (at least no cases that have been considered in this testing) where that combination would make sense.

[Chrome]

Sqlite benchmark isn't using transactrions (BEGIN, COMMIT)
http://sqlite.org/lang_transaction.html

[droidhacker]

Sqlite benchmark isn't using transactrions (BEGIN, COMMIT)
http://sqlite.org/lang_transaction.html

Doesn't matter. It is still synchronizing the filesystem after each INSERT.

[Chrome]

It isn't true. SQLite is 350 times faster with transactions
See http://www.sqlite.org/speed.html