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?

[xpuppykickerx]

Dude!!! You have more than one!?!

Re:Oh Yeah?

[MyLongNickName]

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

Re:Oh Yeah?

[Anonymous Coward]

Your Serious Behavioral Disabilities will blow their doors off?
What's that supposed to mean?

Re:Oh Yeah?

[Myrddin Wyllt]

Don't be obtuse - he obviously means his Ship-Bourne Dive-Bombers.

Re:Oh Yeah?

[Guysmiley777]

Do you mean GBU-39 Small Diameter Bombs?

Re:Oh Yeah?

[insllvn]

SBD?

Several interesting possibilities...

Re:Oh Yeah?

[Anonymous Coward]

that link doesn't work but this video has an excellent description about SBDs in this video

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?

[saleenS281]

small block dodge?

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:Oh Yeah?

[glittalogik]

Best thing I've read today, thank you!

Re:Oh Yeah?

[Anonymous Coward]

My SBDs will blow THEIR doors off.

Did you perhaps mean: "STDs"?

where is the

[ionix5891]

"slahsdvertisement" tag

Re:where is the

[Anonymous Coward]

Probably right next to the dlsyexia tag.

Re:where is the

[sexconker]

The preferred spelling is lysdexia.

Re:where is the

[salnikov]

nope, it's dylsexia

Re:where is the

[Dan9999]

when you're looking for the bathroom in the wrong place dylsexia

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

[adisakp]

Yup - which means the cost of a single SSD drive will be about 25-30% higher or $900-$1000.

I'm happy my WD Velociraptor for right now. The Velociraptor is $300 for 300GB which is still steep but it beat or matched the tested SSD's in quite a few tests.

The Velociraptor even beat the Intel SSD in several tests such as Windows Boot time (and it creamed it on anything that involved large amounts of writing / content creation since the Velociraptor gets 107MB/s write compared to 80MB/s).

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

[adisakp]

FWIW, this article recommends the Velociraptor over SSDs for gamers. The Velociraptor either beats or is close to SSD's in many benchmarks and the price per GB is at least an order of magnitude less.

Re:Well, a step in the right direction

[Ed Avis]

Well it's about $600 in bulk. I imagine the retail price will be a bit more than that. But suppose you can get one for just $600. What else could you do with the money?

You can buy 8 gigabytes of RAM for about $150 (you can even get ECC for that price if it doesn't have to be the fastest clocked RAM). So $600 would let you pimp out your server with 32 gigabytes of RAM - actually, not so much these days. I'd bet that for many applications the RAM will give a better performance increase than going to SSDs. After all, SSDs are hugely faster than rotating disks, but RAM on the motherboard is faster still. It depends whether the data you're accessing would fit in the 32 gigs of cache - if you really are seeking randomly over the whole data set, then the SSD is better.

Similar calculations apply if you were thinking of buying ten SSDs: compare them with 320 gigabytes of RAM. Except that it can be hard to find a motherboard with that many RAM slots :-(.

I'm not saying it isn't a good buy, just pointing out that RAM itself is very cheap these days, and if you view the SSD as a kind of cut-price, extra-slow memory instead of an expensive, extra-fast disk, it doesn't sound as impressive.

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

[sanosuke001]

until you go through the maximum writes on all the storage cells in a year on a busy DB.

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

[Alt_Cognito]

Make backups.

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

[sexconker]

But Cheetah's have a special claw on their front legs, used to trip animals, resulting in faster writes.

Or something?

Re:Well, a step in the right direction

[holywarrior21c]

Completely agree. I will never pay $600 or above for an $80 Gig hard drive. I will absolutely get one if it falls under $100 dollars for the SDD disk alone. I am completely happy with 30GB on my ibook and 40GB on my external 2.5 hard disk. I download everything from web and erase the files or upload them back online almost as soon as i am done using them: such as movies, pictures, documents, music files, etc. I have acceptable internet speed at home: i get about 300KB/sec when i use web browsing/itunes/torrent. that means that i can download regular movies in about less than 3 hours for popular movies and less than 15mins for an album. i am college student and work on a lot of web/software programming. but do not see the point of having large drive. quick access is biggest attraction of SSD. Finder/editors on my 4 yr old mac freezes while hard drive catches up with my demand time to time. but not to the point that i rip my ibook open and shove in new SSD right away. when i use my computer i focus on using only the software i need to use: i don't turn on VLC or itunes to listen to the music or radio when i am working on my computer. instead i use my portable mp3 player. that way i maximize my laptop's battery run time also desktop space, power resource. sure the benefit or having fast and spacious drive/computer is nice. but it doesn't worth $500 or more right now. same goes for other things as well. i play games on xbox so that i don't have to get new pc in order to play newest games.

Re:Well, a step in the right direction

[Cyberax]

One BIG problem: RAM is volatile. So you HAVE to hit the disk for every not-readonly transaction.

Re:Well, a step in the right direction

[billcopc]

FWIW, I recommend a pair of cheap ordinary SATA drives in RAID-0 for gamers. If you want mega bang for the buck, buy four 320gb drives - the total is still less than ONE Velociraptor.

Seek time isn't quite so relevant when you're reading a few gigabytes of closely-packed data, as most recent games tend to do. A properly defragged system will result in your game being stored in contiguous tracks, where the seek time is in the sub-msec range. If your heads are jumping halfway across the platter several times per second, you're doin' it wrong!

Re:Well, a step in the right direction

[Anonymous Coward]

SSDs in a database server? About a million writes and those sectors are down for the count, unless the technology has improved?

Re:Well, a step in the right direction

[RulerOf]

Why? They're almost free at 60 cents each

Intel has finally made the Beowulf cluster affordable for all of us!

Re:Well, a step in the right direction

[Anonymous Coward]

Ancient techniques such as wear levelling, if done correctly, eliminate that problem.

By remapping blocks that have a "spike" in the number of writes, you eventually spread out writes across the whole drive. Ideally you could write a single logical block (max_rewrites * total_blocks) times before running into failure.

Whether or not hard drive manufacturers use an algorithm close to ideal is another matter...

Re:Well, a step in the right direction

[adisakp]

Seek times are very important with virtual memory though and modern games are able to push the memory limits of current machines. Furthermore, the fast seek time helps with lots of other stuff like boot time. 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.

Re:Well, a step in the right direction

[kestasjk]

That's $600 for an 80GB one. I hope among the range they're selling we get a more reasonably priced ~20-30GB one.

My OS (, documents, program files, etc) doesn't use that much space and it's not even a squeeze, and you need more than 80GB anyway to store media.

As I understand the main cost are the Flash chips themselves, so a half sized disk shouldn't cost much more than $300, and 40GB is certainly enough for non-media data for an individual desktop.

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

[billcopc]

We weren't talking about safety/longevity, we were talking about raw gaming performance.

Speed, reliability, affordability: choose any two.

I'm perfectly happy running 4x Raid-0 stripes for performance-critical things. If it dies, I'll pop in a new drive and reload the data. My important files are stored on a Raid-1 pair, and the even more important stuff is backed up through various methods. For business-critical server stuff, I do RAID-10. Yes, I have to buy twice as many drives, but I get the increased throughput and the reliability bump. It's either that, or I could spend the same amount of money on a craptacular RAID-5 accelerator that will leave my drives unusable when its cheap chinese workmanship goes poof!

That said, I would never run a desktop with just a Raid-0 stripe for everything - that's suicide. It's all about risk management. I don't mind reinstalling a game or losing a few hours' worth of intermediate data files, but my home directory is golden and I treat it as such.

Re:Well, a step in the right direction

[bhtooefr]

This is an MLC, you'll have to wait a while for the SLC drive to come out... (and the SLC is supposedly going to destroy everything on write performance, which is this drive's weak point.)

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

[adisakp]

I went from a slow drive to a Velociraptor and my Vista experience went from painful to pleasantly useable :-) I totally understand your statement on the "feel" of a more responsive system. If an SSD makes as big a difference as the VRaptor did, it'd probably be worth it to power users.

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

[adisakp]

A velociraptor beating it on write speed is irrelevant

BTW, that's not true if you do lots of content creation (such as MP3/DVD ripping, recording multiple channels of streaming videos, etc) or write heavy operations (compiling large programs, cooking/batch-processing art,etc).

Re:Well, a step in the right direction

[orkysoft]

Yeah, too bad Dell had to rush things, and they are offering 4GB, 8GB, or 16GB SSDs in their new laptot. If they'd waited a bit, they could just have put one of these babies in all of them as standard. Although, 60 cents might be too expensive for a Dell!

Re:Well, a step in the right direction

[drsmithy]

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.

So use RAID1, just like you would with normal drives.

Re:Well, a step in the right direction

[adisakp]

Isn't the SLC going to be much more expensive ? Look at the price between Intel's Extreme(tm) CPU's and then mainstream ones. They're gonna put the SLC's on the Extremem(tm) brand. Plus initially the Extreme's will only be available in a 32GB and 64GB format.

I'm talking about "bang-for-the-buck" and "fast-enough" which is where the Velociraptor is hitting a sweet point. Heck, the V'Raptor is a bit $$$ for some and I'd suggest a Samsung F1 for those people.

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

[Anonymous Coward]

You should probably check out Texas Memory Systems. They sell a number of solutions to your problem.

Re:Well, a step in the right direction

[Zymergy]

I couldn't agree more... *Everyone* should actually USE an SSD in the field as your OS boot drive to really experience the difference.
These things are like Apples and Oranges (SSD vs. HDD).
I posted my experience with an SSD on my Asus Eee PC 1000H (WinXP) and in this thread: http://slashdot.org/comments.pl?sid=954031&cid=24926963

Re:Well, a step in the right direction

[Anonymous Coward]

Only 40GB of data? Why not put it in RAM with occasionaly writeback to a slower disk?

