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
