Изучение нюансов разгона процессоров AMD Trinity

Изучение возможностей разгона AMD A10-5800K: поиск программного обеспечения, наиболее подходящего в качестве теста стабильности системы для разгона CPU, CPU_NB и встроенной графики, изучение зависимости разгона процессора от напряжения питания, а также сравнение разгона при воздушном и жидкостном охлаждении.
1 марта 2013, пятница 03:00
Ivan_FCB для раздела Лаборатория

Оглавление

Вступление

В данном материале в рамках лаборатории будет рассмотрен разгон процессора AMD A10-5800K. Модели AMD Trinity – уже второе поколение «гибридов», или так называемых APU (Accelerated Processing Unit). Под одной крышкой размещены как привычные процессорные ядра, так и интегрированная графика, что для недорогих систем позволяет отказаться от использования внешних видеокарт. Внутри самого A10-5800K находится пара модулей Piledriver, а также графическое ядро HD 7660D на базе архитектуры VLIW4.

По отдельности данные компоненты сильного интереса не представляют, а вот собранные воедино уже могут быть некоторой головоломкой при поиске оптимального разгона. С одной стороны, процесс разгона Piledriver изучен достаточно подробно, а с другой, свое влияние наверняка проявят такие факторы, как отсутствие кэш-памяти третьего уровня, более сложный контроллер памяти и наличие графического ядра.

Тестовый стенд

Тестирование производилось в составе следующей конфигурации:

  • Процессор: AMD A10-5800K;
  • Материнская плата: Gigabyte F2A85X-UP4;
  • Система охлаждения 1: Zalman CNPS10X Performa (120*120*25, ~2000 об/мин);
  • Система охлаждения 2: СЖО на базе водоблока Watercool Heatkiller 3.0 и циркуляционного насоса Lowara TLC 25-7L;
  • Термоинтерфейс: Prolimatech PK-1;
  • Оперативная память: G.Skill TridentX F3-2400C10D-8GTX, 2*4 Гбайта DDR3-2400 (10-12-12-31, 1.65 В);
  • Видеокарта: NVIDIA GeForce GTX 580 1536 Мбайт 772/1544/1002 МГц;
  • Жесткий диск: Western Digital Caviar Blue (WD500AAKS), 500 Гбайт;
  • Блок питания: Corsair CMPSU-750HX, 750 Вт;
  • Корпус: открытый стенд.

Программное обеспечение:

  • Windows 8 Pro;
  • Catalyst 13.2 beta5.

Краткое знакомство с материнской платой

Системная плата всегда привносит тот или иной оттенок в процессе разгона процессора, так что перед тем, как приступить к его рассмотрению, не помешает ознакомиться и с возможностями платы. Ее обзор уже был за авторством I.N., так что по плате «пройдемся» только кратко, по вопросам, которые непосредственно важны для разгона.

Установка напряжений

Так как все указанные в дальнейшем в тексте статьи или на графиках напряжения – значения, установленные в BIOS платы, то замеры необходимы в первую очередь для того, чтобы пользователи других материнских плат могли сопоставлять результаты со своими.

Работа Load-Line Calibration для напряжения питания процессора:

Напряжение Установлено, В Без нагрузки,
программный
мониторинг, В
Под нагрузкой,
программный
мониторинг, В
Без нагрузки,
замер
мультиметром, В
Под нагрузкой,
замер
мультиметром, В
CPU Vcore,
Load Line
calibration
Auto
1.375 1.368 1.332 1.37 1.334
CPU Vcore,
Load Line
calibration
Normal
1.375 1.368 1.332 1.37 1.334
CPU Vcore,
Load Line
calibration
Standard
1.375 1.368 1.332 1.37 1.334
CPU Vcore,
Load Line
calibration
Low
1.375 1.368 1.344 1.372 1.346
CPU Vcore,
Load Line
calibration
Medium
1.375 1.368 1.356 1.374 1.359
CPU Vcore,
Load Line
calibration
Extreme
1.375 1.38 1.392 1.38 1.399

Традиционно для Gigabyte, режимы Load-Line Calibration Auto, Normal и Standard совпадают, что лишь вводит пользователя в заблуждение. По результатам замеров можно сделать вывод, что минимальные расхождения между напряжением питания в простое и под нагрузкой наблюдаются в режиме Medium. Хотя эта разница весьма заметна, но в других режимах она еще выше. Явно не хватает промежуточной настройки между режимами Medium и Extreme. Что касается программного мониторинга, то расхождения с показаниями мультиметра минимальны, на данной материнской плате ему можно доверять.

