Що таке пам'ять ECC. Що таке ECC RAM? Буферизована оперативна пам'ять – що це? Пам'ять із підтримкою ecc

На запитання Поясніть, що таке "Підтримка ECC" на оперативній пам'яті, заданий автором Оленканайкраща відповідь це це функція корекції помилок. така пам'ять ставиться на сервера, адже не можна щоб вони клали, відключалися чи перевантажувалися через помилок. для домашнього комп'ютера це не необхідна річ, хоч і корисна. якщо вирішили собі таку поставку-переконайтеся, що ваша матплата підтримує такий тип озу з ЕСС.
Джерело: ку

Відповідь від Rainswept[гуру]
ECC (Error Correct Code) - Виявлення та виправлення помилок (можливі інші розшифровки тієї ж абревіатури) - алгоритм, що прийшов на зміну "контролю парності". На відміну від останнього кожен біт входить більш ніж одну контрольну суму, що дозволяє у разі виникнення помилки в одному біті відновити адресу помилки і виправити її. Як правило, помилки у двох бітах також детектуються, хоч і не виправляються. Для реалізації цих можливостей на модуль встановлюється додаткова мікросхема пам'яті і він стає 72-розрядним, на відміну від 64 розрядів даних звичайного модуля. ECC підтримують всі сучасні материнські плати, призначені для серверних рішень, і навіть деякі чіпсети " загального призначення " . Деякі типи пам'яті (Registered, Full Buffered) випускаються лише у ECC варіанті. Слід зазначити, що ECC не є панацеєю від дефективної пам'яті і застосовується для виправлення випадкових помилок, знижуючи ризик виникнення несправностей у роботі комп'ютера від випадкової зміни вмісту осередків пам'яті, викликаного зовнішніми факторами, такими як фонова радіація.
Регістровані модулі пам'яті рекомендуються до використання в системах, що вимагають (або підтримують) 4 Гб і більше оперативної пам'яті. Вони мають розрядність 72 біта, т. е. є модулями з ЕСС, і містять додаткові мікросхеми регістрів для часткової буферизації.
PLL-Phase Locked Loop - ланцюг автопідстроювання частоти і фази сигналу, що служить для зниження електричного навантаження на контролер пам'яті та підвищення стабільності роботи при використанні великої кількості мікросхем пам'яті, застосовується у всіх буферизованих модулях пам'яті.
Buffered – буферизований модуль. Через високу сукупну електричну ємність сучасних модулів пам'яті, тривалий час їх "зарядки" призводить до великих витрат часу на операції запису. Щоб уникнути цього, деякі модулі (як правило, 168-контактні DIMM) забезпечуються спеціальною мікросхемою (буфером) , яка зберігає дані відносно швидко, що звільняє контролер. Буферизовані DIMM зазвичай несумісні з небуферизованими. Модулі з частковою буферизацією називаються також "реєстровим" ("Registered"), а модулі з повною буферизацією (Full Buffered) - "FB-DIMM". При цьому під "небуферизованими" маються на увазі звичайні модулі пам'яті без засобів буферизації.
Parity - парність, модулі з контролем парності, а також контроль парності. Досить старий принцип перевірки цілісності даних. Суть методу полягає в тому, що для байта даних на стадії запису обчислюється контрольна сума, яка зберігається як спеціальний біт парності в окремій мікросхемі. Під час читання даних контрольна сума обчислюється знову і порівнюється з бітом парності. Якщо вони збіглися, дані вважаються автентичними, інакше генерується повідомлення про помилку парності (як правило, що призводить до зупинення системи). До явних недоліків методу відносяться дорожнеча пам'яті, яка потрібна для зберігання зайвих біт парності, незахищеність від подвійних помилок (а також помилкове спрацювання при помилці в биті парності), зупинка системи навіть при непринциповій помилці (скажімо, у відеокадрі). Нині не застосовуються.
SPD - мікросхема на модулі пам'яті DIMM, яка містить усі дані про нього (зокрема, інформацію про швидкодію), необхідні для забезпечення нормальної роботи. Ці дані читаються на етапі самотестування комп'ютера ще задовго до завантаження операційної системи і дозволяють налаштувати параметри звернення до пам'яті навіть при одночасному наявності в системі різномастних модулів пам'яті. Деякі материнські плати відмовляються працювати з модулями, на яких не встановлена мікросхема SPD, проте такі модулі зараз дуже рідкісні і є переважно модулями PC-66.

