Насколько все же важна ECC-память

а то что у тебя происходит - это или чипсет или память или даже не знаю, что еще.

Ну если учесть что на tmpfs данные могли лежать сутками то видимо причина в чипсете или самом винчестере.

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

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

Очень важна для сохранности нервной системы админа, для серверов, по опыту, не очень.

Одна из немногочисленных здравых мыслей ITT, лол.

Тебя torvn77 покусал, что за хрень?

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

Я копировал один Тб винт на другой, параллельно скачивал и раздавал торренты, параллельно смотрел фильм. Это достаточно большая нагрузка? В принципе раз в 15-20 минут при этом фильм мог фризиться на пару секунд, не знаю почему.

У меня есть доступ к одному компьютеру, который включен 24/7, и там минимум раз в квартал бывают выявленные ECC ошибки кэша процессора (в разных ядрах). А вот разгон это уже влияние постоянного фактора.

Отсюда: Максимум ECC-памяти для X570 (комментарий)

Насколько оно критично и не бывает ли при этом еще чего - хз. Пытаюсь окончательно понять. В принципе до сих пор она мне не нужна была. Но и было (есть сейчас) всего 16Гб DDR3, а не 64 Гб DDR4

Еще один нюанс ECC-память работает на 1.2В, не ECC - на 1.35В. Хотя может если погнать ECC с 2666 до 3000-3200, ей тоже надо будет выставить 1.35 - не знаю.

Еще один нюанс ECC-память работает на 1.2В, не ECC - на 1.35В.

Любая нормальная DDR4 работает только на 1.2. Выше уже разгон.

Так я и пытаюсь понять хоть какой-то смысл для меня в ней будет или это такое себе развлечение? В принципе люди говорят, что пару-тройку раз в месяц в логах сыпятся ошибки, выявленные ecc. Вопрос в том, сколько при этом не от памяти.

все ЕСС ошибки памяти - они от памяти :) попортился ли битик в процессе хранения, или попортился в процессе передачи в чип - дело десятое и с практической т.з. абсолютно неважное.

ну а в целом - да, ЕСС память работает более стабильно - там где не-ЕСС сыпет ошибки в мемтесте (к примеру на АМ3/АМ2+ 1-2 ошибки в сутки норма), ЕСС память волшебным образом ошибки не сыпет, ни скорректированные ни нескорректированные, ни в мемтесте ни в EDAC логах. наверное потому что работает на рекомендованных производителем чипов таймингах, а не на «оптимизированных» производителями «оверклокерской» памяти…

Я что-то не видел (смотрел по спекам) ни одной(!) памяти на 3000-3200 МГц на 1.2В. Может такая и есть, но похоже очень редкая.

Между тем для современных Ryzen вроде как оптимальная частота даже 3200-3600Мгц у памяти. Получается изготовитель процессоров сразу закладывается на разгон памяти?

не только.

компиляция больших проектов (без ЕСС вероятность рандомных вылетов ненулевая), файлохранилище ценных файлов…

смотрите спеки чипов, а не плашек. производители плашек таки разгоняют свои поделки.

Я копировал один Тб винт на другой, параллельно скачивал и раздавал торренты, параллельно смотрел фильм.

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

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

В принципе если так пепегнать 20Гб то ошибки уже могут появиться.

Ещё можно взять два винчестера и одновременно копировать с них информацию друг на друга.

И ещё, все испытуемые винчестеры должны быть подключены через контроллер в чипсете материнской платы, при разделении винчестеров между двумя и более контроллерами эфект может снизится или пропасть.

Я что-то не видел (смотрел по спекам) ни одной(!) памяти на 3000-3200 МГц на 1.2В.

Есть Kingston 3200@1.2V. Правда вызывает вопросы тот факт, что под маркой Crucial такого нет, а те чипы произведены Micron, и едва ли могут быть лучше, чем «для себя».

Между тем для современных Ryzen вроде как оптимальная частота даже 3200-3600Мгц у памяти. Получается изготовитель процессоров сразу закладывается на разгон памяти?

Почему нет? Во-вторых, можно хоть 2133 МГц использовать — разницу всё равно искать под микроскопом в большинстве случаев. Не насилуй себе мозг.

