TeamRedMiner Ethash 4GB Status
==============================

v1.3 - 2020-12-17 - Moved the extended mining section.
v1.2 - 2020-12-13 - Rewrote Linux section before epoch 382.
v1.1 - 2020-10-12 - Added Linux section and info around extended mining.
v1.0 - 2020-10-04 - First version, Windows only.

Summary
-------
ETH is now approaching the beginning of the 4GB death period that will
start with epoch 382. The hard limit where 4GB GPUs will no longer be
able to hold the DAG necessary to perform max hashrate hashing has now
been reached.

This status document contains instructions on how to maximize the life
span of your 4GB gpus by mining with TRM in its "extended mode".  This
document will be updated continuously between TRM releases up until
epoch 382.

=========================================================================
Linux
=========================================================================

Linux TL;DR
------------------

Most or all(?) modern amdgpu-pro drivers should be able to mine epoch
381. After that, you only need to add the argument
"--eth_4g_max_alloc=N" to reserve N MiB for the DAG at startup. The
expected range for N is 4070-4078. You really want to run with the
highest N possible for your rig. If the rig fails to allocate the vram
on startup or the miner crashes after 5-10 mins every time, lower the
number (N) in small steps until the miner runs ok. When epoch 382 is
activated, the miner will automatically switch into extended mining
mode and continue to mine epoch 382 and up with a partial DAG but lose
some hashrate for every additional epoch.

If you don't provide a number, the miner will apply N=4072
automatically and log a warning with each stats print that you should
manually try to maximize your hashrate with the argument above.

Linux Instructions
------------------

1) Linux is much simpler to handle than Windows. We've verified mining
   on epoch 381 on amdgpu-pro drivers 18.50, 19.30, 19.50, 20.10. 

2) PRE-ALLOCATE: You should always avoid reallocation of the DAG
   buffers at epoch switches, which means you should instruct the
   miner to allocate the max possible memory at startup. The easiest
   way to do this is the use the "--eth_4g_max_alloc=N" argument,
   which also automatically enables extended mining after epoch
   381. The value N is the nr of MBs the gpu will allocate to store
   the DAG. You can also use epoch numbers, but trying to maximize
   storage using an exact MB number is necessary to maximize your
   hashrate.

   The max possible N value has varied a lot between gpus, driver
   versions and motherboards in our tests. The best drivers seem to be
   in the 18.30-19.30 range rather than 19.50-20.40. We have never
   seen N=4078 work on a driver after 19.30. However, we have also
   seen a number of rigs than only can do N=4072, and it doesn't
   matter what driver version you're running.

   A classic error when using a N that is just slightly too high for
   your rig is that mining works fine for 5-10 mins, then the miner
   crashes with kernel logs stating "Page allocation fault" or "Buffer
   eviction failed". In these cases, try lowering N with -1 or -2 MB
   and you should hopefully run stable.

3) PER-GPU CONFIG: in the approach suggested above, only a single
   value is passed to "--eth_4h_max_alloc", and that value is applied
   to all 4GB gpus in the rig. If you e.g. have a display connected to
   one of your gpus, or if you want to check if some gpus can handle a
   higher value than the others (not impossible), you need to provide
   a comma-separated list with values for all gpus in the rig.

   Example: if you have a mixed rig with two 4GB gpus at index 0 and
   2, and a Vega at index 1, you can pass:

   --eth_4g_max_alloc=4074,4000,4076

   Note that the Vega at index 1 also needs a dummy value. It will not
   be used.

   Display gpus typically need to adjust with at least -8MB compared
   to similar gpus not having a display connected.

3) TEST: take your normal command line and add "--eth_epoch=381
   --high_sample_mode=8" at the end to run simulated mining on epoch 381
   to verify that it works. You can also increase the number to higher
   epochs to test extended mining and check what hashrates you will get
   with partial DAGs.

