Как стать автором
Обновить

Комментарии 49

Поддерживаю. И сам не пользуюсь продукцией Интел, дома был, есть и будет АМД :) Убирать коррекцию ошибок (ЕСС) по-моему несколько… назовем это "недальновидно". И я на стороне АМД в этом вопросе

В общем, "F*ck you, Intel".

Жестко как-то

Ну почему же...


НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь

Сколько ненависти. Не объективно как-то.

А для обычного человека без Threadripper 3970X за 150к есть какой-то смысл в ECC?

Смысл есть всегда, как минимум это позволяет избежать скрытые ошибки (bit rot и подобное), которые вполне возможно еще и переползут на диск и никакими контрольными суммами не обнаруживаются. Те же NAS (а сейчас у народа десятки терабайт там) могут страдать из-за этого и никакой ZFS не поможет.

А реальные кейсы есть?

Вот 20 лет с обычной оперативкой. ECC встречается только в серверах.
Судя по гуглу для десктопов оно нафиг не нужно, только замедлит работу, хоть и незначительно. Те, кому оно надо возьмут себе сециальную сборку. Кому не надо и не знают что оно есть.

Лично у меня было достаточно случаев тихого повреждения данных — что-то не открывалось, не разархивировалось и так далее. Какая была причина — bit flip памяти или bit rot на дисках — фиг его знает, это не выяснишь. Поэтому для нового NAS я взял ECC память от bit flip и наверну ZFS от bit rot. Это не панацея, но уже сильно увеличивает надёжность.

Это паранойя.
что-то не открывалось, не разархивировалось и так далее
у вас либо по причине изменений поддерживаемых софтом форматов, либо банальным повреждением файлов вследствие сбоя ФС. Обычному пользователю в домашних условиях даже с десятками терабайт архивов никогда не столкнуться с этим проблемами.
ECC имеет смысл, но только когда вы — корпорация и у вас петабайты значимых и постоянно меняющихся данных.
лол ват
на моей памяти реально было как минимум 5 случаев когда в оперативке был поврежден определенный диапазон адресов, система падала после установки, писала кривые данные на диск и тд, висла на рандоме, причем иногда именно на бенчмарках показывала себя стабильно, тк бенч не попадал на поломанный диапазон, спасал только мемтест

именно из-за оперативки бились данные на диске, и все думали что проблемы именно в нем

то что лично вы с этим не сталкивались — рекомендую почитать теорию «черного лебедя»

разгон и/или уже подыхающая память. Пример: в прошлом году купил я память ддр-4 3000, а она даже с разгоном работала максимум на 2800. И я полгода пытался её разогнать (благо на хорошей материнке настраивается вообще всё), теперь память работает на 3066 на одной материнке и на временно взятой второй запускалась без ошибок на 3133. А чуть выше — ошибки в тестах. Ещё чуть — и если грузилась винда, проблемы были с софтом. И т.п. Влияли и напряжения на озу и в разных частях процессора, причём внезапно не особо относящиеся к памяти.

или уже подыхающая память

Вот прелесть ecc в том, что она позволяет диагностировать «подыхающую память».

Нет, не паранойя. Каких форматов? RAR/ZIP/JPEG изменились?


Я иногда просматриваю фотки, которым лет 15-20 и которые перекочевали через несколько носителей — и там иногда встречается одна-другая битая, хотя раньше они открывались. Bit rot в своей красе, а может и bit flip в процессе переноса. Какие-то архивы ZIP/RAR тоже бывало не распаковывались с CRC ошибками.


Обычному пользователю в домашних условиях даже с десятками терабайт архивов никогда не столкнуться с этим проблемами.

Мда?
У современных дисков заявленная надежность — 1 ошибка на 10^14 бит — можно увидеть в любом даташите. Это всего лишь ~12.5 ТБ — то есть при размерах современных дисков в 20+ТБ уже не получится даже один диск записать без ошибок в среднем.


Далее по ECC — есть такое исследование на данных Гугла: http://www.cs.toronto.edu/~bianca/papers/sigmetrics09.pdf


3751 скорректированная ошибка на одном DIMM в год в среднем. И это на серверных модулях, которые в среднем должны быть надежнее домашних.

Всетаки битые сектора на дисках — более частая проблема, чем битые сектора в памяти. Такчто очень не факт, что чтото повредилось именно из-за памяти.
Да и вообще, какая часть операций (тоже копирование файлов) проходит через оперативку?
Всетаки битые сектора на дисках — более частая проблема, чем битые сектора в памяти.