В дальнейшем, при разгоне процессора использовался режим Vcore LLC Medium.

Работа Load-Line Calibration для напряжения CPU_NB:

Режим работы Установлено, В Без нагрузки,
замер
мультиметром, В
Под нагрузкой,
замер
мультиметром, В
CPU_NB,
Load-Line
Calibration
Auto
1.275 1.275 1.283
CPU_NB,
Load-Line
Calibration
Normal
1.275 1.275 1.283
CPU_NB,
Load-Line
Calibration
Standard
1.275 1.275 1.283
CPU_NB,
Load-Line
Calibration
Low
1.275 1.28 1.288
CPU_NB,
Load-Line
Calibration
Medium
1.275 1.284 1.294
CPU_NB,
Load-Line
Calibration
Extreme
1.275 1.302 1.312

Как и в случае с CPU Vcore, режимы Auto, Normal и Standard показывают одинаковое поведение системы. В каждом из режимов напряжение питания под нагрузкой растет, и чем более агрессивный режим LLC выставлен, тем сильнее рост напряжения. Итого, оптимальнее использовать настройки Auto, где результаты замеров максимально близки к выставленным в UEFI значениям.

Дабы исключить вероятность «самодеятельности» платы в плане Auto (мало ли, переключит режим в зависимости от используемого напряжения?) при дальнейшем разгоне процессора использовался режим CPU_NB LLC Normal.

Результаты замера вторичных напряжений:

Напряжение Установлено, В Без нагрузки,
замер
мультиметром, В
Под нагрузкой,
замер
мультиметром, В
DRAM Voltage 1.6 1.605 1.607
APU VDD 1.2 1.199 1.2
FCH Voltage 1.1 1.104 1.106

Расхождения установленных в UEFI значений с показаниями мультиметра невелики, и ими можно пренебречь.

Все замеры производились при помощи мультиметра Mastech MY64.

Разгон базовой частоты

Поскольку процессоры Llano и Trinity в отличие от предшественников без встроенной графики работают на базовой частоте 100 МГц, а не 200 МГц, то точный поиск стабильных частот осложнен. На это влияет и отсутствие «дробных» коэффициентов умножения CPU, и сама величина коэффициента умножения, который для штатной частоты ЦП равен уже Х38. Как итог, каждый шаг изменения базовой частоты приводит к большему увеличению частоты работы процессора, помимо этого уменьшается количество возможных сочетаний базовой частоты и коэффициента умножения. Так что лучше заранее знать, какие настройки доступны материнской плате.

К сожалению, результаты разгона базовой частоты совпали с теми, которые были достигнуты I.N. в своем обзоре, то есть 106.5 МГц. При этом можно отметить весьма скверную точность ее установки. Приведу все доступные значения базовой частоты в таблице ниже:

Установлено
в UEFI, МГц
Реальное
значение, МГц
100 99.82
101 101.9
102 102.32
103 103.16
104 103.98
105 106.49
106 106.49

Как можно заключить, перечень доступных настроек не очень-то и впечатляющий, что в дальнейшем может усложнить процесс разгона. Печально, но ничего с этим не поделать. Возможно, стоило просить у AMD на тесты MSI FM2-A85XA-G65 (предоставляли выбор из двух моделей материнских плат), но после того, как wildchaser и I.N. нарисовали себе по звезде «за сбитого», выбор пал на Gigabyte.

Разгон встроенной графики

В UEFI шаг изменения частоты встроенного графического ядра составляет 1 МГц, но после результатов разгона базовой частоты не мешает проверить и то, как система реагирует на изменение частоты встроенной графики. Оказалось, проверка была не зря: несмотря на шаг в 1 МГц, реально доступными оказались лишь несколько фиксированных значений частоты, это 800 МГц -> 844 МГц -> 894 МГц -> 950 МГц -> 1013 МГц -> 1086 МГц -> 1169 МГц.

При любом другом выставленном значении устанавливается частота предыдущей отметки, то есть, если выставить в UEFI частоту графики 1168 МГц, то система запустится на частоте 1086 МГц и так далее. Значение следующей после 1169 МГц отметки вычислить не удалось – это максимальная частота, при которой материнская плата стартовала.

Что ж, видимо, при поиске стабильных частот графики придется повозиться.

С материнской платой закончили, можно приступать к изучению возможностей процессора.

Процессорная часть

Так как у Trinity есть встроенная графика, то описание разгона поделено на две части. Сначала рассмотрим возможности вычислительной части, то есть непосредственно процессора и CPU_NB. Тем временем, графику пока отключим, установив в систему внешнюю видеокарту.

