⛏Team Black Miner (ETHB3 ETHW ETC VTC KAWPOW FIROPOW EVRPROGPOW MEOWPOW +dual)

[BitBlitzer]

https://i.imgur.com/6LYOhOt.png
I just started it for the image but it's above 111MH/s on atleast one of the GPUs (MSI Ventus 3080).

There is a big difference between 111MHASH and 100MHASH. Play with --kernel, --xintensity, --lock-cclock, --lock-mclock and power limit to tune the rig. Perhaps you can get all the cards to run faster than 108 MHASH with some more tweaking?.. I had a user on reddit who bought a new PSU and gained a few MHASH'es. More power, but +10% more money in the pocket might be worth it...

The memory speeds range all the way from 10180 to 11240 as you can see, thereof the different hashrates. All the cards are at their maximum memory speed.

[ayiphelmy]

v1.17
1. Fixed --xintensity -1 (dynamic) on AMD cards
2. Don't add hashrate to average hashrate when validating the dag file.
3. API bumped to v1.2. Added DAG generation to "threads" API call.
4. Core/mem clocks and powerlimit are set after DAG generation.
5. Added a few seconds of mining at startup. (while checking the dag buffer)
6. Reduce the stales on xintensity -1 (AMD)

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

https://www.virustotal.com/gui/file/60e0f121f9a99fccad3f0379b4a3d4c11128e858ce5ffd13b47df81a6df449a0?nocache=1
TeamBlackMiner_1_17_cuda_11_4.7z

https://www.virustotal.com/gui/file/56588e6c15d2dc21f455e6f8e45c5dd17037a3d9e3b2106755fb64ba7554280e?nocache=1
TeamBlackMiner_1_17_cuda_11_2.7z

linux later

this miner is the fafstest but there is  a bug on ethermine no reported hahsrate
(edited) after 5 minute reported hashrate showing

[sp_]

The memory speeds range all the way from 10180 to 11240 as you can see, thereof the different hashrates. All the cards are at their maximum memory speed.

maximum in msi afterburner? Or crash?

On the 1660 bios mod, only kernel 0 is running stable at the highest clockrate.

--kernel 0

[LHiRtibkc6]

I'm happy to say the defaults in v1.16 are proving to be competitive on flexpool so far.

Especially for RTX 3080, RTX 3090, and RX 6800. The effective hashrate matches or exceeds the same setup with gminer now, even with the little bit more stales .

Stales were good at first but climbed up to 2% over 24 hours. gminer is still slightly better effective because of that.

RTX 3070 and 3060Ti still seem to not accept the same level of memory overclocks. They have to be adjusted down -100 to -250 MHz to get past the DAG generation phase and the decrease shows in the effective hashrate.

The easy fix is to run the lock-cclock, lock-mclock, power-limit after the dag buffer has been generated. But then you need to run the miner as admin, and let us clock the cards for you. The delayed clocking might be included in v1.17

I rather control my own watchdog/overclock enforcement and have the option for miner do a slower/safe DAG generation to work with operating overclock settings.For those that want to let TBM control overclocks, is the delay only for the first DAG generation? If so, it will likely crash on epoch change.

[ayiphelmy]

any solution for this? seem hashrate not read correctly on ethermine

[sp_]

any solution for this? seem hashrate not read correctly on

Change to flexpool? Submit a bug to the ethermine team. you just wrote that after 5 minutes the reported hashrate was showing


if the hashrate is dropping, check the miner log for timout messages or restarts. Perhaps the cards are crashing because they are clocked to high, and the watchdog keep resetting. v1.17 has 8 kernels with different properties. low number more stable on high oc

