Ước tính xác suất lỗi phần cứng

Giả sử tôi chạy một tính toán siêu máy tính trên lõi 100 nghìn trong 4 giờ trên http://www.nersc.gov/users/computational-systems/edison/configuration , trao đổi khoảng 4 PB dữ liệu qua mạng và thực hiện khoảng 4 TB I / Ôi Tính toán là tất cả số nguyên, vì vậy kết quả là đúng hoặc sai (không có lỗi số trung gian).

Giả sử mã là chính xác, tôi muốn ước tính xác suất tính toán sai do lỗi phần cứng. Một cách tốt để đi về điều này là gì? Có những nguồn tốt cho những con số cần thiết để ước tính như vậy?

Bạn đã xem các báo cáo exascale khác nhau đã được đưa ra? Thất bại nặng nề không phải là một mối quan tâm đáng kể ngày hôm nay - chắc chắn, chúng xảy ra, nhưng tần suất của chúng không đủ cao để gây ra lo lắng nghiêm trọng. Nhưng chúng được ước tính là đủ thường xuyên trên các hệ thống exascale có hoặc nhiều lõi hơn mà các mã cần được chuẩn bị để phản ứng thích hợp. Tôi tin rằng những vấn đề này đã được đặt ra trong các báo cáo về lộ trình hướng tới exascale.$O(10^8)$

Hồi ức của tôi là trong số các chế độ thất bại khác nhau, các bit đơn lẻ trong bộ nhớ hoặc trên lõi bộ xử lý không phải là mối quan tâm đáng kể nhất. Thay vào đó, toàn bộ các nút bị hỏng, ví dụ do lỗi đĩa, lỗi hệ điều hành, v.v ... Các thiết kế exascale hiện tại do đó tất cả đều yêu cầu kiểm tra định kỳ mã vào RAM flash, tốt nhất là truyền dữ liệu điểm kiểm tra ra khỏi nút. Các mã sau đó sẽ cần có khả năng khởi động lại nhanh chóng từ trạng thái được lưu trước đó nếu hệ thống gặp phải một nút đã biến mất, thay thế nút này bằng nút khởi động nóng ở nơi khác trong hệ thống.

Tôi đoán, bạn bắt đầu bằng cách thu thập tỷ lệ lỗi của các thành phần, chẳng hạn như DRAM, như nghiên cứu này của Google về Lỗi DRAM trong tự nhiên: Một nghiên cứu thực địa quy mô lớn Họ đã tìm thấy ~ 1% cơ hội để nhận một lỗi không thể sửa chữa mỗi năm.

Tôi không chắc đó có phải là điều bạn quan tâm không. Tôi sẽ quan tâm nhiều hơn đến các lỗi không thể phát hiện. Lỗi như vậy mà các phương pháp kiểm tra lỗi điển hình sẽ không phát hiện ra. Chẳng hạn, khi bạn gửi các gói qua hệ thống quang học, chúng đi kèm với một loại CRC nào đó, cho phép có một lỗi nhỏ xảy ra.

CẬP NHẬT: bài viết này Kiến trúc để phát hiện và phục hồi lỗi trực tuyến trong Bộ xử lý đa lõi nói về kiến ​​trúc đa lõi đáng tin cậy, nhưng chúng cũng bao gồm các khía cạnh khác nhau về độ tin cậy của hệ thống và có thư mục

Có những nguồn tốt cho những con số cần thiết để ước tính như vậy?

Bạn có thể thử hỏi quản trị viên của cụm bạn đang tính toán. Tôi tưởng tượng như là một phần của quá trình xác nhận của họ, họ đã phải đối mặt với vấn đề ước tính khả năng xảy ra lỗi phần cứng.

Âm thanh hoành tráng. Nếu chưa có ai thực hiện thử nghiệm này, bạn có thể xem xét việc chạy 100k lõi riêng làm một việc gì đó như lặp đi lặp lại đầu vào sha1, xem tỷ lệ lỗi là gì. (Không thể đo lường được tôi nghi ngờ), từ đó cũng làm như vậy, nhưng hãy để họ giao dịch kết quả chuỗi băm thường xuyên để có được tỷ lệ lỗi mạng của bạn. Điều này tôi tưởng tượng cũng rất nhỏ, nhưng tôi nghi ngờ bạn có thể nhận được ít nhất một cặp đôi sử dụng siêu xe của bạn trong vài giờ :)

Cách tiếp cận này đảm bảo rằng mọi phép tính đều đúng, vì băm cực kỳ nhạy cảm với các hoán đổi một bit, trong khi ngay cả một phép tính chỉ có thể ẩn các lỗi trong các nhánh, tức là toàn bộ phép tính sẽ không có hình elip trên mỗi trạng thái bộ nhớ liên tiếp.

Tôi đã làm việc để đảm bảo rằng mã được chạy chính xác bởi một cụm bên ngoài, động lực của họ là gian lận bằng cách gửi kết quả giả mạo. Giải pháp tôi hội tụ là tích hợp hàm băm vào tính toán với một số tần số khiến cho việc gian lận kém hiệu quả hơn so với thực hiện công việc.