lundi 22 mars
Accueil :: Dépêches :: Entretiens :: Journaux :: Forums :: Sondages :: Suivi :: Statistiques :: Contact :: Plan

Liens connexes

Dépêche modérée par

Dépêche éditée par

: Une analyse précieuse sur la fiabilité de la mémoire vive DRAM

Posté par patrick_g (page perso, ). Modéré le 09 octobre 2009.
32
Après son étude sur la fiabilité des disques durs en février 2007 (voir l'excellent journal d'Herodiade à ce sujet auquel le titre de cette dépêche fait allusion), les ingénieurs de Google ont fait paraître une étude similaire mais qui porte cette fois sur la mémoire vive.

C'est lors du congrès Sigmetrics/Performance 2009 que cette étude a été présentée par deux ingénieurs de Google et une chercheuse de l'université de Toronto (on retrouve les mêmes noms que pour l'article sur les disques durs : Eduardo Pinheiro, Wolf-Dietrich Weber et Bianca Schroeder).

Comme pour le papier précédent, l'intérêt de ces données réside dans le fait qu'elles s'appuient sur l'expérience réelle des gigantesques fermes de serveurs de Google.
Il ne s'agit pas d'une petite étude en laboratoire mais bien de statistiques se basant sur plusieurs millions de barrettes mémoire et une durée de fonctionnement de deux ans et demi !

> Lire la suite (52 commentaires, moyenne: 5).   [dépêche : 3469 caractères]

Alors quelle est la grande nouveauté qu'apporte cette étude ?
Et bien la réponse n'est pas très rassurante puisqu'il s'avère que les erreurs des mémoires DRAM sont bien plus nombreuses que prévu.

Alors que les études précédentes laissaient penser à un taux d'erreur situé entre 200 et 5000 par mégabits (le taux d'erreur est le FIT pour Failure In Time par milliard d'heures) les chercheurs ont découvert que le taux observé était plus de l'ordre de 25000 à 75000. C'est quand même 25 à 375 fois plus que prévu !

Bien entendu les barrettes de chez Google sont protégées par des codes correcteurs d'erreurs ECC mais ce système n'est pas infaillible. Dans la plupart des cas ces codes ECC corrigent l'erreur quand elle affecte un seul bit et se contentent de détecter l'erreur sans pouvoir la corriger quand elle concerne deux bits (SECDED pour single error correct double error detect).
L'étude montre que plus de 30% des machines rencontrent une erreur DRAM corrigeable par an et 1,3% des machines rencontrent une erreur non corrigeable par an (l'erreur non corrigeable se solde le plus souvent par un crash).

Après cette constatation d'un important taux d'erreur il faut tenter d'obtenir des corrélations afin de découvrir les facteurs aggravants.


En résumé :
En conclusion
Les auteurs de l'étude soulignent le rôle absolument crucial des codes de corrections des erreurs. Ils préconisent même l'utilisation d'algorithmes plus avancées que le simple schéma SECDED puisqu'ils montrent que les machines équipées de la technologie Chipkill ont entre 4 et 10 fois moins d'erreurs non corrigeables que celles équipées de simples barrettes ECC.
Ce taux réduit d'erreur obtenu grâce à la technologie Chipkill (0,22% d'erreurs non corrigeables par barrette et par an) n'est toutefois pas suffisamment bas pour dispenser les centres de données d'avoir des applications tolérantes aux crashs.

Sachant que les ordinateurs du grand public n'ont même pas de mémoire ECC, ça laisse rêveur...

Cette discussion est archivée, il n'est plus possible de laisser des commentaires.

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.

Chipotage

Posté par Matthieu Lagouge (Jabber id, page perso, ) le 09/10/2009 à 10:06. (lien). Évalué à 10.

Tu parles d'erreur matérielle pour une barrette défectueuse et d'une erreur logicielle pour un "rayon cosmique".

Outre le fait que tu ne mentionnes pas les effets bénéfiques des rayons cosmiques (transformer les gens beaux, forts et intelligents en super-héros), je me permettrais de dire qu'il serait sans doute plus pertinent d'utiliser les termes suivants:
-erreur d'origine intrinsèque: due à une défaillance de la barrette
-erreur d'origine extrinsèque: due à un facteur extérieur (rayon cosmique ou toute autre perturbation électromagnétique, choc mécanique, etc.)

