[ANN] TeamRedMiner v0.10.10 - Ironfish/Kaspa/ZIL/Kawpow/Etchash and More

[Mashy81]

Best I can get efficiency to is 10.7hs per Watt. 
I might have to go linux..

[1714770460]

1714770460

[1714770460]

1714770460

[1714770460]

1714770460

[1714770460]

1714770460

[1714770460]

1714770460

[SamAlackass]

FYI, I completed an evaluation between win10 driver 18.6.1 vs 19.4.2. Found no hashrate/power draw difference with TRM 0.4.4 miner. Evaluated on CNR algo only.

Still using ODNT? How do you set your fan speeds? IIRC there is no target temp in the beta version.

I tested a few 19.x drivers recently, on a 3x vega 56 rig, TRM 0.4.2 (also CNR only) and came to the same conclusion. Didn't have enough time to play with ODNT, but it felt weird having to spend time tweaking fan speeds. Target temp has been a set and forget kind of thing for me so...      

You can set your target temp in PPT...

Vega (hex short, byteswapped -- e.g. "1c,00" => 0x001c => 0d28):

https://i.imgur.com/8JhCNwRm.png

Polaris (hex char -- e.g. "28" => 0x28 => 0d40):

https://i.imgur.com/bOfHlhDm.png

Thank you for that!! It seems to be working! Your posts have always been immensely helpful.

I can't try the beta ODNT right now as I'm currently on old drivers and it's crashing so, am I right to assume the fan speed section can still be disabled in beta?

Np - happy to help.  I don't know about disabling, but ODNT just reads the value from PPT, so you shouldnt need to worry about it, unless you want to change it.

It doesn't seem to be reading it from PPT, I just double checked to make sure. Apparently it just defaults to 75 no matter what value I set in PPT. So unless the fan section can still be disabled in newer ODNT versions, it will just override whatever is set in PPT apparently.

[carlosmonaco]

When I was looking how to decrease consumption I found two things really weird.

One of my rig is reporting a huge diference between reported hashrate and pool hashrate . ( No hw error etc..)
https://imgur.com/a/In6q2S4
There is no error and there is 2 kh/s between pool hashrate and reported hashrate.

The second thing is even weird:

This is my PPT for my Vega 64:
https://imgur.com/a/NTuNGjT

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 ?

[rednoW]

