pbfarmer
Member
Offline
Activity: 340
Merit: 29
|
|
April 22, 2019, 08:14:22 PM |
|
What about when you run every state @ 900? What does hwinfo say about SOC in that case? Or are you sayin opening hwinfo while mining causes a crash? If so, try running hwinfo first
When I run every state @900 it's working (for almost all card execpte bad ones 4/22) and hwinfo is reporting 895mV, 1107 SOC Ok - one other possibility... somewhere between the TRM implementation, and newer versions of drivers, I feel like I’ve seen instances of transitional states lighting up long enough for voltage settings to actually matter. It’s possible you’re crashing during the p4-p5 transition going from 800 to 1107, as 820mv may be too low (or something like that.) Try setting either a more graduated voltage list, or set every state to your final voltage (I would suggest the former, in keeping w/ the PPT as floor concept.)
|
|
|
|
carlosmonaco
Newbie
Offline
Activity: 105
Merit: 0
|
|
April 22, 2019, 08:30:49 PM |
|
What about when you run every state @ 900? What does hwinfo say about SOC in that case? Or are you sayin opening hwinfo while mining causes a crash? If so, try running hwinfo first
When I run every state @900 it's working (for almost all card execpte bad ones 4/22) and hwinfo is reporting 895mV, 1107 SOC Ok - one other possibility... somewhere between the TRM implementation, and newer versions of drivers, I feel like I’ve seen instances of transitional states lighting up long enough for voltage settings to actually matter. It’s possible you’re crashing during the p4-p5 transition going from 800 to 1107, as 820mv may be too low (or something like that.) Try setting either a more graduated voltage list, or set every state to your final voltage (I would suggest the former, in keeping w/ the PPT as floor concept.) Ok I will try this , I just reinstall 18.6.1 on my test RIG ( 1 Vega 64 and 4 vega 56/64bios) (Most of them are bad card). I Used 850mV PPT from page 67: Name=VEGA 64 GPU_P0=852;800;0 GPU_P1=991;810;0 GPU_P2=1084;820;0 GPU_P3=1138;830;0 GPU_P4=1150;840;0 GPU_P5=1202;850;0 GPU_P6=1212;850;0 GPU_P7=1408;850 Mem_P0=167;800;0 Mem_P1=500;800;0 Mem_P2=800;820;0 Mem_P3=1100;850 Fan_Min=400 Fan_Max=3200 Fan_Target=65 Fan_Acoustic=2400 Power_Temp=80 Power_Target=0 and for memory timing I use : VEga 56/64bios : --i 2,3,4,5 --CL 20 --RP 11 --RC 44 --RCDRD 12 --RCDWR 8 --RFC 250 --FAW 20 --RRDS 4 --RRDL 4 --RAS 32 --REF 7800 Vega 64 --i 1 --RAS 32 --RCDRD 12 --RCDWR 5 --RC 44 --RP 12 --REF 15600 I will try to stabilize the rig ( most of them cannot handle 1100 mem) and let you know. Thanks for helping me ( I'm trying my best ) (and sorry for my english)
|
|
|
|
pbfarmer
Member
Offline
Activity: 340
Merit: 29
|
|
April 22, 2019, 09:23:29 PM |
|
What about when you run every state @ 900? What does hwinfo say about SOC in that case? Or are you sayin opening hwinfo while mining causes a crash? If so, try running hwinfo first
When I run every state @900 it's working (for almost all card execpte bad ones 4/22) and hwinfo is reporting 895mV, 1107 SOC Ok - one other possibility... somewhere between the TRM implementation, and newer versions of drivers, I feel like I’ve seen instances of transitional states lighting up long enough for voltage settings to actually matter. It’s possible you’re crashing during the p4-p5 transition going from 800 to 1107, as 820mv may be too low (or something like that.) Try setting either a more graduated voltage list, or set every state to your final voltage (I would suggest the former, in keeping w/ the PPT as floor concept.) Ok I will try this , I just reinstall 18.6.1 on my test RIG ( 1 Vega 64 and 4 vega 56/64bios) (Most of them are bad card). I Used 850mV PPT from page 67: Name=VEGA 64 GPU_P0=852;800;0 GPU_P1=991;810;0 GPU_P2=1084;820;0 GPU_P3=1138;830;0 GPU_P4=1150;840;0 GPU_P5=1202;850;0 GPU_P6=1212;850;0 GPU_P7=1408;850 Mem_P0=167;800;0 Mem_P1=500;800;0 Mem_P2=800;820;0 Mem_P3=1100;850 Fan_Min=400 Fan_Max=3200 Fan_Target=65 Fan_Acoustic=2400 Power_Temp=80 Power_Target=0 and for memory timing I use : VEga 56/64bios : --i 2,3,4,5 --CL 20 --RP 11 --RC 44 --RCDRD 12 --RCDWR 8 --RFC 250 --FAW 20 --RRDS 4 --RRDL 4 --RAS 32 --REF 7800 Vega 64 --i 1 --RAS 32 --RCDRD 12 --RCDWR 5 --RC 44 --RP 12 --REF 15600 I will try to stabilize the rig ( most of them cannot handle 1100 mem) and let you know. Thanks for helping me ( I'm trying my best ) (and sorry for my english) That looks reasonable. I might suggest trying that PPT without the timings first, just to make sure your cards are stable at those clocks/voltages - prob for at least 12 hours. Once confirmed stable, add the timings. Your english is fine - didn't even notice
|
|
|
|
kerney666
Member
Offline
Activity: 658
Merit: 86
|
|
April 22, 2019, 09:58:35 PM |
|
It uses less power (5-10%), but it's not faster.
What's the point of your repeated broad and general bs statements like the one above and your repeated JCE shills in this thread? The statement above is just so dumb. Have you even tried to do a hashrate test normalized to the same power draw by tweaking core clk for a more fair comparison, since max hashrate seems to be the thing you care about? Your last attempt ( https://bitcointalk.org/index.php?topic=5059817.msg50391527#msg50391527) with the fantastic quote "JCE CN GPU miner is still faster then." after hearing about a single problematic CN-turtle rig of NCarter84 is also awesome. I mean, for THAT specific algo, we still only sit comfortably at +15% above any other miner on all Vegas, albeit not the same edge on Polaris cards, but hey, of course it's proof that JCE is the fastest CN miner across the board. Seriously?
|
|
|
|
kerney666
Member
Offline
Activity: 658
Merit: 86
|
|
April 22, 2019, 10:03:33 PM |
|
I still cannot understand why heavy algo's have not been implemented. Perhaps it already exist and is used in private like Bitmain does with their Asics Just kidding It's actually a valid question, we should have nailed the 4MB variants a long time ago! And, I really wish we had some 3.5 kh/s private heavy kernel, but no .
|
|
|
|
Mashy81
Jr. Member
Offline
Activity: 225
Merit: 1
|
|
April 23, 2019, 01:26:32 AM |
|
I still cannot understand why heavy algo's have not been implemented. Perhaps it already exist and is used in private like Bitmain does with their Asics Just kidding It's actually a valid question, we should have nailed the 4MB variants a long time ago! And, I really wish we had some 3.5 kh/s private heavy kernel, but no . 3.0 kh/s is not to shabby. Doesn't have to be 3.5 Any teasers on the performance on your heavy implementation? Will we see 15% increase on the current first place holder
|
|
|
|
SamAlackass
Newbie
Offline
Activity: 27
Merit: 1
|
|
April 23, 2019, 10:01:38 AM |
|
Since later drivers (>= 19.2.x or so) are using a different approach with a fan curve instead of a single target temp, I'm guessing they don't care about the old classic target temp in the PPT. It's not by random chance that the target temp is missing in the ODNT beta that supports these drivers. The implementation of the fan curve is also f-ing horrible, there is no interpolation with smooth fan rpm increase, it's like they only switch hard between two adjacent points on the curve. This is for 19.2.2 though, might have improved in later versions?
Sorry - was thinking more of older versions. Don’t have much exp w/ windows since 19.2. Based on what @kerney666 said, it sounds to me like fan support is actually broken in later drivers. Like you, I’ve always found target temp to work perfectly in the past, but wattman still provided working fan curve support for those inclined.
Seems like the new fan curve impl has borked a number of things.
Thank you both, the only reason I thought about updating was an issue with AMDMemoryTweak that seems unrelated now anyway so I'll be sticking with what works best. I still have a system where it works and one where it doesn't, both on 18.6.1. I know 18.6.1 is confirmed working but I thought it could be driver related because I don't even get any readings with --current. I read there is an update coming though so... fingers crossed!
|
|
|
|
kerney666
Member
Offline
Activity: 658
Merit: 86
|
|
April 23, 2019, 10:14:42 AM |
|
I still cannot understand why heavy algo's have not been implemented. Perhaps it already exist and is used in private like Bitmain does with their Asics Just kidding It's actually a valid question, we should have nailed the 4MB variants a long time ago! And, I really wish we had some 3.5 kh/s private heavy kernel, but no . 3.0 kh/s is not to shabby. Doesn't have to be 3.5 Any teasers on the performance on your heavy implementation? Will we see 15% increase on the current first place holder Haha, sorry to disappoint but realistically that will _not_ happen. Will let you know as soon as we have any indicative numbers.
|
|
|
|
JuanHungLo
|
|
April 23, 2019, 11:16:21 AM |
|
What about when you run every state @ 900? What does hwinfo say about SOC in that case? Or are you sayin opening hwinfo while mining causes a crash? If so, try running hwinfo first
When I run every state @900 it's working (for almost all card execpte bad ones 4/22) and hwinfo is reporting 895mV, 1107 SOC Ok - one other possibility... somewhere between the TRM implementation, and newer versions of drivers, I feel like I’ve seen instances of transitional states lighting up long enough for voltage settings to actually matter. It’s possible you’re crashing during the p4-p5 transition going from 800 to 1107, as 820mv may be too low (or something like that.) Try setting either a more graduated voltage list, or set every state to your final voltage (I would suggest the former, in keeping w/ the PPT as floor concept.) I don't know if this will help, but on some of my Sapphire Radeon RX VEGA 56 8GB if I set Memory P2 below 850 with PP, the card either won't start mining or shut down properly, I have found 880 to work nearly always, there is one "problem child" that requires 900. Of course, YMMV.
|
Bull markets are born on pessimism, grow on skepticism, mature on optimism, and die on euphoria. - John Templeton
|
|
|
akvilon888
Newbie
Offline
Activity: 19
Merit: 0
|
|
April 23, 2019, 12:10:11 PM |
|
hi, what command i have to use to restart miner if some gpu failed ?
create a batch file and name it you can use this in the file SHUTDOWN -r -t 10 watchdog="filename" as i understand it will reboot my rig, not miner ? how can i restart only trm if some gpu dies?
|
|
|
|
kerney666
Member
Offline
Activity: 658
Merit: 86
|
|
April 23, 2019, 01:14:34 PM |
|
hi, what command i have to use to restart miner if some gpu failed ?
create a batch file and name it you can use this in the file SHUTDOWN -r -t 10 watchdog="filename" as i understand it will reboot my rig, not miner ? how can i restart only trm if some gpu dies? The problem is that the driver might be in a corrupt state, and the miner can't shut down cleanly. On my own rigs, I need to reboot anyway in 99% of these cases. That said, my experience is that the win driver(s) recover somewhat better for Polaris cards. If you know you'll get a clean shutdown and always can just restart the miner, I would define a watchdog.bat file in your miner dir that (1) sleeps for 20 secs or so, (2) runs your normal startup procedure (resets clocks for all gpus, start the miner, etc). Last, you also need to add the command line arg --watchdog_script when starting the miner. The procedure when a dead GPU is detected is that the miner will both execute your watchdog script and then shut down. The 20 sec sleep in your watchdog should catch any unexpected wait times during the miner exit.
|
|
|
|
MaxHa$h
Newbie
Offline
Activity: 37
Merit: 0
|
|
April 23, 2019, 01:38:11 PM |
|
hi, what command i have to use to restart miner if some gpu failed ?
create a batch file and name it you can use this in the file SHUTDOWN -r -t 10 watchdog="filename" as i understand it will reboot my rig, not miner ? how can i restart only trm if some gpu dies? The problem is that the driver might be in a corrupt state, and the miner can't shut down cleanly. On my own rigs, I need to reboot anyway in 99% of these cases. That said, my experience is that the win driver(s) recover somewhat better for Polaris cards. If you know you'll get a clean shutdown and always can just restart the miner, I would define a watchdog.bat file in your miner dir that (1) sleeps for 20 secs or so, (2) runs your normal startup procedure (resets clocks for all gpus, start the miner, etc). Last, you also need to add the command line arg --watchdog_script when starting the miner. The procedure when a dead GPU is detected is that the miner will both execute your watchdog script and then shut down. The 20 sec sleep in your watchdog should catch any unexpected wait times during the miner exit. sorry for not placing the correct command line argument "--watchdog_script". I was going off memory as i wrote them months ago, and was using my mobile to reply. Thank you for the 20 sec recommendation, i will update the scripts from 10 to 20.
|
|
|
|
akvilon888
Newbie
Offline
Activity: 19
Merit: 0
|
|
April 23, 2019, 01:50:17 PM |
|
hi, what command i have to use to restart miner if some gpu failed ?
create a batch file and name it you can use this in the file SHUTDOWN -r -t 10 watchdog="filename" as i understand it will reboot my rig, not miner ? how can i restart only trm if some gpu dies? The problem is that the driver might be in a corrupt state, and the miner can't shut down cleanly. On my own rigs, I need to reboot anyway in 99% of these cases. That said, my experience is that the win driver(s) recover somewhat better for Polaris cards. If you know you'll get a clean shutdown and always can just restart the miner, I would define a watchdog.bat file in your miner dir that (1) sleeps for 20 secs or so, (2) runs your normal startup procedure (resets clocks for all gpus, start the miner, etc). Last, you also need to add the command line arg --watchdog_script when starting the miner. The procedure when a dead GPU is detected is that the miner will both execute your watchdog script and then shut down. The 20 sec sleep in your watchdog should catch any unexpected wait times during the miner exit. dont know why, but after some time one of gpu's dies, it is always fifth cards, and i just close trm and start again, and it starts to mine normaly, but then it happens again after some time...( cant understand why...
|
|
|
|
Mashy81
Jr. Member
Offline
Activity: 225
Merit: 1
|
|
April 23, 2019, 09:22:39 PM |
|
hi, what command i have to use to restart miner if some gpu failed ?
create a batch file and name it you can use this in the file SHUTDOWN -r -t 10 watchdog="filename" as i understand it will reboot my rig, not miner ? how can i restart only trm if some gpu dies? The problem is that the driver might be in a corrupt state, and the miner can't shut down cleanly. On my own rigs, I need to reboot anyway in 99% of these cases. That said, my experience is that the win driver(s) recover somewhat better for Polaris cards. If you know you'll get a clean shutdown and always can just restart the miner, I would define a watchdog.bat file in your miner dir that (1) sleeps for 20 secs or so, (2) runs your normal startup procedure (resets clocks for all gpus, start the miner, etc). Last, you also need to add the command line arg --watchdog_script when starting the miner. The procedure when a dead GPU is detected is that the miner will both execute your watchdog script and then shut down. The 20 sec sleep in your watchdog should catch any unexpected wait times during the miner exit. dont know why, but after some time one of gpu's dies, it is always fifth cards, and i just close trm and start again, and it starts to mine normaly, but then it happens again after some time...( cant understand why... Lower your clocks on that 1 card or change your memory tweak settings if using. Not all cards are the same when pushed close to the edge
|
|
|
|
wei0339
Newbie
Offline
Activity: 12
Merit: 1
|
|
April 23, 2019, 10:30:41 PM |
|
Why is the following error message appearing?
"error code: -l low difficulty share"
|
|
|
|
lttsi
Newbie
Offline
Activity: 25
Merit: 0
|
|
April 23, 2019, 11:44:28 PM |
|
I got a big problem ,my Rig 6x 570 rx 4g run Cryptonight Turtle is perfect but when is change CryptonightXcash ,frist Card gpu0 (gpu is pcie x16) when star x-cash speed is normal ~480h/s but after 5s speed is slow down and got a 100h-200h/s. My rig run SRBminer Xcash is perfect not error with same setting MSI.i tried with 4 rig and got same problem
|
|
|
|
Mashy81
Jr. Member
Offline
Activity: 225
Merit: 1
|
|
April 24, 2019, 12:20:03 AM |
|
Why is the following error message appearing?
"error code: -l low difficulty share"
Wrong algo selected maybe? Did you copy an old .bat file to the new miner version
|
|
|
|
vmozara
Member
Offline
Activity: 190
Merit: 59
|
|
April 24, 2019, 02:31:47 AM |
|
It uses less power (5-10%), but it's not faster.
I liked JCE miner but what you tell here is complete FUD. Even JCE himself said that TRM is so good that there is no point for him to continue development.
|
|
|
|
kristikun
Newbie
Offline
Activity: 62
Merit: 0
|
|
April 24, 2019, 08:48:12 AM |
|
Hello , im looking for some kind soul who could help me set memory timings on my rig (5x vega 56 flashed to 64, helia ppt and 1 WC vega 64), I am willing to pay Btc/eth/dash/monero 1 time for assistance over teamviewer or sumthing.. PM : : kristikun@gmail.com
|
|
|
|
|
|