trexminer / T-Rex

T-Rex NVIDIA GPU miner with web control monitoring page
2.64k stars 439 forks source link

lhr unlock 100 #991

Open thumerman opened 2 years ago

thumerman commented 2 years ago

Hi, my video card unexpectedly unlocked when I decided to lower the memory frequency a little, after a reboot everything went off. How can this be explained. 3060

edmarssil commented 2 years ago

what oc?

Faltskog commented 2 years ago

Did you just low-key broke the LHR?

thumerman commented 2 years ago

pl 55 core 0 memory (samsung) 1300 (it was 1500).

Crisis83 commented 2 years ago

An average share rate of 1.35 /share per minute (as in the screen shot) is about 97MH pool side so that checks out. When you say: "after a reboot everything went off", do you mean you can't replicate the hashrate on the 3060ti?

What Nvidia Driver are you using? Also is it possible you have an old-stock 3060ti which were non-LHR?

thumerman commented 2 years ago

Yes, that's right, I can't reproduce it. 497.09. No, this is a new rig, there is not even a month yet and the cards are all LHR.

Faltskog commented 2 years ago

Well, what about this? any news? no changes? did you restart your PC again and still got 100 LHR? or was once in a lifetime thing

basking-in-the-sun2000 commented 2 years ago

I noticed the same with a 3070. I've assumed it to be lhr, since it always worked around 74. Hadn't seen any values above 75 on most of my cards.

At first, I was very doubtful and thought it to be a display issue. However, it kept giving me more shares all the time. Eventually did see about 33% more than the ti card. I was able to restart the miner, and it worked fine. Did set lhr-tune to 100% and it stayed there. Unfortunately, had to restart the rig and the magic was lost. @Faltskog hope not, hopefully wasn't a once in a lifetime, nor a planetary alignment thing.

Before restarting the rig, I tried lowering the core frequency on a ti, but didn't work. The 3070 was mining at 61-62 Mh/s, but the ti didn't do any better than 45.

Thought it to be some glitch that allowed the card to reach 100%. Noticed a red mark on the farm view (on hive). Today I am getting invalid shares on hive (not the pool), but not seeing that red mark on the farm. Wanted to grab the logs, but the older ones had been rotated out.

https://forum.hiveos.farm/t/rtx-3070-settings/21260/486?u=painting


My driver is 495.44, and hive is current with latest versions of the miners (T-Rex v0.24.8)

edmarssil commented 2 years ago

What memory on your board? Samsung

basking-in-the-sun2000 commented 2 years ago

The hiveon link has several screenshots, including the one with the card data. It has samsung memory indeed

thumerman commented 2 years ago

This happened again, it works only on 1 video card where the Samsung memory is, it's not entirely clear what the memory has to do with it, because the lock works on the core. Procedure: 1. First launch without any settings. Control of lhr values. 2. Disabling autotune in the miner and mining on the obtained lhr values (I mined for 1 day). 3. Restart on default settings. 3060ti

edmarssil commented 2 years ago

do you use the direct oc on t rex? or MSI Afterburner

Faltskog commented 2 years ago

The other EVGA RTX 3060 Ti isn't Samsung?

basking-in-the-sun2000 commented 2 years ago

@thumerman that is interesting. Ran an experiment to try out your method. On the setup where I had seen this before, I could get the 3070 to go fhr. Restarted with all the cards (8 vs 5 from before) mining, but couldn't reproduce the unlocking.

Set the oc as high as I could without getting the rig to crash, and left it overnight. However, never got an invalid share, even when the 3070 used to get some at that oc (1140/2600). After 12h, I tried setting the 3070 to 100% but didn't take.

I'm back to the reduced energy mode (with only 5 cards of which 2 mine eth) and waiting for an invalid share to try this again. Two of my 3060 ti have hynix memory but had hoped another of the 5 cards would have worked with your finding.

Had it not happened to me before, I would have thought this was too crazy. Still think so, but there is something in this that seems to work.

thumerman commented 2 years ago

I use MSI Afterburner. Other EVGA with the memory of the Hynix.

AlbyGNinja commented 2 years ago

