Announcement

Collapse
No announcement yet.

New Linux Benchmarks Of SilverStone's HDDBOOST

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • New Linux Benchmarks Of SilverStone's HDDBOOST

    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

  • #2
    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.

    Comment


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

      Comment


      • #4
        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.

        Comment


        • #5
          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.

          Comment


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

            Comment


            • #7
              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.

              Comment


              • #8
                Sqlite

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

                Comment


                • #9
                  Originally posted by Chrome View Post
                  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.

                  Comment


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

                    Comment


                    • #11
                      Thanks but no thanks, this looks like what those "Hybrid" disks attempt to do, when in fact i would rather see those as two separate drives; that way i can place / and read only stuff in the SSD, and the bulk data in the mechanical device. Having some algorithm trying to "guess" what to place in the SSD is not efficient, this ain't no cache (and ram is better for that) :P

                      Also the i/o scheduler will get in the way, SSDs should use noop.

                      Comment


                      • #12
                        Originally posted by Chrome View Post
                        It isn't true. SQLite is 350 times faster with transactions
                        See http://www.sqlite.org/speed.html
                        1) "The numbers here are old enough to be nearly meaningless."
                        *** that means that sqlite, mysql, and pgsql have ALL CHANGED since those tests were made back in.... 2001!!!!

                        2) TRANSACTIONS ARE NOT SYNCHRONIZATIONS! They are TOTALLY UNRELATED!

                        Be aware that a sensible database server does NOT do what you are showing there.... just because it is a transaction does NOT mean that you shouldn't synchronize to disk. You are just synchronizing to a temporary place instead of the final place. Running in a transaction should NOT affect performance.

                        Note these results here:
                        MySQL: 0.114
                        SQLite 2.7.6: 13.061
                        SQLite 2.7.6 (nosync): 0.223
                        ** you see what difference synchronization makes? It runs 58.57 TIMES as fast without synchronization. This is entirely because of the write latency of mechanical disks!

                        Point of interest... they claim that it is running "nearly as fast as mysql" when sync is disabled.... according to who? Seems to me that mysql is completely destroying it in this test running at virtually DOUBLE THE SPEED.

                        On test 2 in that page, you throw the queries into a transaction, which disables (in the case of sqlite, but not mysql or pgsql) synchronization, and you see the sync and nosync values converge, sure. That's nice, but there's no synchronization, so its just writing to buffers and is therefore NOT A VALID TEST OF DISK PERFORMANCE.

                        In other words... test 2 is NOT APPLICABLE.

                        Further, it appears that this OLD version of sqlite was actually QUITE BROKEN when it comes to transactions. It should STILL be synchronizing, to a TEMPORARY DATABASE. What would happen if you have 32 MB of RAM (common for the old days when those tests were made) and ran a 100 MB transaction? Kablammo! LOL. And what would happen with that transaction? Well you wouldn't even have evidence that the transaction failed since it isn't synchronizing.

                        Further:
                        This type of transaction is a little bit weird. In some cases, it can be used for nightly mass updates (which you aren't going to be doing with sqlite to begin with... note that this is typically done by locking the database rather than running it as a transaction) but in most cases, it is used to ensure data integrity when dealing with multiple clients connecting simultaneously, ensuring that you don't, for example, have a select happening DURING an UPDATE and sending back invalid data. A typical transaction has to happen FAST so that the database doesn't go out during that transaction.... so you might do a transaction with 5 queries in it followed by a sync. So now start thinking about thousands of 5-query transactions, each followed by a sync. Well now you've completely lost any performance advantage that you perceived as being associated with transactions.

                        In other words: It doesn't help to prove performance under conditions that are never going to happen.

                        Transactions are NOT a method of boosting performance. They are a method of ensuring DATABASE CONSISTENCY by (a) applying all queries according to established parameters or rolling back, OR (b) by ensuring that all data in the database is consistent by ensuring that queries are performed in a reasonable ORDER (i.e. you perform an update while someone else performs an insert related to the same data -- bad things can happen).

                        Comment


                        • #13
                          1) I'm developing application which use SQLite. SQLite is still much faster with transactions.
                          2) I have never told that transactions are synchronizations. SQLite isn't database server.
                          Test results from SQLite can't be considered as results from database server.
                          SQLite is used in applications like Firefox and Chrome.
                          Test2 is relevant test of disk performance because this is how every real application should work. PgSQL was also much faster in that test with transactions - 28 times. Compare Test1 and Test2.
                          Inserting data using 5-query transactions will be approx. 5-times faster than without transactions.

                          Comment


                          • #14
                            There is error in previous post.
                            PgSQL was also much faster in that test with transactions - 23 times.

                            Comment


                            • #15
                              Originally posted by Chrome View Post
                              1) I'm developing application which use SQLite. SQLite is still much faster with transactions.
                              Under unreal conditions.
                              2) I have never told that transactions are synchronizations. SQLite isn't database server.
                              You implied it.
                              Test results from SQLite can't be considered as results from database server.
                              You're right.. because sqlite is about as useful as a text file.
                              SQLite is used in applications like Firefox and Chrome.
                              ... which don't actually need it. It also resulted in some serious PROBLEMS for firefox, mostly dealt with by now, but still memorable.
                              Test2 is relevant test of disk performance because this is how every real application should work.
                              No, it isn't how any application should work. NO application is going to be running 25k inserts into a database like that! The results are MEANINGLESS because nobody is EVER going to do that!
                              PgSQL was also much faster in that test with transactions - 28 times. Compare Test1 and Test2.
                              Which clearly identifies a DEFECT in that old version of pgsql.
                              Inserting data using 5-query transactions will be approx. 5-times faster than without transactions.
                              No it won't... because of those 5-queries, most likely only ONE of them will be an update or insert. The performance of read-only queries is unaffected by synchronization.

                              Comment

                              Working...
                              X