| Экспресс-тестирование RAM (20.04.2022). |
|
| 2022 - Апрель | |||
| 20.04.2022 17:42 | |||
BAD-сектора в RAM настолько мерзкие, что бьют в спину скрытно. Проверено на личном опыте: с битой RAM архиватор создает архив без каких-либо ошибок - а вот распаковка этого архива в будущем уже будет с ошибкой (часть файла будет не с изначальным содержимым, если смотреть его в Notepad++). При этом ошибка трудно диагностируется (если вообще догадаешься проверить и заметить), т.к. первоначально начинаешь думать о неисправности ПЗУ. Представление алгоритма в виде отдельной программы пока имеет мало смысла - но подходит для самоконтроля какого-либо ПО. В моем случае, это была программа, математические расчеты которой имеют высокую степень важности для лабораторий - и ошибки в таких расчетах недопустимы. Выход для такого ПО единственный: проводить тестирование RAM в составе встроенного самоконтроля ПО - а лучше вообще перед самым началом расчетов. Проверять либо всю доступную память в системном блоке на текущий момент времени, либо известный необходимый для ПО объем. Программ, показывающих физическое расположение данных в RAM, не обнаружил - поэтому второй способ пока под вопросом. В реальном мире сигналы в планках RAM не передаются по воздуху - можно применять к RAM абстрактные термины, применяемые при тестировании жгутов: - "ячейка": область памяти, хранящая логический 0 или 1; - "контроллер": некое схемотехническое устройство в составе RAM, принимающее решение, что должно храниться в ячейке в текущий момент времени. На решение влияет желание программиста, естественно; - "триггер": официальное название электронного переключающего устройства в составе RAM, запускающего изменение состояния ячейки. Является составным (может содержать в себе много транзисторов, емкостей и прочего хлама). Может быть несколько триггеров на ячейку, как резервирование в сложных системах (может, именно поэтому ОЗУ редко отказывает, уступая по надежности только процессорам); - "стимул": команда от контроллера к триггеру; - "реакция": изменение триггером состояния ячейки по факту; - "тракт": путь от контроллера к триггеру для стимула, путь от триггера к ячейке для реакции. По сути, самоконтроль сводится к тестированию всего вышеперечисленного. Если что-то пойдет не так (например, недооткрытие триггера или замыкание тракта двух соседних триггеров) - пользователя не интересует, какой именно участок сломан: в ячейку требуемая информация не записалась - до свидания. В этом и заключается удобство создания собственных паттернов проверки, отличных от MemTest и прочих программ проверки ОЗУ, - без оглядки на схемотехнику RAM и ее ТТХ. Изначальный вариант тестирования RAM работал через одно место, используя в качестве стимула бегущую единицу для проверки реакций в некотором фиксированном объеме данных. Данный способ проверяет 100-%но каждую связку контроллер-тракт-триггер-тракт-ячейка (как единичную, так и в составе группы), - но крайне долго. В физической реальности крайне маловероятно, что в кристалле RAM порядок расположения ячеек отличается от порядка расположения триггера. Иными словами, для ячейки и связанного с ним триггера всегда будет условный индекс №1, всегда слева будут по соседству №0, справа - №2. Значит, физически в одномерном пространстве возможно замыкание только соседних связок между собой. Косвенно на это указывает работа: Скудняков Ю.А., Шпак И.И. Вычислительные машины и системы / Минск: Белорусский государственный университет информатики и радиоэлектроники, 2020 г. – стр.39-54. Значит, порождается право использовать последовательно комбинации "10" и "01" для физически соседних ячеек - как проверка их работоспособности в одномерном пространстве. Если же предположить, что связки расположены в двумерном пространстве (а, скорее всего, так и есть) - достаточно в уже проверенную комбинацию ячеек записать единицы: для влияния этих замкнутых триггеров на ячейки из других, еще не проверенных, рядов. Далее, внезапно, выяснилось, что скорость работы такого алгоритма напрямую зависит от размерности массива, который используется для выделения памяти и ее проверки. Скорость обработки 8-байтного qint64 (максимально возможного целочисленного в среде Qt v.5.5.1), в сравнении с 4-байтным int, - быстрее на 22.35%. Также выяснилось, что нельзя в цикле проверки массива использовать какие-либо переменные и структуры: увеличение времени обработки на 20%. В итоге, в ход идут голые числа: 0xAAAAAAAAAAAAAAAA, 0x5555555555555555, 0xFFFFFFFFFFFFFFFF. Увеличение скорости изначального алгоритма, суммарно раз в 80, - благотворно сказалось на скорости проверки 1ГиБ: ~789мс на гибибайт в Windows и ~689мс в Linux - и это при использовании режима отладки. По идее, работа такого алгоритма в выпускном режиме должна быть еще быстрее. Однако кажется, что записывать единицу в ячейку нужно не только после проверки этой ячейки. А перед началом всех проверок - все ячейки единицами забить. При такой реализации, скорость обработки падает до 1000мс/ГиБ, на ~25% - при добавлении всего одной строчки. Таким алгоритм в итоге и оставил. Возможно, алгоритм можно оптимизировать путем игр с типами данных. Пока выяснилось: - одинаковы по скорости работы unsigned int и int в составе условий цикла; - int быстрее qint64 в составе условий цикла; - проверка равенства на число медленнее, чем присвоение этого числа. Увеличение количества гибибайт для проверки - не равно уменьшению скорости проверки одного ГиБ. Проверка 1ГиБ - 1000мс/ГиБ, 2ГиБ - ~800мс/ГиБ, 3ГиБ - 773мс/ГиБ, 4ГиБ - 747мс/ГиБ, 5ГиБ - 740мс/ГиБ, 6ГиБ - 737мс/ГиБ (дальше - стало лень). Связано с использованием одной итерации цикла на несколько массивов с данными. Не исключено, если доработать алгоритм еще несколько раз, - то получится быстрый аналог MemTest (как, в свое время, стала самописная программа Fast ZeroFilling взамен SDelete). А то точно помнится, как прогонял MemTest 32ГБ RAM - без шансов: только на ночь оставлять (а еще и за свет платить). А с помощью такого алгоритма есть шанс за 30сек управиться - используя в качестве ОС Mini Windows XP с крайне малым потреблением RAM. Одна проблема: не проверится вся RAM - только свободная, маленький кусочек не затронет. (добавлено 21.04.2022) Изменение const unsigned int в условиях цикла на обычное число 134217728 - привело к увеличению скорости проверки RAM на 5-6%. Непонятно, какая разница обращения к const unsigned int и просто к целочисленному числу (которое должно, по идее, в unsigned int или int и храниться самим компилятором). Не могу сделать отдельный EXE-файл, чтобы проверить скорость работы релизной версии. Qt в Windows - это зло. В интернете пишут, что нужно отключить QML, - но он по умолчанию выключен, тупик. В Linux разницу скоростей пока не тестировал. (добавлено 22.04.2022) На планки удобно ставить полосочки перманентным маркером на верхней кромке, нумеруя так позиции планок в материнской плате. Не смог создать битый модуль оперативки самостоятельно (для проверки алгоритма требуется, чтобы ошибочная область памяти была постоянной). Убил 10 исправных модулей RAM - но так и не смог достичь промежуточного состояния между "работает идеально" и "ПК с такой RAM не включается". Бил молотком, тыкал шилом, резал лезвием, пилил напильником чипы - бесполезно. Разрушал дорожки на плате - бесполезно. Разрушал радиоэлементы на плате - бесполезно. И вот, казалось бы, везение: нашел модуль с ошибкой в одной ячейке (двух?). Радостный, начал ожидать окончания повторных проходов MemTest - а ошибка взяла и исчезла. И больше вообще не появлялась, даже после перезагрузки ПК. Несколько часов гонял ее и, разозленный, выкинул.  Скорее всего, придется писать продавцам на авито: "куплю битую оперативку DDR2 любого объема за полцены". Удалось оптимизировать скорость проверки RAM путем использования релизной сборки. Увеличение скорости - почти в 2 раза; еще немного - и можно заявлять о проверке 2 гибибайт за одну секунду. (добавлено 25.04.2022) Все вышесказанное рождает вывод: если жизнь заставляет проверять биты бегущей единицей - их нужно проверять, наоборот, бегущим нулем. (добавлено 04.05.2022) Представление чисел в Hex или Dec на скорость работы влияет избирательно. Изменение числа 134217728 и 0x8000000 в цикле не дало разницы по скорости. А вот замена 0xFFFFFFFFFFFFFFFF на -1 при присвоении - замедлила работу. (добавлено 10.05.2022) Простое, казалось бы, определение количества свободной RAM в разных ОС - оказалось сложной задачей, описать которую можно только отдельным материалом и много позже. (добавлено 17.05.2022) Получение количества свободной RAM - условно успешно. А вот результаты MemTest (нашел-таки битые, но рабочие модули RAM) показывают интересные результаты: - в зависимости от того, в какой разъем вставлен модуль, - показывается разное расположение битой области (раз, два); - возможна-таки ситуация, когда модуль больше по объему неисправен, чем исправен; - использование RAM Kingston в материнской плате EliteGroup RS482-M754 rev 1.0 вызывало непрерывный сигнал неисправности (верещание динамика) - при этом тест продолжал идти без каких-либо визуальных ошибок. И на этой же материнской платы Qt v.5.5.1 отличилось своей глючностью снова: устанавливается некорректно, вызывая ошибку "точка входа в процедуру strlen не найдена в библиотеке DLL msvcrt.dll" - несмотря на работоспособность на той же ОС в другом ПК. С учетом достаточности оперативной памяти и видеопамяти - не поддерживает именно процессоры старых поколений, несмотря на их 64-битность. (добавлено 24.06.2022) Все уже было написано ранее. MemTest, в составе Windows 10 от Стрельца, - задействует все ядра и потоки системы, чтобы сделать экспресс-тест RAM за несколько секунд. Научной новизной мое изобретение отсвечивать не будет - только практической значимостью для Astra Linux и ПО для нее. Узконаправленное военное применение - и то потому что повезло: и ОС, и среда программирования подошли. |
|||
| Обновлено ( 24.06.2022 18:03 ) |