Search
Write a publication
Pull to refresh

Comments 37

Ага, удивительно беззубый рассказ об очень интересной и сложной проблеме. Причем это не перевод ни о чем, а источник очень плохо написан. На фразах масштаба «Мы берём отдельные части, делаем их радиоактивными» я не знал, плакать или смеяться.
Судя по статье основная проблема в порче данных обрабатываемых в микросхемах.

Тут возникает вопрос, насколько сильно данный эффект будет отражаться на хранении данных в SSD и будет ли хранение данных в HDD более надежным (применительно к данному эффекту).
В SSD этот эффект тоже есть, но в них по не зависящим от космической радиации причинам используется помехоустойчивое кодирование. Оно не устраняет проблему полностью, но примерно на порядок уменьшает вероятность ее проявления.
UFO landed and left these words here
На первый взгляд, HDD более защищены (предположительно требуется большее воздействие более мощной частицы на большую площадь, чем требуется для bit flip в микросхеме; металлический корпус), что косвенно подтверждается отсутствием заметного числа текстов на эту тему, обычно обсуждается воздействие на RAM, реже SSD, практически никогда — HDD.


Металл для нейтрона не помеха, как атмосфера, крыша здания и корпус компьютера. Да и жесткий диск хранит данные в виде намагниченных областей на пластине. а не в виде электрического заряда, думаю пластинам частицы глубоко пофигу. А вот флеш-память — да, страдает.
UFO landed and left these words here
Хм, возможно. Спасибо за информацию. Но все равно нейтроны не должны влиять на пластины жесткого диска.
Зато могут на электронику записи-чтения.
Для защиты от bit rot сделали T10-PI, который считает чексуммы на всём пути от драйвера ОС до секторов на диске. Но дома и для медиархивов они не страшны.

Кстати, у LTO вероятность битовой ошибки на два порядка ниже (1 x 10^-19), чем у SSD (1 x 10^-17).

SSD насколько я понимаю имеет более крупные ячейки. Если и будет угроза, то скорее всего 4-х битовым SSD. Но там же есть еще алгоритмы коррекции, куда продвинутей чем для ОЗУ.

Так штук пять более толковых статей на эту тему есть на Хабре, не только то, что вы процитировали.
Так процитируйте, в чем проблема?
Ни в коем случае не хотел посягать на чей-то уровень толковости по этой теме своим сообщением. Извините, если что!!!
Если хочешь быть отцом — крышу покрывай свинцом!
Подобное происходит и с ASIC — повреждаются данные в регистрах/микрокод.
Подобное вообще в любой микросхеме происходит при попадании ионизирующих частиц.
Не пойму, если биты в RAM действительно иногда меняются, почему на бытовых ПК этого не видно?
Во-первых, слишком маленький объем памяти, чтобы накопить статистику. Во-вторых, у вас что, никогда комп не глючит? В-третьих, ECC же есть везде уже давно.
В-третьих, ECC же есть везде уже давно.
Как раз ны бытовых компах ECC нет, то есть заметить подобное повреждение попросту нечем. Если случайным образом флипать биты в программе, то она достаточно долго может вести себя разумно, а контрольных сумм, способных показать что «таки опа» нету…
В памяти и процессорах бытовых компов ECC, разумеется, есть. Как минимум для того, чтобы процент выхода годных был повыше, и чипы нормально себя вели с парой вылетевших ещё при производстве бит.
Но насчёт того, что случайный сбой в одном бите не всегда приводит к видимым последствиям — это вы правы.
Возможно мы говорим о разных вещах. Кеши в ядре обычно дейстивтельно используют ECC, чтобы повысить уровень годных. А вот ECC DRAM — это девять чипов вместо восьми и, соотвественно, память без ECC дешевле. Почему и используется в 90% (хорошо если не в 99%) случаев.

В бытовой dram памяти ddr2/ddr3/ddr4 (модули udimm) 9-го чипа для хранения ECC нет, на шину выходит 64 бита, а не 72.
Десктопный intel обычно не умеет работать с ddr4 ecc: https://ark.intel.com/products/126686/Intel-Core-i7-8700-Processor-12M-Cache-up-to-4_60-GHz ECC Memory Supported ‡ No
Ср. https://ark.intel.com/Search/FeatureFilter?productType=processors&ECCMemory=true и https://ark.intel.com/Search/FeatureFilter?productType=processors&ECCMemory=false


Не встречалась ли вам документация на четность или ecc внутри чипов dram?


Для повышения выхода годных делают запасные ряды — https://www.skhynix.com/static/filedata/fileDownload.do?seq=379 = DDR4_DeviceOperation.pdf


2.32 Post Package Repair (hPPR)
DDR4 supports Fail Row address repair as optional feature for 4Gb and required for 8Gb and above. Supporting hPPR is identified via Datasheet and SPD in Module so should refer to DRAM manufacturer’s Datasheet. PPR provides simple and easy repair method in the system and Fail Row address can be repaired by the electrical programming of Electrical-fuse scheme.

2.33 Soft Post Package Repair (sPPR)
of Repair elements 1 per BG 1 per BG

В продуктах на базе флеш-памяти используются — ECC, BCH (RS) и LDPC (вероятно, в контроллере, а не в самих массивах) https://www.usenix.org/sites/default/files/conference/protected-files/zhao_fast13_slides.pdf
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.644.1525&rep=rep1&type=pdf
http://www.public.asu.edu/~chaitali/jourpapers/chengen_TVLSI.pdf