Поиск ПО для выявления нестабильности

Предыдущие опыты по процессорам AMD Bulldozer и AMD Vishera показали, что для определения стабильности лучше подходят специализированные стресс-тесты, нежели тесты производительности системы или игры, так что на сей раз остановимся только на них.

Программное обеспечение, выбранное для выявления нестабильности:

  • LinX 0.6.4 (тестирование производилось в режиме 2560 Мбайт для старой версии Linpack, а также в трех режимах, с доступной памятью 1024 Мбайта, 2560 Мбайт и 6144 Мбайта для последней версии Linpack, с поддержкой инструкций FMA);
  • OCCT 4.3.2.b01 (тест CPU: OCCT в режимах Large Data Set, Medium Data Set и Small Data Set, а также тест CPU: LINPACK в режиме AVX с 90% доступной памяти);
  • Prime95 v27.7 build2 (в режимах Small FFTs, In-place Large FFTs и Blend);
  • CST 0.20.01a (комбинированный тест, включающий в себя режимы Matrix=5, Matrix=7 и Matrix=15).

За стабильность принято состояние системы, при котором в течение 10-15 минут работы теста не возникает каких-либо проблем в работе системы.

Нестабильность процессора

В данном подразделе статьи выберем программное обеспечение, при помощи которого легче выявить нестабильность именно процессора, при заведомо стабильных частотах памяти и CPU_NB.

Методика относительно проста: при фиксированном значении напряжения питания подобрать максимальный разгон для каждой из программ и вычислить тест, при котором будет достигнута минимальная частота стабильной работы. Ну, а параллельно поиску стабильных частот можно и оценить поведение системы при переразгоне для того или иного теста. Дабы избежать нестабильности, вызванной перегревом ЦП, все тесты производились при штатном напряжении питания CPU (1.375 В).

Частота работы процессора, при которой стартует Windows – 4392 МГц.

Таблица с результатами разгона A10-5800K под стресс-тестами:

Тест Результат
разгона
процессора, МГц
Поведение
системы при легком
переразгоне
(20-60 МГц)
Поведение
системы при среднем
переразгоне
(60-100 МГц)
Поведение
системы при сильном
переразгоне
(свыше 100 МГц)
LinX 0.6.4,
2560 Мбайт
4263 Остановка теста в связи с ошибкой Остановка теста в связи с ошибкой Зависание системы на первых секундах теста
LinX 0.6.4,
1024 Мбайт + Linpack 11.0.1.005
4192 Остановка теста в связи с ошибкой Зависание системы на первых секундах теста Перезагрузка системы после первых секунд появления нагрузки
LinX 0.6.4,
2560 Мбайт + Linpack 11.0.1.005
4159 Остановка теста в связи с ошибкой Зависание системы спустя 30-40 секунд после включения нагрузки Перезагрузка системы после первых секунд появления нагрузки
LinX 0.6.4,
6144 Мбайт + Linpack 11.0.1.005
4159 Остановка теста в связи с ошибкой Зависание системы спустя 40-50 секунд после включения нагрузки Перезагрузка системы после первых секунд появления нагрузки
OCCT 4.3.2.b01,
LINPACK + AVX
4263 Зависание системы после 4-5 минут работы теста Зависание системы на первых секундах теста Перезагрузка системы после первых секунд появления нагрузки
OCCT 4.3.2.b01,
Large Data Set
4192 Зависание системы на первых минутах теста Зависание системы на первых секундах теста Зависание системы на первых секундах теста
OCCT 4.3.2.b01,
Medium Data Set
4229 Зависание системы на первых минутах теста Остановка теста в первые секунды теста в связи с ошибкой Зависание системы на первых секундах теста
OCCT 4.3.2.b01,
Small Data Set
4229 Зависание системы на первых минутах теста Остановка теста в первые секунды теста в связи с ошибкой Зависание системы на первых секундах теста
Prime 95 v27.7 build2,
Small FFTs
4159 Остановка теста в связи с ошибкой Зависание системы на первых минутах теста Зависание системы на первых секундах теста
Prime 95 v27.7 build2,
In-place Large FFTs
4192 Остановка теста в связи с ошибкой Остановка теста в связи с ошибкой Зависание системы на первых секундах теста
Prime 95 v27.7 build2,
Blend
4192 Зависание системы после 4-5 минут работы теста Зависание системы на первых минутах теста Зависание системы на первых секундах теста
CST 0.20.01a 4292 Остановка теста в связи с ошибкой Остановка теста в связи с ошибкой