6 cheap boxes populated with 8GB each and networked gives a a total of 48G, which should hold your 40G once OS and other overhead is accounted for. Or splurge some more and buy serverboards with 32G (or can you get them with 64G these days?)

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

[darkwhite]

Just because your data volume is growing doesn't mean everyone else's is growing at the same rate. There are lots of databases that fit in 16 GB of RAM, which is pretty cheap to come by these days. Especially if you're frugal with the database design from the start. You can even stuff 64 GB in there pretty easily, and then there are all those memory NAS devices popping up left and right...

Re:Well, a step in the right direction

[moosesocks]

What if the drives realiably fail within a given period of time?

If the device craps out after a very specific amount of time or read/write cycles, it will be a *huge* problem for RAID arrays, which assume that failures are randomly distributed.

If you have a 4-disk RAID array, and all four disks fail within a day of each other, you're screwed.

I'm not saying this is likely (far from it), though I would imagine that SSDs have different rates and patterns of failure than hard drives. It'll take a few years before we know for sure how they need to be handled to achieve a sufficient level of redundancy.

Re:Well, a step in the right direction

[drsmithy]

What if the drives realiably fail within a given period of time?

If the device craps out after a very specific amount of time or read/write cycles, it will be a *huge* problem for RAID arrays, which assume that failures are randomly distributed.

I'm not saying this is likely (far from it), [...]

I think you've pretty much answered your own questions...

Re:Well, a step in the right direction

[jimdread]

Wouldn't it be better to use two drives in RAID1 (mirroring)? That will give extra read speed, since it can read from either drive. It also provides a bit less chance of losing all the data on the drives, since they are mirrored. Drives are big and cheap, so mirrors are a good idea.

It would also be interesting to mirror a solid state drive with a mechanical drive. It would cost more than two mechanical drives, but less than two solid state drives. Hopefully mirroring an SSD with a HDD would combine the faster write speed of the HDD and the faster read speed of the SSD. It's a nice dream anyway, and I'm going to try it out once I get some SSDs.

Re:Well, a step in the right direction

[MrNaz]

Hey! Who gave mod points to the Verizon employees?!

Re:Well, a step in the right direction

[AllynM]

Say you were ripping 2 DVD's in parallel at max drive speed, and had 2x DV camcorders connected and ripping from those as well. You will still only be ripping at a fraction of what the MLC SSD is capable of.

If you were doing that same thing on a HDD, you would get nowhere near max throughput as the heads would be seeking across 4 different file writes constantly. A velociraptor could likely handle that sort of load but you would be treading the line.

Any sort of heavy read at that time would thrash the crap out of the HDD, slowing writes significantly, and no doubt dropping frames on the DV streams, while the SSD would just laugh and carry along with no issue. The SSD does not have to seek all over the place, so you get closer to the throughput figures regardless of how many parallel streams are being written to the device (to a point obviously, but it would still smoke the HDD).

Re:Well, a step in the right direction

[chriso11]

I figure at $600, they should compare to a raid0 of Velicoraptor drives. Suddenly the advantages of SSD start to fade...

Re:Well, a step in the right direction

[Anonymous Coward]

There are commercially available products that do exactly what you want: provide a large, very fast drive backed by RAM or Flash.

I seem to remember that one of those is at the core of the MMO game "EVE Online" - hosting the database for 35,000 concurrent players.

The only drawback is the price - I think you're looking at $25,000 for an entry-level solution.

Re:Well, a step in the right direction

[rainhill]

Get an AppEngine account..

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

[ArsonSmith]

the 10,000 writes is a conservative estimate by most realword tests. It's not like 10,001 and the drive dies.

Re:Well, a step in the right direction

[moosesocks]

Well, no. What I'm saying is that the standard deviation of the failure rate could be a lot smaller than it would be for a normal disk. We still know very little about their modes and patterns of failure.

Again, it's probably nothing to worry about, but I'm not entirely convinced that RAIDing SSDs is the best way to achieve redundancy, considering that a lot of assumptions are made when stating the benefits of a RAID setup that don't apply to SSDs.

For instance, what is the likelihood of a SSD going entirely tits-up? Are those odds less than the odds of the RAID controller itself going berserk?

I imagine that SSD failures will be characterized by a gradual increase in the number of bad blocks on the device, rather than a single catastrophic failure as we typically see in hard disks. Perhaps we'll see SSDs with built-in redundancy, or simply a more advanced form of RAID that can cope with and compensate for these sorts of failures.

Still.... you never know. You may very well encounter a certain batch of SSDs that self-destruct on their 10,001th write. Until we have a good grasp on how these things operate on a large scale in the real world, it's too early to be making any assumptions (and way too early to be using them in mission-critical applications)

Re:Well, a step in the right direction

[Spoke]

Typically, it's not reads that are the performance limitation, but writes, since as you say, you can often throw more memory and/or selective caching to avoid read bottlenecks.

You can only write as fast as your disk can seek, unless you are able to batch small writes into larger ones (typically with the help of a RAID controller with battery backed RAM).

Re:Well, a step in the right direction

[Ed Avis]

Yes you must write everything to disk as you write it. I was kind of assuming a mostly-read data warehousing or website kind of application. However, in principle the DBMS or filesystem can record changes as a journal, which is fast to write because it's all in one place so you pretty much get the disk's raw throughput. During less busy times the journal data can be moved to its final position on disk. Eg with ext3 data=journal you can get a speedup under some loads, although ext3 is not really designed for such usage. I don't know whether the heavyweight database engines have provision to do this - I am just speculating.

Re:Well, a step in the right direction

[tempest69]

nope, wasn't serious.. but the sibling posted as I was typing...

sometimes sarcasm doesnt traverse the posts at full effect.

Re:Well, a step in the right direction

[anarxia]

Just get a controller with battery-backed RAM (the more the better). Your system will be cheaper, more reliable, and only slightly slower.

Re:Well, a step in the right direction

[Anonymous Coward]

4X drives in RAID-0 means you have four times the chance of having a dead weight for a system.

It means you have 1-P^4 chance of having dead weight for a system, when P is probability of a single drive not failing.

Re:Well, a step in the right direction

[deroby]

If the database is 'only' 40GB, wouldn't it be cheaper to put more RAM into the machine ?? I'm not sure how the data is organized off course, but 32Gb should be able to get the cache-hit ratio in the +99% region, and cache still being faster than SSD imho, making up for the sub 1% cache-misses.