Відповідь від Mowgley[гуру]
оперативна роверка пам'яті на помилки

Як я розумію, його докази такі:

У Google не використовували ECC, коли збирали свої сервери у 1999 році.
Більшість помилок ОЗП – це помилки систематичні, а не випадкові.
Помилки ОЗУ виникають рідко, тому що апаратне забезпеченняпокращало.
Якби пам'ять ECC мала насправді важливе значення, вона використовувалися скрізь, а чи не лише серверах. Плата за такий опціональний матеріал явно занадто сумнівна.

Давайте розглянемо ці аргументи один за одним:

1. У Google не використовували ECC у 1999 році

Якщо ви робите щось тільки через те, що колись це зробив Google, спробуйте:

A. Помістіть свої сервери у транспортні контейнери.

Сьогодні все ще пишуть статті про те, що це - чудова ідея, хоча Google лише провів експеримент, який був розцінений як невдалий. Виявляється, навіть експерименти Google не завжди вдаються. Фактично, їхня відома пристрасть до «проривних проектів» («луншоти») означає, що вони мають більше невдалих експериментів, ніж більшість компаній. На мою думку, для них це суттєва конкурентна перевага. Не варто робити цю перевагу більше, ніж вона є, сліпо копіюючи експерименти, що провалилися.

B. Викликайте пожежі у власних центрах обробки даних.

Частина посту Етвуда обговорює, наскільки дивними були ці сервери:

Деякі можуть подивитись ці ранні сервери Google і побачити непрофесійність щодо небезпеки пожежі. Не я. Я бачу тут далекоглядне розуміння того, як недороге стандартне обладнання формуватиме сучасний інтернет.

Остання частина висловленого – це правда. Але й у першій частині є частка правди. Коли Google почав розробляти власні плати, одне їх покоління мало проблему «зростання» ( ), що викликала ненульову кількість загорянь.

До речі, якщо ви перейдете до посту Джеффа і подивіться на фотографію, на яку посилається цитата, ви побачите, що на платах багато кабелів-перемичок. Це викликало проблеми та було виправлено у наступному поколінні обладнання. Також можна бачити досить неохайно виконану кабельну розводку, що додатково викликало проблеми і що було швидко усунуто. Були й інші проблеми, але я залишу їх як вправу для читача.

C. Створюйте сервери, які травмують ваших співробітників

Гострі грані одного з поколінь серверів Google заробили їм репутацію зроблених із «бритв і ненависті».

D. Створюйте погоду у ваших центрах обробки даних

Після розмов із співробітниками багатьох великих технологічних компаній створюється враження, що у більшості компаній був такий клімат-контроль, що в їхніх центрах обробки даних утворювалися хмари чи туман. Можна було б назвати це розважливим і підступним планом Google відтворення сіетлівської погоди, щоб переманювати співробітників Microsoft. Як варіант, це міг бути план створення буквально «хмарних обчислень». А може й ні.

Зверніть увагу, що все це Google спробував, а потім змінив. Робити помилки, а потім усувати їх - поширене явище в будь-якій організації, яка успішно займається розробками. Якщо ви обожнюєте інженерну практику, слід триматися принаймні за сучасну практику, а не за зроблене в 1999 році.

Коли Google використовував сервери без ECC в 1999 році, на них виявилася низка симптомів, які, як зрештою з'ясувалося, були спричинені пошкодженням пам'яті. У тому числі індекс пошуку, який повертав фактично випадкові результати до запитів. Реальний режим збою тут повчальний. Я часто чую, що на цих машинах можна ігнорувати ECC, тому що помилки в окремих результатах є допустимими. Але навіть якщо ви вважаєте для себе випадкові помилки припустимими, їх ігнорування означає, що існує небезпека повного пошкодження даних, якщо не проводити ретельний аналіз з метою переконатися, що одна помилка може лише трохи спотворити один результат.

У дослідженнях, проведених на файлових системах, неодноразово було показано, що, незважаючи на героїчні спроби створення систем, стійких до однієї помилки, зробити це дуже складно. По суті, кожна файлова система, що сильно тестується, може мати серйозний збій через єдину помилку (). Я не збираюся нападати на розробників файлових систем. Вони краще розуміються на такому аналізі, ніж 99,9% програмістів. Просто неодноразово вже було показано, що ця проблема настільки важка, що люди не можуть обґрунтовано обговорювати її, і автоматизований інструментальний засіб для такого аналізу ще далеко від процесу простого натискання кнопки. У своєму довіднику з комп'ютерної обробки складських даних Google обговорює виявлення та виправлення помилок, і пам'ять ECC розглядається як правильний варіант, коли очевидно, що необхідно використовувати виправлення помилок апаратного забезпечення ( ).

