Отключенными ядрами - как? В системе (windows) действительно видно 2 процессора? (Task Manager/Prformance/CPU - сколько окон графиков?)
Если есть разночтение в количестве, то, теоретически, проблемы быть могут.

Добавлено спустя 2 минуты 7 секунд:
Да отключите вы пятую матрицу! (угораздило меня выставить в ini самые жесткие условия). К ней потом вернемся.

Два графика.

Добавлено спустя 3 минуты 17 секунд:
В висте.. семерке в msconfig загрузка дополнительные параметры число процессоров, если поставить галку, можно задать колличество ядер 1 2 3 4 .. если галку снять будут все..

neemestniii, Quad только дома.
Из личных наблюдений - Q6600 очень плохо отваливается по ошибке. Например, LP x64 на нем дает только BSOD. Ни разу я не видел на нем ошибок вычислений. А вот 'рабочий' E8400 BSOD на LP64 не дает и часто отваливает по ошибке. У меня используется похожий алгоритм и, видимо, болезни аналогичны.
Скорее всего, на 4 ядра просто не хватает пропускной способности памяти или чего-то другого и 4 ядра частично простаивают.
А двум достается по полной.

Всё это из раздела "наверно".

neemestniii, если не затруднит, поставь 3 ядра.
Если проблема в неверном определении количества физических-логических ядер, то '3' тоже должны давать сбой.

Попробуйте поставить CheckMode=0
Если и с ним будут ошибки, ну тогда "я не знаю"....

Отключил.. неразогнанный ноут и на четверке ловит ошибки.. с CheckMode=0 и ошибок нет..

Проблема в том, что CheckMode=1 нормально работает, но если поставить CheckType=0.
И то и другое снижает, практически устраняет различие между элементами матрицы.

Добавлено спустя 2 часа 17 минут 16 секунд:
Раздробил, увеличил шаг CheckType с 2 до 4. Теперь прежние 1-2 соответствуют новым 3-4. (версия 0.08)
Причем, что инетересно, если 1 как-то не находит, то 2 находит сбои, просто надо дольше ждать.
Когда от такого параметра вероятность обнаружения практически линейно возрастает, то это не ошибка в коде программы.

А кто-ниьудь тестировал этой прогой Core i7 (HT on) ?
У меня разгон 200х21 CpuVoltage 1,34 ; QPI/DRAM Core Volt 1,34
LinX, SnM , 3DMark, игры ошибок не выдают. А вот запустил Cpu stress test v0.08 - и на первом тесте выдаёт ошибку Ну а зато если его пройдёт", то остальные тесты проходит без ошибок!

Nemosurgeon, открой любым простым текстовым редактором (не word) файл cst.ini и поменяй CheckMode=1 на CheckMode=0
Обычно, достаточно кляцнуть на этот файл и откроется notepad.

Пока что я ищу черную кошку в черной комнате. (продолжение фразы все знают)

Краткий отчет по предварительному исследованию CheckMode=1.
При выполнении некоторых операций происходит спонтанное-непредсказуемое изменение результата.
Может есть и в других местах, но я своими глазами видел это на FPU.
Конкретно - запустил программу под отладчиком, встал на вполне тривиальную последовательность команд FPU и _пошагово_ начал выполнять. Вначале стек пустой, теги показывают неиспользуется, в регистрах мусор. Это нормально.
Выполняю команду fldz, в стек должно поместиться 0. Нажимаю кнопку "Next Step" и с ужасом наблюдаю в окне отладчика число -0.00000e-******, т.е. нечисло 0. И это пошаговый режим, процессор холодный, не разогнан.
Конечно, для расчетов с использованием FPU число 0 и нечисло 0 синонимы (почти) и никто не заметит это разницы. Плюс к тому, любая арифметическая команда увеличит это число и эта мизерная ошибка исчезнет. Ну, в самом деле, если сложить 1e-4000 с 10, то в результате получится 10, ведь мантисса не резиновая.
Мой тест при CheckMode=1 побитно проверяет результат тестирования и несовпадении даже 1 бита выдает ошибку. Поэтому он может 'увидеть' подобный сбой.
Кстати, сбой сильно зависит от странных и непредсказуемых факторов, поэтому можете не пытаться его повтоить - вряд-ли получится.
Это свойство (баг процессора Core?) зависит от загрузки процессора, предыдущих команд и вообще состояния FPU. Средство противодействия есть, можно ограничить точность расчетов FPU и 80 бит до 64, это заставит процессор нечисло 0 превратить в число 0 и сбой будет спрятан. Но он все равно есть, просто его пожрало округление.
Посмотрел, как с этим багом борется linpack - о чудо, там обрезают точность до 64 бит! Мило, мило ... значит они знают об этом?
Кстати, обычно в программах не обрезают разрядность FPU, это не нужно. Ну, их ждет подарок.



Небольшой словарик.
FPU - блок работы с плавающей арифметикой. Оперирует данными в формате мнтисса + порядок.
Мантисса - число в диапозоне 1-9.99999999999999....9999
Порядок - порядок числа, т.е. степень десятки.
Например, число 123 в формате FPU будет представлено как мантисса = 1.23 и порядок = 2 ( 10 в степени 2 ) или 1.23е2
Это т.н. нормализованные цифры, у них есть мантисса и порядок.
Но есть и не_нормальные цифры, в которых нарушается это правило, они называются нечисла. Сейчас поясню, будет понятно.
Есть понятие 'бесконечность' и FPU может пытаться оперировать этим понятием (как 1/0). Конечно-же, численно его не записать, поэтому в FPU оно представляется как некоторое число без порядка и мантиссы, просто 'нечисло' бесконечность.
Другим случаем нечисла является обратное от бесконечности, число 'почти 0'. Обычно, в нем важен знак. Но это не 0!
Вот выходит и еще одно 'нечисло'.