Procedure: 1. First launch without any settings. Control of lhr values. 2. Disabling autotune in the miner and mining on the obtained lhr values (I mined for 1 day). 3. Restart on default settings.

Excuse me, can you clarify a little bit? How to start? with or without OC settings? And what about the parameters? LHR-mode 100 need to be added inline or just use lhr-autotune 0 It's not fully clear sorry

edmarssil commented 2 years ago

Eu uso o MSI Afterburner. Outros EVGA com a memΓ³ria da Hynix.

Print oc?

basking-in-the-sun2000 commented 2 years ago

only got it to work once, but used on hive

"lhr-tune": "74,100" 
"lhr-autotune-mode": "off"

I had an invalid share earlier, but wasn't doing fhr. Finally got a second invalid share πŸ˜ƒ Used the extra lines as above. My guess is that the invalid shares trip something inside the gpu, which disable the lhr limits. Think it might be something like the fan glitch

@trexminer Could t-rex try 100 lhr whenever it detects an invalid share on a card 😈 , and dial down the memory clock if the 100 lhr worked

Mining at eth-us-west.flexpool.io:5555 [34.218.113.86], diff: 4.00 G
GPU #0: RTX 3060 Ti - 45.37 MH/s, [LHR 74.0]  [T:57C, P:112W, F:68%, E:401kH/W], 13/13 R:0% I:0%
GPU #3: RTX 3070    - 62.73 MH/s, [LHR 100.0] [T:56C, P:117W, F:55%, E:536kH/W], 11/11 R:0% I:0%
Hashrate: 108.10 MH/s, Shares/min: 1.985 (Avg. 1.688), Avg.P: 230W, Avg.E: 470kH/W
Max diff share was found by GPU #0, diff: 217.29 G
Uptime: 14 mins 33 secs | Algo: ethash | T-Rex v0.24.8
basking-in-the-sun2000 commented 2 years ago

Has been mining at fhr for the last 5h. The dips are zil minging?

Screen Shot 2022-01-19 at 01 07 46
AlbyGNinja commented 2 years ago

only got it to work once, but used on hive

"lhr-tune": "74,100" 
"lhr-autotune-mode": "off"

I had an invalid share earlier, but wasn't doing fhr. Finally got a second invalid share πŸ˜ƒ Used the extra lines as above. My guess is that the invalid shares trip something inside the gpu, which disable the lhr limits. Think it might be something like the fan glitch

@trexminer Could t-rex try 100 lhr whenever it detects an invalid share on a card 😈 , and dial down the memory clock if the 100 lhr worked

Mining at eth-us-west.flexpool.io:5555 [34.218.113.86], diff: 4.00 G
GPU #0: RTX 3060 Ti - 45.37 MH/s, [LHR 74.0]  [T:57C, P:112W, F:68%, E:401kH/W], 13/13 R:0% I:0%
GPU #3: RTX 3070    - 62.73 MH/s, [LHR 100.0] [T:56C, P:117W, F:55%, E:536kH/W], 11/11 R:0% I:0%
Hashrate: 108.10 MH/s, Shares/min: 1.985 (Avg. 1.688), Avg.P: 230W, Avg.E: 470kH/W
Max diff share was found by GPU #0, diff: 217.29 G
Uptime: 14 mins 33 secs | Algo: ethash | T-Rex v0.24.8

so just to fully understand: Did you follow the steps reported above from @thumerman ? So, mine without any specific parameter - start the miner with "lhr-autotune-mode" : "off" "lhr-tune": [value got in previous step] then you restarted with: "lhr-autotune-mode" : "off" "lhr-tune": 100

And it's mining at 100%??

basking-in-the-sun2000 commented 2 years ago

@AlbyGNinja lol wish it was that simple. First noticed this when my 3070 started increasing the lhr value by itself (see my hive post). Then found thumerman post, who showed me a way to get it to work again.

However, in my case, the trick was getting the card to do invalid shares, before setting the lhr to 100. I have been trying to get a 3060 ti to mine invalid shares, but I'm at 3000 with no success

