The following (minus the obvious) command: ./TBMiner --algo ethash ... -Y 3 --xintensity 1000 --log, resulted in:
Use brackets around the gpu selector -Y [3] ------------------------------------- Can somebody please share setup multiple 3070 (I have 8x3070 (original ones) and Afterburner clocks, as Im still getting lots of dag errors and stales.
One of the cards in the rig needs to be clocked lower than the others so that the dag buffer is created without errors and loaded onto all of the other gpus without errors. My 3070 LHR can run with up to 8300 Memclock if the dag is created on the 3080ti. (T-rex is crashing at 8100) But if your rig is only 3070 cards, let one of them run at 7800 to create the dag buffer. Stale shares can be removed by lowering the --xintensity or switching the pool. This image was created in p2 mode. But after set my cards in P0 mode, I could clock it even higher  -------------------- new fixed build with working lhr-unlock for linux uploaded https://github.com/sp-hash/TeamBlackMiner/releasesTeamBlackMiner_1_50_Ubuntu_18_04_Cuda_11_4_fixed.tar.xz https://www.virustotal.com/gui/file/3af45ac62fc80c2b214152424ffdfc690c7e3117689ada1bf4dc96713277c4e0?nocache=1 |
|
|
|
|
the lhr unlock is broken on linux, so I have to update the binaries
|
|
|
|
While waiting for the autotune, we have added Lost hashrate and Reset count to the LHR unlocker (v1.49) 00:11:35 [2022-02-03 11:28:42.432] GPU3 LHR: 42.51 Mh (max:57.20 Mh, Lost:0.75 Mh, Reset Count:47)
Here is the RTX 3070 LHR on default lhr unlock settings. in 11.5 hours, lhr has been detected 47 times. Loosing around 0.75MHASH in average on the period. 42.51 - 0.75 = 41.75MHASH effective. To increase the hashrate you can add values to the --lhr-unlock parameter, but you risk to increase the reset count and lose hash. |
|
|
|
 Big improvement to the rejected share count in v1.49 on the hiveon pool and other pools that use the ethproxy protocol.. So I attempted to run the miner version 1.49 with just one of my AMD cards using the --cl-devices - and the miner started generating something like 64 GPUs worth of DAG buffers, killed the machine and I'm trying to get it to reboot but HiveOS is taking forever to come back -- well it finally just came back online. Also, if I use the --amd-only flag,
Don't use --cl-devices together with --amd-only you end up having duplicated threads on the same device. I had a crash at startup on one of my rigs with high intensity on rx 570 cards. (ethereum classic) The program found alot of solutions that where rejected, and got trown off the pool. Investegating.. it will use all the cards and ignore any limits in the --cl-devices [ , ] flag; is that expected behaviour?
yes |
|
|
|
|
Refresh the download page. I rebuilt with 1.49
|
|
|
|
v1.49 should have no issues with mixed card rigs now. Got 500 accepted shares and no rejects in the testrig on the hivos.com pool. So the Ethproxy protocol pools seems to be fixed. So, now my peaks are getting washed out by the longer round time and the extra advantage seems to be disappearing (as witnessed by my much lower round % average).
If you run 2 instances of the miner, perhaps it helps to mine on the same workername? If a worker is unable to find a share in a round, might lower the pplns payouts? |
|
|
|
Any major LHR improvements since TBM v1.43?
I made attempts to get my 2x 3080 LHR's to a stable hash rate but have been unsuccessful since then.
yes. Many changes. It might trigger LHR in the beginning, but then stay stable. The autotune is not done yet, so hashrate on default settings are nerfed. The program calculate the reset count and hashrate lost because of the resets. On the 3070 I use 55% powerlimit, and on the 3080ti 70% |
|
|
|
always no temp, fan, core, mem, watt for RX5500XT windows.
yes, been like this for a long time. Working on a fix for stats on 5xxx and 6xxx cards. Perhaps in the next release. |
|
|
|
I was getting a lot of "the GPU is responding slowly" and it would stop accepting jobs for about 5-6 minutes before finally timing out the card.
I managed to reproduce this now on my mixed card rig with the AMD cards running on miningpoolhub with --xintensity 1024. Added logging and debug, and let it run over night. |
|
|
|
any updates? I have similar issue and reducing the intensities and also oc doesn't work on me, the time out event still coming back lol. With other miner it runs rock stable
Try the new version 1.48. My mixed card testrig with 7 cards. AMD / NVIDIA ran all night without any timeouts. and around +16MHASH faster poolside hash. |
|
|
|
00:17:27 [2022-01-25 08:17:42.682] GPU4 3090 CUDA 8 5801 26/0 0 0 0 336
00:17:27 [2022-01-25 08:17:42.682] GPU5 2060S CUDA 12 3000 27/0 85 1650 7950 115
Are you sure this is the 1.47 version? A bug was fixed in v1.45 that fix the memclock/coreclock on mixed rigs. but your rtx 3090 is 0. v1.48 will have some more output to console if the gpu is lagging. +less cpu usage, and LHR unlock support for the RTX 3050. The Nvidia solver is running with blocking sync, that might stop the cl code to perform optimal. |
|
|
|
Thanks!
What does --xintensity [-1] do?
It will dynamically allocate the workload to the gpu based on the hashrate. So it's a floating intensity and not a fixed one. |
|
|
|
I got a good result with TBM for more than 24 hours, but the GPU timed out in AMD GPU came back and makes the result poor again
From the picture it looks like your gpu has crashed. Both temps and power indicate that. Run with --no-ansi. and lower the memclock -10. High intensity might need a slightly lower clock to run stable. In the bug fixed, both power and temps where high when it timed out, which was not a real crash, but a glitch in the gpu test code. |
|
|
|
Thanks sp_
I will try this setup.
But stale shares are bad ? Why ? If they accepted by the pool (mph)
if you see in the Round Shares Submitted shares , you sometimes see stale shares. Level1 stales are payed fully, but lower lewels give a lower payout I think. On 2miners stale shares can give rejected shares, but you need a really high xintensity to trigger that. 8000 or more. |
|
|
|
What do you recommand for a 3080FE and 3090Fe on miningpoolhub ? (xintensity/tweak/kernel) Thanks
rtx 3090 --xintensity 3000 --kernel 1 or 12. Run the autotune a few times to verify. The best kernel depends on your power settings. rtx 3080 --xintensity 2500? --kernel 1 or 12. Run the autotune a few times to verify. The best kernel depends on your power settings. try without tweak first, if you get stale shares incease the tweak to 4 or more |
|
|
|
|
1.45 has a gpu timeout bug on AMD cards on high intensity. Upgrade to 1.47
|
|
|
|
I can't understand: if dag verification fail, it's mean a hardware error here,
Is there have any meaning? The card could make a lot invalid shares, the hash rate of pool will be bad.
No. Because the dag creation is a heavy process for the gpu that fails on the highest clocks. To calculate the hash is an easier task. TBM can copy a working dag from another gpu, so you can increase the mem clock and still get 100% accepted shares. I have tested it on the 3070 and 2060 and it works. +200-300 mz stable the RTX 2060 went from 33MHASH to 35MHASH. (high xintensity on miningpoolhub) |
|
|
|
|
Show Posts