Как видно, исходя из таблицы выше, наиболее лучший результат показали такие тесты, как Prime 95 в режиме Small FFTs и Linpack последней версии в режимах с доступной памятью 2560 Мбайт и 6144 Мбайта. Чуть позади остались такие тесты, как Prime 95 в режимах In-place Large FFTs и Blend, а также Linpack последней версии в режиме с доступной памятью 1024 Мбайта и OCCT 4 в режиме Large Data Set. Все вышеперечисленные тесты уложились в 33 МГц разницы разгона процессора. Остальные тесты/режимы показывают уже более худшие результаты.

Отмечу, что плотность результатов «лидирующей группы» выше, чем в случае с процессорами AMD Bulldozer и AMD Vishera.

Нестабильность CPU_NB

В данном подразделе статьи выберем программное обеспечение, при помощи которого легче выявить нестабильность CPU_NB (встроенный в процессор контроллер памяти), при заведомо стабильных частотах ЦП и памяти. Методика та же, что и в случае с поиском ПО для тестирования CPU: при фиксированном значении напряжения питания подобрать максимальный разгон для каждой из программ и вычислить тест, при котором будет достигнута минимальная частота стабильной работы. Все тесты производились при штатном напряжении питания CPU_NB 1.275 В. Так как CPU_NB включает в себя контроллер памяти, к списку стресс-тестов добавлен Memtest-86 v4.0a.

Частота, при которой стартует Windows – 2595 МГц.

Таблица с результатами разгона A10-5800K под стресс-тестами:

Тест Результат
разгона
процессора, МГц
Поведение
системы при
переразгоне
LinX 0.6.4,
2560 Мбайт
2495 Зависание системы
LinX 0.6.4,
1024 Мбайт + Linpack 11.0.1.005
2495 Остановка теста в связи с ошибкой
LinX 0.6.4,
2560 Мбайт + Linpack 11.0.1.005
2495 Зависание системы
LinX 0.6.4,
6144 Мбайт + Linpack 11.0.1.005
2495 Зависание системы
OCCT 4.3.2.b01,
LINPACK + AVX
2579 Зависание системы
OCCT 4.3.2.b01,
Large Data Set
2495 Остановка теста в связи с ошибкой
OCCT 4.3.2.b01,
Medium Data Set
2495 Остановка теста в связи с ошибкой
OCCT 4.3.2.b01,
Small Data Set
2495 Остановка теста в связи с ошибкой
Prime 95 v27.7 build2,
Small FFTs
2595
Prime 95 v27.7 build2,
In-place Large FFTs
2495 Остановка теста в связи с ошибкой
Prime 95 v27.7 build2,
Blend
2495 Остановка теста в связи с ошибкой
CST 0.20.01a 2595
Memtest-86 v4.0a 2495 Зависание системы

Результаты весьма интересны. С одной стороны, разница между лучшим и худшим значением стабильной частоты составляет 100 МГц, то есть разброс выше, чем у моделей AMD Bulldozer и AMD Vishera, с другой стороны – подавляющее большинство тестов остановилось на одной и той же частоте стабильной работы в 2495 МГц. Хотя здесь очевидно, что проблема кроется в доступных значениях базовой частоты материнской платы, при которых доступны частоты 2495 МГц -> 2548 МГц -> 2558 МГц -> 2579 МГц -> 2595 МГц.

Так что для отличившихся тестов пришлось на частоте 2495 МГц проводить дополнительное тестирование: на выявление минимального напряжения питания CPU_NB, дабы таки выявить лучшие/худшие тесты.

Тест Требуемое
напряжение
питания
CPU_NB, В
LinX 0.6.4,
2560 Мбайт
1.225+
LinX 0.6.4,
1024 Мбайт + Linpack 11.0.1.005
1.225+
LinX 0.6.4,
2560 Мбайт + Linpack 11.0.1.005
1.225+
LinX 0.6.4,
6144 Мбайт + Linpack 11.0.1.005
1.2375+
OCCT 4.3.2.b01,
Large Data Set
1.225+
OCCT 4.3.2.b01,
Medium Data Set
1.225+
OCCT 4.3.2.b01,
Small Data Set
1.2125+
Prime 95 v27.7 build2,
In-place Large FFTs
1.225+
Prime 95 v27.7 build2,
Blend
1.2375+
Memtest-86 v4.0a 1.2375+

