Сравнительное тестирование стабильности разогнанного Intel-процессора в x64Win7 и x86WinXP
реклама
Появление официального релиза Windows 7 стало стимулом для многих пользователей, если и не перейти окончательно на эту операционную систему (ОС), то инсталлировать ее второй наряду с привычной Windows ХР. В числе таковых был и автор настоящей записи. При этом по ряду причин мой выбор пал на 64-разрядную версию данной операционной системы, а именно: Windows 7 Максимальная (х64Win7).
Несколько освоившись с новым интерфейсом, я тут же принялся восстанавливать разгон своего процессора до частоты 3,33Ghz, стабильность которой была подтверждена «прогоном» нескольких тестовых утилит в среде 32-разрядной Windows ХР Professional SP3 (x86WinXP). Однако в новой ОС при отмеченном уровне разгона я неоднократно наблюдал «падение системы» в BSOD с кодом ошибки 0х00000124. (Скажу сразу, что технологии энергосбережения в биосе материнской платы были и есть отключены, а множитель процессора четко зафиксирован на «7»).
~72,5kb
Причем «синий экран» появлялся именно в простое системы, когда компьютер был нагружен разве, что браузером да текстовым редактором. В «тяжелые» игры, вроде S.T.A.L.K.E.R.: Чистое Небо или Зов Припяти, можно было играть часами – система не зависала, и BSOD’ы ее работу не прерывали. На дефолтной частоте процессора х64Win7 также демонстрировала полную стабильность. Иными словами, дело явно было в реакции новой ОС на разгон системы.
«Прогон» нескольких тестов стабильности (таких, как линпак и Prime95 в режиме Small FFTs) ситуацию не прояснил. Проверочные утилиты отрабатывали заданный им объем задачи/период без ошибок, но вот BSOD’ы все также периодически прерывали работу моего компьютера. Это продолжалось до тех пор, пока я не «нагуглил» совет - повысить напряжение на процессор. Подняв в биосе материнской платы значение CPU VCore Voltage на две позиции по сравнению с процессорным напряжением, доказавшим свою достаточность на х86WinХР, я наконец-то добился стабильности разгона и на х64Win7. «Синие экраны» с ошибкой 0х00000124 начали постепенно забываться.
Вспомнить же об этой истории «достижения стабильности» заставила дискуссия, разгоревшаяся в теме конференции Методика тестирования и определение стабильности при разгоне процессоров Intel. Ее участники как раз спорили о достаточности напряжения CPU VCore при подтверждении стабильной частоты разогнанного процессора в 32 и 64-битных операционных системах. Собственный опыт говорил мне, что х64-системы в этом плане более требовательны, и для стабилизации разгона в них требуется более высокое значение CPU VCore Voltage, чем в случае с х86 ОС. С тем, чтобы окончательно подтвердить или опровергнуть это свое убеждение, я и затеял сравнительную проверку стабильности разогнанного процессора (посредством линпак-тестирования) в операционных системах х64Win7 и х86WinХР.
Проверять (либо опровергать) свои догадки и соображения я решил на компьютере, конфигурация основных комплектующих которого такова:
-
Процессор: Intel Core 2 Duo E6300 1,86Ghz@3,33Ghz + Zalman CNPS9700 LED.
Материнская плата: Asus P5B rev.1.04g (LGA775, Intel P965); BIOS ver2001.
Оперативная память: 2х2Gb Mushkin Red Line; DDR2-1000Mhz@952Mhz; тайминги: 5-5-5-18-5 42-10-10-10-25.
Видеокарта: Asus EN8800GT/512Mb/256bit.
Жесткий диск: Samsung SP2504C; 250.0Gb 7200rpm.
Блок питания: Chieftec 450W (GPS-450AA-101A).
В качестве проверочной утилиты был выбран LINPACK в программной оболочке LinX версии 0.6.4. с условием прохождения теста 300 раз (или «кругов»).
В тестировании также использовались такие мониторинговые программы, как CPU-Z v1.53.1 (для 32 и 64-разрядных ОС), Everest Ultimate Edition версти 5.30.1900, CPUID Hardware Monitor (далее - HWMonitor) сначала v1.13, затем v1.15 (для 32 и 64-разрядных ОС). Отслеживание температур процессора и северного моста осуществлялось посредством Real Temp v3.40 и MCH Temp v1.30 Alpha15.
Перед тестированием основные не-CPU напряжения в биосе материнской платы были выставлены следующим образом:
-
Memory Voltage - 2,10V (напряжение, рекомендуемое для профильной памяти ее производителем);
FSB Termination Voltage - 1,300V (+1 шаг от доступного к выбору минимума);
NB VCore - 1,40V (+1 шаг от доступного к выбору минимума);
SB VCore - 1,50V (минимум);
ICH Chipset Voltage - Auto.
Значения частот основной шины и памяти:
-
CPU Frequency - 476;
DRAM Frequency - DDR2-952Mhz.
Таким образом, при зафиксированном в биосе множителе «7» процессор был разогнан до частоты 3330Mhz при соотношении FSB : DRAM = 1:1. (И еще одно важное примечание. На материнской плате в свое время был проведен карандашный vdroop-mod, что позволило исключить просадки напряжения CPU VCore при нагрузке процессора. После проведения этой модификации мониторинг значений процессорного напряжения по мультиметру в принципе совпадает с показаниями утилит CPU-Z и Everest Ultimate Edition).
Первой «испытуемой» ОС я решил выбрать 64-битную Windows 7 Максимальная. При указанных выше значениях вольтажей и напряжении CPU VCore 1,4750V по-биосу (1,456-1,464V по данным CPU-Z) моя система в среде х64Win7 и ранее проходила 300 раз тест LinX при объеме задачи 12000:
~177,5kb
Впрочем, ознакомившись с этим результатом, камрад Xmast посоветовал увеличить размер матрицы в утилите LinX для получения действительно корректных результатов тестирования. Согласившись с его доводами, я повысил в утилите LinX объем задачи с 12000 до 14000 и запустил этот тест. Примерно через час после начала проверки система выдала все тот же BSOD с ошибкой 0x00000124.
В ответ на это я поднял в биосе значение CPU VCore Voltage до 1,4875V (по данным CPU-Z: 1,472V) и вновь включил тест. Аналогичный BSOD прервал работу системы... минут через 20. Это навело меня на мысли о том, что повышение процессорного напряжения здесь явно не выход. С учетом этого я опять зафиксировал CPU VCore Voltage на позиции 1,4750V, и стал попеременно повышать на один шаг остальные напряжения, доступные к регулировке в биосе материнской платы. После каждого изменения того или иного напряжения я запускал ОС и тестовую утилиту. Однако попеременное увеличение вольтажей на FSB, северный и южный мосты (а также некоторые другие «шаманства» с настройками биоса) к положительному результату не приводили. «Синий экран» с неизменной ошибкой 0x00000124 и ссылкой на файл ntoskrnl.exe опять появлялся через 30-60 мин после начала тестирования.
Казалось, единственный выход заключался в том, чтобы последовательно снижать уровень разгона (частоту FSB) до тех пор, пока эта ошибка не перестанет прерывать работу системы. Однако я решил запустить LinX еще раз - «на ночь», повысив до этого в биосе процессорное напряжение до уже апробированных 1,4875V (CPU-Z: 1,472V), но без утилиты HWMonitor, корректная работа которой вызывала сомнения. Утром монитор встретил меня все тем же BSOD`ом. При всем том, просмотрев соответствующую запись в журнале событий Windows 7, я обнаружил, что с момента запуска LinX до появления «синего экрана» прошло около 5-ти часов (примерно к завершению второй сотни проходов теста, может быть к началу третьей...). Я истрактовал это, как несомненный прогресс в сравнении с прежним периодом возникновения BSOD - максимум, чуть больше часа после начала тестирования...
Далее. Я скачал последнюю версию HWMonitor для х64-систем с веб-сайта разработчика, поднял в биосе напряжение до 1,5000V (по данным CPU-Z: 1,488V) и вновь запустил LinX. На этот раз тест отработал все 300 проходов при объеме задачи 14000:
~335,5kb
Перипетии этого тестирования подвели меня к нескольким предварительным выводам:
1. Объем задачи 14000 в линпаке/LinX’е, действительно, сильно загружает компьютер и предъявляет куда больше требований к стабильности разогнанного процессора, чем размер матрицы 12000. В сравнении с последним, на моей системе потребовалось поднять в биосе процессорное напряжение на две позиции с тем, чтобы пройти тест при 14000. И я далеко не уверен, что этих «биосных» 1,5000V на CPU VCore Voltage будет достаточно для успешного прохождения 300 раз теста в утилите LinX, но при объеме задачи, скажем, 16000.
2. Неоднократно прерывавшую мои тесты ошибку с кодом 0x00000124 и ссылкой на файл ntoskrnl.exe, видимо, вполне можно объяснять либо переразгоном процессора на х64Win7, либо недостатком напряжения CPU VCore при «том или ином»/текущем уровне разгона.
С такими вот соображениями я и приступил к проверке стабильности разогнанного процессора в 32-разрядной операционной системе Windows XP Professional Service Pack 3. При этом была надежда на то, что на «доброй-старой» и давно проверенной ОС особых сюрпризов в ходе тестирования возникнуть не должно. Не тут-то было! Неожиданности не заставили долго ждать, хоть и проявили себя с другой стороны…
Перед тестированием стабильности на х86WinXP в биосе матплаты применялись те же настройки, что и в случае с х64Win7, но за двумя исключениями. Во-первых, значение CPU VCore Voltage было понижено до 1,4500V (по данным CPU-Z: 1,432-1,440V). Во-вторых, была отключена Memory Remap Feature (с тем, чтобы 32-разрядная ОС увидела 2,93Gb оперативной памяти, а не 2,00 Gb, как это происходит, если включить данную «фичу»). Процессорное напряжение я снизил не «просто так». Именно при «биосных» 1,4500V тестируемый IC2D E6300 вполне проходит 300 «кругов» в утилите LinX при объеме задачи 10000:
~263,5kb
Но поскольку условием проверки был определен больший размер матрицы в тесте, то при указанных выше настройках БИОСа я загрузил х86WinXP, запустил мониторинговые утилиты и включил LinX при объеме задачи 14000. Все было нормально, кроме «поведения» программы HWMonitor, которая в ходе тестирования демонстрировал просто удивительные показания вольтажей. Обнуление показаний мониторингового окна в данной утилите ни к чему не приводило - через некоторые время значения напряжений приобретали нереальный вид. С учетом этого я остановил тестирование:
~307,5kb
После чего скачал последнюю версию HWMonitor для 32-разрядных систем и опять начал тест. Однако мои надежды на новую версию этого самого монитора не оправдались. Утилита продолжала «пугать» очень низкими показателями основных напряжений и сверхвысоким CPU VCore. Решив не обращать на это внимание, я «на ночь» вновь запустил LinX на 300 проходов при размере матрицы 14000 и указанных выше настройках разгона. Утром же увидел лишь... рабочий стол ОС, посреди которого нагло красовалась табличка Kaspersky Anti-Hacker c утверждением о том, что «срок лицензии истек»! Изучение журнала событий Windows XP, поиск дампов «синего экрана» при помощи утилиты BlueScreenView ни к чему не привели. Внятной причины происшедшего я так и не определил. Ясно было одно – компьютер перезагрузился. (У меня сложилось впечатление, что в ходе теста компьютер выключился, а затем, некоторое время спустя, включился. Иными словами, возможно, ночью в доме отключалось электричество на небольшой промежуток времени).
Как бы там ни было, я счел подобное завершение теста его провалом. После чего удалил Kaspersky Anti-Hacker, установил другой файерволл, перегрузил ОС и повысил в биосе значение CPU VCore на один шаг - до 1,4625V (по данным CPU-Z: 1,448V). Далее последовали: загрузка x86WinXP - запуск мониторинговых утилит - включение LinX. На сей раз система прошла 300 «кругов» линпака при объеме задачи 14000:
~316kb
По итогам уже двух сессий тестирования были сделаны следующие выводы:
1. Я был крайне удивлен тем «разрывом» в значениях напряжения CPU VCore, который требуется для подтверждения стабильной частоты разогнанного процессора в одной утилите, с одними условиями тестирования, но в разных операционных системах. Для того, чтобы пройти 300 раз линпак в оболочке LinX при объеме задачи 14000 в среде х64Win7Макс потребовалось подымать в биосе CPU VCore Voltage до 1,5000V. Это на три шага/позиции больше, чем для прохождения этого же теста, с теми же условиями проверки, но в операционной системе х86WinXP Prof. SP3.
Чем это объяснять: разной разрядностью ОС, относительной «свежестью» Win7 или особенностями утилиты LinX, точно не скажу. Конечно, для большей уверенности следовало бы осуществить подобное тестирование, но с применением другой оболочки для линпака - IntelBurn Test или OCCT-Linpack. Как, впрочем, и включить в тестировании иные версии Windows - х64 и х86... Однако в ближайшее время я заниматься этим точно не буду. Пока же на основании результатов своего сравнительного тестирования буду считать, что для стабилизации разгонной частоты CPU в х64 Windows действительно необходимо подавать в биосе большее процессорное напряжение, нежели в случае с х86-разновидностями этих ОС.
2. Напомню, что в среде х64Win7 при увеличении объема задачи в LinX с 12000 до 14000 для прохождения 300 «кругов» теста на моей системе потребовалось поднять процессорное напряжение в биосе на два шага - с 1,4750V до 1,5000V - с тем, чтобы подтвердить стабильный разгон IC2D E6300 на частоте 3330Mhz. Для х86WinXP увеличение размера матрицы в указанном тесте было более существенным - с 10000 до 14000. Однако напряжение в биосе пришлось повышать всего на один шаг (и то с некоторыми оговорками) - с 1,4500V до 1,4625V. Объяснить подобную «непропорцию повышений» ничем иным, кроме разной разрядности используемых в тестировании ОС, я также не могу...
3. Мысль о том, что многочисленные BSOD`ы (с ошибкой 0x00000124 и ссылкой на файл ntoskrnl.exe), неоднократно прерывавшие тестирование в среде х64Win7, имеют другое объяснение, чем недостаток процессорного напряжения, не давала мне покоя. Поэтому я решил проверить потенциальные причины сбоев - ошибки в работе памяти или матплаты. Вначале была осуществлена проверка оперативной памяти. Трехчасовой «прогон» утилиты memtest86+ v4.00 в среде DOS ошибок не выявил:
~156,84kb
Вслед за этим был предпринят следующий эксперимент. Подняв в биосе напряжение CPU VCore до 1,5125V, а NB VCore - до 1,55V, и, оставив остальные настройки прежними (как для разгона моего процессора до уровня FSB-476Mhz х 7), я загрузил х64Win7 на частоте шины в 500Mhz:
Затем я запустил все тот же LinX с объемом задачи 14000, но количеством проходов - 10. Секунд через 5-6 после начала тестирования оно было прервано «синим экраном» с ошибкой 0x00000124. Далее последовала перезагрузка, снижение частоты шины до 495Mhz, F10 - загрузка ОС и вновь запуск тестовой утилиты. На этот раз LinX с теми же условиями тестирования вызвал «синий экран» чуть позже - секунд через 10-15 после старта... Вообщем, дальше я снижал частоту FSB еще на 5Mhz и вновь повторял тест. С каждым разом время проверки «до BSOD 0x00000124» увеличивалось: чем ниже была частота, тем дольше система держала тест (проходя уже по нескольку «кругов»). Наконец, на частоте шины именно 476Mhz линпак в оболочке LinX с объемом задачи 14000 был пройден все 10 раз.
С одной стороны, это говорит о том, что нынешний разгон моего процессора до уровня FSB-476Mhz х 7, пожалуй, и составляет его потолок стабильности. (По крайней мере, в утилите LinX_14000 и при заданном значении VCore 1,5125V по-биосу). С другой же – прослеживается явная зависимость между снижением частоты FSB и увеличением времени тестирования до появления синего экрана. Думаю, это не менее явно свидетельствует о следующем. В моем случае указанный BSOD следует трактовать скорее не в качестве ошибки в работе памяти или материнской платы, но с большой долей уверенности как реакцию LinX на переразгон/недостаток процессорного напряжения именно в среде х64Win7. Да, и расписанная выше проверка разгона на х86WinXP вполне позволяет доверять этому выводу. Ведь странно же получается: на x64 ОС матплата нещадно "бсодит" в процессорном тесте, а на х86-системе (при заметно меньшем значении CPU VCore Voltage) и намека на это нет...
Как нет, собственно, и провала тестирования в утилите Prime95 (режим Blend), что в определенной степени позволило бы «пенять» на BSOD`ы, вызываемые материнской платой. На х86WinXP этот тест при частоте FSB-476Mhz моя система также держит не один час:
~315kb
По итогам всех этих «опытов», я сделал один обобщающий вывод. А именно: для обретения стабильности разогнанного процессора на 64-разрядных Windows 7 в биосе матплаты следует задавать (заметно) большее напряжение CPU VCore, чем в ситуации с 32-битными WinОС - при аналогичных уровне и условиях оверклока, а также последующего тестирования. Естественно, что каждый волен (пере)проверить данное утверждение, проведя аналогичное исследование на своем компьютере.
Но прежде, чем «закрыть» эту отчетную заметку, я хотел бы поблагодарить alex1974 и Xmast с конференции overclockers.ru. Их дискуссия, соображения и доводы в споре о нюансах определения/подтверждения стабильности разгона в х86 и х64 ОС, во-многом, и подвигли автора на проведение расписанного выше исследования. Камрады, спасибо!
Также хотел бы отметить, что настоящая запись – дебютная для меня на Персональных Страницах портала overclockers.ru. И немалая роль в ее появлении принадлежит камраду alex1974, который и предложил объединить мои форумные посты о тестированиях в заметку на ПС.
P.S. Обсудить (похвалить-покритиковать) эту запись можно здесь.
реклама
Лента материалов
Соблюдение Правил конференции строго обязательно!
Флуд, флейм и оффтоп преследуются по всей строгости закона!
Комментарии, содержащие оскорбления, нецензурные выражения (в т.ч. замаскированный мат), экстремистские высказывания, рекламу и спам, удаляются независимо от содержимого, а к их авторам могут применяться меры вплоть до запрета написания комментариев и, в случае написания комментария через социальные сети, жалобы в администрацию данной сети.
Сейчас обсуждают