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

v1.32 could do 85MHASH, v1.33 can do 95 MHASH. (3080ti)

11000 memory, 75% tdp 0 core.

Might need tuning. defaults are nerfed. v1.33 has semi Autotune, but you need to start correct. LHR unlock is still in BETA, so we do small adjustments/improvements for each release.
---------

linux binaries of v1.33 released.

any LHR number we can expect for 3080 or 3080ti for example?

v1.33
1. Fixed index problem in stats when running with a selection of the gpu's.
2. Added more pools.
3. Improve the EXIT code for LHR gpu's
4. Improved the stability and speed of the --lhr-unlock
5. Improved --dagintensity more stable on higher clocks.
6. Try to remove more rejected shares on the hiveon pool (again)
7. Fixed bug in the LHR detector
8. Fixed Hang if selecting a non existing cuda device

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

TeamBlackMiner_1_33_cuda_11_5_fix.7z
https://www.virustotal.com/gui/file/faa0f2694d6a2beeeecac615e21975d49eeae3745ce10853be196348a33549c0?nocache=1

TeamBlackMiner_1_33_cuda_11_4_fix.7z
https://www.virustotal.com/gui/file/6600f56f9be19c8e6d670bc103c34798355c92dcc7140ad1f8f166a699cf4c11?nocache=1

TeamBlackMiner_1_33_cuda_11_2_fix.7z
https://www.virustotal.com/gui/file/2c1bbf51b0ee3f90be60bb70e9c7e9cbc47727cf6898de94b005457a46f78e9c?nocache=1

TeamBlackMiner_1_33_Ubuntu_18_04_Cuda_11_5.tar.gz
https://www.virustotal.com/gui/file/ec72ec4cdfadb2bf6a929810c63ea14d447f93c5886b8054231108286ab3720f?nocache=1

TeamBlackMiner_1_33_Ubuntu_18_04_Cuda_11_4.tar.gz
https://www.virustotal.com/gui/file/ec0056312d8c0f3e0b320209aaea44419e7cee3c8c9943868099a796e5a4c48a?nocache=1

let's go sir when is it? cant wait... new release means improvement and a fix of something.. 

I really only look at the pool stats for stale shares and I'll check through the miner logs to see if there were any stales or rejects that aren't represented in the pool data.  I don't even look at the miner hashrate information anymore really, I'll calculate the average pool hashrate myself based on the number of valid shares submitted and the timeframe over which those shares are submitted (ensuring valid shares from the miner data = valid shares from the pool data).  I've managed to push the miners hard enough to get stale shares at the pool, but once you go over a certain intensity, the miner becomes super unstable and generally getting stale shares is past the point of long term stability anyway.

Remember that some pools pay for stale shares, but the increased poolside speed doesn't always give higher payouts.

---

I got a 3070LHR in it is hard to get it unlocked. In v1.33 I can do around 43MHASH.  Not sure about the 3060ti.

in v1.32 you can try tweak 1-8, and lhr-unlock 0-100 or more.

--tweak [1] --lhr-unlock [30]

note that in v1.33 the values will change and you have to retune.