ieeexplore.ieee.org/document/7087646
Вот например. В спецификацию ddr4 возможность встроенного ECC заложена (с выходом на шину 64 бит), а вот реализации — это уже к производителям чипов вопрос.
В спецификацию ddr4 возможность встроенного ECC заложена

Не укажете как это называется в стандарте или в какой его части описано? В JESD79-4.pdf сходу не нашел.
Сообщали от +20% площади и росте задержек — https://www.cs.utah.edu/thememoryforum/kang_slides.pdf "In-DRAM ECC ..but has in general large chip size overhead (~20% for X4 DRAM)"
Исследования похоже есть, но неясно, существуют ли такие чипы в серии…
https://arxiv.org/pdf/1704.03991.pdf "DRAM chips with On-Die ECC are already proposed for systems with DDR3, DDR4 and LPDDR4 standards [55, 31, 91]"

"4.16.1 CRC Polynomial and logic equation"


DDR4 supports CRC for write operation, and doesn’t support CRC for read operation.

Лучше чем ничего, но, кажется, это лишь защита на этапе транспорта пакета из контроллера памяти в чип ОЗУ. Хранение данных внутри массива этот CRC уже не использует.


PB_IM_ECC_DRAM.pdf — интересно… Для обычной памяти сослались на данные google


Although servers run under well-controlled environmental conditions, failure-rates counted in FIT (failure in time / per billion devices hours) of 25000 to 70000 FIT per Megabit were determined. Conversion into Gigabit and MTBF (mean time between failure) results in only 14 to 40 hours until the first bit flips in a standard 1 Gigabit DRAM chip as an average value.

для своей встроенной ecc заявили


The complete process of error-correction runs without any noticeable delays or latencies and does not require any specific hardware or software changes.

http://lph.ece.utexas.edu/merez/uploads/MattanErez/duo_hpca18.pdf
DUO: Exposing On-chip Redundancy to Rank-Level ECC for High Reliability optional CRC in DDR4 (+цитирования этой статьи)


s In-DRAM error checking and correcting (IECC)… IECC presents inefficiencies… because highly-reliable systems must also rely on rank-level ECC (RECC) with its own redundancy for tolerating severe operational faults such as device failures.… 6.25%

Нашел исследование от Onur Mutlu по выяснению типов ECC в LPDDR4 чипах. Один из 4 производителей (micron?) применяет "(128 + 8) Hamming Code"
https://people.inf.ethz.ch/omutlu/pub/EIN-understanding-and-modeling-in-DRAM-ECC_dsn19-talk.pdf
We experimentally test LPDDR4 DRAM devices
-232 with on-die ECC (one major manufacturer)
-82 without on-die ECC (three major manufacturers)
ECC scheme in LPDDR4 devices with on-die ECC to be a (128 + 8) Hamming Code


on-die ECC:Primarily mitigates technology scaling issues [1]
-Transparently mitigates random single-bit errors (e.g., VRT)
-Fully backwards compatible (no changes to DDRx interface)


Статья: https://people.inf.ethz.ch/omutlu/pub/EIN-understanding-and-modeling-in-DRAM-ECC_dsn19.pdf Understanding and Modeling On-Die Error Correctionin Modern DRAM: An Experimental Study Using Real Devices — ETH/CMU, DOI: 10.1109/DSN.2019.00017 Jun 2019

Во-вторых, у вас что, никогда комп не глючит?

Например, такого чтобы в набираем¿м тексте или коде вдруг появился левый симвɏл — ни разу не было.

Может конечно вероятность события раз в 100 лет, тогда да, у меня еще все впереди :)
UFO landed and left these words here
Да, это сильно :)

Кстати, программа «Штирлиц» помогла бы декодировать послание :)
www.softportal.com/software-3560-shtirlits.html
Когда-то давно пользовался, когда был зоопарк разных кодировок и текст мог попасться в любом формате WIN/DOS/KOI8/etc.
Потому как, если это лишь изредка проявляется на суперкомпьютерах, у которых зачастую объемы логики на многие порядки выше, чем у бытовых, а вычисления нередко задействуют почти всю доступную память (разумеется, так же на многие порядки превосходящую в объеме), да еще и при разного рода симуляциях, когда многие ошибки теоретически приводят к накоплению неверных результов (и это хоть как-то можно потом пост-фактум отследить), то можно предположить, что проблема в действительности очень редка. Интуитивно кажется, что шансов, что в домашний компьютер попадет молния — и то выше.
Проблема для домашних компьютеров действительно очень редка, но для суперов по всему миру она вполне осязаема.
Хинт: если все же хотите проверить сами, без супера, вам подойдет трансконтинентальный авиаперелет, на их высоте можно какую-то статистику набрать даже на небольшом объеме памяти.
Или можно стратостат запустить.
Запускал и запускаю, если бы все было так категорично как в заметке, то эти GPGPU можно было лишь на свалку свозить. Да, брак, несомненно бывает, и, мне кажется, заметка скорее об этом. А еще Nvidia довольно чувствительна к любым UB при синхронизации, и реально могут разъехаться данные в совсем неожиданных областях, а то, что эти UB могут быть созданы совсем даже «чужими» воркерами — не секрет, но уж очень я много разных вещественных рассчетов запускал, чтобы сказать, «не подтвержаю». А про целочисленные майнеры все могут рассказать.
Sign up to leave a comment.

Articles