| Форумы
ЧАТ |
Орешник |
|
| Форумы -» | Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG |
|
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
Отлов ошибок аппаратного уровня. [D7, XP]
Проходящий © (2011-02-26 00:15:00)Доброго времени суток, мастера.
Предыстория: Как то купил дополнительное ОЗУ для одного компьютера, все бы хорошо, но почему то иногда стали зависать программы или выполнять недопустимые ошибки, после чего Win выдавало сообщение об ошибке и различныепрограммы благополучна вылетали в никуда(то бишь закрывалась, иногда с занятой памятью). После того, как ОЗУ было проверено на memtest, которая аоказала наличие ошибок в ОЗУ (битая планка), пришлось ее поменять на новую и все нормализовалось.......
А теперь собственно к тому что стало интересно:
Обычно работая с Try Except Finally используются конструкции следующего вида:
SomeObject := TSomeObject.Create;
try
//Что-то делаем
finally
SomeObject.Free
end;
И вот у меня возник вопрос. А что если при работающей программе где то в середине кода условно в момент выполнения SomeObject := TSomeObject.Create; создающаяся переменная или объект попадают на битый байт или бит в ОЗУ? При этом либо глобальная программа подвисает, либо аварийно закрывается Windows без освобождения ресурсов...
А кто нибудь пытался отлавливать ошибки на уровне железа? с целью спасти работоспособность программы и скажем возобновить Create, но уже не в "битом" секторе памяти? или более важный вопрос, как сохранить данные программы (БД и т.д.) без потерь основных(например компютер стоит в офисе, работнику поставили ОЗУ, и он работает с базой не подозревая, что может случиться)?
Гипотетически, конструкция может стать:
try
SomeObject := TSomeObject.Create;
Except
Ошибка с ОЗУ?
1. Попробовать выполнить вновь предыдущий оператор, с целью попасть не в "битый" сектор ОЗУ
2. Или вызвать обработчик закрывающий программу, с сохранением аварийных данных на хард с последующим восстановлением информации и т.д.
try
//Что-то делаем
finally
SomeObject.Free
end;
end;
Это такое общее представление...А есть ли возможность определить ошибки извне?
Интересно Ваше мнение, мастера.
С уважением.
PS: Может вопрос не в эту ветку форума, но очень интересно стало попытаться найти ответ или как нить понять возможно ли отловить ошибки в ОЗУ (физические)...
Anatoly Podgoretsky (2011-02-26 17:26:00) [1]> RWolf (26.02.2011 17:16:25) [25]
Для указания от 0 до 8 нужно четыре бита, плюс один бит четности, без этого
восстановление не возможно.
Основы кода Хемминга
RWolf (2011-02-26 17:16:00) [2]
> Anatoly Podgoretsky © (26.02.11 16:18) [24]
откуда информация?
про 8+4 с восстановлением одиночной ошибки знаю, про 8+5 — не слышал.
Anatoly Podgoretsky (2011-02-26 16:18:00) [3]> sniknik (26.02.2011 14:24:18) [18]
Там принцип другой, и конечно не четырьмя, а пятью битами, для 8 бит данных
Anatoly Podgoretsky (2011-02-26 16:16:00) [4]> sniknik (26.02.2011 14:18:15) [15]
Для восстановления используется 7 бит, корректируют методом простой инверсии
бита.
Алгоритм называется код Хемминга.
По теории надежность восзрастает на много порядков, до появлявления
неустранимой ошибки.
Anatoly Podgoretsky (2011-02-26 16:14:00) [5]> Брю (26.02.2011 13:25:11) [11]
Во первых контролируют не 8, а 32 бита.
А во вторых так вероятность не считают, простым делением на N
Anatoly Podgoretsky (2011-02-26 16:04:00) [6]> Inovet (26.02.2011 11:44:08) [8]
Ну во первых одиночная ошибка устраняется, а вот что делается со второй
ошибкой совсем не ясно, не вижу ни какого механизма, возможно будет
сообщение об ошибке, но не уверен.
Inovet (2011-02-26 14:38:00) [7]> [17] sniknik © (26.02.11 14:21)
> а название это маркетинговый ход
Сейчас может быть больше так и есть, но раньше из-за низкой надёжности памяти, когда контроль чётности практически везде ставили, ECC был настоящим, да и сейчас наверное есть такие. Потом уже когда надёжность повысилась контроль почти везде убрали, вот может и стали называть его ECC.
Вот нашёл
http://www.cyberguru.ru/hardware/memory/memory-modules-faq-page6.html
RWolf (2011-02-26 14:26:00) [8]
> sniknik © (26.02.11 14:21) [17]
исправляются любые единичные ошибки — самый типичный случай.
если одновременно поменяются два соседних бита, такое код испрваить не сможет.
sniknik (2011-02-26 14:24:00) [9]> не одним, а четырьмя;
хм во время моего изучения этого, это был 1 бит в добавок к 8... видать память реально, и серьезно подешевела...
осталось еще 4 добавить и будет полное зеркало (+ экономия на расчетах, + из-за этого ускорение). :)
sniknik (2011-02-26 14:21:00) [10]ECC (англ. error-correcting code, код коррекции ошибок) — данные, присоединяемые к каждому передаваемому сигналу, позволяющие принимающей стороне определить факт сбояи (в некоторыхслучаях) исправить несущественнуюошибку
все таки, работает как я представлял/описал, а название это маркетинговый ход.
RWolf (2011-02-26 14:20:00) [11]
> и как он одним битом корректирует 8?
не одним, а четырьмя; см. «код Хэмминга».
sniknik (2011-02-26 14:18:00) [12]> вообще-то ECC — это error-correcting code.
серьезно? никогда не воспринимал его так. и как он одним битом корректирует 8?
RWolf (2011-02-26 14:10:00) [13]
> sniknik © (26.02.11 13:59) [13]
> это не избыточный бит информации, типа для восстановления
> данных
вообще-то ECC — это error-correcting code.
sniknik (2011-02-26 13:59:00) [14]> возможность коррекции сбоя в одном бите
какая коррекция? ты о чем?
> при одном избыточном бите на один байт вероятность возникновения сбоя уменьшится на 1/8, что даст 12,5% увеличения надежности.
это не избыточный бит информации, типа для восстановления данных, это контроль четности, для проверки памяти и возбуждения ошибки "на раннем этапе".
т.е. прочитали откуда то данные, после начинаем писать на диск, а вместо записи получили ексепт типа "ошибка памяти, четность не совпадает".
или начинаем выполнять код, комп читает очередную команду, и вместо выполнения ставшей неопределенной, потенциально опасной, оп - "ошибка памяти, четность не совпадает".
> Хотя, впрочем, блондинки дают 50%, чет/нечет.
блондинки правы, для одного байта возможность определить "битость" памяти = 50%. если оценивать систему в целом там конечно будут другие цифры.
Inovet (2011-02-26 13:32:00) [15]> [11] Брю (26.02.11 13:25)
> О как, возможность коррекции сбоя в одном бите - это уже
> "увеличение надежности на много порядков"?
Это что за цитата в кавычках? Твоя? Я о другом говорил, потрудись перечитать.
> [10] Inovet © (26.02.11 12:47)
Брю (2011-02-26 13:25:00) [16]>Inovet © (26.02.11 12:47) [10] ECC сделает эту возможность на много порядков более вероятной
О как, возможность коррекции сбоя в одном бите - это уже "увеличение надежности на много порядков"?
Что-то мне подсказывает, что при одном избыточном бите на один байт вероятность возникновения сбоя уменьшится на 1/8, что даст 12,5% увеличения надежности.
Хотя, впрочем, блондинки дают 50%, чет/нечет.
Inovet (2011-02-26 12:47:00) [17]> [9] Tag (26.02.11 12:44)
> Когда глючит память, корректно завершить работу вряд ли удастся.
ECC сделает эту возможность на много порядков более вероятной
Tag (2011-02-26 12:44:00) [18]>>для того чтобы всё не упало, корректно завершить работу
Когда глючит память, корректно завершить работу вряд ли удастся.
Даже если удастся, то это может оказаться еще хуже.
Где-то там, внутри, остались неуловимые катастрофические баги.
До поры, до времени.
И даже смена планок памяти не поможет.
Баги уже есть.
На винте.
И никуда не денутся.
До поры, до времени.
До поры...
До времени...
Inovet (2011-02-26 11:44:00) [19]> [7] Anatoly Podgoretsky © (26.02.11 11:20)
> ошибку все равно на пользовательском уровне не поймать.
Это, как я понимаю и выше сказал, для того чтобы всё не упало, корректно завершить работу и заменить память.
Anatoly Podgoretsky (2011-02-26 11:20:00) [20]> Германн (26.02.2011 00:56:03) [3]
Это реально - ECC
Проверен будет каждый байт, только ошибку все равно на пользовательском
уровне не поймать.
| |
Страницы: 