Одной лишь настройкой лимитов далеко не всегда выйдет раскачать 9950X.
Да и загонять PPT/TDC/EDC до максимума - особого смысла нету.
Напишу достаточно поверхностно, как я делаю :
Я настраиваю PBO-Лимиты используя SSE-Многопоточную нагрузку (т.е не AVX, как некоторые предпочитают). Я просто не использую софт с таким уровнем нагрузок как в Prime95 SmallestFFT/OCCT-AVX/LinX, Linpack и тд... Мне лично достаточно CineBench R23 + понимания что Corona Render в момент HQ-Денойзера может вжарить процессор больше чем сам рендер. Потому это держу в голове и делаю отступы в финальных настройках.
Первым делом отключаю iGPU, так как интеграшка делает вклад в общий PPT лимит. И мне она не нужна. Собственно и SoC вольтаж тоже делает вклад в PPT. Так что тут можно ~20вт отыграть у медленной памяти в ~1.0-1.05V SoC относительно разогнанной в 1.30V SoC. Так что на этом этапе я уже слежу за вольтажами VDDG/VDDP/SoC/VDDIO что бы не было лишнего напряжения.
Так же я выставляю частоту VRM в максимум (да я в курсе что есть некоторые платы которые только хуже начинают от этого работать). Но мне везло с этим и все предыдущие платы за 10+ лет только повышали стабильность подачи питания на высоких значениях частоты VRM. Проверяю режим LLC, не сильно ли он упорот (подбираю средний режим, так как за компом и играю и рендрю). Если комп чисто для рендера и работы, в теории можно линейный жесткий LLC подобрать. Разница конечно небольшая с этими двумя манипуляциями, тем не менее. В лучшем случае выйдет отыграть там условные 0.02V на грани стабильности. Сколько это будет, наверное 4-5 вт ? Ну плюс из за высокой частоты VRM, сам питальник начнет греться больше, а процессор чуть чуть меньше.
И только на этом этапе начинаю подгонять PPT/TDC/EDC.
Первым делом ставлю PPT на сколько вт я хочу что бы шпарил проц в рендере (примерно). Оптимально для макс производительности 9950X это чаще - 230вт. На 250-260вт может будет буквально на 75-100мгц больше работать. Но это может вполне добавить вам 8-10 градусов нагрева. И уже в Сайнбенче смотрю насколько TDC/EDC в процентах загружены (через HWInfo64). И уже их подгоняю таким образом что бы в полной нагрузке они были не менее чем на 95% заняты. Делаю это что бы во время Короновского Денойза (или внезапных AVX нагрузок, компиляции шейдеров в играх) процессор все таки упирался в TDC чуть чуть буквально и притормаживался. А в легких резких нагрузках что бы проц не сильно упарывался и упирался в EDC.
И вот после всего этого, проц все равно может упереться в 5.0-5.1Ггц а дело в том что нужно еще настроить Curve Optimizer. И тут есть три пути. Тупой-Простой и неэффективный (общий оффсет на все ядра). Оптимальный и самый распространенный (оффсет на отдельные чиплеты). Душный и рискованный (оффсет на каждое отдельное ядро).
Соответственно, в первом варианте у вас 1 крутилка, жмете вольтаж пока проц перестанет стабильным быть, и потом делаете отступ обратно на 2-3 шажка что бы зазор был для стабильности. В втором варианте у вас 2 крутилки, и надо отдельно первый и второй чиплет тестить и потом еще оба вместе тестить на подобранных значениях. Ну а с третьим вариантом... Да, тестить все ядра по отдельности, потом все вместе на подобранных значениях. Делать руками это можно занять несколько дней, в лучшем случае. Но для этого есть софтина CoreCycler, разбирайтесь с ней сами, не буду 10км текста писать по ней. Конечно есть еще "Hydra от 1usmus", но там нужно шарить или читать 100 страниц мануала по 3 раза. Потому что без понимания - можно только хуже сделать.
В любом случае настраивая многоядерные процы, есть смысл делать поядерный тесты, как минимум для того что бы убедиться нету ли 'паршивой овцы'. Т.е отдельно нестабильного ядра которое требует больше напряжения для стабильной работы. А то выйдет так что у вас например 14 ядер норм работают на -30/-35 CO а два ядра неудачные уже на -20/-25 валяться. Соответственно если их вычислить, то им отдельно можно задать оффсет. Тогда и все остальные - задышат.
Вот на этом моменте в целом можно остановиться. А если вдруг захочется получить лучше результаты в однопотоке и смешанных нагрузках. То придется еще крутить Curve Shaper. Тоже душная штука в которую вникать нужно.
И да, конечно же - Стягивать чужие настройки PBO - смыслу нету. Только если у вас прям одинаковая плата/проц/охлаждение и задачи которые проц выполняет.
И разумеется, посматривать во время всего этого на ЭФФЕКТИВНЫЕ частоты а не на обычный лимит частоты. Т.е смотреть что бы не было Clock Stretching-а. Когда вам диспетчер задач начнет показывать 5.4ггц а на самом деле проц рендрит на 5.1Ггц. Этот датчик есть в HWInfo64, отдельно. И разумеется нужно делать контрольные и промежуточные замеры в Короне/Сайнбенче. Райзены так устроены что если ты его до грани дожмешь - он может остаться стабильным в рендере, но не прибавить при этом в производительности а наоборот потерять. Тут нужно вот нащупать оптимальный промежуток.
Ну еще, нужно понимать что чем легче сцена/ниже разрешение в Короне тем лучше утилизация конвейера команд, процу легче дышать. И соответственно - он достигает лимитов быстрее и греется сильнее. А если это огроменный экстерьер в высоком разрешении - то он может и на 15 градусов меньше греться. Тут нужно не забывать что диспетчер задач показывает не то насколько нагружен процессор а то насколько процентов он ЗАНЯТ. Вот в эти проценты входят все затупы/промахи по кэшу/подгрузки с памяти и тд и тп... В целом CineBench R23 и та тестовая сцена с интерьерам - очень близки друг к другу (в плане нагрузки). Так что CBR23 можно гонять для быстрого до-минутного теста. А Корону на 10 минут уже гонять на каких то ключевых этапах. И не использовать для настройки огроменные сцены или высокое разрешение. И не забывать про Corona HQ Денойзер и то как он фигачит по процу. А то будет у вас комп вроде стабильно рендрить часами а на Денойзере отлетать в синий экран или зависать.
Удовлетворил свою потребность в графомании, пошел игры играть, пиво утреннее пить 🙃