p.s.
Ну нет, это настолько неподъемная тема, что оставляется "на потом". На долгий-долгий потом.
Я убираю режим CheckMode=1.
Версия 0.09

За выходные "почистил" программу.
Вылет программы при старте был связан с применением HeapAlloc и только в w7(Vista?). ntdll вываливалась с исключением при запросе ~2Kb.
Попытки изменения размеров и параметров хипа ничего не дали. Перешел на VirtualAlloc, проблема ушла.
Если кто посчитает, что в этом нет вины Windos, может кинуть в меня камнем.
Из фич - если не будет файла ini (первый запуск), то программа создаст ярлык на рабочем столе. Его можно удалить, если мешает, больше не появится.
Появился ключь ускоренной проверки. Я знаю, где чаще возникает сбой, не обязательно выполнять все последующие действия.
Он был включен с версии 0.02 (кажется), теперь можно выбрать самим.
Версия 0.11b

Добавлено спустя 53 минуты 43 секунды:
Уффф, наконец-то поднялся ftp. Теперь информация (и файл) есть на оригинальной странице - testmem.tz.ru
Кстати, C&QC2 поднялся до .9 версии - исправление мелких ошибок - криво работали HotKey переключения окна и показ графиков (замирали-исчезали).

serj
Потерял эту страничку.. шас будем смотреть..
Очень интересная инфа..

Добавлено спустя 1 час 53 минуты 17 секунд:
Посмотрел версию 12b.. вроде работает.. не понял FastCheck=1 как использовать?

По-хорошему, надо бы юзать







Ну и другие функции Native API вместо Win32-оберток к ним, и тогда проблем не будет нигде. А заодно и накладные расходы на вызовы уменьшатся.

HertZ, теряется совместимость. А пользы не дает. Я свегда стараюсь избежать залезания туда, куда нет явной необходимости лезть. ... уже наелся на проблемах совместимости.
IMHO, оболочка там декоративная.

Но ... спасибо, что напомнил.

Добавлено спустя 2 часа 15 минут 25 секунд:
константин с байконура, эта фича появилась после описания.
Наиболее часто (читай - всегда) сбой вызывает процедура преобразования. Она выполняется 90% времени.
После нее идут другие действия, которые (почти?) не влияют на обнаруживаемость, но снижают нагрев из-за простоя ядер. Эту ненужную деятельность можно исключить этим ключем. При этом проверяется CRC после преобразования, а не корректность вычисления матриц. Т.к. такой задачи не ставится, то можно не выполнять.
По умолчанию ключ ставится в 1, если есть подозрения, что опущенная часть процедур может повышать качество, то fast можно отключить.
Разницу от вкл-выкл можно посмотреть по загрузке процессора - паузы в циклах станут в ~2 раза меньше.

Так и подумал

взял вчера ку6600 на работу...
сначала тестил LinX-ом, только там в последней версии косяки какие то и он на 100% не нагружает ядра, потом перешел на сабж..., ну и грелка блин:
#77
( или мне кажеться, или перекос кулера!? )

там где линкс проходил без проблем сабж "завалил" на 30-ой секунде.
немного поработал с частотами и напряжением, всё таки процессор не из холодных а кулер у меня (кхм...кхм..) самосборный

вобщем остановился на фсб 385 и 1.46в напряжении ( проседает с квадом при нагрузке прилично ).
конфигурация железа из профиля под номером 2.

machKim, я думаю, ты уже разобрался с проблемами.
CST, условно говоря, имеет 2 режима работы - с однократным повтором и с многократным повтором. Для первого режима, если сравнивать с LP, то - греет он немного хуже, а определят сбои несколько лучше LP. Я могу повысить эффективность CST на недостающие 5%, но это будет в ущерб эффективности определения ошибок. В режиме с повторами CST греет так-же (или чуть-чуть лучше) версии LP x64 с большим объемом памяти.

Сколько раз мне нужно прогнать этот самый CST чтобы быть уверенным в стабильности системы?!

Странный вопрос. Наибольшая определяющая способность для максимальной матрицы. При этом повтор идет за несколько минут. Если за пол часа сбоев нет, то можно говорить о стабильности системы.
Вот только ... ни один нормальный человек не будет сидеть на максимально_стабильной частоте. Старение компонентов, стало немного жарче - и могут пойти сбои. Поэтому ВНАЧАЛЕ ищется максимальная стабильная частота, а потом она снижается на 2-5%. Я делаю так и компьютер работает без проблем.
Если придерживаться этого принципа, то можно использовать небольшую матрицу, что несильно понизит четкость определения, но на порядок снизит время определения сбоев. Разница между подходами дает разное время.

Ответ - от 2 минут до 3 часов.

Спасибо, до этого проц работа на 4.5 при напряжении 1.45-1.46, но народ начал пугать деградацией проца и тем что возможно мамка завышает напргу и в реале может быть 1.5, поэтому я чутка снизил частоту, хотя до этого был c2d 6400 понятно что он 65nm но он работал на 3.6 при напряжении 1.56 и ничего с ним не стало на протяжении всего пользования где то год