Tia vũ trụ: xác suất họ sẽ ảnh hưởng đến một chương trình là gì?

Một lần nữa tôi đang xem xét thiết kế và gặp phải tuyên bố rằng xác suất của một kịch bản cụ thể là "ít hơn rủi ro của các tia vũ trụ" ảnh hưởng đến chương trình, và tôi nhận ra rằng tôi không có ý tưởng mờ nhạt nào về điều đó xác suất là.

"Vì 2 ^-128 là 1 trong số 340282366920938463463374607431768211456, tôi nghĩ rằng chúng tôi có lý khi nắm lấy cơ hội của mình ở đây, ngay cả khi những tính toán này bị giảm đi bởi một vài tỷ ... vít chúng tôi lên, tôi tin. "

Lập trình viên này có đúng không? Xác suất của một tia vũ trụ va vào máy tính và ảnh hưởng đến việc thực hiện chương trình là gì?

Từ Wikipedia :

Các nghiên cứu của IBM vào những năm 1990 cho thấy các máy tính thường gặp phải một lỗi do tia vũ trụ trên mỗi 256 megabyte RAM mỗi tháng. ^[15]

Điều này có nghĩa là xác suất 3,7 × 10 ^-9 mỗi byte mỗi tháng hoặc 1,4 × 10 ^-15 mỗi byte mỗi giây. Nếu chương trình của bạn chạy trong 1 phút và chiếm 20 MB RAM, thì xác suất thất bại sẽ là

                 60 × 20 × 1024²
1 - (1 - 1.4e-15)                = 1.8e-6 a.k.a. "5 nines"

Kiểm tra lỗi có thể giúp giảm hậu quả của sự thất bại. Ngoài ra, do kích thước chip nhỏ gọn hơn như nhận xét của Joe, tỷ lệ thất bại có thể khác với 20 năm trước.

Rõ ràng, không đáng kể. Từ bài báo của Nhà khoa học mới này , một trích dẫn từ một ứng dụng bằng sáng chế của Intel:

"Sự cố máy tính gây ra tia vũ trụ đã xảy ra và dự kiến ​​sẽ tăng theo tần số khi các thiết bị (ví dụ, bóng bán dẫn) giảm kích thước trong chip. Vấn đề này được dự báo sẽ trở thành một hạn chế lớn về độ tin cậy của máy tính trong thập kỷ tới."

Bạn có thể đọc bằng sáng chế đầy đủ ở đây .

Lưu ý: câu trả lời này không phải về vật lý, mà là về lỗi bộ nhớ im lặng với các mô-đun bộ nhớ không phải ECC. Một số lỗi có thể đến từ không gian bên ngoài và một số - từ không gian bên trong của máy tính để bàn.

Có một số nghiên cứu về lỗi bộ nhớ ECC trên các trang trại máy chủ lớn như cụm CERN và trung tâm dữ liệu của Google. Phần cứng lớp máy chủ với ECC có thể phát hiện và sửa tất cả các lỗi một bit và phát hiện nhiều lỗi nhiều bit.

Chúng ta có thể giả định rằng có rất nhiều máy tính để bàn không phải ECC (và điện thoại thông minh không phải ECC). Nếu chúng tôi kiểm tra các giấy tờ về tỷ lệ lỗi có thể sửa được ECC (bitflips đơn), chúng tôi có thể biết tỷ lệ hỏng bộ nhớ im lặng trên bộ nhớ không phải ECC.

• Nghiên cứu quy mô lớn Cern 2007 "Tính toàn vẹn dữ liệu" : các nhà cung cấp tuyên bố " Tỷ lệ lỗi bit 10 ^-12 cho các mô-đun bộ nhớ của họ ", " tỷ lệ lỗi được quan sát là thấp hơn 4 bậc so với dự kiến ". Đối với các tác vụ cần nhiều dữ liệu (8 GB / giây đọc bộ nhớ), điều này có nghĩa là việc lật bit đơn có thể xảy ra mỗi phút (10 ^-12 nhà cung cấp BER) hoặc một lần trong hai ngày (10 ^-16 BER).