Mind you that "lhr-tune": [value got in previous step] has to be found previously, to whatever value the card likes

AlbyGNinja commented 2 years ago

Mind you that "lhr-tune": [value got in previous step] has to be found previously, to whatever value the card likes

Because TONS of ppl with LHRs already knows their card optimal lhr value this is potentially skippable step imho.

the trick was getting the card to do invalid shares

so in your case you intentionally overclock the gpu too much to get invalids? after that what you do? you reduce overclock while LHR value is increasing?

basking-in-the-sun2000 commented 2 years ago

the trick was getting the card to do invalid shares

so in your case you intentionally overclock the gpu too much to get invalids? after that what you do? you reduce overclock while LHR value is increasing?

I change the flightsheet (assuming you are on hive 😁 ) and then lower the memory clock. If you are using t-rex manually, you would need to restart t-rex with the lhr at 100 for that card, and adjust the clock. My card has been mining for the last 7h, and have restarted the miners a couple of times. As long as I don't power off (or restart the rig??), the fhr ability isn't lost

Don't know if this is a glitch in the silicon, or the control for the lhr. Haven't been able to get any other card to reproduce this yet 🀞

AlbyGNinja commented 2 years ago

assuming you are on hive

I'm on windows so i assume i just need to close the cmd is mining and start different .bat file (?)

lower the memory clock

Is this step needed to get invalid? How much you are lowering? Are you lowering the clock WHILE mining until get invalid?

restart t-rex with the lhr at 100 for that card, and adjust the clock

Restart t-rex you mean, in addition to lhr-tune: 100, is lhr-autotune-mode: "off" required?

I stress that this seems to work only on samsung memory

Dekkarino commented 2 years ago

hi, i've a single 3060ti samsung lhr mining on windows with trex, I can try to replicate the glitch but need more information.

now i'm mining with this setting --lhr-tune 75.3 --lock-cclock 1380 --mclock 1025 --fan 70 --lhr-autotune-step-size 0.2 --lhr-autotune-interval 5 and not using msi afterburner

basking-in-the-sun2000 commented 2 years ago

assuming you are on hive

I'm on windows so i assume i just need to close the cmd is mining and start different .bat file (?)

sorry, I'm on linux and know nothing about windows. You will have to try it out

lower the memory clock

Is this step needed to get invalid? How much you are lowering? Are you lowering the clock WHILE mining until get invalid?

No, I lower the memory clock to avoid further invalids. I hate pushing my card so much, and the 3060 ti is already at 3300 (understand on windows this would be half that value), and no invalids yet. For the 3070 I raised the memory to 2700 and then lowered it to 2500

restart t-rex with the lhr at 100 for that card, and adjust the clock

Restart t-rex you mean, in addition to lhr-tune: 100, is lhr-autotune-mode: "off" required?