компиляция больших проектов (без ЕСС вероятность рандомных вылетов ненулевая),

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

UER у обычного (десктопного) диска - 10^14. Задолбаешься ждать.

Эти некогда невообразимо гигантские 12,5 ТБ (десятичных) сегодня сравнимы с объёмом двух или даже одно диска.

ECC-память исправляет ошибки в передаче данных «на лету» - на аппаратном уровне. Это быстрее. Обычная память вынуждена тратить дополнительные циклы процессора (на повторные транзакции обмена) для правильной передачи данных. Это медленнее и вызывает единичные фризы (стопперы в играх).

Это что-то новое сейчас прочел. Я думал обычная память вообще не занимается исправлением ошибок, а фризы в играх от задержек при I/O с диском. Или чего не додумали в игровом движке. Или проц тротлит, но тогда будут не фризы, а фризища.

ну у меня на АМ2+ платформе gcc крашился раз в несколько часов рандомно.

то поциэнт принял вещества перед написанием поста, не обращайте внимания.

обычная память - она вообще корректировать что-либо (или даже детектировать ошибки) не может. софт - ну в принципе может, но не факт что будет (вроде с переменным успехом это умеют только некоторые СУБД делать), и будет это пытаться делать независимо от установленной памяти.

Если это из-за неECC, то в принципе аргумент. Компилировать планируется много, хотя до сих пор не очень много было.

Еще тупой вопрос на всякий случай: поддержка ECC совсем никак от операционки не зависит - я имею ввиду, конечно не сообщения в логах (кстати, в каких - dmesg?), а работу в принципе?

Но пытаюсь понять юзкейс

Берешь обычную память.

Статистически значимое количество раз проводишь «экперименты». Экспериментом может быть имитация твоей повседневной деятельности с перезагрузкой системы в неожиданное время из-за зависания (Так называемый «юзкейс») Как ты добъешься «неожиданного» зависания - это твои проблемы. Потом результаты анализируешь всякими разными стат.методами.

Берешь есс-память. Делаешь то же самое, что с обычной памятью.

Сравниваешь результаты. Делаешь вывод, нужна ли тебе «необычная» память.

В общем, бери всё! Ставь «эксперименты» на всём. Ты же не лох, и у тебя есть много свободных ресурсов, в том числе человеко-часов, как у транснациональных макаранных корпораций, для проведения экспериментов с неожиданными зависаниями каждый день (непонятные зависания - это важно при тестах ecc-памяти). О результатах отпишись. Или не пиши, не важно. :)

Как ты добъешься «неожиданного» зависания - это твои проблемы.

Чем нажатие на Reset не подходит?

Чем нажатие на Reset не подходит?

Твой эксперимент, твои методы, твои результаты, твои выводы о нужности есс-памяти при неожиданных резетах. Никто никому ничего не навязывает. Почти. Бери всё!

компиляция больших проектов (без ЕСС вероятность рандомных вылетов ненулевая)

Компиляция больших проектов - это и есть числодробильня в чистом виде :)

файлохранилище ценных файлов

Ну это ежу должно быть понятно, КМК :)

Статистически значимое количество раз проводишь «экперименты». Экспериментом может быть имитация твоей повседневной деятельности с перезагрузкой системы в неожиданное время из-за зависания (Так называемый «юзкейс») Как ты добъешься «неожиданного» зависания - это твои проблемы. Потом результаты анализируешь всякими разными стат.методами.

А причем тут зависания и ошибки памяти? Это вообще не связанные вещи, не считая случаев зависания из-за сбоев в памяти.

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

Вопрос только насколько это все же актуально. Пока не понял толком. Но вроде есть такой плюс, что просто ECC еще и чуть покачественнее.

Эти некогда невообразимо гигантские 12,5 ТБ (десятичных) сегодня сравнимы с объёмом двух или даже одно диска.

Ну на HDD - довольно долго ждать.

нафиг не нужно с твоим объемом памяти и аптаймом. мне лень ищи сам спеку по вероятности возникновения ошибки по аптайму и объему плашек.

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

поддержка ECC совсем никак от операционки не зависит

Да, не зависит.

кстати, в каких - dmesg?

Да.

