TeamRedMiner Ethash 4GB Status ============================== 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. ========================================================================= 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. ========================================================================= 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!