Google має чудову інфраструктуру. З того, що я чув про інфраструктуру в інших великих інфотехнологічних компаніях, Google є найкращим у світі. Але це не означає, що слід копіювати все, що вони роблять. Навіть якщо розглядати лише їхні добрі ідеї, для більшості компаній немає сенсу копіювати їх. Вони створили заміну планувальнику перехоплення робіт Linux, який використовує як апаратну інформацію часу виконання, так і статичні трасування, щоб дозволити використовувати переваги нового обладнання в серверних процесорах Intel, що дозволяє динамічно розбивати кеш між ядрами . Якщо використовувати це на всьому їхньому обладнанні, то Google заощадить за тиждень більше грошей, ніж компанія Stack Exchange витратила на всі свої машини за всю свою історію. Чи означає це, що ви повинні скопіювати Google? Ні, якщо на вас уже не впала манна небесна, наприклад, у вигляді того, що ваша основна інфраструктура написана на високооптимізованому C++, а не на Java або (не дай Боже) Ruby. І справа в тому, що для переважної більшості компаній написання програм мовою, яка тягне за собою 20-кратне зниження продуктивності, - цілком розумне рішення.

2. Більшість помилок ОЗУ – це систематичні помилки

Аргументація проти ECC відтворює наступний розділ дослідження помилок DRAM (виділення дано Джеффом):

Наше дослідження має кілька основних результатів. По-перше, ми виявили, що приблизно 70% збоїв DRAM є повторюваними (наприклад, постійними) збоями, тоді як тільки 30% є нестійкими (переміжними) збоями. По-друге, ми виявили, що великі багатобітові збої, такі як збої, які зачіпають весь рядок, стовпець або блок, становлять понад 40% усіх збоїв DRAM. По-третє, ми виявили, що майже 5% відмови DRAM впливають на схеми на рівні плати, такі як лінії даних (DQ) або стробування (DQS). Нарешті ми виявили, що функція Chipkill зменшила частоту відмов системи, викликаних збоями DRAM, в 36 разів.

Цитата здається дещо іронічною, оскільки вона виглядає не аргументом проти ECC, а аргументом за Chipkill – певний клас ECC. Відклавши це убік, пост Джеффа вказує, що систематичні помилки зустрічаються вдвічі частіше, ніж помилки випадкові. Потім пост повідомляє, що вони запускають мемтест на своїх машинах, коли відбуваються систематичні помилки.

По-перше, співвідношення 2:1 не таке велике, щоб просто ігнорувати випадкові помилки. По-друге, пост має на увазі віру Джефа, що систематичні помилки, по суті, незмінні і не можуть виявитися через деякий час. Це не вірно. Електроніка зношується так само, як зношуються механічні пристрої. Механізми різні, але ефекти схожі. Дійсно, якщо порівняти аналіз надійності чіпів з іншими видами аналізу надійності, то можна бачити, що вони часто використовують ті самі сімейства розподілів для моделювання відмов. По-третє, перебіг міркувань Джеффа має на увазі, що ECC не може допомогти у виявленні чи виправленні помилок, що не тільки невірно, а й прямо суперечить цитаті.

Отже, як часто ви збираєтеся запускати memtest на своїх машинах у спробах зловити ці системні помилки та скільки втрат даних ви готові пережити? Одне з ключових застосувань ECC полягає не в тому, щоб виправити помилки, а в тому, щоб сигналізувати про помилки, завдяки чому обладнання може бути замінене до того, як станеться "silent corruption" ("приховане пошкодження даних"). Хто погодиться закривати все на машині щодня, щоб запустити memtest? Це було б набагато дорожче, ніж просто купити ECC пам'ять. І навіть якби ви змогли переконати ганяти тестування пам'яті, memtest не виявив би стільки помилок, скільки зможе знайти ECC.