[moderator's note: consecutive posts merged]

[ayiphelmy]

any solution for this? seem hashrate not read correctly on

Change to flexpool? Submit a bug to the ethermine team. you just wrote that after 5 minutes the reported hashrate was showing

after showing its dropped again

[BitBlitzer]

The memory speeds range all the way from 10180 to 11240 as you can see, thereof the different hashrates. All the cards are at their maximum memory speed.

maximum in msi afterburner? Or crash?

On the 1660 bios mod, only kernel 0 is running stable at the highest clockrate.

--kernel 0

I can't push any of the cards higher or they will crash in T-rex. They all max out at different frequences.

Is there a clear answer to which kernel is the fastest (on a given card) or does that depend on core/memory speed?

[ayiphelmy]

if the hashrate is dropping, check the miner log for timout messages or restarts. Perhaps the cards are crashing because they are clocked to high, and the watchdog keep resetting. v1.17 has 8 kernels with different properties. low number more stable on high oc

-200 core, 1200 mem 3090

[sp_]

I can't push any of the cards higher or they will crash in T-rex. They all max out at different frequences.

Is there a clear answer to which kernel is the fastest (on a given card) or does that depend on core/memory speed?

This is not T-Rex.

core/memory/power/xintensity/kernel

the maximum speed depend on 5 variables. Why don't you try yourself

And then there is mining pool and stale shares as well

[dle378]

v1.17
1. Fixed --xintensity -1 (dynamic) on AMD cards
2. Don't add hashrate to average hashrate when validating the dag file.
3. API bumped to v1.2. Added DAG generation to "threads" API call.
4. Core/mem clocks and powerlimit are set after DAG generation.
5. Added a few seconds of mining at startup. (while checking the dag buffer)
6. Reduce the stales on xintensity -1 (AMD)

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

https://www.virustotal.com/gui/file/60e0f121f9a99fccad3f0379b4a3d4c11128e858ce5ffd13b47df81a6df449a0?nocache=1
TeamBlackMiner_1_17_cuda_11_4.7z

https://www.virustotal.com/gui/file/56588e6c15d2dc21f455e6f8e45c5dd17037a3d9e3b2106755fb64ba7554280e?nocache=1
TeamBlackMiner_1_17_cuda_11_2.7z

linux later

Is xintensity 192 still the recommended value for miningpoolhub?

[sp_]

Linux build of 1.17 added

[sp_]

Is xintensity 192 still the recommended value for miningpoolhub?

For nvidia it should be good.

Testing it now on miningpoolhub. The payout was lower than normal the last 24hours, but pool luck was bad as well. Ethereum difficulty has rised to new heights.
Previous tests show that higher xintensities are better. f.ex 400

[dle378]

Is xintensity 192 still the recommended value for miningpoolhub?

For nvidia it should be good.

Testing it now on miningpoolhub. The payout was lower than normal the last 24hours, but pool luck was bad as well. Ethereum difficulty has rised to new heights.
Previous tests show that higher xintensities are better. f.ex 400

Here are my results after running TBM 1.17 with xintensity 192 for more than 13+ hours:

   835m [2021-10-20 06:57:14.476] miningpoolhub.com (ethash)    PING: 57ms    DIFFICULTY: 3.00     EPOCH: 448
   835m [2021-10-20 06:57:14.476] ID           BOARD   HASHRATE/W   HASHRATE           AVERAGE           SHARES
   835m [2021-10-20 06:57:14.476] GPU0           3060Ti   426.20 kH/W   65.21 MH/s   65.21 MH/s   238/0/0 (100.00)
   835m [2021-10-20 06:57:14.476] GPU1           3060Ti   353.21 kH/W.    64.99 MH/s   64.99 MH/s   228/3/0 (98.70)
   835m [2021-10-20 06:57:14.476] GPU2           3060Ti   423.85 kH/W.    64.85 MH/s   64.91 MH/s   253/6/0 (97.68)
   835m [2021-10-20 06:57:14.476] GPU3           3060Ti   356.24 kH/W   65.19 MH/s   65.19 MH/s   234/0/0 (100.00)
   835m [2021-10-20 06:57:14.476] GPU4           3060Ti   425.63 kH/W   65.12 MH/s   65.13 MH/s   247/0/0 (100.00)
   835m [2021-10-20 06:57:14.476] GPU5           3060Ti   426.30 kH/W   65.22 MH/s   65.20 MH/s   245/0/0 (100.00)
   835m [2021-10-20 06:57:14.476]                               2411.42 kH/W   390.58 MH/s   390.64 MH/s   1445/9/0 (99.38)

Going to change xitensity to 400 to see if that value is better on miningpoolhub.

[sp_]

 835m [2021-10-20 06:57:14.476] GPU1           3060Ti   353.21 kH/W.    64.99 MH/s   64.99 MH/s   228/3/0 (98.70)
   835m [2021-10-20 06:57:14.476] GPU2           3060Ti   423.85 kH/W.    64.85 MH/s   64.91 MH/s   253/6/0 (97.68)

Check the clocks on these cards, you shouldn't normally get rejected shares on this pool. Search in the log for cpu verification errors. Reduce the clocks. TBM will not send shares to the pool that fail CPU verification, but they will show as rejected in the stats.

Here is a live test on v1.17 with default intensity (192), ~21 hours:

[dle378]

 835m [2021-10-20 06:57:14.476] GPU1           3060Ti   353.21 kH/W.    64.99 MH/s   64.99 MH/s   228/3/0 (98.70)
   835m [2021-10-20 06:57:14.476] GPU2           3060Ti   423.85 kH/W.    64.85 MH/s   64.91 MH/s   253/6/0 (97.68)

Check the clocks on these cards, you shouldn't normally get rejected shares on this pool. Search in the log for cpu verification errors. Reduce the clocks. TBM will not send shares to the pool that fail CPU verification, but they will show as rejected in the stats.

Here is a live test on v1.17 with default intensity (192), ~21 hours:

449m [2021-10-20 00:25:04.726] GPU2 Cpu verification failed. Share not sent to the pool. Rejected!
482m [2021-10-20 00:58:43.716] GPU1 Cpu verification failed. Share not sent to the pool. Rejected!
617m [2021-10-20 03:16:21.509] GPU2 Cpu verification failed. Share not sent to the pool. Rejected!
701m [2021-10-20 04:41:53.221] GPU1 Cpu verification failed. Share not sent to the pool. Rejected!
708m [2021-10-20 04:48:35.281] GPU2 Cpu verification failed. Share not sent to the pool. Rejected!
708m [2021-10-20 04:48:36.015] GPU2 Cpu verification failed. Share not sent to the pool. Rejected!
708m [2021-10-20 04:48:36.749] GPU2 Cpu verification failed. Share not sent to the pool. Rejected!

Are these messages an indicator that the Memory Overclocks are too high for these two cards?

[sp_]

708m [2021-10-20 04:48:36.749] GPU2 Cpu verification failed. Share not sent to the pool. Rejected!
Are these messages an indicator that the Memory Overclocks are too high for these two cards?

Yes, but instead of dropping the memclock you can try a lower kernel number --lock-cclock is helping for stability as well.

[dle378]

708m [2021-10-20 04:48:36.749] GPU2 Cpu verification failed. Share not sent to the pool. Rejected!
Are these messages an indicator that the Memory Overclocks are too high for these two cards?

Yes, but instead of dropping the memclock you can try a lower kernel number --lock-cclock is helping for stability as well.

I did not specify a kernel speed as I was allowing the miner to select the best one.

0m [2021-10-20 07:15:30.854] GPU5 using gpu kernel 4.
0m [2021-10-20 07:15:30.885] GPU0 using gpu kernel 2.
0m [2021-10-20 07:15:30.963] GPU3 using gpu kernel 4.
0m [2021-10-20 07:15:30.995] GPU1 using gpu kernel 2.
0m [2021-10-20 07:15:31.010] GPU2 using gpu kernel 6.
0m [2021-10-20 07:15:31.026] GPU4 using gpu kernel 6.

Is there a baseline I can start with for 3060 TIs?

[sp_]

I did not specify a kernel speed as I was allowing the miner to select the best one.

Depends on the tdp(power), intensity, memory type and clocks. start it a few times and see what number is the best for the card.


--kernel 0 seems to best on gtx 1080 and 1080ti with the pill. default intensity (192)
--kernel 7 crashing


41MHASH on the 1080ti, 34++ on 1080

[moderator's note: consecutive posts merged]

[dle378]

--kernel 0 seems to best on gtx 1080 and 1080ti with the pill. default intensity (192)
--kernel 7 crashing


41MHASH on the 1080ti, 34++ on 1080

Does the kernel value determine the number of shares submitted per minute?