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

[jimsta]

Just want to say thanks for getting this going.

I've been running 1.1 for a while now, I've tried all version past 1.1 and it get tons more stale shares, with no changes to my clocks.

https://imgur.com/a/bbGToIc


Think I'll be sticking with the 1.1.

my settings are 66% PL, +1250 Mem, -150 clock and 80% fan speeds.

[sp_]

On nvidia, you can use 1.14b with --xintensity -1 for few stales. You can also try to lock the coreclock to 1500

open cmd as admin and run:

nvidia-smi -i 0 --lock-gpu-clocks=1500,1500

and change the pool and get a 12% boost in profit.

[Ramsete2]

still no news about linux 1.14 version?

Is it bad or good that 10% of the submitted shares are stales for miningpoolhub?

MPH pay 100% for stales so it doesn't matter. But for other pools this intensity can be a problem. Some pools kick you off if the stale share count is more than 5% The stale estimate in the miner window is inaccurate, and poolside stale can vary. This is because every mining pool have their own stale evaluation.

Source confirming that MPH pays for stales?
I didn't find anything on their website.

[moderator's note: consecutive posts merged]

[sp_]

Source confirming that MPH pays for stales?
I didn't find anything on their website.

mph pool doesn't track or reject stales. You can mine and check for yourself.

The Europe server had problems yesterday with high ping. Could be an attack.

The profit was down 12.3% the last 24hours, but the week has been good overall.

https://ethereum.miningpoolhub.com/index.php?page=statistics&action=blocks

[Ramsete2]

Source confirming that MPH pays for stales?
I didn't find anything on their website.

mph pool doesn't track stales. You can mine and check for yourself.

The Europe server had problems yesterday with high ping. Could be an attack.

The profit was down 12.3% the last 24hours

https://ethereum.miningpoolhub.com/index.php?page=statistics&action=blocks

I mined there, and under Round Shares and "Your Valid", stales are mentioned in brackets

[sp_]

I mined there, and under Round Shares and "Your Valid", stales are mentioned in brackets

This is not stale shares, the invalid shares have errors. (rejected shares)

your valid = accepted shares
your invalid = rejected shares

[Ramsete2]

I mined there, and under Round Shares and "Your Valid", stales are mentioned in brackets

This is not stale shares, the invalid shares have errors. (rejected shares)

your valid = accepted shares
your invalid = rejected shares

I'm sure that after my value of Valid Shares there was a bracked saying something like level 1 stares , etc.
By the way I could make another test.

[sp_]

We are probobly releasing v1.15 tonight for linux and windows. With bugfixes, lock clocks and api v1.1 (dual mining stats)

I'm sure that after my value of Valid Shares there was a bracked saying something like level 1 stares , etc.
By the way I could make another test.

Level 1 stale : the block submitted is 1 block late. The ethereum blockchain rewards up to 6 blocks late but with reduced payouts for each block (a stale block is called an uncle block).

[moderator's note: consecutive posts merged]

[PeaMine]

We are probobly releasing v1.15 tonight for linux and windows. With bugfixes, lock clocks and api v1.1 (dual mining stats)

Excited to try out 1.15 with my new Linux rig!

[sp_]

v1.15
1. API is bumped to v1.1. Added xintensity to threads call.
2. One set of shares stats per algorithm. If mining eth+zil zil will have own stats.
3. Fixed gpu order bug in the stats
5. Fixed gpu order bug in average hashrate
6. Fixed slow start and 0 in averagehashrate. Now with more samples to avoid fluctation
7. Fixed 0 bug in submit hashrate on ethermine
8. Added support more AMD devices in stats
9. xintensity reduced 400 on nvidia, amd dynamic intensity start lower to avoid crash on some config.
10. Added option to lock clocks --lock-cclock . (you need to run the program as admin)

hot tips:
rtx 3060, rtx 3060ti, rtx 3070, rtx 3080, rtx 3090 seem to run better with --lock-cclock [1500,1500]


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


TeamBlackMiner_1_15_cuda_11_4.7z

https://www.virustotal.com/gui/file/14fadd1bcf32ea40d38aba4393f26e9a0adaa03c62554907135f581bdd0de660?nocache=1

TeamBlackMiner_1_15_cuda_11_2.7z

https://www.virustotal.com/gui/file/4f0ad7e94367a74c33bbf45da59638cefcf7eba845db2b6d13275fa34a8d653c?nocache=1

TeamBlackMiner_1_15_Ubuntu_18_04_Cuda_11_4

https://www.virustotal.com/gui/file/1b94d97fbce18440d4d69e6fe4c79f19678c3d2d52b605d7e056d393cea11210?nocache=1

If there is not enough power, then gpu will not clock to 1800 mhz. It is not temperature and not power. As i said, with 1.09 it is working perfectly, but newer versions only with core-lock.
I cant try 1.14 because of 407.05.

Can you try 1.15 please. tbminer needs to be run as admin, and you supply the --lock-cclock parameter

1 gpu:

--lock-cclock [1500,1500]

2 gpus:

--lock-cclock [[1500,1500],[1500,1500]]

...

[moderator's note: consecutive posts merged]

[ZerodayTrader]

Testing 1.15 now. If its not "that good", is it possible to add the gpu timeout watchdog to 1.07? As 1.07 seems to be as "the best" Version atleast for Pascal GPUs - just 100% Valid Hashes on maximum Memory OC.

Edit; When i start with: --api --api-ip 127.0.0.1 --api-port 1025 im just getting: "ERR_EMPTY_RESPONSE"

[sp_]

Testing 1.15 now. If its not "that good"

For pascal cards the cuda 11.2 build is better. Check it out

Edit; When i start with: --api --api-ip 127.0.0.1 --api-port 1025 im just getting: "ERR_EMPTY_RESPONSE"

You need to add a request, like help

http://127.0.0.1:1025/help

[moderator's note: consecutive posts merged]

[ZerodayTrader]

Thanks mate! Running with older Cuda now. Will report tomorrow how it goes. 

[dle378]

v1.15
1. API is bumped to v1.1. Added xintensity to threads call.
2. One set of shares stats per algorithm. If mining eth+zil zil will have own stats.
3. Fixed gpu order bug in the stats
5. Fixed gpu order bug in average hashrate
6. Fixed slow start and 0 in averagehashrate. Now with more samples to avoid fluctation
7. Fixed 0 bug in submit hashrate on ethermine
8. Added support more AMD devices in stats
9. xintensity reduced 400 on nvidia, amd dynamic intensity start lower to avoid crash on some config.
10. Added option to lock clocks --lock-cclock . (you need to run the program as admin)

hot tips:
rtx 3060, rtx 3060ti, rtx 3070, rtx 3080, rtx 3090 seem to run better with --lock-cclock [1500,1500]


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


TeamBlackMiner_1_15_cuda_11_4.7z

https://www.virustotal.com/gui/file/14fadd1bcf32ea40d38aba4393f26e9a0adaa03c62554907135f581bdd0de660?nocache=1

TeamBlackMiner_1_15_cuda_11_2.7z

https://www.virustotal.com/gui/file/4f0ad7e94367a74c33bbf45da59638cefcf7eba845db2b6d13275fa34a8d653c?nocache=1

TeamBlackMiner_1_15_Ubuntu_18_04_Cuda_11_4

https://www.virustotal.com/gui/file/1b94d97fbce18440d4d69e6fe4c79f19678c3d2d52b605d7e056d393cea11210?nocache=1

In this release, should we specify the xintensity value or just leave it by default?

[sp_]

on pools that reject stale work. nvidia run with --xintensity -1 and coreclock 1500. The default is working good on miningpoolhub, nanopool, 2miners and others

[dle378]

on pools that reject stale work. nvidia run with --xintensity -1 and coreclock 1500. The default is working good on miningpoolhub, nanopool, 2miners and others

Thanks.

So far, I can already tell that this version of TBM seems promising.

Will update you in the next 8-10 hours.

[Jeggu]

Hi sp_!

Loving the work so far, I've been able to push my 3080s further than I would ever have hoped for.

Any plans on optimizing the miner for LHR cards? I've got a couple 3080 tis looking for a home.

[somaton]

Here are some info after testing 1.15:

1. ASCII bug is fixed now.
2. Now with core-lock gpu core is steady, looks fine. I'm using this command for locking core manually: nvidia-smi -i 0 -lgc 1500 (same as --lock-gpu-clocks=1500). There is no need to put same frequency twice for gpu or memory. You can put memory-lock at same time if you want: nvidia-smi -i 0 -lmc 8400 (same as --lock-memory-clocks=8400). Ideally core-lock, mem-lock and fan speed, so no need to use any other programs, just like t-rex.
3. GPUs order in status and configuration for --lock-cclock mismatch. Had to use GPU-Z to see real gpu order.
4. For some reason, 3070, especially 3060 ti is slower with 1.15 compared to 1.09, look at core/mem frequencies - they are almost same. Looks like 3060 ti and 3070 are underloaded with 1.15 - temperatures are lower compared to 1.09.

log from 1.09, --xintensity 64

  6665m [2021-10-15 20:13:36.173] ID   BOARD   TEMP   FAN   CORE   MEM   WATT   kW/h   COST/h
  6665m [2021-10-15 20:13:36.173] GPU0   3070   44/0   75   1464   8022   127   0.13   0.00USD
  6665m [2021-10-15 20:13:36.173] GPU1   3060Ti   44/0   78   1441   7963   135   0.14   0.00USD
  6665m [2021-10-15 20:13:36.173] GPU2   3060   45/0   88   1471   8462   107   0.11   0.00USD
  6665m [2021-10-15 20:13:36.173]                   369   0.37   0.00USD
  6665m [2021-10-15 20:13:36.173]
  6665m [2021-10-15 20:13:36.173] ID   BOARD   TYPE   HASHRATE/W   HASHRATE   AVERAGE      SHARES
  6665m [2021-10-15 20:13:36.173] GPU0   3070   Cuda   503.41 kH/W   63.93 MH/s   63.93 MH/s   1903/0/0 (100.00)
  6665m [2021-10-15 20:13:36.173] GPU1   3060Ti   Cuda   468.47 kH/W   63.24 MH/s   63.24 MH/s   1888/0/0 (100.00)
  6665m [2021-10-15 20:13:36.173] GPU2   3060   Cuda   470.12 kH/W   50.30 MH/s   50.30 MH/s   1455/0/0 (100.00)
  6665m [2021-10-15 20:13:36.173]          1441.99 kH/W   177.48 MH/s   177.47 MH/s   5246/0/0 (100.00)

1.15, without --xintensity

    20m [2021-10-15 20:51:17.199] ID   BOARD   TYPE   TEMP   FAN   CORE   MEM   WATT   kW/h   COST/h
    20m [2021-10-15 20:51:17.199] GPU0   3070   Cuda   42/0   75   1468   8062   127   0.13   0.00USD
    20m [2021-10-15 20:51:17.199] GPU1   3060Ti   Cuda   42/0   77   1438   7963   131   0.13   0.00USD
    20m [2021-10-15 20:51:17.199] GPU2   3060   Cuda   45/0   88   1499   8462   110   0.11   0.00USD
    20m [2021-10-15 20:51:17.199]                      368   0.37   0.00USD
    20m [2021-10-15 20:51:17.199]
    20m [2021-10-15 20:51:17.199] ID   BOARD   HASHRATE/W   HASHRATE   AVERAGE      SHARES
    20m [2021-10-15 20:51:17.199] GPU0   3070   495.74 kH/W   62.96 MH/s   62.64 MH/s   3/0/0 (100.00)
    20m [2021-10-15 20:51:17.199] GPU1   3060Ti   458.60 kH/W   60.08 MH/s   59.25 MH/s   8/0/0 (100.00)
    20m [2021-10-15 20:51:17.199] GPU2   3060   463.69 kH/W   51.01 MH/s   51.02 MH/s   9/0/0 (100.00)
    20m [2021-10-15 20:51:17.199]       1418.02 kH/W   174.04 MH/s   172.91 MH/s   20/0/0 (100.00)

[sp_]

Thanks for testing.

log from 1.09, --xintensity 64

in 1.15 you should multiply the intensity with 4. Run with --xintensity 256. 1.09 is using a cpu intensive thread scheduling that give 1-2% faster hashrate on low intensiities. We could add a --cpu-mining parameter in the next release.
 

1.15, without --xintensity

The cuda 11.4 build is faster on the rtx cards. It's not only a different build, it's a different kernel.
Pascal cards is faster in cuda 11.2, rtx card faster on 11.4.

I get around 1MHASH more on the gtx 1070 with the 11.2 kernel.

3. GPUs order in status and configuration for --lock-cclock mismatch. Had to use GPU-Z to see real gpu order.

this is what I replied on github in the same issue:

By default, CUDA orders the GPUs by computing power. GPU:0 will be the fastest GPU on your host
If you set CUDA_DEVICE_ORDER='PCI_BUS_ID' then CUDA orders your GPU depending on how you set up your machine meaning that GPU:0 will be the GPU on your first PCI-E lane.

on windows :
set CUDA_DEVICE_ORDER='PCI_BUS_ID'

to see the order run:

tbminer.exe --list-devices

[moderator's note: consecutive posts merged]

[somaton]

With 470.05 faster 11.4 builds does not help. No choices. About gpu order - just put this in your miner switches, its just easier. Looks like it is same what t-rex is doing with --pci-order switch.