В этой теме предлагаю обсуждать мои записи на ПС.

Пока из таковых лишь одна :
Сравнительное тестирование стабильности разогнанного Intel-процессора в x64Win7 и x86WinXP

50 хватит + часик прайм + ОССТ часик. Если отработает - тогда ОК. Валидация CPU-Z - не показатель. Надо тесты чтобы проходило.



Какже не идет если идет?

Вот полная цитата из записи:

Я не понимаю, где вы увидели слова о BSOD’ах на дефолте системы? Процитированный вами абзац начинается не с "дефолта", но с "простоя" системы. Впрочем... если это не понятно, могу соответствующую фразу дополнить в записи словом "разогнанной". С тем, чтобы первое предложение процитированного вами абзаца выглядело так:


Насчет тестов - ОК, прогоню сначала на х86, затем на х64. Правда... Небольшое уточнение - Prime95, я так понимаю, следует прогнать в режиме blend, а в ОССТ`е загрузить его родной тест стабильности?

Хотя, честное слово, не понимаю - зачем это? В своей записи я не исследую ни максимально "загружаемых" частот шины либо процессора, ни fsb-wall данного процессора на данной плате (чтобы каждый под этой "стеной" и не понимал...).
Я рассматриваю довольно узкий вопрос - подтверждение стабильности одного процессора при одном его уровне разгона на одной материнской плате, в одном признанном стресс-тесте, но в разноразрядных ОС. И мои "опыты" как раз подтверждают то, что х64 к стабильности при разгоне предъявляет больше требований, нежели х86, именно в части величины CPU VCore. Другие напряжения (при увеличении их значений) на исчезновение/острочку появления того самого 00000х124 BSOD никак не повлияли... К тому же ни этим, ни иным "синим экраном" на х86-"оси" при том же уровне разгона, но меньшем значении CPU VCore, и "не мелькало". Тут я могу лишь повторить фразу из обсуждаемой записи:


ДОБАВЛЕНО:
Вы говорили (еще в теме "Методика..."):


Xmast
Краеугольный камень - не в этом. А в коде самой ошибки "синего экрана". 00000х124 - одна из болезней "семерки". Жалоб именно на эту ошибку и именно в "семерке" по инету сейчас не так уж и мало. Если эта ошибка "выскакивает" на неразогнанной системе, ее лечат, как правило, отключением в биосе технологий энергосбережения. Если есть разгон - рекомендуют либо повышать проц. напряжение, либо "расслаблять" тайминги оперативной памяти.
Однозначных рецептов здесь нет. Мне допустим, в свое время, повышение таймингов нисколько не помогло избавиться от 00000х124 в разгоне системы на х64 Win7. А вот увеличение проц. напряжения - вполне...

ovix дефолт в моем контексте - работа без нагрузки. Именно работу без нагрузки и имею в виду. Так что уточняю. Понятно же что компьютер тестировался в разгоне и о дефолте по частоте разговора не идет. Между работой под нагрузкой и в простое разница очень велика (как и причина появления бсода в простое при стабильном процессоре в нагрузке на мой взгляд исключена вина процессора) что и вызывает вопросы.

Добавлено спустя 18 минут 43 секунды:
Какой режим тестировать в прайме? Да можно вобще без него. Насколько я помню, для определения границы фсб должно хватить одного лишь линпака. Но это не проверенно.
Поэтому нескольких программ более чем достаточно.
Если в инете идет много жалоб на определенную ошибку, то можно сделать вывод, что дело версии ОС. Опять же надо пробовать другую версию. У меня та же вин7 макс х64. Бсодов не наблюдал ни в каком режиме. Та же ситуация у знакомого. Буквально вчера он говорил мне о переходе на х64 вин7. Причем с его слов только с третьего раза. Две предыдущие сборки глючили. Третяя работает без проблем. Напряжение он по любому не повышал. Уверен. У него находится мой бывший квад 9550. Продал в декабре. Тогда же он его намтроил и разогнал. 4Ггц получил. Немало. Вот рассказывает на работе про новые игры...

Заметил знакомые цифири и обозначения в статье
До этого была P5B-Dlx (P965) нынче P5Q (P45) обе на C2D E6300. Гнал на обоих до умеренности. На P5B было как-то проще ввиду малых настроек
К слову о нужности и важности определённых напряжений:

При этом выводы: камень предкновения Vfsb (если известно примерное стабильное Vcpu при облегченных остальных настройках всего CAS/PL/Strap) при выкрученных PL и др. неявных настройках таймингов памяти/чипсета, который для 64um имеет своё абсолютное максимальное значение, гарантирующее работоспособность девайса, при возврате к исходному/номинальному значению, равно 1,55В (1,45В для 45um), согласно даташитам, поэтому волноваться за цпу не стану

Ну а статья так себе. БСОДы только настройками вызваны ибо если процессор позволяет стартовать, мать позволяет и больше подать, охлаждение позволяет /температура мониторится в допустимых нормах/, расплавленный свинец, медь, пардон, не струится по корпусу - значит настройки можно ещё крутить в надежде и при имеющемся желании.
Вообще можно заметить то, как себя система ведёт при перегреве/овервольтинге (жёсткое зависание без бсода напр. для NB/SB, или троттлинг, есля для цпу) и при недоедании/андервольтинге (бсод напр.) и делать выводы о допустимых диапазо нах вам это нужно.

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

Добавлено спустя 19 минут 35 секунд:
Да, а статья не особо понравилась. Цифры потолочные, да и методика тоже.
Мои тесты: Prime95x64 25.11 с кастом настройками от бленд - на 2600Мб памяти (при 3072 общего объёма). Также можно другие встроенные покрутить для полноты.
Linpack последний с сайта с объёмом задачи по 2700Мб памяти и повышенным приоритетом (выдаёт 19Gflops) - в статье 21 видел в разницу по частоте укладывается. Обязательно контролировать показатель ибо LinX выделяет памяти чересчур под "тестировать всё" так, что начинаются "свопы"/кэширование/ что видно по 15-16Gflops в статье, что снижает смысл и производительность теста Linpack. IntelStressTest выделяет меньше памяти, оставляя под систему поболее, поэтому свопа и прочего переключения контекстов поменьше и Gflop'ы идут стабильнее, т.е. высокие всегда. Ну это принципы, но не мелочи. Принцип в том, что LinX до определённой свое версии (последней что ли) сам мог ошибку выдать, при этом Linpack работал бе ошибок - все "спасибо" к дельфовой оболочке и автору, хорошо, что хоть когда-то пофиксили это, а то столько электроэнергии и нервов ушло под хвост кривой дельфистской оболочки на Linpack до последнего релиза...
И всё это главное из-под х64 Safe Mode (F8) с отключёнными по макс. службами, чёрным раб. столом и отсутствием активных окон и приложений. Всё ради стабильности.

Замеры температур не интересовали ибо троттлингом не пахнет, да и Q-Fan на Silent нормально себя ведёт. +Для интереса можно чуть это всё погонять не в Safe Mode, чтобы темпу с цифровых датчиков снять, посмотреть, удовлитвориться (её адекватности Tcpu < Tj) и забыть о ней, как несущественном показателе на этапе конечного тестирования стабильности и перезагрузиться в DOS, пардон Safe Mode.
Всё это для "ночного" режима проверкой длительностью до 10ч.
Стабильно.

Xmast

ОС - х64Win7. Процессор IC2D Е6300 был разогнан по шине до 490Mhz при множителе 6. Напряжение на процессор было зафиксировано в биосе на 1,5125V (1,496V по мониторингу CPU-Z). Остальные вольтажи - как указано в записи.

Вот скрин "прогона" в LinX (50 раз при объеме задачи 14000):
~229,67kb
#77

Вот скрин "прогона" в Prime95_Blend (чуть больше часа):
~184,5kb
#77



И на том спасибо .

А мне статья понравилась. И содержание. И изложение. Просто при прочтении сама тематика должна быть интересно. В данном материале есть исследование. А не просто очередной тест видеокарты или там блока питания.

Добавлено спустя 9 минут 35 секунд:
Да. Скрины посмотрел. По работоспособности материнки на частоте 480-490Мгц вопросов больше нет.

Ну в смысле, есть куда копать и что улучшать. О мелочах, которые сказываются на результате писал выше.
И если чуть твикнуть в нужном направлении, то покорится и больше. Примерные направления я тоже дал на примере зависимости от конкретных напряжений (никогда не думал, что Vnb будет играть малую роль в процедуре разгона +0,08 от минимума и при этом Vfsb такую большую)

Я полностью, соледарен с автором !
У меня вин 7 х 64 максимальная (лицензия).

Вчера разогнал E8200 до 500 х 8 (4000 Мгц),
все в принципе работает на Vcc 1,325,
начал тестировать на наличие ошибок и температурный режим:

1,325
Линкс (14000 на 30 проходов, довольно тяжелый режим) - на втором проходе ошибка
Прайм (FFT самый верхний тест, самый тяжелый) - сбой одного из ядер на первой минуте
1,35
Линкс - на 5 проходе ошибка
Прайм - сбой одного из ядер на 8 минуте
1,375
Линкс - 30 без ошибок
Прайм - сбой одного из ядер на 58 минуте

Сегодня продолжу, не решил правда что еще делать, поднимать напруго больше не хочеться,
опускаться по фсб тоже )) Больно шустро работает ))

Да и комрады просветите, если в Прайме ошибка можно сказать после часа тестирования,
может в реальных приложениях (играх) её совсем не будет, напруга то уже почти 1,4 ???

Очень жаль что данная тема заглохла.
Наблюдения по напряжению и стабильности в данной статье по разнобитным системам интересные, но если сюда добавить данные по температурам и производительность ГФлопах то выводы можно сделать совсем другие. Поясню когда я разгонял и тестировал свой профильный проц я обратил внимание на некоторые "непонятки" при работе ЛинХ, объяснить для себя я не смог и в соответствующей ветке на вопрос мне не ответили. Теперь подробней о том что было.
При использовании максимальной памяти зачение производительночти всегда меньше, чем при использовании примерно того же но целого числа объема задачи(18Гф-макс.память; 20Гф-макс.объем задачи). При меньшем значении производительности температура меньше и система стабильно работает при меньшем значении Vcpu. При использовании максимально целого значения объема задачи при равных напряжениях и разгоне сис. проводя повторные тесты иногда по непонятным мне причинам величина производительности увиличивалась до 21Гф, причем это можно было определить сразу до появления результата по увеличению температуры ядер и заканчивалось это не стабильностью бсодом или зависоном или перезагрузкой
Поэтому мне лично кажется что причина необходимости увеличения Vcpu для обеспечения стабильности вызвана разным значением Гф на разных осях 21Гф-64бит(W7) и 17Гф-32бит(W-XP), то-есть чем больше Гф тем больше нужно мощности процесору, а может быть это зависит не от битности а от операционки

Почему заглохла? Вы же откликнулись.
Насчет температур - не раз думал об этом. Наверное, все же проведу сравнительный "прогон" нескольких стресс-тестов (LinX, OCCТ-Linpack, Prime 95/Small FFTs, SnM) в 32-ух и 64-ех битной ОС. На предмет выяснения - в какой из операционных систем процессор греется больше, по данным тех или иных мониторинговых утилит. Естественно, что "биосные" условия тестирования - частота процессора и напряжение CPU VCore - будут одинаковыми.
А вот насчет производительности в ГФлопах - . Это уже будет больше походить на тестирование разнообразных GUI для программной библиотеки Linpack, чем на проверку стабильности разогнанного процессора. Заниматься этим не хочу.

Почитайте/просмотрите последние страниц 10-15 в теме Методика тестирования и определение стабильности при разгоне процессоров Intel. Там в отношение этого (нужно/не нужно повышать cpu Vcore при одинаковом уровне разгона в разноразрядных ОС) высказано несколько различных, но серьезно аргументированных мнений. Я свою позицию высказал в сабжевой записи.

В целом же, при сравнительном тестировании я не ставил перед собой цель отслеживать "поведение ГФлопс" при тех или иных условиях проверки в LinX. Задача была куда проще - найти минимально достаточное CPU VCore для подтверждения стабильности в признанной/рекомендуемой/популярной/etc. проверочной утилите.

ovix
Я может быть не правильно высказал свою мысль(всегда были проблемы с этим, еще со школы ), попробую еще раз
Я имел в виду, что для стабильной работы под ЛинХ в разных осях, ХР и 7, требуются разные значения Vcpu, потому что разная производительнось процессора. (примерная аналогия -мне чтобы увеличить производительность проц. с 18Гф до 22Гф надо увеличить частоту с 3600 до 4000 и соответственно поднять напругу с 1,36 до 1,42, чтобы добиться стабильности, а у вас в обзоре 17 и 21 и соответственно значения Vcpu примерно похожие.
P.S. после смены кулера тестил комп при мах.задаче 14000 значения Гф были меньше чем при 13000, пока не снизил разгон с 375 до 370. теперь вроде все нормально

rodiki33
Я не зря запостил ссылку на тему по "Методике тестирования..." Там есть ответы на это ваше наблюдение.
Относительно --->

Думаю, потому, что в х64-ОС задействуются дополнительные блоки/узлы/регистры процессора.
Есть такое аргументированное мнение, которое мне представляется верным --->


Насчет иной (более высокой или низкой) производительности?.. Ответить не готов. В реальных приложениях, которые я использую, если таковая разница и проявляется, то весьма незначительно (64-битные приложения работают по-быстрее - тот же WinRAR; насколько (?) - не замерял). А синтетика в виде различающихся значений ГФлопс в утилите LinX при прогоне ее с одним объемом задачи, но в разноразрядных ОС, мне не столь интересна... Еще и потому, что LinX в этом плане может и учудить. От запуска к запуска (при одинаковых условиях тестирования, настройках в биосе и на одной ОС), эта устилита может выдавать различные усредненные значения этого параметра. Иногда данный параметр разнится между собой в несколько ГФлопов. Вот мнение по этому поводу, с которым я согласен.
Относительно --->

Этот тест предъявляет такие повышенные требования к стабильности системы (при соответствующем объеме задачи, естественно), кои вряд ли предъявит любое иное рабочее/игровое приложение. Как следует из сабжевой записи, моей системе при разгоне процессора до уровня 476 х 7 = 3330Mhz для подтверждения стабильности в LinX (300 раз, объем задачи - 14000) в 64-разрядной "семерке" потребовалось установить в биосе напряжение на отметке 1,5000V. При этом для повседневного использования компа в разноплановых задачах/приложениях в среде x64Win7 примерно на протяжении 16-18 часов в сутки хватает и 1,4750V "биосного" напряжения. Если подавать на камень меньшее значение cpu vCore, то х64-"семерка" начинает перманентно "бсодить". Хотя при том же уровне разгона в 32-разрядной ХР для стабильной работы хватает и более низкого vCore, устанавливаемого в биосе (подробнее - опять же в записи).

Я после исследования также скинул разгон по шине - на 4Mhz. Но руководствовался при этом иными соображениями, а не показателями ГФлопс в утилите LinX... Повторюсь, задача стояла - проверить стабильность разгона при тех или иных значениях проц. напряжения в разноразрядных ОС. И проанализировать результаты такой проверки стабильности. Подтверждать/опровергать ее еще теми или иными значениями индекса производительности в данной утилите - ... Если честно, даже мысли такой не было - увязать определенную величину ГФлопс с признаком стабильности/нестабильности разогнанного процессора. Как по мне, логическая связь здесь все же неявная. Особенно, если учесть, опять же повторюсь, неодинаковую "выдачу" LinX'ом усредненного значения этого показателя от запуска - к запуску этой утилиты.

ovix
большое спасибо за ссылку , дейсвительно очень интересная тема

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

а программой AppCrashView пробовал смотреть?
у меня после BSOD BlueScreenView показывает ошибку 124 - драйвер причны - hal.dll
а AppCrashView показывает "Аппаратная ошибка видео" это началось когда я поставил дрова ATI Radeon 10.5

Нет, не пробовал.
Но от версии драйвера на видео появление BSOD с кодом 0x00000124 явно не зависит. По крайней мере, на моей системе.

ovix
Ознакомился с большинством Ваших постов по теме влияния ОС и ее разрядности на стабильность системы. К сожалению нет такого солидного материала по тестам но при переходе с ХРх32 на W7х32 при тех же показателях разгона (2,95Гц=295х10_1,4375V)тоже заметил отсутствие той же стабильности. Накинул на Vядро один пункт и все ОК.

Мы с Вами стыкались в топике "Р5В" где я продолжаю экспериментировать с разгоном. Так вот замечено при поднятии последнего до 3,10Гц (1,45v) DIMM 690МГц 1,90v (1:1) сценарий следующий:

1.0х000000124
2.+ один пункт vCore краткосрочный ОССТ-Линпак(50% память)(20мин.) ошибка на 3-й минуте (00:17:26)
3.+ один пункт vCore краткосрочный ОССТ-Линпак(50% память)(20мин.) ошибка на 5-й минуте (00:15:04)
4.+ один пункт vCore краткосрочный ОССТ-Линпак (20мин.) 50% память все ОК, а 90% память ошибка на 15-й минуте
5.+ один пункт vDIMM (=1.95м) ОССТ-Линпак (по 40мин. на 50% и 90%) все ОК

Остановился на 1,48v память же позже на 10:8 задрал до 863МГц и понизив с 2,05v до 1.95v (Prime95 Blend -3 часа все ОК)
По моему ошибка 0х000000124 является отправной точкой.

В моем случае (расписанном в записи) так и было. Появилась эта ошибка - возникла нужда в совладании с ней - начался поиск решений - найдено было влияние только лишь напряжения vCore на появление/непоявление именно этой ошибки - было поднято напряжение vCore - ошибка 0х000000124 перестала беспокоить мою х64Win7Макс в разгоне процессора.
ДОБАВЛЕНО:

Pro_Gektor писал(а):

(Prime95 Blend -3 часа все ОК)

ИМХО, но по времени маловато будет. Запустите этот тест на 10-12 часов, если пройдет - тогда можно будет с определенной уверенностью говорить о том, что память стабильна.
В своих случаях тестирования оперативки на стабильность, я помимо Prime95/Blend_10-12_часов также нередко использую memtest86+ в среде DOS. В свое время прогон именно этого теста помог выявить нестабильность оперативной памяти. Хотя Prime95/Blend при тех же установках в биосе отработал 12 часов без ошибок, вылетов и "остановки по ядру".

По Prime95 Blend согласен, на выходных попробую.