[moderator's note: consecutive posts merged]

Hi
Whats a good start setting for a 3060ti lhr v3?

I have it as device 0 so i added --lhr-unlock [1] on bat file, its okay?
thanks
alex

hi, thanks for replies.
I was first using xintensity -1, after reading sxemini reply I used xintensity 78 which indeed lowered the stales and a little the hash rate. now around 75.5mh/s which is still better than what I had (73.4mh/s with nbminer)

now I have 13 stales for 141 shares.
https://imgur.com/a/hHhg7CD

I will have to continue lower xintensity for stales to disappear I guess. fair enough.
I didn't find out the fixes for stats and api tho. maybe I should try to use 11_4 or 11_2 ?

anyway great miner, tbh I'm not the best tester, but definitively best hash rate perf I ever got so far.

I think we will improve the estimate in the next version. We can check if the new job is a new block. Currently we only check if the pool has sent out a new job, but completing the work on old jobs doesn't give stales on the recommended pools.

It's not the cards, is the pool. Many pools pay for stale shares, and level 1 stales are counted as normal shares. (2miners, miningpoolhub, nanopool, f2pool etc..)

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

I don´t think that you can push so high your intensity without getting stale shares. Can you show us your miner with stats? All over intensity 80 result in more staleshares - tested with 10 different AMD cards.
My Nvidia rigs runs fine with intensity 284.

I'm currently running between 800 and 1024 on my 6800's on 2Miners and getting decent results (66-68 MH/s).  The funny thing is that my fastest and most stable card is my Sapphire 6800, the 6800XTs are close and run very nearly the same hashrate in the client but their share rate at the pool is lower, and by far my worst card is the 6900XT which won't run full memory speed without crashing (same memory as the 6800XTs) and constantly drops to low power if the memory is pushed too fast, or has these annoying 1 second power downs which don't crash the miner (as opposed to those glitches that do crash the miner and the driver).  

But in general, it seems that I can push the intensities on these cards without getting _any_ stale shares at the pool, and maybe 20% 'estimated' by the miner.

Oh, and yeah, there are certain AMD cards that will not show statistics, but I'm not exactly sure why, since I have two ASUS TUF 6800XT cards that are identical, one shows stats and the other doesn't, (the other one that doesn't show stats, is unsurprisingly my 6900XT), while they all show stats in the HiveOS GUI.

Remove --xintensity -1 for this pool. Ethermine doesn't pay for stale shares, so you need a low value like the default --xintensity 24 or similar. --xintensity 78 was reported to run good on the 6800XT.

The hashrate will drop, but if you want to use --xintensity -1 switch to 2miners, f2pool, miningpoolhub, nanopool or similar.

For the color you can find a ansicolor.reg file in the miner folder. double click and yes and now you see the colors.
What is the problem with the api? There is no much you can do, only add the argument to the commandline and it will run. You added the argument? --api --api-port xxxx (xxxx fill in your prefered port)
No stats: what driver you are using?
The ratio is ok if the pool pay for stale shares, if not, reduce --xintensity to reduce the stale shares.

hi.
my 1st times trying tbm and it's going fine with a 6800xt. some issues tho:

- can't make remote api work
- no stats
- no colors & the text is not aligned somehow, compared to screenshots I've seen here
- can't say if my stall ratio ok: 114/0/21 ?

I'm using Windows, tried 1.32cuda11.5 version. here is my bat file. about the api I tried to go to these urls:http://127.0.0.1:4068/miner, the browser failed to connect.



here is a screenshot of tbm:

https://i.imgur.com/mvuaKTJ.jpeg

Try to add --dagintensity 1 and --kernel 1. (kernel 1 low power, kernel 8 high power) 

The dev fee is mined in the first 10 minutes of mining, so if your rig is crashing 20 times, the devfee is higher than normal. Miner startup and Dag creation is also taking a while to create (up to 20 seconds), so a stable rig is important.



10% of the time is used to mine the maintenance wallet, so it will even out over time. 9 hours isn't enough. If the rig is crashing regulary, the factor might change.
The maintenance wallet is starting around 20mins into the mining and will run for a few seconds depending on the config, and then resume after another 20mins ..
If your rig is mining for 19 minutes and crash every time, 0 to the maintenance wallet..

---

We fixed a couple of leaks in the latest versions. Older versions have a leak in the dagger buffer when mining ETH+ZIL. 1.32 should be good though. You can restart and do some tests, report an issue to git if you find anything and we will fix it.

---

v1.33 will have an improved hashrate on the 3080ti (LHR) + 10MHASH stable. The 3080ti and 3060 LHR1 can run for 24 hours without triggering LHR, but I have problems with the 3070 LHR2.

[moderator's note: consecutive posts merged]

Managed to get TBM 1.32 to run in SMOS.

Some notices. I'm currently testing TBM 1.32 with a 7 x 3060 Ti FHR. SMOS 5.10.60-sm1#021 nvidia drivers 470.74. Was running t-rex-v0.24.8 with same SMOS and Nvidia versions. With TBM I had to slightly lower my mem overclock, it was crashing all the time. Even with lower mem overclock rig restarts about 20 times per day.
Only reason I switched is the "maintenance-fee" feature. It works but it has room to grow.
My config: -d -a ethash -H eu1.ethermine.org -p 4444 -r 40 -y 20 -t 120 -W "ETH_WALLET1" -w $rigName -P x --maintenance-wallet "ETH_WALLET2" --maintenance-percent 10
(Note on config for SMOS: If you don't put "-d" you don't get any MHs status in SMOS. SMOS puts a persistent message in console telling you to put "-b" to see stats. If you put "-b" you're telling TBM to run only with AMD cards. Not cool when you only have Nvidia cards in your rig... So don't put "-b" to see stats, put "-d")

Ethermine reported hashrate in "ETH_WALLET1" is the full rig's speed not the 90% of the rig's full speed as it should (since the maintenance fee is 10%). In "ETH_WALLET2" it only reports 2,4 MHs, should be 10% of the total hashrate.
Below numbers are after 9 hours running straight without a reboot.
Reported hashrate in both SMOS and Ethermine "ETH_WALLET1" is about 433 MHs, Current is 373 MHs and Average is 306 MHs.
Reported hashrate in Ethermine "ETH_WALLET2" is 2,4MHs, Current is 35.8MHs and Average is 28.4 MHs. 
As you can see by the numbers Current and Average are way off. Even if we take that Average needs more than 9 hours online to stabilize, Current should be very close but it's not. About 24 MHs are missing. Any ideas?

I checked my memory stats on HiveOS and it seems that there is a some weird allocation happening in TBM 1.32 (maybe earlier too?).  Currently TBM has mapped 219G of memory space for my 6 card rig...  Now, it's been a while since I really looked into how linux handles address spaces, and it may be that this is just recording the total amount of memory allocated from the graphics cards, but even then I don't have 219G of memory across all my cards and CPU, so maybe there's a leak happening when the miner is failing and being restarted (as my rig is currently doing as I test out various different voltages, speeds and intensities, and the previous Alloc isn't being released?  Or it might be a common thing with mining software and I'm only just now looking at it and scratching my head.

A new, promising, built from the ground-up ALT needs an AMD miner.. Recently gone CPU-GPU but only green miner available (and very slow green miner)

Kaspa is a 1 second block POW coin, with an aim of 10 and 100/blocks/sec .. You can see the potential. Here's a snippet below:

''Kaspa is a proof-of-work cryptocurrency which implements the GHOSTDAG protocol. Unlike traditional blockchains, GHOSTDAG does not orphan blocks created in parallel, rather allows them to coexist and orders them in consensus. Whereby our blockchain is actually a blockDAG; you can see GHOSTDAG in action in a real time blockDAG visualizer). This generalization of Nakamoto consensus allows for secure operation while maintaining very high block rates (currently one block per second, aiming for 10/sec, dreaming of 100/sec) and minuscule confirmation times dominated by internet latency''

https://github.com/kaspanet/kaspad

cheers

Okay, so there's a spelling error in the command line help for the lhr unlock.

Also, I have noticed that HiveOS is showing the client reported values for "Hashrate" for the Nvidia cards, but the AMD cards are showing the values for 'Average'.