Beta

Slashdot: News for Nerds

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Long-Term Performance Analysis of Intel SSDs

Soulskill posted more than 5 years ago | from the apparently-some-things-get-worse-over-time dept.

Data Storage 95

Vigile writes "When the Intel X25-M series of solid state drives hit the market last year, there was little debate that they were easily the best performing MLC (multi-level cell) offerings to date. The one area in which they blew away the competition was with write speeds — initial reviews showed consistent 80MB/s results. However, a new article over at PC Perspective that looks at Intel X25-M performance over a period of time shows that write speeds are dramatically reduced from everyday usage patterns. Average write speeds are shown to drop to half (40MB/s) or less in the worst cases, though the author does describe ways that users can recover some of the original drive speed using standard HDD testing tools." Reader MojoKid contributes related SSD news that researchers from the University of Tokyo have developed a new power supply system which will significantly reduce power consumption for NAND Flash memory.

cancel ×

95 comments

Damn (1, Funny)

Anonymous Coward | more than 5 years ago | (#26852835)

Where is everyone? Oh right. Friday night.

Re:Damn (4, Insightful)

Viper Daimao (911947) | more than 5 years ago | (#26853069)

Exactly. BSG and Joss Whedon's new show are on.

Re:Damn (1)

Killjoy_NL (719667) | more than 5 years ago | (#26855229)

What new show?
I'm in the Netherlands, so I'd like to know (so I can sample it online) :D

Re:Damn (0)

Anonymous Coward | more than 5 years ago | (#26855265)

Dollhouse.

Re:Damn (1)

commodore64_love (1445365) | more than 5 years ago | (#26855583)

>>>Dollhouse.

It should be called "The Eliza Dushku Hour" because that's the only reason to watch it. At least it's better than that Terminator show which suffers from Gilligan's Island syndrome (no escape; no story progression). I suspect both shows are headed for the FOX Friday night graveyard along with Firefly, Brisco County Junior, Sliders, Millenium, Brimstone, VR5, Strange Luck, and Sliders. The X-Files is the only show to survive Friday night.

http://www.wallpapergate.com/data/media/77/Eliza_Dushku_010.jpg [wallpapergate.com]

   

Re:Damn (0)

Anonymous Coward | more than 5 years ago | (#26860791)

I am intrigued by her gazongas and wish to subscribe to her newsletter.

Re:Damn (1)

ptx0 (1471517) | more than 5 years ago | (#26854919)

Obviously, out buying some Intel STDs.

Re:Damn (1)

joaommp (685612) | more than 5 years ago | (#26855391)

Intel Sexually Transmitted Diseases?

Why? (3, Interesting)

IamGarageGuy 2 (687655) | more than 5 years ago | (#26852839)

I didn't see anything that answered the question of why this would happen. I may be slow but shouldn't it either fail or work? Is storage being lost and therefore getting less with more time used to find a good area? Please don't mod me as troll for not knowing (maybe flamebait for being stupid, I guess)

Re:Why? (1)

timmarhy (659436) | more than 5 years ago | (#26852925)

well, as the cells age it has to work harder and harder to find cells that are working to write on. probably involves some kind of write then test scenario, and the more times it has to rewrite data due to bad cells the slower it gets to complete a singe write.

Re:Why? (5, Informative)

Dr. Ion (169741) | more than 5 years ago | (#26853393)

Um... no.

When cells age, they take longer to erase. This happens over 5,000, 10,000 cycles or longer. It's not dramatic, and eventually the cells fail in a way more severe than can be corrected by the ECC.

Because there is a (software) process to bring full speed back to the drive, we can safely conclude that none of the slowdown is related to cell aging or other cell-level issues. It's more of an organization and fragmentation issue.

Re:Why? (1)

cheater512 (783349) | more than 5 years ago | (#26854177)

It brings it back to full speed, but I'd bet that it returns to the slow state much faster.

Re:Why? (2, Informative)

AllynM (600515) | more than 5 years ago | (#26855279)

There was no difference in how long it took to fragment. If we wrote a nasty enough mix of smaller file sizes to the drive, performance would drop right at the point where all flash was written to at least once (i.e. just over the 80GB mark).

After running HDDErase on the drive, it went the same *exact* 80 MB/sec write speed each and every time. Additionally, running successive software secure erasures (writing 0's across all 80GB) showed 0 drop in speed even after 10 passes.

In testing several different SSD brands / types, I have yet to see a slowdown that would suggest block erasures take longer over time. I suspect the block erase timing is based on flash that is at or near its end of life.

Al Malventano
PCPer Editor

Re:Why? (1)

commodore64_love (1445365) | more than 5 years ago | (#26855377)

I'm curious -

How much is the speed difference between a new Hard Disk Drive and a fragmented drive? Do HDDs also slowdown with age?

Re:Why? (1)

cheater512 (783349) | more than 5 years ago | (#26859711)

No they dont. The filesystem can get fragmented, but thats a different matter which also applies to flash.
While they are still working, they will always pump out the same speed.

Re:Why? (5, Informative)

SpazmodeusG (1334705) | more than 5 years ago | (#26852991)

The Intel SSD (and all SSDs) are made up of big addressable blocks. On the Intel SSD these are 64KiB in length. When you read or write to the drive the internal controller actually reads or writes an entire 64KiB block.
A simple change to 1 byte means a read of the entire 64KiB block that byte is in, a change of the data and then a write of 64KiB.
If the filesystem isn't flash-aware you can suffer a theoretical performance hit of being 65536 times slower because of this.

So what you really need is a filesystem that stores files in 64KiB blocks and groups reads and writes to the same blocks together as 1 operation.

Re:Why? (2, Informative)

MadnessASAP (1052274) | more than 5 years ago | (#26853099)

I thought it could flip a bit too 1 at will without having to rewrite the whole block but if you want to write a 0 it needs to read the whole block, wipe it out and rewrite it with the same data but with the bit flipped to 0. But I wouldn't really know, I'll use SSDs when they cost about the same as hard drives.

Re:Why? (1)

TheRaven64 (641858) | more than 5 years ago | (#26855439)

This is technically correct, but you'd need to massively redesign an operating system's block device and caching layers to take advantage of it. The smallest write that a piece of software will ever do is one byte, and the probability of such a write only changing 0s to 1s is very low. If you assume an equal probability of every prior and new value, then, for every bit, you have four equally likely transitions: 0 to 0, 0 to 1, 1 to 0, 1 to 1. The only one that is a problem is 1 to 0, so you have a 0.25 probability of this for each bit. For a byte, you have a probability of 0.000015, of a change going from one arbitrary value to another not flipping any bits from 1 to 0. It is not worth a massive rewrite to optimise for a condition that happens this rarely.

Re:Why? (1)

thePowerOfGrayskull (905905) | more than 5 years ago | (#26857171)

Wouldn't the probability be heavily weighted in favor of "1" to "1"? Think of all the minor edits that typically get done to existing files...

Re:Why? (1)

maxume (22995) | more than 5 years ago | (#26860245)

Unchanged bytes might be slightly more common than changed bytes, but deleting a single byte might require the file to be rewritten. The 'only 0's get flipped' case is not worth giving special consideration.

Re:Why? (1)

sjames (1099) | more than 5 years ago | (#26863263)

The idea is to avoid erases or at least batch them.

The idea is to allocate metadata blocks somewhere to manage the storage. The metadata for a block includes a replacement pointer set initially to all ones. If the block changes, write the replacement block number into that pointer. If a block is released, write 0 to the pointer.

This can be done in the drive logic or can be handled by the OS. The catch is that the device gets slower as time goes on. Eventually, you are forced to defrag the flash management system.

Wear leveling comes as a side benefit to such a scheme.

Re:Why? (5, Informative)

tlhIngan (30335) | more than 5 years ago | (#26853395)

The Intel SSD (and all SSDs) are made up of big addressable blocks. On the Intel SSD these are 64KiB in length. When you read or write to the drive the internal controller actually reads or writes an entire 64KiB block.
A simple change to 1 byte means a read of the entire 64KiB block that byte is in, a change of the data and then a write of 64KiB.
If the filesystem isn't flash-aware you can suffer a theoretical performance hit of being 65536 times slower because of this.

So what you really need is a filesystem that stores files in 64KiB blocks and groups reads and writes to the same blocks together as 1 operation.

Actually, NAND flash comes in 2 block sizes - small block (16kiB/block, 512bytes/page, 32 pages/block), and large block (128kiB/block, 2048bytes/pages, 64 pages/block).

Also, in NAND flash, a "write" operation can turn a "1" bit to a "0" bit. An "erase" operation turns a "0" bit into a "1" bit. Writes can work at the bit level, erases at the block level. (Though, large block NAND can NOT be partial-page programmed, so you must write 2048 bytes at once, but you can read all 2048 bytes, flip one bit, then write it all back). This characteristic is used by the flash management routines in order to manage the flash block. Marking pages as "discard" or "ready for erase" is done by flipping a 1 bit to 0 since that's easy. You can write a block partially, so you don't have to incur a huge 128kiB write always.

Given this, it's a block device, so you can't write 1 byte anyhow - you must write the sector size, which is emulated as 512 bytes. What normally happens is that the SSD will mark a page as "dirty" to indicate it's not to be used, and remap that page's contents onto a new page elsewhere, thus only performing a 2048 byte write (plus 64 out of band bytes).

Now, what happens when all the blocks are used? The flash routines have to erase a block, but before erasing a block, it has to make sure all the pages within it are "dirty". If there are non-dirty pages, they're copied to another block, and when all non-dirty pages are copied, that block is erased. If your access pattern is such that all the blocks have non-dirty pages, it takes a little while to actually move all the data around to get blocks that can be erased. Do enough random I/O, and this can happen quite easily.

Re:Why? (2, Informative)

Dr. Ion (169741) | more than 5 years ago | (#26853565)

Older flash devices allowed multiple writes to one page, but new ones do not.

The higher-density MLC devices do not allow you to read a page, flip a bit to 0 and overwrite it. They require that pages be written just one, and in order.

This is causing no end of frustration for the Microsoft mobile filesystems, which frequently overwrote pages to flag them.

Closer, but.. no. (4, Informative)

Dr. Ion (169741) | more than 5 years ago | (#26853403)

NAND blocks are *erased* in large blocks, probably 128KB or larger in this case.

However, the read and write operations occur at a *page* level, not block. NAND pages today are typically 2K or 4KB in size.

So you can read and write in smaller units than 128KB.

However, to erase any byte of the NAND, you have to relocate the preserved data and erase a whole block.

Because these drives operate on huge aggregate arrays of NAND, their block structure may be much larger, or they may have very complicated and smart algorithms to re-map write new data while waiting to perform erases much later.

Re:Why? (1)

adpowers (153922) | more than 5 years ago | (#26859533)

This isn't Wikipedia, we call them "KB" here. Thanks.

Re:Why? (1)

Phasma Felis (582975) | more than 5 years ago | (#26943879)

This isn't Wikipedia, we call them "KB" here. Thanks.

I do love the irony when Slashdotters insist on tradition over correctness.

Re:Why? (5, Informative)

Rockoon (1252108) | more than 5 years ago | (#26853081)

It happens because flash drives write on very large (512KB) "blocks", but they still pretend like they have average sized (4KB) "sectors".

Essentialy what the intel write-combining technology is doing is combining multiple small (4KB) writes into a single block, and letting the old block become fragmented (having a bunch of 4KB holes in it.)

The scenario in the nutshell:

You have a 1MB file and a program which modifies a single 4KB chunk of it. Intels technology marks the original 4KB chunk within its original "block" as erased, and then allocates a new block (using the wear leveling algorithm) to hold the new version of the 4KB chunk and additionally combines it with any other small writer operations that may have recently occured or will recently occur. Up to 128 such 4KB writes can be combined into a single block write.

After this is done many hundreds of thousands of times, however, the drive begins to be in a state where nearly every "block" is only partialy used. The write combiner itself is stuck with whatever the wear leveling algorithm handed it, which is now a partialy used block instead of a fully virgin block. It can no longer combine 128 small 4KB writes together, but maybe only has space to combine 10 of them, or in the worst case scenario.. 1 of them.

Re:Why? (-1, Flamebait)

billcopc (196330) | more than 5 years ago | (#26853321)

The "fragmentation-proof" SSD suffers performance degradation due to its own internal fragmentation...

So when the hell are the Linux fanboys going to get off their high horse and write a sane defragmenter for Ext2/3/4 ?

Re:Why? (0, Flamebait)

Anonymous Coward | more than 5 years ago | (#26853571)

Well, they got used to the idea that Ext never fragmented much because quite frequently it would corrupt itself and force a restore from tape. This naturally defragments the filesystem, leaving another six or so months until another automatic defragmentation was triggered. Now that newer versions don't fail so often, the true internal degragmentor is relied on. So now its quite frequent to see operational departments do the wipe-restore on a yearly basis to improve FS performance. This is pretty much the solution that linux admins will tell you to do, and the lack of a backup on your personal machine isn't their concern.

Re:Why? (1)

Dr. Ion (169741) | more than 5 years ago | (#26853419)

Again, it's only the ERASE unit that is huge -- 64KB, 128KB, or 256KB on the device itself.

You can't erase 4KB alone.

It gets more complicated when you consider huge parallel arrays of NAND, and the complex logical remapping that goes on to give the appearance of a typical 512-byte sector device.

Re:Why? (1)

AllynM (600515) | more than 5 years ago | (#26853797)

Nothing is lost, it just goes slower. Due to the fragmentation caused by write combining, the drive has to shuffle more data around when you write to those same areas later on. The flash is still being written at full speed as it copies the data internally, but the drive can only accept new data at the reduced speeds seen.

We're working with Intel to help them reproduce the more significant issue we saw.

Allyn Malventano
PCPer Editor

i just got off the toilet (-1, Troll)

Anonymous Coward | more than 5 years ago | (#26852877)

i shit out an obama

plop!

No fix until ZFS (1)

Gothmolly (148874) | more than 5 years ago | (#26852899)

With the fix for this problem being essentially "nuke the drive and reinstall periodically", there's really no fix until you get a flash-aware filesystem. Too many virtualization layers between your app doing the write, and the bits being flipped.

This could be useful for ETL jobs or other heavy 'batch' type work, as the nature of the access will essentially 'reset' the drive for the next pass.

EXT4/BTRFS (0)

Anonymous Coward | more than 5 years ago | (#26852959)

EXT4 has a mode for SSDs as well. ZFS isn't the only answer.

Re:No fix until ZFS (1)

TheRaven64 (641858) | more than 5 years ago | (#26855457)

Something like LFS, which predates ZFS by almost two decades, would also work. Everything old is new again.

TL:DR (3, Insightful)

Nursie (632944) | more than 5 years ago | (#26852937)

That article is a multi-page annoyance, the grammar is bad and we already have flash-aware filesystems like jffs2.

Re:TL:DR (3, Informative)

bcrowell (177657) | more than 5 years ago | (#26853145)

That article is a multi-page annoyance, the grammar is bad and we already have flash-aware filesystems like jffs2.

As far as I can tell from some quick googling and checking on Wikipedia, jffs2 isn't much of a competitor at this point, e.g., it's apparently not really usable on flash chips bigger than 512 Mb. Maybe UBIFS or LogFS? None of them seem to be really mature.

Re:TL:DR (4, Interesting)

TheRaven64 (641858) | more than 5 years ago | (#26855489)

Not sure about the Linux world, but LFS on NetBSD counts as mature. It's been sitting in the BSD tree since 4.4BSD (1990, a year before the first Linux release) and is well supported by NetBSD, although the other BSDs dropped it from their trees in the intervening decades because it didn't provide major benefits on rotating mechanical disks. With flash becoming cheap, suddenly it's seeing a lot more interest...

Re:TL:DR (1, Interesting)

mcbridematt (544099) | more than 5 years ago | (#26853349)

Will the traditional flash file systems (jffs2) etc. still work when we have SSD's interfacing over SATA? USB sticks don't work with it because they 'pretend' to be a hard drive over USB, and same for the SSD's over SATA. jffs wants the flash device (MTD) interface.

Intel employee Matthew Wilcox spoke at linux.conf.au about some kernel performance improvements related to the Intel SSD drives - redundant ATA calls that have been removed, and allowing larger sector sizes under ATA 8 [lwn.net] , so maybe the authors of this article should look to a recent Linux kernel.

Re:TL:DR (2, Insightful)

renoX (11677) | more than 5 years ago | (#26854115)

Flash-aware filesystem currently only works on embeded setup where there is direct access to the Flash.
Given the need for compatibility, SSD will always have a controller showing the SSD as a disk, but I agree that it'd be nice if they would add additionnal lower level access in the case the computer is able to use Flash-aware filesystem.

Re:TL:DR (1)

cuby (832037) | more than 5 years ago | (#26854851)

Dont't be a troll!
The article was very useful and, as far I can tell, the author was systematic and did a good research. This conclusions are very useful for everyone using SSD. Did you ever used jffs2? Do you trust your files to it? Come on... At present there is no production reliable, SSD oriented file system available.

Bullshit (0)

bluefoxlucid (723572) | more than 5 years ago | (#26852981)

Fortunately for us, flash based storage has access times nearly as fast as RAM

My 300MHz DDR bus had 300M x 2 x 8 == 600M x 8 == 4.8GB/s sequential read access speed.

Re:Bullshit (1)

Aluvus (691449) | more than 5 years ago | (#26853109)

I assume you realize that "maximum theoretical speed of the interface" and "real-world performance" are not the same thing.

Re:Bullshit (1)

bluefoxlucid (723572) | more than 5 years ago | (#26892239)

Consider that's 300MHz DDR, and DDR3 can hit 12.8 gig peak. Peak performance and real-world performance will be analogous; a slower chip's peak performance and real-world performance will be slower.

Re:Bullshit (1, Informative)

Anonymous Coward | more than 5 years ago | (#26853139)

Access time != bandwidth. But you're right, RAM still has much quicker access times. Still, both seem instantaneous to humans; is a 0.2 ms access time really so bad for most applications?

Re:Bullshit (1)

bluefoxlucid (723572) | more than 5 years ago | (#26892265)

0.2mS for 300 trillion accesses.

Re:Bullshit (1)

Dr. Ion (169741) | more than 5 years ago | (#26853427)

Access time != sequential bulk read throughput.

Think hard drive vs flash drive.

Flash does have "access time" close to RAM, since it doesn't have to seek or do complex addressing.

When you have these huge banks of flash acting as one drive, then "access time" becomes a computational problem of how fast you can look up the physical location of the user's data, based on a logical sector address.

Still faster then mechanically moving a drive head, of course.

File system? (1)

mail2345 (1201389) | more than 5 years ago | (#26852983)

The problem, according to the article is writing small files over and over again, like the journal in journaling file systems, so would not using a journaling file system reduce the problem?

Re:File system? (1)

some_guy_88 (1306769) | more than 5 years ago | (#26853095)

I'm confused. Is the problem the deteriorating hardware or an unsuitable filesystem?

No I didn't RTA..

Re:File system? (2, Insightful)

Dr. Ion (169741) | more than 5 years ago | (#26853455)

One of the biggest challenges of the coming years will be finding and developing filesystems (logical data stores) that take advantage of the strengths of flash memory while deminishing the weaknesses of it.

Our approach today is mapping large banks of Flash to look like a hard drive, and then using a filesystem that is optimized to reduce seek activity. (Cyl/Hds/Tracks-per-Sector..)

EXT3 on SSD, FAT on huge SD cards, it's just shoe-horning our old filesystems onto new media. It makes about as much sense as using a hard drive to store a single TAR image only.

Once we make the huge step of designing high-performance filesystems that are exclusively *for* flash media, then we can take advantage of some of the huge benefits that are distinctly flash.

Key things like journalling should be designed with the flash organization in mind: pages and blocks vs "sectors". That kind of thing.

Re:File system? (1)

TheRaven64 (641858) | more than 5 years ago | (#26855501)

Or we could use an old filesystem, like LFS from 1990, which was part of the last BSD release from UCB. It works best on devices where random read and linear writes are very cheap. Devices like flash.

I am waiting for these SSDs (3, Informative)

bogaboga (793279) | more than 5 years ago | (#26853017)

I am patiently waiting for these SSDs and plan to test them on a MythTV distro box. I will get a fully compatible Linux SSD notebook onto which a MythTV distro will be installed.

Then with 3 TV cards, I will see how these SSDs measure up on reading/writing/transcoding etc. My intention is to work the SSD for about a week. Watch this space for results.

I do not think that Intel will deliver the "golden" SSD. I think Samsung's SSD [samsung.com] effort will bear results faster. Those videos say a lot.

SLC vs MLC (3, Interesting)

w0mprat (1317953) | more than 5 years ago | (#26853195)

Isn't the problem partly MLC? SLC has consistently better small random write performance. Many cheap SSDs use MLC for obvious reasons, it fairs well in benchmarking -MLC has relatively high read performance- but write performance hurts real bad in real world usage. You may get noticeable micro-lag anytime the OS writes to storage. Application loading may be snappy for example, but the whole system slows down while writes are done. It's good to see the truth coming out amongst all the benchmarketing

It's early days for SSDs. I'll be sticking with my power guzzling magnetic frisbe stacks for a while yet.

Re:SLC vs MLC (1)

billcopc (196330) | more than 5 years ago | (#26853375)

Many cheap SSDs use MLC for obvious reasons,

You hit the nail on the head. This high-price Intel SSD is just a cheap MLC unit with a big brand name and inflated expectations.

I'm usually quick to adopt new tech, but I'm still not satisfied with SSDs. I can't think of a good reason to use one in a desktop PC right now. They're slow, they die young, and they have perverse design quirks like oversized pages that result in internal fragmentation, and oh yeah, they cost an arm and a leg. Once someone releases an SSD that solves ALL of those sticky points, and ideally delivers enough random-access throughput to saturate the 300MB/s SATA line (or whatever bus is mainstream by then), that's when I'll jump on board.

Right now, my opinion is that anyone even considering an SSD would probably be better served by a VelociRaptor. Same price, same humorously low capacity, less bullshit.

Re:SLC vs MLC (2, Informative)

Anonymous Coward | more than 5 years ago | (#26853521)

Once someone releases an SSD that solves ALL of those sticky points, and ideally delivers enough random-access throughput to saturate the 300MB/s SATA line (or whatever bus is mainstream by then), that's when I'll jump on board.

Well, like myself, you will be waiting for a non-flash based SSD then.

Inevitably, something like PRAM [wikipedia.org] will displace Flash, and it can't happen soon enough. Until then, I would much rather see some of that fab capacity reclaimed for DRAM production.

Re:SLC vs MLC (0)

Anonymous Coward | more than 5 years ago | (#26855231)

Until then, I would much rather see some of that fab capacity reclaimed for DRAM production.

Um, why? Is RAM (except for brand new DDR3) not already dirt cheap?

Re:SLC vs MLC (2, Interesting)

Kneo24 (688412) | more than 5 years ago | (#26855027)

I've been using an Intel SSD as a boot drive and I think it's worth every penny so far. I have a few programs and games on the boot drive and they all load up considerably faster than the alternatives. I don't care about write speeds. Their size alone means they're not really meant for storage yet, so using it as such is a bit retarded. If you're doing a lot of write operations to your SSD, you should probably think about moving that file(s) to a different storage device.

Re:SLC vs MLC (1)

afidel (530433) | more than 5 years ago | (#26861963)

Intel already sells most of what you want, it's just spendy. It's called the X25-e and it's an SLC based SSD that will do 170MB/s read and 150MB/s write even at 4KB block sizes. It costs ~$700 for a 32GB drive which is why they aren't all that popular with the ricer desktop set, but if you have a database server that can use a wicked fast log file drive and you don't already have a SAN then it's currently the way to go.

Re:SLC vs MLC (0)

Anonymous Coward | more than 5 years ago | (#26941957)

You might want to think about this for just a second. In the military they have been buying flash-based storage for about 15 years. When they started a 1TB drive cost over $150,000. It could go about 140MB/s sustained read or write. Of course that took a 16-channel system with whopping 128Mb chips. This new Intel SSD is a 10 channel MLC drive. You can purchase the SLC version for $400 as well but it is only 32GB. I certainly agree with you that magnetic hard drives can offer quite a bit better price point and don't have that bad a performance. But I would like you to consider this: when you are developing software or hardware that costs $100-$200/hr to develop and you lose 2 hrs or work because the hard drive failed were you really better off working from some $50 Seagate special or from a $400 SLC drive from Intel?

Re:SLC vs MLC (0)

Anonymous Coward | more than 5 years ago | (#26853463)

I'm not familiar with the SSD write-leveling algorithms, but you should be able to improve the write performance by sing a battery-backed disk controller that combines a lot of small random writes into a large sequential write.

Small vs Large (1)

Dr. Ion (169741) | more than 5 years ago | (#26853487)

MLC brings more density to the table. That's the only reason they do it. Smaller die size and storage density means more MB per dollar

SLC would be a much smaller capacity drive for the same money. It would be faster at writing, but probably too expensive or too small to have many adopters.

Same reason SLC is all but unheard-of in thumbdrives. (IronKey being one exception.)

Re:SLC vs MLC (1)

BikeHelmet (1437881) | more than 5 years ago | (#26853959)

I'm trying to snatch up some last-gen Mtron SSDs. The Mobi 3000 looks especially good for the price. They're old and only 16GB, but they're also SLC server SSDs, with about 100MB/sec read and 80MB/sec write.

Cant wait for them to drop under $100!

Re:SLC vs MLC (1)

dslbrian (318993) | more than 5 years ago | (#26854339)

I think a major hidden problem with MLC is not so much read or write speed, but data integrity. If an MLC chip is storing 4-bits per cell, that's 16 discrete VT levels that need to be detected to resolve the stored info. Couple that with increasingly smaller cell sizes and it would seem to me that even very low levels of gate leakage could lead to bit errors.

I cringe at the thought of using an MLC based SSD to store important data and then having it basically bit rot due to gate leakage (an effect which is worse at hot temp if the drive is cooking inside a case). I use USB thumb drives more than SSDs, but even those are most all MLC now. Nobody lists what the error correction capabilities are for these things (perhaps SSDs list them but I've never seen it for USB drives), which makes them kind of dodgy IMO. Anyone know the typical EC specs?

I usually run TrueCrypt on my USB drives also, and I kind of wonder what the effect of bit errors would be on that. Currently I've been using SLC, but I expect in the future that option will go away.

Re:SLC vs MLC (0)

TeknoHog (164938) | more than 5 years ago | (#26854539)

To me, MLC has a conceptual problem of going against the fine tradition of binary computing, which is all about data integrity. Why don't we go back to analog computers for even higher densities, while we're at it.

Re:SLC vs MLC (4, Insightful)

Kjella (173770) | more than 5 years ago | (#26855289)

To me, MLC has a conceptual problem of going against the fine tradition of binary computing, which is all about data integrity. Why don't we go back to analog computers for even higher densities, while we're at it.

Says someone that obviously has never seen the raw output of a HDD read head, or the optical laser in a DVD reader. The real world was always very ugly and analog, there's a helluva lot going on to give you a 0 or 1 answer.

Re:SLC vs MLC (4, Informative)

cnettel (836611) | more than 5 years ago | (#26855327)

Do you detest Gigabit Ethernet and disk-based drives as well? Pure binary protocols for signals on media tend to be inefficient. The technology is still digital. Whether data integrity is a priority or not is really a matter of proper error correction, to rely on avoiding on single-bit errors is a flawed strategy.

Re:SLC vs MLC (1)

TeknoHog (164938) | more than 5 years ago | (#26865445)

Thanks. I stand corrected. This doesn't make me any happier about MLC flash, though.

Not ready for prime-time (1)

aaronmarks (873211) | more than 5 years ago | (#26853265)

This is unfortunately another case to show that SSDs are not ready for prime-time. With that said, I'm anxiously awaiting the ability to buy a super-fast 120GB+ SLC drive once prices drop below $400.

I just hope that Microsoft and Apple come up with some great software enhancements for handling SSDs ASAP.

It is hard for me to believe that the two OS giants can't release their upcoming software in a way that is totally SSD optimized. They are kidding themselves if they don't think that conventional mechanical HDDs are living past their life expectancy already.

Certainly ready for prime-time (1)

wikinerd (809585) | more than 5 years ago | (#26855673)

For some time now all my storage needs are satisfied in their entirety by SSDs and I have no HDDs now. Certainly much better than my previous 10,000 RPM hard disks, so I think they are ready for the prime time.

Re:Not ready for prime-time (1)

Doppler00 (534739) | more than 5 years ago | (#26857601)

I believe there is so much misconception out there about flash memory performance, it's astonishing. There just isn't a good understanding of how all the layers of cache in the OS work.

SSD's are not slow, do not "die young". I just built a new system with 3 SSD's in RAID0 and I'm getting 350MB/sec sequential read performance, and nearly 250MB/sec sequential write. In fact, I'm less worried adding additional drives in RAID0, because they fail by total wear, not a single point of a failure, and if the wear is being spread out, it should be less of a concern. I have not done benchmarks on random write performance yet, but I'm guessing it will not be that bad.

100% of the problems now are related to some of the controllers and how the OS caches data before writes. For example, why would you write thousands of small 1k blocks, and not cache those in memory first if the write is going to occur a second later? In fact, most OS's will intelligently do this.

So here's the real problem, a bunch of the early SSD's that came out were incredibly cheap and used really really bad controllers. Most of the new new SSD's now have moved beyond these deficiencies. Because of the past products though, it's creating a huge confusion in the market and people just don't "trust" these new products.

Re:Not ready for prime-time (1)

lmnfrs (829146) | more than 5 years ago | (#26858541)

In a 3 drive RAID 0 array 350MB/s isn't that impressive. That's 116 2/3 MB/s per drive which is only slightly higher than the 1TB SATA spindles that were on sale months ago for less than a SSD. (Those speeds were maximums, though. Min was in the upper 60's I believe.)

That performance is cool but its price premium is huge for a drive that provides only a fraction of spindles' capacity. Until they drop in price or are handled more efficiently to improve their performance, they may be ready for prime time but they're being sold for PPV prices.

Re:Not ready for prime-time (1)

Doppler00 (534739) | more than 5 years ago | (#26860087)

The benchmarks I've seen on 1TB drives show about 80MB/sec average, and it goes from 60MB to 100MB/sec depending on the location of the read on the drive, SSD's don't have this non-linearity. Also, the 350MB/sec is reaching the limitations of the RAID controller, a single drive is about 150MB/sec, so it starts scaling down a little when you add more. I will probably try a PCI express adapter that has more bandwidth in the future.

Still, the main speed boost is in the latency. 0.2ms vs 8ms is a huge leap. Also, I like my system as silent as possible, so I'm willing to pay a premium for that.

I save additional files on an external 1TB drive when needed.

As far as price, if you avoid the big name brand Samsung and Intel parts, you can get fairly good prices.

There's got to be some writable space here... (-1, Flamebait)

LostCluster (625375) | more than 5 years ago | (#26853285)

The thing about all forms of flash memory is that they can stand limited numbers of writes per physical bit, the exact number varies by design, but in general the number is much fewer than magnetic specs of similar cost and size.

So, I think we have an explanation for the the write speed decrease. The rated size of the "logical disk" is what they make available, while more bits stand back waiting to replace bits that have gone bad. When such bits have to come into play, it takes a guess and check process just to find where the bit the physically is within the SSD. That takes time... and there you go.

Re:There's got to be some writable space here... (4, Insightful)

Dr. Ion (169741) | more than 5 years ago | (#26853529)

That's so oversimplified as to be completely wrong.

The number of write/erase cycles on NAND is significantly less than a hard drive. Typical devices are rated for 10,000 cycles. Bleeding-edge MLC parts can be as low as 5,000 or 7,000 erase cycles.

But.. a well-designed device will perform accurate wear-levelling across all the available blocks, so it doesn't matter what kind of access the user performs -- the whole device will wear evenly.

There are indeed reserve blocks to mitigate premature death of some parts.

But, the most important part is the ECC mechanism. The parts don't just wear out and die, they get an increasing bit error rate. By overdesigning the ECC logic, you can squeeze longer life out of the parts.

It does not play guess and check.. well-recognized error correction algorithms like Reed-Solomon or BCH are used with really high detect/correct rates.

Once you have accurate wear levelling, excellent ECC, and some manner of failure prediction, then it doesn't make so much sense to keep all your flash "in reserve" ready to swap out other parts wholesale. You might as well involve all the parts in the mix, so you get longer wear throughout.

Re:There's got to be some writable space here... (0)

Anonymous Coward | more than 5 years ago | (#26853723)

RTFA

My take on this (0)

Anonymous Coward | more than 5 years ago | (#26853307)

If, after all of these years, sophisticated measurements can't show whether SSDs are faster or slower, then I am probably not going to notice when running one at home.

Still better than the alternative (2, Informative)

Anonymous Coward | more than 5 years ago | (#26853533)

Looking at the big picture, I'd rather have a slow SSD than keep dealing with the data losses of (criminally unreliable) HDs.

Re:Still better than the alternative (0)

Anonymous Coward | more than 5 years ago | (#26856243)

Good luck with that. The current generation of SSD's are not any more reliable than the old spinning media. In fact, my personal experience says they are much, much worse than hard-drives when it comes to failures in use on a development workstation. Using SSD's on a machine used for development work (compiling, VMware, databases, etc) seems to kill them in short order. I have never had one last more than a year.

They also seem to have failure patterns similar to hard-drives. That is, often they will either die within the first couple weeks (ie. it was a manufacturing defect) or they will a last few months until the rewrites start to kill the memory cells. See, even if the cells are rated for x number of rewrites some of them will be bad and can't take anywhere near that many rewrites. When you get enough bad cells (ie. it runs out of space) the drive starts crapping itself and you have to toss it.

Same goes for other people I know using SSD's on machines that are actually used for real work. The common Average Joe machine used for web browsing and e-mail doesn't typically have as many failures and that's why people think SSD's are good but they're not really using their computer either.

I'm hopeful the situation will improve but right now SSD's suck donkey balls as much as hard-drives.

Re:Still better than the alternative (0)

Anonymous Coward | more than 5 years ago | (#26860519)

Thank you! I came very close to buying an SSD 3 days ago. Now I'm glad I didn't. But I'm sick to death of the horrible quality of HDs. Does anyone care about quality anymore? What is the solution?

As to the second link, the power saving one... (1)

YesIAmAScript (886271) | more than 5 years ago | (#26854441)

A boost converter is FAR from new.

http://en.wikipedia.org/wiki/Boost_converter [wikipedia.org]

They have not invented a new power supply system. They are just suggesting it be applied to NAND and the high voltage needed be fed into the chip from a central supply, instead of having a charge pump (switching capacitors) in each NAND chip.

I'm not certain this will save power, but it will reduce peak currents because when the charge pumps switch on in the NAND chips, it creates a huge (but short) current spike. And if you write to two NAND chips in parallel, the spike is doubled.

a new power supply system ... (0)

Anonymous Coward | more than 5 years ago | (#26855191)

which will significantly reduce power consumption for NAND Flash memory

What's that - an on-die Beowulf cluster of gerbil-powered bicycle dynamos?

STDs (0)

Anonymous Coward | more than 5 years ago | (#26855353)

I thought the title was "Long-Term Performance Analysis of Intel STDs" for a second there...

already on a french computer news website (0)

Anonymous Coward | more than 5 years ago | (#26855535)

This french website www.matbe.com/articles/lire/1001/ssd-intel-x25-m-80-go-une-bombe/page12.php had an article about that in september 2008.
It is apparently the consequance of optimizations for "normal" desktop use, ie sequentials writes.
when you do random sustained random writes, it fragmentes the drive.
Not on the filesystem layer but in the SSD address translation system.

Big opportunity for Linux (1)

jensend (71114) | more than 5 years ago | (#26856139)

As people push for smaller laptops with longer battery life and as flash memory continues to drop in price and power requirements and to gain in raw performance, it makes less and less sense for people to use mechanical hard drives in laptops. But as this article shows, the drive's logic can only do so much to try to maintain performance while appearing to the OS to be just a regular hard drive. Using a direct flash interface and a flash file system like UBIFS, YAFFS2, or LogFS should provide Linux netbooks etc with a serious performance advantage while costing only a fraction of what the higher-end SSDs cost. Since Windows users are fairly tied down to NTFS or FAT, this seems to me to be a good opportunity for Linux to snag marketshare.

Hw Wear leveling is BAD (1)

chiui (1120973) | more than 5 years ago | (#26857147)

Hardware CAN'T know what areas are used and what aren't. So those hw workarounds for not using a real flash filesystems can't work well.
I can't understand why those people are still spending money in producing such complex brain damaged products. Give us complete access to flash chips, let the OS do the right thing. Legacy operating systems like Windows? Just give a driver and the flash file system in bundle! I'm sure performance and cost outweight the inconvenience of installing it. Maybe use a replaceable USB drive just for booting, which is compatible, cheap and convenient. Anyway those product are not for general market yet, can't understand why they are doing this mess to "semplify" things.

...workarounds for not using a real filesystems (1)

Joce640k (829181) | more than 5 years ago | (#26859159)

This is what happens when your OS is closed/proprietary.

Re:Hw Wear leveling is BAD (1)

maxume (22995) | more than 5 years ago | (#26860269)

You do realize that there is software in the hardware that is lying to the software at higher layers, right?

Even spinning disks present a virtual interface to the hardware.

Re:Hw Wear leveling is BAD (1)

chiui (1120973) | more than 5 years ago | (#26871581)

You do realize that there is software in the hardware that is lying to the software at higher layers, right?

Even spinning disks present a virtual interface to the hardware.

I understand that there IS a layer even on hard disks.
The problem is that the layer for SSD is currently the wrong one (the hard disk one)
In fact, the linux layer for MTD devices is completely different and more complex, and flash filesystems are very specific for that layer so you can't use them for normal block devices.
I don't say you don't need a layer. I say that using the wrong layer and reversing it in hardware is excessively WRONG.

SSDs and forensics (1)

klui (457783) | more than 5 years ago | (#26857359)

This guy presented SSDs and they're are laid out. Seems like quite a bit of unknowns now.

http://www.youtube.com/watch?v=WcO7xn0wJ2I [youtube.com]

my SSD performance results (1)

Doppler00 (534739) | more than 5 years ago | (#26857797)

Okay, I just ran this benchmark on my 3 RAID0 SSD array....

From 0.5KB to 128KB write performance (in KB/sec)
3928
7368
12579
19931
48306
83492
143772
233510
252352

The reason for the low performance on small block sizes is the option called "Direct I/O" on ATTO Disk Benchmark. What this probably does is turns of your system's caching capability, so of course you are going to get ridiculously slow rates. It's good for comparison, but to say you're system is going to be slow because of it is ridiculous because in the real world your OS will cache everything. If you look around, you'll see that 7200 RPM HD also do bad on these write benchmarks. Maybe better on read, because HD have a RAM buffer, but that shouldn't matter in real world if you're using the OS's cache.

And ATTO tech is more interested in selling disk controllers anyway, so really this is more of a disk controller benchmark, not real world HD performance usage.

It would be the equivalent of turning L2 cache off on your CPU and publishing those benchmarks as real world performance.

I think a more accurate benchmark would be some type of MySQL database test.

SSD (1)

JimOD (1475509) | more than 5 years ago | (#26862433)

The Intel X25-M series of drives are the best performing MLCs offerings to date.

Fusion too. (0)

Anonymous Coward | more than 5 years ago | (#26893375)

FusionIO sells very fast SSDs in a PCI-E form factor. Writes to their device slowed down materially over time. A driver update fixed it.

It turned out that they erase "empty" blocks in the background, and were not doing so at a high enough rate.

It still slows down if you write to it heavily, but a kernel thread is seen using a lot of CPU, and when this is over, writes are fast again.

Use MFT instead... (1)

Rainefan (969597) | more than 5 years ago | (#26943255)

You could use Managed Flash Technology to improve write performance and drive lifetime as well (Windows and Linux). For MLC or SLC drives. http://managedflash.com/home/index.htm [managedflash.com]

Re:Use MFT instead... (1)

Rainefan (969597) | more than 5 years ago | (#26943287)

From the site: "Flash memory is a wonderful invention. It can randomly access data at speeds up to 60 times faster than a hard disk. Similarly, the newest MLC models are as cheap as enterprise hard disks. But Flash has a problem: when this data needs to be written back, the random write speed is often only 1/500th of the random read speed. As a result, most flash drives inherently perform a little better than some hard drives, and a little worse than others. Our patent pending Managed Flash Technology (MFT) solves that random write problem, enabling Flash Drives to write clusters of random data in linear streams, thus allowing it to write at the full Flash Drive linear write speed of forty to ninety megabytes a second (which is 10,000 to 22,000 4kb writes per second). Normal random writes put things back where they came from. Writing linearly requires us to put them where ever free space is available at this moment. This method of remembering things works as long as a memory table exists to tell you where a logical sector is at this moment. Similarly, MFT often extends the effective write-life of Flash SSDs by two orders of magnitude. While this may not be of practical benefit if you are using an expensive single-level cell (SLC) based Flash SSD, it may be absolutely critical if you want to use the vastly less expensive, but more limited erase-life multi-level cell (MLC) drives. That is the essence of MFT. In the following pages, we will consider particular elements in detail."
Check for New Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Create a Slashdot Account

Loading...