Разгон процессора и новый governor

Для разгона процессора нам нужно сначала установить CLI (точка - это путь, так что это часть команды, а не опечатка)

sudo pacman -S --needed stress git python python-pipx
pipx ensurepath
git clone https://github.com/bc250-collective/bc250_smu_oc.git
cd bc250_smu_oc
pipx install .

Проверяем

bc250-detect --help

1) Подготовь мониторинг

Если sensors у тебя еще не настроен, для BC250 в документации рекомендуют модуль nct6683 с force=true, чтобы видеть материнские датчики. Также для CPU-клоков сам README проекта советует смотреть эффективные частоты через /proc/cpuinfo. Для BC250 целевой температурный диапазон под нагрузкой — в идеале до 85°C, а 85–90°C уже зона осторожности.

В одном терминале:

watch -n 1 'sensors; echo; grep "cpu MHz" /proc/cpuinfo'

Если sensors не показывает нужные датчики:

sudo modprobe nct6683 force=true

И, если хочешь заодно видеть поведение GPU/governor:

watch -n 1 'cat /sys/class/drm/card1/device/pp_dpm_sclk; echo; cat /sys/class/drm/card1/device/gpu_busy_percent'

2) Сделай безопасный базовый прогон

У проекта есть официальный пример для чистого undervolt без роста частоты: 3500 MHz @ 1000 mV. Это хороший первый прогон, чтобы убедиться, что все в целом стабильно.

bc250-detect --frequency 3500 --vid 1000 --temp 90 -c ~/uv-3500.conf

Что он делает по факту: выставляет температурные лимиты CPU/GPU, поднимает частоту шагами по 100 MHz, на каждом шаге запускает stress, проверяет напряжение и прекращает подбор, если видит троттлинг.

3) Потом иди к нужной частоте

В README есть официальный пример для разгона: 4000 MHz @ 1275 mV. Если при таком запуске система падает, автор советует повторить с 1300 mV, а если и это не помогает — снижать целевую частоту. Параллельно общая BC250-документация советует повышать частоту шагами 50–100 MHz и тестировать каждую ступень.

Пример:

bc250-detect --frequency 4000 --vid 1275 --temp 90 --keep -c ~/oc-4000.conf

Если нестабильно:

bc250-detect --frequency 4000 --vid 1300 --temp 90 --keep -c ~/oc-4000.conf

Если хочешь идти аккуратнее, делай несколько проходов с ростом частоты по 100 MHz, а напряжение поднимай только когда это реально нужно.

4) После удачного подбора — длинный тест

bc250-detect удобен для первичного подбора, но сам проект отдельно пишет, что потом нужен более тщательный stability testing. В BC250-документации рекомендуют держать тест 30+ минут на ступень и смотреть, чтобы температура была желательно ниже 85°C. В самом README из синтетики отдельно упомянуты Prime95 и OCCT, а Furmark предлагается использовать скорее для питания и охлаждения, а не как проверку CPU-стабильности.

Простой длинный CPU-прогон:

stress --cpu 12 --timeout 1800s

Во время него смотри:

нет ли зависаний/ребутов,
держатся ли cpu MHz близко к цели,
не уезжают ли температуры в 90+,
не начинается ли явный троттлинг.

5) Что считать нормой, а что признаком проблемы

Если система падает сразу, BC250-документация трактует это как слишком низкое напряжение для выбранной частоты: обычно помогает +25–50 mV или уменьшение частоты на 50–100 MHz. Если падает через 10–30 минут, это уже похоже на пограничную стабильность или перегрев.

Нормальный результат:

нет крашей,
частоты не проседают сильно ниже цели под CPU-нагрузкой,
температура в основном держится до ~85°C,
после bc250-detect у тебя появился конфиг, который можно применять повторно.

6) Когда нашел стабильный вариант

Проект предлагает потом установить найденный конфиг как сервис:

bc250-apply --install ~/oc-4000.conf
sudo systemctl enable bc250-smu-oc

Это соответствует описанию из README: сначала подобрать через bc250-detect, потом применить через bc250-apply --install.

И еще важный нюанс BC250: CPU и GPU сидят на одном кристалле и делят общий тепловой бюджет, поэтому GPU-нагрузка уменьшает термозапас CPU. Если твой реальный сценарий — игры, то после чистого CPU-стресса обязательно проверь еще и реальную игровую нагрузку.

Далее устанавливаем новый governor, а старый отключаем

paru -S cyan-skillfish-governor-smu
sudo cyan-skillfish-governor-smu
sudo systemctl stop  oberon-governor.service
sudo systemctl disable  oberon-governor.service
sudo systemctl start cyan-skillfish-governor-smu.service
sudo systemctl enable cyan-skillfish-governor-smu.service

Данные из ChatGPT

Я уже нашёл главное: у проекта есть два режима — временное применение параметров и постоянная установка через systemd. От этого и зависит, где искать «текущий конфиг».

bc250_smu_oc — это небольшой Python-проект для платы AMD/ASRock BC-250, который меняет параметры CPU через сообщения в SMU (System Management Unit). По сути он нужен для разгона и андервольта BC-250, причём авторы отдельно предупреждают, что без снижения напряжения разгон может убить плату. Репозиторий ориентирован на Linux и использует systemd для постоянного применения настроек при старте.

У проекта два основных сценария работы. bc250-detect подбирает и проверяет параметры, принимает целевую частоту и лимит напряжения, а по умолчанию сохраняет результат в файл overclock.conf. Ключ --keep оставляет найденные настройки применёнными после завершения проверки. bc250-apply либо просто применяет готовый конфиг из указанного файла, либо ставит его как сервис автозапуска.

Теперь главное по твоему вопросу. Если конфиг установлен “по-правильному” через bc250-apply --install, то постоянная копия хранится здесь: /etc/bc250-smu-oc.conf. Сам systemd-юнит создаётся здесь: /etc/systemd/system/bc250-smu-oc.service, и в ExecStart он запускает bc250_apply.py --apply /etc/bc250-smu-oc.conf. Это прямо зашито в коде проекта.

Если же ты не ставил сервис, а просто запускал bc250-detect или bc250-apply вручную, то постоянного “системного” места хранения может не быть. В этом случае файл обычно лежит как локальный overclock.conf в текущем каталоге, либо в том пути, который ты сам передал через -c для bc250-detect или как path для bc250-apply.

И важный нюанс: “применённый сейчас конфиг” сам проект не ведёт в отдельной базе или runtime-файле. При применении он читает конфиг, затем пишет значения прямо в SMU: лимит температуры CPU/GPU, масштабирование F/V-кривой и максимальный boost clock. То есть текущие активные параметры фактически находятся уже в состоянии SMU, а не в каком-то отдельном “current.conf”. Файл на диске — это источник, из которого настройки были взяты.

Практически смотреть так:

cat /etc/bc250-smu-oc.conf
systemctl cat bc250-smu-oc

Если этих файлов нет, проверь каталог, из которого запускал bc250-detect, на наличие overclock.conf.

Если хочешь, дальше могу сразу разобрать формат bc250-smu-oc.conf и пояснить, что означает scale, потому что в конфиге хранится не vid в милливольтах, а именно frequency, scale и max_temperature.