Qu'est-ce que la mémoire ECC. Qu'est-ce que la RAM ECC ? RAM tamponnée - qu'est-ce que c'est? mémoire compatible ecc

A la question Expliquez ce qu'est le "support ECC" sur la RAM, donnée par l'auteur Alyonka la meilleure réponse est c'est une fonction de correction d'erreur. cette mémoire est placée sur les serveurs, car il leur est impossible de retarder, de s'éteindre ou de se surcharger en raison d'erreurs. pour un ordinateur personnel, ce n'est pas une chose nécessaire, même si c'est utile. si vous décidez d'en installer un pour vous-même, assurez-vous que votre carte mère prend en charge ce type de RAM avec ECC.
Source : ku

Réponse de Balayé par la pluie[gourou]
ECC (Error Correct Code) - détection et correction des erreurs (d'autres interprétations de la même abréviation sont possibles) - un algorithme qui a remplacé le "contrôle de parité". Contrairement à ce dernier, chaque bit est inclus dans plus d'une somme de contrôle, ce qui permet, en cas d'erreur sur un bit, de restituer l'adresse d'erreur et de la corriger. En règle générale, des erreurs sur deux bits sont également détectées, bien qu'elles ne soient pas corrigées. Pour implémenter ces capacités, une puce mémoire supplémentaire est installée sur le module et il devient 72 bits, contrairement aux 64 bits de données d'un module conventionnel. ECC est pris en charge par toutes les cartes mères modernes conçues pour les solutions de serveur, ainsi que par certains chipsets "à usage général". Certains types de mémoire (Registered, Full Buffered) ne sont disponibles que dans la version ECC. Il convient de noter que l'ECC n'est pas une panacée pour la mémoire défectueuse et est utilisé pour corriger les erreurs aléatoires, réduisant ainsi le risque de dysfonctionnements informatiques dus à des modifications accidentelles du contenu des cellules de mémoire causées par des facteurs externes tels que le rayonnement de fond.
Les modules de mémoire enregistrés sont recommandés pour une utilisation dans les systèmes nécessitant (ou prenant en charge) 4 Go ou plus de RAM. Ils sont toujours de 72 bits, c'est-à-dire qu'ils sont des modules ECC, et contiennent des puces de registre supplémentaires pour une mise en mémoire tampon partielle.
PLL-Phase Locked Loop - circuit de réglage automatique de la fréquence et de la phase du signal, sert à réduire la charge électrique sur le contrôleur de mémoire et à augmenter la stabilité lors de l'utilisation d'un grand nombre de puces de mémoire, est utilisé dans tous les modules de mémoire tamponnés.
Tamponné - module tamponné. En raison de la capacité électrique totale élevée des modules de mémoire d'aujourd'hui, leurs longs temps de "charge" entraînent des opérations d'écriture chronophages. Pour éviter cela, certains modules (généralement des DIMM à 168 broches) sont équipés d'une puce spéciale (tampon) qui stocke les données entrantes relativement rapidement, ce qui libère le contrôleur. Les modules DIMM tamponnés sont généralement incompatibles avec ceux sans tampon. Les modules partiellement tamponnés sont également appelés modules "enregistrés" et les modules entièrement tamponnés sont appelés "FB-DIMM". Dans ce cas, "sans tampon" fait référence à des modules de mémoire ordinaires sans fonctions de mise en mémoire tampon.
Parité - parité, modules avec parité, également parité. Un principe assez ancien de vérification de l'intégrité des données. L'essence de la méthode est que pour l'octet de données à l'étape d'enregistrement, une somme de contrôle est calculée, qui est stockée sous la forme d'un bit de parité spécial dans une puce séparée. Lorsque les données sont lues, la somme de contrôle est recalculée et comparée au bit de parité. S'ils correspondent, les données sont considérées comme authentiques, sinon un message d'erreur de parité est généré (entraînant généralement un arrêt du système). Les inconvénients évidents de la méthode incluent le coût élevé de la mémoire nécessaire pour stocker des bits de parité supplémentaires, la vulnérabilité aux doubles erreurs (ainsi que les faux positifs en cas d'erreur dans le bit de parité), l'arrêt du système même avec une erreur mineure (par exemple, dans une image vidéo). Actuellement non applicable.
SPD - une puce sur un module de mémoire DIMM qui contient toutes les données à ce sujet (en particulier, des informations sur la vitesse) nécessaires pour fournir fonctionnement normal. Ces données sont lues au stade de l'auto-test de l'ordinateur, bien avant le chargement du système d'exploitation, et vous permettent de configurer les paramètres d'accès à la mémoire même s'il existe différents modules de mémoire dans le système en même temps. Certaines cartes mères refusent de fonctionner avec des modules qui n'ont pas de puce SPD, mais ces modules sont maintenant très rares et sont principalement des modules PC-66.


Réponse de Mowgley[gourou]
vérification de la mémoire pour les erreurs

Si j'ai bien compris, ses arguments sont les suivants :

  1. Google n'a pas utilisé ECC lors de la construction de ses serveurs en 1999.
  2. La plupart des erreurs de RAM sont des erreurs systématiques et non aléatoires.
  3. Les erreurs de RAM sont rares car Matériel amélioré.
  4. Si la mémoire ECC était vraiment importante, alors elle serait utilisée partout, pas seulement dans les serveurs. Payer pour ce genre de matériel optionnel est clairement trop incertain.
Passons en revue ces arguments un par un :

1. Google n'a pas utilisé ECC en 1999

Si vous faites quelque chose simplement parce que Google l'a déjà fait, essayez :

A. Placez vos serveurs dans des conteneurs d'expédition.

Aujourd'hui, ils écrivent encore des articles disant que c'est une excellente idée, même si Google vient de lancer une expérience qui a été considérée comme un échec. Il s'avère que même les expériences de Google ne fonctionnent pas toujours. En fait, leur penchant notoire pour les "projets révolutionnaires" ("loonshots") signifie qu'ils ont plus d'expériences ratées que la plupart des entreprises. À mon avis, c'est un avantage concurrentiel important pour eux. Ne rendez pas cet avantage plus grand qu'il ne l'est en copiant aveuglément des expériences ratées.

B. Démarrer des incendies dans vos propres centres de données.

Une partie du message d'Atwood explique à quel point ces serveurs étaient incroyables :

Certains peuvent jeter un coup d'œil à ces premiers serveurs Google et voir le manque de professionnalisme concernant le risque d'incendie. Pas moi. Je vois ici une compréhension visionnaire de la façon dont le matériel à faible coût et prêt à l'emploi façonnera l'Internet moderne.

La dernière partie de ce qui a été dit est vraie. Mais dans la première partie, il y a une part de vérité. Lorsque Google a commencé à concevoir ses propres tableaux, une génération d'entre eux avait un problème de "croissance" ( ) qui provoquait un nombre non nul d'incendies.

Au fait, si vous allez sur le post de Jeff et que vous regardez la photo référencée dans le devis, vous verrez qu'il y a beaucoup de câbles de démarrage sur les cartes. Cela a causé des problèmes et a été corrigé dans la prochaine génération de matériel. Vous pouvez également voir un câblage plutôt bâclé, qui a également causé des problèmes et a également été rapidement corrigé. Il y avait d'autres problèmes, mais je vais les laisser comme un exercice pour le lecteur.

C. Créer des serveurs qui blessent vos employés

Les arêtes vives d'une génération de serveurs Google leur ont valu la réputation d'être "des lames de rasoir et de la haine".

D. Créez votre propre météo dans vos centres de données

Après avoir parlé aux employés de nombreuses grandes entreprises technologiques, il semble que la plupart des entreprises étaient tellement climatisées que des nuages ​​ou du brouillard se sont formés dans leurs centres de données. On pourrait appeler cela le plan calculé et sournois de Google pour reproduire la météo de Seattle afin de débaucher les employés de Microsoft. Alternativement, il pourrait s'agir d'un plan visant à créer littéralement "l'informatique en nuage". Ou peut être pas.

Veuillez noter que tout ce qui est indiqué par Google a essayé puis a changé. Faire des erreurs puis les corriger est courant dans toute organisation de développement qui réussit. Si vous idolâtrez la pratique de l'ingénierie, vous devriez au moins vous accrocher à la pratique moderne, et non à ce qui a été fait en 1999.

Lorsque Google a utilisé des serveurs non ECC en 1999, ils ont présenté un certain nombre de symptômes qui se sont finalement avérés être une corruption de la mémoire. Y compris un index de recherche qui a renvoyé des résultats pratiquement aléatoires dans les requêtes. Le mode de défaillance réel ici est instructif. J'entends souvent dire que l'ECC peut être ignoré sur ces machines car les erreurs dans les résultats individuels sont acceptables. Mais même si vous considérez que les erreurs aléatoires sont acceptables, les ignorer signifie qu'il existe un risque de corruption complète des données, à moins qu'une analyse minutieuse ne soit effectuée pour s'assurer qu'une erreur ne peut que légèrement fausser un résultat.

Dans des études menées sur systèmes de fichiers ah, il a été démontré à plusieurs reprises que, malgré les tentatives héroïques de créer des systèmes résistants à une seule erreur, il est extrêmement difficile de le faire. Essentiellement, chaque système de fichiers fortement testé peut connaître une défaillance majeure due à une seule erreur (). Je ne vais pas attaquer les développeurs de systèmes de fichiers. Ils sont meilleurs dans ce genre d'analyse que 99,9 % des programmeurs. C'est juste qu'il a été démontré à maintes reprises que le problème est si difficile que les gens ne peuvent pas raisonnablement en discuter, et un outil automatisé pour une telle analyse est encore loin d'être une simple pression sur un bouton. Dans son Warehouse Computer Handbook, Google traite de la détection et de la correction des erreurs, et la mémoire ECC est considérée comme la meilleure option lorsqu'il est évident que la correction des erreurs matérielles ( ) doit être utilisée.

Google a une excellente infrastructure. D'après ce que j'ai entendu sur l'infrastructure d'autres grandes entreprises technologiques, Google semble être le meilleur au monde. Mais cela ne signifie pas que vous devez copier tout ce qu'ils font. Même si seules leurs bonnes idées sont prises en compte, cela n'a aucun sens pour la plupart des entreprises de les copier. Ils ont créé un remplaçant pour le planificateur de hook de travail Linux qui utilise à la fois les informations d'exécution du matériel et les traces statiques pour leur permettre de tirer parti du nouveau matériel des processeurs de serveur Intel, permettant un partitionnement dynamique du cache sur les cœurs. Si vous l'utilisez sur tout leur matériel, Google économisera plus d'argent en une semaine que Stack Exchange n'en a dépensé sur toutes ses machines dans toute son histoire. Cela signifie-t-il que vous devez copier Google ? Non, à moins que vous n'ayez déjà été frappé par la manne du ciel, comme avoir votre infrastructure de base écrite en C++ hautement optimisé plutôt qu'en Java ou (à Dieu ne plaise) Ruby. Et le fait est que pour la grande majorité des entreprises, écrire des programmes dans un langage qui entraîne une diminution de 20 fois de la productivité est une décision parfaitement raisonnable.

2. La plupart des erreurs de RAM sont des erreurs systématiques

L'argument contre ECC reproduit la section suivante de l'étude d'erreur DRAM (emphase ajoutée par Jeff):
Notre étude a plusieurs résultats principaux. Premièrement, nous avons constaté qu'environ 70 % des pannes de DRAM sont des pannes répétitives (par exemple, permanentes), tandis que seulement 30 % sont des pannes intermittentes (intermittentes). Deuxièmement, nous avons constaté que les grandes pannes multi-bits, telles que les pannes qui affectent une ligne, une colonne ou un bloc entier, représentent plus de 40 % de toutes les pannes de DRAM. Troisièmement, nous avons constaté que près de 5 % des pannes de DRAM affectent les circuits au niveau de la carte, tels que les lignes de données (DQ) ou de porte (DQS). Enfin, nous avons constaté que la fonction Chipkill réduisait la fréquence des pannes système causées par des pannes de DRAM par un facteur de 36.

La citation semble quelque peu ironique, car elle ne semble pas être un argument contre ECC, mais un argument pour Chipkill - une certaine classe ECC. Cela mis à part, le message de Jeff indique que les erreurs systématiques sont deux fois plus fréquentes que les erreurs aléatoires. Le message indique ensuite qu'ils exécutent memtest sur leurs machines lorsque des erreurs systématiques se produisent.

Premièrement, le rapport 2:1 n'est pas assez grand pour simplement ignorer les erreurs aléatoires. Deuxièmement, le message implique la conviction de Jeff que les erreurs systématiques sont essentiellement immuables et ne peuvent pas apparaître après un certain temps. Ce n'est pas vrai. L'électronique s'use de la même manière que les appareils mécaniques s'usent. Les mécanismes sont différents, mais les effets sont similaires. En effet, si l'on compare l'analyse de fiabilité des puces à d'autres types d'analyse de fiabilité, on constate qu'elles utilisent souvent les mêmes familles de distributions pour la modélisation des défaillances. Troisièmement, le raisonnement de Jeff implique qu'ECC ne peut pas aider à détecter ou à corriger les bogues, ce qui est non seulement faux, mais contredit directement la citation.

Alors, à quelle fréquence allez-vous exécuter memtest sur vos machines pour tenter de détecter ces erreurs système, et combien de perte de données êtes-vous prêt à supporter ? L'une des principales utilisations de l'ECC n'est pas de corriger les erreurs, mais de signaler les erreurs afin que le matériel puisse être remplacé avant qu'une « corruption silencieuse » ne se produise. Qui accepterait de tout fermer sur la machine tous les jours pour lancer memtest ? Ce serait beaucoup plus cher que d'acheter simplement de la mémoire ECC. Et même si vous pouviez me convaincre d'exécuter un test de mémoire, memtest ne trouverait pas autant d'erreurs que l'ECC.

Lorsque je travaillais pour une entreprise disposant d'un parc d'environ un millier de machines, nous avons remarqué que nous rencontrions d'étranges échecs de vérification de l'intégrité des données, et après environ six mois, nous avons réalisé que les pannes sur certaines machines étaient plus probables que d'autres. Ces échecs étaient assez rares (peut-être quelques fois par semaine en moyenne), il a donc fallu beaucoup de temps pour accumuler des informations et comprendre ce qui se passait. Sans en connaître la cause, l'analyse des journaux pour voir si les erreurs étaient causées par des basculements d'un seul bit (avec une probabilité élevée) n'était pas non plus triviale. Nous avons eu la chance que, comme effet secondaire du processus que nous utilisions, les sommes de contrôle soient calculées dans un processus séparé sur une machine différente à des moments différents, de sorte qu'un bogue ne puisse pas corrompre le résultat et propager cette corruption à la somme de contrôle.

Si vous essayez simplement de vous protéger avec des sommes de contrôle en mémoire, il y a de fortes chances que vous effectuiez une opération de somme de contrôle sur des données déjà corrompues et que vous obteniez la somme de contrôle correcte des mauvaises données, à moins que vous ne fassiez des calculs vraiment sophistiqués. qui donnent leurs propres sommes de contrôle. Et si vous êtes sérieux au sujet de la correction d'erreurs, vous utilisez probablement encore ECC.

Quoi qu'il en soit, après avoir terminé l'analyse, nous avons constaté que memtest ne pouvait détecter aucun problème, mais le remplacement de la RAM sur de mauvaises machines entraînait une diminution du taux d'erreur d'un à deux ordres de grandeur. La plupart des services n'ont pas le type de sommes de contrôle que nous avions ; ces services écriront simplement silencieusement les données corrompues dans le stockage persistant et ne verront pas le problème jusqu'à ce que le client se plaigne.

3. En raison du développement du matériel, les erreurs sont devenues très rares.

Les données du message ne suffisent pas pour une telle déclaration. Notez qu'à mesure que l'utilisation de la RAM augmente et continue d'augmenter de manière exponentielle, les pannes de RAM doivent diminuer à un rythme exponentiel plus élevé pour réduire réellement la fréquence de corruption des données. De plus, à mesure que les puces continuent de devenir plus petites, les cellules deviennent plus petites, ce qui rend les problèmes d'usure discutés au deuxième point plus pertinents. Par exemple, avec la technologie 20 nm, un condensateur DRAM peut accumuler environ 50 électrons, et ce nombre sera moindre pour la prochaine génération de DRAM tout en continuant à diminuer.

Autre remarque : lorsque vous payez pour ECC, vous ne payez pas seulement pour la mémoire ECC - vous payez pour des pièces (processeurs, cartes) de meilleure qualité. Cela peut facilement être vu avec les taux de panne de disque, et j'ai entendu beaucoup de gens le remarquer dans leurs observations personnelles.

Pour citer des recherches accessibles au public, pour autant que je m'en souvienne, le groupe d'Andrea et Ramsey a publié l'article SIGMETRICS il y a quelques années, qui montrait qu'un lecteur SATA était 4 fois plus susceptible d'échouer en lecture qu'un lecteur SCSI, et 10 fois plus susceptible d'avoir caché la corruption des données. . Ce rapport a été maintenu même en utilisant des disques du même fabricant. Il n'y a aucune raison particulière de penser que l'interface SCSI devrait être plus fiable que l'interface SATA, mais il ne s'agit pas de l'interface. Nous parlons d'acheter des composants serveur hautement fiables par rapport à ceux des clients. Peut-être n'êtes-vous pas particulièrement intéressé par la fiabilité du disque, car vous avez tout sur les sommes de contrôle et les dommages sont faciles à détecter, mais certains types de violations sont plus difficiles à détecter.

4. Si la mémoire ECC était vraiment importante, alors elle serait utilisée partout, pas seulement dans les serveurs.

Pour paraphraser légèrement cet argument, nous pouvons dire que "si cette caractéristique était vraiment importante pour les serveurs, alors elle serait également utilisée dans les non-serveurs". Vous pouvez appliquer cet argument à pas mal de matériel serveur. En fait, c'est l'un des problèmes les plus frustrants auxquels sont confrontés les principaux fournisseurs de cloud.

Ils ont suffisamment d'effet de levier pour obtenir la plupart des composants au bon prix. Mais la négociation ne fonctionnera que s'il y a plus d'un fournisseur viable.

L'un des rares domaines où il n'y a pas de concurrents viables est la production d'unités centrales de traitement et d'accélérateurs vidéo. Heureusement pour les grands fournisseurs, ils n'ont généralement pas besoin d'accélérateurs vidéo, ils ont besoin de beaucoup de processeurs - c'est depuis longtemps le cas. Les vendeurs de processeurs ont tenté à plusieurs reprises d'entrer sur le marché des serveurs, mais chacune de ces tentatives comportait toujours des défauts fatals dès le début, ce qui rendait évident qu'elle était vouée à l'échec (et ce sont souvent des projets qui nécessitent au moins 5 ans, c'est-à-dire qu'il fallait passer beaucoup de temps sans confiance dans le succès).

Les efforts de Qualcomm ont fait beaucoup de bruit, mais quand je parle à mes contacts chez Qualcomm, ils me disent tous que la puce en cours de fabrication est essentiellement destinée aux tests. C'est arrivé parce que Qualcomm avait besoin d'apprendre à fabriquer une puce de serveur à partir de toutes les personnes qu'il avait débauchées d'IBM, et que la prochaine puce serait la première qui pourrait, espérons-le, être compétitive. J'ai de grands espoirs pour Qualcomm, ainsi que pour les efforts d'ARM pour fabriquer de bons composants de serveur, mais ces efforts n'ont pas encore donné le résultat escompté.

L'inadéquation presque complète des options ARM (et POWER) actuelles (à part les options hypothétiques pour l'impressionnante puce ARM d'Apple) pour la plupart des charges de travail de serveur en termes de performances par dollar de coût total de possession (TCO) est un sujet un peu hors des sentiers battus. , donc je vais laisser ça pour l'instant. une autre publication. Mais le fait est qu'Intel a une position sur le marché qui peut obliger les gens à payer un supplément pour les fonctionnalités du serveur. Et Intel le fait. De plus, certaines fonctionnalités sont vraiment plus importantes pour les serveurs que pour appareils mobiles avec plusieurs gigaoctets de RAM et un budget énergétique de plusieurs watts, les appareils mobiles qui sont toujours censés planter et redémarrer périodiquement.

Conclusion

Dois-je acheter de la RAM ECC ? Cela dépend de beaucoup de choses. Pour les serveurs, c'est probablement une bonne option compte tenu des coûts. Il est cependant très difficile de faire une analyse coûts / avantages, car il est assez difficile de déterminer le coût de la corruption latente des données ou le coût du risque de perdre six mois du temps d'un développeur à traquer les plantages intermittents, pour découvrir qu'ils sont causés par utilisation de la mémoire non ECC.

Pour les ordinateurs de bureau, je suis également un partisan de l'ECC. Mais si vous ne faites pas de sauvegardes régulières, il est alors plus utile pour vous d'investir dans des sauvegardes régulières que dans la mémoire ECC. Et si vous avez sauvegardes sans ECC, vous pouvez facilement écrire des données corrompues sur le stockage principal et répliquer ces données corrompues sur la sauvegarde.

Merci à Prabhakar Ragda, Tom Murphy, Jay Weiskopf, Leah Hanson, Joe Wilder et Ralph Corderoy pour les discussions/commentaires/corrections. Aussi, merci (ou peut-être pas merci) à Leah de m'avoir convaincu d'écrire cet impromptu oral sous forme de billet de blog. Nous nous excusons pour les erreurs, le manque de références et la prose sublime ; il s'agit essentiellement d'un enregistrement de la moitié de la discussion, et je n'ai pas expliqué les termes, fourni des liens ou vérifié les faits au niveau de détail que je fais habituellement.

Un exemple amusant est (pour moi du moins) le lien fusible magique d'auto-guérison. Bien qu'il existe de nombreuses implémentations, imaginez un lien fusible sur une puce comme une sorte de résistance. Si vous y faites passer du courant, vous devriez obtenir une connexion. Si le courant est trop élevé, la résistance chauffera et finira par casser. Ceci est couramment utilisé pour désactiver des éléments sur les puces ou pour des activités telles que le réglage de la vitesse d'horloge. Le principe de base est qu'une fois le cavalier grillé, il n'y a aucun moyen de le remettre dans son état d'origine.

Il y a longtemps, il y avait un fabricant de semi-conducteurs qui était un peu hâtif avec son processus de fabrication et des tolérances un peu trop réduites dans une certaine génération de technologie. Au bout de quelques mois (ou années), la liaison entre les deux extrémités d'un tel cavalier a pu réapparaître et le rétablir. Si vous avez de la chance, un tel cavalier sera quelque chose comme le bit le plus significatif du multiplicateur d'horloge, qui, s'il est modifié, désactivera la puce. Si vous n'êtes pas chanceux, cela entraînera une corruption cachée des données.

J'ai entendu de nombreuses personnes de différentes entreprises parler des problèmes de cette génération technologique de ce fabricant, il ne s'agissait donc pas de cas isolés. Quand je dis que c'est drôle, je veux dire que c'est drôle d'entendre cette histoire dans un bar. C'est moins drôle de découvrir après un an de test que certaines de vos puces ne fonctionnent pas car leurs paramètres de cavaliers n'ont aucun sens et vous devez refaire votre puce et retarder la sortie de 3 mois. Soit dit en passant, cette situation de récupération de lien fusible est un autre exemple d'une classe d'erreurs qui peuvent être atténuées avec ECC.

Ce n'est pas un problème Google ; Je ne mentionne cela que parce que beaucoup de gens à qui je parle sont surpris de voir à quel point le matériel peut tomber en panne.

Si vous ne voulez pas parcourir tout le livre, voici l'extrait:

Dans un système qui peut supporter une série de pannes au niveau logiciel, l'exigence minimale pour la partie matérielle est que les pannes de cette partie soient toujours détectées et signalées. logiciel suffisamment à temps pour permettre à l'infrastructure logicielle de les contenir et de prendre les mesures de récupération appropriées. Il n'est pas nécessaire que le matériel gère explicitement toutes les pannes. Cela ne signifie pas que le matériel de tels systèmes doit être conçu sans capacité de correction d'erreurs. Chaque fois que la fonctionnalité de correction de bogues peut être offerte à un coût ou une complexité raisonnable, sa prise en charge est souvent payante. Cela signifie que si la correction des erreurs matérielles était extrêmement coûteuse, le système pourrait être en mesure d'utiliser une version moins chère qui ne fournissait que des capacités de détection. Les systèmes DRAM actuels sont un bon exemple d'une situation dans laquelle une correction d'erreur puissante peut être fournie à un coût supplémentaire très faible. Cependant, assouplir l'exigence de détection des erreurs matérielles serait beaucoup plus difficile, car cela signifierait que chaque composant logiciel serait accablé par la nécessité de vérifier sa propre exécution correcte. Au stade initial de sa historique google J'ai dû faire face à des serveurs où la DRAM n'avait même pas de parité. La création d'un index de recherche Web consiste essentiellement en une très grande opération de tri/fusion utilisant plusieurs machines de manière prolongée. En 2000, l'une des mises à jour mensuelles de l'index Web de Google a échoué à la pré-validation lorsqu'il a été constaté qu'un sous-ensemble des requêtes testées renvoyaient des documents, apparemment au hasard. Après quelques recherches, une situation a été trouvée dans les nouveaux fichiers d'index qui correspondait à la fixation d'un peu à zéro à un certain endroit dans les structures de données, ce qui était un effet secondaire négatif du streaming d'une grande quantité de données via une puce DRAM défectueuse. Des vérifications de cohérence ont été ajoutées aux structures de données d'index pour minimiser le risque que ce problème se reproduise et il n'y a plus eu de problèmes de cette nature. Cependant, il convient de noter que cette méthode ne garantit pas une détection d'erreur à 100% dans la passe d'indexation, car toutes les positions de la mémoire ne sont pas vérifiées - les instructions, par exemple, restent non vérifiées. Cela a fonctionné parce que les structures de données d'index étaient tellement plus grandes que toutes les autres données impliquées dans le calcul que la présence de ces structures de données d'auto-surveillance rendait très probable que les machines avec une DRAM défectueuse seraient identifiées et exclues du cluster. La prochaine génération de machines chez Google incluait déjà la détection de parité de mémoire, et une fois que le prix de la mémoire ECC est tombé à des niveaux compétitifs, toutes les générations suivantes ont utilisé ECC-DRAM.

Balises : Ajouter des balises

De plus, des schémas de protection des données ECC peuvent être appliqués à la mémoire intégrée aux microprocesseurs : mémoire cache, fichier de registre. Parfois, le contrôle est également ajouté aux circuits de calcul.

description du problème

On craint que la tendance à des dimensions physiques plus petites des modules de mémoire n'entraîne une augmentation des taux d'erreur en raison du fait que des particules de moindre énergie pourront changer le bit. D'autre part, la taille compacte de la mémoire réduit le risque que des particules y pénètrent. De plus, le passage à des technologies telles que le silicium sur isolant peut rendre la mémoire plus stable.

Une étude menée sur un grand nombre de serveurs Google a montré que le nombre d'erreurs peut être compris entre 25 000 et 70 000 erreurs par milliard d'heures de travail (eng. heures d'appareil) par mégabit (c'est-à-dire 2,5-7,0 × 10 − 11 erreurs / bit heure) .

Technologie

Une solution à ce problème est la parité - en utilisant un bit supplémentaire qui enregistre la parité du reste des bits. Cette approche vous permet de détecter les erreurs, mais ne vous permet pas de les corriger. Ainsi, lorsqu'une erreur est détectée, vous ne pouvez qu'interrompre l'exécution du programme.

Une approche plus fiable est celle qui utilise des codes de correction d'erreurs. Le code correcteur d'erreurs le plus couramment utilisé est le code de Hamming. La plupart des mémoires de correction d'erreurs utilisées dans les ordinateurs modernes peuvent corriger une erreur sur un seul bit dans un mot machine de 64 bits et détecter, mais pas corriger, une erreur sur deux bits dans un seul mot de 64 bits.

L'approche la plus efficace pour la correction des erreurs dépend du type d'erreurs attendues. On suppose souvent que les différents bits changent indépendamment. Dans ce cas, la probabilité de deux erreurs dans un mot est négligeable. Cependant, cette hypothèse ne tient pas pour ordinateurs modernes. Mémoire basée sur la technologie de correction d'erreurs Chipkill(IBM), permet de corriger plusieurs erreurs, y compris lorsque toute la puce mémoire est endommagée. D'autres technologies de correction de mémoire qui ne supposent pas l'indépendance des erreurs dans différents bits incluent ECC étendu(Sun Microsystèmes), Chipspare(Hewlett-Packard) et SDDC(Intel).

De nombreux systèmes plus anciens ne signalaient pas les bogues corrigés, ne signalant que les bogues trouvés et qui n'ont pas pu être corrigés. Les systèmes modernes enregistrent à la fois les erreurs corrigées (CE, erreurs corrigibles en anglais) et les erreurs non corrigibles (UE, erreurs non corrigibles en anglais). Cela vous permet de remplacer à temps la mémoire endommagée: malgré le fait qu'un grand nombre d'erreurs corrigées en l'absence d'erreurs non corrigibles n'affecte pas le bon fonctionnement de la mémoire, cela peut indiquer que pour un module de mémoire donné, la probabilité d'erreurs non corrigibles augmentera à l'avenir.

Avantage et inconvénients

La mémoire de correction d'erreur protège contre le fonctionnement incorrect d'un système informatique en raison de la corruption de la mémoire et réduit la probabilité d'une défaillance fatale du système. Cependant, une telle mémoire coûte plus cher ; la carte mère, le chipset et le processeur qui prennent en charge la mémoire de correction d'erreurs peuvent également être plus chers, de sorte que cette mémoire est utilisée dans les systèmes où un fonctionnement fluide et correct est important, comme un serveur de fichiers, des applications scientifiques et financières.

La mémoire de correction d'erreurs est 2 à 3 % plus lente (nécessitant souvent un cycle supplémentaire du contrôleur de mémoire pour vérifier les sommes) que la mémoire conventionnelle, selon l'application. Une logique supplémentaire qui implémente le comptage, la vérification ECC et la correction d'erreurs nécessite des ressources logiques et du temps pour fonctionner soit dans le contrôleur de mémoire lui-même, soit dans l'interface entre le CPU et le contrôleur de mémoire.

voir également

Remarques

  1. Werner Fisher. RAM révélée (indéfini) . admin-magazine.com. Consulté le 20 octobre 2014.
  2. Copie archivée (indéfini) (lien indisponible). Récupéré le 20 novembre 2016. Archivé de l'original le 18 avril 2016.
  3. Un événement bouleversé au niveau du sol, Eugene Normand, membre, IEEE, Boeing Defence & Space Group, Seattle, WA 98124-2499
  4. "Une enquête sur les techniques de modélisation et d'amélioration de la fiabilité des systèmes informatiques", IEEE TPDS, 2015
  5. Kuznetsov VV Physique solaire-terrestre (cours de conférences pour les étudiants en physique). Conférence 7. Activité solaire. // Tempêtes solaires. Université d'État du Gorno-Altaï. 2012
  6. Gary M. Swift et Steven M. Guertin. "Observations en vol de plusieurs bits bouleversés dans les DRAM". Laboratoire de propulsion à réaction
  7. Borucki, "Comparison of Accelerated DRAM Soft Error Rates Measured at Component and System Level", 46th Annual International Reliability Physics Symposium, Phoenix, 2008, pp. 482–487
  8. Schroeder, Bianca; Pinheiro, Eduardo; Weber, Wolf-Dietrich. Erreurs DRAM dans la nature : une étude de terrain à grande échelle (indéfini) // SIGMETRICS/Performance. - ACM, 2009. - ISBN 978-1-60558-511-6.
  9. Utilisation du StrongArm SA-1110 dans l'ordinateur de bord du nanosatellite (indéfini) . Centre spatial Tsinghua, Université Tsinghua, Pékin. Récupéré le 16 février 2009. Archivé de l'original le 2 octobre 2011.
  10. Doug Thompson, Mauro Carvalho Chehab. "EDAC - Détection et correction d'erreurs" Archivé de l'original le 5 septembre 2009. . 2005-2009. "L'objectif du module noyau "edac" est de détecter et de signaler les erreurs qui se produisent dans le système informatique fonctionnant sous linux."
  11. Discussion sur ECC sur pcguide (indéfini) . Pcguide.com (17 avril 2001). Consulté le 23 novembre 2011.

Page 1 sur 10

Sur le Web, vous pouvez souvent voir des questions sur des forums thématiques concernant la mémoire de correction d'erreurs, à savoir son impact sur les performances du système. Le test d'aujourd'hui répondra à cette question.

Avant de lire ce document, nous vous recommandons de vous familiariser avec les documents sur et plate-forme LGA1151.

Théorie

Avant de tester, parlons des erreurs de mémoire.
Les erreurs qui se produisent dans la mémoire peuvent être divisées en deux types : matérielles et aléatoires. La raison de l'apparition des premiers sont des puces DRAM défectueuses. Ces derniers surviennent en raison de l'influence des interférences électromagnétiques, des rayonnements, des particules alpha et élémentaires, etc. En conséquence, les erreurs matérielles ne peuvent être corrigées qu'en remplaçant les puces DRAM, et les erreurs aléatoires peuvent être corrigées à l'aide de technologies spéciales, par exemple ECC (Error-Correcting Code). La correction d'erreurs ECC a deux méthodes dans son arsenal : SEC (Single Error Correction) et DED (Double Error Detection). Le premier corrige les erreurs sur un seul bit dans un mot de 64 bits et le second détecte les erreurs sur deux bits.
L'implémentation matérielle d'ECC consiste à prendre en charge des puces de mémoire supplémentaires nécessaires pour écrire des sommes de contrôle 8 bits. Ainsi, un module de mémoire à correction d'erreurs avec une conception à une face aura 9 puces de mémoire au lieu de 8 (comme un module standard), et avec une double face - 18 au lieu de 16. Dans le même temps, la largeur de le module passe de 64 à 72 bits.
Lors de la lecture des données de la mémoire, la somme de contrôle est recalculée et comparée à celle d'origine. Si l'erreur est sur un bit, elle est corrigée, si sur deux, elle est détectée.

Pratique

En théorie, tout va bien - la mémoire de correction d'erreurs augmente la fiabilité du système, ce qui est très important lors de la construction d'un serveur ou d'un poste de travail. Mais en pratique, il y a aussi le côté financier de cette question. Si le serveur nécessite une mémoire de correction d'erreurs, le poste de travail peut se passer d'ECC (de nombreux postes de travail prêts à l'emploi de différents fabricants sont équipés de RAM conventionnelle). Combien coûte la mémoire avec correction d'erreurs ?
Un module DDR4-2133 typique de 8 Go coûte environ 39 $, tandis qu'un module ECC coûte 48 $ (au moment de la rédaction). La différence de coût est d'environ 23%, ce qui est assez significatif à première vue. Mais si vous regardez le coût total du poste de travail, cette différence ne dépassera pas 5% de celui-ci. Ainsi, l'achat de mémoire avec ECC n'augmente que légèrement le coût du poste de travail. La seule question qui reste est de savoir comment la mémoire avec ECC affecte les performances du processeur.
Afin de répondre à cette question, les éditeurs du site ont pris des modules mémoire Samsung DDR4-2133 ECC et Kingston DDR4-2133 avec les mêmes timings 15-15-15-36 et 8 Go pour les tests.

Sur les modules mémoire Samsung M391A1G43DB0-CPB avec correction d'erreur, 9 puces sont soudées de chaque côté.

Alors que sur les barrettes mémoire classiques Kingston KVR21N15D8/8, 8 puces sont soudées de chaque côté.

Banc d'essai : Intel Xeon E3-1275v5, Supermicro X11SAE-F, Samsung DDR4-2133 ECC 8 Go, Kingston DDR4-2133 non ECC 8 Go

Détails

Processeur : (HT activé ; TB désactivé );
- Carte mère: ;
- RAM : 2x (M391A1G43DB0-CPB), 2x (KVR21N15D8/8) ;
- OS : .

Méthodologie des tests

3DMark06 1.21 ;
- 7zip 15.14 ;
- AIDA64 5,60 ;
- Cinebench R15 ;
- Fritz 4.2 ;
-Geekbench 3.4.1;
- Marque Lux v3.1 ;
- MaxxMEMI 1,99 ;
- Pass Mark v8;
- Real Bench v2.43 ;
-SiSoftware Sandra 2016;
- SVPmark v3.0.3b ;
-TrueCrypt 7.1a ;
-WinRAR 5.30 ;
- wPrime 2.10;
-x264 v5.0.1 ;
-x265 v0.1.4 ;
-Kraken ;
- indice d'octane ;
- Indice d'octane 2.0 ;
- Gardien de la paix ;
- Araignée solaire ;
- XPRT Web.

mob_info