Битый сектор на диске — не проблема, он детектируется штатно и корректируется либо реаллокейтом либо диск выбрасывается из рейда. А тут речь идёт о https://en.wikipedia.org/wiki/Data_degradation который происходит тихо.


Да и вообще, какая часть операций (тоже копирование файлов) проходит через оперативку?

Всмысле? 100% естественно.


И в современных ОС данные обычно пишутся асинхронно и не журналируются (в журнал идут только метаданные), поэтому довольно долгое время сидят в dirty cache в оперативке если не делается fsync.

Битый сектор на диске — не проблема, он детектируется штатно и корректируется либо реаллокейтом либо диск выбрасывается из рейда. А тут речь идёт о en.wikipedia.org/wiki/Data_degradation который происходит тихо.


И это никак не детектируется? Интересно было бы об этом более подробно узнать. (речь именно про жесткие/ssd диски)

Всмысле? 100% естественно.

Тоесть копирование файла идет через оперативную память? Не знал, думал, может есть команды какие специальные
И это никак не детектируется?

Детектируется, если есть соответствующая файловая система вроде ZFS/BTRFS или есть слой dm-integrity с контрольными суммами блоков на диске. На уровне просто жесткого диска — нет.


Тоесть копирование файла идет через оперативную память?

Ну а как еще? Прочитал кусок в память, потом записал его в другое место.

через аппаратный буфер на диске? Или всё сложнее?

И это никак не детектируется? Интересно было бы об этом более подробно узнать.
Для важных файлов рядом класть файл с чек-суммами и периодически сравнивать. В архивных форматах (7z rar zip) чек-суммы интегрированы.
В imac pro и mac pro есть ECC память. Несколько старая статистика гугла про это www.cs.toronto.edu/~bianca/papers/sigmetrics09.pdf
Я бы крайне не хотел, чтоб такое происходило, даже раз в 2-3 года.
Основатель Linux упрекнул компанию за то, что она полностью заблокировала поддержку ECC на своих потребительских наборах микросхем и процессорах.

Это где она его заблокировала? Только в 2019 вышел 21 процессор (потребительского сегмента) с поддержкой ECC (Core i3, Celeron G & Pentium G), всего же на настоящий момент их аж 85 штук.


Хотя если уж говорить о потребительском сегменте, то ценность ECC памяти очень сильно преувеличена, массовый потребитель просто не ощутит разницы (кроме цены — она явно вырастет).

Это где она его заблокировала?

У него речь идёт про лет 10-20 назад когда синие были полными монополистами. А в 2019 году Интел, возможно, ощутил горение жопы от Ryzen-ов и прочих Эпиков и начал поворачиваться к народу фасадом.


массовый потребитель просто не ощутит разницы (кроме цены — она явно вырастет).

Он может это ощутить когда какой-нибудь архив без избыточности не распакуется например. Ибо побился тихонько. А цена на ECC память выше совсем незначительно (а иногда вообще такая же) — и она будет падать если спрос вырастет.


В общем лично я согласен с Торвальдсом — у нас нынче уже куча ЕСС в железе (жесткие диски, всякие PCI Express с избыточным 10b/8b кодированием и прочая прочая), а в памяти почему-то нет, хотя если что-то испортится там — никакой другой ECC не поможет.

А цена на ECC память выше совсем незначительно
А вот скорость ниже (2999 МГц сейчас уже не особо котируются, всем подавай 3600 и выше). Придётся разгонять (и тут привет Intel, у которой для разгона памяти извольте купить плату на топовом чипсете).
А вот скорость ниже

Это, как мне кажется, вопрос спроса и предложения. Будет спрос — будет скорость нужная. Как уже тут писали — DDR5 будет иметь так называемый on-die ECC т.е. без отдельной микросхемы как сейчас. Надо будет поглядеть как это будет работать...

НЛО прилетело и опубликовало эту надпись здесь

Глупо было бы отрицать ценность ECC памяти в принципе, но мне кажется что в обычных условиях всё же она явно избыточна.


За последние лет 15 на десятках серверов с ECC памятью я не помню ни одного случая коррекции который не сопровождался бы полным вылетом памяти — обычно модуль начинает сбоить, система успевает это записать в логи и почти сразу за этим всё вешается — т.е. коррекция вообще не помогает, а модуль приходится менять. Были и случаи когда модули просто жёстко умирали — т.е. система просто не грузится с умершим (что примечательно — ни одного такого случая с обычными, не ECC, модулями — они умирают "частями").


