Observations on memory reliability

I'm a member of

Quicksearch

Codenews Search

Disclaimer

The individual owning this blog works at Sun Microsystems GmbH in Germany, a subsidiary of Oracle. The opinions expressed here are his own, are not necessarily reviewed in advance by anyone but the individual author, and neither Oracle nor any other party necessarily agrees with them.

Navigation

< links for 2009-10-11 | 7,717,511 tpmC >

Observations on memory reliability

Sunday, October 11. 2009

Robin Harris points to an interesting study about DRAM failures in his blog storagemojo (BTW: Robins blog is really a great read). He points to the paper "DRAM Errors in the Wild: A Large-Scale Field Study"( written by Bianca Schroeder (University of Toronto), Eduardo Pinheiro and Wolf-Dietrich Weber (both from Google)) in his article.

Some of the numbers are really terrifying: 4.15% unrecoverable errors for of of the platforms are much more then i had thought and i'm somewhat conservative in my thinking how far i trust hardware. Furthermore hard errors (as in "bit permanently flipped and put it to the trashbin") are vastly more common reasons for errors as most people think.

As a sidenote: After the discussion about DRAM prices in the M3000 i've got some flak because of memory prices at different quality and got many comments "there never failed a dimm at my home pc". But given the point that Google is said to use cheaper hardware and the amount of errors (especially the unrecoverable ones) there may be a point behind the fixation of Sun in regard of memory quality

Posted by Joerg Moellenkamp in English, Technology, The IT Business at 20:48 | Comments (5) | Trackbacks (0)
View as PDF: This entry | This month | Full blog

Trackbacks

Trackback specific URI for this entry

No Trackbacks

Comments

Display comments as (Linear | Threaded)

The study's interesting, but drawing any conclusions is difficult as it doesn't say what memory Google buys.

There is a suggestion (without any evidence given, so...) that Google buys RAM in massive bulk that's failed mfr QA, but for absolute peanuts. Google then check the RAM themselves.

Given Google's scale, that could actually work out.

But it skews the findings of that paper a bit.

Read the discussion at arstechnica on the story.

#1 Chris Ridd on 2009-10-11 21:51 (Reply)

yeah, the results show that the majority of errors appear on the same machines, those have a lot of errors, but there are enought of machines with ram that doesn't have any errors.
the conclusion is still valid, lots of bad ram out there and not only marketed to the "chinese homeland"...
something mentioned elsewhere is the conclusion that the not so good chips are used for cheap ecc modules because it doesnt matter that much there.

#1.1 uhum on 2009-10-12 02:06 (Reply)

Hmmm ... i don't know if this would really save that much money. AFAIK the chips are tested before soldering, so defunct chips wouldn't get on the PCB. And a defunct PCB is often a total loss and you could just desolder the chips.

It's just an assumption, but: When google knocks at your door and says "I want xy Petabyte RAM" you get pretty competitive prices without buying the trash bin.

Dont't know how much truth is behind this, but i don't think that they would publish such an paper when they know that their DIMMS were the ones left ofter after sweeping the fab

#1.2 Jörg+M. (Homepage) on 2009-10-12 06:54 (Reply)

a once-per-hour to once-per-day error
rate in 8% of DIMMs is quite huge imho.

#2 Bro on 2009-10-12 10:42 (Reply)

Very interesting article, thanks for sharing.

#3 Sue Célibataire (Homepage) on 2009-10-14 11:08 (Reply)

Add Comment

Name
Email
Homepage
In reply to
Comment	E-Mail addresses will not be displayed and will only be used for E-Mail notifications. To prevent automated Bots from commentspamming, please enter the string you see in the image below in the appropriate input box. Your comment will only be submitted if the strings match. Please ensure that your browser supports and accepts cookies, or your comment cannot be verified correctly. Enter the string from the spam-prevention image above: Standard emoticons like :-) and ;-) are converted to images. Enclosing asterisks marks text as bold (word), underscore are made via _word_.
	Remember Information? Subscribe to this entry

View as PDF: This entry | This month | Full blog

Competition entry by David Cummins powered by Serendipity v1.0

Links in this article

The LKSF book

The book with the consolidated Less known Solaris Tutorials is available for download here

Twitterfeeds

twitter.com/c0t0d0s0
@ihsandogan i didn't had it at that moment .... and just a GSM data line

twitter.com/codenews
6932590 zdb -vvv causes core dump http://bit.ly/bHwUp9

twitter.com/SunPatches
125332-09 - JDS 3: Macromedia Flash Player Plugin Patch. Available for SPARC since Mar/15/10. http://bit.ly/au3wfA

twitter.com/SolPatchesX86
137148-06 - SunOS 5.10_x86: libexpat patch. Available since Mar/15/10. http://bit.ly/aNZcLt

twitter.com/SolPatchesSPARC
137147-06 - SunOS 5.10: libexpat patch. Available since Mar/15/10. http://bit.ly/cZmvyt