v1.47

https://github.com/sp-hash/TeamBlackMiner/releases/


1. Fix dag verification copy on mixed cards rig AMD/NVIDIA.
2. Fix AMD timeouts in linux on high intensity.
3. Removed No GPU devices available on platform error message on startup.

TeamBlackMiner_1_47_cuda_11_5.7z
https://www.virustotal.com/gui/file/7809fcf40ad8bfeccee69bca1c73f8aeeb5d602c64128a1f150cbd0c8a957fcf?nocache=1

TeamBlackMiner_1_47_cuda_11_4.7z
https://www.virustotal.com/gui/file/acff4d45e4e765174e8b67560de9e6a6dfc7af988a56bd282a92dfcbb0dafd2a?nocache=1

TeamBlackMiner_1_47_Ubuntu_18_04_Cuda_11_5.tar.xz
https://www.virustotal.com/gui/file/c27750518e2ecba1dea05ed2515bfbbf12735f0b58ee4e36b9b2c5677846b0e3?nocache=1

TeamBlackMiner_1_47_Ubuntu_18_04_Cuda_11_4.tar.xz
https://www.virustotal.com/gui/file/b03bc7f374cd9fa6a89ee4efc84b999750578a9d1e6404aaf106ec7e127907ae?nocache=1

-----------------------

With v1.47 and the new copy dag function I managed to reach 35MHASH on the RTX 2060 6gb!! by increasing the memclock



fixed in v1.47

With 6 3070/3060ti cards  in the rig. lower the clock on one of the cards, or replace one card with an older card. +300-400mz on the memclock will give you a few percent profit increase.

I believe this was fixed in v1.42. Did you run the v1.41 version?





I tried the hdd->gpu aproach but it took 15 seconds on the pci1 riser. and used too much memory.

v1.46 re-upload

1. If dag verification fails, copy a verified dag from another gpu. (NVIDIA)
2. RTX 3070/3060ti/2060/2070/2060S/2070S stable on +300mz memclock, when the dag is created on another gpu.
3. Exit faster on linux

https://github.com/sp-hash/TeamBlackMiner

TeamBlackMiner_1_46_cuda_11_5.7z
https://www.virustotal.com/gui/file/5c4de8414cc0acf0353ab1bb69c4fad5997f211abeaca54f0b63305798160246?nocache=1

TeamBlackMiner_1_46_cuda_11_4.7z
https://www.virustotal.com/gui/file/b68c56f30fdb51ad13ae39efa36def7c1c2238b1f0f51736331974b5aa7c38d6?nocache=1

TeamBlackMiner_1_46_Ubuntu_18_04_Cuda_11_5.tar.xz
https://www.virustotal.com/gui/file/ad45e90dd5990fa3fa50c0922a59e6120d8e2ce2a27834e4ad518daa40d5edc1?nocache=1

TeamBlackMiner_1_46_Ubuntu_18_04_Cuda_11_4.tar.xz
https://www.virustotal.com/gui/file/5a55db1ac64e365273b257a9662b00cf51d5973c74302c3ee5f2d0764aba0904?nocache=1

V1.46 is Peaking at 112 MHASH but average speed is 80-90 at maximum. The LHR autotune is not done yet, so perhaps it will beat my manual tuning. But the maximum limit is probobly below 100MHASH somewhere. The LHR limit seems to be in hardware, so a crack is not possible.

The numbers are with the LHR partial unlock mode enabled. Without LHR 120MHASH should be possible I think. but then the gpu will switch to LHR mode in a few seconds and the hashrate fall to 60 ish.

The new code seems to work. The 3070LHR is now stable at 8100 Memory (+1500) . v1.45 could only do (+1200)

When the dag verification fails, the program will copy the dag from the fastest card in the rig (here a 3080ti). (gpu->gpu copy. No hardrive or memory buffers needed) Works smooth and fast on linux and windows 4GB rigs. For rigs with only 3070 or 3060ti cards, one of the cards need to be down clocked to be able to verify the dag, then the rest of the cards will copy this validated dag into their memory.

Windows version perhaps tomorrow. This feature need alot of testing.

use msi afterburner. We don't support sdtting the clocks on Amd cards

see the example launch config

tbminer_flexpool_eth.bat

yes

The difference can be big. The high xintensity not only increases the stale shares, it increase the share coun and poolside profit.

6800xt

flexpool: 61MHASH (poolside) (low xintensity, and not paying for stales)
2miners: 67MHASH(poolside)

Yes,. Tweak is not implemented for AMD yet. With tweak inplace it might help to reduce stales.



The only way to reduce stales on AMD is to change the pool or lower the xintensity. Did you try 24 or 48?
Having a low ping to the pool isn'tas important if the pool pay for stale shares. Read a few posts back and see the settings that can give you +10% poolside hashrates with TBM.

Expect 5-10% less return on the hiveon pool. There is a bug that give rejected shares on this pool.Something is wrong with the Ethproxy stratum implementation.

mine with --xintensity 1024 on 2miners.com / nanopool.org/ miningpoolhub/ f2pool.com or other pools that pay for stales.. And get no stale penalty. The estimated stales reported in the miner window is wrong. TBM has 0.5% fee. TRM has 1% fee. A few MHASH faster might not cover the expensive fee.

https://github.com/sp-hash/TeamBlackMiner/blob/main/FAQ.md

Is this the latest 1.45 version?

We have alot of releases, but we also have 38 test cards that run the latest version 24/7 (AMD/NVIDIA). But we can't test all the different mining pools, and sometimes pools change their code. So if you find something, please report to our github, here or on reddit.


try with --xintensity 1024


The stale share estimate is way off because it also report level 1 stale shares. You should always check the pool for the stale count. Will fix it.

(accepted/rejected/estimated stale)



Default intensity is 284 for NVIDIA and 71 for amd. You can try with --xintensity 512 and --tweak 6. Or change the pool and use --xintensity 4096 and get payed for the 5% stales.

https://github.com/sp-hash/TeamBlackMiner/blob/main/FAQ.md



Check the log for error messages. Perhaps you had an epoc change? The temperature high on the memory? The miner should work stable for days. But you can try the mining time option

f.ex

--miningtime 1440

will restart the miner every 24 hours.

-k --miningtime             Only mine for x minutes.
                            Typically used to test different setups.

I will create a cache of the dag buffer on file. On every new epoc, one of the cards in the rig needs to be able to create the dag buffer. And if the validation fails for the other cards, the program will read from file. Will use around 5GB of harddrive space, but no need to reduce the clocks.

I might add dag generation on the cpu/disk. This will solve this problem.

v1.45?

There are options you can try that might help.

--dagintensity 1
--xintensity 24 (or another low value)
--kernel 0
--lock-cclock [1200,1200]

TBM can still be faster on lower memclocks than the other miners, so you need to downclock and check the results.

Correction: cuda 11.4 and 11.5


TBM works really good when tuned correctly. We are planning to make mining easier for everybody and implement:

- LHR Autotune
- xintensity autotune (pool dependent)


In v1.45 kernel 1 or kernel 12 seems to be the winner on 3xxx cards.


Cheers.