Forgot your password?
typodupeerror
Data Storage Intel Hardware Technology

Intel's Braidwood Could Crush SSD Market 271

Posted by kdawson
from the if-only-they-could-make-it-rotate dept.
Lucas123 writes "Intel is planning to launch its native flash memory module, code named Braidwood, in the first or second quarter of 2010. The inexpensive NAND flash will reside directly on a computer's motherboard as cache for all I/O and it will offer performance increases and other benefits similar to that of adding a solid-state disk drive to the system. A new report states that by achieving SSD performance without the high cost, Braidwood will essentially erode the SSD market, which, ironically, includes Intel's two popular SSD models. 'Intel has got a very good [SSD] product. But, they view additional layers of NAND technology in PCs as inevitable. They don't think SSDs are likely to take over 100% of the PC market, but they do think Braidwood could find itself in 100% of PCs,' the report's author said."
This discussion has been archived. No new comments can be posted.

Intel's Braidwood Could Crush SSD Market

Comments Filter:
  • by jcr (53032) <.jcr. .at. .mac.com.> on Friday September 04, 2009 @08:23AM (#29309643) Journal

    Sooner or later, no moving parts beats moving parts. The magnetic disk makers have done an amazing job so far, but eventually they're going to lose out to solid-state.

    -jcr

  • Re:Bullshit (Score:5, Insightful)

    by jcr (53032) <.jcr. .at. .mac.com.> on Friday September 04, 2009 @08:30AM (#29309707) Journal

    Random I/O is essentially uncacheable.

    I'm sure that would come as a great surprise to anyone who ever implemented a virtual memory system.

    -jcr

  • by BESTouff (531293) on Friday September 04, 2009 @08:33AM (#29309727)
    If the onboard flash is a cache, that means it will be used frequently do it will wear faster. Won't that mean you're more likely to corrupt your data, even if your HD is still good ?
  • by Anonymous Coward on Friday September 04, 2009 @08:34AM (#29309739)

    Just goes to show how warped a professional's perspective really is. Standard consumer with 4TB of data? Really?

  • by natehoy (1608657) on Friday September 04, 2009 @08:36AM (#29309747) Journal

    I agree, but why would Intel want to use flash memory for this? RAM is faster, has the capability of a LOT more read/write cycles, and could be backed up by a small battery in the case of short power outages (or maybe a battery big enough to run the hard drive long enough to flush the write buffer, as others have said).

    This is essentially a cache, which means it's going to get a lot of reads and writes. Under those circumstances, the flash memory's going to wear out relatively quickly and unless it's easily replaceable it means everyone's going to need to buy new motherboards every year. How could forcing people to replace motherboards annually possibly benefit Intel? Oh, wait...

  • Re:why flash? (Score:2, Insightful)

    by imgod2u (812837) on Friday September 04, 2009 @08:37AM (#29309755) Homepage

    Your OS doesn't always have time to shut down properly. Don't think anyone's fond of the idea of having their last couple of saves go poof because Windows crashed.

    Intel's SSD drives already have 32MB of DRAM. But it's not used to buffer data because of reliability issues.

  • Re:Not so sure (Score:5, Insightful)

    by Dogtanian (588974) on Friday September 04, 2009 @08:41AM (#29309785) Homepage

    I can't take the flash to the next PC as i can do with the SSD.

    Not really a big deal; if it becomes commonplace, most PCs will eventually have it (or something like it) as standard anyway and you won't be bothered about it.

  • by kimvette (919543) on Friday September 04, 2009 @08:47AM (#29309843) Homepage Journal

    The RIAA and MPAA would have you believe that each man, woman, and child has downloaded at least that much illegal movies and music.

  • Re:Bullshit (Score:3, Insightful)

    by Dogtanian (588974) on Friday September 04, 2009 @08:48AM (#29309865) Homepage

    Random I/O is essentially uncacheable.

    I'm sure that would come as a great surprise to anyone who ever implemented a virtual memory system.

    His flaw lies in assuming- or implying- that most I/O *is* random.

  • by KC7JHO (919247) on Friday September 04, 2009 @08:52AM (#29309897) Homepage
    Ya really, no one will ever need more than 64k, right?
  • Re:Not so sure (Score:5, Insightful)

    by Z00L00K (682162) on Friday September 04, 2009 @08:53AM (#29309903) Homepage

    Whoever defined parent as troll must be weird.

    That said - I'm more worrying about the consideration about exhausted flash on the motherboard. Have all avenues actually been considered here, or is that a built-in best before date that new motherboards will have?

  • Re:why flash? (Score:3, Insightful)

    by Profane MuthaFucka (574406) <busheatskok@gmail.com> on Friday September 04, 2009 @08:54AM (#29309909) Homepage Journal
    Exactly. I already have a disk cache. This solution is redundant. Also, this solution doesn't get me away from the mechanical spinning noisy hot slow thing which fails too often.
  • Re:Bullshit (Score:5, Insightful)

    by John_Booty (149925) <johnbooty@b[ ]yp ... g ['oot' in gap]> on Friday September 04, 2009 @08:54AM (#29309911) Homepage

    Random I/O is essentially uncacheable.

    I'm sure that would come as a great surprise to anyone who ever implemented a virtual memory system.

    -jcr

    You're both right.

    The problem here is that "random I/O" can have at least two subtly different meanings. In the very old days they talked about random I/O as opposed to sequential (ie, tape) I/O. In that sense, yes, random I/O is often extremely cacheable, as you say. That's why virtual memory works, as system files, drivers, commonly-used applications, and so forth are accessed much more often than other daa.

    "Random I/O" can also refer to I/O that does not follow any real pattern - ie, a 50GB database in which all records are accessed about equally as often. This kind of I/O is not really cacheable, practically speaking. Unless you can cache the entire thing.

    What's the correct terminology for the second kind of random I/O? Random I/O with very low locality?

  • by camperdave (969942) on Friday September 04, 2009 @08:54AM (#29309915) Journal
    Consumer electronics store shelves are packed with terabyte sized hard drives. 4TB may be a little ahead of the curve, but not by much.
  • by Truekaiser (724672) on Friday September 04, 2009 @08:57AM (#29309945)

    It's called planed obsolescence. Due to the amount of read/write cycles on the i/o and the fact all flash memory is limited to a certain number. If they integrate this into the motherboard it means that the motherboard has a expiration date they can predict and design around. In such a situation the flash will mostly last about a year or 2.

    Speed has nothing to do with it because your /still/ bound to the data flush to the disk drive which will be much slower. data security between crashes seems to only be a side benefit.

  • Re:Bullshit (Score:3, Insightful)

    by A beautiful mind (821714) on Friday September 04, 2009 @09:01AM (#29309973)
    It's more the case of hedging characteristics against each other.

    1. SSDs handle random I/O extremely well compared to traditional harddisks.
    2. Braidwood is essentially a small, cheap, 8-16GB flash based cache.
    3. If Braidwood is transparent to the OS, it will have a hard time guessing what to put in the cache, because a lot of the I/O on a desktop/laptop is random, but the issue with caching the non-random part is that most OSs do caching themselves for frequently accessed parts of the disk. This means that for a transparent caching solution like that it is very hard to tell the difference between a frequently accessed piece of executable data and random I/O, since in both cases, it only gets accessed once per startup/shutdown cycle, for frequently accessed stuff it is already cached in memory, for random I/O, it is simply never requested again for a long time. So to make this caching work the flash thing either needs OS level support or very sophisticated statistics collection specifically tuned for keeping track of patterns across reboots and providing a caching solution for startup basically.
  • Re:why flash? (Score:4, Insightful)

    by DigiShaman (671371) on Friday September 04, 2009 @09:39AM (#29310311) Homepage

    Well hopefully, there will be a BIOS option to disable this hardware in case a failure shows up. Better yet, have them removable much like the old COAST (Cache On A STick) modules of the first gen Pentium days.

  • by pmontra (738736) on Friday September 04, 2009 @09:59AM (#29310519) Homepage

    I'd answered yes, but one doesn't control the fsync behavior of every application running on his/her system and the OS/file system can take a lot of time (even tens of seconds or more) before deciding to commit changes to the hard disk. Furthermore, a fsync may take seconds to complete and disaster can strike at any time.

    There was quite a commotion about those matters when somebody filed a data loss bug [launchpad.net] against the new Linux ext4 file system in January 2009. It turned out that ext3 commits changes at least every 5 seconds and ext4 does it less often. Some applications that got lucky with Linux crashes on ext3 exposed their poor design when running on ext4. Comments #45 and #54 in the linked page are quite explanatory.

    By the way that was a sloppy application coding problem (if you want your data safe on HD you fsync and wait as long as it takes to write them down) but they eventually issued some patches to the file system code to mitigate it.

  • Re:Not so sure (Score:3, Insightful)

    by Hognoxious (631665) on Friday September 04, 2009 @10:10AM (#29310667) Homepage Journal

    That's about 68 erases per sector PER DAY if I want my new SSD to last 4 years.

    TFA says it'll be used for an I/O cache, so I supsect it'll get hit slightly more often than that.

  • Re:why flash? (Score:3, Insightful)

    by mayko (1630637) on Friday September 04, 2009 @10:26AM (#29310881)
    Of course, because planned obsolescence has never been an issue before... especially with a corporation full of engineers.
  • Re:Not so sure (Score:5, Insightful)

    by toppavak (943659) on Friday September 04, 2009 @10:29AM (#29310913)
    Didn't they already try this with their turbocache stuff? I seem to recall the general consensus [anandtech.com] being that it doesn't really offer any remarkable benefits. Regardless of how fast the cache is, eventually you run apps or open files that can't live on it 24x7 and you're going to revert to magnetic HD performance limits. This might improve some battery life and performance for some apps, but its not going to give you the across-the-board speed and battery life boosts that SSDs do. While this would certainly result in a better experience for the average computer user, I feel like its going to be relegated as a middle-ground between HDDs and SDDs, augmenting the low end, but by no means obsoleting the high-end.
  • Re:Not so sure (Score:3, Insightful)

    by Hal_Porter (817932) on Friday September 04, 2009 @10:30AM (#29310919)

    Actually if it's a cache the size could just reduce as the flash wears out.

  • What nonsense (Score:5, Insightful)

    by PopeRatzo (965947) * on Friday September 04, 2009 @10:51AM (#29311177) Homepage Journal

    Is this the latest FUD? That if a company brings out a successful product that's priced cheaply it'll "erode the market"?

    How did the :"market" become so sacred that it must be preserved at all costs by keeping prices high? It's really funny the crap that'll come out of an MBA's mouth. He'll be all for "free markets" until someone comes along with a better product and then he'll start to squeal that the "market" is under siege.

    Good for Intel.

  • Re:Not so sure (Score:3, Insightful)

    by gabebear (251933) on Friday September 04, 2009 @11:15AM (#29311461) Homepage Journal
    If a 16GB Brainwood used a revolving cache, where any data not already in flash was read from disk and written over the oldest data in flash, then you would see very few erase cycles per day per block. You would need to do more than 16GB of disk IO to eat up one of the 100K erase cycles.

    With intelligent cache techniques you should be able to get the erase-cycle count for each block very low.
  • Re:Not so sure (Score:3, Insightful)

    by Fweeky (41046) on Friday September 04, 2009 @12:12PM (#29312327) Homepage

    I would expect they'd be using some sort of slot, something like this [scan.co.uk]. Motherboard manufacturers aren't exactly going to be thrilled at the idea of putting some yet more expensive components on there, but they might be happy to hook up a small ZIF socket thing like some of them do with CF.

    Intel actually had some weird ZIF connected SSD's on there a while ago on preorder, but they appear to have disappeared.

    Either way, it's nice to see some hybrid storage stuff which isn't ZFS L2ARC (zpool add tank cache /dev/my_ssd -> tank now has an 80GB SSD for fs cache). Kind of surprised it hasn't been done in software elsewhere really; you'd think there would be some Linux developer who found the idea compelling, or even Microsoft wanting to extend ReadyBoost to its logical conclusion.

  • Re:Not so sure (Score:3, Insightful)

    by oldspewey (1303305) on Friday September 04, 2009 @12:14PM (#29312345)
    One would hope these motherboards would come with a BIOS option to erase the onboard flash.
  • by Gothmolly (148874) on Friday September 04, 2009 @01:08PM (#29313053)

    Just add the extra 32GB of RAM to the OS, and let it more intelligently manage the data.

  • Re:why flash? (Score:3, Insightful)

    by Profane MuthaFucka (574406) <busheatskok@gmail.com> on Friday September 04, 2009 @03:06PM (#29315335) Homepage Journal

    It's that time of year. The one time every annum when I respond graciously to a request without becoming belligerent. So there you go.

"A great many people think they are thinking when they are merely rearranging their prejudices." -- William James

Working...