Что ж, при таком раскладе картина уже более ясна, и появляется возможность выявить наиболее подходящие тесты стабильности. Таковыми оказались Prime 95 в режиме Blend, Memtest-86, а также Linpack последней версии в режиме с доступной памятью 6144 Мбайта.

Сравнение стресс-тестов для проверки температурного режима

Мониторинг температурного режима – больная тема для Trinity, получаемые цифры сильно зависят от утилит мониторинга, причем все любят показывать для состояния простоя температуры ниже комнатных. При замерах температур использовалась утилита, идущая в комплекте с материнской платой – Gigabyte ET6.

Для того, чтобы более адекватно оценить разницу в результатах, были использованы сразу три различных уровня напряжения: 1.4 В, 1.5 В и 1.5875 В. Система охлаждения – Zalman CNPS10X Performa.

Тест Пиковое
значение
температуры
процессора при 1.4 В
Пиковое
значение
температуры
процессора при 1.5 В
Пиковое
значение
температуры
процессора при 1.5875 В
LinX 0.6.4,
2560 Мбайт
48 63 85
LinX 0.6.4,
1024 Мбайт + Linpack 11.0.1.005
46 60 83
LinX 0.6.4,
2560 Мбайт + Linpack 11.0.1.005
48 61 84
LinX 0.6.4,
6144 Мбайт + Linpack 11.0.1.005
47 61 85
OCCT 4.3.2.b01,
LINPACK + AVX
48 62 84
OCCT 4.3.2.b01,
Large Data Set
48 62 78
OCCT 4.3.2.b01,
Medium Data Set
47 60 75
OCCT 4.3.2.b01,
Small Data Set
48 63 79
Prime 95 v27.7 build2,
Small FFTs
48 63 79
Prime 95 v27.7 build2,
In-place Large FFTs
49 64 80
Prime 95 v27.7 build2,
Blend
49 64 80
CST 0.20.01a 46 60 75

Интересно, что при разном уровне напряжения питания пиковое значение температуры достигается в различных программах. Так, при 1.4 В и при 1.5 В это Prime 95 в режимах Blend и In-place Large FFTs, а при максимальном значении 1.5875 В в лидерах с разницей в 4-5 градусов уже Linpack тесты. Что интересно – более «горячие» результаты показывает медленная версия Linpack’а. Хотя не исключено, что это просто «причуды» мониторинга.

Разгон процессора

Вот и подошло время перейти непосредственно к процессу разгона. В данном подразделе статьи изучим зависимость результатов разгона от установленного напряжения питания, а также сравним разгон на воздушном и жидкостном охлаждении, что, сопоставив результаты, позволит выявить зависимость разгона от температурного режима процессора.

Как и ранее, помимо изучения возможностей к увеличению штатной частоты, проверена и работа режимов с заниженным напряжением питания CPU. Точкой отсчета выбрано минимальное напряжение, требуемое для стабильной работы ЦП на частоте 3 ГГц (2994 МГц, с поправкой на точность установки базовой частоты материнской платой).

Результаты A10-5800K с воздушным охлаждением:

Процессор отвечает неплохим ростом частотного потенциала на увеличение напряжения питания вплоть до 1.5 В, после дивиденды от увеличения напряжения питания уже не так велики. Отмечу, что на фоне протестированных ранее старших представителей линеек AMD Bulldozer и AMD Vishera результаты разгона выглядят откровенно слабыми. Тем более что процессорная часть Trinity куда проще, ведь урезана в два раза по количеству ядер, и отсутствует кэш-память третьего уровня. Видимо, все же оказывает влияние наличие встроенной графики, даже когда та не задействована.

К слову, использование встроенной графики вместо внешней видеокарты сколько-нибудь значимых изменений в разгон процессора не привносит. Можно отметить, что достигнутая частота в 4539 МГц не является для стендового ЦП пределом на воздушном охлаждении, просто тут свою лепту вносит материнская плата, не позволяющая изменять его частоту с достаточно низким шагом (следующий шаг частоты – уже 4592 МГц, что ему не под силу). Лишние 20-30 МГц наверняка еще можно было бы «выжать», пусть и с поднятием напряжения питания свыше 1.6 В.

Зависимость температурного режима от напряжения питания процессора:

В целом, слишком сильный рост температур наблюдается лишь при переходе от 1.5375 В к 1.5875 В, в остальных случаях рост температурного режима с увеличением напряжения питания более-менее плавен.

