Topic: [ANN] TeamRedMiner v0.10.10 - Ironfish/Kaspa/ZIL/Kawpow/Etchash and More - page 83. (Read 211877 times)

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

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?

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

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.

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

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

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

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.

create a batch file and name it

you can use this in the file

SHUTDOWN -r -t 10


watchdog="filename"

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

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.

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.


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?

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,

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?

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 ((

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 ?

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.

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

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.

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?