⛏Team Black Miner (ETHB3 ETHW ETC VTC KAWPOW FIROPOW ZIL +dual +tripple mining )

[sp_]

there is a new cuda version 11.6 with the latest nvidia driver, have you gotten a look at it?

Should work with this setting set in the nvidiaprofileinspector (windows)

I can confirm this. TBM can't handle a Vega card. I tried to play with different timings and settings to make it work but the best i get is around 70% of the max speed i get with TRM or Phoenix. I sold the vega card though so i can't test it anymore.

Might need a kernel rewrite. the issue has been registered.

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

[KillrBee]

I am leaving the house now and can continue testing tomorrow.
Thanks for support!

TeamBlackMiner_1_44_cuda_11_6_beta6.7z

The dag is taking 10 seconds on the 3070 Mobile in 1-44 beta 6 with --dagintensity 1. I am able to run stable on higher memclocks

My observations for almost a day of mining on a 12x3080 no LHR rig.
1. If you are using Hive OS, use cuda 11.4, 11.5 gives a slight drop in hashrate.
2. I tried all the cores of the miner, the core does not automatically set correctly in Hive OS (1.42 core 1, 1.43 core 3). You must manually set the sign from 6 to 8 if you use 1.42 and 12-15 if use 1.43 20xx 30xx series of cards.
3. It makes no sense to set the core clock above 1440, it does not give any performance, it only increases the temperature of the cards and power consumption. This only works on older cards like 1070, 1080, 1080 Ti with gdd5 memory. On cards with GDDR 6-6X memory, the core does not participate in ETH mining and there is NO point in increasing it!
I tested the range from 1200 to 1600, anything above 1440 gives a drop in hashrate.
4. Option --xintensity , you need to select individually, for example, it works better for me on 8100 than on 4096.

Bugs that I found, on a rig with 13 video cards 3090x2 3080x7 3070 x4 NO LHR, I could not achieve stable operation, constant dag generation errors and a lot of invalid shares. Also, a 12x3070 NO lhr rig gives errors during dag generation, option --dagintensity 1 is always on.

Wishes, you should conduct detailed tests under HIVE OS, mining on Windows is extremely inconvenient and not popular. Big miners don't use Windows. Improve stability and fix core map definition.

I will continue to test it on different rigs to find bugs and errors in the hive, as well as to find the optimal settings.

I've extensively tested TBM with an RTX3090 and can conclusively say that setting the core clock above 1440 does make a difference, especially in a windows environment.  setting core clock is the only way we have to set the voltage of the cards in Linux, and 1650 for the GPU sets the voltage to 0.78 which is the sweet spot for the 3090 with a high xintensity value.

I've tested 1500, 1550 and 1600 and the only way I've been able to obtain 135+ MH/s at-pool hashrate is by being at 1650 -- I will provide one caveat on those numbers, is that the testing was done on versions 1.24 to 1.28, afterwards I stopped because I was happy with the performance, and the later versions focused on LHR, which for some reason had a negative effect on the non-LHR cards until this last release. Version 1.27 was where I was able to achieve the highest rates on my 3090, and version 1.41 is where the AMD cards started to achieve 66+ MH/s under windows and 65+ under HiveOS.

OK,  I think you use it now ? Can you show your up time in hive os ?

Here is my current HiveOS status -- I have a windows machine running an AMD 6900XT which I'm using to try and optimize my AMD cards in the Linux rig.



I just realized the the GPU and Memory stats are missing from the display (happens with HiveOS).  
Here is my HiveOS GUI for the reference values:

Not bad , what cuda and drivers do you  use ? 11.5 ? Or 11.4 ?

I'm using the 11.4 CUDA right now since 11.5 in linux underperforms.  But I'm switching back and forth between 470.94 and 495.46 while running the 11.4 CUDA runtime to see if there's any driver benefits.  

how is your test going? what are the results?

