Thread: Intel's X25-M SSD
If like me you've been reading all the flash SSD drive reviews that come out, you might have also noticed that the performance on write-heavy workloads hasn't been too far ahead of traditional drives. It's typically been hit or miss as to whether the SDD would really be all that much faster on a real OLTP-ish database workload, compared to a good 10k or 15k drive (WD's Velociraptor is the usual comparison drive). That's over as of today: http://techreport.com/articles.x/15433/9 You can see what I was talking about above in their Database graph: under heavy load, the Velociraptor pulls ahead of even a good performing flash product (Samsung's FlashSSD), and the latency curve on the next page shows something similar. But the Intel drive is obviously a whole different class of SSD implementation altogether. It's not clear yet if that's because of their NCQ support, or maybe the firmware just buffers writes better (they should have tested with NCQ disabled to nail that down). With entry-level 64GB Flash drives now available for just under $200 ( http://www.newegg.com/Product/Product.aspx?Item=N82E16820227344 , price is so low because they're closing that model out for a better V2 product) this space is really getting interesting. -- * Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD
On Mon, Sep 8, 2008 at 7:12 PM, Greg Smith <gsmith@gregsmith.com> wrote: > If like me you've been reading all the flash SSD drive reviews that come > out, you might have also noticed that the performance on write-heavy > workloads hasn't been too far ahead of traditional drives. It's typically > been hit or miss as to whether the SDD would really be all that much faster > on a real OLTP-ish database workload, compared to a good 10k or 15k drive > (WD's Velociraptor is the usual comparison drive). > > That's over as of today: http://techreport.com/articles.x/15433/9 > > You can see what I was talking about above in their Database graph: under > heavy load, the Velociraptor pulls ahead of even a good performing flash > product (Samsung's FlashSSD), and the latency curve on the next page shows > something similar. But the Intel drive is obviously a whole different class > of SSD implementation altogether. It's not clear yet if that's because of > their NCQ support, or maybe the firmware just buffers writes better (they > should have tested with NCQ disabled to nail that down). What's interesting about the X25 is that they managed to pull the numbers they got out of a MLC flash product. They managed this with a DRAM buffer and the custom controller. Their drive is top dollar for a MLC product but also provides top notch performance (again, for a MLC product). The Intel SLC flash products, also due to be out in '08 are what are most likely of interest to database folks. I suspect prices will quickly drop and you will start hearing about flash in database environents increasingly over the next year or two. We are only a round or two of price cuts before flash starts looking competitive vs 15k sas products in light of all the advantages. This will spur price cuts on high margin server product drives, which will also cut r&d budgets. I'll stick to the predictions I made several months ago...flash will quickly replace drives in most environments outside of mass storage, with significant market share by 2010. I think the SSD manufacturers made a tactical error chasing the notebook market when they should have been chasing the server market...but in the end the result will be the same. This should mean really interesting things to the database world. merlin
I have been paying close attention to the recent SSD performance/price changes with a keen eye to server performance on various workloads and applications.
The real barrier is in the controller design, and IP surrounding that. All flash products with any amount of wear-leveling map logical addresses to physical flash addresses dynamically. An intelligent controller, with enough processing power and RAM (Intel's drive has 16MB of DDR SDRAM) and an intelligent design can translate ALL random writes into a sequential stream. With enough overprovisioning, the erasing and cleaning that goes on in the background will have very minimal impact. One thing many people will claim about a SSD is that the erasing and block management will get slower as the drive becomes more full. This is incorrect -- from the point of view of any block device it is always 100% full, it is not privy to the file system notion of 'free space'. Addresses are simply overwritten, which makes blocks that previously mapped to those addresses available for writing. By definition, every write is an overwrite.
This paper, is very enlightening:
http://research.microsoft.com/users/vijayanp/papers/ssd-usenix08.pdf
Given Intel's particular strenghts and engineering resources, its not a surprise that they are among the first to make a design like this (FusioIO seems to have solved the random write performance issue as well ?). But as the review you provided links to demonstrates, it is this IP that will provide the performance gains necessary for flash performance to be hands down better than all drives, for all workloads, all the time. It is the same IP that will provide the most longevity and reliability.
Also of note for others reading this thread, the review was for Intel's "mainstream" device, not the "enterprise" one. The enterprise one claims 3300 random 4k writes/sec and over twice the write throughput. I'm sure it will also cost twice as much for less capacity.
Of particular interest in the short term may be using cheaper, read-biased flash drives for ZFS L2ARC caches for a database -- it may be like running with a couple hundred extra gigs of RAM, but you can still use slow, big drives for mass storage. The price is prohibitive for putting your whole db on flash if it is not a small one, but this is not true if you're just talking about cache devices or xlogs or temp space.
http://blogs.sun.com/brendan/entry/test
The real barrier is in the controller design, and IP surrounding that. All flash products with any amount of wear-leveling map logical addresses to physical flash addresses dynamically. An intelligent controller, with enough processing power and RAM (Intel's drive has 16MB of DDR SDRAM) and an intelligent design can translate ALL random writes into a sequential stream. With enough overprovisioning, the erasing and cleaning that goes on in the background will have very minimal impact. One thing many people will claim about a SSD is that the erasing and block management will get slower as the drive becomes more full. This is incorrect -- from the point of view of any block device it is always 100% full, it is not privy to the file system notion of 'free space'. Addresses are simply overwritten, which makes blocks that previously mapped to those addresses available for writing. By definition, every write is an overwrite.
This paper, is very enlightening:
http://research.microsoft.com/users/vijayanp/papers/ssd-usenix08.pdf
Given Intel's particular strenghts and engineering resources, its not a surprise that they are among the first to make a design like this (FusioIO seems to have solved the random write performance issue as well ?). But as the review you provided links to demonstrates, it is this IP that will provide the performance gains necessary for flash performance to be hands down better than all drives, for all workloads, all the time. It is the same IP that will provide the most longevity and reliability.
Also of note for others reading this thread, the review was for Intel's "mainstream" device, not the "enterprise" one. The enterprise one claims 3300 random 4k writes/sec and over twice the write throughput. I'm sure it will also cost twice as much for less capacity.
Of particular interest in the short term may be using cheaper, read-biased flash drives for ZFS L2ARC caches for a database -- it may be like running with a couple hundred extra gigs of RAM, but you can still use slow, big drives for mass storage. The price is prohibitive for putting your whole db on flash if it is not a small one, but this is not true if you're just talking about cache devices or xlogs or temp space.
http://blogs.sun.com/brendan/entry/test
On Mon, Sep 8, 2008 at 4:12 PM, Greg Smith <gsmith@gregsmith.com> wrote:
If like me you've been reading all the flash SSD drive reviews that come out, you might have also noticed that the performance on write-heavy workloads hasn't been too far ahead of traditional drives. It's typically been hit or miss as to whether the SDD would really be all that much faster on a real OLTP-ish database workload, compared to a good 10k or 15k drive (WD's Velociraptor is the usual comparison drive).
That's over as of today: http://techreport.com/articles.x/15433/9
You can see what I was talking about above in their Database graph: under heavy load, the Velociraptor pulls ahead of even a good performing flash product (Samsung's FlashSSD), and the latency curve on the next page shows something similar. But the Intel drive is obviously a whole different class of SSD implementation altogether. It's not clear yet if that's because of their NCQ support, or maybe the firmware just buffers writes better (they should have tested with NCQ disabled to nail that down).
With entry-level 64GB Flash drives now available for just under $200 ( http://www.newegg.com/Product/Product.aspx?Item=N82E16820227344 , price is so low because they're closing that model out for a better V2 product) this space is really getting interesting.
--
* Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
mmoncure@gmail.com ("Merlin Moncure") writes:
> I think the SSD manufacturers made a tactical error chasing the
> notebook market when they should have been chasing the server
> market...
That's a very good point; I agree totally!
--
output = reverse("moc.enworbbc" "@" "enworbbc")
http://www3.sympatico.ca/cbbrowne/nonrdbms.html
"We are all somehow dreadfully cracked about the head, and sadly need
mending." --/Moby-Dick/, Ch 17
On Mon, 8 Sep 2008, Merlin Moncure wrote: > What's interesting about the X25 is that they managed to pull the > numbers they got out of a MLC flash product. They managed this with a > DRAM buffer and the custom controller. I finally found a good analysis of what's wrong with most of the cheap MLC drives: http://www.anandtech.com/cpuchipsets/intel/showdoc.aspx?i=3403&p=7 240ms random write latency...wow, no wonder I keep hearing so many reports of cheap SSD just performing miserably. JMicron is one of those companies I really avoid, never seen a design from them that wasn't cheap junk. Shame their awful part is in so many of the MLC flash products. -- * Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD
On Mon, 2008-09-08 at 19:12 -0400, Greg Smith wrote: > If like me you've been reading all the flash SSD drive reviews... Great post, thanks for the information. -- Simon Riggs www.2ndQuadrant.com PostgreSQL Training, Services and Support
Greg Smith wrote: > On Mon, 8 Sep 2008, Merlin Moncure wrote: > > > What's interesting about the X25 is that they managed to pull the > > numbers they got out of a MLC flash product. They managed this with a > > DRAM buffer and the custom controller. > > I finally found a good analysis of what's wrong with most of the cheap MLC > drives: > > http://www.anandtech.com/cpuchipsets/intel/showdoc.aspx?i=3403&p=7 > > 240ms random write latency...wow, no wonder I keep hearing so many reports > of cheap SSD just performing miserably. JMicron is one of those companies > I really avoid, never seen a design from them that wasn't cheap junk. > Shame their awful part is in so many of the MLC flash products. I am surprised it too so long to identify the problem. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
A fantastic review on this issue appeared in July:
http://www.alternativerecursion.info/?p=106
And then the same tests on a RiData SSD show that they are the same drive with the same characteristics:
http://www.alternativerecursion.info/?p=276
Most blamed it on MLC being "slow" to write compared to SLC. Technically, it is slower, but not by a whole lot -- we're talking a low level difference of tens of microseconds. A 250ms latency indicates an issue with the controller chip. SLC and MLC share similar overall performance characteristics at the millisecond level. The truth is that MLC designs were low cost designs without a lot of investment in the controller chip. The SLC designs were higher cost designs that focused early on on making smarter and more expensive controllers. SLC will always have an advantage, but it isn't going to be by several orders of magnitude like it was before Intel's drive appeared. Its going to be by factors of ~2 to 4 on random writes in the long run. However, for all flash based SSD devices, there are design tradeoffs to make. Maximizing writes sacrifices reads, maximizing random access performance reduces streaming performance and capacity. We'll have a variety of devices with varying characteristics optimal for different tasks.
http://www.alternativerecursion.info/?p=106
And then the same tests on a RiData SSD show that they are the same drive with the same characteristics:
http://www.alternativerecursion.info/?p=276
Most blamed it on MLC being "slow" to write compared to SLC. Technically, it is slower, but not by a whole lot -- we're talking a low level difference of tens of microseconds. A 250ms latency indicates an issue with the controller chip. SLC and MLC share similar overall performance characteristics at the millisecond level. The truth is that MLC designs were low cost designs without a lot of investment in the controller chip. The SLC designs were higher cost designs that focused early on on making smarter and more expensive controllers. SLC will always have an advantage, but it isn't going to be by several orders of magnitude like it was before Intel's drive appeared. Its going to be by factors of ~2 to 4 on random writes in the long run. However, for all flash based SSD devices, there are design tradeoffs to make. Maximizing writes sacrifices reads, maximizing random access performance reduces streaming performance and capacity. We'll have a variety of devices with varying characteristics optimal for different tasks.
On Tue, Sep 23, 2008 at 8:24 PM, Bruce Momjian <bruce@momjian.us> wrote:
Greg Smith wrote:I am surprised it too so long to identify the problem.
> On Mon, 8 Sep 2008, Merlin Moncure wrote:
>
> > What's interesting about the X25 is that they managed to pull the
> > numbers they got out of a MLC flash product. They managed this with a
> > DRAM buffer and the custom controller.
>
> I finally found a good analysis of what's wrong with most of the cheap MLC
> drives:
>
> http://www.anandtech.com/cpuchipsets/intel/showdoc.aspx?i=3403&p=7
>
> 240ms random write latency...wow, no wonder I keep hearing so many reports
> of cheap SSD just performing miserably. JMicron is one of those companies
> I really avoid, never seen a design from them that wasn't cheap junk.
> Shame their awful part is in so many of the MLC flash products.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
Scott Carey wrote: > A fantastic review on this issue appeared in July: > http://www.alternativerecursion.info/?p=106 > And then the same tests on a RiData SSD show that they are the same > drive with the same characteristics: > http://www.alternativerecursion.info/?p=276 > > Most blamed it on MLC being "slow" to write compared to SLC. > Technically, it is slower, but not by a whole lot -- we're talking a low > level difference of tens of microseconds. A 250ms latency indicates an > issue with the controller chip. SLC and MLC share similar overall > performance characteristics at the millisecond level. The truth is that > MLC designs were low cost designs without a lot of investment in the > controller chip. The SLC designs were higher cost designs that focused > early on on making smarter and more expensive controllers. SLC will > always have an advantage, but it isn't going to be by several orders of > magnitude like it was before Intel's drive appeared. Its going to be by > factors of ~2 to 4 on random writes in the long run. However, for all > flash based SSD devices, there are design tradeoffs to make. Maximizing > writes sacrifices reads, maximizing random access performance reduces > streaming performance and capacity. We'll have a variety of devices > with varying characteristics optimal for different tasks. > > On Tue, Sep 23, 2008 at 8:24 PM, Bruce Momjian <bruce@momjian.us > <mailto:bruce@momjian.us>> wrote: > > Greg Smith wrote: > > On Mon, 8 Sep 2008, Merlin Moncure wrote: > > > > > What's interesting about the X25 is that they managed to pull the > > > numbers they got out of a MLC flash product. They managed this > with a > > > DRAM buffer and the custom controller. > > > > I finally found a good analysis of what's wrong with most of the > cheap MLC > > drives: > > > > > http://www.anandtech.com/cpuchipsets/intel/showdoc.aspx?i=3403&p=7 > <http://www.anandtech.com/cpuchipsets/intel/showdoc.aspx?i=3403&p=7> > > > > 240ms random write latency...wow, no wonder I keep hearing so > many reports > > of cheap SSD just performing miserably. JMicron is one of those > companies > > I really avoid, never seen a design from them that wasn't cheap junk. > > Shame their awful part is in so many of the MLC flash products. > > I am surprised it too so long to identify the problem. > > -- > Bruce Momjian <bruce@momjian.us <mailto:bruce@momjian.us>> > http://momjian.us > EnterpriseDB http://enterprisedb.com > > + If your life is a hard drive, Christ can be your backup. + > > -- > Sent via pgsql-performance mailing list > (pgsql-performance@postgresql.org > <mailto:pgsql-performance@postgresql.org>) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-performance > > Anybody know of any tests on systems that have specific filesystems for flash devices?