Коли я працював у компанії з парком приблизно тисячу машин, ми помітили, що у нас відбуваються дивні відмови при перевірці цілісності даних, і приблизно через півроку ми зрозуміли, що відмови на одних машинах вірогідніші, ніж на інших. Ці відмови були досить рідкісними (можливо, кілька разів на тиждень у середньому), тому знадобилося багато часу для накопичення інформації та розуміння, що ж відбувається. Без знання причини аналіз логів з метою зрозуміти, що помилки були спричинені поодинокими випадками інвертування бітів (з великою ймовірністю), також був нетривіальним. Нам пощастило, що як побічний ефект процесу, який ми використовували, контрольні суми обчислювалися в окремому процесі на іншій машині в різний час, тому помилка не могла спотворити результат і поширити це пошкодження на контрольну суму.

Якщо ви просто намагаєтеся захистити себе за допомогою контрольних сум у пам'яті, є чимала ймовірність того, що ви виконаєте операцію обчислення контрольної суми на вже пошкоджених даних і отримаєте правильну контрольну суму неправильних даних, якщо ви не робите деякі дійсно незвичайні операції з обчисленнями, які дають їх власні контрольні суми. А якщо ви серйозно ставитеся до виправлення помилок, то ви, ймовірно, все ж таки використовуєте ECC.

У всякому разі, після завершення аналізу ми виявили, що memtest не міг виявити будь-які проблеми, але заміна ОЗУ на поганих машинах призвела до зменшення частоти помилок на один-два порядки. Більшість сервісів немає такого роду контрольних сум, які були у нас; ці послуги просто мовчки записуватимуть пошкоджені дані в постійне сховище і не побачать проблему, поки клієнт не почне скаржитися.

3. Завдяки розвитку апаратного забезпечення помилки стали дуже рідкісними

Даних у пості замало такого твердження. Зверніть увагу, що оскільки використання ОЗП зростає та продовжує збільшуватися експоненційно, відмови ОЗП повинні зменшуватися з більшою експонентною швидкістю, щоб фактично зменшити частоту пошкодження даних. Крім того, оскільки чіпи продовжують зменшуватися, елементи стають меншими, що робить актуальнішими проблеми зносу, що обговорюються в другому пункті. Наприклад, за технології 20 нм конденсатор DRAM може накпливати десь електронів 50, і це число буде меншим для наступного покоління DRAM при збереженні тенденції зменшення.

Ще одне зауваження: коли ви платите за ECC, ви платите не просто за пам'ять ECC – ви платите за деталі (процесори, плати), які є якіснішими. Таке легко можна бачити із частотою відмови дисків, і я чув, що багато хто помічає таке у своїх особистих спостереженнях.

Якщо наводити загальнодоступні дослідження: наскільки пам'ятаю, група Андреа та Ремзі кілька років тому випустила документ SIGMETRICS, який показав, що ймовірність збою при читанні у диска SATA у 4 рази вища, ніж у диска SCSI, а ймовірність прихованого пошкодження даних – у 10 разів вища . Це співвідношення зберігалося навіть у разі використання дисків одного виробника. Немає особливої причини думати, що інтерфейс SCSI має бути надійнішим, ніж інтерфейс SATA, але йдеться не про інтерфейс. Йдеться про купівлю високонадійних серверних компонентів, порівняно з клієнтськими. Можливо, надійність диска вас не цікавить, тому що у вас все на контрольних сумах, і пошкодження легко знаходяться, але є деякі види порушень, які виявити важче.

4. Якби пам'ять ECC мала дійсно важливе значення, то її використовували б скрізь, а не тільки в серверах.

Трохи перефразовуючи цей аргумент, можна сказати, що «якби ця характеристика була дійсно важлива для серверів, то вона використовувалася б і в не-серверах». Можна застосувати цей аргумент до досить великої кількості апаратних засобів сервера. Насправді, це одна з найбільш неприємних проблем, що стоять перед великими постачальниками хмарних рішень.

Вони мають достатньо важелів впливу, щоб отримувати більшість компонентів за відповідною ціною. Але поторгуватися вийде лише там, де є більше одного життєздатного постачальника.

Однією з небагатьох областей, де немає життєздатних конкурентів, є виробництво центральних процесорів і відеоприскорювачів. На щастя для великих постачальників, відеоприскорювачі їм зазвичай не потрібні, потрібні процесори, багато вже давно так склалося. Було кілька спроб постачальників процесорів увійти на серверний ринок, але завжди кожна така спроба з самого початку мала фатальні недоліки, що робили очевидною її приреченість (а це часто проекти, що вимагають не менше 5 років, тобто необхідно було витратити багато часу без впевненості в успіху).

