Estadísticas sobre mal funcionamiento de RAM

¿Alguien sabe acerca de estadísticas o estudios sobre la frecuencia con la que las computadoras tienen mal funcionamiento de RAM?

Actualización: ¡ Mi computadora está bien! No tengo problemas de RAM, me interesan las estadísticas. Recibo informes de errores de mi software por los cuales una causa podría ser el mal funcionamiento de la RAM en la computadora del usuario, y me gustaría saber qué tan probable es eso.

¡Gracias!

Carl

En una población de máquinas de clase de servidor 36, veo una falla corregible detectada por los circuitos ECC una vez cada 3 meses.

Si sospecha una falla de memoria, debe ejecutar memtest86, que viene incluido con casi todas las distribuciones de Linux populares en estos días.

De las tasas de error DRAM de Robin Harris : Pesadilla en la calle DIMM :

Un estudio de dos años y medio de DRAM en 10 de miles de servidores de Google encontró que las tasas de error DIMM son cientos o miles de veces más altas de lo que se pensaba, una media de 3,751 errores corregibles por DIMM por año.

Harris cita un estudio realizado durante 2.5 años en la flota de servidores de Google . Tenga en cuenta que los servidores suelen utilizar EEC RAM, que realiza algunas correcciones de errores. Las computadoras a nivel de consumidor generalmente no tienen esto.

Berke Durak de Lambda Diode calcula :

Primero, supongamos que tiene un sistema sin corrección de errores ni paridad. La probabilidad de que experimente un error de bit durante el tiempo T será 1- (1-p) ^ m.

Para T = 1 hora, p = 1.3e-12 ym = 4 * 2 ^ 30 * 8 que da 0.044 o 4.4%. Esa es una probabilidad bastante alta. De hecho, en un día, eso lleva a una probabilidad del 66% y en 72 horas a una probabilidad del 96%.

Entonces, la probabilidad de tener al menos un bit de error en 4 gigabytes de memoria al nivel del mar en el planeta Tierra en 72 horas es superior al 95%.

No me reiré la próxima vez que un colega diga "rayo cósmico" cuando no podamos identificar la causa de un accidente ...

Puede iniciar la computadora con memtest86 + y ejecutar una verificación durante la noche. Así es como encuentro los problemas.

Sí, he visto fallas de memoria donde solo fallarían con un patrón particular de escritura de memoria. El BIOS de la computadora no detectó el problema, pero memtest86 lo encontró en una ejecución nocturna.

He visto que dos palos de RAM se estropean en unas cincuenta computadoras que he usado en los últimos diez años. Sucede, pero no a menudo.

Es posible que desee echar un vistazo a este estudio de google :

En promedio, aproximadamente uno de cada tres servidores de Google experimentó un error de memoria corregible cada año y uno de cada cien un error no corregible

Pero hablan de RAM ECC, no de la RAM de usuario cotidiana

He visto un puñado de módulos de memoria fallar directamente en los servidores operativos durante la última década más o menos y un número ligeramente mayor de fallas al realizar la prueba de grabación de Memtest86 en el hardware recién entregado. Estos son sistemas de servidor, casi todos los cuales tendrán memoria ECC de un tipo u otro, por lo que esperaría problemas mucho más frecuentes en los sistemas cliente con RAM sin corrección de errores. Sin embargo, no tengo un gran conjunto de muestras para trabajar, tenemos un par de docenas de servidores propios y, en términos de la puesta en servicio de sistemas de clientes, diría que he trabajado en un centenar más o menos a un nivel donde ' en realidad estaría prestando atención a la RAM.

En el lado del cliente, tengo un poco más de experiencia a escala empresarial: fui ingeniero sénior para un grupo que administró 50,000 PC de usuarios finales durante un par de años y nunca vimos los fallos RAM o blandos como un problema importante, ciertamente no fue algo que afectó a cualquier porcentaje medible de sistemas. Eso no quiere decir que no sucedió, solo que me sorprendería mucho si fuera un problema que afectara a> 1% de las computadoras de escritorio y portátiles de clase empresarial. Algunos modelos específicos demostrarían tasas de falla realmente altas que estaban relacionadas con el control de calidad de construcción, el primer lote de IBM Thinkpad T30 tuvo un problema con su segunda ranura DIMM que nos llevó a tener que reparar / reemplazar un par de miles de máquinas en un punto.

Sin embargo, esta publicación de blog de Larry Osterman de Microsoft de 2005 podría dar una posible explicación para algunos de estos: su análisis de algunos errores extraños informados en el conjunto de datos bastante grande que proviene de Informes de errores de Windows indica que muchos de esos problemas extraños son causados ​​por un exceso de reloj Si es probable que un número significativo de sus usuarios finales estén usando un kit de nivel de consumidor con exceso de reloj, entonces esto puede estar relacionado con sus errores.

¿Tiene la opción de usar 'memoria duplicada' en su sistema? Eso le diría si tiene problemas de memoria o no. Con eso en su lugar, hay MUCHA menor posibilidad de que cualquier error se deba a problemas de memoria física.

Si está ejecutando Linux:

Si no desea reiniciar en memtest86 + , puede obtener algunos resultados ejecutando memtester para probar la memoria y encontrar si está defectuosa o no. Realiza un buen trabajo realista para encontrar las fallas irregulares, así como con las fallas no deterministas. Tiene varias pruebas para detectar el límite de la memoria y produce un informe detallado de fallas localizadas, pruebas ejecutadas y el tiempo necesario para encontrar las fallas en la computadora. No es necesario reiniciar, puede ejecutarlo en un sistema Linux en ejecución.

No encontré ningún enlace para la aplicación, pero aquí está la información del paquete debian :