• Bài báo của Google năm 2009 "Lỗi DRAM trong tự nhiên: Nghiên cứu thực địa quy mô lớn" nói rằng có thể có tới 25000-75000 FIT một bit trên mỗi Mbit ( thất bại về thời gian trên một tỷ giờ ), tương đương với 1 - 5 bit lỗi mỗi giờ cho 8GB RAM sau khi tính toán của tôi. Bài báo cũng nói như vậy: " có nghĩa là tỷ lệ lỗi có thể sửa được là 2000 2000.000 mỗi GB mỗi năm ".

• Báo cáo của Sandia năm 2012 "Phát hiện và sửa lỗi dữ liệu im lặng cho tính toán hiệu năng cao quy mô lớn" : "các lần lật đôi bit được coi là không thể xảy ra" nhưng tại Cray XT5 dày đặc của ORNL, chúng "với tốc độ một lần mỗi ngày cho 75.000 DIMM" với ECC. Và lỗi đơn bit nên cao hơn.

Vì vậy, nếu chương trình có tập dữ liệu lớn (vài GB) hoặc có tốc độ đọc hoặc ghi bộ nhớ cao (GB / s trở lên) và nó chạy trong vài giờ, thì chúng ta có thể mong đợi một vài lần lật bit im lặng trên phần cứng máy tính để bàn. Tốc độ này không thể được phát hiện bởi memtest và các mô-đun DRAM là tốt.

Cụm dài chạy trên hàng ngàn máy tính không phải ECC, như điện toán lưới toàn mạng BOINC sẽ luôn có lỗi từ các bit lật bộ nhớ và cả các lỗi im lặng của đĩa và mạng.

Và đối với các máy lớn hơn (10 nghìn máy chủ) ngay cả với bảo vệ ECC khỏi các lỗi một bit, như chúng ta thấy trong báo cáo năm 2012 của Sandia, có thể có các lần lật hai bit mỗi ngày, do đó bạn sẽ không có cơ hội chạy song song kích thước đầy đủ chương trình trong vài ngày (không có điểm kiểm tra thường xuyên và khởi động lại từ điểm kiểm tra tốt cuối cùng trong trường hợp có lỗi kép). Các cỗ máy khổng lồ cũng sẽ nhận được các bit-bit trong bộ nhớ cache và các thanh ghi cpu (cả bộ kích hoạt của chip kiến ​​trúc và bên trong, ví dụ như trong datapath ALU), bởi vì không phải tất cả chúng đều được ECC bảo vệ.

PS: Mọi thứ sẽ tồi tệ hơn nhiều nếu mô-đun DRAM xấu. Ví dụ, tôi đã cài đặt DRAM mới vào máy tính xách tay, đã chết vài tuần sau đó. Nó bắt đầu cho rất nhiều lỗi bộ nhớ. Những gì tôi nhận được: treo máy tính xách tay, khởi động lại linux, chạy fsck, tìm lỗi trên hệ thống tập tin gốc và nói rằng nó muốn thực hiện khởi động lại sau khi sửa lỗi. Nhưng ở mỗi lần khởi động lại tiếp theo (tôi đã thực hiện khoảng 5-6 trong số đó) vẫn có lỗi được tìm thấy trên hệ thống tập tin gốc.

Wikipedia trích dẫn một nghiên cứu của IBM vào những năm 90 cho thấy rằng "các máy tính thường gặp phải một lỗi do tia vũ trụ trên mỗi 256 megabyte RAM mỗi tháng." Thật không may, trích dẫn là một bài báo trên Science American, không đưa ra bất kỳ tài liệu tham khảo nào nữa. Cá nhân, tôi thấy con số đó rất cao, nhưng có lẽ hầu hết các lỗi bộ nhớ do tia vũ trụ gây ra đều không gây ra bất kỳ vấn đề thực tế hoặc đáng chú ý nào.

Mặt khác, mọi người nói về xác suất khi nói đến các kịch bản phần mềm thường không có manh mối gì về những gì họ đang nói.