При этом относиться к графику можно двояко. С одной стороны, по форме график вроде и близок к тому, что должен быть, а с другой, крайние точки графика видятся как промахи мониторинга температур, и если с нижними значениями все понятно – показания температуры на уровне комнатной под нагрузкой быть не могут, то с верхними значениями возникает вопрос о предыдущем графике, с результатами максимального разгона процессора.

Получается, что или ЦП устойчив к высоким температурам, и разгон к температурному режиму не критичен, или все же мониторинг не совсем адекватен. С другой стороны, на тех же AMD Vishera рост температур в первую очередь бил по стабильности CPU_NB, или, что вероятнее – по кэш-памяти третьего уровня, которой нет у Trinity. Скорее всего, именно это отличие приводит к возможности стабильной работы процессора при высоких температурах.

С воздушным охлаждением разобрались, самое время рассмотреть результаты разгона при переходе на жидкостное охлаждение:

График для сравнения разгона на воздушном и жидкостном охлаждении:

Разница между максимальными результатами даже с учетом разницы в используемых напряжениях составила лишь чуть более 100 МГц, то есть можно сделать вывод, что вклад температурного режима в результат разгона минимален, и все определяется скорее удачностью конкретно взятого экземпляра процессора, нежели эффективностью системы охлаждения (в разумных пределах). Думаю, что хороший экземпляр A10-5800K мог бы и на воздушном охлаждении показать результат выше, нежели используемый ЦП с жидкостным охлаждением. Что касается максимальной разницы в результатах разгона при одном уровне напряжения питания, то это 65 МГц, что находится на равном с протестированным ранее FX-8350 уровне.

Зависимость температурного режима от напряжения питания процессора:

Разница по сравнению с воздушным охлаждением весьма заметна только при высоких напряжениях, к примеру, при равном напряжении 1.5875 В разница между воздушным и жидкостным охлаждением составляет 21 градус. При этом отличия видны не только в цифрах, но и в самой форме графика, который стал более плавным на всем своем протяжении. Интересно, что в конце графика изгиб уже начинает усиливаться, и, вероятно, следующий шаг напряжения уже привел бы к скачку температуры, сравнимому с переходом на 1.5875 В при воздушном охлаждении. При всем при этом, температура у основания водоблока колебалась на уровне комнатной.

Напоследок приведу сравнение температурного режима при воздушном и жидкостном охлаждении:

По графику видно, что до уровня 1.5375 В разница не такая уж и большая, несмотря на отличие в эффективности систем охлаждения. Возможно, проблема заключается в малой площади кристалла, и в не самом лучшем отводе тепла от него к теплораспределителю. Нечто подобное можно видеть у процессоров Intel Ivy Bridge. Ведь судя по температуре у основания водоблока, да и по температуре воздуха, выходящего из CNPS10X Performa, можно сделать вывод о том, что у A10-5800K не такой уж и горячий нрав, как можно видеть по температурным графикам.

Разгон CPU_NB

В данном подразделе статьи изучим зависимость результатов разгона CPU_NB от установленного напряжения питания. Как и в случае с разгоном процессора, произведено и сравнение результатов разгона в зависимости от системы охлаждения.

Точкой отсчета взято минимальное напряжение питания, при котором система стабильна на штатной частоте CPU_NB в 1800 МГц (1797 МГц, с поправкой на точность установки базовой частоты материнской платой).

Результат разгона CPU_NB явно лучше, чем у протестированного ранее FX-8350, но в то же время разгон слабее, нежели у моделей AMD Bulldozer. Можно отметить явную разницу в поведении процессоров – если представители AMD Bulldozer и AMD Vishera на увеличение напряжения CPU_NB свыше 1.3-1.35 В отзывались не слишком охотно, то здесь график почти не меняет вида и при переходе от 1.4 В к 1.45 В. Отсутствие кэш-памяти третьего уровня на поведении ЦП сказывается заметно. Но тут главное – в порыве азарта не загубить его высокими напряжениями, и даже несмотря на хороший отклик, для постоянной работы процессора лучше напряжениями не злоупотреблять.

Отмечу, что включение интегрированной графики негативно сказывается на разгоне CPU_NB, в среднем, график смещается примерно на 0.05-0.07 В вправо, без изменения поведения.

Результаты разгона с жидкостным охлаждением:

График для сравнения разгона на воздушном и жидкостном охлаждении:

По сравнению с процессорами AMD Vishera, рост результатов разгона от перехода на жидкостное охлаждение не так велик, и находится примерно на равном с моделями AMD Bulldozer уровне. При этом поведение ЦП остается схожим, резкого увеличения разницы результатов при увеличении напряжения питания не наблюдается. Отдельно отмечу, что при использовании встроенной графики результаты разгона CPU_NB находятся примерно на том же уровне, что и с воздушным охлаждением, то есть при использовании встроенной графики жидкостное охлаждение не приносит выгоды.

