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


546

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ì?


42
"Xổ số trúng thưởng: xác suất họ sẽ ảnh hưởng đến một chương trình là gì?"
kennytm

27
Nó phụ thuộc một phần vào nơi chương trình được thực thi và mức độ được bảo vệ của nó. Trên Trái đất, thông lượng tia vũ trụ thấp hơn nhiều so với trong không gian sâu, hoặc thậm chí gần quỹ đạo Trái đất. Ví dụ, Kính viễn vọng Không gian Hubble tạo ra các hình ảnh thô được đánh dấu bằng các dấu vết tia vũ trụ.
Adam Hollidge

89
Điều này có nghĩa là từ bây giờ, khi có ai đó hỏi về finallycác khối, chúng ta sẽ phải đủ điều kiện với "luôn luôn thực thi trừ khi chương trình thoát ra, hoặc nếu nó bị tia vũ trụ tấn công"?
skaffman

72
Làm việc trên một máy dò hạt nguyên mẫu nhiều năm trước, tôi đã lập trình nó để in "ouch!" mỗi khi nó bị tia vũ trụ tấn công. Thời gian tốt ...
Beta

8
Một trong những câu hỏi thú vị nhất mà tôi đã đọc ở đây trong một thời gian. Một mắt mở thực sự. Tin tưởng vào tôi để mở lại.
Agnel Kurian

Câu trả lời:


308

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.


10
Quan trọng hơn, kích thước tính năng chip cho CPU vào năm 1995 là khoảng 0,35 Thaym hoặc 350nm. Bây giờ là 1/10 kích thước đó ở 35nm.
Joe Koberg

18
Có thể thay vì giảm rủi ro, giảm kích thước sẽ tăng rủi ro vì sẽ tốn ít năng lượng hơn để thay đổi trạng thái của từng bit?
Robert

63
Giảm kích thước chắc chắn làm tăng rủi ro. Bộ xử lý cứng cho các phương tiện không gian sử dụng kích thước tính năng rất lớn để tránh hiệu ứng tia vũ trụ.
Joe Koberg

22
Không chỉ các tia vũ trụ, các đồng vị phóng xạ trong các vật liệu được sử dụng trong chip là một vấn đề lớn hơn nhiều. Các nhà sản xuất đi đến các chiều dài lớn để đảm bảo silicon, hàn, đóng gói, v.v. không chứa bất kỳ bộ phát alpha hoặc beta nào.
Martin Beckett

14
Ồ Điều này có nghĩa là khoảng 1 byte trong PC của tôi bị hỏng cứ sau hai ngày.
Stefan Monov

91

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 .


7
Tại sao chúng tăng với sự giảm kích thước của chip? Chắc chắn một vật nhỏ hơn ít có khả năng bị tia bắn trúng (tức là so sánh ném bóng tennis vào tường, ném vào tem)
Jonathan.

7
Bởi vì khi kích thước của các thành phần co lại, chúng trở nên nhạy cảm hơn nhiều đối với các tia vũ trụ.
ire_and_curses

4
Có, nhỏ hơn tương đương với ít khả năng bị tấn công hơn, nhưng nhiều khả năng cú đánh đó sẽ ảnh hưởng đến trạng thái.
John Hascall

2
@ire_and_curses [cần dẫn nguồn]
Anko

8
@Anko - Đó là loại hiển nhiên. Khi một thành phần nhất định trở nên nhỏ hơn, nó cần ít điện áp hơn và ít phí hơn để thiết lập một chút. Điều đó làm cho nó nhạy cảm hơn khi được thổi năng lượng từ không gian bên ngoài. Tuy nhiên, đây là một trích dẫn dành cho bạn: Khi các thiết bị bộ nhớ LSI trở nên nhỏ hơn, chúng trở nên nhạy cảm hơn với các lỗi mềm do bức xạ hạt nhân gây ra.
ire_and_curses

55

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.


9
Tài liệu bổ sung từ BH 2011: "Bitsquatting cướp DNS mà không khai thác" media.blackhat.com/bh-us-11/Dinaburg/... danh sách hiện đại đa GB DRAM có khoảng 10.000-30.000 FIT / Mbit (ít hơn 100 giờ giữa lỗi cho mỗi 128MB). Bài viết cũng liệt kê các bài báo kết luận rằng hầu hết các lỗi mềm là do phóng xạ, hầu hết tất cả các trường hợp - từ các tia vũ trụ và một số trường hợp từ các máy phát alpha trong PC. Các tác giả BH đã thử nghiệm và có 50000 lượt truy cập vào các tên miền, có 1 bit được thay đổi từ các trang web phổ biến
osgx