Chà, tia vũ trụ rõ ràng đã khiến các thiết bị điện tử trong xe ô tô Toyota gặp trục trặc, vì vậy tôi sẽ nói rằng xác suất rất cao :)

Là tia vũ trụ thực sự gây ra tai ương Toyota?

Với ECC, bạn có thể sửa các lỗi 1 bit của Tia vũ trụ. Để tránh 10% các trường hợp trong đó các tia vũ trụ gây ra lỗi 2 bit, các tế bào ECC thường được xen kẽ trên các chip để không có hai ô nằm cạnh nhau. Do đó, một sự kiện tia vũ trụ ảnh hưởng đến hai tế bào sẽ dẫn đến hai lỗi 1bit có thể sửa được.

Mặt trời tuyên bố: (Phần số 816-5053-10 tháng 4 năm 2002)

Nói chung, lỗi mềm tia vũ trụ xảy ra trong bộ nhớ DRAM với tốc độ ~ 10 đến 100 FIT / MB (1 FIT = 1 thiết bị bị lỗi trong 1 tỷ giờ). Vì vậy, một hệ thống có bộ nhớ 10 GB sẽ hiển thị một sự kiện ECC cứ sau 1.000 đến 10.000 giờ và một hệ thống có 100 GB sẽ hiển thị một sự kiện cứ sau 100 đến 1.000 giờ. Tuy nhiên, đây là một ước tính sơ bộ sẽ thay đổi như là một chức năng của các hiệu ứng được nêu ở trên.

Lỗi bộ nhớ là có thật, và bộ nhớ ECC sẽ giúp. Bộ nhớ ECC được triển khai đúng sẽ sửa các lỗi bit đơn và phát hiện lỗi bit kép (tạm dừng hệ thống nếu phát hiện lỗi như vậy.) Bạn có thể thấy điều này từ việc mọi người thường xuyên phàn nàn về vấn đề phần mềm được giải quyết bằng cách chạy Memtest86 và phát hiện ra trí nhớ xấu. Tất nhiên, một sự cố thoáng qua gây ra bởi một tia vũ trụ khác với một phần bộ nhớ bị hỏng liên tục, nhưng nó có liên quan đến câu hỏi rộng hơn về việc bạn nên tin tưởng bao nhiêu vào bộ nhớ của mình để hoạt động chính xác.

Một phân tích dựa trên kích thước cư dân 20 MB có thể phù hợp với các ứng dụng tầm thường, nhưng các hệ thống lớn thường có nhiều máy chủ với bộ nhớ chính lớn.

Liên kết thú vị: http://cr.yp.to/hardware/ecc.html

Liên kết Corsair trong trang không may dường như đã chết.

Đây là một vấn đề thực sự và đó là lý do tại sao bộ nhớ ECC được sử dụng trong các máy chủ và hệ thống nhúng. Và tại sao các hệ thống bay khác với các hệ thống trên mặt đất.

Ví dụ: lưu ý rằng các bộ phận Intel dành cho các ứng dụng "nhúng" có xu hướng thêm ECC vào bảng thông số. Bay Trail cho máy tính bảng thiếu nó, vì nó sẽ khiến bộ nhớ đắt hơn một chút và có thể chậm hơn. Và nếu một máy tính bảng gặp sự cố một chương trình mỗi lần trong một mặt trăng xanh, người dùng sẽ không quan tâm nhiều. Bản thân phần mềm này kém tin cậy hơn nhiều so với CTNH. Nhưng đối với SKU dự định sử dụng trong máy móc công nghiệp và ô tô, ECC là bắt buộc. Vì ở đây, chúng tôi hy vọng SW sẽ đáng tin cậy hơn rất nhiều và các lỗi từ các upets ngẫu nhiên sẽ là một vấn đề thực sự.

Các hệ thống được chứng nhận theo tiêu chuẩn IEC 61508 và các tiêu chuẩn tương tự thường có cả các kiểm tra khởi động để kiểm tra xem tất cả RAM có hoạt động không (không có bit nào bị kẹt ở 0 hoặc 1), cũng như xử lý lỗi khi chạy cố gắng khôi phục từ các lỗi được phát hiện bởi ECC và thường cũng kiểm tra các tác vụ bộ nhớ đi qua và đọc và ghi bộ nhớ liên tục để đảm bảo rằng bất kỳ lỗi nào xảy ra đều được chú ý.