** some looking around for ram-prices later : damned, ram is expensive... makes these drives look cheap =(

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?

Re:Well, a step in the right direction

[cyb97]

Then do a cost vs. benefit analysis on having to replace the drives constantly compared to the extra benefits (extra customers served, etc.).

If it is acceptable to replace drives constantly, make sure you stagger the use of them so that when the first pair fails the second pair (or what ever configuration you have) has 50% lifespan left.

And so the circle repeats...

Of course it might be cheaper to throw more disks at your array, or create a slave to share the load of the original system. Depends on what your service is worth in terms of money.

It's all down to right tool for the right job, as always.

Re:Well, a step in the right direction

[Anonymous Coward]

Sounds like maybe it is time to implement memcached on your sever.

Re:Well, a step in the right direction

[Pharmboy]

Still means you might have failures somewhat clustered. I would opt for an option that used a RAID 1 and a traditional hard drive, with slower sync times, for reliability and price. Still gives you insanely fast reads, still gives you faster writes to the primary drive It is just slower for the mechanical to catchup, which doesn't affect actual performance since that is done on the raid card, not the system. Since most boxen are no 100% busy all the time (and should be expanded if they are) this would work to add redundancy at a lower price point.

Re:Well, a step in the right direction

[Vigile]

Another non-slashdotted look can be found here:

http://www.pcper.com/article.php?aid=616&type=expert

Re:Well, a step in the right direction

[drsmithy]

Still means you might have failures somewhat clustered.

No, it doesn't. There's nothing to suggest failures would be any more "clustered" than they would be for a traditional disk RAID.

I would opt for an option that used a RAID 1 and a traditional hard drive, with slower sync times, for reliability and price. Still gives you insanely fast reads, still gives you faster writes to the primary drive It is just slower for the mechanical to catchup, which doesn't affect actual performance since that is done on the raid card, not the system.

It will most certainly affect "actual performance", unless your entire dataset fits within the cache on your RAID controller.

Re:Well, a step in the right direction

[Anonymous Coward]

Talking about 10K write cycles is just stupid, since this drive, like every other SSD, uses wear leveling. Of course Intel says their wear leveling is 3x better than everyone. It's right there if you RTFA.

Re:Well, a step in the right direction

[Anonymous Coward]

FTA:
"Actual drive lifespans aside, Intel rates the X25-M's Mean Time Between Failures (MTBF) at 1.2 million hours. That's competitive with the MTBF rating of other MLC-based flash drives and equivalent to common MTBF ratings for enterprise-class mechanical hard drives."

Re:Well, a step in the right direction

[lewiscr]

MP3/DVD ripping is a poor "big write operation". Even at 8x DVD speed (which I only get for a small percentage of the disk), it's writing at 10 MBps. And that's only if you rip the ISO to HDD, then re-compress. If you re-compress on the fly, it's less. These slower-than-your-disk sequential writes will be stuttering the drive head, at a rate that depends on how much your OS will buffer before writing a chunk at full speed. The SSD should handle this stuttering better than a HDD.

It's different if the rip reads from DVD, writes uncompressed to the HDD, then in a 2nd thread/process reads from HDD, compresses, and writes to HDD. Now you're talking in the neighborhood of 30 MBps... except you can't get that on a HDD because of the seeking between the write, read, and write location.

For large compiles... you're not maxing your disk I/O, you're maxing your disk IO Ops. SSD had many more IOps than HDD, so this will be faster.

Now, recording multiple channels of streaming video, maybe. If you're recording the compressed streams, and then it's not that high of MBps. If you're streaming raw HD, then no single disk is going to handle it anyway.

Here's the cool thing about I/O in general. 70 MBps is a *huge* amount of data. You can copy that 9GB DVD image in about 2 minutes. When's the last time you've ever seen any real life I/O operation go that fast? The best I've managed to pull off is about 32 MBps sustained, because I was scp'ing something from one computer to another, and I saturated the GigE link (no jumbo packets). Well, I've gotten better, but most people don't have $250k fiber channel disk arrays to play with. And even then, it wasn't a whole lot better.

Disclaimer: I'm not talking about those crap-ass first-gen SSD drives; those drives that get beat by a 100 MB IDE drive on an ISA card. I'm talking about real SSD drives, and it looks like Intel just released the first one.

Re:Well, a step in the right direction

[Anonymous Coward]

These slower-than-your-disk sequential writes will be stuttering the drive head, at a rate that depends on how much your OS will buffer before writing a chunk at full speed. The SSD should handle this stuttering better than a HDD.

You're inventing a problem which doesn't exist. HDDs do not have to stutter their heads to write at slower rates.

Say the HDD has just finished writing sector N when a command to write N+1 arrives. Unfortunately, the host computer is writing slower than the disk can write, and the command to write N+1 doesn't arrive until that sector is already passing underneath the head. What does the disk need to do? It certainly doesn't need to stutter anything. It just needs to wait slightly less than 1 full rotation of the disk, keeping the head fixed on the same track, and sector N+1 will come around again.

Now, if the HDD had very little buffer memory, you could run into performance problems where the HDD can't queue up enough pending writes to smoothly accommodate all possible sequential write rates. But it's been something like 15+ years since there were HDDs on the market which had less than a full track's worth of buffer onboard. Modern HDDs have caches much much larger than a single track, as big as 16 or 32 MB in some cases. As long as it can buffer at least 1 full track's worth of writes, a disk is able to deal with any conceivable host behavior with the best possible efficiency.

It's different if the rip reads from DVD, writes uncompressed to the HDD, then in a 2nd thread/process reads from HDD, compresses, and writes to HDD. Now you're talking in the neighborhood of 30 MBps... except you can't get that on a HDD because of the seeking between the write, read, and write location.

You'd be surprised at how much sustained throughput some drives can keep up in that scenario, provided that they have high seek performance and the system has enough buffering and command reorder capability to allow moderately large sequential reads/writes between seeks. I have tested 10K and 15K RPM SCSI drives which could maintain ~90% of their nominal sustained transfer rate when loaded with 2-3 sequential read/write streams.

These days, even some standard cheap SATA drives may be capable of pulling such tricks off, since command queueing and reordering is finally a standard feature of the commodity HDD interface. (Queueing used to be limited to just SCSI drives; parallel ATA also theoretically had some queueing capability late in its life but in practice it wasn't very good and didn't ship on many devices or controllers.)

Re:Well, a step in the right direction

[billcopc]

The big problem with mirroring is you still need a smart controller to handle the load balancing. Cheap junk like Promise/Highpoint cards don't do that, many of them read from just one drive (and good luck rebuilding after a failure).

Intel's fakeraid is actually pretty decent in this area, as long as you don't do that stupid "matrix raid" nonsense where you stripe part of a drive, then mirror the other, or even dumber is to mirror one half of a drive to the other half :P But if you use whole drives, the performance is quite amazing for "free" raid.

Re:Well, a step in the right direction

[Nefarious Wheel]

Well, as it turns out it did. Frequently in fact -- these old disk packs were not what you'd call reliable. But people bought multi-platter disks anyway. It simply changed the granularity of what constituted the minimum backup set.

RAID 0 does the same thing -- multiple spindles bound together in a stripe set is functionally the same as multiple platters bound together in a disk pack, both in granularity of the volume set as a unit, parallelism (disk packs) or near-parallelism (stripe sets) and the fail-one, fail-all vulnerability. The two systems are topologically conformant.

And people buy RAID stacks as a separate unit, today, in the form of 1RU and 2RU server blades with pre-packaged RAID stacks in the same, single box as the computer. If one component dies, you may just replace the entire unit.

The more things change, the more they stay the same...

Re:Well, a step in the right direction

[blair1q]

Just to remind those of us who were there:

Those multiple-platter sets usually spread the bytes across the platters. One or two bits per platter from each byte.

So yes, if one platter or a head on one platter became non-functional, you didn't just lose 1/Nth of your files, you lost a portion of every byte, including all the volume and directory structures.

Poof.

Tape backup systems have always sold well, until the robust forms of RAID were developed, because the best backup is an actual backup.

Re:Well, a step in the right direction

[jZnat]

I'd assume that a person using four drives in RAID would use something like RAID 5 instead of living dangerously in a RAID 0 environment with several disks.

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

[jabuzz]

Funny it improves the speed on my DS4400's DSs4500's and DS4800's....

Re:but is it fast enough

[larry bagina]

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

Re:but is it fast enough

[drsmithy]

RAID doesn't improve speed, at least not by a large amount. RAID will save you time if a drive died and you can get your data back quicker. As for normal performance speed you are just as good with 1 drive.

Uh.... What ?

Re:but is it fast enough

[Anonymous Coward]

You'd better stop giving advice on the things that you don't know.

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

[Anonymous Coward]

You're an idiot. Look up Raid 0.

Re:but is it fast enough

[smitty97]

Im sure they have properly optimiz^H^H^H^H^H^H crippled versions to use with Vista.

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.

Re:but is it fast enough

[Just Some Guy]

RAID is an acronym for Redundant Array of Inexpensive Disks. There is no Redundant part in aid 0.

Yes, and "hacker" means "enthusiastic computer explorer". Really, give up. RAID 0 is still recognized as RAID, regardless of what the "R" should mean, by everyone.

Re:but is it fast enough

[riceboy50]

Well, AJAX stands for Asynchronous JavaScript and XML (which is itself an acronym!), but everyone uses it generically to refer to all asynchronous server communication between page loads using JavaScript, regardless of whether any XML is involved.

The point is, most people don't know or care what an acronym means anymore and it just becomes a term unto itself such as RADAR and PATRIOT Act.

Re:but is it fast enough

[Anonymous Coward]

use
[Redundant]*

not

[Redundant]+

Re:but is it fast enough

[Myrddin Wyllt]

Not being American, I didn't realise PATRIOT (as in Act) was an acronym - yuck, forced or what?

I had to resort to AcronymFinder, and one of the alternatives (presumably referring to the SAM) was 'Phased Array Tracking Radar Intercept On Target', which kind of re-enforces your point.

Re:but is it fast enough

[sexconker]

/prefetch:1

I remember that being a "HOT NEW TWEAK" back in the early days of XP.

Re:but is it fast enough

[Glonoinha]

You're new here, aren't you?

Re:but is it fast enough

[Anonymous Coward]

RAID array? Are you talking RAID1+0, 0+1? Or are you trying to say RAID 5 and you really don't know what RAID stands for?

Re:but is it fast enough

[billcopc]

It's nothing that couldn't be done with "copy myapp.exe nul:" under XP, or even DOS for that matter.

As a matter of fact, I wrote a quick precaching script in Perl a while back, that I use extensively for thrash-heavy jobs like compression/decompression and some games. I wish those apps would just learn to make use of my Ram, but obviously the concept of efficiency died out, right around the same time Windows 95 was released.

Re:but is it fast enough

[drsmithy]

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.

You get exactly the same (relative) performance and reliability benefit from RAIDing SSDs as you do from RAIDing regular drives.

Re:but is it fast enough

[Anonymous Coward]

RAID doesn't improve speed, at least not by a large amount. RAID will save you time if a drive died and you can get your data back quicker. As for normal performance speed you are just as good with 1 drive.

Uh.... What ?

I think what he's referring to the fact that RAID 0 setups don't really improve speed for normal, everyday desktop/gaming usage. However, in environments that have heavy I/O usage (such as webservers or databases), they can be a godsend ;though, RAID 0+1 or 5/6/10 are MUCH better options for these tasks.

Re:but is it fast enough

[Z34107]

RAID is an acronym for Redundant Array of Inexpensive Disks. There is no Redundant part in aid 0. You can ofcourse have multiple aid 0s in mirrored configuration so you have raid instead of aids.

Anyone else find it ironic that this post got modded -1, Redundant?

Besides, the "Redundant" part in RAID 0 comes from the repeated attempts to explain why it's not redundant at all. And, therefore, "bad."

Re:but is it fast enough

[Anonymous Coward]

Regardless of the RAID type, it should speed up reads. In a mirror, the IO scheduler can read alternating sectors from the drives to achieve a 2x theoretical speed increase. Stripe arrays force this, but there's no reason why you can't do it with an SSD on a mirror given that there's no requirement that you read sequentially for optimal speed.

Re:but is it fast enough

[Anonymous Coward]

I thought MS parallized my I/O?

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

Re:More details and Benchmarks here

[Anonymous Coward]

pcmark/3dmark != real world. ever.
sisoft alu/fpu benchmarks either, for that matter..

Re:More Details and Benchmarks Here

[Tracking System]

Thanks! This is more informative with all the specs.

Re:More Details and Benchmarks Here

[Anonymous Coward]

holy jebus!

That thing can read the ENTIRE drive in under 7 mins 30 sec!

7.4 = 80GB/(180MB/s)/60

Re:More Details and Benchmarks Here

[kestasjk]

The fact that so many algorithms take into account disk based storage, and attempt to serialize reads and writes, I don't think the benchmarks (which are close in most cases between SSDs and HDDs) reflect the potential gains of SSDs.

Re:More Details and Benchmarks Here

[billcopc]

So will a pair of standard 7200rpm drives in RAID-0, that will cost you 1/10th the price of this one SSD.

SSDs excel at random seeking, not sustained throughput, though for most common uses the same performance benefit can be obtained by adding Ram for the system to use as a disk cache. Linux and Windows are both pretty good at this.

Damn it intel

[sakdoctor]

You were only supposed to blow the bloody doors off!

Re:Damn it intel

[Chemisor]

Do you think I overreacted, Hal?

Re:Damn it intel

[Hal_Porter]

IOPS. Thousands of them.

Re:Damn it intel

[grey3]

Oh, good plan this, probably! Their best laid plan, I believe...

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

[Facegarden]

Yeah, i have 3TB of HDD's on my desktop. Someone let me know when they make 3TB SSD's that i can afford. :)
-Taylor

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

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