Зусилля Qualcomm отримали багато шуму, але коли я спілкуюся з моїми контактами в Qualcomm, вони всі говорять мені, що зроблений в даний момент чіп призначений, по суті, для проби. Так вийшло, тому що компанії Qualcomm потрібно було дізнатися, як зробити серверний чіп, у всіх фахівців, яких вона переманила з IBM, і що наступний чіп буде першим, який, можна сподіватися, стане конкурентоспроможним. Я покладаю великі надії на Qualcomm, а також на зусилля ARM щодо створення хороших серверних компонентів, але ці зусилля поки що не дають бажаного результату.

Майже повна непридатність поточних варіантів ARM (і POWER) (не рахуючи гіпотетичних варіантів вражаючого чіпа ARM від Apple) для більшості робочих навантажень серверів з точки зору продуктивності на долар сукупної вартості володіння (TCO) - ця тема трохи осторонь, тому я залишу її для іншої публікації. Але річ у тому, що Intel має таку позицію на ринку, що може змусити людей платити зверху за серверні функції. І Intel це робить. Крім того, деякі функції дійсно важливіші для серверів, ніж для мобільних пристроївз кількома гігабайтами оперативної пам'яті та енергетичним бюджетом у кілька ватів, мобільних пристроїв, від яких все одно очікують періодичні вильоти та перезавантаження.

Висновок

Чи слід купувати ECC-ОЗУ? Це залежить багато від чого. Для серверів це, мабуть, хороший варіант, враховуючи витрати. Хоча насправді важко провести аналіз витрат/вигод, тому що досить складно визначити збитки від прихованого пошкодження даних або витрати на ризик втратити півроку часу розробника на відстеження збоїв, що перемежуються, тільки щоб виявити, що вони викликані використанням пам'яті без ECC.

Для настільних комп'ютерів я також прихильник ECC. Але якщо ви не робите регулярні бекапи, то вам корисніше вкластися в регулярні бекапи, ніж в ECC-пам'ять. І якщо у вас є резервні копіїбез ECC, ви можете легко записати пошкоджені дані в основне сховище і реплікувати ці пошкоджені дані в резервну копію.

Дякую Прабхакару Рагді, Тому Мерфі, Джею Вайскопфу, Лії Хансон, Джо Вайлдеру та Ральфу Кордерою за обговорення/коментарі/виправлення. Крім того, дякую (або, можливо, не-дякую) Лії за те, що переконала мене написати цей усний експромт як пост у блозі. Просимо вибачення за будь-які помилки, відсутність посилань і підвищену прозу; це, по суті, запис половини обговорення, і я не пояснив умови, не надав посилання або не перевірив факти на рівні деталізації, як я зазвичай роблю.

Одним із кумедних прикладів є (принаймні для мене) магічна плавка перемичка, що самовідновлюється. Хоча реалізацій багато, уявімо собі плавку перемичку на чіпі як певний резистор. Якщо ви пропускаєте через неї якийсь струм, ви повинні отримати з'єднання. Якщо струм занадто великий, то резистор розігріється і зруйнується. Це зазвичай використовується для відключення елементів на мікросхемах або таких дій, як завдання тактової частоти. Основний принцип у тому, що після згоряння перемички немає можливості повернути їх у вихідний стан.

Давним давно жив і був виробник напівпровідникових пристроїв, який трохи поспішно зі своїм виробничим процесом і дещо надмірно зменшив допуски в деякому технологічному поколінні. Через кілька місяців (або років) з'єднання між двома кінцями подібної перемички змогло знову з'явитися та відновити його. Якщо вам пощастить, то така перемичка буде чимось на зразок старшого біта множника тактової частоти, який у разі зміни буде виводити чіп з ладу. Якщо не пощастить, це призведе до прихованого пошкодження даних.

Я чув від багатьох людей у різних компаніях про проблеми в цьому технологічному поколінні цього виробника, тому це не були окремі випадки. Коли я говорю, що це смішно, я маю на увазі, що кумедно почути цю історію в барі. Менш цікаво виявити через рік тестування, що деякі з ваших чіпів не працюють, тому що їх установки для перемичок безглузді, і потрібно переробити ваш чіп і відкласти випуск на 3 місяці. До речі, ця ситуація з відновленням плавки перемички - ще один приклад класу помилок, гостроту яких можна згладити за допомогою ECC.