«hardware ecc recovered, no action needed»

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

При зависаниях не известно что происходит. Данные могут теряться, или генерироваться случайные и записаться как настоящие, или стереться. Знаешь, что такое UB в языке c/c++ и шутки про форматирование диска при UB?

Ресет - это просто сигнал. А что за процессы происходят при этом сигнале нигде полностью не прописаны.

Вот и думай, насколько нужен ECC если у тебя данные уже ошибочные. И поможет ли ECC в исправлении таких ошибок, которые не контролируется ECC.

И ты описывал свой «юзкейс» с ежедневными засыпаниями, зависаниями, перезагрузками (а это достаточно сложные процессы, в реалиазции которых бесконечно много где можно наошибаться).

Задай вопрос, что чаще происходит: зависание/сон/перезагрузка или инвертнется 1 бит в 32 гигах памяти, которую ты используешь максимум для просмотра очередного сериала перед сном и выключением компа.

Если нет ответа на этот вопрос, то «бери всё!» и экспериментируй.

ECC нужен только тогда, когда у тебя всё остальное стабильно работает. У тебя есть ИБП, дизель-генератор, два блока питания, что там еще принято резервировать в корпорациях с имеющимися свободными ресурасами, которые щедро оплачиваются клиентами.

При зависаниях не известно что происходит. Данные могут теряться, или генерироваться случайные и записаться как настоящие, или стереться. Знаешь, что такое UB в языке c/c++ и шутки про форматирование диска при UB?

Ресет - это просто сигнал. А что за процессы происходят при этом сигнале нигде полностью не прописаны.

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

Задай вопрос, что чаще происходит: зависание/сон/перезагрузка или инвертнется 1 бит в 32 гигах памяти, которую ты используешь максимум для просмотра очередного сериала перед сном и выключением компа.

64Гб планирую. Сейчас 16Гб. Естественно для сериалов ECC лютый оверпрайс и даже более 8Гб памяти. Но все же я еще иногда и компиляцию делаю чего-нибудь тяжелого. Или вот начал с нейронными сетками упражняться. Хотя в целом комп домашний, то есть, это не сервер на работе.

ECC нужен только тогда, когда у тебя всё остальное стабильно работает. У тебя есть ИБП, дизель-генератор, два блока питания, что там еще принято резервировать в корпорациях с имеющимися свободными ресурасами, которые щедро оплачиваются клиентами.

Нет конечно. Тут в треде уже были сообщения, что без ECC мемтест раз в сутки выдавал ошибку и при компиляции были сбои. Хотя может это не из-за неЕСС, а просто такая память. хз.

В общем, все еще обдумываю. Все же 20 или 28 тысяч рублей для меня разница заметная.

Тем не менее, при этом обычно четко можно отделить успешно записанные нормальные данные и мусор.

Вопрос как определить, что ты прочитал то, что записал на диск? Если у тебя исходных данных нет. «Контролная сумма» это не может, если она по объему меньше чем данные (допустим, что данные не сжимаются). Всё это «четко можно» - это не более чем вера (в бога).

Нет конечно. Тут в треде уже были сообщения, что без ECC мемтест раз в сутки выдавал ошибку и при компиляции были сбои.

Пусть выкидывают свои 25-сантиметровые причандалы. 5 раз за ночь у них случается. У меня недели воздержания. Как тебе такое, Илон Маск?!

Но чтобы компиляция отваливалась из-за ошибок памяти - ни разу такого не было.

Вы что над ядерным реактором живете, или на МКС, да еще небось на запределеьно разогнанных системах.

Вопрос как определить, что ты прочитал то, что записал на диск? Если у тебя исходных данных нет. «Контролная сумма» это не может, если она по объему меньше чем данные (допустим, что данные не сжимаются). Всё это «четко можно» - это не более чем вера (в бога).

Ой, блин, ну вот пишет какая-то прога результаты вычислений в виде, допустим n:X:Y:Z:T в текстовый файл. И я вижу, что после перезагрузки оно хренак и оборвано на каком-то месте. Может даже с мусором в хвосте. Мусор удалил, прогу запустил, она данные всосала и с последнего n продолжила.

А если вычисления ошибочны, то у меня нет способа узнать это.