[blankinthefill]

I just filled a 150 gig velociraptor with OS/programs. I may be a little out of the ordinary, but programs, especially games, are starting to stack up space wise. I have a few that top the 10gb mark, and at least one that tops 20. When you're eating space like that, the SSD sizes that are coming out right now just don't cut it. (I know, I know, I could just uninstall some stuff... but I like having all of them on hand in case I get a bug at 2 in the morning and have to play THIS GAME! :) )

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

[PitaBred]

Seconded.

What gets really interesting is if you start thinking about these access times and such on your swap partition/file/drive/whatever. It's a hell of a lot less expensive than a ton of extra RAM, but still performs quite well, especially in random access. 80GB of an Intel SSD is still a lot cheaper than the equivalent amount of RAM, too.

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

[MooseMuffin]

I have a 74gb raptor, split into two 36gb halves (xp/ubuntu) and I get by on that as my OS drive. Seems enough for any programs I use plus 4 current-ish (wow, oblivion, cod4, civ4, plus any expansions for each) games. Its a little restrictive but I really don't regularly play 4 games anyway so I'm fine with tossing one for spore or whatever comes next. Admittedly, if I didn't have a 360 and did all my gaming on the PC, this probably wouldn't be sufficient.

This isn't to say you're doing it wrong or anything, just presenting the opposite scenario. A 160gb drive would be fine for me for the next 5 years.

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

[diamondsw]

Actually, it is the speed - the write speed. Most SSD's on the market right now have extremely slow write speeds, to the point that it can make running an OS off them quite painful.

First get performance to parity with hard drives on write (they already kill them on reads due to lack of seek times), and then start ramping up the capacity. I expect we'll see both of these well underway by the end of next year. 200GB SSD, anyone?

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

[Anonymous Coward]

Just wait. There are 250GB SSD's already roughly at the price of this 80GB thingy.

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

[JCSoRocks]

Yeah, i have 3TB of HDD's on my desktop. Someone let me know when they make 3TB SSD's that i can afford.

Yeah, but you don't really need all of that to be on SSD. I'm up to about 3.5 TB of storage between my home server and my PC. about 300 GB of that is on Raptors... and that's plenty. It's got my OS and apps / games that I want to be fast and my photoshop scratch files. Pictures, music, other crap... that can all just sit on my slower 1 TB drives. I'd treat an SSD the same way - fast, expensive storage for stuff that I want to be fast.

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

[mosch]

That's the basic idea behind things like ZFS/Flash which will layer flash storage in along with traditional rotating storage.

You can do it now with some high-end SANs, but soon it'll be workable for people on more meager budgets as well. Quite exciting, really. Storage capacity has been going great for a long time, but access speeds haven't been nearly as impressive.

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

[billcopc]

It's not so much that we've been lagging at the terabyte, it's that the increments are getting bigger. Platter differences aside, the increment is usually 33% or more.

40gb, 60gb, 80gb, 120gb, 160gb, 200gb, 250gb, 320gb, 400gb, 500gb, 750gb, 1000gb, and soon we'll have 1500gb drives.

Once in a while, some idiot will release a smaller drive as an in-between step, as was the case with 60gb and 640gb: 750gb drives were overpriced, so they took 320gb drives and doubled the platters for a cheap (and slow) alternative.

There would be little point in releasing, say, an 1.1tb drive. It will only cannibalize sales of the 1.0tb model. You have to consider the fact that the industry is used to a few specific price points. The 1.0tb drive currently goes for $150-160, so you couldn't realistically charge $260 for a 1.1tb drive, even if it is the biggest drive available. We've also reached the point where the average consumer doesn't need nor want such a large drive, so there is much less pressure to bring products to market as quickly as in the past.

It is more efficient (and marketable) to concentrate on a significant step up. I believe Seagate has roadmapped the 1.5tb for Q1 2009, with 2.0tb coming later in the year. Two terabytes! Imagine all the pr0^H^H^Hrips^H^H^H^Hlinux isos you could put on there.

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

[Firethorn]

It's not so much that we've been lagging at the terabyte, it's that the increments are getting bigger. Platter differences aside, the increment is usually 33% or more.

It's also taking longer. The 1 - 1.5 increment has taken longer than the 1GB - 2GB - 4 GB flash drive jumps took.

Yes, it's going to take a while for flash to catch up. On the other hand, especially if Microsoft can actually contain it's bloat, in about 5 years flash based laptops will dominate platter versions.

If flash doubles every year and HD's gain 50%, It'll be ~9 years before 'state of the art' has SSDs pass HD's. Especially since HD price for 'state of the art' seems to stay pretty steady, while SSD prices are decreasing about 10% for the 'sweet spot' capacity each year.

I also figure that SSD density increases will accelerate when it takes over for laptop hard drives, then again when it starts taking over the server market. Meanwhile HD development will slow as markets for the SSDs increase.

Once you can get a 200GB SSD for ~$100, I figure it'll see a big growth - at that point it'll serve the non-videophile non-techie market quite well. $40 for the OEM market, I'd say 80GB today, but let's call it 160 GB at that future point of time. I'd say 4-5 years.

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

[Courageous]

End of 2010 at the very latest, and all 15K type drives are completely doomed. Go do a calculation on the rate of price change, purely on a $/GB basis, between flash and enterprise drives, take the current price points, and see when they intersect.

This is without taking into account the phenomenal pace at which flash is increasing in performance. For a glimpse of things to come, look here:

http://www.fusionio.com/

700MB/s sustained read, 600MB/s sustained write.

C//

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

[elh_inny]

I bought Seagate's 1.5TB last week, can you google?

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

[Just Some Guy]

Figure on a doubling each year, that'd be 3 years before the SSD exceeds current models.

In all fairness, HDDs are growing, too. Anyone got the (approximate) Moore's Law for SSD and HDD and know where the lines cross?

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

[yellowalienbaby]

It's already out there. EMC Symmetrix DMX Arrays.

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

[Anonymous Coward]

Nope, it doesn't have plenty of speed. The 70MB/s write speed figure doesn't mean it can write anything at 70MB/s, it's the speed for streaming huge amounts of data to the disk, when you're writing block-sized chunks. If you do tons of tiny writes all over the place (you know, updating a database, copying lots of small files, ...), because you have to erase 128kB blocks on updates. I didn't see any useful information (i.e. IOPS values) on this aspect for this SSD yet. The X25-E looks good in this respect, but it won't come cheap. OCZ Core Series V2, which has even more impressive claimed write speed of 90MB/s can drop down to 10MB/s for all-over-the-place writes :(

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

[Firethorn]

Right now I'm looking at 50% annual increase for HD's, and 100% increase for SSD.

SSDs are a bit odd in that they should be nearly infinitly chainable in a device, while a hard drive is a much more discrete unit. So I'm looking more at 'What's the total capacity based on the size and number of chips manufacturers are willing to put in a SSD for the best $ per GB?'. Going by pure $ per GB, SSDs are doing better than 100% improvement a year.

Going by that, it'll be around 9 years. I figure HD development will stall before that, as SSDs take over the laptop and high speed database server market much sooner, 3-5 years.

I figure about 4 years until we start looking at putting ~80GB SSDs in baseline computers for under $40, still plenty for a windows/office install*, your favorite linux distro, or whatever. Occasional use programs and AV media will be stored on terabyte sized spinning platter hard drives.

*Yes, as long as they keep the bloat halfway under control.

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

[Firethorn]

If it's anything like these systems, they still use spinning platter disk drives.

I'm talking about when you start seeing a significant percentage of datacenters choosing to go with flash storage for at least some of their systems.

Signficant percentage would be 5-10%, with more extensive installs giving more weight to 'significant'. Only OSes and programs would count less than terabytes of database, for example.

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

[billcopc]

It's listed at many suppliers but nobody has received stock yet... at least nobody I know.

Nice, now maybe Vista will be snappy

[einer]

These things cut latency by 2 orders of magnitude. Defrags are no longer necessary. 250MB/s damn near saturates the newest SATA gear.

Write/Read speed parity would be nice.

Re:Nice, now maybe Vista will be snappy

[Glonoinha]

250MB/s saturates a single SATA channel, but it's not the peak throughput. I read a few weeks ago about a guy that RAID'ed six iRAM's together (it wasn't pretty - took a second motherboard and wires were everywhere) and the 24G of space he had (or whatever it was) blasted through the 600MB/s mark and scared the hell out of the 700MB/s mark.

Based on what I read, and of that what I can still recall. Not exactly a scalable solution, but it shows what's possible.

Re:Nice, now maybe Vista will be snappy

[Frools]

Only 700MB/s? Battleship Mtron hit 800MB/s sustained and nearly 1200MB/s burst and that was with SSDs that are now 9 months old.
I'd love to see what could be accomplished with the new Intel SLC SSD's

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

[KokorHekkus]

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

Also, what would the defrag speeds be?

SSD don't have seek times so all blocks have the same access times which means that fragmentation isn't an issue.

Re:One test they never run - FRAGMENTATION

[Anonymous Coward]

Although NAND based flash does not provide random-access like NOR flash drives, with that low of an access time, the need for defragmantation probably won't be there. They have wear-leveling algorithms that distribute data. I am no expert, but a file that filesystem thinks is not fragmented, might actually be fragmented already due to wear-leveling algorithm inside the SSD.

Re:One test they never run - FRAGMENTATION

[Duncan Blackthorne]

