|
Gminer is sponsored by The Russian Industrial Military Complex. By using it you are supporting Putin and his war.
V. Buterin and Ethereum wil go POS in 3months, and this is when we end our support for ethereum.
|
|
|
|
to select the desire gpu
amd: --cl-devices [0,1,2,3,4] nvidia --cuda-devices [0,1,2,3,4] Or all amd devices; --amd-only Or all nvidia devices; --nvidia-only use TBMiner --list-devices to see the device order. |
|
|
|
This LHR business is weird... I created a startup - no login script to run the miner on my windows machine (so none of the other user-level garbage is loaded on login), and I set the --LHR-unlock to "0" with a --tweak of "5", to test the baseline full LHR speed (what Nvidia intended for the card to do when mining ethereum), and over the past 16 hours the miner share rate has averaged 54 MH/s and 2Miners poolside for the past 6 hours is 61 MH/s ...
Which is better than the 47 MH/s I wound up getting when logged in and running an LHR-unlock of -25 / tweak 2 (which was required to allow the miner to mine for > 300 seconds without a reset)...
Based on the non-LHR architecture with GDDR6x RAM, I would expect that the full non-LHR hashrate of this card under a standard miner without insane OC's would be between 67-69 MH/s and getting and average of 54 MH/s without unlocking means it's running between 77 - 80% of its maximum potential at baseline... Is this normal? Am I missing something about how the --LHR-unlock 0 functions? Are my current OC values pushing the card beyond the 'normal' LHR and the standard TBMiner advantage is just compensating for the cards natural speed lock?
No 61MHASH is not the normal LHR rate for this card (3070ti). it will go below 38MHASH in Phoenix miner after a few seconds of mining. I get similar results in windows when I disable fast startup and reboot the rig, the card fail to enter the LHR mode and is hashing at almost full capacity for days with the TBM miner. Reproduced on the 511.23 driver. The --lhr-unlock option will enable a "reduced hashrate mode" to avoid LHR and try to autotune if the lhr unlock is triggered. |
|
|
|
So if im right for example
Wallet A (Main wallet)
Pool A (HiveOn)
Wallet B (maintenance wallet) Lets say 10% of 1gh
Pool B (uses HiveOn aswell?)
So when i try to search Wallet B on HiveOn, there should be 100mh/s hasrate.
Yes, it might take an hour or more, but in the long term around 100 on the other adress on hiveon. 10% of the time will be used to mine on this adress, but the average hashrate depends on the luck in these 10%. But over a long term 10% |
|
|
|
How does the maintenance wallet function work. Is the wallet mining with the pool of the original wallet? Or can a 2nd pool be selected. Because i dont see any hashrate on the original wallet pool.
You can split the mining reward between two adresses on the same pool. Remember to specify the percentage as well. --maintenance-wallet <new adress> --maintenance-percent 5 5% of the mining revenue is mined to <new adress> 94.5% to the normal wallet. 0.5% fee |
|
|
|
I managed to pick up a 3070Ti for basically just the shipping costs and I've been trying my best to figure out how I'm supposed to interpret the TBMiner output for tuning. The following screen shows some very confusing information and I'm wondering if there's something wrong with the setup or if this is what I should expect with LHR cards:
In my tests, the autotune can reset a few times and still give a good result. With your current settings, 48MHASH should be the expected speed. Abit low but stable. Adding more LHR cards to the rig or normal cards can add stability and speed to the unlock. A freshly rebooted rig with the miner running in a startup script seems to be performing best. use --log. The debug output from the LHR code can be removed with a setting --no-verbose , work is still in progress. |
|
|
|
Uncle blocks and stale shares are not the same thing.
No but stale shares can find uncle blocks and should be rewarded. In Bitcoin mining stale shares are not rewarded by the blockchain, and should not be rewarded. |
|
|
|
I checked a few of the pools on the page (MPH, f2pool, 2miners) for their stales policy. MPH and 2miners don't say anything about it one way or another. F2pool indicates they don't pay stale shares.
On 2miners you can also get a rejected shares (stale). The difference is that 2miners always pay 100% for level1 stale shares. The ethereum blockchain reward stale work, so pools have a different definition of what a stale share is. On the 2miners pool you can get 100% accepted shares with --xintensity 512 and 0 stale shares, on crazypool you get ~5% stales. Miningpoolhub, f2pool,nanopool accept more shares. You can get a 5-10% higher poolspeed, and this will almost always lead to a higher profit. Conflating uncle blocks and stale shares. Even if that were true, crazypool does find and pay out uncles.
It's the reward system on crazypool that is odd. Every miner that find an uncle block will get his work rejected(stale), and the profit from the work will be divided to the other miners that have more accepted shares. Uncleblocks are securing the ethereum blockchain, and if every miningsoftware and pool try to remove the reward , it could be dangerous. |
|
|
|
|
For crazypool and other pools that doesn't pay for stale shares:
Users report less stales with --xintensity 24 on AMD cards. <1% . If you reduce it lower than that, f.ex 16 the lost performance will probobly eat up the gain.
But Lower intensity = lower power.
But why mine on crazypool, when you can get +10% more poolside hash on other pools. Are they paying +10% or more per MHASH than 2miner.com f.ex?
Crazypool only have 0.2% of the ethereum network hash
|
|
|
|
I have two AMD 6000 series rigs and have switched over to 1.56 late yesterday on crazypool. I'll let it go a few days and then run a comparison on pool side stats for shares.
Crazypool doesn't pay for stale shares and is not a recomended pool for The Team Black miner. You might need to reduce the default xintensities to get fewer rejecs/stales. https://github.com/sp-hash/TeamBlackMiner/blob/main/FAQ.mdWith same settings as TRM power consumption is a bit higher. For example, one rig went from 570w to 592w moving over to TBM.
More power and higher hashrate. With the right miningpool and the right settings. +5-10% |
|
|
|
0.6-213@220220 is showing as a 'miners update' and doesn't note the new version of TBM so it may be a few days before I can try this.
0.6-213@220220 🐧
What's new?
MINERS 👷♂️
⛏ TeamBlackMiner v1.56
* Fixed timeoutson AMD GPUs
* Fixed rejects at crazypool
|
|
|
|
|
SSL Port 5555 is not working.
you need to remove the TLS and use the statum port 3333
|
|
|
|
Is there a chance for a bit Win7 support? [for ETC mining on 1050 Ti]
Windows 7 will not be supported, but you can mine ETC on the 1050ti on windows 10 ------------------ since Hive is only supplying the CUDA 1.14 version with 1.55), which will unlock the version 1 LHR (I think -- not an expert here since I don't have any LHR cards).
The correct name is cuda 11.4 and cuda 11.5. The LHR unlock was made for cuda 11.5, but should work on cuda 11.4 builds as well. The lhr autotune code needs to be enabled with --lhr-unlock [1,1,1,1,1]. One entry per card in the rig. 1 = on, 0 = off You can adjust the starting point of the unlock to avoid the card resetting many times, and loose average hashrate. here is my rig running v1.55 for 5 hours without triggering the lhr: (passive powersave unlock setting) If you want to try to increase the hashrate you can increase the --lhr-unlock value --lhr-unlock [10,10,10,10...] or higher, but might trigger lhr. So a higher hashrate in the miner window. (80-90MHASH 3080ti, but also a higher lost hashrate rate because of gpu reset's) Latest nvidia driver on windows:  ------------------ - OC on both: 1350 CC / 2100 memory / pl 0
You need to use the the --lock-cclock option in the miner instead of setting clocks in hiveos. When locking the clock low, the gpu will automaticly undervolt to save power. The LHR mode only works with lower power. |
|
|
|
- hiveOS with latest TBM 1.55 cuda 11.4
- 2 GPU 3060ti LHR with Hynix memory
I used the --lhr-unlock [0,0,0,1,1]
Lock the GPU core clock to 1350 MHz --lock-cclock [0,0,0,1350,1350] Limit the power to 55% tdp |
|
|
|
so perhaps the cards are just failing but the miner isn't catching / throwing the error.
yeah, that's the problem here. Perhaps you undervolted too much.In 1.56 we have improved the error handling of failing gpus. |
|
|
|
Here's an issue:
The miner stopped accepting jobs at 7:18am
Thanks for testing. Report issues like this to our github, much easier to follow up on. Search for "has timed out" messages in the log. Looks like the gpu solver thread #0 has crashed, and not recovered. If the pool connection was broken, the program will restart automatically. Are you running with a high timeout value (-t). The default in 1.55 is to restart the miner after 2 minutes of inactivity. I have reproduced similar behavior if I clock my cards too high and they trigger a driver error. |
|
|
|
|
Show Posts