The lhr-autotune-mode: "off" is to prevent the lhr mechanism from reducing the lhr value. The first time my card got to 100, it did it by itself and started from 74. I had the mode at full, but if you don't have it at off, t-rex will try to find a value the card likes in case your card isn't going to do fhr (the 100 didn't take)

I stress that this seems to work only on samsung memory

Currently only have samsung cards active


the 3060 ti didn't like 3300 and crashed. The rig had to restart, and the magic is gone 😒

You will get GPU #3: LHR detected. 0.1min since last lock. Unlocking ... since card can't handle the lhr at 100 and the autotune is off. The best I get is now

GPU #3: RTX 3070 - 46.18 MH/s, [LHR 74.0] [T:53C, P:108W, F:53%, E:416kH/W], 2/2 R:0% I:0%

edmarssil commented 2 years ago

I did it on a 3060 LHR - I once got 45 mh but it returns to 35 mh but does not activate the LHR. Decreasing the cclock and increasing the LHR and as it was accepted I increased the cclock. I noticed that when I restarted the pc it accepted higher LHR. at the time it was no more than 75.5. 20220119_160714

Dekkarino commented 2 years ago

I did it on a 3060 LHR - I once got 45 mh but it returns to 35 mh but does not activate the LHR. Decreasing the cclock and increasing the LHR and as it was accepted I increased the cclock. I noticed that when I restarted the pc it accepted higher LHR. at the time it was no more than 75.5. 20220119_160714

how you did it ? it's replicable? normally I've lhr 73,1 with 43 44 mhs

MOCO-MHz commented 2 years ago

@basking-in-the-sun2000 or anyone, have you been able to replicate this in windows?

If so we are keen to understand how. The idea is that we enhance our software (https://youtu.be/rfgHEE5komM) (https://github.com/MOCO-MHz) to systematically do 100 up after detecting an invalid LHR trip.

AlbyGNinja commented 2 years ago

@basking-in-the-sun2000 or anyone, have you been able to replicate this in windows?

If so we are keen to understand how. The idea is that we enhance our software (https://youtu.be/rfgHEE5komM) (https://github.com/MOCO-MHz) to systematically do 100 up after detecting an invalid LHR trip.

clearly shitposting -.-'

MOCO-MHz commented 2 years ago

@basking-in-the-sun2000 or anyone, have you been able to replicate this in windows? If so we are keen to understand how. The idea is that we enhance our software (https://youtu.be/rfgHEE5komM) (https://github.com/MOCO-MHz) to systematically do 100 up after detecting an invalid LHR trip.

clearly shitposting -.-'

@AlbyGNinja thanks for the feedback. Unfortunately we are unsure about how that comment can help us better our software.

AlbyGNinja commented 2 years ago

@basking-in-the-sun2000 or anyone, have you been able to replicate this in windows? If so we are keen to understand how. The idea is that we enhance our software (https://youtu.be/rfgHEE5komM) (https://github.com/MOCO-MHz) to systematically do 100 up after detecting an invalid LHR trip.

clearly shitposting -.-'

@AlbyGNinja thanks for the feedback. Unfortunately we are unsure about how that comment can help us better our software.

Yeah well, I'm not sure how your post is helpful here neither.

basking-in-the-sun2000 commented 2 years ago

Been trying to repeat the feat with no luck. After those initial successes, not even the 3070 has gone fhr. Finally got two invalid shares, but didn't work.

Had high hopes that invalid shares would trigger this since nothing else made sense. Seeing @thumerman post was very encouraging, since it meant someone else had done this.

It wasn't so much using a lower core speed to get a few extra lhr points, it went all the way to 100%. Wished it worked more consistently, not only on a planetary conjunctions

basking-in-the-sun2000 commented 2 years ago

This is going to sound even crazier than reaching 100% lhr. Was thinking what was different, and recalled I had another 2 miners on my flightsheet (lolminer, and xmrig)

Added them to my config, and it started mining at 76 (had limited to prevent taking too long). Restarted at 100% and has been mining fine for 10m. Not sure if this might be related to having less gpu on t-rex or having the other 2 miners.

Unless my rig crashes overnight, will try to take a look at it tomorrow 🀞

If there is any files that might help point to what is going on, let me know

@thumerman did you had another miner or process?

Mining at eth-us-west.flexpool.io:4444 [34.218.113.86], diff: 4.00 G                                                                     
GPU #2: RTX 3060 - 34.86 MH/s, [LHR 78.0<>]  [T:53C, P: 91W, F:30%, E:375kH/W], 10/10 R:0% I:0%
GPU #3: RTX 3070 - 62.37 MH/s, [LHR 100.0<>] [T:56C, P:116W, F:54%, E:538kH/W], 9/9 R:0% I:0%
Hashrate: 97.23 MH/s, Shares/min: 1.899 (Avg. 1.818), Avg.P: 209W, Avg.E: 465kH/W                                                        
Max diff share was found by GPU #2, diff: 666.23 G                                                                                       
Uptime: 11 mins 1 sec | Algo: ethash | T-Rex v0.24.8                                                                                     
GPU #2: [LHR 80.0<>] intensity 21                                                                                      
conn1: ethash epoch: 468, block: 14054353, diff: 4.00 G                                                                
GPU #3: [LHR 100.0<>] intensity 21.3                                                                                   
conn1: ethash epoch: 468, block: 14054354, diff: 4.00 G                                                                
GPU #3: generating DAG 4.66 GB for epoch 468 ...                                                                       
conn1: ethash epoch: 468, block: 14054355, diff: 4.00 G                                                                
GPU #3: DAG generated [crc: e72e18d1, time: 15295 ms], memory left: 2.98 GB                                            
GPU #2: generating DAG 4.66 GB for epoch 468 ...                                                                       
GPU #3: using kernel #4                                                                                                
GPU #3: target hashrate for unlocker - 52.04 MH/s                                                                      
GPU #2: DAG generated [crc: e72e18d1, time: 18669 ms], memory left: 7.00 GB                                            
GPU #2: using kernel #4                                                                                                
GPU #2: target hashrate for unlocker - 33.56 MH/s                                                                      
GPU #2: LHR detected. 0.8min since last lock. Unlocking ...                                                            
conn1: ethash epoch: 468, block: 14054356, diff: 4.00 G                                                                
conn1: ethash epoch: 468, block: 14054357, diff: 4.00 G                                                                
conn1: ethash epoch: 468, block: 14054358, diff: 4.00 G                                                                
ethash [ OK ] 1/1 - 64.85 MH/s, 74ms ... GPU #3 | 4.15 G                                                               
jemshit commented 2 years ago

@basking-in-the-sun2000 any update, i tried two different miners (trex + pheonix + xmr (for cpu)), started with locked LHR-74, restarted with locked LHR-100 (without getting invalid share), no luck

basking-in-the-sun2000 commented 2 years ago

had some issues and my rig shut down. Restarted, but haven't reached fhr. Has been running very stable ☹️ lol, and just got a couple of invalid shares. However, fhr didn't take. Wish there was a way to get the cards to reach that without having to wait. Is there a way to an overflow error or something that would be equivalent to invalid shares?

Will try to use nvidia-bug-report.sh to see if there is anything noticeable between when it works and not.

basking-in-the-sun2000 commented 2 years ago

Seems my rig just likes to make fun of me 😦

Just got another invalid share, and it started doing fhr again. Took a while, but had to raise the memory to 2700

I checked the nvidia-bug-report.sh, but besides t-rex using a bit more memory than the other cards (Used 5005 MB on a 3070), I didn't see anything significant. Didn't decode the base64 sections.

Think this is over my pay grade, since I tried everything I could think of, and nothing makes sense. I deleted all the other miners and still mines at 100%.

Even thought maybe my card was fhr, the box has an lhr label. Not sure if you need the other miners to start the fhr, or a certain fault to occur.

basking-in-the-sun2000 commented 2 years ago

thought maybe the magic would break if I changed miner since it would initialize the card differently. I tried gminer, but didn't get it to work. Lolminer (no config) and nbminer (needed lhr values) worked.

After that, I went back to t-rex, and still works. If anyone has any idea to figure out how to trigger this, I can give it a try. Unfortunately, will have to shut down tonight.

lolminer

-------------------------------------------- 
Statistics (18:47:30); Mining: Ethash 
Connected to: eth-us-west.flexpool.io:4444 
Uptime: 0h 15m 1s 
      Name         Speed    Pool  --lhrtune  Shares    Best  Power
                    MH/s    MH/s             A/S/Hw   Share      W
GPU 0 RTX 3060 Ti  42.70   39.96       29.4   9/0/0   92.1G   61.6
GPU 1 RTX 3060     31.58   22.20       68.0   5/0/0   16.2G   91.1
GPU 2 RTX 3060     32.64   17.76       67.4   4/0/0   13.2G   93.0
GPU 3 RX 6700XT    46.17   31.08        0.0   7/0/0  128.0G   86.7
GPU 4 RTX 3070     61.33   71.03        0.0  16/0/0   31.6G  116.6
--------------------------- 
Total             214.43  182.02             41/0/0  128.0G  449.0

          Eff.  CCLK  MCLK  Core  Junc   Mem  Fan  --lhrtune
        MH/s/W   MHz   MHz  Temp  Temp  Temp  Pct           
GPU 0    0.687  1380  8100    51  n.a.  n.a.   63       29.4
GPU 1    0.345  1350  8425    55  n.a.  n.a.   51       68.0
GPU 2    0.349  1320  8400    54  n.a.  n.a.   30       67.4
GPU 3    0.530  1150  1074    39    46    60   44        0.0
GPU 4    0.524  1140  8050    56  n.a.  n.a.   54        0.0
--------------------------- 
Total    0.475                                              
--------------------------------------------- 

nbminer

NFO - ===================== [nbminer v40.1] Summary  =====================                               
INFO - |ID|Device|Hashrate| LHR|Accept|Reject|Inv|Powr|CTmp|MTmp|Fan|CClk|GMClk|MUtl|Eff/Watt|                               
INFO - | 0|3060ti| 45.12 M|  74|     3|     0|  0| 111|  57|    | 68|1380| 8100| 100| 406.5 K|                               
INFO - | 1|  3060| 30.39 M|  74|     2|     0|  0|  87|  57|    | 51|1350| 8425| 100| 349.3 K|                               
INFO - | 2|  3060| 25.88 M|    |     0|     0|  0|  78|  48|    | 30|1320| 8400|  65| 331.7 K|                               
INFO - | 3|6700xt| 46.80 M|    |     1|     0|  0|  88|  40|    | 46|1150| 1074|  45| 531.8 K|                               
INFO - | 4|  3070| 61.87 M|    |     7|     0|  0| 115|  58|    | 50|1140| 8050| 100| 538.0 K|                               
INFO - |------------------+----+------+------+---+----+--------------------------------------|                               
INFO - |    Total: 210.0 M|    |    13|     0|  0| 479| Uptime:  0D 00:04:00        CPU:  3% |                               
INFO - =======================================================================================                               

and obviously t-rex again

Mining at eth-us-west.flexpool.io:4444 [34.218.113.86], diff: 4.00 G                                                                    
GPU #0: RTX 3060 Ti - 45.87 MH/s, [LHR 75.5<>]  [T:55C, P:117W, F:67%, E:410kH/W]
GPU #1: RTX 3060    - 31.58 MH/s, [LHR 77.0<>]  [T:57C, P: 88W, F:51%, E:351kH/W], 1/1 R:0% I:0%
GPU #2: RTX 3060    - 32.62 MH/s, [LHR 77.5<>]  [T:50C, P: 88W, F:31%, E:362kH/W], 2/2 R:0% I:0%
GPU #3: RTX 3070    - 61.93 MH/s, [LHR 100.0<>] [T:56C, P:117W, F:54%, E:534kH/W], 3/3 R:0% I:0%
Hashrate: 172.00 MH/s, Shares/min: 1.507 (Avg. 1.434), Avg.P: 408W, Avg.E: 422kH/W                                                      
Max diff share was found by GPU #3, diff: 24.89 G                                                                                       
Uptime: 4 mins 31 secs | Algo: ethash | T-Rex v0.24.8     
basking-in-the-sun2000 commented 2 years ago

Just found a difference between my 3070 and all the other cards. Not sure if this might be related, but seems to be memory clock dependent. I wanted to see if I could get it to trigger with another miner. Trying out lolminer, since it required no setup. The 3070 gave an error that none of the other cards did

GPU 4: DAG generation completed (4876 ms)
GPU 4: DAG verification detected 1194 defect segment(s)
GPU 4: DAG repair will be started. This may take a moment.
GPU 4: starting smart DAG repair
GPU 4: smart DAG repair done 
GPU 4: DAG verification passed
GPU 4: GPU will be paused to make sure it is unlocked... 

In case anyone was wondering, the lhr value is 17.2 unlike 0 before

t-rex reported a invalid shares a couple of times, but wasn't enough for fhr

AlbyGNinja commented 2 years ago

but seems to be memory clock dependent

Do you mean the 100% unlock or getting the invalid share?

Just to understand more precisely, with t-rex, what are the miner configurations before and after invalid?

basking-in-the-sun2000 commented 2 years ago

but seems to be memory clock dependent

Do you mean the 100% unlock or getting the invalid share?

Just to understand more precisely, with t-rex, what are the miner configurations before and after invalid?

it is clock-dependent to get a damaged dag table. If I lower the memory clock it doesn't happen. Since this is the only obvious difference between the 3070 and the other cards, I have found. After some occurrence (fault?), something in the card gets altered, which allows for fhr.

The only changes, once the card goes into fhr is to raise the lhr value to 100. This is for the expediency sake since otherwise, it can take 12h to reach 100%. Of course, this assumes the lhr mode is set to full (the default). The other is to lower the memory clock, to prevent a crash.

This isn't something related to the miner per se, since lolminer and nbminer were able to achieve 100% lhr. Something in the card triggers, and unless you restart, that condition doesn't change with most changes you do. Seems that changing the miner doesn't reinitialize the cards, only launches a process in the gpu. To get to fhr, seems to violate one of the main rules I knew about mining, such as not overclocking too aggressively the memory.

As I said before, this is beyond me, since I never dealt with gpus before. I have been poking at anything I can think of, trying to find a difference. The only thing is there is some fault that triggers the card into fhr, and might need some other factor to start mining in that mode. Could also have been a coincidence that it started after changing the flightsheet.

Wish there was something that would allow you to try different fault conditions. It is very erratic and sometimes doesn't get triggered for days. Sometimes I get an invalid share but doesn't trigger fhr. Don't know what conditions t-rex ven considers as invalid shares, since the pool doesn't see them

iGio90 commented 2 years ago

reading all of this discussion and umh. I have no clue if there is documentation around about someone reverse enginered how the LHR lock happens, but from what I can read here it looks like they are measuring the timings / number of calls to ethash involved function. Rising the mem clock to stars would make those functions being invoked a crazy amount of time and if the lock that follows is a percent of reduction calculated from that time variable, there you go with FHR because the lock is set higher. Just speculation, but could make sense.. :D i have 4x 308ti, 3x 3060 and 1x 3060ti to play with :beers:

Edit: i'm otherwise sure that if it was enough to rise mem clock to the hell, make it mine for a while and then restore to a proper oc, it would be already public everywhere

basking-in-the-sun2000 commented 2 years ago

i'm otherwise sure that if it was enough to rise mem clock to the hell, make it mine for a while and then restore to a proper oc, it would be already public everywhere

Never thought it was to rise the mem clock to make it fhr, rather to a way to get the card to go into an overflow, overrun, etc. condition that triggered something in the card. However, as you said just that shouldn't be enough. I've been waiting all week for fhr, and after a couple of invalid shares a day nothing yet ☹️


Just posted this, and started mining at 100%. I had tried different flightsheets whenever I noticed a couple of invalid shares, without success. Any ideas how to check what changed in the card?

Faltskog commented 2 years ago

reading all of this discussion and umh. I have no clue if there is documentation around about someone reverse enginered how the LHR lock happens, but from what I can read here it looks like they are measuring the timings / number of calls to ethash involved function. Rising the mem clock to stars would make those functions being invoked a crazy amount of time and if the lock that follows is a percent of reduction calculated from that time variable, there you go with FHR because the lock is set higher. Just speculation, but could make sense.. :D i have 4x 308ti, 3x 3060 and 1x 3060ti to play with 🍻

Edit: i'm otherwise sure that if it was enough to rise mem clock to the hell, make it mine for a while and then restore to a proper oc, it would be already public everywhere

I really thought that was for termal throttle issue, i have a twin (2x) Gigabyte 3080Ti ViSiON OC, but one of them tends to "suffer" a little more of temp issues than the other, when passes 60ctemp/90mtemp, it start to drop from 90 to 88/87ish mh/s, but when it start to drop the temp to 86mtemp or below it goes back up to 90/91mh/s and often (not a rule) hits a LHR when that happens, and so on. I personally think that has a couple of different layers of thermal throttling temps, there's permissible ones, and then has to have a terminating thermal temperature like hitting 115-120 memory temp and shut down, but i think no one reverse enginered thermal throttling.

Maybe tthrottling + timings of ethash like you said could be?

iGio90 commented 2 years ago

reading all of this discussion and umh. I have no clue if there is documentation around about someone reverse enginered how the LHR lock happens, but from what I can read here it looks like they are measuring the timings / number of calls to ethash involved function. Rising the mem clock to stars would make those functions being invoked a crazy amount of time and if the lock that follows is a percent of reduction calculated from that time variable, there you go with FHR because the lock is set higher. Just speculation, but could make sense.. :D i have 4x 308ti, 3x 3060 and 1x 3060ti to play with 🍻 Edit: i'm otherwise sure that if it was enough to rise mem clock to the hell, make it mine for a while and then restore to a proper oc, it would be already public everywhere

I really thought that was for termal throttle issue, i have a twin (2x) Gigabyte 3080Ti ViSiON OC, but one of them tends to "suffer" a little more of temp issues than the other, when passes 60ctemp/90mtemp, it start to drop from 90 to 88/87ish mh/s, but when it start to drop the temp to 86mtemp or below it goes back up to 90/91mh/s and often (not a rule) hits a LHR when that happens, and so on. I personally think that has a couple of different layers of thermal throttling temps, there's permissible ones, and then has to have a terminating thermal temperature like hitting 115-120 memory temp and shut down, but i think no one reverse enginered thermal throttling.

Maybe tthrottling + timings of ethash like you said could be?

Negative. I had this too on a 3080. You have to replace thermal pads and paste if it hit thermal (reduce oc has a temporary solution)

Faltskog commented 2 years ago

reading all of this discussion and umh. I have no clue if there is documentation around about someone reverse enginered how the LHR lock happens, but from what I can read here it looks like they are measuring the timings / number of calls to ethash involved function. Rising the mem clock to stars would make those functions being invoked a crazy amount of time and if the lock that follows is a percent of reduction calculated from that time variable, there you go with FHR because the lock is set higher. Just speculation, but could make sense.. :D i have 4x 308ti, 3x 3060 and 1x 3060ti to play with 🍻 Edit: i'm otherwise sure that if it was enough to rise mem clock to the hell, make it mine for a while and then restore to a proper oc, it would be already public everywhere

I really thought that was for termal throttle issue, i have a twin (2x) Gigabyte 3080Ti ViSiON OC, but one of them tends to "suffer" a little more of temp issues than the other, when passes 60ctemp/90mtemp, it start to drop from 90 to 88/87ish mh/s, but when it start to drop the temp to 86mtemp or below it goes back up to 90/91mh/s and often (not a rule) hits a LHR when that happens, and so on. I personally think that has a couple of different layers of thermal throttling temps, there's permissible ones, and then has to have a terminating thermal temperature like hitting 115-120 memory temp and shut down, but i think no one reverse enginered thermal throttling. Maybe tthrottling + timings of ethash like you said could be?

Negative. I had this too on a 3080. You have to replace thermal pads and paste if it hit thermal (reduce oc has a temporary solution)

But how the other one has the same temperatures and doesn't suffer from drops of hashrate?

IN FACT, the one that doesn't seem to suffer temperature, has more tolerance on memory temp, it goes up to 92/94mtemp and still hits 92 and even 93mh/s

Faltskog commented 2 years ago

272216365_324772889569847_3365880689087418004_n

Faltskog commented 2 years ago

GPU #0 always struggles to reach above 90mh/s, 2 or 3 of 5 intervals, hits 90 as you see in the photo above, while GPU #1 always stays above 90.

jemshit commented 2 years ago

GPU #0 always struggles to reach above 90mh/s, 2 or 3 of 5 intervals, hits 90 as you see in the photo above, while GPU #1 always stays above 90.

Each card is different, even if they have same brand/model/vram. They might require different OC settings. Also above one is doing better in terms of shares

zhanko73 commented 2 years ago

@Faltskog What are the settings for 90 MH/s on 3080Ti?

AlbyGNinja commented 2 years ago

@Faltskog What are the settings for 90 MH/s on 3080Ti?

Easy: Absolute core clock: 1140 Mem clock: +1300/1500 (windows) +2600/3000 (hiveos) No power limit