Flash File Systems (FFSs) use a wear-balancing algorithm to spread write-cycles out over the entire available drive, thus minimizing failure of individual blocks that would otherwise turn the drive as a whole into a brick. You specifically do not defragment flash drives because of this; all the defrag process accomplishes is to use up write cycles, because there is no seek delay and no rotational delay, which is what makes a fragmented filesystem slower than one where all the files in it are contiguous.

Re:One test they never run - FRAGMENTATION

[Intron]

Who says SSD don't have sectors? Erase blocks are around 128K or larger. Pages to write are 2K typical.

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

[Anonymous Coward]

Uh-oh

Another muppet that defragments his ipod Nano and USB memory stick, then tells everyone how much faster they are now...

Re:One test they never run - FRAGMENTATION

[Anonymous Coward]

Fragmentation is an issue for SSDs too, because Flash writes in much bigger chunks than the usual file system block sizes. Depending on the wear leveling algorithm and caching of consecutive accesses, a non-fragmented SSD needs fewer physical write accesses than a heavily fragmented disk. Fragmentation on a SSD causes both lower performance and lower life expectancy. Unlike spinning disk drives, a SSD can work around that problem internally, because there is no seek latency, so reordering blocks internally is "free".

Re:One test they never run - FRAGMENTATION

[sam0737]

Yes. Imagine the files are tightly packed, and if you try to growth the files in the middle...the file will get fragmented.

I am pretty sure that The SSD is not read byte by byte, but chunk by chunk, like 4KB per read request, instead of reading one by one. So if files get fragmented, and needs extra read to get the file read, there are always overhead and waste.

In short, we still need to defrag SSD-

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

[adisakp]

BTW, the Blitter analogy isn't so good because today's hardware often has scatter/gather technology for fetching reads where it can combine many smaller blocks into a what appears to be a larger single virtual block for the read.

Even tech without this will usually allow lists or queued fetching to hide the overhead of many little fetches.

The important thing is to have the subblock size to be at least large enough that the time penalty for switching native blocks is minimal compared to the actual time of reading the subblock.

Re:One test they never run - FRAGMENTATION

[Anonymous Coward]

Note that the hardware already does wear leveling so you can use normal filesystems, so this blitting (or anti-blitting - caching and coalescing) is already done for you. "Defragmenting" the filesystem to create contiguous blocks won't help physical access time much.

Where it might still help you is with command overhead, which is apparently significant when dealing with storage of this speed. But of course, most modern FSes do everything they can to avoid fragmentation anyway, until the disk fills up.

Re:One test they never run - FRAGMENTATION

[antdude]

So do those RAM defraggers even work? Or do they not help?

Re:One test they never run - FRAGMENTATION

[Anonymous Coward]

Fragmentation is based on how far apart on the disk the blocks of a file are from each other. Each block is by definition one continuous stream on the disk. When reading a file if the head has to move to another part of the disk to get the next block the file is fragmented which is what adds latency.
However the OS only retrieves one block at a time from the disk drive and it may require multiple requests to the drive to pull one block if the block size is large enough.

As long as the block size is larger than the word size (or maximum chunk request size) of data stored in the flash drive fragmentation is irrelevant. You can almost be guaranteed that the design of an SSD is such that the minimum access size is the same as the typical OS minimum block size (512 bytes).

Memory fragmentation is relevant when accessing data in RAM in an order such that between accesses you have a cache miss. This is most obvious when accessing an array out of order. These are two completely different issues.

Re:One test they never run - FRAGMENTATION

[chill]

I have no idea if the products work. RAM does get fragmented, but nothing a quick reboot won't fix. Hard drives need explicit defragmenting, but that scares me with RAM. I don't want Program A trying to move crap around in memory. Actually, I can't even see *how* they work, moving other program's data around. If program B expects to find a data block at $C000, it better be there and not bounced around by some defrag program.

I personally wouldn't waste my time on them.

Re:One test they never run - FRAGMENTATION

[arth1]

There's only one benefit you can have from defragmenting a solid state disk -- you free up space.

On a heavily fragmented drive, the information on how to jump all over the disk to read the file has to be stored somewhere. Depending on the file system, it can either be in a block allocation map or file allocation table (BAM or FAT), which grows quicker the more fragmented the disk gets, or in continuation blocks (extents), where the end of a file block tells the file system "jump to sector NNNNN block MMMM" for the next chunk of data.
In either case, defragmenting can clean up some of that excess use, and free up space.

In addition, some file systems allow for fractions of blocks to be used, so multiple tiny files can go in one block, or the leftover end of a file after full 4k/16k chunks have been stored can be stored with the leftovers from another file (or five). Intelligent defragmenters can fit pieces of the puzzle more efficiently together, saving an additional tiny bit of space.

All in all, the space savings aren't huge -- a percentage or two. The most I've seen was around 5% on a seriously badly fragmented drive. And on an SSD, the cost of wear doing the defragmentation might be far higher than the small benefit in freeing up space.

Re:One test they never run - FRAGMENTATION

[ACMENEWSLLC]

You really don't need to defrag your SSD / USB flash drives. Just as there are defrag utilities for your hard drives, there are defrag utilities for your RAM in your PC. Last time I ran one of those was perhaps 10 years ago. Do a Google search for RAM Defrag and you will find these. The time's I've done it with RAM where to clean up after programs with memory leaks, not for the real defrag use.

The fact is in very few cases do you ever want to do this. The benefits just are not there to justify an early end of life for the drive. Most flash drives don't really store the data where you think they do anyway. They use logic to spread read/writes across the drive to prevent wear. http://www.truecrypt.org/docs/?s=wear-leveling

I have a 16GB flash drive I run VMWare guests on. I don't see any speed difference if the VMDK file is severely fragmented, or completely defragged. There may be rare exceptions to this, but don't defrag your flash drives / SSD's.

Re:One test they never run - FRAGMENTATION

[PitaBred]

Generally not. What a RAM defragger does, all it CAN do, is request a metric fuckton (not imperial... people often get those confused) of memory, which shoves almost everything currently running into swap, and then it releases it, so hopefully the OS reads the pages back from the swap in larger cohesive blocks.

In short, no, there's no reason for it. If there was, it'd be recommended for use on memory-hungry server applications in the enterprise, and I have never seen that. Operating systems have improved a lot since Windows98, which was really the last time you might want to actually use one of those, since they didn't really have any actual control over the application memory allocations and such.

Re:One test they never run - FRAGMENTATION

[mikael]

That's a pity.

Most file systems store files using a multi-way tree format. Each block stores a particular amount data and contains links to the next sets of data blocks. This way, if you write a small block of data to the start of a file (at offset 0), and at some far distant point (+maxint = 2 gigabytes), the file system will only store those two blocks plus the hierarchy to find those blocks, and not the whole 2 gigabytes.

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?

Re:One test they never run - FRAGMENTATION

[Anonymous Coward]

Not at all, since each allocated memory block is contiguous unlike fragmented files in file systems. The only thing that can get fragmented is the free disk space caused by many allocations with different block sizes. Also this is just an address space fragmentation since everything is else is handled by virtual memory in systems nowadays.

Re:One test they never run - FRAGMENTATION

[chill]

I wasn't misinformed, I was sloppy.

Hard drives == file systems as far as the everyday person is concerned. I am fully aware of the benefits of XFS's pre-block allocation and things like packed tails (ReiserFS). File defragmentation has a noticeable benefit on Windows machines formatted as either FAT-32 or NTFS. Disk access can be greatly sped up on defragmented volumes. I would not recommend defragmenting a Linux/Unix system at all. Anyone who searches for "Linux disk defragmentation" is going to find more posts basically saying "you'd don't need to do this" than defrag programs.

I was assuming workstations or PCs, where a weekly reboot is something I still recommend to people. Standby mode is great, but reboots are still necessary in the Windows world. There are too many little memory leaks and other issues that are too easily fixed by a "shut it down on Friday before you go home" mentality. Servers are another ballgame totally. People running servers shouldn't be taking random posts on /. as gospel without further research.

Yes, RAM defragmenters are a waste of time. I'd go as far as say "scam", but can't prove it so I didn't. Keep in mind, back in the days of the C-64 and floppy disks you could create SERIAL files and RANDOM files. Just because the disk could be accessed randomly didn't make any two blocks equal in access time. Contiguous is faster because it can be done in one fetch operation. Are you claiming that two commands to get two non-contiguous blocks of memory are as fast as one command to read a single contiguous block? How about 100 to 1? If so, please feel free to provide me with a detailed explanation as I am genuinely curious. But, I'll agree, that for most operations, memory fragmentation is a non-issue. We're talking theoretical here, or at least "not going to affect your home PC or office workstation".

Uptime clocks are wanking material. Scheduled maintenance requires periodic downtime unless you're in the 1% of the population running totally redundant hardware. And while I can't find the link at the moment, I've seen recent studies that say the entire "it is better to leave the machine powered on than reboot" are myths. Take in the entire equation -- in larger organizations it is cheaper in cooling costs and electricity to shut down workstations over weekends and holidays, and rebooting isn't that bad. Heh, it is even LITERALLY "cool".

Re:One test they never run - FRAGMENTATION

[anss123]

As for RAM fragmentation, it's such a non-issue that it's worth explaining.

Actually, back in the day RAM fragmentation was an issue. On the Amiga, for instance, if your memory was fragmented you might not have enough continuous memory to run an application - even if you had enough free memory.

Modern systems are fitted with Memory Management Units that solve most of these problems, but memory fragmentation can still result in performance issues in cornerstone cases.

Re:One test they never run - FRAGMENTATION

[atamido]

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

This is actually a problem. I have two SSDs here that use 64KB blocks internally. Most operating systems don't give you the option to select cluster size while formatting for install. Vista won't even boot on an NTFS partition that doesn't have 4KB clusters. And while the drive is faster when formatted using 64KB clusters, you end up with a lot of wasted space if you are using largely small files.

