Skip to content

Commit

Permalink
v0.8.6 release.
Browse files Browse the repository at this point in the history
  • Loading branch information
@Kerney666
Kerney666 committed Oct 6, 2021
1 parent 025042a commit 14d91e5
Show file tree
Hide file tree
Showing 3 changed files with 139 additions and 47 deletions.
16 changes: 15 additions & 1 deletion README.md
View file
Original file line number Diff line number Diff line change
@@ -1,8 +1,10 @@
# teamredminer v0.8.5
# teamredminer v0.8.6
This is an optimized miner for AMD GPUs created by todxx and kerney666.

**Download is available in the [github releases section](https://github.com/todxx/teamredminer/releases).**

TRM official website: https://www.teamredminer.com

TRM discord server: https://discord.gg/RGykKqB

Below is a list of mining operating systems and management software that have built-in support for teamredminer:
Expand Down Expand Up @@ -68,6 +70,7 @@ Some algorithms are not supported on some GPU architectures and/or drivers. Bel
| Kawpow | Y | Y | Y | Y | Y |
| Verthash | Y | Y | Y | Y | N |
| Autolykos2 | Y | Y | Y | Y | N |
| Firopow | Y | Y | Y | Y | Y |
| Nimiq | Y | Y | Y | Y | N |
| Cryptonight R | N | L | L | L | N |
| Cryptonight v8 upx2 | N | L | L | L | N |
Expand Down Expand Up @@ -110,6 +113,17 @@ For example command lines please see the batch/shell scripts in the miner downlo
For command line options see the [USAGE.txt](USAGE.txt) file that comes with the miner.

-----------
Changes in v0.8.6

Release notes:
- Firopow: new algo added for Firo's upcoming fork (see start_firo.sh/bat). Only testnet mining is available before the fork, see start_firo_testnet.sh/bat.
- Firopow/kawpow: rewrote tuning guide (see KAWPOW_FIROPOW_TUNING.txt).
- Firopow/kawpow: slight hashrate improvements, mainly from choosing full gpu tuning by default and adding a micro-tuning mechanism for Polaris gpus (see new argument --prog_micro_tune).
- Autolykos2: added high score support and display of submitted share difficulty.
- General: fixed Radeon VII support on recent win drivers. NOTE: HBCC must be DISABLED for all Vegas.
- General: fixed broken fan control for Navis on some driver versions.
- General: improved Windows compute mode enable with automatic elevation (with --uac) and restart of gpus.

Changes in v0.8.5

Release notes:
Expand Down
15 changes: 13 additions & 2 deletions USAGE.txt
View file
Original file line number Diff line number Diff line change
@@ -1,10 +1,11 @@
Team Red Miner version 0.8.5
Team Red Miner version 0.8.6
Usage: teamredminer [OPTIONS]
Options:
-a, --algo=ALGORITHM Selects the mining algorithm. Currently available:
ethash (eth, etp, others)
etchash (etc, alias for -a ethash --eth_variant_mode=etchash)
kawpow (ravencoin)
firopow (firo)
autolykos2 (ergo)
verthash (vtc)
nimiq (nimiq)
Expand Down Expand Up @@ -380,7 +381,7 @@ Ethash options:
issue is hard hangs where the rig becomes unresponsive requiring a power cycle to reboot, but it can also
be regular gpu crashes. Valid values are 1-128. Not using this argument means no delay, value zero.

Progpow options:
Progpow options (kawpow, firopow):
--prog_config=CONFIG Manual progpow configuration for the miner. CONFIG must be in the form [M][L].
The [M] value selects the mode which can be either 'A' or 'B'.
The 'B' mode typically results in better performance but is only available for
Expand All @@ -403,6 +404,16 @@ Progpow options:
--prog_ramp_up See --eth_ramp_up.
--prog_no_stagger See --eth_no_stagger.
--prog_no_ramp_up See --eth_no_ramp_up.
--prog_micro_tune=X,Y,... This option enables a small retuning session for every new random code block. This is important
for Polaris gpus to run at their max speed. For Vegas and Navis it usually does not improve
performance. The default AUTO mode enables it for all Polaris gpus but disables it otherwise.
The only reason to disable it would be for stability purposes. The argument value is a
comma-separated list of values, one per gpu. If a gpu is missing a value, the value for the
first gpu is used. Please note that setting a manual prog_config will effectively disable the
micro-tuner as well. Available values are:
0 - turn OFF progpow micro-tuning for this gpu.
1 - turn ON progpow micro-tuning for this gpu.
2 - let the miner decide if micro-tuning should be enabled (AUTO).

Cryptonight options:
--rig_id Set the rig identifier that will be sent to the pool. This is only used for
Expand Down
155 changes: 111 additions & 44 deletions doc/KAWPOW_TUNING.txt → doc/KAWPOW_FIROPOW_TUNING.txt
View file
Original file line number Diff line number Diff line change
@@ -1,55 +1,106 @@
Team Red Miner Kawpow Mining
============================
Team Red Miner Kawpow/Firopow Mining
====================================
This document provides some pointers on how to best test and tune for
the Kawpow algo used by Ravencoin.
the progpow family of algos in TRM: the Kawpow algo used by Ravencoin
and Firopow used by Firo.


Versions
--------
2021-09-30 v1.1 Rewritten when Firopow was added.
2020-05-26 v1.0 Kawpow guide.


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
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 changes frequently
with new network block heights. The compute 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%, this much depending on your core clock. 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.
to avoid overheating your gpus unless you have a good cooling setup.


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.
of your gpu. This miner can set clocks and voltages for you on Windows
from TRM 0.8.5. For linux you need to use a mining distro, tools or
direct overdrive sysfs api writes.

Progpow as configured by both Kawpow and Firopow consumes twice the
amount of memory bandwidth as ethash. Therefore, you will not see a
higher bandwidth than roughly half the ethash hashrate on a specific
gpu, at least not if it's tuned well for ethash. Progpow does run an
easier access pattern than ethash, so untuned cards can see an
increase from the expected 0.5x ethash hashrate. It's important to
note that this is an _upper bound_ for your progpow
hashrate. Depending on your configured core clock many block heights
might run at a lower effective hashrate.

In order to reach the point where memory bandwidth becomes the
bottleneck, progpow needs much more compute resources compared to
ethash. Given the random compute element in progpow, the amount of
compute resources required will also vary wildly between network block
heights. If your core clock is relatively low, you will only see the
max hashrate produced for the easiest / most lean block heights. For
heavier block heights the gpu will not be able to produce enough
pressure on the memory controller to sustain the maximum possible
memory bandwidth and your effective hashrate will be lower. If you run
a high core clock, you will reach the max possible hashrate on many
more block heights, but also pull a lot more power overall. Therefore,
the goal is to find a balance between the core and memory clock so
that your gpu temperatures are under control and your power draw is
acceptable.

For very lean block heights, how much memory bandwidth the gpu can
produce will be the bottleneck unless your core clock is very low. A
higher mem clock will most probably produce a higher hashrate for such
heights. Hence, checking the max possible progpow hashrate for a gpu
is best done at such heights.

For mean block heights with a high compute load, you will have to
decide for yourself what core clock you're willing to expend power
for. With a high core clk the gpu will pull more power for all block
heights, the lean ones as well. At the end of the day, you will end up
with a configuration that hits the max hashrate on X% of all block
heights, then loses some hashrate on the rest, but the overall
performance, power draw and gpu temperatures are acceptable to you.

When testing a final configuration, it's good to verify that it runs
ok for a while on all three types of block heights: lean, average and
mean.

A last note for Polaris gpus: TRM 0.8.6 added a micro-tuner for
progpow algos that retunes the intensity for each new random code
block height. This is necessary to hit the max possible hashrate on
all block heights where the core clock is high enough. Without this
step (i.e. using a static intensity), Polaris gpus will not maximize
their potential.


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.
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.
Unless you specify the intensity manually, the miner will select the
max intensity possible for the gpu. 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
Expand All @@ -72,6 +123,11 @@ 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.

NOTE: as mentioned earlier, TRM 0.8.6 introduced a micro-tuning
concept for Polaris gpus (see the --prog_micro_tune argument). If you
specify a manual intensity for a Polaris gpu, this mechanism is
disabled.


Tuning for monitor gpus
-----------------------
Expand All @@ -96,22 +152,26 @@ monitor, choosing the A node for the monitor gpu:
Tuning Workflow
---------------
This is an example workflow that can be used to tune a rig for kawpow
mining:
or firopow mining. It aims to find a balance where roughly 50% of the
block heights will run at max hashrate, the rest with a penalty
depending on how much additional compute resources they each require.

- We have selected three block heights representing lean, average, and
mean random math selections:

Lean: 937863
Average: 1234567
Mean: 1006647
Kawpow Firopow
Lean: 937863 312621
Average: 1234567 411522
Mean: 1006647 335549

- 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:
--prog_height=1234567 (or 411522 for firopow). 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 \
Expand All @@ -135,7 +195,7 @@ mining:
affects the hashrate slightly.

- Modify your script or command line to use our mean block height,
1067241, instead of 1234567.
1006647 (335549 for firopow), 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
Expand All @@ -150,8 +210,9 @@ mining:
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.
script to run block height 937863 (firopow 312621). It will probably
give you the highest hashrate seen so far, and hopefully have no
issues running.


Memory Timings
Expand All @@ -160,12 +221,18 @@ 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.

It _is_ important to note that the max possible hashrate for progpow
is always bound by the memory bandwidth available though. Therefore,
simple things like increasing REF interval will have an impact since
it increases the effective available mem bandwidth.


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.
These clocks are old reports TRM testers before the kawpow release in
May 2020 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
------- -------- -------- ------ ------------- ---------
Expand Down

0 comments on commit 14d91e5

Please sign in to comment.