Topic: Team Black Miner (ETHW ETC Vertcoin Ravencoin Zilliqa +dual +tripple mining ) - page 54. (Read 35053 times)

Unfortunately, all of my cards are non-lhr at the moment.  

With the latest TBM 1.26, I am trying xintensity 1024 and it seems like this value produces 10% more accepted shares compared to xintensity 2048.

How accurate is the reported "Shares Per Minute/Pool Hashrate" on the miner?


  

I just noticed a very miner issue with how the submit rate is calculated on version 1.25.  

I am trying to figure out exactly what the 2miners current Megahash per share factor is (since they use shares per time unit to determine their pool MH/s rate), and when I was looking at the console I noticed that the Shares Per Minute was at 1.00 (and there were 65 shares submitted within the 65 minute run window), but the "Submit every ##.## seconds" was showing 1.35 seconds, which is a lower value than the actual share/second rate.  It seems to start out fairly accurate, but as time increases it becomes less accurate...  Is there some sort of sliding window that is used to calculate that averaged value that isn't used in the "Shares Per Minute:" variable?

Also, maybe it's not a bug but the Pool Hashrate very rarely seems to be aligned to the pool hashrate reflected in the 2Miners output.  I'm reasonably sure that the window you're using for averaging is different than the one used by 2Miners -- they use a 30 minute average to calculate the current rate and I assume that you're using the most recent hashrate or maybe average hashrate?  But even then, based on the shares per 3 hour window that 2miners provides, I'm calculating about 0.0073 Shares/min per 1 MH/s, so if I was hashing at 135 MH/s, my share rate should be about 0.986 shares per minute, but on the client a value of 0.986 (rounded to 0.98) shows about 145 MH/s.  Perhaps 2Miners has changed their difficulty a bit?? I'm not sure how the miner is getting the pool's difficulty value and if it's updated every time the miner is started...

Which leads me to another minor bug I just remembered; when the miner has been running for a long time (>24 hours) on 2miners (I've only seen this on windows, but tbh, I hardly every check the client output on HiveOS, so it might happen there too), the "Pool Hashrate: ##" will change to (VarDiff).  

yes. The lhr-unlock might need some adjustments. Please test.

edit: Ethereum classic on miningpoolhub seems to have issues after the stratum change, ethereum mining works fine. Strange..

---

use the 11.5 version if you have the latest driver installed. Should be a little bit faster as well

---

will re-upload a fixed version soon. Found another index bug opencl+cuda mixed rig.

[moderator's note: consecutive posts merged]

Are high intensity values still recommended when using Nvidia Cards on either MPH or 2Miners?

Currently running xintensity 2048 on MPH as of yesterday…

v1.26
1. Added --lhr-unlock option that can give a +20% boost on lhr cards nvidia with lower power.
2. Reduced invalid shares on hiveon pool and possibly other ethereum stratum 1.0 pools.
3. Faster reconnect to pool if pool does not resolve or is not available.
4. --xintensity 24 default on ethermine for AMD cards.
5. Fixed memleak in the dag cache code when mining ETH+ZIL.

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

fixed version:

TeamBlackMiner_1_26_cuda_11_2_fixed.7z
https://www.virustotal.com/gui/file/d2b5834421cc8e9e2823bed1ab64df31bd182a0bf93b86e2cf66064527bafa2a?nocache=1

TeamBlackMiner_1_26_cuda_11_4_fixed.7z
https://www.virustotal.com/gui/file/31e7e35c12da1ec49999bea43750362e43014c18b3bc61519a636e45a8c43aa9?nocache=1

TeamBlackMiner_1_26_cuda_11_5_fixed.7z
https://www.virustotal.com/gui/file/1b295f79d60329dc38b4c98aad76d64ad58df62d9f812ef03d90f8e6de24a7f0?nocache=1

Thank you for your answer, I see now what the meaning of the brackets are in the readme.txt. Maybe a full example at the end of the readme.txt file would save you questions like this

Also thank you for the tip, 24 is much better for my rx 6800. The miner chose 224 authomatically for the gtx 1660s but it chosed 0 for the rx 6800, I guess you are aware of that. I put 8 because a friend told me to as I was getting an insane amount of rejected shares in ethermine.

I understand there are three different miner versions for different cuda devices (11.5, 11.4,11.2). How do I know which version to use for a particular device?

Regarding older amd cards, I have several rx 590, the hashrate is similar as in TRM but the power consumption at the wall is 10w higher per card with team black. However for my rx 6800 and for the gtx 1660 team black is better than any other miner I have tried. Congrats!

The repository you are linking from is from 2018.

I was in the team that made the first ethereum gpu miner. back in 2015. The Gateless Gate Sharp version seems to be a slightly modified version of the original kernel.
 

Someone's in violation of the GPLv3. Your AMD Ethash is clearly a slightly modified version of this: https://github.com/ethereum-mining/ethminer/blob/master/libethash-cl/kernels/cl/ethash.cl - and not even the newest version! You added in split DAG support, but that's about it.

Use brackets around them  -E [8,224] . 8 is too low. I think 24 is better

Hello,

I am on TBM 1.24, I got a rx 6800 and a gtx 1660 super. If I try to set different xintensities for the cards -E 8,224 I end up having 8 for both of them. What am i doing wrong ?

Happy to hear, I had pool side speed issues on hiveon but good results on miningpoolhub. Flexpool seemed to have a lower reported rate like hiveon, so looking forward to testing v1.26.

I've been using your miners since you used to do specialized paid miners, I think I purchased a skunkhash miner from you so I know you do good work.

We have fixed a duplicate share bug in multicard rigs on the hiveon pool and possible other ethereum 1.0 stratum pools. The ~2% rejected shares are now ~0% in version 1.26 and this will improve the poolside speed..

hi, first thanks for the miner, really good, now testing x6 rtx 3090 in flexpool 133mh to 135 best card, only runing --xintensity 512 , less than 2% stales, with its the best kernel and dag for last version of the miner?
thanks

Nope. just tried, even this doesn't help.
okay i will check it on Windows, maybe miner will be able to start.
Thank you Friend!

On high oc on 1080ti and the 1070 --kernel 0 can help. you can try with a low --kernel number

just tried both parameters (-K 1 ; -j 1200,1200,1200,1200). still same error GPU Dag verification failed

then try this:

 --lock-cclock [[1200,1200],[1200,1200],[1200,1200],[1200,1200]]

it will undervolt and give more power to the memory controller.

sorry but as i wrote above, i already tried dagintensity 1 and it didn't help =(

try with --dag-intensity 1 --lock-cclock [[1200,1200],[1200,1200]]

Hello guys.

Please could you help me?
All day I tried to run TeamBlackMiner on four RTX 3070, but even with the minor overclocking (for example, +1000 MHz on video memory) I get DAG Verification Failed on all video cards. Only at the stock frequencies, the DAG is generated without errors.
I cannot increase the frequencies after generating the DAG, since I am going to mine on ezil.me and every time it switch DAG I will get a verification error again.
I also tried to set parameter --dagintensity to 1, but it doesn't help.
also i tried to set xintensity to 48 and DAG was verified ok, but i get very very low hashrate. If xintensity is higher - DAG verification error appears again.
now my OC settings for RTX 3070: Core -100, Mem 2200, PL 130.

I'm using HiveOS 0.6-211@211116, NVIDIA drivers 470.86 and latest version of TeamBlackMiner.

Help me please, I really really want to try this awesome TeamBlackMiner.