Re:One test they never run - FRAGMENTATION

[adisakp]

Yes. If the native block size is not similar to the OS cluster size you have significant "write amplification" on drives without write combining of subblocks. For example, with a 4K OS block and 64K SSD block, you can have a 16X write amplification in the worst case.

However, if you do write combining of subblocks with wear leveling as I described in my naive CS101 approach, you could have a 4K OS block with 64K native SSD blocks and the SSD will do writecombining with a 4K subblock size and separated journaling for the subblock. The result is write amplification that was very close to 1X (rather than 16X). This is how I think Intel is getting away with the claim of 1.04-1.10X write amplification.

Re:One test they never run - FRAGMENTATION

[adisakp]

Basically, the theoretical write combining will take 16 (SSD_blocksize/OS_blocksize) writes of 4K (OS_blocksize) each and make them into a single 64K (SSD_blocksize) write of the native SSD block size regardless of the virtual location of the OS FS writes, they will be physically adjancent in the memory on the SSD and within a single SSD native block.

The journaling will record this write combining and the drive will remap blocks dynamically.

High end enterprise SSD's with write combining and more sophisticated wear leveling did this already. Unfortunately, most consumer drives (including the ones you bought) do not do this. Intel is bringing this feature to consumer level drives and one of the side effects is they're able to get higher performance from the writes (especially for MLC flash) and to get a longer lifetime for the device by reducing the write amplification.

Re:One test they never run - FRAGMENTATION

[Tumbleweed]

If you're old enough, think back to the Blitter on the Amiga

Oh, man! +5, Amiga Reference! :)

You just made my day.

Re:One test they never run - FRAGMENTATION

[Stoutlimb]

I don't know about anyone else, but if I install an SSD on my computer, one of the first things I'd be tempted do is run defrag on it to see how fast it goes. :-)

Re:One test they never run - FRAGMENTATION

[hankwang]

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.

I recently did an experiment on the impact of fragmentation on a flash drive, and it does seem that there are significant issues with fragmentation, although I'll be the first to acknowledge that I only tested one device so far and that an older SD card is not a modern SSD.

It looks like writing flash memory is very slow (tens of milliseconds for a write), which is compensated for by parallelizing writes in large (100+ kB) contiguous blocks, with obvious consequences for performance on writing scattered data. It would not surprise me if high-end SSDs parallellize their write operations across the separate physical chips inside so that a single write does not block all other read/write access to the device, but wear and access would still be better if data is stored contiguously as much as possible.

Re:One test they never run - FRAGMENTATION

[Anonymous Coward]

You can fill a previously unused section in the middle of a sparse file though. Which could indeed lead to fragmentation.

Re:One test they never run - FRAGMENTATION

[spydum]

To be fair, this is not exactly true. RAM fragmentation does impact some applications that demand contiguous blocks of memory to be allocated. I think Sun's JVM has such requirements on certain platforms.

Re:One test they never run - FRAGMENTATION

[Anonymous Coward]

RAM fragmentation is not an access speed issue; it is a continuous free space issue. As a software engineering problem, it definitely exists. I have no idea if OSes don't already do enough to prevent it or if any of the memory defragment tools actually do anything about it.

Re:One test they never run - FRAGMENTATION

[Anonymous Coward]

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.

The Samsung chip isn't SLC flash, it's a DRAM. The non-naive leveling algorithms tend to need some fast volatile memory to store layout information scanned from the flash array during powerup.

BTW, a couple key things you might not be aware of which are pertinent when thinking about how to design a wear-levelling controller:

First, SLC/MLC NAND flash blocks contain extra storage over the nominal capacity, since real systems will need to use it for ECC to detect and correct at least single bit errors (even before the erase cycle limit is reached errors will happen). This extra scratch/ECC area is large enough that the controller can also store pointers, counters, and other useful information associated with the block.

Second, writing is actually a 2-step process, erase then write. You can write to a flash memory cell at any time, but only one transition is possible, from the erased state (logic '1') to the programmed state (logic '0'). To go from 0->1 requires erase, which is a fundamentally different operation from writing. It's the erase block size which is large; flash chips can allow writing in much smaller units than the erase block, theoretically down to single bytes or even single bits. In the type of flash chips used in SSDs, the minimum write block is probably 4kB, matching the typical filesystem block size. Because of this architecture, a SSD controller can incrementally fill an erased block, rather than needing to write it all at once.

Re:One test they never run - FRAGMENTATION

[Anonymous Coward]

Testing SD cards isn't useful. I would remove the comment from the end of your article; you can't draw any conclusions about SSDs from them.

Always remember: flash memory cards are designed for cameras. Cameras write large contiguous files and users frequently reformat the cards or otherwise completely erase them. There is no need to design the controllers of such cards to perform well on random access patterns (fragmentation), nor is there any need to have particularly good wear levelling. These things are far too costly for something as cheap and minimalistic as a SD card. So you just can't draw any conclusions about SSDs from how SD/CF/MS/etc. cards behave.

Now, there are some SSDs on the market which do perform horribly under random write access patterns, especially the cheaper of the recent spate of enthusiast-oriented products, but the only way to know which ones is to conduct tests on the actual SSDs.

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

[Anonymous Coward]

That's the least insightful comment I've seen moderated "insightful," ever.

Re:Gonna Take a Little While Yet

[TooMuchToDo]

They need to get cheaper, and they need to be easy as pie to recycle, because people who write intensively to them are going to go through them faster than consumers.

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]

IMHO, we also need a couple of orders of magnitude more write cycles. I'm not entirely comfortable even with devices that claim a million write-erase cycles, much less multi-level devices like this one that only go for probably 10,000 write-erase cycles.

If they used a poor wear leveling algorithm, for example (e.g. one that relies solely on a pool of a few percent of spare blocks), you could make a 10k-cycle SSD unwritable in just a couple of hours. Somehow I am very uncomfortable knowing that the only thing between me and a complete drive failure is a proprietary algorithm that I have to blindly trust without the ability to inspect it and without any real peer review from other companies in the field. Short of either open sourcing these algorithms or creating open industry standards for how they work, the thought of relying on a SSD with such a short maximum cycle count is way, way outside my comfort zone.

Re:Gonna Take a Little While Yet

[Anonymous Coward]

I don't know. My first Apple II+ had four 143K floppy drives that cost $695 each. That didn't keep people from buying the Apple II+. You don't even want to know what my first 40MB SCSI drive cost, but I'll tell you anyway - $1080. I'll take one of these little SSD jobbers any day.

Re:Gonna Take a Little While Yet

[mosch]

80GB of blazing speed will find plenty of applications today, even at $600. Make the ZFS/Flash initiative happen, and I'd happily plonk down for a couple of them today, even at $600/drive.

Sure, I'm not going to pay $7.50/gb for a home media server, but there are lots of applications where that's an absolute steal.

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:Gonna Take a Little While Yet

[Whiteox]

I think your comment was truly insightful.

Re:Gonna Take a Little While Yet

[Von Helmet]

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.

Assume a fucking big television.

Re:Gonna Take a Little While Yet

[Anonymous Coward]

You are assuming a VERY naive wear leveling algorithm that can only move data within the spare area. If the wear leveling algorithm were only slightly less naive, and considered all unused areas to be "spare" for the purpose of wear leveling,(80GB hard drive with only 70GB used for example) then the story improves dramatically. We can infer that Intel is doing something like this, based on the following quote from AnandTech:

http://www.anandtech.com/cpuchipsets/intel/showdoc.aspx?i=3403&p=4
"One interesting sidenote, you can actually increase the amount of reserved space on your drive to increase its lifespan. First secure erase the drive and using the ATA SetMaxAddress commend just shrink the user capacity, giving you more spare area."
      --AnandTech

You are right to be wary. SSD vendors should report their write amplification numbers, along with some background on how the number was calculated. Intel has at least reported some numbers, has any other SSD vendor gone even that far?

The whole AnandTech review is very informative, and contains generic information on SSD architecture:
http://www.anandtech.com/cpuchipsets/intel/showdoc.aspx?i=3403

Re:Gonna Take a Little While Yet

[dgatwood]

