Team Red Miner Kawpow Mining
============================
This document provides some pointers on how to best test and tune for
the Kawpow algo used by Ravencoin.
General background
------------------
Kawpow (progpow) is designed to fully utilize the resources on a gpu:
compute, local memory and global memory. This means the algorithm
falls into the most resource-intensive category of pow algorithms to
date. In turn, this leads to a high power draw and hot gpus.
The algorithm also contains random elements that vary with each block
height. The load on the gpu will therefore vary accordingly. The
hashrate difference between lean and mean blocks with easy vs heavy
random math operations can vary as much as +-10%. Therefore, tuning
for the algo without locking down your tests to a specific block
height means you'll get random results over time. This is very
important, and the miner therefore provides a mechanism for doing so.
DISCLAIMER: please note that this algo runs MUCH HOTTER than
e.g. ethash. You should be prepared to lower your clocks significantly
to avoid overheating your gpus.
Tuning Clocks
-------------
The most important controls are (as usual) the core and memory clock
of your gpu. This miner does not set clocks; you need to control them
using your mining os or an external tool like OverdriveNTool on Windows.
The goal is to find a balance between the core and memory clock so
that your gpu temperatures are under control and neither core or mem
is a clear bottleneck. We choose to do so on a specific block height
that we know represent an average load on the gpu. Then, we make sure
our tuning runs fine on two other example heights that are lean and
mean, respectively. If the rig can run for a sustained test period on
the mean block height, the configuration should hopefully survive the
hardest heights during regular mining.
Tuning Intensity and Kernel Mode
--------------------------------
This miner very aggressively consumes a gpu's resources to achieve the
highest possible hashrate. In some cases, you need to control the
"intensity" used to allow for e.g. rendering tasks to execute in
parallel with mining.
Unless you specify the intensity manually, the miner will select an
intensity that is 16 below the max (see below for max values). Most of
the time a higher intensity results in a higher hashrate, but can
cause problems with responsiveness on GPUs used for monitors.
For Vegas and Navi cards, the miner also provides two different mining
modes: A and B mode. Due to choices made by the AMD driver teams, the
B mode is not available for Vegas on Windows or older amdgpu-pro
drivers (<= 18.50 or so). For Navi cards, both modes are available on
all platforms. Unless specified, the miner will choose what should be
the optimal mode for each gpu automatically. The B mode is the obvious
choice whenever you can run it, it is faster. However, for gpus
running a monitor, the A mode is sometimes the better choice.
The maximum intensity a gpu can run is 16 x ComputeUnits. This means:
GPU 470/570 480/580 Vega56 Vega64 VII 5700xt 5700/5600xt
Max 512 576 896 1024 960 640 576
The miner will automatically cap a higher configured value than the
max intensity for a gpu.
The kernel mode and intensity are specified together using the
--prog_config command line parameter. Please see the USAGE.txt file or
run the miner with --help to see examples of how to use the parameter.
Tuning for monitor gpus
-----------------------
As mentioned, monitor gpus need to be limited manually with a lower
intensity to provide access to the gpu for rendering tasks, or your
system might become overly sluggish and unresponsive.
Typically, take the max intensity possible for your gpu, reduce it
with 64 and pass it in a --prog_config argument. If the system still
feels sluggish, decrease the value further in steps of 8 until you're
satisfied. You can also try increasing it if the system feels
responsive enough. For Vegas and Navi cards, you can also try to
switch between the A and B modes to see what effect it has on your
system.
Example for a three gpu system of Vega 64s, the first running a
monitor, choosing the A node for the monitor gpu:
--prog_config=A960,B1024,B1024
Tuning Workflow
---------------
This is an example workflow that can be used to tune a rig for kawpow
mining:
- We have selected three block heights representing lean, average, and
mean random math selections:
Lean: 937863
Average: 1234567
Mean: 1006647
- Create a script or command line for running the miner against any
pool of your choice but also adding the argument
--prog_height=1234567. This means the miner will simulate mining on
our average random math height and also not submit any shares to the
pool. Using the example script provided with TRM
(start_kawpow.sh/bat), mining on Linux, only on device 0 and
hashrate log time shortened to 15 secs, it would look as follows:
./teamredminer -a kawpow -o stratum+tcp://us.rvn.minermore.com:4501 \
-u RDpPHx43bhrmdyd8L6BcpkHtjuc1vMpNSk.trmtest -p x \
-d 0 -l 15 --prog_height=1234567
- Crank up your fans as much as possible to keep temps in check
throughout the tuning process.
- Start tuning by tweaking your clocks, always rerunning the same
script with the average block height 1234567. You can use the clock
examples below as your starting point, or any other clocks of your
choice. Use a low-ish voltage for your clocks but rather a little
above what you're hoping to achieve as the final configuration.
- Running the script over and over again, or using live clock
adjustments, observe how changes to higher/lower core clk and
higher/lower mem clk affects the hashrate. Unless they are balanced
fairly well, changes to one of core/mem clk will have a more
significant impact on the hashrate than the other. Lower that clock
until you reach the point where lowering either of the two clocks
affects the hashrate slightly.
- Modify your script or command line to use our mean block height,
1067241, instead of 1234567.
- Run the script repeatedly again, and try to lower voltage as much as
possible while still being able to mine continuously for a while on
the mean block height.
- Lower your fans to a more comfortable level. Run mining on the mean
block height again and verify that gpu temps are still under control.
- If you feel you ended up with a too low/high core clock, or your
temps are not under control, restart the process from tuning your
clocks with a different core clock as starting point, and find the
correct mem clock for a balanced core/mem clock configuration.
- Last, run the lean mining level as a final test, modifying your
script to run block height 937863. It should give you the highest
hashrate seen so far, and hopefully have no issues running.
Memory Timings
--------------
Timings do not have the same significant impact on kawpow as on
e.g. ethash or CN variants. There might be findings in the future that
can be worth mentioning, for now we skip the subject in this guide.
Clocks and hashrates examples
-----------------------------
These clocks are reported by TRM testers and can be used as a starting
point for your own tuning. They have not been tested at controlled
heights, so your results may vary from the specified hashrates below.
Type CoreClk MemClk mV prog_config Hashrate
------- -------- -------- ------ ------------- ---------
5700XT 1310 MHz 1800 MHz 750 mV B608 23.0 MH/s
5700 1310 MHz 1800 MHz 775 mV A400 (monitor) 19.7 MH/s
5600XT 1310 MHz 1800 MHz 750 mV B608 20.0 MH/s
Vega 64 1045 MHz 925 MHz 800 mV B1024 25.0 MH/s
Vega 56 Hynix 957 MHz 940 MHz 812 mV B896 24.4 MH/s
RX580 8GB 1175 MHz 2100 MHz 820 mV A576 15.0 MH/s
RX480 4GB 1100 MHz 2000 MHz 850 mV A400 14.3 MH/s