I see some minor improvements when using the 495.46 drivers with the CUDA 1.14 library under version 1.43 (I didn't run any 1.15 CUDA tests).  My average over the timeframe of testing (19 hours or so), was about 140 MH/s but I lost my logs when HiveOS updated to the newest version of TBM (and I couldn't get the AMD cards to hash properly with that, so I'm manually running the Nvidia cards with the new 1.44 binary and running the AMD cards through HiveOS on 1.43).  

I'd prefer not to have to manually set the kernel, but for some reason with the new set of kernels, the attuning will find a lot of 100's but pick the lowest (so it seems to like kernel 3), but my understanding is that the low kernels are good for low intensities, and the new kernels are good for low power, but I'm running my 3090 at high(ish) intensity and high power, so it would be good to have an idea of which would be expected to be the best kernel for the 3090 and the 2060S based on the 'style', so I don't have to spend days running tests on each kernel (for at least 2 hours with  multiple non-serial runs).  

That being said -- This morning my Pool-side average hashrate for my rig on 2Miners (so the last 6 hour average) was 511 MH/s.  This is for the combined hashing of 5 AMD 6-series cards, 1 3090 and 1 2060S.   With T-rex and TRM I would expect a maximum of about 470 MH/s (usually it was much lower-- 440 - 450 MH/s, so being at 511 MH/s is almost a 10% improvement across all the cards.

[sp_]

I see some minor improvements when using the 495.46 drivers with the CUDA 1.14 library under version 1.43 (I didn't run any 1.15 CUDA tests).  My

Correction: cuda 11.4 and 11.5

That being said -- This morning my Pool-side average hashrate for my rig on 2Miners (so the last 6 hour average) was 511 MH/s.  This is for the combined hashing of 5 AMD 6-series cards, 1 3090 and 1 2060S.   With T-rex and TRM I would expect a maximum of about 470 MH/s (usually it was much lower-- 440 - 450 MH/s, so being at 511 MH/s is almost a 10% improvement across all the cards.

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.

[Akyboy]

Also, a 12x3070 NO lhr rig gives errors during dag generation, option --dagintensity 1 is always on.

Hi Guys,

Yep, i still have same problem, DAG error on No LHR 3070
I'm testing the miner on my son's gaming computer before I put it on my rigs. But DAG is failing no matter what. Same clock i use on other miners and there is no dag errors.

[sp_]

Hi Guys,
Yep, i still have same problem, DAG error on No LHR 3070
I'm testing the miner on my son's gaming computer before I put it on my rigs. But DAG is failing no matter what. Same clock i use on other miners and there is no dag errors.

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.

[KillrBee]

Also, a 12x3070 NO lhr rig gives errors during dag generation, option --dagintensity 1 is always on.

Hi Guys,

Yep, i still have same problem, DAG error on No LHR 3070
I'm testing the miner on my son's gaming computer before I put it on my rigs. But DAG is failing no matter what. Same clock i use on other miners and there is no dag errors.

If your OC is stable, you can set the clock low on startup and wait for the DAG to be verified and then use nvidiaInspector to lock the clock speed.  Just make sure you're also forcing the P0 state since the Memory OC values will be much higher on the other P-states and the card will crash the system if the miner stops; the card will revert to P0 for idle and the requested OC values will be much higher than the card is actually able to clock to.  

[Akyboy]

Also, a 12x3070 NO lhr rig gives errors during dag generation, option --dagintensity 1 is always on.

Hi Guys,

Yep, i still have same problem, DAG error on No LHR 3070
I'm testing the miner on my son's gaming computer before I put it on my rigs. But DAG is failing no matter what. Same clock i use on other miners and there is no dag errors.

If your OC is stable, you can set the clock low on startup and wait for the DAG to be verified and then use nvidiaInspector to lock the clock speed.  Just make sure you're also forcing the P0 state since the Memory OC values will be much higher on the other P-states and the card will crash the system if the miner stops; the card will revert to P0 for idle and the requested OC values will be much higher than the card is actually able to clock to.  

I was thinking about that but as per sp_ , miner works faster then others so i lowered MC to 1050 and im geting 62+Mhs with no additional flags in bat file , all default.
Does this also mean that i could perhaps lower PL too to save some on electricity? ))

I will run it as this and report back.

[sp_]

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

[Akyboy]

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

That sounds like sp__ is back! )))))

I would love resolution as then i would just have to switch to your miner without tweaking any cards instead of tweaking 5 rigs with multiple 3070s. Luckily my son has 3070 on this gaming machine so i test here.

[Dojo76]

v1.45

1. Fixed cuda stats in mixed card rig and missing stats in AMD on linux.
2. Fixed bug in LHR detector, sometimes the program didn't detect correctly.
3. Fix AMD rig fail to start issue on linux from 1.44.
4. Improved default setting for the LHR mode.

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

TeamBlackMiner_1_45_cuda_11_4.7z
https://www.virustotal.com/gui/file/4b4e7f5d3f94855a20c3f8dc093cb329522213abf5518cac5b6a02f903d5d03a?nocache=1