Nhưng đối với phần mềm PC chính thống? Không phải là một thỏa thuận lớn. Đối với một máy chủ tồn tại lâu dài? Sử dụng ECC và xử lý lỗi. Nếu một lỗi không thể sửa được sẽ giết kernel, vì vậy hãy là nó. Hoặc bạn bị hoang tưởng và sử dụng một hệ thống dự phòng với thực thi bước khóa để nếu một lõi bị hỏng, lõi kia có thể tiếp quản trong khi lõi đầu tiên khởi động lại.

Nếu một chương trình quan trọng đến tính mạng (nó sẽ giết một ai đó nếu thất bại), thì nó cần được viết theo cách nó sẽ không an toàn hoặc tự động phục hồi sau thất bại đó. Tất cả các chương trình khác, YMMV.

Toyotas là một trường hợp tại điểm. Nói những gì bạn sẽ về một cáp ga, nhưng nó không phải là phần mềm.

Xem thêm http://en.wikipedia.org/wiki/Therac-25

Tôi đã từng lập trình các thiết bị bay trong không gian, và sau đó bạn (được cho là, không ai từng cho tôi xem bất kỳ bài báo nào về nó, nhưng nó được cho là kiến ​​thức phổ biến trong doanh nghiệp) có thể mong đợi các tia vũ trụ luôn gây ra lỗi.

"Các sự kiện tia vũ trụ" được coi là có sự phân bố đồng đều trong nhiều câu trả lời ở đây, điều này có thể không phải lúc nào cũng đúng (ví dụ như siêu tân tinh). Mặc dù theo định nghĩa "các tia vũ trụ" (ít nhất là theo Wikipedia) đến từ ngoài vũ trụ, tôi nghĩ thật công bằng khi bao gồm các cơn bão mặt trời cục bộ (còn gọi là phóng đại khối coronal dưới cùng một chiếc ô. Tôi tin rằng nó có thể khiến một số bit bị lật trong một thời gian ngắn, có khả năng đủ để làm hỏng ngay cả bộ nhớ hỗ trợ ECC.

Người ta biết rằng bão mặt trời có thể gây ra một số tàn phá với hệ thống điện (như mất điện Quebec vào tháng 3 năm 1989 ). Rất có khả năng các hệ thống máy tính cũng có thể bị ảnh hưởng.

Khoảng 10 năm trước tôi đã ngồi ngay cạnh một anh chàng khác, chúng tôi đang ngồi với mỗi chiếc máy tính xách tay của mình, đó là thời kỳ có thời tiết mặt trời khá "bão tố" (ngồi ở Bắc cực, chúng tôi có thể quan sát điều này một cách gián tiếp - rất nhiều cực quang được nhìn thấy). Đột nhiên - ngay lập tức - cả hai máy tính xách tay của chúng tôi bị hỏng. Anh ta đang chạy OS X, còn tôi thì chạy Linux. Cả hai chúng ta đều không quen với việc máy tính xách tay gặp sự cố - đó là một điều khá hiếm gặp trên Linux và OS X. Các lỗi phần mềm thông thường ít nhiều có thể được loại trừ vì chúng tôi đang chạy trên các hệ điều hành khác nhau (và nó đã không xảy ra trong một bước nhảy vọt thứ hai). Tôi đã gán cho sự kiện đó là "bức xạ vũ trụ".

Sau đó, "bức xạ vũ trụ" đã trở thành một trò đùa nội bộ tại nơi làm việc của tôi. Bất cứ khi nào điều gì đó xảy ra với các máy chủ của chúng tôi và chúng tôi không thể tìm thấy bất kỳ lời giải thích nào cho nó, chúng tôi đùa rằng lỗi thuộc về "bức xạ vũ trụ". :-)