Are we going to see heavy (heaven) algo support in TeamRed? Current implementation of SRBminer is poor compute-wise optimized and needs high gpu clocks and a lot of power ((

[kerney666]

FYI, I completed an evaluation between win10 driver 18.6.1 vs 19.4.2. Found no hashrate/power draw difference with TRM 0.4.4 miner. Evaluated on CNR algo only.

Still using ODNT? How do you set your fan speeds? IIRC there is no target temp in the beta version.

I tested a few 19.x drivers recently, on a 3x vega 56 rig, TRM 0.4.2 (also CNR only) and came to the same conclusion. Didn't have enough time to play with ODNT, but it felt weird having to spend time tweaking fan speeds. Target temp has been a set and forget kind of thing for me so...      

You can set your target temp in PPT...

Vega (hex short, byteswapped -- e.g. "1c,00" => 0x001c => 0d28):



Polaris (hex char -- e.g. "28" => 0x28 => 0d40):

Thank you for that!! It seems to be working! Your posts have always been immensely helpful.

I can't try the beta ODNT right now as I'm currently on old drivers and it's crashing so, am I right to assume the fan speed section can still be disabled in beta?

Np - happy to help.  I don't know about disabling, but ODNT just reads the value from PPT, so you shouldnt need to worry about it, unless you want to change it.

It doesn't seem to be reading it from PPT, I just double checked to make sure. Apparently it just defaults to 75 no matter what value I set in PPT. So unless the fan section can still be disabled in newer ODNT versions, it will just override whatever is set in PPT apparently.

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?

[kerney666]

Hello prompt how to include a single-threaded mode, in readme read that it is necessary to use a configuration Y+0, but I tried various combinations (--cn_config=Y+0,L16+16,16+16,16+16,L16+16,L16+16) but the miner gives an error, tell me what I'm doing wrong. As the card which is inserted in X16 irrespective of dispersal and intensity gives out HW errors, I thought can the single-threaded mode will be able to solve my problem.

Just replace Y (intensity) with a value. --cn_config=16+0 for example.

Thanks

Also replace +  with  *  not all card like 16*16. My best value is 16*14

16+16 is always a bad idea, it would use 8GB for pads. I hate that the drivers allow it, I'm guessing they are actually spilling using host-side mem mapped over PCIe,

[kerney666]

When I was looking how to decrease consumption I found two things really weird.

One of my rig is reporting a huge diference between reported hashrate and pool hashrate . ( No hw error etc..)

There is no error and there is 2 kh/s between pool hashrate and reported hashrate.

Miner vs poolside testing is a b*tch, and I dedicated the last section of the CN_MAX_YOUR_VEGA.txt guide in the 0.4.4 release to it. That said, your numbers are way off, this should happen in <= 0.07% of all cases _if you were running at a static diff_. Since you aren't, it's really difficult to reason about if this is a "normal outlier" that happens every 100th run, or that it more or less proves that something clearly is off.

Drilling deeper and looking at each gpu, two of your cards look a little fishy at 1480 h/s poolside, but we have way too little data to assert anything on a per-gpu basis. So, please run a xmrig-proxy test as decribed in the guide for e.g. 50k shares total and you should have the data you need - it might be that those two cards are not doing great at the current clocks and/or timing mods, and it should be clearly visible with that higher amount of shares. We're doing tons and tons of testing ourselves to make sure we hit the poolside hashrate, I'd love to get more user data here, but it must be from runs that I know I can trust from a statistical standpoint.

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 ?

Newer drivers often seem to lock P7 core+P3 mem during load to not be too aggressive with switching p-states.

For the PPT itself, this is an artform. Don't be fooled by the view in ODNT. The only thing that exists is a single vdd lookup table which is _shared_ by core and mem states. ODNT fools you into believing that you can separate voltage settings for e.g. core P4 from mem P3, which isn't true unless you do some serious PPT tweaking. I'm not 100% it's possible even then.

To simplify your tests, I'd either (1) use the same target voltage for ALL core and mem states in your PPT or (2) make sure all core and mem states have increasing voltage levels in respective series and also that core P4 voltage == mem P3 voltage and that it matches your target.

I'm not 100% sure what happens in your tests. Maybe mem P3 is rather grabbed from core P4, so in your first test you get 900 mV (~= 895 mV), and in your second test you get 820 mV which is way too low to handle sustained pressure?

[kerney666]

Are we going to see heavy (heaven) algo support in TeamRed? Current implementation of SRBminer is poor compute-wise optimized and needs high gpu clocks and a lot of power ((

Yeah, should have been done already. I'm away for Easter, then I'll hit CNv7 Lite, then probably the 4MB variants that still are active.

[akvilon888]

hi, what command i have to use to restart miner if some gpu failed ?

[MaxHa$h]

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"

[carlosmonaco]

When I was looking how to decrease consumption I found two things really weird.

One of my rig is reporting a huge diference between reported hashrate and pool hashrate . ( No hw error etc..)
https://imgur.com/a/In6q2S4
There is no error and there is 2 kh/s between pool hashrate and reported hashrate.

Miner vs poolside testing is a b*tch, and I dedicated the last section of the CN_MAX_YOUR_VEGA.txt guide in the 0.4.4 release to it. That said, your numbers are way off, this should happen in <= 0.07% of all cases _if you were running at a static diff_. Since you aren't, it's really difficult to reason about if this is a "normal outlier" that happens every 100th run, or that it more or less proves that something clearly is off.

Drilling deeper and looking at each gpu, two of your cards look a little fishy at 1480 h/s poolside, but we have way too little data to assert anything on a per-gpu basis. So, please run a xmrig-proxy test as decribed in the guide for e.g. 50k shares total and you should have the data you need - it might be that those two cards are not doing great at the current clocks and/or timing mods, and it should be clearly visible with that higher amount of shares. We're doing tons and tons of testing ourselves to make sure we hit the poolside hashrate, I'd love to get more user data here, but it must be from runs that I know I can trust from a statistical standpoint.

The second thing is even weird:

This is my PPT for my Vega 64:
https://imgur.com/a/NTuNGjT

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 ?

Newer drivers often seem to lock P7 core+P3 mem during load to not be too aggressive with switching p-states.

For the PPT itself, this is an artform. Don't be fooled by the view in ODNT. The only thing that exists is a single vdd lookup table which is _shared_ by core and mem states. ODNT fools you into believing that you can separate voltage settings for e.g. core P4 from mem P3, which isn't true unless you do some serious PPT tweaking. I'm not 100% it's possible even then.

To simplify your tests, I'd either (1) use the same target voltage for ALL core and mem states in your PPT or (2) make sure all core and mem states have increasing voltage levels in respective series and also that core P4 voltage == mem P3 voltage and that it matches your target.

I'm not 100% sure what happens in your tests. Maybe mem P3 is rather grabbed from core P4, so in your first test you get 900 mV (~= 895 mV), and in your second test you get 820 mV which is way too low to handle sustained pressure?

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.

[Iamtutut]

Are we going to see heavy (heaven) algo support in TeamRed? Current implementation of SRBminer is poor compute-wise optimized and needs high gpu clocks and a lot of power ((

If you want to mine Haven, just use JCE CN miner. Although the development has stopped, Heavy algos work very fine with it.

[Mashy81]

Are we going to see heavy (heaven) algo support in TeamRed? Current implementation of SRBminer is poor compute-wise optimized and needs high gpu clocks and a lot of power ((

If you want to mine Haven, just use JCE CN miner. Although the development has stopped, Heavy algos work very fine with it.

I too am eager to try TRM heavy as every CN they have implemented has been a big advance on other soffware

[Iamtutut]

It uses less power (5-10%), but it's not faster.

[pbfarmer]

FYI, I completed an evaluation between win10 driver 18.6.1 vs 19.4.2. Found no hashrate/power draw difference with TRM 0.4.4 miner. Evaluated on CNR algo only.

Still using ODNT? How do you set your fan speeds? IIRC there is no target temp in the beta version.

I tested a few 19.x drivers recently, on a 3x vega 56 rig, TRM 0.4.2 (also CNR only) and came to the same conclusion. Didn't have enough time to play with ODNT, but it felt weird having to spend time tweaking fan speeds. Target temp has been a set and forget kind of thing for me so...     

You can set your target temp in PPT...

Vega (hex short, byteswapped -- e.g. "1c,00" => 0x001c => 0d28):



Polaris (hex char -- e.g. "28" => 0x28 => 0d40):

Thank you for that!! It seems to be working! Your posts have always been immensely helpful.

I can't try the beta ODNT right now as I'm currently on old drivers and it's crashing so, am I right to assume the fan speed section can still be disabled in beta?

Np - happy to help.  I don't know about disabling, but ODNT just reads the value from PPT, so you shouldnt need to worry about it, unless you want to change it.

It doesn't seem to be reading it from PPT, I just double checked to make sure. Apparently it just defaults to 75 no matter what value I set in PPT. So unless the fan section can still be disabled in newer ODNT versions, it will just override whatever is set in PPT apparently.

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.

[fluxy12]

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

[pbfarmer]

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 ?

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?

[carlosmonaco]

The second thing is even weird:

This is my PPT for my Vega 64:
https://imgur.com/a/NTuNGjT

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

[pbfarmer]

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 ?

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

[carlosmonaco]

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