TeamBlackMiner_1_45_cuda_11_5.7z
https://www.virustotal.com/gui/file/081b774689766644ff54cb08ffc914162f522c4c955b57f66f9570a07de054fb?nocache=1

TeamBlackMiner_1_45_Ubuntu_18_04_Cuda_11_4.tar.xz
https://www.virustotal.com/gui/file/11a14093aadcf09563fe4398f6b8f073e0b9882721968d66473349faaa30b9e4?nocache=1

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

I hope it will fix the issue, Hiveos has not realeased an update with 1.45 so I can't test it yet

[KillrBee]

v1.45

1. Fixed cuda stats in mixed card rig and missing stats in AMD on linux.
2. Fixed bug in LHR detector, sometimes the program didn't detect correctly.
3. Fix AMD rig fail to start issue on linux from 1.44.
4. Improved default setting for the LHR mode.

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

TeamBlackMiner_1_45_cuda_11_4.7z
https://www.virustotal.com/gui/file/4b4e7f5d3f94855a20c3f8dc093cb329522213abf5518cac5b6a02f903d5d03a?nocache=1

TeamBlackMiner_1_45_cuda_11_5.7z
https://www.virustotal.com/gui/file/081b774689766644ff54cb08ffc914162f522c4c955b57f66f9570a07de054fb?nocache=1

TeamBlackMiner_1_45_Ubuntu_18_04_Cuda_11_4.tar.xz
https://www.virustotal.com/gui/file/11a14093aadcf09563fe4398f6b8f073e0b9882721968d66473349faaa30b9e4?nocache=1

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

I hope it will fix the issue, Hiveos has not realeased an update with 1.45 so I can't test it yet

Just wget the tar file, decompress it and copy the TBMiner executable into the existing HiveOS generated TBMiner directory.  There's no other binaries that you need and the configuration is the same.

[sp_]

That sounds like sp__ is back! )))))

I would love resolution as then i would just have to switch to your miner without tweaking any cards instead of tweaking 5 rigs with multiple 3070s. Luckily my son has 3070 on this gaming machine so i test here.

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.

[Akyboy]

That sounds like sp__ is back! )))))

I would love resolution as then i would just have to switch to your miner without tweaking any cards instead of tweaking 5 rigs with multiple 3070s. Luckily my son has 3070 on this gaming machine so i test here.

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.

Sounds good to me!
Cant wait to try!

[ekgd39]

That sounds like sp__ is back! )))))

I would love resolution as then i would just have to switch to your miner without tweaking any cards instead of tweaking 5 rigs with multiple 3070s. Luckily my son has 3070 on this gaming machine so i test here.

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'm testing 1.45 on HIVE OS. At the start, the hashrate results on the pool and shares are good, I use cuda 11.4 Nvd driv. 470.94 , --kernel 1, --xintensity 1988 , cclock 1311. The miner still gives a dag generation error on rigs 3060 - 3070 . I continue the test.
I noticed that your miner works fine for the first 24 hours, but then the speed slows down, the hashrate on the pool becomes smaller, maybe this is due to Hive OS and cuda 11.4 You should do more tests under HIVE OS, more than 24 hours.

https://ibb.co/X3TYsrF

[KillrBee]

That sounds like sp__ is back! )))))

I would love resolution as then i would just have to switch to your miner without tweaking any cards instead of tweaking 5 rigs with multiple 3070s. Luckily my son has 3070 on this gaming machine so i test here.

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'm testing 1.45 on HIVE OS. At the start, the hashrate results on the pool and shares are good, I use cuda 11.4 Nvd driv. 470.94 , --kernel 1, --xintensity 1988 , cclock 1311. The miner still gives a dag generation error on rigs 3060 - 3070 . I continue the test.
I noticed that your miner works fine for the first 24 hours, but then the speed slows down, the hashrate on the pool becomes smaller, maybe this is due to Hive OS and cuda 11.4 You should do more tests under HIVE OS, more than 24 hours.

I've done some analysis based on the shares per minute as at-pool hashrate and:

*The miner stabilizes at around the 70 minute mark and remains fairly stable until at about the 300 minute mark, the miner performance begins to degrade after this.  
At the 430 minute mark, the degradation levels off and remains relatively constant until around the 500 minute mark where it degrades again until about the 600 minute mark where it remained stable / slightly increasing until the end of the sample dat at 780 minutes.