Thường xuyên hơn, tiếng ồn có thể làm hỏng dữ liệu. Tổng kiểm tra được sử dụng để chống lại điều này trên nhiều cấp độ; trong cáp dữ liệu thường có một bit chẵn lẻ di chuyển dọc theo dữ liệu. Điều này làm giảm đáng kể khả năng tham nhũng. Sau đó, ở các mức phân tích cú pháp, dữ liệu vô nghĩa thường bị bỏ qua, vì vậy ngay cả khi một số tham nhũng đã vượt qua bit chẵn lẻ hoặc các tổng kiểm tra khác, trong hầu hết các trường hợp, nó sẽ bị bỏ qua.

Ngoài ra, một số thành phần được che chắn bằng điện để chặn tiếng ồn (có lẽ không phải là tia vũ trụ tôi đoán).

Nhưng cuối cùng, như những người trả lời khác đã nói, thỉnh thoảng có bit hoặc byte bị xáo trộn, và điều đó sẽ tùy thuộc vào việc đó có phải là một byte đáng kể hay không. Kịch bản trường hợp tốt nhất, một tia vũ trụ làm xáo trộn một trong các bit trống và hoàn toàn không có tác dụng, hoặc làm hỏng máy tính (đây là một điều tốt, vì máy tính không bị làm hại); Nhưng trường hợp xấu nhất, tốt, tôi chắc chắn bạn có thể tưởng tượng.

Tôi đã trải nghiệm điều này - Không hiếm khi các tia vũ trụ lật một chút, nhưng rất khó để một người quan sát điều này.

Tôi đã làm việc trên một công cụ nén cho trình cài đặt vào năm 2004. Dữ liệu thử nghiệm của tôi là một số tệp cài đặt Adobe có dung lượng khoảng 500 MB trở lên.

Sau khi chạy nén tẻ nhạt và chạy giải nén để kiểm tra tính toàn vẹn, FC / B cho thấy một byte khác nhau.

Trong một byte đó, MSB đã lật. Tôi cũng lật lại, lo lắng rằng tôi có một con bọ điên chỉ xuất hiện trong những điều kiện rất cụ thể - tôi thậm chí còn không biết bắt đầu tìm ở đâu.

Nhưng một cái gì đó nói với tôi để chạy thử nghiệm một lần nữa. Tôi chạy nó và nó đã qua. Tôi thiết lập một kịch bản để chạy thử nghiệm 5 lần qua đêm. Vào buổi sáng cả 5 đã trôi qua.

Vì vậy, đó chắc chắn là một bit lật vũ trụ.

Bạn cũng có thể muốn xem phần cứng Fault Tolerant.

Ví dụ, Stratus Technology xây dựng các máy chủ Wintel được gọi là ftServer có 2 hoặc 3 "mainboard" trong bước khóa, so sánh kết quả tính toán. (điều này cũng được thực hiện trong các phương tiện không gian đôi khi).

Các máy chủ Stratus đã phát triển từ chipset tùy chỉnh đến bước khóa trên bảng nối đa năng.

Một hệ thống rất giống (nhưng phần mềm) là bước khóa VMWare Fault Tolerance dựa trên Hypervisor.

Là một điểm dữ liệu, điều này chỉ xảy ra trên bản dựng của chúng tôi:

02:13:00,465 WARN  - In file included from /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/ostream:133:
02:13:00,465 WARN  - /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/locale:3180:65: error: use of undeclared identifier '_'
02:13:00,465 WARN  - for (unsigned __i = 1; __i < __trailing_sign->size(); ++_^i, ++__b)
02:13:00,465 WARN  - ^
02:13:00,465 WARN  - /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/locale:3180:67: error: use of undeclared identifier 'i'
02:13:00,465 WARN  - for (unsigned __i = 1; __i < __trailing_sign->size(); ++_^i, ++__b)
02:13:00,465 WARN  - ^

Điều đó trông rất mạnh mẽ giống như một cú lật xảy ra trong quá trình biên dịch, ở một vị trí rất quan trọng trong tệp nguồn một cách tình cờ.

Tôi không nhất thiết phải nói đây là "tia vũ trụ", nhưng triệu chứng phù hợp.