Kudos để thêm các nghiên cứu gần đây ở đây. Với sự năng động của bỏ phiếu SO và cách chúng được tích lũy theo thời gian, thật khó để có một bài thuyết trình cập nhật về chủ đề này nổi bật (ở đây).
Fizz

Chúng tôi đã có vấn đề tương tự. Chúng tôi đã không thực hiện bất kỳ nghiên cứu chính xác nào, nhưng chúng tôi đã có khá nhiều cú va chạm với các cú lật bit có thể nhìn thấy. Chúng tôi đã kiểm tra các bit lật và hóa ra chúng nằm trong phần mã. Chúng tôi đã so sánh với những gì nên có và nó không giống như sửa đổi có chủ ý (nghĩa là hướng dẫn kết quả không có nhiều ý nghĩa). Cuối cùng, chúng tôi đã có ứng dụng đơn giản, đó là so sánh các lần đổ vỡ với các phiên bản đã phát hành (được lưu trữ) và lọc ra các trường hợp như vậy. Thật thú vị tôi nghĩ rằng hầu hết các trường hợp như vậy đến từ Iran, Ả Rập và tôi nghĩ rằng một quốc gia nữa từ Nam Mỹ (không nhớ bây giờ).
GiM

2
Trong bài viết của Google, nó trông giống như một trường hợp RAM kém hơn Khoảng một phần ba số máy và hơn 8% DIMM trong đội tàu của chúng tôi đã thấy ít nhất một lỗi có thể sửa được mỗi năm. Tỷ lệ lỗi trên mỗi DIMM của chúng tôi có thể sửa được trung bình là 25.000 F7575.000 FIT (thất bại về thời gian trên một tỷ giờ hoạt động) trên mỗi Mbit và phạm vi FIT trung bình là 778 - 25.000 mỗi Mbit (trung bình cho các DIMM có lỗi), trong khi các nghiên cứu ưu tiên báo cáo 200-5.000 FIT mỗi Mbit. Số lượng lỗi có thể sửa được trên mỗi DIMM rất khác nhau, với một số DIMM gặp phải một số lượng lớn lỗi, so với các lỗi khác.
vartec

31

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.


7
Xác suất của một bit được lật phải được nhân với xác suất của bit có ảnh hưởng đáng chú ý đến chương trình. Tôi đoán xác suất thứ hai thấp hơn nhiều so với bạn nghĩ.
Đánh dấu tiền chuộc

2
@Mark: Các chương trình máy tính thông thường không có loại tích hợp khả năng chịu lỗi đó. Một lỗi một bit trong mã chương trình sẽ có nhiều khả năng hơn là không làm hỏng chương trình, nếu mã bị hỏng được thực thi.
Robert Harvey

75
Có, nhưng hầu hết bộ nhớ chứa dữ liệu, trong đó flip sẽ không phải là visiblp.
zoul

34
@zoul. lol tại 'visiblp', nhưng nếu e = 1100101 và p = 1110000 thì bạn là nạn nhân đáng tiếc của 3 lần lật!
PaulG

10
@Paul: hoặc một ngón tay blip.
mở

30

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?


23
"Các nhà quản lý liên bang đang nghiên cứu xem liệu gia tốc đột ngột ở Toyotas có liên quan đến các tia vũ trụ hay không." Đây là lý do tại sao bạn không bao giờ nên cung cấp cho các cơ quan quản lý liên bang quyền lực trong cuộc sống của bạn.

13
Tôi đoán lý thuyết ở đây là các tia vũ trụ đang lật các bit trong bộ não cũ hơn khiến chúng bị trục trặc và nhấn nhầm bàn đạp.
Knox

16
"Rõ ràng"? Tôi muốn nói rằng đó là một phỏng đoán hoang dã vào thời điểm này. Dự đoán hoang dã của tôi là hiện tượng này là kết quả của cơn ác mộng cũ của các hệ thống nhúng (thực ra là hầu hết các hệ thống máy tính phức tạp) - điều kiện cuộc đua.
Michael Burr

7
@Knox: Hãy ra khỏi chiếc mũ giấy thiếc cũ của bạn, nó hữu ích!

3
Nó có thể không phải là một trò đùa. Tôi đã thấy một số thứ nghiêm trọng kỳ lạ như thế xảy ra trước đây. Không hiếm như hầu hết mọi người nghĩ.
Brian Knoblauch

25

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.


17

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.