It seems that for whatever reason, the first 60 minutes sees the most improvement and the highest share/minute production after it peaks decreases significantly to the 70 minute mark where it stabilizes until the 300 minute mark.

[ekgd39]

That sounds like sp__ is back! )))))

I would love resolution as then i would just have to switch to your miner without tweaking any cards instead of tweaking 5 rigs with multiple 3070s. Luckily my son has 3070 on this gaming machine so i test here.

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'm testing 1.45 on HIVE OS. At the start, the hashrate results on the pool and shares are good, I use cuda 11.4 Nvd driv. 470.94 , --kernel 1, --xintensity 1988 , cclock 1311. The miner still gives a dag generation error on rigs 3060 - 3070 . I continue the test.
I noticed that your miner works fine for the first 24 hours, but then the speed slows down, the hashrate on the pool becomes smaller, maybe this is due to Hive OS and cuda 11.4 You should do more tests under HIVE OS, more than 24 hours.

https://ibb.co/X3TYsrF

I've done some analysis based on the shares per minute as at-pool hashrate and:

*The miner stabilizes at around the 70 minute mark and remains fairly stable until at about the 300 minute mark, the miner performance begins to degrade after this.  
At the 430 minute mark, the degradation levels off and remains relatively constant until around the 500 minute mark where it degrades again until about the 600 minute mark where it remained stable / slightly increasing until the end of the sample dat at 780 minutes.

It seems that for whatever reason, the first 60 minutes sees the most improvement and the highest share/minute production after it peaks decreases significantly to the 70 minute mark where it stabilizes until the 300 minute mark.

yes, at the start it is very fast, but then the same LoL miner overtakes it and gives a more stable hashrate. The developer needs to conduct detailed tests for more than a day to stabilize his work while I return to LoL

[KillrBee]

That sounds like sp__ is back! )))))

I would love resolution as then i would just have to switch to your miner without tweaking any cards instead of tweaking 5 rigs with multiple 3070s. Luckily my son has 3070 on this gaming machine so i test here.

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'm testing 1.45 on HIVE OS. At the start, the hashrate results on the pool and shares are good, I use cuda 11.4 Nvd driv. 470.94 , --kernel 1, --xintensity 1988 , cclock 1311. The miner still gives a dag generation error on rigs 3060 - 3070 . I continue the test.
I noticed that your miner works fine for the first 24 hours, but then the speed slows down, the hashrate on the pool becomes smaller, maybe this is due to Hive OS and cuda 11.4 You should do more tests under HIVE OS, more than 24 hours.

I've done some analysis based on the shares per minute as at-pool hashrate and:

*The miner stabilizes at around the 70 minute mark and remains fairly stable until at about the 300 minute mark, the miner performance begins to degrade after this.  
At the 430 minute mark, the degradation levels off and remains relatively constant until around the 500 minute mark where it degrades again until about the 600 minute mark where it remained stable / slightly increasing until the end of the sample dat at 780 minutes.

It seems that for whatever reason, the first 60 minutes sees the most improvement and the highest share/minute production after it peaks decreases significantly to the 70 minute mark where it stabilizes until the 300 minute mark.

yes, at the start it is very fast, but then the same LoL miner overtakes it and gives a more stable hashrate. The developer needs to conduct detailed tests for more than a day to stabilize his work while I return to LoL

To be fair, at the end of my 780 minute (13 hour) run, the median/mean hashrate for my 3090 was 181/182 MH/s with a STD.Dev of +/- 10 MH/s, so I'm not complaining.

[ekgd39]

That sounds like sp__ is back! )))))

I would love resolution as then i would just have to switch to your miner without tweaking any cards instead of tweaking 5 rigs with multiple 3070s. Luckily my son has 3070 on this gaming machine so i test here.

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'm testing 1.45 on HIVE OS. At the start, the hashrate results on the pool and shares are good, I use cuda 11.4 Nvd driv. 470.94 , --kernel 1, --xintensity 1988 , cclock 1311. The miner still gives a dag generation error on rigs 3060 - 3070 . I continue the test.
I noticed that your miner works fine for the first 24 hours, but then the speed slows down, the hashrate on the pool becomes smaller, maybe this is due to Hive OS and cuda 11.4 You should do more tests under HIVE OS, more than 24 hours.

https://ibb.co/X3TYsrF

I've done some analysis based on the shares per minute as at-pool hashrate and:

