 Show Posts
|
|
Pages: [1] 2 3 4 »
|
Which cards? 3060ti LHR3 unlocks with -85
--lhr-unlock [-85]
10GB 3080 LHR |
|
|
|
v1.61 is looking good. One testrig has been running for 48 hours on the hiveon.com pool with more than 10000 accepted and no rejected shares.
Any LHR updates for the latest releases? I still cannot get my LHR hashrates to stabilize even after trying all the recommended values you provided in previous posts. |
|
|
|
|
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.
|
|
|
|
That sounds like sp__ is back!  ))))) I would love resolution as then i would just have to switch to your miner without tweaking any cards instead of tweaking 5 rigs with multiple 3070s. Luckily my son has 3070 on this gaming machine so i test here. I will create a cache of the dag buffer on file. On every new epoc, one of the cards in the rig needs to be able to create the dag buffer. And if the validation fails for the other cards, the program will read from file. Will use around 5GB of harddrive space, but no need to reduce the clocks. I'm testing 1.45 on HIVE OS. At the start, the hashrate results on the pool and shares are good, I use cuda 11.4 Nvd driv. 470.94 , --kernel 1, --xintensity 1988 , cclock 1311. The miner still gives a dag generation error on rigs 3060 - 3070 . I continue the test. I noticed that your miner works fine for the first 24 hours, but then the speed slows down, the hashrate on the pool becomes smaller, maybe this is due to Hive OS and cuda 11.4 You should do more tests under HIVE OS, more than 24 hours.  I've done some analysis based on the shares per minute as at-pool hashrate and: *The miner stabilizes at around the 70 minute mark and remains fairly stable until at about the 300 minute mark, the miner performance begins to degrade after this. At the 430 minute mark, the degradation levels off and remains relatively constant until around the 500 minute mark where it degrades again until about the 600 minute mark where it remained stable / slightly increasing until the end of the sample dat at 780 minutes. It seems that for whatever reason, the first 60 minutes sees the most improvement and the highest share/minute production after it peaks decreases significantly to the 70 minute mark where it stabilizes until the 300 minute mark. yes, at the start it is very fast, but then the same LoL miner overtakes it and gives a more stable hashrate. The developer needs to conduct detailed tests for more than a day to stabilize his work while I return to LoL To be fair, at the end of my 780 minute (13 hour) run, the median/mean hashrate for my 3090 was 181/182 MH/s with a STD.Dev of +/- 10 MH/s, so I'm not complaining. I ran the test for more than a day and my hash dropped from 1345 to 1275 in the miner in about 27-28 hours. The pool averaged 1.26 gh/s over 6 hours Do you experience this behavior on other miner software or just TBM? |
|
|
|
Any recommendation for a xitensity value on the LHR cards as a starting point?
If it fails to unlock at 1 reduce to -1, -2 etc. If it unlocks stable at 1 increase the number to 2, 3,4 to increase the speed. LHR cards are tricky, and takes a while to find the correct clock setting / LHR setting. I am trying that now. How long should I run each test before changing to the next value? |
|
|
|
Should I try negative values this time?
Yes negative values are supported. The LHR docs are not updated to the later version. My GTX 3070 LHR works best with -4. Thanks. Any recommendation for a xitensity value on the LHR cards as a starting point? |
|
|
|
Added 2x 3080 LHRs to my setup and was hoping to get a stable hash rate on the cards.
Any tips or options to add as a starting point?
On windows I use 75% powerlimit and low coreclock as possible on the 3080ti. No need to lock the clock. If the card fail to unlock try with -1, -2, -3, -4 ... etc until it's stable. --lhr-unlock [-1,-1,0,0,0,0] On the Options page, the supported values for LHR-unlock is either 1 (Unlock Mode) or 0 (Normal Mode).  Should I try negative values this time? |
|
|
|
Added 2x 3080 LHRs to my setup and was hoping to get a stable hash rate on the cards. Any tips or options to add as a starting point? Current Options/Settings --lhr-unlock 1 --lock-cclock [[1500,1500]] --xitensity 2048 Memory Clock: 1000 (2000 if HiveOS) P0 State enabled. I am currently on TBM 1.42 (CUDA 11.4) with Nvidia GPU driver CUDA 11.5.  |
|
|
|
Have you tried any other xintensity values for MPH that worked best for your setup?
yes. --xintensity 4096 move the rig up to 115 (+5) mhash and poolside 113 ish. on 1.30 and nvidia 497.09 windows 10 let's try --xintensity [5120] --tweak [7] --kernel [6] on 2miners running at P0 = ON and the latest final MSI AB (i find memclock improve from +1200 (MSI beta version) to +1500 (MSI final version)). https://ibb.co/DkzmZ9RHave you tried these settings on MiningPoolHub? |
|
|
|
1.29 and 1.30 hash about 2MH/s slower than 1.28 on my RTX 3080 (Non LHR) 497.09, at least the reported hashrate is lower.
Increase the --xintensity to 284 (old default) to get back the 2MH/s or more. This miner works best on high diff and high intensity, but some pools works better on low intensity. Here is v1.29 been running on --xintensity 144 for ~2.5 days Old testrig with broken cards.  Have you tried any other xintensity values for MPH that worked best for your setup? |
|
|
|
Hello. Do you have 1.37 for Windows?
Also interested in 1.37 for Windows as well too! |
|
|
|
Currently seeing VARDIFF instead of DIFF for Difficulty value in 1.29.  Is this correct? |
|
|
|
Currently on TBM 1.28 and I notice that GPU solution duration time has increased significantly.  Thoughts? |
|
|
|
I have tried testing on other miner software such as GMiner and T-Rex. After three + hours or so, I either get 1-2% rejected shares or the miner software ends up crashing.
Well, if you had problems on those rock solid miners there is something wrong with your setup/OC. I won't disagree with you on that. I'll probably need to spend more time troubleshooting/modifying my OC settings that would adhere stability to each individual miner software. |
|
|
|
Is there any benefit in adding the dagintensity value if mining on miningpoolhub?
The point of the --dagintensity 1 is to avoid crash on dag creation on high clockrates. You can oc the memory +100-200 or more with this setting on, but the dag generation will be slower. So not good in eth-zil mining. In v1.28 we will do an adjustemnt to the dag creation with --dagintensity and make it slower. Thanks for the explanation. I am setting the dagintensity value to "9", is that considered too high of a number? Also, I don't understand why I see so many negative posts about your miner software. I have tried testing on other miner software such as GMiner and T-Rex. After three + hours or so, I either get 1-2% rejected shares or the miner software ends up crashing. Plus your level of support within the thread is top notch so you can't beat that! Please keep up the great work.  |
|
|
|
|
Is there any benefit in adding the dagintensity value if mining on miningpoolhub?
|
|
|
|
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.
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?  |
|
|
|
Are high intensity values still recommended when using Nvidia Cards on either MPH or 2Miners? Currently running xintensity 2048 on MPH as of yesterday… |
|
|
|
Are there any settings I can modify to increase the number of submitted accepted shares on 2Miners?
you can save some power run as admin --lock-cclock [[1200,1200],[1200,1200],[1200,1200],[1200,1200],[1200,1200],[1200,1200]] I’m actually going to switch back to miningpoolhub and see if my earnings are higher than 2Miners. Is xintensity 4096 still good for that pool? |
|
|
|
Do you think that with lower --xintensity I have better pool hashrate?
Only if you get stale shares. Click on the worker on the pool and check for stales  Are there any settings I can modify to increase the number of submitted accepted shares on 2Miners? |
|
|
|
|