Це не проблема Google; я згадую про це тільки тому, що багато людей, з якими спілкуюся, здивовані тим, яким чином апаратне забезпечення може вийти з ладу.

Якщо ви не хочете копатися у всій книзі, то ось потрібний фрагмент:

У системі, яка може витримати ряд відмов на програмному рівні, мінімальна вимога до апаратної частини полягає в тому, що збої цієї частини завжди виявляються і повідомляються. програмного забезпеченнядостатньо своєчасно, щоб дозволити програмній інфраструктурі обмежити їх та вжити відповідних дій щодо відновлення. Необов'язково, щоб апаратне забезпечення справлялося з усіма збоями. Це не означає, що обладнання для таких систем має бути спроектоване без можливості виправлення помилок. Всякий раз, коли функціональні можливостівиправлення помилок можуть бути запропоновані з розумною ціною або складністю, їх підтримка часто окупається. Це означає, що якщо апаратна корекція помилок була б надзвичайно дорогою, то система могла б мати можливість використання більш дешевої версії, яка надавала б можливості тільки виявлення. Сучасні системи DRAM є гарним прикладом ситуації, в якій потужна корекція помилок може бути надана за дуже низьких додаткових витрат. Однак пом'якшення вимоги про виявлення апаратних помилок було набагато складніше, оскільки це означало б, що кожен програмний компонент був би обтяжений необхідністю перевірки його власного правильного виконання. На початковому етапі своєї історії Googleдовелося мати справу з серверами, на яких у DRAM був відсутній контроль парності. Створення індексу веб-пошуку складається, по суті, з дуже великої операції сортування/злиття, яка використовує кілька машин. У 2000 році одне із щомісячних оновлень веб-індексу Google не пройшло попередню перевірку, коли виявилося, що деяке підмножина перевірених запитів повертає документи, мабуть, випадковим чином. Після деякого дослідження в нових індексних файлах було виявлено ситуацію, яка відповідала фіксації біта на нулі в певному місці в структурах даних, що було негативним побічним ефектом потокової передачі великої кількості даних через несправний чіп DRAM. До структур даних індексу були додані перевірки несуперечності, щоб звести до мінімуму ймовірність повторення цієї проблеми, і надалі проблем такого характеру не було. Однак слід зазначити, що цей спосіб не гарантує 100% виявлення помилок у проході індексації, так як не всі позиції пам'яті перевіряються – інструкції, наприклад, залишаються без перевірки. Це спрацювало тому, що структури даних індексу були настільки більшими, ніж усі інші дані, що беруть участь у обчисленні, що наявність цих самоконтрольованих структур даних робило дуже ймовірним, що машини з дефектним DRAM будуть ідентифіковані та виключені з кластера. Наступне покоління машин Google вже містило виявлення парності в пам'яті, і як тільки ціна пам'яті з ECC опустилася до конкурентного рівня, всі наступні покоління використовували ECC-DRAM.

Теги: Додати теги

Також схеми ECC-захист даних можуть застосовуватися для вбудованої в мікропроцесори пам'яті: кеш-пам'яті, регістрового файлу. Іноді контроль також додають до обчислювальних схем.

Опис проблеми

Існують побоювання, що тенденція до зменшення фізичних розмірів модулів пам'яті призведе до збільшення частоти помилок через те, що частинки менших енергій будуть здатні змінити біт. З іншого боку, компактні розміри пам'яті зменшують ймовірність потрапляння частинок до неї. Крім того, перехід на такі технології, як кремній на ізоляторі може зробити пам'ять більш стійкою.

Дослідження, проведене на великій кількості серверів Google, показало, що кількість помилок може бути в межах від 25 000 до 70 000 помилок за мільярд робочих годин (англ. device hours) на мегабіт (тобто 2,5-7,0 × 10 − 11 помилок / біт · год) .

Технологія

Одним із рішень цієї проблеми є контроль парності - використання додаткового біта, який записує парність інших бітів. Такий підхід дозволяє виявляти помилки, але не дозволяє виправляти їх. Таким чином, при виявленні помилки можна тільки перервати виконання програми.

