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 ! 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é :
- Il y a une forte corrélation entre le début des problèmes et le risque d'erreurs ultérieures sur une même barrette. Si une mémoire est victime d'une erreur corrigeable alors les chances d'en rencontrer une autre dans le même mois sont entre 13 et 228 fois plus élevées que pour une barrette lambda (et entre 9 et 400 fois pour une erreur non corrigeable).
- Il y a une corrélation significative entre le taux d'erreur et l'âge des barrettes.
- Il n'y a pas de corrélation claire entre le taux d'erreur et la taille mémoire de la barrette (1 Go, 2 Go ou 4 Go) ou entre le taux d'erreur et la technologie employée (DDR, DDR2, FBDIMM). L'influence de la température (dans la limite des variations des centres de données Google) semble également assez faible.
- On observe une forte corrélation entre le taux d'erreur et le taux d'utilisation de la machine (la charge du processeur et la quantité d'allocation mémoire).
- Les erreurs matérielles (une cellule endommagé définitivement) sont bien plus fréquentes que les erreurs logicielles (un rayon cosmique qui se baladait par là et qui change aléatoirement une cellule).
Aller plus loin
- DRAM Errors in the Wild: A Large-Scale Field Study (137 clics)
- Un résumé sur Arstechnica (34 clics)
- Le journal d'Herodiade sur les disques durs (60 clics)
# Chipotage
Posté par Maclag . Évalué à 10.
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...)
[^] # très pertinent!!
Posté par turanga leela . Évalué à 2.
Pour ajouter quand même ma contribution à cette dépêche, je dirai que si l'erreur est humaine alors le bug est son équivalent en informatique.
Du coup avec même du code proche de la perfection que celui de Linux, *BSD (ou d'autres systèmes exotiques que je ne connais pas) mais pas Windows pitié,
un système peut planter pour des raisons Hardware.
ça rétablit un peu l'équilibre entre l'Homme et la machine pour son taux d'erreur et/ou de connerie.
Enfin je voudrais adresser une question ouverte: je ne sais plus si c'est Freud qui a dit ça ou mon coiffeur,
mais il parait que l'être humain apprend en faisant des erreurs. N'est ce pas une voie de réflexion pour l'intelligence artificielle ??
[^] # Re: très pertinent!!
Posté par cram51 . Évalué à 6.
A méditer
[^] # Re: très pertinent!!
Posté par Laurent Cligny (site web personnel) . Évalué à 7.
http://v4.nosamislespeople.com/wp-content/uploads/2008/02/br(...)
[^] # Re: très pertinent!!
Posté par Larry Cow . Évalué à 10.
Enfin je voudrais adresser une question ouverte: je ne sais plus si c'est Freud qui a dit ça ou mon coiffeur,
mais il parait que l'être humain apprend en faisant des erreurs. N'est ce pas une voie de réflexion pour l'intelligence artificielle ??
Quand on dit qu'on apprend de ses erreurs, on apprend surtout à ne pas les refaire. Notre inconscient endure les conséquences - généralement peu agréables - de l'erreur et met tout en œuvre (souvent à notre insu) pour ne pas avoir à le re-subir.
Un ordinateur, il peut répéter un million de fois la même erreur sans sourciller. Et accessoirement, l'intelligence artificielle ne fantasme plus sur la "conscience artificielle" depuis bien longtemps (mettons, les années 80/90, et encore). De nos jours, on se concentre sur des heuristiques - certes efficaces, sur des astuces - certes élégantes, mais l'ensemble reste violemment non-bandant pour qui se prend à rêver en lisant Asimov.
[^] # Re: très pertinent!!
Posté par Thomas Douillard . Évalué à 5.
Je prendrai un exemple, la reconnaissance de forme "visuelle". On sait que la structure des neurones joue un rôle très important dans la reconnaissance de forme ... le genre d'astuces qu'un humain aurait pu utiliser, ou pourrait utiliser, pour faire faire de la reconnaissance de forme à une machine.
Pour reconnaitre une ligne droite par exemple, si je me trompe pas (vague souvenirs d'un article de vulgarisation) le cerveau analyse si il n'y a pas des neurone "alignés" par une astucieuse structure neuronale.
Cette information "il y a une ligne droite" peut être ensuite analysé et utilisée pour d'autres traitements conscients ou inconscients et faire une analyse à plus haut niveau de l'image.
Tout ça pour dire que ce n'est pas parce que les chercheurs utilisent des heuristiques et des astuces qu'ils ont arrêtés de fantasmer ^^ Ils ont juste arrêter de penser qu'on pourrait tout faire grâce à l'algorithme magique de l'intelligence.
Rien ne dit que ces informations "bas niveaux" ne pourront pas être combinée avec de l'apprentissage et des techniques de représentation de la connaissance et des techniques d'inférences, pour obtenir des machines dans le style de celle d'Asimov.
Et pourquoi pas en s'inspirant des mécanisme du cerveau humain que l'on connait de mieux en mieux ...
[^] # Re: très pertinent!!
Posté par zerkman (site web personnel) . Évalué à 10.
Ça alors, on en apprend tous les jours.
[^] # Re: très pertinent!!
Posté par Gniarf . Évalué à 5.
[^] # Re: très pertinent!!
Posté par Tony Ducrocq . Évalué à 2.
Enfin je voudrais adresser une question ouverte: je ne sais plus si c'est Freud qui a dit ça ou mon coiffeur,
mais il parait que l'être humain apprend en faisant des erreurs. N'est ce pas une voie de réflexion pour l'intelligence artificielle ??
Je dirais même que c'est déjà utilisé, ça s'appelle le Machine_learning et ça marche bien!
# correction d'erreur linux vs windows
Posté par ochonpaul . Évalué à 5.
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?
[^] # Re: correction d'erreur linux vs windows
Posté par dguihal . Évalué à 9.
A confirmer par un clone de patrick_g cependant
[^] # Re: correction d'erreur linux vs windows
Posté par ʭ ☯ . Évalué à 7.
J'ai eu le cas d'un portable avec 2Go qui avait des milliers d'erreurs à partir de 1,3Go, j'ai pris la solution bourrine : mem=1200M en paramètre noyau, et le portable n'utilise plus que les premiers 1,2 Go...-
Sinon, le problème Windows peut être plus triste : ce système avertirait plus tôt quand la RAM merde? De toute façon, je déconseille fortement de continuer à utiliser une barrette de RAM endommagée : comme cette étude le confirme, ça ira de pire en pire....
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
[^] # Re: correction d'erreur linux vs windows
Posté par Brice Goglin . Évalué à 5.
http://lkml.org/lkml/2009/9/16/240
[^] # Re: correction d'erreur linux vs windows
Posté par ckyl . Évalué à 10.
> Si, ca va être automatique. Sur les prochains Nehalems [...]
Toute l'histoire de l'informatique résumée en deux lignes...
[^] # Re: correction d'erreur linux vs windows
Posté par liberforce (site web personnel) . Évalué à 6.
(z'avez même un p'tit screenshot de l'affichage de memtest en mode badram).
Le principe : l'affichage badram fournit des couples adresse/masque des zones défectueuses. On fournit alors ces couples à la ligne de démarrage du kernel au niveau du bootloader. A noter qu'avec un trop grand nombre de couples, on se fait jeter. Ça m'est arrivé avec une barette, que j'ai pu utiliser sur une machine avec un bus mémoire plus lent, et là, 0 erreurs.
Un kernel équipé du patch badram va allouer ces zones mémoires défectueuses qu'on lui a signalé, sans les utiliser, pour qu'elles ne soient plus allouées à des programmes qui comptent s'en servir.
Il me semble aussi que depuis quelques versions Mandriva a désactivé le patch badram qui semble-t-il posait problème. Quelqu'un (pterjan) pourrait confirmer ? De même, j'ai trouvé que c'était un avantage fantastique (et écologique) de pouvoir faire fonctionner un système avec du matériel défectueux. Est-ce que quelqu'un sait si c'est faisable sous Windows ?
[^] # Re: correction d'erreur linux vs windows
Posté par Brice Goglin . Évalué à 4.
[^] # Re: correction d'erreur linux vs windows
Posté par __o . Évalué à 4.
On peut l'activer en ajoutant le paramètre memtest=X au boot, où X est le nombre de patterns à tester sur chaque block (si le kernel a été compilé avec CONFIG_MEMTEST).
[^] # Re: correction d'erreur linux vs windows
Posté par thedude . Évalué à 1.
Il fait un memtest au boot?
[^] # Re: correction d'erreur linux vs windows
Posté par __o . Évalué à 4.
[^] # Re: correction d'erreur linux vs windows
Posté par Etienne Bagnoud (site web personnel) . Évalué à 8.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: correction d'erreur linux vs windows
Posté par Olivier Serve (site web personnel) . Évalué à 7.
Du coup, il est possible, suivant où se situe l'erreur dans la plage d'adresses, qu'un système accepte de fonctionner jusqu'à un certain point alors que l'autre ne voudra rien entendre.
[^] # Re: correction d'erreur linux vs windows
Posté par Ronan BARZIC . Évalué à 4.
[^] # Re: correction d'erreur linux vs windows
Posté par Albert_ . Évalué à 5.
[^] # Re: correction d'erreur linux vs windows
Posté par hugo (site web personnel) . Évalué à 5.
[^] # Re: correction d'erreur linux vs windows
Posté par Krom1er . Évalué à 5.
Pour ma part, je pencherais plutot pour un probleme de CPU ou de chipset.
Le fait qu'un OS fonctionne et pas un autre pourrait venir d'instructions peu ou pas utilise dans un cas et pas dans l'autre (pas les meme drivers de chipset par ex).
Je doute fortement qu'un OS soit mieux a meme de gerer des problemes materiel qu'un autre, et ce, peu importe l'OS (mis a part solaris sur des SUNs, mais la c'est fait pour)
[^] # Re: correction d'erreur linux vs windows
Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . Évalué à 3.
« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
[^] # Re: correction d'erreur linux vs windows
Posté par ochonpaul . Évalué à 2.
Merci à tous pour les réponses.
[^] # Re: correction d'erreur linux vs windows
Posté par Anonyme . Évalué à 3.
je branche mon disque externe, et de temps en temps il disparraissait de son point de montage, un jour je me decide a faire un coup de dmesg suite a la disparition brutale et la j'ai droit a un joli message d'erreur :
...error...
maybe the usb cable ?
...
je change de cable usb et le probleme était resolu. snif j'en ai presque eu une larme à l'oeuil, linux a detecté un mauvais cable usb.
# Une mauvaise expérience dûe à une barrette de Ram défectueuse.
Posté par Grasyop . Évalué à 10.
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... ).
[^] # Re: Une mauvaise expérience dûe à une barrette de Ram défectueuse.
Posté par chuchunain (site web personnel) . Évalué à 7.
T'as le bonjour de JavaScript !
[^] # Re: Une mauvaise expérience dûe à une barrette de Ram défectueuse.
Posté par Zenitram (site web personnel) . Évalué à 2.
A ma connaissance, rien, un peu d'argumentation serait pas mal, car Google n'a donné aucun nom de marque.
De plus, les barrettes les plus chère ne sont pas forcement les moins pourrie, une petite étude est ici :
http://www.hardware.fr/html/articles/lire.php3?article=773&a(...)
Tu pourras même remarque que pour une même marque, les barrettes "value" ont un taux de retour moins élevé.
Bon, ça ne dit rien pour l'utilisation donnée par Google, mais ça donne déjà une idée sur la qualité en fonction de la marque et/ou value/haut de gamme.
S'enlever l'idée de la tête : les plus fiables ne sont pas forcement les plus chers!
Et sans preuve, les noname ne peuvent pas être dites moins fiables (oui, je n'ai jamais eu de problèmes avec mes nonames en 10 ans...), elles sont validé JEDEC donc bon...
Bref, qu'est-ce que te dit que le prix payé en plus vaut quelque chose en diminution d'emmerdes?
[^] # Re: Une mauvaise expérience dûe à une barrette de Ram défectueuse.
Posté par Antoine . Évalué à 10.
Elles n'ont pas le même public non plus, et les zozos overclockers qui achètent des barrettes "haut de gamme" ont tendance à les pousser dans leurs derniers retranchements.
(ils seront peut-être aussi plus du genre à lancer memtest régulièrement, alors que l'utilisateur lambda ne soupçonnera même pas un défaut de mémoire s'il a un plantage tous les mois)
En fait, concernant les barrettes noname, on peut faire une observation intéressante, liée à la réputation. Lorsqu'une compagnie A produit des chips ou barrettes qui se trouvent être défectueuses, il y a deux cas possibles :
- ces barrettes étaient vendues en "noname", la responsabilité se perd donc (sauf client très perfectionniste qui va essayer de retrouver des références sur Internet)
- ces barrettes étaient vendues sous la marque de la compagnie, et la réputation de la compagnie peut en souffrir (s'il y a beaucoup de cas)
Conclusion logique : une compagnie a intérêt à appliquer un processus qualité plus contraignant sur les barrettes vendues sous marque, que sur les barrettes vendues en noname, parce que c'est sur les premières que se fera la réputation (bonne ou mauvaise) de la compagnie.
[^] # marque de RAM
Posté par koopa . Évalué à 2.
On le retrouve dans les comparatifs
http://www.hardware.fr/articles/773-1/taux-pannes-composants(...)
[^] # Re: marque de RAM
Posté par Thierry Thomas (site web personnel, Mastodon) . Évalué à 7.
C'est du masochisme ?
[^] # Re: marque de RAM
Posté par BAud (site web personnel) . Évalué à 9.
"et on a moins de problème"
ou "et on n'a plus de problème"
de l'importance de la négation complète "ne... plus" à l'écrit ;-)
[^] # Re: Une mauvaise expérience dûe à une barrette de Ram défectueuse.
Posté par Manuel Vonthron (site web personnel) . Évalué à 2.
Que s'est-il passé en général lors des défauts RAM ? Freeze du serveur ? Données invalides ? Pas de conséquences ? Corruption du cluster ? ...
[^] # Re: Une mauvaise expérience dûe à une barrette de Ram défectueuse.
Posté par Grasyop . Évalué à 2.
[^] # Re: Une mauvaise expérience dûe à une barrette de Ram défectueuse.
Posté par _alex . Évalué à 2.
Memtest86 n'affichait pas d'erreur sur le coup, mais je l'ai laissé tourné.
Quand je suis revenu au bout de 3h, il y avait ça à l'écran :
http://img183.imageshack.us/img183/2586/freezez.jpg
-> une fois la RAM, et il n'y a plus jamais eu de problème.
[^] # Re: Une mauvaise expérience dûe à une barrette de Ram défectueuse.
Posté par Pierre Jarillon (site web personnel) . Évalué à 3.
Voici des résultats plus normaux lorsque memtest découvre des erreurs :
- http://pjarillon.free.fr/docs/memory-fail.jpg
- http://pjarillon.free.fr/docs/memory-fail2.jpg
- http://pjarillon.free.fr/docs/memtest-pey.jpg
# ECC logiciel?
Posté par GTof . Évalué à 5.
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) ?
[^] # Re: ECC logiciel?
Posté par ZeroHeure . Évalué à 5.
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
[^] # Re: ECC logiciel?
Posté par ʭ ☯ . Évalué à 3.
Il faudrait alors 200Mo de RAM pour un logiciel qui en utilise 100Mo...
L'ECC est plus intelligent : il utilise un code de correction d'erreur.
..... mais sur le fond, un point invalide l'idée : si l'erreur se fait dans la zone mémoire qui compare les lectures. Bref, il faudrait des machines avec un minimum d'ECC pour avoir une zone mémoire garantie qui servirait à vérifier le reste. Inutile, vu le coût en performances du tout.
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
[^] # Re: ECC logiciel?
Posté par neologix . Évalué à 1.
[^] # Re: ECC logiciel?
Posté par M . Évalué à 4.
Une autre idée : faire tourner le même algo plusieurs fois en utilisant des zones RAM différentes.
Si les résultats diffère c'est qu'il y a eu une erreur. Dans ce cas on peut prendre le résultat majoritaire.
En fait ca revient a faire un soft tolérant aux erreurs.
[^] # Re: ECC logiciel?
Posté par gilgam . Évalué à 5.
[^] # Re: ECC logiciel?
Posté par ʭ ☯ . Évalué à 5.
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
# dreuk
Posté par bubar🦥 (Mastodon) . Évalué à 9.
[^] # Re: dreuk
Posté par zerkman (site web personnel) . Évalué à 4.
[^] # Re: dreuk
Posté par Grunt . Évalué à 6.
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
# HWPOISON
Posté par Victor STINNER (site web personnel) . Évalué à 1.
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 . Évalué à 2.
*S'enfuit vers la porte*
[^] # Re: En même temps tout ça ne sert à rien
Posté par teoB . Évalué à 2.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.