C'était ma géniale contribution du vendredi.

Bon week-end (au cas où je ne reviendrais pas troller un peu plus tard...)

correction d'erreur linux vs windows

Posté par ochonpaul () le 09/10/2009 à 11:15. (lien). Évalué à 5.

Anecdote à propos de correction d'erreur:
Recemment, on m'a apporté un pc portable sous windows xp qui faisait un ecran bleu pendant le boot . J'ai alors tenté de reinstaller win xp : pareil , ecran bleu à un moment ou un autre de l'install (pas toujours le meme). J'ai essayé plusieurs disques d'install:pareil. J'ai alors changé la ram, mis un autre disque dur: toujours pareil.
Autre test avec Memtesk (disque de boot de test qui semble être du windows ): le test de la ram commence bien, puis crash apres quelques minutes.

Là dessus, je boote avec Mandriva one 2009, et là , plus de probleme. Je l'ai installé, et le pc marche depuis 2 mois.

Je suppose qu'il y avait un probleme d'ecriture par la carte mère sur certaines zones de ram (voire d'un autre peripherique ), probleme detecté par linux et pas par windows. (pb de carte mère car la ram a été changée sans effet).
Cette hypothèse est elle plausible?

Une mauvaise expérience dûe à une barrette de Ram défectueuse.

Posté par Grasyop () le 09/10/2009 à 11:45. (lien). Évalué à 10.

De la mémoire vive défectueuse peut avoir d'autres conséquences qu'un simple plantage de l'ordi, j'en ai un jour fait l'expérience. J'avais acheté une barrette de Ram (sans marque) et l'avais ajoutée à mon ordi. Quelques temps après, mon système plante, apparemment à cause d'erreurs sur le disque dur. Mes tentatives de correction du système de fichiers semblent empirer les choses. Je démarre alors sur une autre partition, sur un autre disque dur, contenant une sauvegarde du précédent. Pas de chance : il se met à flancher lui aussi ! J'étais en train de perdre à la fois mes données normales et leur sauvegarde, pourtant situées sur des disques durs distincts physiquement ! J'ai alors pensé à faire un Memtest : c'était la nouvelle barrette de Ram qui était défectueuse ! Cette barrette avait dû corrompre les données transitant par elle, et ainsi corrompre les deux systèmes de fichiers de mes deux disques. Heureusement, j'ai pu en sauver un des deux, et au final je n'ai donc pas perdu mes données.
Moralité 1 : se méfier de la Ram. Moralité 2 : la santé de deux disques durs n'est pas indépendante si on utilise leurs données à travers le même système de base (mémoire vive, processeur... ).

ECC logiciel?

Posté par GTof (Jabber id, ) le 09/10/2009 à 12:40. (lien). Évalué à 5.

Sachant que les ordinateurs du grand public n'ont même pas de mémoire ECC, ça laisse rêveur...

Est ce envisageable de simuler une mémoire avec code correcteur d'erreur au niveau logiciel (par exemple le compilateur ou l'interprète rajouterait une couche d'abstraction de la ram avec ECC) ?

dreuk

Posté par tankey () le 09/10/2009 à 12:42. (lien). Évalué à 9.

Avec une mémoire aussi fragile, j'interdis à mes ordinateurs de fumer et de picoler, dès ce soir !

HWPOISON

Posté par Victor STINNER (Jabber id, page perso, ) le 09/10/2009 à 22:56. (lien). Évalué à 1.

Plus la quantité de mémoire augmente, plus le taux d'erreur augmente. Andi Kleen et Fengguang Wu ont écrit un patch "HWPOISON" qui permet de rattraper les erreurs "soft" et "hard" de la mémoire.
http://lwn.net/Articles/348886/

Cet article est fort intéressant. Mais si j'ai bien compris, il faut le processeur associé, genre un Xeon Nehalem-EX et son architecture Machine Check Abort (MCA).

En même temps tout ça ne sert à rien

Posté par the_glu () le 10/10/2009 à 20:54. (lien). Évalué à 2.

Si on n'a pas de barque :]


*S'enfuit vers la porte*

Revenir en haut de page

Run by Team LinuxFr.org

Cette page a été générée par Templeet en 0.1926s (dont 0.0254 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Faire un don !