Или копировались файлы просто. Видно что скопировалось, а что нет. Можно еще последний после включения проверить отдельно.

Это все при внезапном зависоне или перезагрузке. При штатном выключении процессы можно штатно же и завершить предварительно.

Но чтобы компиляция отваливалась из-за ошибок памяти - ни разу такого не было.

Рандомно. Х.з. у меня тоже не было, но не поручусь.

Собственно пока никак не пойму оценку вероятности (и где ее искать как советовали?). Потому что если она достаточно низкая, то и действительно нефиг себя накручивать в стиле «а что если».

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

praseodim ★★★★

:) Вопросов больше не имею.

Ах, да! Бери всё! Иначе пятую звезду не получишь.

Представь, что в твоих расчётах флипнулся бит.

Насколько это реально ожидаемо? Просто например глупо брать ECC, если вероятность ее срабатывания в разы меньше вероятности, что бит инвертируется в SATA-кабеле или контроллере или где-то около. Неделями напролет я ничего не считаю.

Ну что не так? Нормальный подход. Или чтобы подсчитать чего-то обязательно надо сверхнадежные системы делать? Зависон у меня это что-то очень редкое, изредка при pm-suspend случается или если под большой нагрузкой, как уже говорил, очень редко, но бывает диск отваливается.

Видел бы ты на чем работают и на чем считают в некоторых российских лабораториях научные сотрудники.

Видел бы ты на чем работают и на чем считают в некоторых российских лабораториях научные сотрудники.

В правильных руках компьютер(вычислитель) - это всего лишь еще один инстумент, который ломается(починят), тупится(заточат), взрывается(ну что ж поделать), светиться (а это прикольно).

Нафиг не нужна, тем более на десктопе.

ECC нужен. Хотя бы чтобы не гадать откуда глюки есть память испортилась.

Собственно пока никак не пойму оценку вероятности (и где ее искать как советовали?). Потому что если она достаточно низкая, то и действительно нефиг себя накручивать в стиле «а что если».

Вообще некоторые люди свинтили с вебкамеры объектив, сняли с неё инфракрасный фильтр, чем то заклеили отверстие и стали наблюдать вспышки, выделяя среди них треки от частиц. В общем сделали из вебкамеры рентгеновский детектор.

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

Если это из-за неECC, то в принципе аргумент.

это на АМ2+/АМ3 платформе, где мемтест86 на обычной памяти в норме порядка 1 сбоя в сутки выявляет, на разных плашках (более половины плашек глюкают).

на других платформах скорее всего не так печально будет, но все же.

Еще тупой вопрос на всякий случай: поддержка ECC совсем никак от операционки не зависит - я имею ввиду, конечно не сообщения в логах (кстати, в каких - dmesg?), а работу в принципе?

никак.

а вы уверены что никаких ошибок при этом не возникало? или «работает? ну и хрен с ним»?

контрольные суммы файлов сверяете хоть? :)

на других платформах скорее всего не так печально будет, но все же.

Не очень понятно причем тут платформа? Или AM2+/AM3 настолько говено с памятью работают?

Платформа-то AM4 планируется.

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

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

https://ru.wikipedia.org/wiki/ECC-память#cite_note-Schroeder1-8

Тогда если даже 2.5E-11 * 64*1024*1024*1024*8 = 13.4 ошибок в час на всю память?! Чего-то как-то чересчур. Или я чего напутал при подсчете?

Но они наверное в 2009 году делали отчет по максимум DDR2 - памяти и тех размеров чипы. Сейчас выросло все на порядок, но даже порядка 1 ошибки в час на 64Гб многовато.

Нашел ссылку на вероятность в вики с первоисточником в виде отчета гугла за 2009 год.

Да ладно, ты начал ставить экперименты! Жаль, что чужими руками, чужими методами, чужими результатами и выводами. Осталось только переехать в серверную гугла и в 2009 год.

Мне вот интересно, где гугл использует есс-память (в 1% из всех серверов?), кто ему оплачивает эти свободные ресурсы?

Да ладно, ты начал ставить экперименты! Жаль, что чужими руками, чужими методами, чужими результатами и выводами. Осталось только переехать в серверную гугла и в 2009 год.