4) Epoch 382 is here or I can't reach the same speed on the current
   epoch, what do I do if I want to continue mining?

   Your first choice is to continue mining with TRM in the "extended
   mode" using the argument "--eth_4g_max_alloc=N", as described in
   the instructions above. You will lose hashrate for every new epoch,
   so after 2-3 weeks it won't be worth it unless nethash has dropped
   significantly and profits have gone up. 
   
   Your second choice is to switch to a different coin using ethash but
   with a lower algo. Metaverse, Expanse, Ubiq are three examples, but
   their returns will be much lower then ETH.

   Your third choice is to switch algo. Plenty of choices available,
   although the power draw profile for e.g. kawpow is very different
   from ethash. You have to do your own research for making an
   informed choice here.

   Fourth choice: shut down and sell the gpus.

=========================================================================
Extended Mining
=========================================================================
TRM v0.7.14 adds support for "extended mining". This means that you
can continue to mine with 4GB gpus even when they can't store the full
DAG for the epoch. However, since the full DAG isn't available, some
hashes will be discarded and your hashrate will decrease for every
additional epoch.

This mode is enabled using the argument "--eth_4g_max_alloc=N". Please
see the description in the --help output (or USAGE.txt), or in the
instructions above. Windows users should try "--eth_4g_max_alloc=374",
Linux users should try "--eth_4g_max_alloc=4078". If you get
allocation errors on startup, or the miner crashes after the same
amount of time every run, lower the number slightly until it
works. For example, on amdgpu-pro 20.10, our tests crashed after
exactly 7 mins every run. Lowering the value from 4078 to 4076 and it
ran for days. Amdgpu-pro 19.30 could use 4078 with no issues.

NOTE: extended mining means that the optimal intensities will change
with each epoch. Therefore, the miner will reinitiate the auto-tune
process for every epoch switch during extended mining unless manual
intensities were given with --eth_config when the miner was started.

This is an example table with 2 x Nitro+ 470 4GBs mining at 29.65 MH/s
each at full speed, i.e. 59.30 MH/s total, having 4078MB of DAG buffer
space available. Power draw will stay roughly the same, so your
efficiency will take about the same hit as the hashrate.

Epoch  DAG MB  DAG %    Hashrate  Loss %
381    4072    100.00%  59.30       0.0%
382    4080    99.95%   58.38      -1.6%
383    4088    99.76%   54.89      -7.4%
384    4096    99.56%   51.46     -13.2%
385    4104    99.37%   48.29     -18.6%
386    4112    99.17%   45.17     -23.8%
387    4120    98.98%   42.17     -28.9%
388    4128    98.79%   39.35     -33.6%
389    4136    98.60%   36.80     -37.9%
390    4144    98.41%   34.23     -42.3%
395    4184    97.47%   22.46     -62.1%
400    4224    96.54%   12.55     -78.8%

Happy mining!

=========================================================================
Windows
=========================================================================

Windows overall comments
------------------------
- All our tests have been mode on driver Adrenalin 20.4.2. Many other
  driver versions will work equally well, we chose to lock down
  testing to a single version.

- Older drivers consume more baseline vram and will not work. You need
  to use a recent driver like Adrenalin 20.4.2 that we use for
  testing.

- This guide and testing applies to gpus _without_ monitor(s)
  connected. At this point, there simply isn't enough vram on the gpu
  to both store the DAG and drive graphics.

Windows TL;DR
--------------------

We now provide two new example .bat files, start_eth_4gb.bat and
test_eth_4gb_epoch_374.bat. If you can run the test and cards reach
their max speed, you're good to go for epoch 374 but need to add
"--restart_gpus --uac --eth_alloc_epoch=374" as additional arguments
to your current command line. The start_eth_4gb.bat contains these
arguments. You will also need TRM v0.7.14 or later. If you don't reach
the same hashrates as you normally do, or if you don't like the
built-in gpu reset mechanism, continue to read below.

The start_eth_4gb.bat file also enables extended mining for epoch 375
and up. You will lose hashrate for every additional epoch after epoch
374. The better choice is to switch to Linux first, as it enables full
hashrate mining up until epoch 381, then run extended mining from
there. See the separate section on extended mining for more details.