Графическая часть

С изучением возможностей процессора как конкретно процессора закончили, так что теперь с чистой совестью можно приступить к изучению возможностей встроенной графики.

Поиск ПО для выявления нестабильности встроенной графики

В данном подразделе статьи выберем программное обеспечение, при помощи которого легче выявить нестабильность встроенной графики, при заведомо стабильных частотах процессора, памяти и CPU_NB. Методика относительно проста: при фиксированном значении напряжения питания подобрать максимальный разгон для каждой из программ и вычислить тест, при котором будет достигнута минимальная частота стабильной работы. Помимо этого, параллельно поиску частот производилась оценка поведения системы при переразгоне. Все тесты производились при штатном напряжении питания встроенной графики 1.2 В.

Вопрос поиска ПО для выявления нестабильности графики довольно сложен, ибо ранее всерьез не рассматривался, так что была попытка охватить максимально возможное количество игр/тестов.

В список попали следующие синтетические тесты:

  • FurMark 1.10.4;
  • OCCT 4.3.2 в режимах DX9 и DX10;
  • 3DMark Vantage;
  • 3DMark 11;
  • HWBOT Unigine Heaven Benchmark;
  • GUIMiner v2012-12-03.

И следующие игры:

  • Assassin's Creed 3;
  • Batman: Arkham City;
  • Battlefield 3;
  • Deus Ex: Human Revolution;
  • Dishonored;
  • Dirt: Showdown;
  • Dragon Age II;
  • Far Cry 3;
  • Hitman: Absolution;
  • Sleeping Dogs;
  • Metro 2033;
  • The Elder Scrolls V: Skyrim;
  • The Witcher 2: Assassins of Kings;
  • Total War: Shogun 2.

Частота работы встроенной графики, при которой стартует Windows – 1169 МГц.

Таблица с итоговыми результатами разгона для штатного напряжения графического ядра 1.2 В:

Тест Итоговый
результат
разгона
встроенной
графики, МГц
Поведение
системы при
переразгоне
на 1 шаг частоты
Поведение
системы при
переразгоне
на 2 и более шага частоты
FurMark 1.10.4 1013 Сброс частоты работы графического ядра до 217 МГц и сообщение «Видеодрайвер перестал отвечать и был успешно восстановлен» Появление артефактов и последующее зависание системы
OCCT 4.3.2, DX9 844 Монотонное закрашивание экрана и зависание системы Перезагрузка системы после первых секунд теста
OCCT 4.3.2, DX10 950 Сброс частоты работы графического ядра до 217 МГц и сообщение «Видеодрайвер перестал отвечать и был успешно восстановлен» Сброс частоты работы графического ядра до 217 МГц и сообщение «Видеодрайвер перестал отвечать и был успешно восстановлен»
3DMark Vantage 1013 Зависание системы в произвольных местах Зависание системы на первых секундах теста
3DMark 11 1013 Зависание системы в произвольных местах Зависание системы на первых секундах теста
HWBOT Unigine Heaven Benchmark 1013 Вылет программы
GUIMiner v2012-12-03 1086 Остановка вычислений в связи с ошибкой
Assassin's Creed 3 950 BSOD Вылет программы, иногда со сбросом частоты работы графического ядра до 217 МГц и сообщением «Видеодрайвер перестал отвечать и был успешно восстановлен»
Batman: Arkham City 1013 Сброс частоты работы графического ядра до 217 МГц и сообщение «Видеодрайвер перестал отвечать и был успешно восстановлен» Зависание системы
Battlefield 3 1013 Зависание системы Зависание системы
Deus Ex: Human Revolution 1013 Сброс частоты работы графического ядра до 217 МГц и сообщение «Видеодрайвер перестал отвечать и был успешно восстановлен» Зависание системы
Dishonored 950 Зависание системы Перезагрузка системы
Dirt: Showdown 1013 Вылет игры Зависание системы
Dragon Age II 1013 Зависание системы Зависание системы
Far Cry 3 1013 Сброс частоты работы графического ядра до 217 МГц и сообщение «Видеодрайвер перестал отвечать и был успешно восстановлен» Фризы и последующее зависание системы
Hitman: Absolution 1013 Вылет программы, иногда со сбросом частоты работы графического ядра до 217 МГц и сообщением «Видеодрайвер перестал отвечать и был успешно восстановлен» Зависание системы
Sleeping Dogs 1013 Зависание системы Перезагрузка системы
Metro 2033 844 Зависание системы спустя 4-5 минут работы теста Зависание системы на первом проходе бенчмарка
The Elder Scrolls V: Skyrim 1013 Зависание системы Перезагрузка системы
The Witcher 2: Assassins of Kings 1013 Сброс частоты работы графического ядра до 217 МГц и сообщение «Видеодрайвер перестал отвечать и был успешно восстановлен» Зависание системы
Total War: Shogun 2 950 Вылет программы Сброс частоты работы графического ядра до 217 МГц и сообщение «Видеодрайвер перестал отвечать и был успешно восстановлен»