Більш надійним є підхід, у якому використовується коди з корекцією помилок . Найчастіше використовуваним кодом з корекцією помилок, є код Хеммінга. Більшість пам'яті з корекцією помилок, що використовуються в сучасних комп'ютерах, можуть виправляти помилку одного біта в одному 64-бітному машинному слові і визначити, але не виправити помилку в двох бітах в одному 64-бітному слові.

Найбільш ефективний підхід до виправлення помилок залежить від виду очікуваних помилок. Часто передбачається, що зміна різних біт відбувається незалежно. І тут ймовірність двох помилок у одному слові зневажливо мала. Однак це припущення не виконується для сучасних комп'ютерів. Пам'ять, основна на технології корекції помилок Chipkill(IBM), дозволяє виправляти кілька помилок, у тому числі і при псуванні цілого чіпа пам'яті. Інші технології корекції пам'яті, які не припускають незалежності помилок у різних бітах, включають Extended ECC(Sun Microsystems), Chipspare(Hewlett-Packard) та SDDC(Intel).

Багато старих систем не повідомляли про виправлені помилки, повідомляючи лише про виявлені помилки, які неможливо було виправити. Сучасні системи записують як виправлені помилки (CE, англ. correctable errors), так і помилки, що не виправляються (UE, англ. uncorrectable errors). Це дозволяє вчасно замінити зіпсовану пам'ять: незважаючи на те, що велика кількість виправлених помилок при відсутності помилок, що не виправляються, не впливає на коректність роботи пам'яті, це може свідчити про те, що для даного модуля пам'яті ймовірність появи невиправних помилок в майбутньому зросте.

Перевага та недоліки

Пам'ять з корекцією помилок захищає від некоректної роботи комп'ютерної системи у зв'язку з псуванням пам'яті та зменшує ймовірність фатальної відмови системи. Однак така пам'ять коштує дорожче; материнська плата, чіпсет і процесор, які підтримують пам'ять з корекцією помилок, теж можуть бути дорожчими, тому така пам'ять використовується в системах, в яких важлива безперебійна та коректна робота, таких як файловий сервер, наукові та фінансові програми.

Пам'ять з корекцією помилок працює на 2-3% повільніше (часто для перевірки сум потрібно один додатковий такт контролера пам'яті), ніж звичайна пам'ять, залежно від додатків. Додаткова логіка, що реалізує підрахунок, перевірку ECC та виправлення помилок, вимагає логічних ресурсів і часу на свою роботу або в самому контролері пам'яті, або в інтерфейсі між CPU та контролером пам'яті.

Див. також

Примітки

Werner Fischer. RAM Revealed (неопр.) . admin-magazine.com. Дата звернення 20 жовтня 2014 року.
Архівована копія (неопр.) (недоступне посилання). Дата звернення 20 листопада 2016 року. Архівовано 18 квітня 2016 року.
Single Event Upset на Ground Level, Eugene Normand, Member, IEEE, Boeing Defense & Space Group, Seattle, WA 98124-2499
"A Survey of Techniques for Modeling and Improving Reliability of Computing Systems", IEEE TPDS, 2015
Кузнєцов В. В. Сонячно-земна фізика (курс лекцій для студентів фізиків). Лекція 7. Сонячна активність. // Сонячні бурі. Гірничо-Алтайський державний університет. 2012
Gary M. Swift та Steven M. Guertin. "In-Flight Observations of Multiple-Bit Upset in DRAMs". Jet Propulsion Laboratory
Borucki, "Comparison of Accelerated DRAM Soft Error Rates Measured at Component and System Level", 46th Annual International Reliability Physics Symposium, Phoenix, 2008, pp. 482–487
Schroeder, Bianca; Pinheiro, Eduardo; Weber, Wolf-Dietrich. DRAM Errors in the Wild: A Large-Scale Field Study (неопр.) // SIGMETRICS/Performance. - ACM, 2009. - ISBN 978-1-60558-511-6.
За допомогою StrongArm SA-1110 в On-Board Computer of Nanosatellite (неопр.) . Tsinghua Space Center, Tsinghua University, Beijing. Дата звернення 16 лютого 2009 року. Архівовано 2 жовтня 2011 року.
Doug Thompson, Mauro Carvalho Chehab. "EDAC - Error Detection And Correction" Архівовано 5 вересня 2009 року. . 2005–2009. "The "edac" kernel module goal is to detect and report errors that occur within the computer system running under linux."
Discussion of ECC on pcguide (неопр.) . Pcguide.com (17 квітня 2001 року). Дата звернення 23 листопада 2011 року.