При этом за тот же период активной работы с обычной памятью как на рабочих станциях так и на серверах построенных на потребительском железе (без ECC) я также не могу вспомнить ни одного случая повреждения данных в связи с памятью — т.е. без явного сбоя железа который очевиден. Память и другое железо вылетало, kernel panic случался, да — но это всё (на железе с ECC это тоже в норме).


Конечно, мой личный опыт, и даже опыт тех с кем я работал все эти годы — лишь капля в море, но всё же говорит о чём-то. Будь обычная память настолько ненадёжной как её хотят представить — проблемы с ней, равно как и повреждения данных были бы массовыми, а это явно не так.

обычно модуль начинает сбоить, система успевает это записать в логи и почти сразу за этим всё вешается — т.е. коррекция вообще не помогает, а модуль приходится менять

ECC не про сбойные модули, хотя в некоторых конфигурациях вроде Mirroring или Lockstep может и от них помочь. ECC это больше про тихий bit flip который происходит по вине фоновой радиации и прочих космических лучей и темной энергии :)


А насчет как часто это происходит — можно поискать статистику. Ну или на работе может будет время пройдусь скриптом по логам iLO тысячи-другой серверов и соберу статистику, самому интересно. Но я довольно часто натыкался на сообщения о "ECC error corrected" в них. И память сбойную у нас там меняют довольно часто по результатам этих ошибок (так что видать всё же модуль может начать подгнивать, но пока еще корректируемо)


Я не говорю, что обычная память ненадёжна, я говорю о том что проблемы вызванные случайными повреждениями в ней сложно диагностируемы, как минимум — и Линус про это тоже упоминал, что мол куча Kernel OOPS непонятных в багзилле вполне возможно вызвана именно этим. А уж на десктопах где "синий экран — час работы коту под хвост — жмем резет и заново" так это вообще норма, люди даже не подумают на память скорее всего.


я также не могу вспомнить ни одного случая повреждения данных в связи с памятью

Тут, мне кажется, зависит от везения. Повреждения есть, но чтобы их обнаружить они должны попасть на какое-то критичное место и вызвать проблемы. А если просто в какой-то огромной БД какой-то байтик изменится (и в БД нет чексумминга) — никто не заметит пока не попадёт на деньги.

Были и случаи когда модули просто жёстко умирали — т.е. система просто не грузится с умершим (что примечательно — ни одного такого случая с обычными, не ECC, модулями — они умирают «частями»)

Дело в том, что ECC не только исправляет малые ошибки, но и обнаруживает большие ошибки — такие, которые скорректировать невозможно. В результате, как только ECC-модуль начал «умирать частями», система уходит в NMI по обнаружению некорректируемых ошибок, и это происходит ещё до старта ОС.
Пока не-ECC память работает хорошо, — она ничем не хуже, чем ECC.
Преимущество ECC начинается тогда, когда память не работает хорошо по каким-то причинам. Без кодов коррекции/обнаружения ошибки памяти крайне тяжело диагностировать таким образом, чтобы выяснить, что причина была именно в памяти.
Будут случайные проблемы, зависания, повреждения данных. И, к тому моменту как вы соберете статистику, чтобы задуматься о том, что это, наверно, может быть, память, — может оказаться уже сильно поздно.

Если же память будет с ECC, то, по обнаружении в логах первых сообщений вида «исправлена ошибка памяти» можно просто по логам посмотреть, какой модуль сбоит, и поменять его. Без последствий.

У меня недавно сервер под виртуализацию начал сыпать ошибками в лог про "ECC Recovered". Тупил, но работал) ВМ оттуда долго переезжали, но переехали без остановок и проблем.

мой личный опыт, и даже опыт тех с кем я работал все эти годы — лишь капля в море, но всё же говорит о чём-то. Будь обычная память настолько ненадёжной как её хотят представить — проблемы с ней, равно как и повреждения данных были бы массовыми

у меня постоянные проблемы и возвраты в магазин материнок асус, асустек и кто-то третий от них же. Но у других же работает, как они говорят.

За последние лет 15 на десятках серверов с ECC памятью я не помню ни одного случая коррекции который не сопровождался бы полным вылетом памяти

