Team Black Miner ⛏ (KAWPOW FIROPOW EVRPROGPOW MEOWPOW VERTHASH ETC/ETH/ETHB3)

[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?

[drewsolace]

Just switched all my RX6000 rigs over to TBM, saw HUGE improvement on submitted shares instantly, but went from like 0.3% stales using TRM to over 2% on TBM. I am on flexpool, miner sets that xintensity to 71 for flex. Anyone find a good number for xint on flex to reduce stales? Also seem to get invalid or rejects in the miner print I assume it goes accepted/rejected/invalid? But none reported by the pool. For example: 52/0/3. This only occurs on my Hive rigs, windows rigs seem to be all accepted. Glad to be with the black team now. Any info or help is appreciated!

[UniJo]

sp_ : are you planning on adding support for the BC-160 cards? I have 12 of them and i can't make it work with TBM (weird unstable speeds) for now the only miner i get decent speeds is TRM.