Вообще, перед тем, как приступить к проверке тестов и игр была мысль, что разница между различным ПО будет небольшой, ведь тут накладывается и довольно солидный шаг по изменению частоты работы встроенной графики (напомню, 800 МГц -> 844 МГц -> 894 МГц -> 950 МГц -> 1013 МГц -> 1086 МГц -> 1169 МГц). На деле же оказалось, что разброс очень велик. Наибольшие требования к стабильности системы предъявили такие тесты, как Metro 2033 и OCCT 4.3.2 в режиме DX9.

Разгон встроенной графики

В качестве теста стабильности была выбрана Metro 2033. Опираясь на возможности материнской платы по изменению частоты работы графического ядра по сравнению с разгоном процессора и CPU_NB в методику пришлось вносить коррективы. Точка отсчета, как и в случае с CPU_NB – минимальное значение напряжения, необходимое для работы графики на штатной частоте (800 МГц). Но в дальнейшем подбиралась не максимальная стабильная частота работы (в зависимости от установленного напряжения), а напряжение, требуемое для каждого последующего шага увеличения частоты.

Итого, результат разгона:

Разгон откровенно слабоват, да и на увеличение напряжения питания отклик слабый. Также отметку наложил и весьма большой шаг изменения частоты. К примеру, при сохранении текущей линии графика, для следующего шага частоты в 1013 МГц надо уже ~1.55 В. Отдельно можно отметить слабость преобразователя питания встроенной графики: помимо Metro 2033 с увеличением напряжения питания был проверен и OCCT 4.3.2 в режиме DX9. Так вот, при напряжении питания 1.28-1.3 В в OCCT система теряет стабильность уже при штатной частоте работы.

Отдельно отмечу, что переход с воздушного охлаждения на жидкостное к улучшению результатов разгона не привел, как и попытки манипуляции с напряжениями питания VCore и CPU_NB. Видимо, все же сказывается общая бюджетность платформы.

Заключение

Все уже было сказано в статье выше, но необходимо сделать краткое заключение. Для удобства восприятия разобью выводы по пунктам:

  • Как тест определения стабильности лучше всего показали себя Prime 95 в режиме Small FFTs, а также Linpack последней версии в режимах с доступной памятью 2560 Мбайт и 6144 Мбайта. Чуть позади остались такие тесты, как Prime 95 в режимах In-place Large FFTs и Blend, Linpack последней версии в режиме с доступной памятью 1024 Мбайт и OCCT 4 в режиме Large Data Set.
  • Для выявления нестабильности CPU_NB наиболее подходят такие стресс-тесты как Prime 95 в режиме Blend, Memtest-86, а также Linpack последней версии в режиме с доступной памятью 6144 Мбайта.
  • Для выявления нестабильности встроенной графики наиболее подходят такие тесты, как OCCT 4 в режиме DX9 и Metro 2033.
  • В качестве теста на прогрев лучшие результаты показали Prime 95 в режимах Blend и In-place Large FFTs при низких напряжениях, и Linpack тесты при напряжениях, близких к максимально допустимым. Что интересно – более «горячие» результаты показывает медленная версия Linpack’а.
  • Возможно, показания мониторинга температур не совсем точны.
  • Влияние температуры ЦП на результаты разгона невелико, дивидендов от использования жидкостного охлаждения почти нет.
  • Наличие в процессоре встроенной графики негативно сказывается на разгоне, его результаты хуже, чем у моделей AMD Bulldozer и AMD Vishera.
  • Материнская плата для разгона подходит «так себе», возможно, что здесь сказывается общая дешевизна платформы FM2.

Конев Иван aka Ivan_FCB

Выражаем благодарность:

  • Компании AMD и лично Шакирову Ильясу за предоставленные на тестирование процессор AMD A10-5800K и материнскую плату Gigabyte F2A85X-UP4.