I -think- that vendors generally report amplification numbers (at least when you're talking about SSDs as opposed to disposable keychain drives). The Intel numbers, however, seem (at least to me) to be too good to be true. The more incredible the claim, the more substantiation is needed.

We can infer that Intel is doing something like this, based on the following quote from AnandTech:

Actually, I would interpret that quote in the opposite way as an indication that corners are being cut in this area. Where increasing the spare count would make a huge difference would be with a naive algorithm in which data never moves unless it gets rewritten.

An ideal algorithm needs to use some reasonable weighting mechanism that says "Okay, this block has been rewritten a hundred times and 90% of the used blocks have only been written once, so let's copy data and turn some of those lightly-used cells into spares to level things out a bit." With such a mechanism, once you have a single bad block, ideally every block on the media should be nearly equally worn, including any spares and including all blocks that are used for other data. Therefore, increasing the number of spares (within a reasonable range) should have minimal impact on lifespan. The only effect would be to decrease the number of writes needed by one when the controller decides to swap out a heavily used block for one of those spares.

Over the life of the device, such a change should be very nearly lost in the noise. By increasing the number of spares from 1% to 2%, there's slightly more than a 1% (1/99) chance that the controller would now choose a spare block where otherwise it would have chosen a used block since it represents just over 1% of the total number of blocks. Thus, there's a 1/99 chance that it saves one out of two writes, so the lifespan improvement should be at most slightly over half a percent even if the device constantly swapped blocks around (bad for life expectancy. If it only swaps for one write out of every hundred, the lifespan improvement from doubling the spare count is reduced to a paltry 0.005%, assuming I'm thinking about this correctly.

Am I missing something?

Re:Blows doors off? I call bullshit.

[Anonymous Coward]

To be fair, in a web-serving or database read-only type operation it does in fact blow the doors off everything else. I have never seen IO graphs even close to that good on a single drive (SSD or not).

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.

Increase the capacity and lower the price

[Yvan256]

Other than that, we can already say that the days of magnetic media are numbered. The technology is here, we now only need to wait a bit. I give it three to four years at most.

Re:Increase the capacity and lower the price

[Anonymous Coward]

I think that depends on the use you are considering the drives for. Consumers interested in bargan basement prices will go for computer with traditional hard drives due to the cost savings. Servers, renderfarms, developers, etc will probably make the switch in the time you give, but my grandmother will probably never purchase a computer with a solid state drive unless it's used.

Re:Increase the capacity and lower the price

[freedom_india]

Nope. For sheer storage size, nothing can beat HDs.
Plus, SSD have still a lot to make up for in capacity and speed, random or otherwise.
My USB flash drive cannot accept a 4GB file in under 20 seconds yet. My WD Firewire drive HD does.
Figure it out.

Re:Increase the capacity and lower the price

[Anonymous Coward]

My USB flash drive cannot accept a 4GB file in under 20 seconds yet. My WD Firewire drive HD does.

NAND versus Memristor?

[Easy2RememberNick]

How different is NAND flash memory compared to Memristor technology and would Memristors make a better SSD?

Re:NAND versus Memristor?

[memristance]

Fundamentally, and potentially yes.
Details provided in the links.

Re:NAND versus Memristor?

[jeffb (2.718)]

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

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:Real use for SSD

[PitaBred]

Grab a price/performance ratio on all of those you listed, compare it to the ratio this Intel SSD has, and get back to me. Then put them in a RAID config. Not to mention... how many of those will fit into a 2.5" form factor? I don't think any of them. This is big news for mobile speed, and for compact datacenter needs.

Who needs..

[ypctx]

..flash memory, when you can have 300 GB of L1 cache? Oh wait, still not there..

System boot time goes from 43 secs to 37 seconds

[Anonymous Coward]

I'm not impressed. A 10 percent reduction in boot time does not blow my doors off.

far from the first

[sl0ppy]

http://www.pcworld.com/businesscenter/article/149792/intel_launches_smaller_ssd_for_netbooks_minidesktops.html

intel appears to have actually jumped into the SSD foray before this.

unfortunately, reviews have been lackluster.

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:SSD on PS3?

[68030]

Storing the game on a flash chip sounds conspicuously like games based on cartridge technology.

Starting to come full circle, eh?

Re:SSD on PS3?

[Awptimus Prime]

Yes. Much like the OS on a computer being installed on an SSD is a lot like the TRS80, Commodore, Apple2, Atari, etc with the OS built into a ROM-- except this time around we get to write to it freely.

Solid state storage should be very interesting in the coming years. Especially if there becomes a way to issue more writes before failure.

Re:SSD on PS3?

[magus_melchior]

The greater bottlenecks would be the optical disc or the Internet connection, I would think, unless the "install-to-HD" means "no more inserting discs" (I'd love to see the BSA squirm over that one).

Another problem for now is limited size: a single PS3 game can conceivably take up 1/4 of your SSD.

Re:SSD on PS3?

[Anonymous Coward]

It seems to affect performance pretty convincingly. It might even effect it, if you believe hard enough.

Re:SSD on PS3?

[Anonymous Coward]

Gamespot did a story on this (with a different drive, as Intel's offering was not yet available) here.

Long story short: it offered minor improvements at best and in some cases degraded performance. I'm not sure what the reason is, but in the PS3, at least, solid state disks are not worth the expense.

Re:SSD on PS3?

[Whiteox]

Nothing like booting from a 128k eeprom!
Ahhh... Those were the days!

Re:SSD on PS3?

[Penguinoflight]

Since games typically have to read to either graphics memory or system memory to run whatever data is needed, typically reads are sequential. High quality mechanical drives are still quite fast in sequential reads.

Re:Blows doors off? I call bullshit.

[TooMuchToDo]

Note to self: Tell Netflix to store all their watch it now content on these drives.

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:Blows doors off? I call bullshit.

[beaviz]

Pardon me, but it is "blowing down the doors" (and the house too) in some tests, like this one.

If you're an enterprise that can turn IOPS into profits, you can do much better than these Intel SSD's.

IODrive for example:
100.000 IOPS, 700MB/s read, 600MB/s write: http://www.fusionio.com/Products.aspx - you get a 80GB disk for about $4.500.

- another option is to run your database/whatever entirely in ram.

Re:Blows doors off? I call bullshit.

[Gat0r30y]

The read times are impressive - how impressive? I suspect almost nobody finds room for one of these in a machine that isn't just reading from disc. The metrics for write performance simply don't match the price tag. Also

According to Intel, its SSDs are so fast that NCQ helps to compensate for latency encountered in the host PC

NCQ? Really? Because the Host PC is too slow? I really don't buy that.

Re:Blows doors off? I call bullshit.

[Kingrames]

"door blowing manner" Sir, I am intrigued by your ideas and wish to subscribe to your newsletter.

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!

Re:Commercial uses don't fragment

[Anonymous Coward]

There is no concept of "modify a physical block" in flash devices. Most flash devices will make a new block when ever you modify even a byte in it. It's done for wear-leveling and also how flash can only clear whole groups of block or write a block. No clearing a single block and writing it again.

I know I'm not explaining it well. Just google JAFFS and YAFFS2 and see how they work. I believe there is one good article from IBM.

Ah! here it is - http://www.ibm.com/developerworks/library/l-flash-filesystems/

-1tsm3

What does volatile memory have to do with SSD?

[Layth]

Ram goes away as soon as your computer reboots or loses power.
I think you're entirely missing the point.

Re:What does volatile memory have to do with SSD?

[ypctx]

RAM goes away because BIOS tells it so (by cutting power or otherwise). In future systems, portion of RAM could easily be preserved on battery power, and cleaned could be only that portion, which needs it, if any. Solid state media would of course be used as a backup, but not necessary to be synced too often.
The only reason why we don't do this now is that huge L1 caches (future RAMs) are difficult to make and thus expensive. (IMHO)

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.

Re:Thinking about using SSD for external backup

[Tumbleweed]

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

Once they get the wear-levelling working as advertised, SSDs will beat spinning disks, hands-down. Wear-levelling will result in less capacity as time goes on, unlike a spinning disk which shreds itself and you lose everything. In theory, an SSD will still be able to read data on failed cells (they apparently fail on write), so this should result in less data loss than with a spinning disk. In theory. We'll see what happens in practice. My one worry with this scheme is what happens when you want to throw out an old SSD with private data in those read-only 'failed' cells. You can't write to them to overwrite them. Physical destruction seems the only way to get rid of SSDs with private data, as far as I've heard thus far.

Re:Blows doors off? I call bullshit.

[Just Some Guy]

These Intel drives are $595. Your $4,500 would buy 7 of these, for 560GB of storage, and 1750MB/s read / 490MB/s write in aggregate. Slice the speeds in half because you'll never balance loads that well, and you still get 875MB/s / 245MB/s. Slower writes but faster reads and 7 times the capacity.

Another option is to run your database/whatever entirely in ram.

I haven't priced machines with 64GB of RAM this month, but it was a little spendy last time I looked.

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:Price is over-rated

[noob749]

i think the reason people are making such a big deal about the pricing is that only the more expensive ssds actually offer any significant benefit over hdds. most of the cheaper/older generation ssds actually compare unfavourably to hdds (see http://www.tomshardware.com/reviews/ssd-hdd-battery,1955.html) in almost every metric.

Re:Price is over-rated

[Anonymous Coward]

That's for a shitty SSD.

Re:Blows doors off? I call bullshit.

[tknd]

They did blow the doors off the competition because they actually have engineers that get it. They were able to make an MLC based flash disk that is not only faster in every manner but has an amazing MTBF. This brings cheaper SSDs within reach. Look at how thorough the assessment of their MTBF calculations are and it really shows they paid attention to every detail.

Caveat

[Anonymous Coward]

It's fast..Until it starts wearing out.

Re:Caveat

[Anonymous Coward]

Yeah, Totally unlike Hard drivers the spin reliably forever...

Your SSD will become obsolete (speed, space) before it wears.

Also, when your disk crashes, your data there is lost. When flash wears, just new writes will fail.

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:Blows doors off? I call bullshit.

[BitZtream]

but for IO and read-heavy uses it's completely mindblowing

I'm being anal but ... you realize IO implies reading AND writing, right?

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:System boot time goes from 43 secs to 37 second

[Anonymous Coward]

Doesn't a seek time two orders of magnitude faster than a WD Raptor at least give you a semi?

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:Blows doors off? I call bullshit.

[Kjella]

I'm being anal but ... you realize IO implies reading AND writing, right?

Short answer, you have read and write performance as you'd see in normal laptop/desktop/workstation use which consists of fairly mixed size and randomness. Then you have what is typically database transactions - a huge number of small read/writes which tend to saturate the controller not the actual medium unless the underlying medium is extremely fast to respond. Those specificly interested will check out read IOPS, write IOPS and various mixes for various block sizes, but in many ways its a separate metric. Two fairly identical HDDs with the same read/write speeds may have very different IOPS depending on the controller.

Re:Your SSDs

[Anonymous Coward]

Surely you mean "I/O".

(or else you're doing it wrong)

It's only a teeny bit faster than my Velociraptor

[Joce640k]

In fact my VR destroys it in write speed...I'll stick with it for now.

Re:Blows doors off? I call bullshit.

[beaviz]

These Intel drives are $595. Your $4,500 would buy 7 of these, for 560GB of storage, and 1750MB/s read / 490MB/s write in aggregate. Slice the speeds in half because you'll never balance loads that well, and you still get 875MB/s / 245MB/s. Slower writes but faster reads and 7 times the capacity.

It's not about sustained read/write, it's about io's per second. Try to take a look at iostat at a busy database server, I bet you'll notice how there's hardly anything transferred at all, but a lot of IO-requests - and a lot of iowait.

Your RAID controller will probably make it even worse, trying to bundle request to allow higher transfer speeds - and even if it's a dumb controller you'll be limited by SAS/SATA-performance.

I haven't priced machines with 64GB of RAM this month, but it was a little spendy last time I looked.

Considering the cost of traditional ram based SAN, I think you'll find it cheap.

Re:Your SSDs

[Anonymous Coward]

Listen, lady. I don't come to where you work and slap the dick out of your mouth.

Don't you mean..

[Anonymous Coward]

Redundant RAID array of these drives?

(definitely not inexpensive though..)

Write Speed

[HaeMaker]

Why don't they put a 1GB RAM on the thing with a battery and create a huge write cache? This ought to make the write speed almost a non-issue.

Re:Write Speed

[rrohbeck]

What for? Your OS already uses lots of RAM for write buffering.
The write data rate only comes into play when you copy really large files, and it would only speed up things if you added more RAM than your system uses for buffering. In any case it would add a huge amount of cost and complexity. Also consider that batteries are a lot less reliable than electronics, they'd wear out and have to be charged, and you'd have to turn off write back as long as you don't have sufficient charge, which means you need really good charge circuitry that can monitor how much charge you have. That would mean a processor and lots of analog stuff.
Batteries are a PITA.

Re:Write Speed

[JimboFBX]

They probably did actually.

So?,..

[Anonymous Coward]

The software just crashes faster.

Re:Blows doors off? I call bullshit.

[treeves]

110 score vs. 109?! C'mon, surely that's blowing the doors off the competitor (Samsung in this case)!
And the good old-fashioned Western Digital hard drive that's only eight times bigger is waaaaaay back at 106!

Not for long.

[Anonymous Coward]

While it may blow the doors off the competition, Slavegate's lawyers will blow the doors off of Wintendo.

Test results and more results

[DDumitru]

I have been awaiting some non-intel results on the X25-M drives for a while. Intel has been very good at putting marketting spin on this drive. While it is a good drive, it is nice to finally see some real numbers.

There appear to be two sites that have posted IOMeter results. I like IOMeter numbers because they don't try to hide the details and are easy to reporduce. Just for fun, I ran IOMeter File-Server, Workstation, and Database tests on an in-house MLC SSD to see how it compared. My results are here compared with the two sites X25-M numbers.

File Server:

Numbers are "Outstanding IOs", MFT IOPS, Intel X25-M @ pcper.com, and Intel X25-M @techreport.com.

        1 - 2652.64 / 3000 / 850
        2 - 2724.80 / 3700 / 1010
        4 - 2224.81 / 4000 / 990
        8 - 2472.40 / 4800 / 1040
      16 - 2754.18 / 5200 / 1060
      32 - 2783.93 / 5800 / 1055

Workstation:

Numbers are "Outstanding IOs", MFT IOPS, Intel X25-M @ pcper.com, and Intel X25-M @techreport.com.

        1 - 3346.12 / 850 / 850
        2 - 3582.49 / 860 / 1000
        4 - 3637.09 / 910 / 990
        8 - 3657.64 / 900 / 1030
      16 - 3692.25 / 890 / 1060
      32 - 3716.06 / 900 / 1050

Database:

Numbers are "Outstanding IOs", MFT IOPS, Intel X25-M @ pcper.com, and Intel X25-M @techreport.com.

        1 - 3705.97 / 1800 / 980
        2 - 3947.26 / 1950 / 600
        4 - 3948.28 / 1100 / 600
        8 - 3838.48 / 975 / 600
      16 - 3800.85 / 925 / 610
      32 - 3930.27 / 800 / 620

Someday I will learn how to post tables on /.

A couple of points here. First, my numbers from the sites are from their graphs, so I might be off by a few percent.

Second, it looks like pcper.com's numbers for File-Server are messed up. They are too high at larger queue sizes. File-Server numbers should not be better than workstation numbers.

Regardless, these tests show two things. First, the Intel drive is a very good drive when comparing it with other "non managed" drives. Flash storage is a strange thing that really benefits from software that is designed for flash storage. That is what MFT (Managed Flash Technology) is. MFT is basically a transparent layer under the filesystem that re-ordered reads and writes so that Flash "is happy". Flash file systems do much the same things, although less aggressively than MFT.

Also, from what I can tell from Intel market-hype, their drive should last about 10x longer than other MLC drives for typical random-write workloads. This 80GB drive is designed for 20GB/day of random writes for a 5 year life. With MFT, a 64GB MLC drive can do about 100GB/day for a 7 year life so the software solution is still better.

Re:Blows doors off? I call bullshit.

[Kjella]

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.

You can modify those irc settings, at least in mirc /fsend will speculatively send 10 packets ahead and /pdcc the whole thing without waiting, oh yeah and increase packetsize with /dcc packetsize = 8192. It probably violates some RFC or the other, but I don't care. What makes DCC so horribly broken are the NAT issues, for example sends and resumes go in different directions so you get problems like being able to send but unable to resume.

Re:Your SSDs

[moosesocks]

Those're STDs.

It burns when I read/write

Dude... You might want to get that checked.

Most humans were only designed to do one or the other....

Damn SATA Connections!

[Whiteox]

Hrumph! I can't use it in my PIII home server damn it! Only got IDE.....

Not Intel's first

[the_raptor]

So Intel marketing would like people to forget their SSDthat is in the Acer Aspire One>? Which is notorious among the Aspire community for being a dog.

Erm. . . No. Power Consumption still a question.

[Fantastic Lad]

This is a very impressive article and all, good on yeh Intel and all that. . , but did anybody else notice that one of the most important tests was conspicuously missing?

That of power consumption during the write process. --They measured it on idle and on read but not on write, which is where SSD's fall down hard-core.

One of the things the ASUS eee crowd was surprised to discover was that the difference between the hard-drive and the SSD versions of their little netbooks was that there was virtually NO detectable power-savings in using the SSD over the hard drive.

Power consumption was the thing I was racing through the article for with 'chomping at the bit' anticipation for. What gives? (Not that it actually matters in a practical sense for me, but I would like to know more about this!)

-FL

Re:It's only a teeny bit faster than my Velocirapt

[Kingston]

Cheetah speed. Fifty, sixty miles an hour if they ever got out into the open, and they're astonishing jumpers...

Robert Muldoon - Jurrasic Park

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

[InfiniteLoopCounter]

I'm not impressed. A 10 percent reduction in boot time does not blow my doors off.

Either you have not programmed any part of a kernel, window manager, file system tools, any C/C++ program here, etc; or you you are very good programmer indeed. Here, fast boot up time is essential for peace of mind.

Re:Blows doors off? I call bullshit.

[sarabob]

Assuming, of course, that you can actually *get* an iodrive. They've been remarkably quiet since 'shipping' in 'April'. No benchmarks, no stockists, nothing.

Agreed that there's a whole load of us waiting for an SSD that does a decent amount of iops for small writes - sustained transfer is a pretty irrelevant metric unless you're copying huge files from one disk to another.

This does not "blow the doors of the competition"

[Canto.Bermuda]

I am used to Slashdot being more objective and informed than this. Write speed is extremely important in this market. Mtron has been selling much more mature products to NASA and the US military for many months already. check out : http://www.mtron.net/English/Product/ProductDetail.asp?itemcode=MSP-SATA7535 Sustained Read** 130 Sustained Write** 120

Mainframes had 'em back in 1990

[spookymonster]

Solid state storage? Command channels to take some of the load off the CPU? Sounds like the what we had on the s/370 (MVS) platforms.... back in 1990...

Re:Blows doors off? I call bullshit.

[beaviz]

Assuming, of course, that you can actually *get* an iodrive.

I'm not sure if they're lying or not, but I just ordered 2 of these cards, I was promised two weeks delivery (to Europe). We'll see in about 10 days if they actually deliver ;)

Re:It's only a teeny bit faster than my Velocirapt

[Just Some Guy]

In fact my VR destroys it in write speed

...as long as the writes are contiguous. If it's carved up into bunches of little seek-and-writes, pretty much any SSD is going to make the VR look bad.

Good thing its only doors

[toetagger]

Imagine it would blow off the Windows also, then it would truely be the year of Linux!

What is the best Filing System for a SSD?

[cryingpoet]

Filing systems such as EXT2 have to update a lot of nodes when a single file name is altered. Unnecessarily updating tables may cause additional wear on the flash drive. Samsung is working on a new filing system for SSDs, but I do not know anything about the impimentation or the advantages.

For Linux based systems perhaps one of the NAND Flash based filing systems could be altered to better fit the needs of a NAND hard drive. Does anyone know what changes could be made to UBIFS or LogFS to better fit the needs of a SSD?

Do any of the current filing systems work effectively on SSDs?

Re:Blows doors off? I call bullshit.

[Anonymous Coward]

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.

SFTP (which uses SSH) has the same problem, requiring each packet to be acknowledged before sending the next.

FTPS (which uses SSL) just streams encrypted data over a TCP connection.

Re:It's only a teeny bit faster than my Velocirapt

[PipsqueakOnAP133]

Actually, that doesn't seem to be the case. I've been staring at the results of file copy from drive-to-itself, wondering why the Velociraptor still crushes the X25.

Sometimes the X25 is behind by just 0.5MB/sec. Sometimes it's behind by over 20MB/sec.

When copying from a drive to itself, a HDD is normally crippled by the fact that typically different areas and partitions will cause the actuator arm to seek to a different location for each chunk. That seek time often costs you most of the time spent doing the file dupe.

Re:Blows doors off? I call bullshit.

[beaviz]

Assuming, of course, that you can actually *get* an iodrive. They've been remarkably quiet since 'shipping' in 'April'. No benchmarks, no stockists, nothing.

- and today two drives arrived at my office! :)