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

if mix : device 1 LHR and device 2 non LHR
 
-æ or --lhr-unlock [1,0]
-K or --dagintensity [0,9]
-E or --xintensity [-2,192]
-J or --kernel [-1,-1]
-u or --tweak [1,0]

correct me...

You need to be more spesific. Which card, which pool? The TBM team have access to many types of cards but not all of them. With abit of trial and error you can gain a few percent by adjusting the program correctly. This is a time consuming process, but some of you have already done it and got rewarded.

I really appraise TBM efforts and hope you'll become the next big thing.
Since all the mentioned options vastly change the behavior of a RIG, could you mention recommended settings for all the mainstream cards or recommended low and high values  for different cards along with how a setting changes the behavior of the card?

Only lhr-unlock and tweak works in the lhr mode. It is made for cuda 11.5 and the latest driver, but should work on cuda 11.4 as well. Expected speed on the 3060ti is 42mhash with 60% power and 7900 memory. This is with --lhr-unlock [1]

Hiveos is using the short options, so you have to find the correct letters from the short options.

more info here:

https://github.com/sp-hash/TeamBlackMiner/blob/main/FAQ.md

sir... guide me for 3060ti lhr in hiveos for v1.35 extra parameters --lhr-unlock, --xintensity, --dagintensity?? CUDA 11.4 working? 

thanks

Well written. Merry x-mas.

Again, you're lying and then dodging the issue. I didn't say you copied gminer - what I said was, you copied the Ethash OpenCL kernel.

The problem with the current autotune is that it runs for a too short time. Ideally it should run for minutes and not seconds. The problem is that the hashrate is reduced abit when trying out bad configurations. We don't have all the cards and models, so our solution is to create a program that will try to calcuate the best settings automaticly, or let you configure it yourself.

Nothing beats Human testing. V1.35 have 4 tuning options. Different cards have different optimal settings. Different power settings have different optimal settings. Different pools have different optimal settings.

--kernel (0-9) --xintensity (0-10000) / (0-2500 amd) --tweak (0-8) --dagintensity (0-9) / (0-8 amd)

So tune and be rewarded

72 kernels ...you kill me... sir ...u are already did with --xintensity xxxxx haha..

autotune will help so...... much and will you make autotune kernels be dynamic something like --xintensity [-1] or at least at periodic time or epoch change or whatever haha no idea..

what now --dagintensity in v1.35 are have effect .. well i will find out..

Thanks for your support.
This miner might be harder to setup correctly, but if you do, you will be rewarded.

I plan to create a new improved autotune in the next release which will check 72 kernels/launchconfigs instead of 8 today. Playing with the --dagintensity in v1.35 can actually gain a little bit on some cards. The default 9 is not always the fastest.
The modification is not done on amd cards yet, but can be implemented. I might seperate the tweak into a new setting.

I guess they're really playing a good long game, since they keep generating new features and slowly fixing bugs, which based on your comments, I assume they're generating on purpose to be sneaky and underhanded about some GNU violation? 

Even if they did take open source code and modify it for commercial purposes, the software is better than any others out there and there are a lot worse things in this world to get upset about.  The worst is that they have incorporated an open source project and built out and around it, which is common practice. Even creating a closed-source project based on the modification of the core open source code is not exactly uncommon, and there are far more flagrant violators of the GNU agreement for you to gripe about; how about elastic search, they _IPO'd_ on modified open source software which wasn't shared with the community.

I am a single point of reference for the validity of this software, it works very well for me. I'm not talking about the client generated hash numbers - I agree that there are a number of cases where the client generously over-reports the hash rate, but my actual at-pool share rate calculations still results in a hash rate of 132-140 for my 3090 and 65-67 for my 6#00 series AMD cards, and I am hoping for more improvement in the AMD cards through personal tuning and software improvements -- and this part of the software can't be open source stolen, because no other miner comes anywhere close in terms of performance, and no other miner comes even remotely close in terms of the methods required to tune the software to obtain such high at pool results.

I feel sad about the many obviously desperately unhappy people in the mining software community, because there are so many other things to direct focus and energy on than spite and undirected anger; live your life the way you wish, but trust me, there are happier and more satisfying ways to enjoy our lives.

Dag verification failed?

you can try to halve the xintensity and use --dagintensity 2

13 cards need alot of virtual memory in the rig

Hi!
My rig ( 2x1060+9xp104+3060ti+4000) works only with dagintensity 1 in 1.35
any suggestions to solve the problem?
alex

TBM is a new miner and not based on any other project. I am an opensource dev and have contributed to various crypto projects since 2014.

This is my config

-d -K 1 --dagintensity 1 --xintensity 284 -a ethash -H eu1.ethermine.org -p 4444 -r 40 -y 20 -t 120 -W ETH_WALLET -w $rigName -P x --maintenance-wallet MAINTENANCE_WALLET --maintenance-percent 5


As I understood dagintensity should be lower in higher clocks. Has this changed in new version?

Is TBM based on an open source project? It seems like there guys are doing their own coding, they are very promising and adding value some to the scene. As soon as the latest version is released in Hive OS I'll test it again

Now seems it works. At least mining started and shares accepted by pool )

Try --dagintensity 8 (or find the best setting 1 to 9)  (short option -K 9)

We have done a change in the threads per block configuration when using dagintensity. This was done to be able to run on higher clocks.

Just saw that 1.35 is available is SMOS.
I gave it a try in a 8 x 3060 Ti FHR RIG. Same config as 1.32.
Reported hashrate in SMOS is lower. 437.xx MH/s in 1.32 went to 415.xx MH/s in 1.35.
The thing is that poolside it now seems more correct since 1.32 reported 437.xx MH/s was never the same as current or average.
Tried 1.33 and had the same results as 1.35.

Was the 1.32 and previous versions over reporting the hashrate or is it something else? My cards have gone sub 60 MH/s now and I don't like it.

Uploaded  new 11.4 build. Please try again.

TeamBlackMiner_1_35_Ubuntu_18_04_Cuda_11_4.tar.gz
https://www.virustotal.com/gui/file/60e4649b9455ea582bd25dbd8b95ae14c246d9c89ce42761fbba1f988180f2fb?nocache=1