Ядро или память: что крутить в разгоне под разные алгоритмы
Разгон — это не «добавить везде по максимуму». Одним алгоритмам нужна быстрая память и почти не нужно ядро, другим — наоборот. Крутить не ту ручку означает жечь ватты впустую: хешрейт не растёт, а счёт за свет растёт. Разбираем, как понять, что важно вашему алгоритму.
Коротко (для тех, кто без чтения)
- Алгоритмы делятся на два типа: одни упираются в память (memory-bound), другие — в ядро (core-bound). Пресет под один тип почти всегда плох для другого.
- Memory-bound: крутите память вверх, ядро можно заметно снижать — хешрейт не упадёт, а ватты и градусы уйдут.
- Core-bound: память на умеренных значениях, хешрейт решает частота ядра — но растить её надо вместе с контролем ватт.
- Лишние ватты не в том месте — чистый убыток: 30 Вт впустую на карту — это больше 800 ₽ в месяц с восьмикартного рига просто так.
- При смене монеты пресет меняется тоже. «Вечный разгон» существует только до смены алгоритма.
Два типа алгоритмов
Memory-bound (упор в память). Алгоритм постоянно гоняет данные через видеопамять: ядро большую часть времени ждёт, пока память ответит. Хешрейт почти линейно зависит от частоты памяти и почти не зависит от частоты ядра. Классические примеры — алгоритмы семейства Ethash/Etchash.
Core-bound (упор в ядро). Алгоритм считает на самом чипе, а память нужна умеренно. Хешрейт растёт с частотой ядра, а перегретая память только добавляет ватт и градусов. Сюда относятся, например, Autolykos, kHeavyHash и большинство «процессорных по духу» алгоритмов.
Бывают и промежуточные случаи, где важно и то, и другое — но почти всегда одна из ручек даёт больше. Понять тип своей монеты можно по простому признаку: посмотрите, на каких частотах ядра майнят её владельцы таких же карт. Если у всех ядро занижено, а память поднята — это memory-bound, и наоборот.
Что крутить в каждом случае
Для memory-bound: память — вверх мелкими шагами до границы стабильности, ядро — вниз. Снижение ядра на 200–300 МГц от стока часто вообще не трогает хешрейт, зато снимает десятки ватт и несколько градусов. Лимит мощности после этого можно опустить ещё — карта перестанет упираться в него (про упор в лимит и троттлинг — отдельная статья).
Для core-bound: память держите умеренной — лишний разгон памяти здесь не даёт хешрейта, но греет чипы памяти (особенно GDDR6X, см. про горячую память). Растите ядро, пока растёт хешрейт и не появляются ошибки, и следите за ваттами: после некоторой точки каждый следующий мегагерц стоит всё дороже.
Общее правило для обоих типов: меняйте одну ручку за раз и проверяйте результат длительным прогоном, а не пятиминуткой. Хешрейт «в моменте» врёт — о чём подробно в статье про плавающий хешрейт.
Экономика: ватты не в том месте — это счёт за свет
Типичная ошибка на memory-bound алгоритме — ядро на стоковых частотах. Это 25–40 Вт лишнего тепла на карту, не дающие ни одного хеша. Считаем по тарифу 4,92 ₽/кВт·ч: 30 Вт × 24 часа = 0,72 кВт·ч в сутки ≈ 3,5 ₽ в день ≈ 106 ₽ в месяц с карты. Восьмикартный риг — около 850 ₽ в месяц, потраченных просто на обогрев комнаты.
Обратная ошибка на core-bound — перегретая память. Там цена не только в ваттах: чипы памяти живут на пределе, вентиляторы крутятся быстрее, износ выше. Правильный пресет под конкретный алгоритм почти всегда и холоднее, и тише, и дешевле «универсального» — а по хешрейту ещё и стабильнее.
Если майните несколько монет попеременно, пресетов должно быть несколько — по одному под каждый алгоритм. Переключение между ними дешевле, чем компромисс, который плох для всех сразу (мы разбирали это в статье про режимы).
Куда тут автоматика
Определить тип алгоритма и найти рабочую точку под него — это ровно то, что делает OCBot вместо ручного подбора: перебирает сочетания частот ядра и памяти под конкретную монету, отбрасывает нестабильные и оставляет вариант с лучшим хешрейтом на ватт. При смене алгоритма — новый подбор, а не старый пресет «на авось».
Статья — общая информация и пересказ общедоступной практики; конкретные частоты и пределы зависят от модели вашей карты и алгоритма. OCBot — независимый проект: не связан с NVIDIA и HiveOS/Hiveon. Использование — на ваш риск: отказ от ответственности.