Феном, пингвин и оверклокинг (часть 1)
Интро
Волею судеб, являюсь я (не)счастливым обладателем процессора Phenom II x6 1090T. Штука, в принципе, неплохая и по нынешним временам, но, при моей специфике применения компа, именно мощность CPU оказалась его бутылочным горлышком. Специфика эта состоит в том, что я пользуюсь в качестве домашней ОС Линуксом, а именно Ubuntu MATE. Интернеты, редактирование фото и, нечасто, видео, а к тому же еще и игры. Большей частью нативные, но бывает и под Proton'ом. Для первых трех применений Фенома хватает, а вот в третьем... Игры под Линукс частенько оказываются гораздо более процессорозависимы, чем их виндовые версии. Кривые порты и трансляция команд из одного API в другое дают о себе знать. Тут рулит производительность на ядро, чем Феном похвастаться не может. С пришествием Vulkan и DXVK ситуация понемногу меняется, но уже вышедшие игры переделывать никто не станет, увы. Таким образом, я пришел к тому, что процессор надо гнать, иначе толка не будет. О моих приключениях на пути оверклокинга и будет дальнейший рассказ.
реклама
Рассказ оный долгий, потому я разбил его на три тематические части. В первой я хочу коснуться темы наблюдения за различными параметрами системы в Линукс. Тема эта в сети в какой-то степени освещенная, но либо в специфично-серверном контексте, либо очень поверхностно. Я сильно углубляться тоже не буду, просто поделюсь опытом того, какие хотелки по наблюдению за системой мне удалось реализовать, не выходя за рамки имеющихся у простого юзера (т.е. меня) знаний.
Кратко о моем железе (подробнее - в одной из следующих частей): материнка MSI 750-G55 под AM3, две планки по 4 ГБ DDR3 1600 МГц Kingston FURY HyperX и видеокарта Palit JetStream 1060 с 3 ГБ памяти. Последняя, очевидно, избыточна для этой системы, но майнинговые ценовые флуктуации позволили купить ее чуть дороже, чем 1050Ti, при неслабой разнице в производительности. В качестве ОС установлена Ubuntu MATE 16.04 x86_64, не так давно перенесенная на 256 ГБ SSD. Обновление на 18.04 в планах есть и, скорее всего, оно сможет заметно повысить производительность в играх, но, пока, на это нет времени.
Разгонять я собираюсь процессор и, как непосредственно с ним связанную, память. Для процессора мне показались необходимыми к наблюдению следующие параметры: частота, напряжение, температура. Хорошо бы еще посмотреть на частоту и напряжение контроллера памяти, встроенного в процессор и температуру зоны VRM. Для самой памяти полезны будут частота, напряжение и тайминги. Это минимум, которого мне должно быть достаточно для разгона. Но, кроме инфы о железе, нужно еще знать, как система его использует, т.е. мне еще понадобится информация о загрузке работой ядер процессора.
Частота процессора
реклама
В наблюдении за частотой процессора в Линукс почти в реальном времени мне помогла следующая команда: watch -n 1 "grep MHz /proc/cpuinfo"
Синтаксис ее прост. Команда watch запускает заданную утилиту раз в указанное количество секунд и следит за ее результатом. Параметр -n со значением 1 - это как раз интервал в 1 с. Утилита grep выводит строки, содержащие MHz из файла /proc/cpuinfo, в котором находится актуальная информация о состоянии процессора. Для шестиядерного Фенома я получил обновляемый раз в секунду вывод такого вида:
Когда я включал в биосе C'n'Q, то мог наблюдать за изменением частоты в зависимости от нагрузки. Кроме того, я хотел таким способом посмотреть на действие технологии Turbo CORE, повышающей частоту трех ядер, при отсутствии нагрузки на остальные три ядра, но, увы, этой информации в /proc/cpuinfo нет. Увидеть работу указанной технологии в деле можно опосредованно - наблюдая за напряжением процессора.
Напряжения и температуры
реклама
В деле отлова напряжений мне опять пригодилась команда watch, но запускал ею я уже другую утилиту: watch -n 1 sensors
Синтаксис аналогичный, так что сразу расскажу о самой утилите sensors. Это часть пакета lm-sensors. Устанавливается он из стандартных репозиториев, а настраивается командой sudo sensors-detect
, которая при этом спросит, с каких интерфейсов и датчиков снимать показания. Для их снятия утилите понадобится загрузить соответствующие модули в ядро системы. Для загрузки этих модулей по умолчанию при старте системы, утилите понадобится разрешение, которое она так же спросит. Если модуль откажется работать с ядром (у меня на ноуте так было), проблем это не вызывает - появляется только пара лишних сообщений при загрузке системы, но ОС грузится и позволяет потом удалить эти модули из списка загружаемых (см. файл /etc/modules). Если все прошло хорошо, то запустив sensors указанной выше командой, можно получить такой вывод:
На первый взгляд, ничего непонятно. Какие-то безымянные температуры, напряжение и обороты в минуту. Для того, чтобы информация была удобоваримой, придется утилиту sensors немного настроить под имеющиеся материнскую плату и процессор. Мануал есть тут: lm-sensors (Русский) в ArchWiki.
реклама
Для моей материнки настройка выглядит так. Вывод sensors состоит из двух блоков: f71889fg-isa-0a00 и k10temp-pci-00c3. Первый блок - показания датчиков материнки, выдаваемые микросхемой F71889F по шине ISA. Второй - данные с датчика температуры процессора, выдаваемые самим процессором по шине PCI. Из всего сонма показаний сходу понятны только +3,3V, 3VSB, Vbat - это соответствующие напряжения. С остальными надо разбираться методом научного тыка. Для этого я проверил в биосе в разделе H/W Monitoring обороты вентиляторов и температуры и нашел соответствие среди этих fan и temp. В разделе Cell Menu я понаблюдал за выставленными напряжениями (с учетом вероятной погрешности между выставленным в настройках и измеренным напряжением) и сопоставил с in'ами. Но для датчика температуры процессора все оказалось немного сложнее.
Цитата из FAQ'а виндовой программы CPU Temp:
Процессоры AMD на архитектуре Phenom и Phenom II (Athlon II, Sempron II, Turion II и т.д.) и все новые процессоры AMD, типа FX и APU-серий, оборудованы только одним термодатчиком. Поэтому Core Temp показывает только одну температуру. На этих процессорах нет способа считывания показания температуры отдельно для каждого ядра.
Начиная с Феномов, амдешный цифровой датчик не показывает абсолютное значение температуры, а выдает его только с некоторым смещением, значение которого точно не известно. Предположительно, это значение находится в диапазоне 10 - 20 градусов Цельсия.
Отсюда следует, что для получения температуры более-менее близкой к реальной, мне нужно прибавить к temp1 датчика k10temp величину смещения. Ориентировался я на датчик температуры процессора на мат. плате (temp1 с f71889fg) - температура на самом процессоре должна быть на несколько градусов больше. 39 (датчик мат. платы) - 20,5 (датчик процессора) = 18,5, округляем до 20, это и будет величиной смещения.
Осталась мелочь - скормить всю полученную информацию утилите sensors. Для этого нужно создать файл (название произвольное, свою материнку я вписал просто для порядка) /etc/sensors.d/msi_750-G55
и записать в него настройки:
Синтаксис вполне очевидный. В кавычках после chip записывается название соответствующей микросхемы. После label идет имя датчика этой микросхемы, а в кавычках то, на которое оно заменяется. В строке compute первое число определяет то, как изменится показание датчика при передаче от микросхемы к операционке. Второе - в обратном направлении. Символом @ обозначено изменяемое значение. Строчки, начинающиеся с ignore, скрывают ненужные (я не смог понять, за что они отвечают) показатели. В результате вывод sensors получает вполне цивилизованный вид:
Но кроме обновляемого текущего значения температуры, полезно иногда иметь перед глазами график, показывающий динамику ее изменения. Такого рода функционал есть у утилиты psensor. Она также имеется в репозитории. Выглядит окно программы так:
Очевидно, здесь не только данные по материнке и процессору от утилиты sensors, но и кое-какая информация по видеокарте и жестким дискам. Можно включать/выключать отображение показаний, переименовывать их, изменять цвет графиков и т.д. - визуализация хороша. С помощью этой утилиты можно проследить за тем, когда график температуры процессора превратится из восходящей кривой в горизонтальную прямую, т.е. когда температура установится на постоянном значении.
Загрузка ядер
Информацию об этом может дать утилита htop, которая устанавливается из репозитория. Выглядит запущенная в эмуляторе терминала программа так (запущен однопоточный тест процессора):
Очевидно, утилита представляет собой диспетчер задач. Функционал его очень богат (см. статью "Htop: интерактивный инструмент мониторинга системы" Гэри Ричмонда), но в данном случае мне от него нужны только индикаторы в верхнем левом углу. Цифры 1-6 обозначают ядра процессора, справа от них полоса загрузки ядра и отображение ее же в процентах. Цвет индикатора загрузки ядра обозначает следующее: синий - процессы с низким приоритетом, зеленый - процессы с нормальным приоритетом, красный - процессы ядра, бирюзовый - процессы виртуализации.
Еще один вид мониторинга загрузки ядер процессора, наглядно показывающий ее в играх, есть, например, в виндовой программе MSI Afterburner. На экран поверх картинки игры выводится текущая загрузка ядер процессора. Увы, под Линукс я программы с таким функционалом не нашел. Есть, конечно, GLXOSD, но она не умеет выводить именно этот параметр. ФПС, время кадра, температуры, загрузка видеокарты, но не загрузка процессора. Да и автор прекратил поддержку GLXOSD в 2017 году, в связи с нехваткой времени и скорым пришествием Wayland'а.
Устанавливается GLXOSD следующим образом (для 64-битной Ubuntu 14.04 и более новых):
sudo apt-add-repository -y ppa:nickguletskii200/glxosd
sudo apt-get update
sudo apt-get install -y glxosd glxosd-libs-amd64 glxosd-libs-i386:i386
Запускается утилита вместе с приложением, поверх второго надо вывести данные. Например, вот команда для линуксового теста с шестеренками glxgears: glxosd glxgears
. Для стимовских игр в параметрах запуска прописывается команда glxosd --steam %command%
. Включить или выключить вывод утилиты можно сочетанием клавиш Shift+F10. Выглядит в работе она так (цвет, размер шрифта, выводимые значения и другие нюансы настраиваются в конфиг-файле):
Киллер-фичей GLXOSD, на мой дилетантский взгляд, является возможность вывода данных в лог-файл для последующего анализа. В игрушках, где нет встроенного бенчмарка или где его итоговые результаты малоинформативны, это может оказаться очень полезно. В контексте моих процессорных ковыряний, среди выдаваемых показателей GLXOSD вызывают интерес фпс и время кадра, но, с учетом того, что я не сравниваю между собой разные железки, а просто смотрю на отличия в производительности между разогнанным и неразогнанным состоянием одной и той же системы, анализ этих данных показался мне не особо и нужным. Да лень было разбираться: кроме ковыряния в настройках, пришлось бы еще как-то решить проблему с игровыми лаунчерами, из-за запуска которых перед игрой GLXOSD не работает с некоторыми играми. Возни много при сомнительной пользе.
Единственный же найденный мной способ для отслеживания загрузки ядер процессора в полноэкранных приложениях - системный монитор MATE. В других графических средах есть похожие программы, которые, возможно, тоже подойдут, но это не точно. У меня под рукой только две среды - MATE и LXDE, и во второй системный монитор не показывает нагрузку по ядрам. MATE-монитор имеет похожий на htop функционал, но умеет показывать график нагрузки на ядра за определенное время и, после сворачивания или закрытия полноэкранного приложения, по этим графикам можно наблюдать "долбление в соточку" и прочие нюансы работы. Выглядит так (после окончания трехпоточного теста процессора):
В принципе, описанного выше инструментария хватает для наблюдения за системными параметрами, связанными с разгоном процессора. Но хотелки мои по наблюдению за его работой реализовать удалось не в полном объеме. Не нашлось, увы, способа мониторинга частоты работы контроллера памяти. Для Фенома это не критично, насколько я знаю, а вот для FX'ов это параметр важный, т.к. не все материнки выставляют их контроллеру памяти ту частоту, которая указана в биосе, и возможность ее мониторить в ОС нужна. Еще одна не решенная проблема - измерение температуры VRM. На своей материнке я не нашел датчика, показания которого коррелировали бы с реальной его температурой. Пришлось задействовать хардварный метод мониторинга - мультиметр с термопарой.
Память
Перед разгоном памяти хотелось бы узнать о ней побольше, для чего хорошо бы залезть в SPD. Увы, аналога CPU-Z под Линуксом нет, так что путь будет чуть более долгим. Данные о памяти хранятся в специальной микросхеме на ней - EEPROM. Доступ же к этой микросхеме осуществляется по шине I2C. А такое Линукс уже могет. Для начала, нужно установить из репозиториев пакет i2c-tools. Затем нужно загрузить в ядро модуль работы с EEPROM. Делается это такой командой: sudo modprobe eeprom
Теперь данные можно считать командой-декодировщиком: decode-dimms
Вывод выглядит так (для одной планки памяти):
Тип памяти, частота, тайминги, напряжение - все необходимое есть, пусть и не в самом удобном виде. Частоту 1600 МГц и тайминги 10-10-10-30 можно считать параметрами по умолчанию и от них уже отталкиваться при разгоне. Действующее напряжение на памяти есть в утилите sensors, а загрузка памяти показывается утилитой htop или системным монитором MATE. Это ПО уже описано в процессорном разделе, повторяться не буду. Наверно, какой-то толк был бы от показаний текущей частоты и таймингов памяти, кроме их SPD'шных значений, но это есть в биос, в реальном времени же наблюдать смысла нет - я не стал заморачиваться поиском этой инфы. Таким образом, все хотелки по мониторингу памяти реализовать получилось.
Итоги
После долгого ковыряния в сети, я все-таки получил достаточный набор инструментов для мониторинга необходимых при разгоне параметров системы. Вот так выглядит мой экран при стресс-тестировании процессора в Prime95:
Слева сверху - psensor с графиком температуры процессора. Справа сверху - утилита sensors для мониторинга напряжений, справа снизу - окно с запущенным prime95, слева снизу - загрузка процессора в htop. Мультиметр с температурой VRM остался за кадром. Та же самая картина для любых консольных тестов процессора или памяти. При полноэкранных тестах, вместо htop я запускаю монитор MATE, чтобы по окончании можно было посмотреть на график загрузки процессора.
На этом первую часть я заканчиваю. Возможно, получилось поверхностно, но такова и была цель: подобрать для себя простой набор инструментов для мониторинга всякого полезного при разгоне процессора и памяти. Для профессионального тестирования железа, этого, конечно, мало, однако домашним пользователям и описанного должно хватить. А в следующей части будет рассказ о тестах, с помощью которых я проверял стабильность и изменение скорости работы системы при разгоне.
Теги
Лента материалов
Соблюдение Правил конференции строго обязательно!
Флуд, флейм и оффтоп преследуются по всей строгости закона!
Комментарии, содержащие оскорбления, нецензурные выражения (в т.ч. замаскированный мат), экстремистские высказывания, рекламу и спам, удаляются независимо от содержимого, а к их авторам могут применяться меры вплоть до запрета написания комментариев и, в случае написания комментария через социальные сети, жалобы в администрацию данной сети.
Комментарии Правила