Вопрос, в сущности просто решается. Ты бы лучше привел примерную реальную статистику пригожаемости ECC-памяти и все стало бы понятно.

Например, один сбой в месяц на 64 Гб может произойти. - Тогда скорее всего не нужна. Один раз в неделю - можно подумать. Один сбой раз в пару суток уже наверное повод приобрести. Где-то так.

Из рытья в интернете я вынес, что если смотреть сериалы, котиков в ютубе, дрочить на fps в играх, стримить игры в ютубе и вообще быть модным влогером, то ECC нахрен не впилась. Надо брать что-то чего можно разогнать до 3600 МГц, больше уже многоканал отрубается.

Если же чем-то посерьезнее заниматься, то может быть полезной, а может и не особо.

Мне вот интересно, где гугл использует есс-память (в 1% из всех серверов?), кто ему оплачивает эти свободные ресурсы?

Гугл раньше строил свои ресурсы по принципу и г-на и палок, а ненадежность компенсировать программными резервированиями и архитектурой. Тем более, что для поисковых запросов особой надежности и не нужно. Ну будет какое-то количество ошибок в выдаче и пофиг. Абсолютно никто этого даже не заметит, кто бы вообще понял, что не релевантная выдача на 5 и 6-й строчке - это результат где-то сбоя?

Наверное, все-таки возьму. В конце-концов переплата в 8 тысяч хотя и заметна для меня, но учитывая, что беру не на год и даже не на два, а самое минимум года на три, то и не так чувствительно. В конце-концов, на еду в месяц трачу раза в два больше.

Кроме того, ECC память двухранговая, а non-ECC- одноранговая. Не уверен, что это существенная разница, но слышал мнение, что двухранговая более «ровно» ведет себя под нагрузкой. Правда скорость 2666 все же меньше 3200. Хотя можно и погнать ECC, гонится она хуже, но все же гонится. Из бонусов - проблемы в разгоне сразу будут заметны.

Вопрос, в сущности просто решается.

Я тебе и предлагаю решать в сущности. Бери всё!

Берёшь всё! Ставишь, например, ecc-память. Берёшь еще фен (всё, так, всё!). И дуешь горячим воздухом на память (и чипсет), имитируя работу памяти в высокоплотной серверной упаковке (или при бесполезном разгоне). И смотришь на сообщения о срабатывании ecc.

Или простую память. Запускаешь мемтест и фен.

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

В общем, имитируй свой «юзкейс». Только не забудь в отчете к «серьезной» работе указать, что имитировал: серьезную работу в стабильных условиях (всё-так-всё, дизель-генератор тоже нужен), или «серьезную» работу в «стабильных» условиях.

В общем, имитируй свой «юзкейс». Только не забудь в отчете к «серьезной» работе указать, что имитировал: серьезную работу в стабильных условиях (всё-так-всё, дизель-генератор тоже нужен), или «серьезную» работу в «стабильных» условиях.

Нахрена мне что-то имитировать? Интересно использование именно в моих естественных, так сказать, условиях. Тем более брать все вот уж точно лишних денег нет.

Я просто посмотрю будут ли вообще срабатывания. Пока что я никак не могу найти именно статистику срабатываний ECC. Сообщения на форуме разнятся от 1-2 в квартал на сервере 24/7 до 1-го за пару дней. И даже чаще.

Это конечно нифига не статистика, но сейчас попросил посмотреть лог аппаратных ошибок на одном сервере с 24Гб ddr3, и там с самого начала эксплуатации в 2014 году зарегистрировано 0 ошибок.
Совершенно другой компьютер в другом месте зарегистрировал 4 ошибки в течении 1.5 месяцев, и после этого ни одной ошибки небыло. Еще один компьютер, с обычной памятью, примерно в то же время зарегистрировал 1 ошибку в кэше процессора.
Что это все значит гадай сам.

Что это все значит гадай сам.

Может быть с сервера в лог не падают по какой-то причине. Про чипсет x570 прочитал, что только в ядре 5.4 научили их отображать.

Но вообще, спасибо за примеры.

Довод за - снижение вероятности ошибок.

каких ошибок?

В содержимом памяти.