*The miner stabilizes at around the 70 minute mark and remains fairly stable until at about the 300 minute mark, the miner performance begins to degrade after this.  
At the 430 minute mark, the degradation levels off and remains relatively constant until around the 500 minute mark where it degrades again until about the 600 minute mark where it remained stable / slightly increasing until the end of the sample dat at 780 minutes.

It seems that for whatever reason, the first 60 minutes sees the most improvement and the highest share/minute production after it peaks decreases significantly to the 70 minute mark where it stabilizes until the 300 minute mark.

yes, at the start it is very fast, but then the same LoL miner overtakes it and gives a more stable hashrate. The developer needs to conduct detailed tests for more than a day to stabilize his work while I return to LoL

To be fair, at the end of my 780 minute (13 hour) run, the median/mean hashrate for my 3090 was 181/182 MH/s with a STD.Dev of +/- 10 MH/s, so I'm not complaining.

I ran the test for more than a day and my hash dropped from 1345 to 1275 in the miner in about 27-28 hours. The pool averaged 1.26 gh/s over 6 hours

[Dojo76]

v1.45

1. Fixed cuda stats in mixed card rig and missing stats in AMD on linux.
2. Fixed bug in LHR detector, sometimes the program didn't detect correctly.
3. Fix AMD rig fail to start issue on linux from 1.44.
4. Improved default setting for the LHR mode.

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

TeamBlackMiner_1_45_cuda_11_4.7z
https://www.virustotal.com/gui/file/4b4e7f5d3f94855a20c3f8dc093cb329522213abf5518cac5b6a02f903d5d03a?nocache=1

TeamBlackMiner_1_45_cuda_11_5.7z
https://www.virustotal.com/gui/file/081b774689766644ff54cb08ffc914162f522c4c955b57f66f9570a07de054fb?nocache=1

TeamBlackMiner_1_45_Ubuntu_18_04_Cuda_11_4.tar.xz
https://www.virustotal.com/gui/file/11a14093aadcf09563fe4398f6b8f073e0b9882721968d66473349faaa30b9e4?nocache=1

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

I hope it will fix the issue, Hiveos has not realeased an update with 1.45 so I can't test it yet

Just wget the tar file, decompress it and copy the TBMiner executable into the existing HiveOS generated TBMiner directory.  There's no other binaries that you need and the configuration is the same.

Thank for the tip, they've already released the update. Now it's working, problem with AMD rig and Ubuntu fixed

[dle378]

That sounds like sp__ is back! )))))

I would love resolution as then i would just have to switch to your miner without tweaking any cards instead of tweaking 5 rigs with multiple 3070s. Luckily my son has 3070 on this gaming machine so i test here.

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'm testing 1.45 on HIVE OS. At the start, the hashrate results on the pool and shares are good, I use cuda 11.4 Nvd driv. 470.94 , --kernel 1, --xintensity 1988 , cclock 1311. The miner still gives a dag generation error on rigs 3060 - 3070 . I continue the test.
I noticed that your miner works fine for the first 24 hours, but then the speed slows down, the hashrate on the pool becomes smaller, maybe this is due to Hive OS and cuda 11.4 You should do more tests under HIVE OS, more than 24 hours.

I've done some analysis based on the shares per minute as at-pool hashrate and:

*The miner stabilizes at around the 70 minute mark and remains fairly stable until at about the 300 minute mark, the miner performance begins to degrade after this.  
At the 430 minute mark, the degradation levels off and remains relatively constant until around the 500 minute mark where it degrades again until about the 600 minute mark where it remained stable / slightly increasing until the end of the sample dat at 780 minutes.

It seems that for whatever reason, the first 60 minutes sees the most improvement and the highest share/minute production after it peaks decreases significantly to the 70 minute mark where it stabilizes until the 300 minute mark.

yes, at the start it is very fast, but then the same LoL miner overtakes it and gives a more stable hashrate. The developer needs to conduct detailed tests for more than a day to stabilize his work while I return to LoL

To be fair, at the end of my 780 minute (13 hour) run, the median/mean hashrate for my 3090 was 181/182 MH/s with a STD.Dev of +/- 10 MH/s, so I'm not complaining.

I ran the test for more than a day and my hash dropped from 1345 to 1275 in the miner in about 27-28 hours. The pool averaged 1.26 gh/s over 6 hours

Do you experience this behavior on other miner software or just TBM?