Добро пожаловать, Гость. Пожалуйста авторизуйтесь здесь.
FGHIGate на GaNJa NeTWoRK ST@Ti0N - Просмотр сообщения в эхоконференции RU.LINUX
Введите FGHI ссылку:


Присутствуют сообщения из эхоконференции RU.LINUX с датами от 24 Jan 02 06:01:34 до 29 Apr 24 03:15:24, всего сообщений: 8279
Ответить на сообщение К списку сообщений Предыдущее сообщение Следующее сообщение
= Сообщение: 7905 из 8279 ========================================= RU.LINUX =
От   : Eugene Muzychenko                2:5000/14          11 Mar 23 11:36:46
Кому : Dmitry Protasoff                                    11 Mar 23 11:36:46
Тема : ECC
FGHI : area://RU.LINUX?msgid=2:5000/14+640c5d8d
На   : area://RU.LINUX?msgid=2:5001/100.1+640be8fa
= Кодировка сообщения определена как: CP866 ==================================
Ответ: area://RU.LINUX?msgid=2:5001/100.1+640c80b3
Ответ: area://RU.LINUX?msgid=2:5080/172+640df167
==============================================================================
Привет!

11 Mar 23 02:34, you wrote to me:

DP> Раз в месяц - это не ничтожная.

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

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

EM>> Hа серверах, ага? А как часто они падают из-за неисправимых
EM>> ошибок?

DP> С ЕСС не падают.

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

DP> А как ты проверял, что данные не бились?

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

А вот банальных глюков софта я за это время наблюдал предостаточно. Каждый такой глюк может повлечь порчу рабочих файлов, нарушить целостность БД и т.п., что иногда и случается. Вероятность потерять из-за этого важные данные многократно выше, чем из-за редких аппаратных ошибок памяти.

Всего доброго!
Евгений Музыченко
fi-do@muzy-chen-ko.net (все дефисы убрать)

--- GoldED+/W32-MSVC 1.1.5-b20180707
* Origin: Fox Tracks, France (2:5000/14)

К главной странице гейта
Powered by NoSFeRaTU`s FGHIGate
Открытие страницы: 0.055445 секунды