Странно, я помню кучу случаев вроде «были разовые ошибки, потом не повторялись», «были скорректированные ошибки, вынули модули, протёрли контакты ластиком, пропали».
А вот случаи полного отказа ecc памяти у меня единичны.


При этом за тот же период активной работы с обычной памятью как на рабочих станциях так и на серверах построенных на потребительском железе (без ECC) я также не могу вспомнить ни одного случая повреждения данных в связи с памятью — т.е. без явного сбоя железа который очевиден. Память и другое железо вылетало, kernel panic случался, да — но это всё (на железе с ECC это тоже в норме)

Так битые файлы зачастую незаметны. Я с битами файлами сталкивался, утверждать, что дело именно в битой памяти не могу, но это весьма вероятная причина(даже самая вероятная, наверное).
В случае «глюков» десктопа одно из первых действий — тестирование памяти, по моим ощущениям битая память, «уставший» блок питания, перегрев, вздувшиеся конденсаторы — это >>90% всех аппаратных причин.

PCI Express с избыточным 10b/8b кодированием
Поправка. Конкретно 10b/8b служит для устранения постоянной составляющей из сигнала, это не ECC в чистом виде. Да, избыточности этого кода хватит, чтобы обнаружить ошибку, но не устранить её, как это делает ECC. Цель этой избыточности в том, чтобы убрать из сигнала длинные последовательности нулей или единиц, которые встречаются достаточно часто, это помогает сделать сигнал более узкополосным, что в свою очередь помогает корректной синхронизации данных при работе асинхронных приёмников, что встречаются в PCIe, SATA, USB3 и т.д. В остальном согласен, ECC — вещь.

Согласен, но там еще есть LCRC/ECRC и ретрансмиты что по сути гарантирует отсутствие ошибок при передаче.

НЛО прилетело и опубликовало эту надпись здесь

Ох уж эти проблемы неразогнанноно (и как следствие нормально не протестированного) железа)) /s


А вообще Линус мог бы и за новостями следить, DDR5 будет ECC Only

Наконец, Линус выразил радость по поводу того, что AMD поддерживает массовые потребительские платформы Ryzen, давая потребителям возможность использовать ECC, не платя деньги за оборудование серверного класса.
Если память не изменяет, у AMD ECC официально поддерживают лишь Ryzen PRO, которые дороже, чем точно такие же процессоры без суффикса PRO.

Неофициально, да, её поддерживают все Ryzen, но, наверное, могут быть проблемы с поддержкой со стороны мат.платы?

Ешё вопрос к частотам, быстрой ЕСС-памяти «из коробки» я не видел, а пользователи десктопных ПК предпочитают более быструю, а не более надёжную память.
Если память не изменяет
А у вас ECC?

Все Ryzen, даже не Pro, поддерживают ECC (кроме мобильных). AMD вполне официально это подтвердил, хотя и с оговоркой что это "не тестировалось на потребильских платформах". Я недавно собрал комп с Ryzen 5 3600X — ECC память вполне работает (Samsung M391A4G43MB1-CTD @X470D4U).


Что касается быстрой ECC-памяти — 3200 есть "из коробки", но тут другая проблема — очень немногие материнки (если брать недорогие) поддерживают эту скорость для более чем одного-двух модулей.

Линус Торвальдс: выразил своё мнение в абсолютно типичной для него безапеляционно-агрессивной манере.
Журналисты: «Линус Торвальдс раскритиковал...»
Это хороший журналист с ёмкими заголовками. Плохой написал бы «Учёные рассказали о вреде процессоров Intel».
НЛО прилетело и опубликовало эту надпись здесь

По мне все просто: хочешь память (памятуя о хлипкости современной электроники) с коррекцией? Поставь. Вас же никто не заставляет… Я вот хочу, и она работает. А Интел просто закрыла эту возможность. Потому у меня Райзен :)

Что-то я не нахожу нигде информации о поддержке 5900X ECC памяти.

Помню свою ЕС1842 и любимую ошибку всех ЕСок — СБОЙ ПАРИТЕТА ПАМЯТИ, именно большими буквами в текстовом режиме и на чёрном фоне. И помню что сбой паритета висел на простом прерывании и я написал свой обработчик, который играл похоронную мелодию, но при этом позволял работать дальше. Понятное дело, в те времена реализовать ECC было трудно, хотя объём ECC памяти тот же, добавляется 8 бит кода Хэминга на 64 бита.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Другие новости

Истории