Windows instructions
--------------------
1) RESET gpus right before starting the miner. The allocation is very
   sensitive. Even coming from a fresh reboot isn't enough for some
   gpus. Starting with TRM v0.7.13, we include experimental support
   for automatically resetting gpus before mining. This maximizes the
   probability of Windows allowing the large DAG allocation.

   NOTE: the gpu reset is optional, but our example .bat files do
   it. You can test without the "--restart_gpus" option, and if it
   works fine without it, good for you! If you do need to reset gpus,
   you have four options:

   a) If you run the miner as Administrator, you can add
      "--restart_gpus" as a miner argument and it will automatically
      restart your gpus without requiring user interaction. Configured
      clocks will be retained, at least this has been the case in all
      our tests, so you typically run your clock configuration as
      usual before starting the miner.
   
   b) Run the miner as a normal user and add "--restart_gpus --uac"
      to your start command line. This will trigger a privilege
      escalation at startup, and the standard Windows popup asking if
      you accept running this program as Administrator. Only the
      separate process that resets the gpus will run with admin
      rights, the miner will then run as the normal user.
   
   c) Do your own reset of the necessary gpus with some tool,
      e.g. "devcon.exe" available in the Windows Driver Kit
      toolset. You need to google for instructions on how to use the
      tool. This mechanism was very common in the early Vega Monero
      mining days.

   d) Disable+enable all gpus manually in the Windows Device
      Manager. Not really recommended for anything but testing.

2) ALWAYS add the argument "--eth_4g_max_alloc=N" for a limit
   specified as an epoch or a raw number of MBs. We believe most (or
   all?) rigs should be able to do epoch 374, which means using
   "--eth_4g_max_alloc=374". If this doesn't work, as in you're not
   getting your normal max hashrates, try a lower number. This
   argument forces the miner to allocate the necessary vram on all
   gpus right at startup in a prioritized way, and then cap it and
   start mining in extended mode from epoch 375 and up.

3) TEST your max possible epoch on beforehand. This is done by running
   the miner in benchmark mode using "--eth_epoch=374
   --high_sample_mode=8". You just add these arguments last in your
   normal start command line with pool, wallet etc. This mining mode
   will NOT submit any shares to your pool, it's only for
   benchmarking. As soon as you see if you're reaching max speed or
   not, exit the miner and remove the argument from your start
   command. You can also test higher epochs to see what hashrate you
   will get in extended mining mode.

   NOTE: we also provide an example .bat file for this test,
   test_eth_4gb_epoch_374.bat included in the zip package.

4) ADVANCED mode: for some rigs, the default allocation strategy isn't
   optimal. We provide a tweak argument that might help for such rigs.
   The argument is called "--eth_4g_alloc_adjust=X,Y,...". This is the
   description from our --help output:

   -------------------------------------------------------------------
   --eth_4g_alloc_adjust=X,Y,...

   On Windows, the allocation balance is very delicate for 4GB gpus
   being able to reach their maximum possible DAG epoch.  The miner
   uses a strategy that has worked fine for our test gpus, but other
   setups can benefit from tweaking this number.  The valid range is
   [-128,+128].  Zero means no adjustment.  You provide either a
   single value that is used for all 4GB gpus in the rig, or a
   comma-separated list with values for all gpus, including non-4GB
   Polaris gpus.  Values for non-4GB gpus are ignored.
   -------------------------------------------------------------------

   I would recommended testing values between -16 and 16. I do not
   believe values outside that range will be helpful. If you do find
   that this is helpful for you, please drop us a note in our Discord,
   it's very interesting to hear if there are rigs out there only
   being able to do epoch 374 with a manual adjustment using this
   argument.

5) Epoch 375 is here or I can't reach the same speed on the current
   epoch, what do I do if I want to continue mining?

   Your first choice is to switch to Linux. Epoch 381 should be doable
   on most drivers, and all major mining os distributions will make
   sure they are capable of mining the max possible epoch.

   Your second choice is to continue mining with TRM in the "extended
   mode" using the argument "--eth_4g_max_alloc=N". This means
   allocating as much space as possible but then only storing a
   partial DAG. Your hashrate with decrease for every additional epoch.

   Your third choice is to switch to a different coin using ethash but
   with a lower algo. Metaverse, Expanse, Ubiq are three examples, but
   their returns will be much lower then ETH.

   Your fourth choice is to switch algo. Plenty of choices available,
   although the power draw profile for e.g. kawpow is very different
   from ethash. You have to do your own research for making an
   informed choice here.

   Fifth choice: shut down and sell the gpus.

