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.
Topic: [ANN] TeamRedMiner v0.10.10 - Ironfish/Kaspa/ZIL/Kawpow/Etchash and More - page 82. (Read 211877 times)
April 23, 2019, 09:31:47 PM
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.
April 23, 2019, 07:20:03 PM
Why is the following error message appearing?
"error code: -l low difficulty share"
"error code: -l low difficulty share"
Wrong algo selected maybe?
Did you copy an old .bat file to the new miner version
April 23, 2019, 06: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
My rig run SRBminer Xcash is perfect not error with same setting MSI.i tried with 4 rig and got same problem
April 23, 2019, 05:30:41 PM
Why is the following error message appearing?
"error code: -l low difficulty share"
"error code: -l low difficulty share"
April 23, 2019, 04: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
April 23, 2019, 08:50:17 AM
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...
April 23, 2019, 08:38:11 AM
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.
April 23, 2019, 08:14:34 AM
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.
April 23, 2019, 07:10:11 AM
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?
April 23, 2019, 06: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.
April 23, 2019, 05: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
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.
April 23, 2019, 05: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.
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!
April 22, 2019, 08:26:32 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
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
April 22, 2019, 05: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
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
. April 22, 2019, 04: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://bitcointalksearch.org/topic/m.50391527) 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?
April 22, 2019, 04: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
April 22, 2019, 03: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)
April 22, 2019, 03: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.)
April 22, 2019, 03:03:23 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
April 22, 2019, 02:55:19 PM
The second thing is even weird:
This is my PPT for my Vega 64:
P0->p6 core are disable and P0->P2 mem too and for the last state I use 875mV but when I check HWinfo when mining voltage is still around 895 mV.
Look like it use the higher voltage of disable state when running.
So I try to change my PPT by using 820mV for all state except the last one for core and mem.
I keep the exact same P7 core and P3 mem but my card is reporting dead almost one min after starting to mine.
Any explanation ?
This is my PPT for my Vega 64:
P0->p6 core are disable and P0->P2 mem too and for the last state I use 875mV but when I check HWinfo when mining voltage is still around 895 mV.
Look like it use the higher voltage of disable state when running.
So I try to change my PPT by using 820mV for all state except the last one for core and mem.
I keep the exact same P7 core and P3 mem but my card is reporting dead almost one min after starting to mine.
Any explanation ?
Thanks so much for the answer , for the bad pool hashrate I just reinstalled 18.6.1 drivers , now seems to be ok . Didn't know what happens.
For the PPT , I checked all my rig ( all running at 895 mV for the good one ) even when I set up 850 mV Core P7 And Mem P3.
When I try to lower voltage for CORE P4 and above I get a crash everytime ( vega 56 and vega 64).
Two ideas : I just lost silicon lotery for all card or my PPT are really bad.
Running drivers 18.6.1
Soc Clock : 1107 ( VEga 64 and 56)
I cannot use mem timing , too much increase in heat and consumption.
I will try to test other PPT.
I’m betting the issue w/ being stuck @ 900mv is due to you having set p0 @ 900. Even though you have lower states locked out in ODNT, you would already be at 900 in your idle state, before ODNT is ever involved. This may very well prevent you from ever going lower.
Best practice is to have voltages in PPT be coded as a floor - this allows it to serve its purpose (removing the uv barrier,) while staying out of the way otherwise. Your idea of setting 820 across the board except for top states is moving in the right direction (though I believe default p0 is actually 800, so 820 is still high.). As for why that approach causes crashes - only thing I can think is that 900 has been a threshold voltage for 1200 SOC in my exp. Are you sure you’re running 1107 SOC? As in, that’s what’s reported in hwinfo under load?
Yeah P0 was 900mV in my PPT , I cannot check with hwinfo because my rig crash I use it when mining. But I checked with the excel generator and for 1107 SOC and I have the same value in my PPT.
I will try 850mV PPT from ingyenfrag (Page 67) to see is there is any change
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
Jump to: