Intel's First SSD Blows Doors Off Competition

theraindog writes "Intel is entering the storage market with an ambitious X25-M solid-state drive capable of 250MB/s sustained reads and 70MB/s writes. The drive is so fast that it employs Native Command Queuing (originally designed to hide mechanical hard drive latency) to compensate for latency the SSD encounters in host systems. But how fast is the drive in the real world? The Tech Report has an in-depth review comparing the X25-M's performance and power consumption with that of the fastest desktop, mobile, and solid-state drives on the market."

Comments

Oh Yeah?

[MyLongNickName]

My SBDs will blow THEIR doors off.

Re:Oh Yeah?

[MyLongNickName]

That's the beauty of it. You will never know!

Re:Oh Yeah?

[sabre86]

Maybe I'm being a bit pedantic, but in the dive bomber context, the SBD isn't the category of ship borne dive bombers, it's a specific one. SBD stands for Scout Bomber, Douglas -- aka, the Dauntless -- in the pre-1962 Navy naming scheme.

--sabre86

Re:Oh Yeah?

[Myrddin Wyllt]

That's not pedantry, it's rigour.

Thank you for taking the time to correct my misuse of a sixty year old acronym in an off-hand quip replying to a fart joke. It is this level of attention to detail which makes slashdot what it is.

Re:Your SSDs

[gardyloo]

Those're STDs.

Well, a step in the right direction

[Anonymous Coward]

A step in the right direction, but at $600 per 1000 I am gonna wait a bit longer before jumping on the SSD bandwagon.

Re:Well, a step in the right direction

[orkysoft]

Why? They're almost free at 60 cents each :-P

Re:Well, a step in the right direction

[Anonymous Coward]

Replying to you, since you seem serious, as opposed to sibling.

That's $600 per 80GB drive, with a minimum order of 1000.
You can't buy a single drive for $600. Or at least, not from Intel.

Re:Well, a step in the right direction

[Just Some Guy]

A step in the right direction, but at $600 per 1000 I am gonna wait a bit longer before jumping on the SSD bandwagon.

I'd place an order for one this instant if I could. My company uses a relatively small database, on the order of 40GB of online data. It's running on 4 SCSI-320 Cheetah 32GB, 15K RPM drives in RAID 0. By all accounts, this single SSD would out-seek the Cheetahs, meaning that our website can serve more customers and more quickly. This is a total no-brainer for a lot of applications, even at the current price.

Re:Well, a step in the right direction

[arth1]

Before rushing to buy these for database use, I would want a good look at MTBF values. Especially MTBF values for really heavy use, which may be completely different from estimated desktop use.

Re:Well, a step in the right direction

[Dancindan84]

It's running on 4 SCSI-320 Cheetah 32GB, 15K RPM drives in RAID 0.

I hope you know how volatile RAID 0 can be. A problem with any single one of those drives will screw up the whole works until you can restore from a backup. I can understand wanting to avoid RAID 5/6 if there are a lot of writes to your DB as performance of those arrays in writes are notoriously bad and RAID 1 would be a doubled hardware cost increase, but the ability to stay up and hot swap in drives after a failure is priceless.

Re:Well, a step in the right direction

[lgw]

Have you tried just putting 16GB of RAM in the database server? Nearly 16GB of cache for a 40GB database should work pretty well.

More geenrally, it's time to start thinking about DB servers that satisfy all reads from memory. It won't be long before the RAM available in a commodity sever is larger than many shops' database. Your caching model would want to be very different if you know you can cache everything.

Re:Well, a step in the right direction

[Anonymous Coward]

Why? They're almost free at 60 cents each :-P

Verizon cents.

Re:Well, a step in the right direction

[AllynM]

The review is slashdotted at the moment so I can't RTFM, but...

If a velociraptor beat an SSD in boot time, well, something is wrong with their test, or perhaps the bios was waiting on the SSD to initialize (entirely possible based on the added intelligence on their controller chipset). I just went from an SLC SSD to a velociraptor and the difference is painful. Boot time is slower. The system is just 'laggier'.

You can't judge the differences between SSD and HDD from charts and graphs on review sites. Reserve judgement until you have actually sat down at an SSD driven system. It is on par with the difficulty we all used to have explaining the difference in 'feel' between a single and dual cpu system back before they were mainstream.

Seek time dropping to 0.1 msec changes the entire equation. Events that would usually thrash your hard drive for several seconds happen *instantly* on an SSD. When you boot into the windows desktop, everything acts as if it was already cached, and does so even if other drive intensive tasks are already running.

Remember the reason everyone puts their swapfile on a second hard drive? SSD's nullify that reasoning.

A velociraptor beating it on write speed is irrelevant - a typical windows system will be reading from the drive occasionally during the writes. An HDD will drop to significantly below its max 'straight line' speed when you throw in a bit of random access (or fragmentation). End result: the SSD will still roast it in practical use.

I only switched to the raptor as a stopgap so I can sell off my current SSD in preparation to get this Intel unit. After seeing the change in speed / responsiveness in practical usage, the new SSD can't get here fast enough...

Re:Well, a step in the right direction

[Just Some Guy]

I hope you know how volatile RAID 0 can be.

Oh yeah, but we can do a bare-metal recovery in an acceptable amount of time, so a failure is more along the lines of "dangit, break out the tapes".

To answer other posters while I'm at it:

That chassis is maxed out on RAM. We could buy a newer, bigger system but this SSD would serve about the same ends for a lot less money and effort. Besides, at some point you have to flush those cached writes out to disk. Right now, that is sometimes a bottleneck on our system. If we could magically make those writes several times faster, it'd be a nice win.

Hey, I admit that our usage patterns probably don't match a lot of others'. These may not be ideal for everyone, but from what I've seen they'd work great for us.

Re:Well, a step in the right direction

[Korin43]

If you want a fast disk, get some i-RAM (you'll probably want it doing constant backups to a normal hard drive). It's expensive, and you max out at 4 Gb (unless you put it in some sort of RAID), but it's hellafast. With the price of 1 GB sticks of RAM, you could probably do 4 in RAID 0 for around $500 (is 16 Gb enough space?).

Re:Well, a step in the right direction

[wizzat]

Honestly, I think we're long past the time when we can even consider satisfying all reads from memory. Data volume is growing these days - and it's growing much faster than hardware.

Disclaimer: I work in the data warehousing industry.

Re:Well, a step in the right direction

[Nefarious Wheel]

I hope you know how volatile RAID 0 can be. A problem with any single one of those drives will screw up the whole works until you can restore from a backup

Oh my, pardon me, I am rolling on the floor laughing, biting the carpet and frightening the cat (ROFLBTCAFTC).

I remember reading these exact same arguments in articles written during the early days of computing, when people were complaining of the multi-platter nature of modern disk packs. These started hitting the market around 1963 I think. The argument went -- if you stack all those platters together, the failure of one platter would trash the entire set! Oh noes...

Re:Well, a step in the right direction

[drsmithy]

Plus RAID-0 ain't all it's cracked up to be. I had a Dell XPS600 with RAID 0 and one of the drives went kaput. Guess what happens to all the other drives then ? They're useless. 4X drives in RAID-0 means you have four times the chance of having a dead weight for a system.

RAID0: Optimised for failure.

Re:Well, a step in the right direction

[benow]

IRAMs don't play well with controllers... bad SATA implementation. Good idea, bad implementation, and a costly experiment on my part.

Re:Well, a step in the right direction

[ignavus]

It won't be long before the RAM available in a commodity sever is larger than many shops' database.

First law of data: data always expands to fill all available storage.

Second law: doubling your storage only buys you half the extra time you expected.

Final law: no storage is ever enough.

Re:Well, a step in the right direction

[afabbro]

Plus RAID-0 ain't all it's cracked up to be. I had a Dell XPS600 with RAID 0 and one of the drives went kaput. Guess what happens to all the other drives then ? They're useless.

RAID-0 is exactly what it's cracked up to be. It just may not have been what you're looking for.

Re:Well, a step in the right direction

[Atario]

The argument went -- if you stack all those platters together, the failure of one platter would trash the entire set! Oh noes...

And...what? It doesn't?

but is it fast enough

[kesuki]

to run vista, or do you need a RAID array of these drives.

Re:but is it fast enough

[Colonel Korn]

to run vista, or do you need a RAID array of these drives.

Vista does a lot better with slow hard drives than XP or most other operating systems, thanks to superfetch or whatever silly name they give to the precache of apps.

Re:but is it fast enough

[larry bagina]

SSD doesn't have a seek delay or rotational delay.

Re:but is it fast enough

[mooingyak]

That depends entirely on what kind of RAID we're talking about...

Re:but is it fast enough

[GreyWolf3000]

Yeah, but the reason it speeds up mechanical hard drives is because your kernel can schedule I/O on multiple spindles, effectively parallelizing your I/O. Flash chips don't have to batch up a lot of transactions in memory and then block the process for long periods of time. Flash does not typically operate synchronous to the bus speed it's connected to, so you could get some speed benefits by accessing multiple banks in tandem, but probably not as much.

More Details and Benchmarks Here

[Anonymous Coward]

This article at HotHardware, has a few additional tests that show real-world usage models as well as synthetic benchmarks: http://www.hothardware.com/Articles/Intel-X25M-80GB-SATA-Solid-State-Drive-Intel-Ups-The-Ante/

The PCMark Vantage tests are especially impressive: http://www.hothardware.com/Articles/Intel-X25M-80GB-SATA-Solid-State-Drive-Intel-Ups-The-Ante/?page=7

Damn it intel

[sakdoctor]

You were only supposed to blow the bloody doors off!

It's not the speed, it's the storage

[religious freak]

This is great and all, but if I had to choose, give me more SSD storage. It's got plenty of speed right now, I'll be impressed when SSDs can be an actual alternative to disks.

Re:It's not the speed, it's the storage

[grasshoppa]

Or you split up your expectations.

Honestly, how much space do you need for the OS and programs? Have an SSD for these functions, and a traditional HDD for pure space requirements. That'd be more economical too, at least in the short term.

Re:It's not the speed, it's the storage

[Firethorn]

At current improvement rates, I think that you're looking at 7-10 years before SSD becomes cheaper than 3.5" form factor drives for sheer storage. We seem to have been lagging at around a terabyte for a while. Meanwhile it seems that SSD is doubling in capacity per $ at it's 'sweet spot' each year at the moment.

Going by performance improvements, it'll only be a 2-4 years before companies start replacing their platters with solid state for intensive database operations, especially those biased towards reads. Those 10k-15k RPM drives are significantly more expensive and store less than 7200/5400 RPM drives.

The article mentions $595. Looking up, a 300GB 15k HD is $400 for an OEM. That's 5 times the size of the 80GB SSD mentioned in the article. Figure on a doubling each year, that'd be 3 years before the SSD exceeds current models. Figure in the lower power requirements and such, and I can see SSDs selling well before reaching parity based purely on size - their improved seek time, lower power demands, etc...

More details and Benchmarks here

[MojoKid]

This review at HotHardware shows some additional data including a few additional real-world usage models, like PCMark Vantage tests: http://www.hothardware.com/Articles/Intel-X25M-80GB-SATA-Solid-State-Drive-Intel-Ups-The-Ante/

Benchmarks start here: http://www.hothardware.com/Articles/Intel-X25M-80GB-SATA-Solid-State-Drive-Intel-Ups-The-Ante/?page=4

Blows doors off? I call bullshit.

[azav]

If anyone's seen the results, it's in first place in speed but not in a "door blowing manner". It's just slightly faster than the next guy. "Blows doors off" reads like marketing spooge trying to overhype something that has a small or no advantage over the next contender. Misleading title.

One test they never run - FRAGMENTATION

[Anonymous Coward]

Since SSD don't really have "sectors", do they fragment files the same way as HDD?

Also, what would the defrag speeds be?

Re:One test they never run - FRAGMENTATION

[bunratty]

The reason you defrag a hard disk is because the time to read a file is much less if the drive doesn't have to a random-access seek while reading the file. SSDs have fast performance whether they need to seek randomly or not, so why would there be a need to defrag an SSD disk? I would think it would only wear out the drive faster.

Re:One test they never run - FRAGMENTATION

[chill]

Yes, it would wear the disk out faster, but your original premise is flawed.

Clustering locations would allow for accessing large chunks of data with one fetch, instead of lots of little fetches. If you're old enough, think back to the Blitter on the Amiga and moving contiguous chunks of memory as opposed fragmented blocks.

Remember, RAM can get fragmented just as badly as a hard drive.

Re:One test they never run - FRAGMENTATION

[TheSunborn]

You can't grow a file in the middle. There don't exists any filesystem call that can do that.

Fragmentation only happens if you append to a file, but that kind of fragmentation should not be a problem for ssd, because all blocks(Except the last) will be full, and ssd don't read the 'next' block, any faster then any other black.

Re:One test they never run - FRAGMENTATION

[adisakp]

You never want to defrag SSD's. It just wears out the disk.

A good SSD has wear-leveling and write-combining techniques that keep the SSD "defragmented" automatically.

And it doesn't matter if the FS clusters are far apart as long as they are close to the SSD's hardware cluster sizes or the SSD intelligently combines them (which is what I believe Intel is doing since they claim a write amplification of only 1.1).

It's possible that the Samsung SLC chip stores data for the wear-leveling and write-combining operations which would remap the MLC in a non-fragmented way.

BTW, let me give you a naive wear-leveling / write-combining algorithm. I'm sure Intel has a better one because they've invested millions of dollars of research and the one I'm about to present to you could be done by a CS101 student:

1) You have a bit more than 80GB free for an 80GB drive (extra memory to take care of bad sectors just like a normal hard drive plus a small amount of required for the wear-leveling / writecombining)

2) You treat most of the storage as a ring buffer that consists of blocks on two levels: the native block size and a subblock size. The remaining storage (or alternate storage which may be the Samsung SLC chip on the MLC drives) is used to journal your writes and wear-leveling.

3) You combine all writes aligned to the subblock size into a native block and write them out to the next free native block in the ring buffer and keep a counter for the write to the block. If you run into a used block, and increment a counter (for wear levelling) and if the counter is below a certain value, you skip it to the next free block, otherwise you move the used block (which has been stagnent) to a more frequently writtento free block (which will now take less of a burden since it's had a stagnant block moved into it).

4) Anytime you make a write, the new sectors are updated in the memory area used for journaling / wear-level / sector remapping.

Assuming your reads can be done fairly quickly at the subblock level, it never matters if you have to "seek" for the reads and the drive won't fragment on writes because they are combined into native block sizes.

Re:One test they never run - FRAGMENTATION

[Thaelon]

I don't mean to attack directly, but you seem to be just well informed enough to be dangerous. First, you seem to think a quick reboot is something that should be no big deal and happen rather often. This is kind of appalling. If you need to reboot a computer often (more than to install new hardware), something serious is wrong with it or it's OS.

Secondly, this phrase, "Hard drives need explicit defragmenting" is misleading as all hell. Hard drives do not need defragmenting. They're made of platters, heads, etc. It's a filesystem that need fragmented. If you want to really nit-pick, it's files within file systems. Still, not hard drives.

Some filesystems are much more prone to fragmentation than others. Namely FAT, FAT32, and NTFS. They have no fragmentation prevention measures. Luckily there are good tools available to defragment them. Other filesystems like ext3 have built in fragmentation-prevention techniques that go a long way, so it's not nearly so big of an issue. They do have defragmentation programs but they don't seem to be trusted by some experts.

As for RAM fragmentation, it's such a non-issue that it's worth explaining. Note that it's Random Access Memory! It's designed to be read randomly. So reading two contiguous blocks is no faster than reading two blocks on opposite ends of the stick or address space. Hence fragmentation is a complete non-issue. And it's a near certainty that your RAM defragger will waste more time than just leaving the RAM alone. Assuming it's not just scamware anyway.

So why does that make your post dangerous? Perpetuating the myth that rebooting is cool and normal is harmful in the long run. It's harder on hardware and hell on uptimes. As is perpetuating the misunderstanding that hard drives need defragmented. Some undereducated, child-of-nepotism CTO might read your post, then take it to heart to the detriment of some entire company and all of their clients. Rebooting machines willy-nilly and attempting to defragment hard drives. In any case, misinformation on a public forum is dangerous, okay?

Gonna Take a Little While Yet

[segedunum]

SSDs are *very* compelling. The lack of mechanical moving parts, better seek time, better read and write rates, better random access (goodbye defragmentation?), less noise, lees heat, better power consumption and the ability for us to finally use a lot of the bandwidth of those interfaces we've had for ages - what's not to like?

However, they're going to need to get a lot cheaper, and we're going to need to see capacities in the hundreds of gigabytes before they start to take off, but take off they will.

Re:Gonna Take a Little While Yet

[BitZtream]

Write rates aren't THAT impressive, good but meh.

Less heat depends on the device, I've seen plenty of HOT SSDs, presumably due to the density of silicon in them and being first generation devices

Better power consumption ... where? Every SSD I've seen doesn't have a power saving mode, in power saving mode, as a general rule, mechanical drives are less hungry than SSDs.

They are really only compelling if you need fast seek times or for use in a laptop where shock (head strikes) is a potential issue at this point in time.

Re:Gonna Take a Little While Yet

[dgatwood]

Here's my concern in a nutshell:

Assuming a degenerate workload, with a naive algorithm that never remaps existing data except when it is written, death is swift. Assume a 256 KB flash block. Assume a 4 GB flash device with 2% spare. Assume 70 MB/sec. transfer rate. Assume TCQ/NCQ so that you can queue up requests without waiting for the previous request to complete. At 2%, you have about 81.92 MB of spares, or about 328 spares. You have to erase a block containing 256KB at once (one entire flash block). Write random data on a single data block over and over without caching. At 70 MB/sec. divided by a 256 KB block, you can write 280 blocks per second. That comes to about 1.17 seconds to go through all of the spares once. With a 10,000 erasure limit, that means you destroy all the spares in 2.38 hours. At that point, no further writes can occur because erasing and rewriting a block in place is inherently unsafe. Obviously for a 60 GB disk, multiply the numbers by 15. Even with 100,000 cycle flash, one could kill a drive with a naive algorithm in about four months. Okay, so it wouldn't be quite that fast because you'd have to issue write cache flush instructions between each write, but you're in the ballpark.

On the flip side, with a typical workload, a drive would likely last several years even with such a naive algorithm. This is why I'm concerned. It is quite possible for a company to implement a remarkably naive wear leveling algorithm and mostly get away with it except for a few unlucky people who end up with data loss. We saw this in the HD industry not too long ago with IBM claiming after the fact that their drives were not designed for continuous use. With such a history of reliability corner-cutting from storage vendors, I think there's good reason to expect better transparency from the flash drive vendors about how they are doing wear leveling, particularly if these products are expected to be used in enterprise installations as this drive supposedly is. Fool me once and all that....

I won't even get into the question of how one can possibly achieve anything approaching a 1.1 write amplification rate short of building custom flash chips that allow per-page erasure.... Maybe for certain synthetic workloads, but not for a degenerate workload (e.g. write blocks sequentially with a stride length of the same size as (or larger than) the physical flash block size until you exceed the capacity of the write cache, rinse, repeat).... Otherwise, that seems at least an order of magnitude lower than is plausible. I'd have to see white papers explaining exactly how they're doing this miraculously good wear leveling before I'd trust any low-cycle-count SSDs in anything resembling a production server....

Re:Blows doors off? I call bullshit.

[Kjella]

If anyone's seen the results, it's in first place in speed but not in a "door blowing manner". It's just slightly faster than the next guy.

Pardon me, but it is "blowing down the doors" (and the house too) in some tests, like this one. More than 3x the number of transactions of the second fastest flash drive? 7x faster than the slowest SSD drive? And the traditional HDDs are so crushed at the bottom I can't make out a ratio, but 30x or more? That is just ownage of the highest level. Yes, the write speeds aren't exactly compelling but for IO and read-heavy uses it's completely mindblowing.

Real use for SSD

[jcdick1]

Western Digital blah blah, 2.5" mobile blah blah. How do they compare to the mainline Hitachi and Seagate 15k Fibre Channel? EMC's SSD offerings? I want to know what I can expect for data warehousing on Oracle RAC.

Re:System boot time goes from 43 secs to 37 second

[Gloy]

System boot time is a function of many different factors, of which storage read and write speeds are only two.

SSD on PS3?

[nobodyman]

With more PS3 games offering an "install-to-HD" option, I wonder how SSD would affect performance. My theory is that playing a console game is a read-heavy experience, so an SSD should do quite well, right? Any rich gamers out there that have tried this out yet?

Re:Blows doors off? I call bullshit.

[CaptainPatent]

Pardon me, but it is "blowing down the doors" (and the house too)

Yes, the write speeds aren't exactly compelling but for IO and read-heavy uses it's completely mindblowing

Great, first the doors, then the house and now your mind...

I guess if there's anything we've learned is this drive really blows.

Re:where is the

[Anonymous Coward]

Probably right next to the dlsyexia tag.

Commercial uses don't fragment

[petes_PoV]

You store the database on these, so fragmentation questions are moot. Provided you've set the (database) block size correctly, the only time you'd have to modify (as opposed to write new) a block is to update a VARCHAR field that won't fit in the original size.

What would be interesting would be to put an Oracle database block interface on these puppies, instead of the normal filesystem interface. then you'd just have the database say to the storage "get me block X" and it appears. No filesystem overheads - which given the speed of these things could turn out to be significant.

Looks like we'll be back on RAW "disks" for databases. Plus ca change!

Thinking about using SSD for external backup

[Layth]

Anyone know about the general longevity of these devices?
The shelf life of a hard drive isn't incredibly impressive.

Price is over-rated

[sampson7]

I get a little tired of hearing about how the price has to drop orders of magnitude before SSD is viable. Shop around a little people!

I ended up buying a refurb Dell laptop for around $1000 with a 64 gig SSD. Was it the latest and greatest? Nope. But it was about $150/200 more than a similarly priced computer with a traditional drive (which of course, was larger). Since the only significant problems I've ever had with my two prior Dell laptops (admittedly a small sample) involved the hard drive, going with the SSD (especially when you include the "cool" factors -- both temperature and nerd-ism) was an easy decision.

But the point is that as SSDs become more prevalent, they become available at cheaper prices. I'm sure that as the Intel drives are rolled out, the "obsolete" drives currently on the market will continue to fall in price and become available to bottom-dwelling cheap-o-s like me who may not be able to justify $1000, but can rationalize $200 without a whole lot of difficulty.

Re:NAND versus Memristor?

[jeffb (2.718)]

Well, NAND has the whole "already exists" thing going for it.

Re:Blows doors off? I call bullshit.

[QuoteMstr]

If you read the article, NCQ actually makes sense. The Intel drive actually finishes requests before the CPU gets around to asking "are you done yet?". That time between the drive finishing and the drive being told what to do next is spent idle. By supporting NCQ, the drive can convince the CPU to send large batches of commands and get rid of that latency.

It's faster for the same reason that FTP is faster than IRC DCC. FTP just keep sending bytes as long as the other end doesn't close the connection. IRC DCC sends a packet, waits for a reply, sends the next packet, and so on.

Re:Your SSDs

[Anonymous Coward]

Those're STDs.

It burns when I read/write

Are you sure?

[RotateLeftByte]

Quote
  4 SCSI-320 Cheetah 32GB, 15K RPM drives in RAID 0.
End Quote

What company would really want to run their DB on a Raid 0 (Striped) Disk setup? Does this not put it at risk from a single spindle failure?

Re:Are you sure?

[Just Some Guy]

What company would really want to run their DB on a Raid 0 (Striped) Disk setup?

One who replicates the data to slower backup systems.

Does this not put it at risk from a single spindle failure?

If those were the only spindles involved, sure.

Re:Your SSDs

[Anonymous Coward]

Here's a prescription for 500 mg of PCCillin. Take it 3 times a day with meals, avoid alcohol and ganja. Pay the receptionist on the way out. NEXT?!?

Re:where is the

[sexconker]

The preferred spelling is lysdexia.