Statistik kerusakan RAM

Adakah yang tahu tentang statistik atau studi tentang seberapa sering komputer mengalami kerusakan RAM?

Pembaruan: Komputer saya baik-baik saja! Saya tidak memiliki masalah RAM, saya tertarik dengan statistik. Saya mendapatkan laporan bug untuk perangkat lunak saya yang salah satu penyebabnya mungkin tidak berfungsi RAM pada komputer pengguna, dan saya ingin tahu seberapa besar kemungkinannya.

Terima kasih!

Carl

Dalam populasi mesin server kelas 36, saya melihat kegagalan yang dapat diperbaiki terdeteksi oleh sirkuit ECC setiap 3 bulan sekali.

Jika Anda mencurigai kegagalan memori, Anda harus menjalankannya memtest86, yang disertakan dengan hampir semua distro linux populer akhir-akhir ini.

Dari tingkat kesalahan DRAM Robin Harris : Nightmare on DIMM street :

Sebuah penelitian DRAM selama dua setengah tahun tentang 10 ribu server Google menemukan tingkat kesalahan DIMM ratusan hingga ribuan kali lebih tinggi daripada yang diperkirakan - rata-rata 3,751 kesalahan yang dapat diperbaiki per DIMM per tahun.

Harris mengutip penelitian yang dilakukan lebih dari 2,5 tahun di armada server Google . Perhatikan bahwa server biasanya menggunakan EEC RAM, yang melakukan beberapa koreksi kesalahan. Komputer tingkat konsumen biasanya tidak memiliki ini.

Berke Durak dari Lambda Diode menghitung :

Pertama, anggap Anda memiliki sistem tanpa koreksi kesalahan atau paritas. Probabilitas bahwa Anda akan mengalami sedikit kesalahan selama waktu T adalah 1- (1-p) ^ m.

Untuk T = 1 jam, p = 1.3e-12 dan m = 4 * 2 ^ 30 * 8 yang menghasilkan 0,044 atau 4,4%. Itu kemungkinan yang cukup tinggi. Memang, dalam satu hari, itu mengarah pada probabilitas 66% dan dalam 72 jam hingga probabilitas 96%.

Jadi probabilitas memiliki setidaknya satu kesalahan bit dalam 4 gigabytes memori di permukaan laut di planet Bumi dalam 72 jam adalah lebih dari 95%.

Saya tidak akan tertawa lain kali seorang kolega mengatakan "sinar kosmik" ketika kita gagal mengidentifikasi penyebab kecelakaan ...

Anda dapat mem-boot komputer dengan memtest86 + dan menjalankan pemeriksaan semalam. Begitulah cara saya menemukan masalah.

Ya, saya telah melihat tongkat memori menjadi buruk di mana mereka hanya akan gagal dengan satu pola memori tertentu menulis. BIOS komputer tidak mendeteksi masalah, tetapi memtest86 menemukannya dalam semalam.

Saya telah melihat dua batang RAM rusak dari sekitar lima puluh komputer yang telah saya gunakan selama sepuluh tahun terakhir. Itu terjadi, tetapi tidak sering.

Anda mungkin ingin melihat studi google ini :

Rata-rata, sekitar satu dari tiga server Google mengalami kesalahan memori yang dapat diperbaiki setiap tahun dan satu dalam seratus kesalahan yang tidak dapat diperbaiki

Tetapi mereka berbicara tentang ECC RAM, bukan RAM pengguna sehari-hari Anda

Saya telah melihat beberapa modul memori gagal total di server operasional selama dekade terakhir ini dan jumlah kegagalan yang sedikit lebih tinggi ketika melakukan Memtest86 terbakar dalam pengujian pada perangkat keras yang baru dikirim. Ini adalah sistem server, hampir semuanya akan memiliki memori ECC atau sejenisnya, jadi saya berharap masalah yang lebih sering terjadi pada sistem klien dengan RAM yang tidak mengoreksi kesalahan. Saya tidak memiliki set sampel besar untuk bekerja, kami memiliki beberapa lusin server kami sendiri dan dalam hal sistem pelanggan komisioning saya akan mengatakan saya telah bekerja pada seratus atau lebih pada tingkat di mana saya d benar-benar memperhatikan RAM.

Di sisi klien, saya memiliki sedikit lebih banyak pengalaman di skala perusahaan - saya adalah seorang insinyur senior untuk grup yang mengelola PC pengguna akhir 50k selama beberapa tahun dan kami tidak pernah melihat RAM hard atau soft failure sebagai masalah yang signifikan, tentu saja itu bukan sesuatu yang mempengaruhi persentase sistem yang dapat diukur. Itu tidak berarti itu tidak terjadi, hanya saja saya akan sangat terkejut jika itu adalah masalah yang mempengaruhi> 1% desktop dan notebook kelas bisnis. Beberapa model tertentu akan menunjukkan tingkat kegagalan yang sangat tinggi yang terkait dengan membangun kontrol kualitas, batch pertama dari IBM Thinkpad T30's memiliki masalah dengan slot DIMM kedua mereka yang menyebabkan kami harus memperbaiki \ mengganti beberapa ribu mesin pada satu titik.

Posting blog ini dari Microsoft Larry Osterman dari 2005 mungkin memberikan penjelasan yang mungkin untuk beberapa hal ini - analisisnya tentang beberapa kesalahan aneh yang dilaporkan dalam dataset yang cukup besar yang berasal dari Windows Error Reporting menunjukkan bahwa banyak dari masalah aneh tersebut disebabkan oleh kelebihan pencatatan jam kerja. Jika sejumlah besar pengguna akhir Anda cenderung menggunakan kit tingkat konsumen over-clock maka ini mungkin terkait dengan kesalahan Anda.

Apakah Anda memiliki opsi untuk menggunakan 'memori cermin' di sistem Anda - yang akan memberi tahu Anda jika Anda memiliki masalah memori atau tidak - dengan itu ada JAUH kemungkinan lebih kecil bahwa ada kesalahan karena masalah memori fisik.

Jika Anda menjalankan Linux:

Jika Anda tidak ingin mem-boot ulang ke memtest86 + Anda bisa mendapatkan beberapa hasil dengan menjalankan memtester untuk menguji memori untuk mengetahui apakah itu salah atau tidak. Itu melakukan pekerjaan yang baik secara realistis untuk menemukan kesalahan tidak teratur serta dengan kesalahan non-deterministik di dalamnya. Ini memiliki beberapa tes untuk menangkap batas memori, dan menghasilkan laporan kesalahan yang terletak, tes berjalan, dan waktu yang dibutuhkan untuk menemukan kesalahan di komputer. Tidak perlu reboot, Anda dapat menjalankannya di sistem Linux yang berjalan.

Saya tidak menemukan tautan apa pun untuk aplikasi ini, tetapi ini adalah informasi paket debian :