Các bit bit tia vũ trụ có thể không được phân bố đồng đều, đặc biệt nếu chúng ta bao gồm các cơn bão mặt trời dưới "sự kiện tia vũ trụ" -um giác. Nếu bạn có hai hoặc nhiều bitflips trong cùng một byte, ECC điển hình sẽ không thể sửa lỗi.
tobixen

@tobixen Phát hiện lỗi bit kép tốt hơn là tiếp tục chạy với dữ liệu xấu. Bước tiếp theo sau ECC là Chipkill với phản chiếu DIMM ...
janm 16/11/17

13

Đâ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.


Các bit bit tia vũ trụ có thể không được phân bố đồng đều, đặc biệt nếu chúng ta bao gồm các cơn bão mặt trời dưới "sự kiện tia vũ trụ" -um giác. Một vụ nổ bất ngờ có thể gây ra một số bitflips trong một byte và thuật toán ECC sẽ không thể sửa lỗi.
tobixen

12

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


Không bao giờ phần mềm cho throttles. Các cảm biến và hệ thống dây điện cho các điều tiết là điểm yếu. Cảm biến vị trí bướm ga của tôi đã thất bại trong một bộ tạo số ngẫu nhiên ... Không tăng tốc ngoài ý muốn, nhưng nó chắc chắn không làm được gì cho hỗn hợp nhiên liệu!
Brian Knoblauch

3
@Brian: Phần mềm tốt sẽ chỉ ra rằng các điểm dữ liệu không liên tục và kết luận rằng dữ liệu là xấu.
Robert Harvey

..và những gì ... Dữ liệu tốt là bắt buộc. Biết nó xấu không giúp được gì. Không phải cái gì bạn có thể làm việc kỳ diệu xung quanh.
Brian Knoblauch

3
@Brian: Chà, vì một điều, bạn có thể thực hiện hành động khắc phục dựa trên kiến ​​thức rằng dữ liệu của bạn là xấu. Bạn có thể ngừng tăng tốc, ví dụ.
Robert Harvey

Có, bạn có thể (và nên) dữ liệu cheksum. Đầu cuối tốt nhất. Tuy nhiên điều này chỉ làm giảm cơ hội tham nhũng. Hãy tưởng tượng hướng dẫn "là hợp lệ" này của bạn bị lỗi bit trong bộ nhớ hoặc thanh ghi CPU ngay khi bạn muốn phân nhánh đến bộ xử lý lỗi.
eckes

11

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.


8
Trên bầu khí quyển có hai điều xảy ra: 1) tổng từ thông cao hơn 2) nhiều hơn nữa ở dạng các hạt nặng, rất năng lượng (có đủ năng lượng để lật một chút vào một không gian nhỏ).
dmckee --- ex-moderator mèo con

Liên quan đến tài liệu tham khảo, có những cuốn sách (ví dụ: Books.google.com/books?hl=vi&lr=&id=Er5_rzW0q3MC ), hội nghị (ví dụ: radecs2015.org , showsapld.org , và những cuốn khác) . Tia vũ trụ không phải là một trò đùa trong không gian vũ trụ. Chúng là một trong những lý do chính khiến nhiều tàu vũ trụ sử dụng máy tính cứng rad, hầu hết đều có khả năng xử lý của một lò nướng bánh thông minh hiện đại.
David Hammen

8

"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ụ". :-)


7

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.


Các bit bit tia vũ trụ có thể không được phân bố đồng đều, đặc biệt nếu chúng ta bao gồm các cơn bão mặt trời dưới "sự kiện tia vũ trụ" -um giác. Nếu bạn có hai bitflips trong cùng một byte, kiểm tra bit chẵn lẻ sẽ thất bại. Một số bitflips và thuật toán ECC có thể sẽ không thể sửa lỗi.
tobixen

5

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ụ.


Chắc chắn? Nó không thể là một biến chưa được khởi tạo mà không bao giờ có giá trị ban đầu xấu trong các thử nghiệm tiếp theo?
doug65536

Tôi luôn biên dịch với W3 hoặc W4 trên VS - Ngoài ra Rational Purify, không có lỗi nào thuộc loại đó.
rep_movsd

À, xin lỗi, tôi không biết rằng các tùy chọn trình biên dịch và Rational Purify hoàn toàn không thể sai được. =)
doug65536

Xem xét rằng mã sau đó đã được đưa vào sản xuất và được nén và giải nén hàng trăm GB đúng cách, không có dấu hiệu của một lỗi tương tự.
rep_movsd

4

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.


4

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.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.