Announcement

Collapse
No announcement yet.

Linux Solid-State Drive Benchmarks

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

  • #16
    Heh... Encrypted filesystems will be close to on a par for SSD's versus magnetic media- the bottleneck is in the encryption process through the CPU unless you've got a coprocessor involved. Next pass, I'd skip that part, Michael.

    Moreover, you're testing the known to be one of the slower of the bunch (in spite of the OCZ name on it...). I'd be more interested in what Transcend, Samsung, and Intel are doing in some of your testing, sans the encrypted fs...

    Comment


    • #17
      Anandtech looked a little deeper into the seemingly slow performance of some SSD's and found the culprit. In some cases, the average write latency for random 4K writes was 250ms! It really affects the cheaper drives, the intel SSD is nearly 3000 times faster.

      http://www.anandtech.com/cpuchipsets...spx?i=3403&p=8

      Comment


      • #18
        Hi,

        I'm using the Mtron MSD-SATA3525 32GB SLC in my home server (Asus EeeBox B202, for a bigger IMAP/mbox storage and VPN mostly) and am very happy with it. The Mtron is an SLC drive which is cheaper than all others I know and has decent access times aswell as read and write speeds (100/100 MB/s linear). It costs around €170 here including 19% VAT, so it should sell at around $200 in the US if it's available there. The OCZ Core V2 30GB sells at €87 here.

        I tried a 1st-generation MLC drive before, same size, same price 10 months ago - it was slow but read access was fast enough and what matters most in a note- or netbook to me is that it's absolutely 100% quiet. Problem with that drive was that debian updates were terribly slow due to write random access times when there was a lot of work to do (bigger update of 500 packages took a whole night!). This (the Mtron) drive is A LOT faster here, also compared to the original Seagate Momentus 5400.5 shipped with the EeeBox. So it is indeed a win. What is also noticeable though is that the Atom CPU makes this system noticeably slower compared to eg. an Athlon X2 2GHz even on hard disk heavy tasks like debian updates and IMAP access.

        So I think the Mtron SLC is a very interesting alternative to the Core V2 without the MLC drawbacks - might be interesting to compare?

        The OCZ Vertex seems to be very interesting, too, its 30GB incarnation is listed at €130 but still not available - and I have seen no benchmarks yet. Also these drives have the potential to become (close) as cheep as current generation MLC drives, so 1 €/$ per GB shouldn't be too far off! (currently best ratio is 1.45 €/GB)
        When you compare to smaller (<80GB) 2.5" drives, they are not that much cheaper: about 0.6 €/GB currently. The biggest (best ratio) 2.5" drives are at 0.16 €/GB of course, so that IS a difference (of about 10).

        Finally a question: is the USB port on the OCZ drives really usable for normal drive operations? I'm reading it's intended for firmware upgrades only (which is weird as this could be done through ATA commands).
        Last edited by edgar_wibeau; 01-02-2009, 09:25 AM.

        Comment


        • #19
          Originally posted by smitty3268 View Post
          Anandtech looked a little deeper into the seemingly slow performance of some SSD's and found the culprit. In some cases, the average write latency for random 4K writes was 250ms! It really affects the cheaper drives, the intel SSD is nearly 3000 times faster.

          http://www.anandtech.com/cpuchipsets...spx?i=3403&p=8
          My understanding of things is that some wear-levelling algorithms in some of the silicon on the controllers on these drives doesn't cope well with random writes because they didn't think about that being one of the mainline use cases on these drives- they worried about sustained reads and writes to files in the filesystem (which, you have to admit, is actually the mainline use case for the average user, not the massive numbers of random reads/writes that a DB or similar would do...).

          Comment


          • #20
            Originally posted by Svartalf View Post
            My understanding of things is that some wear-levelling algorithms in some of the silicon on the controllers on these drives doesn't cope well with random writes because they didn't think about that being one of the mainline use cases on these drives- they worried about sustained reads and writes to files in the filesystem (which, you have to admit, is actually the mainline use case for the average user, not the massive numbers of random reads/writes that a DB or similar would do...).
            Like the db firefox uses ? Or your IM client? Or those config files that are read by the thousand when you computer starts? Or all those icons? Or the small files in the latest update to your favorite package? Or those small blocks bittorrent clients save and retrieve at a time? Or those swap files when you don't have that much ram? Or all those thumbnails when you're previewing your photos?

            I think manufacturers shot for "very pretty benchmark values" and forgot to do their homework. I think small reads and writes is one of the main workloads of most computers, but they have been forgotten.

            Comment


            • #21
              I believe it's not possible to bypass the inbuilt algorithms of SSDs. But it would be an interesting read to see how an SSD with it's own logic and some fs on top of it stacks against the same flash chip, but with the MTD layer and JFFS2 handling the wear levelling.

              Comment


              • #22
                Originally posted by [Knuckles] View Post
                Like the db firefox uses ?
                DB? It's an http/html client. If it uses a DB, it's not in the same manner as oracle and it's not CONSTANTLY using it.

                Or your IM client?
                Uh, an IM client logs a constant slow stream to the same place and puts things to the display. NOT random operations. Sorry.

                Or those config files that are read by the thousand when you computer starts?
                Linear stream. NOT random accesses. Begin to see a pattern here?

                Or all those icons?
                Again, done largely once and NOT random access. I think you're going to find that the random writes are the problem with any SSD with "issues", NOT really the read operations.

                Or the small files in the latest update to your favorite package?
                How many, what size, how often. I think you're blowing this more out of proportion than it needs to be- you're exaggerating everything here to try to make a point. Unfortunately for you, I'm versed on things like performance of disks (including SSDs) because I have to be to max out performance of things like network monitoring probes and deep packet inspection engines for my day job. The stuff you're bringing up isn't IN the use cases normally- just like I said.

                Or those small blocks bittorrent clients save and retrieve at a time?
                This might be the case, but honestly, HOW many people that're in that market segment using laptops would be bittorrenting things?

                Or those swap files when you don't have that much ram?
                Of the examples you give, the ONLY one that matches up with their envisioned customer market would be THIS one. Everything else doesn't work.

                Or all those thumbnails when you're previewing your photos?
                Typically, you thumbnail once on the main UI. Inside an app, you don't thumbnail to disk.

                I think manufacturers shot for "very pretty benchmark values" and forgot to do their homework. I think small reads and writes is one of the main workloads of most computers, but they have been forgotten.
                Actually, it's a big mix of both types of operations, based on my 30 years as an enthusiast and 25 years as a professional developer. They missed their homework just a bit (and it shows on some of them- and I believe I pinned why the random write problem is there...), but apparently so did you. Next time, I suggest you contemplate what actually gets done repeatedly and often- you only had ONE of all of that list as actual issues with the random write performance for an average user (You aren't, neither am I- and bittorrent, while it's the other one that's "valid", isn't being used as much unless you're talking someone playing World of Warcrack which uses it to push updates more efficiently, you've got someone getting Linux distro ISOs, or doing warez...)

                Comment


                • #23
                  Originally posted by curaga View Post
                  I believe it's not possible to bypass the inbuilt algorithms of SSDs. But it would be an interesting read to see how an SSD with it's own logic and some fs on top of it stacks against the same flash chip, but with the MTD layer and JFFS2 handling the wear levelling.
                  JFFS2 isn't the sharpest tool in the shed performance-wise. The compression and journalling will slow you down more than the chips' weak wear levelling performance will.

                  Comment


                  • #24
                    Svartalf, as I wrote above, I had a 32GB first generation MLC SSD in use which was slow on linear read/write yes (like 30/20 MB/s), but the major bottleneck even for desktop usage was the random write rate here. Problems were (unexpected to me) firefox usage which froze for some seconds regularly even though I had disabled its disk cache, a major problem were big debian (or did I use ubuntu?) uptdates where a 500 package upgrade (after download) took a whole night (8 hours) instead of maybe half to one our using a normal (not fast ~40 MB/s) notebook disk.

                    So I can at least confirm some of Knuckles' claims. Random reads are not the problem with any SSD I saw so far though - your point.

                    Regarding random writes, I got values ranging from 90 to 300 ops per second (depending on how I measured, block size was 4k)* using the Mtron 3525 SLC SSD on an Atom N270 EeeBox B202 which also is not blazingly fast, yet fast enough for desktop usage. The brilliant thing are random reads, exceeding 10k/s upto more than 20k/s which makes this little guy kick any spinning disk where nobody wants to be kicked

                    * Linus claims 8500 writes/s using 4k blocks for the Intel MLC SSD here (7th paragraph). Now this would really be amazingly fast! I'd really like to know how the other 3rd gen MLC SSDs like the OCZ Vertex will perform.
                    Last edited by edgar_wibeau; 01-05-2009, 05:15 AM.

                    Comment


                    • #25
                      Originally posted by Svartalf View Post
                      Originally posted by Knuckles
                      Like the db firefox uses ?
                      DB? It's an http/html client. If it uses a DB, it's not in the same manner as oracle and it's not CONSTANTLY using it.
                      Firefox 3 uses an sqlite database to track bookmarks, browsing history and power its address bar. Yes, this entails many random reads and writes and yes it's *painful* on 1st-gen SSDs.


                      Originally posted by Svartalf View Post
                      Uh, an IM client logs a constant slow stream to the same place and puts things to the display. NOT random operations. Sorry.

                      Linear stream. NOT random accesses. Begin to see a pattern here?
                      By itself the IM client may not be a problem, but try having a conversation while upgrading a package. Latency becomes a significant issue and the whole IM becomes unresponsive (talking about Pidgin here).

                      The point you are missing is that while most desktop programs use the drive more or less linearly, you typically run more than one program at once. Latency is a real issue that renders (current and previous) cheap SSDs, USB sticks etc unsuitable for day to day usage. To give you an example, the original OCZ Core drive drops down to *4* ops per second on random writes - not nearly enough!

                      If you wish to see this effect for yourself, try the Ubuntu LiveUSB on a 2GB usb stick with read/write support. Reads are plenty fast (Firefox launches instantly!) but writes make the system quite unresponsive.

                      Edit: From Linus' blog:
                      And the sad part is that other SSD's generally absolutely suck when it comes to especially random write performance. And small random writes is what you get when you update various filesystem meta-data on any normal filesystem, so it really does matter. For example, a vendor who shall remain nameless has an SSD disk out there that they were also hawking at the Kernel Summit, and while they get fine throughput (something like 50+MB/s on big contiguous writes), they benchmark a pitiful 10 (yes, that's ten, as in "how many fingers do you have) small random writes per second. That is slower than a rotational disk.
                      Last edited by BlackStar; 01-05-2009, 09:09 AM.

                      Comment


                      • #26
                        I'd really like to see some benchmarks for SATA vs SSDs being used as swap partitions. I've often wondered whether there would be any benefit to using SSDs (or even memory sticks/SD cards) for swap.

                        Comment


                        • #27
                          Originally posted by Nexus6 View Post
                          I'd really like to see some benchmarks for SATA vs SSDs being used as swap partitions. I've often wondered whether there would be any benefit to using SSDs (or even memory sticks/SD cards) for swap.
                          +1 i've wondered about this myself too.

                          @Svartalf: both firefox and my IM client like to use a lot of sqlite. Already two "apps" in kde 4 (amarok and akonadi [not really an app, used by many apps]) use mysql.
                          I think Blackstar's answer already covered it pretty well too. You are free to disagree of course

                          Comment


                          • #28
                            Memory sticks and SD cards would die quickly from using swap.. BTW why does this not affect SSD's? Or does it, but they just have higher quality flash chips, and so can withstand more write cycles?

                            Comment


                            • #29
                              That and they also implement wear-leveling logic, where the drive tries to spread writes evenly to avoid wearing out the same cells.

                              That said, I'm still not convinced that this is a real problem. Someone tried to kill USB sticks by writing data non-stop for *months* and they didn't fail (sorry, don't have the link). All things considered, SSDs are far more reliable than rotating glass disks, moving needles and oil-leaking motors.

                              Posting with Archlinux on a 8GB usb stick

                              Comment


                              • #30
                                BlackStar: The ones trying to kill the USB stick are german c't magazine (http://www.heise.de/ct/), they are using a small (2GB IIRC) but fast USB stick. Small and fast so that their chance is higher to really wreck that stick. Their test is indeed running for months now, I haven't tried to find anything online though, because I read ebaout it twice in the paper issue. To all who don't know: c't magazine is a VERY believable source. They use to point their fingers on stuff no other IT magazine (online nor offline) ever touches.

                                Comment

                                Working...
                                X