Сторінка 1 з 10

У Мережі часто можна побачити на тематичних форумах питання щодо пам'яті з корекцією помилок, а саме – її вплив на продуктивність системи. Сьогоднішнє тестування відповість на це запитання.

Перед прочитанням даного матеріалу рекомендуємо ознайомитися з матеріалами з і платформі LGA1151.

Теорія

Перед тестуванням розповімо про помилки пам'яті.
Помилки, що виникають у пам'яті, можна розділити на два типи – апаратні та випадкові. Причиною появи перших є дефектні мікросхеми DRAM. Другі виникають через вплив електромагнітних перешкод, випромінювання, альфа- і елементарних частинок тощо. Відповідно, виправити апаратні помилки можна лише шляхом заміни мікросхем DRAM, а випадкові – за допомогою спеціальних технологій, наприклад ECC (Error-Correcting Code). Корекція помилок ECC у своєму арсеналі має два методи: SEC (Single Error Correction) та DED (Double Error Detection). Перший виправляє однобітові помилки у 64-бітному слові, а другий детектує двобітові помилки.
Апаратна реалізація ECC полягає у розміщенні додаткових чіпів пам'яті, які необхідні для запису 8-бітових контрольних сум. Таким чином, модуль пам'яті з корекцією помилок при односторонньому дизайні матиме 9 чіпів пам'яті замість 8 (як стандартного модуля), а при двосторонньому - 18 замість 16. Разом з цим збільшується і ширина модуля з 64 до 72 біт.
При зчитуванні даних із пам'яті відбувається повторний підрахунок контрольної суми, яка порівнюється з вихідною. Якщо помилка в одному биті – вона виправляється, якщо у двох – детектується.

Практика

Теоретично все добре - пам'ять з корекцією помилок підвищує надійність системи, що дуже важливо при побудові сервера або робочої станції. А на практиці існує ще й фінансова сторона цього питання. Якщо серверу пам'ять з корекцією помилок обов'язкова, то робоча станція може обійтися без ECC (багато готових робочих станцій різних виробників оснащуються звичайної ОЗУ). Наскільки ж дорожча пам'ять із корекцією помилок?
Типовий модуль DDR4-2133 з об'ємом 8 ГБ коштує близько 39 доларів, а модуль з ECC – 48 доларів (на момент написання матеріалу). Різниця у вартості становить близько 23%, що дуже значно на перший погляд. Але якщо подивитися на загальну вартість робочої станції, то ця різниця не перевищить 5% від неї. Таким чином, придбання пам'яті з ECC лише трохи збільшує вартість робочої станції. Залишається лише питання – як впливає пам'ять з ECC на продуктивність процесора.
Для того, щоб відповісти на це запитання, редакція сайт взяла для тестування модулі пам'яті Samsung DDR4-2133 ECC та Kingston DDR4-2133 з однаковими таймінгами 15-15-15-36 та об'ємом 8 ГБ.

На модулях пам'яті Samsung M391A1G43DB0-CPB з корекцією помилок розпаяно по 9 чипів з кожного боку.

На звичайних модулях пам'яті Kingston KVR21N15D8/8 розпаяно по 8 чіпів з кожного боку.

Тестовий стенд: Intel Xeon E3-1275v5, Supermicro X11SAE-F, Samsung DDR4-2133 ECC 8GB, Kingston DDR4-2133 non-ECC 8GB

Деталізація

Процесор: (HT on; TB off);
- Материнська плата: ;
- Оперативна пам'ять: 2x (M391A1G43DB0-CPB), 2x (KVR21N15D8/8);
- ОС: .

Методика тестування

3DMark06 1.21;
- 7zip 15.14;
- AIDA64 5.60;
- Cinebench R15;
- Fritz 4.2;
- Geekbench 3.4.1;
- LuxMark v3.1;
- MaxxMEMI 1.99;
- PassMark v8;
- RealBench v2.43;
- SiSoftware Sandra 2016;
- SVPmark v3.0.3b;
- TrueCrypt 7.1a;
- WinRAR 5.30;
- wPrime 2.10;
- x264 v5.0.1;
- x265 v0.1.4;
- Кракен;
- Octane;
- Octane 2.0;
- Peacekeeper;
- SunSpider;
- WebXPRT.