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

[kerney666]

@kerney666

What does it mean to have the "hw" code triggered for a GPU? My Radeon VII GPU is having almost a 40% "hw" triggering even though the pool is still accepting its share. However, the poolside hashrate for the card is very low. I am using TRM 0.5.2 and running my GPU @1575cclk/975mclk/855mV.

Any ideas what is happening and how to fix this?

Yo Bro
try to play with your clocks and votag and see which one is best for your GPU.
HW means hardware error and it shows that your GPU is not doing well.
40% HW error means you are losing 40% of your hashrate. try to increse your voltage and see if it can fix or not, and be careful to not break your GPU increase bit by bit.

Hi!

+1 for bumping voltage. My experience is that the VIIs react with hw errs when they're starved on voltage, V64/56 and Polaris cards typically crash outright instead. I can't run my VII at 855mV at your clocks, it would produce bad hashes just like for you. I do know other VII owners that are just fine at the same levels though, so silicon lottery/ymmv/etc. Try raising it +5-10mV at the time and observe the error rate. Also, make sure your fan curve is set to provide adequate cooling.

[alexcrys1]

Can confirm, TRM works awesome with MetaMiner!

I'm using it on this pool & getting great results.
mpsc.xripx.com

hi, u can share coinfig? thx

[ku4eto]

@kerney666

What does it mean to have the "hw" code triggered for a GPU? My Radeon VII GPU is having almost a 40% "hw" triggering even though the pool is still accepting its share. However, the poolside hashrate for the card is very low. I am using TRM 0.5.2 and running my GPU @1575cclk/975mclk/855mV.

Any ideas what is happening and how to fix this?

Yo Bro
try to play with your clocks and votag and see which one is best for your GPU.
HW means hardware error and it shows that your GPU is not doing well.
40% HW error means you are losing 40% of your hashrate. try to increse your voltage and see if it can fix or not, and be careful to not break your GPU increase bit by bit.

Hi!

+1 for bumping voltage. My experience is that the VIIs react with hw errs when they're starved on voltage, V64/56 and Polaris cards typically crash outright instead. I can't run my VII at 855mV at your clocks, it would produce bad hashes just like for you. I do know other VII owners that are just fine at the same levels though, so silicon lottery/ymmv/etc. Try raising it +5-10mV at the time and observe the error rate. Also, make sure your fan curve is set to provide adequate cooling.

Actually, with my Polaris cards, if the voltage is just a tad lower than needed, it will throw HWs. A 1-2 step increase is enough to fix it.

[frozen80]

@kerney666

What does it mean to have the "hw" code triggered for a GPU? My Radeon VII GPU is having almost a 40% "hw" triggering even though the pool is still accepting its share. However, the poolside hashrate for the card is very low. I am using TRM 0.5.2 and running my GPU @1575cclk/975mclk/855mV.

Any ideas what is happening and how to fix this?

Can you share your hashrate,power draw and stable settings. Did you manage to solve your "hw" errors problem? I'm also interested to buy one and I'm curious with the power draw and the temperatures. Also does it come with Samsung memory?

[seefatlow]

@kerney666

What does it mean to have the "hw" code triggered for a GPU? My Radeon VII GPU is having almost a 40% "hw" triggering even though the pool is still accepting its share. However, the poolside hashrate for the card is very low. I am using TRM 0.5.2 and running my GPU @1575cclk/975mclk/855mV.

Any ideas what is happening and how to fix this?

Can you share your hashrate,power draw and stable settings. Did you manage to solve your "hw" errors problem? I'm also interested to buy one and I'm curious with the power draw and the temperatures. Also does it come with Samsung memory?

Yes, managed to solve the "hw" error by increasing the voltage by 10mV. Current hashrate is at 2.9kh/s for CNR using the following settings - 1565 core/985 mem/865mV. Power at the wall is 190W. Mine card is Hynix. I read it comes with Samsung memory as well but the hashrate isn't better than a Hynix.

[fmz89]

@kerney666

What does it mean to have the "hw" code triggered for a GPU? My Radeon VII GPU is having almost a 40% "hw" triggering even though the pool is still accepting its share. However, the poolside hashrate for the card is very low. I am using TRM 0.5.2 and running my GPU @1575cclk/975mclk/855mV.

Any ideas what is happening and how to fix this?

Can you share your hashrate,power draw and stable settings. Did you manage to solve your "hw" errors problem? I'm also interested to buy one and I'm curious with the power draw and the temperatures. Also does it come with Samsung memory?

Lowering you mem clock, then hw error will gone

[fmz89]

What I am awaiting the most is Random X for AMD CPUs and APUs.

Randomx is mean for cpu not for gpu, you can still mine with gpu, but the ratio is 3:1 perfomance on the same power, vega need switch to other algo after xmr implement randomx

[kerney666]

What I am awaiting the most is Random X for AMD CPUs and APUs.

Randomx is mean for cpu not for gpu, you can still mine with gpu, but the ratio is 3:1 perfomance on the same power, vega need switch to other algo after xmr implement randomx

To be fair, he did ask for RandomX for CPUs and APUs though .

To answer that original question: we don't really shy away from doing hardcore x86 asm projects, but it doesn't really fit the TRM context. There is plenty of gpu work left to be done, so at this point we'll rather focus on expanding the potential deployment opportunities for AMD GPUs rather than follow the RandomX trail to CPUs.

[Pennywis3]

So no plans to support RandomX on GPU's? That's a lot of customers down the drain  

[kerney666]

So no plans to support RandomX on GPU's? That's a lot of customers down the drain  

I hear you, but like I've stated a nr of times now, without a proper static analysis resulting in a theoretical design that we know will run profitably on AMD GPUs, there is nothing that can justify spending the enormous amount of implementation time necessary here. Spending 2+ months on an implementation of something that earns 25% of a decent Ryzen CPU is clearly suboptimal use of our time. And, note that the available CPU benchmarks for RandomX are based on the available proof of concept code. It's not bad, but if anything, CPU performance will increase over time. As an indicative comparison, SCernykh threw what he could at the problem with AMD GCN asm and on-gpu program compilation and ended up with 1100 h/s on his Vega 64, this compared to the listed benchmark for a Ryzen 7 1700 at 4100 h/s.

So if this hasn't been clear already from the specs for RandomX, ongoing Reddit discussions etc: for all gpu miners who still believe you'll be mining XMR after the October fork, the odds are stacked heavily against you. The nrs and comments the RandomX people for some reason are putting out for GPUs are completely irrelevant, measuring their performance as a pct of their CN/r hashrate. Who cares if a Nvidia gpu (which is useless for CN/r to begin with) can produce roughly the same hashrate after the fork when a CPU increases its hashrate 7-10x? 

[Azzgard1980]

Hi guys, is there an option to run "run_autotune_full" with the initial given intensity, I am immediately offered on the heavy algorithm, 16+14, and kills the driver if I force prescribe in *.Bat" file 14+14 then works.... how to run "run_autotune_full" from 14+14 ? Sorry for English, it's Google

[Iamtutut]

What I am awaiting the most is Random X for AMD CPUs and APUs.

Randomx is mean for cpu not for gpu, you can still mine with gpu, but the ratio is 3:1 perfomance on the same power, vega need switch to other algo after xmr implement randomx

To be fair, he did ask for RandomX for CPUs and APUs though .

To answer that original question: we don't really shy away from doing hardcore x86 asm projects, but it doesn't really fit the TRM context. There is plenty of gpu work left to be done, so at this point we'll rather focus on expanding the potential deployment opportunities for AMD GPUs rather than follow the RandomX trail to CPUs.

Exactly. Use of the CPU part of AMD APUs and full power of their CPUs.

Seriously Kerney666, should you release a Random X CPU miner, you'll get lots of fees

[fmz89]

After random x you can compete with other guy who have access to server, like long time ago when xmr mine cpu only, no profit can make for small miner at home even you had threadripper 64 core, monero become more centralized, the profit its on early day after hf

[SigiSinatra]

https://i.ibb.co/CBrmSXB/01.png


Does this mean that I'll mine forever at reduced hashrate if miner can't connect to devs pool or if there is some error in dev-poll connection?

[seefatlow]

So no plans to support RandomX on GPU's? That's a lot of customers down the drain  

I hear you, but like I've stated a nr of times now, without a proper static analysis resulting in a theoretical design that we know will run profitably on AMD GPUs, there is nothing that can justify spending the enormous amount of implementation time necessary here. Spending 2+ months on an implementation of something that earns 25% of a decent Ryzen CPU is clearly suboptimal use of our time. And, note that the available CPU benchmarks for RandomX are based on the available proof of concept code. It's not bad, but if anything, CPU performance will increase over time. As an indicative comparison, SCernykh threw what he could at the problem with AMD GCN asm and on-gpu program compilation and ended up with 1100 h/s on his Vega 64, this compared to the listed benchmark for a Ryzen 7 1700 at 4100 h/s.

So if this hasn't been clear already from the specs for RandomX, ongoing Reddit discussions etc: for all gpu miners who still believe you'll be mining XMR after the October fork, the odds are stacked heavily against you. The nrs and comments the RandomX people for some reason are putting out for GPUs are completely irrelevant, measuring their performance as a pct of their CN/r hashrate. Who cares if a Nvidia gpu (which is useless for CN/r to begin with) can produce roughly the same hashrate after the fork when a CPU increases its hashrate 7-10x? 

@Kerney666

Honestly, TRM will not be complete without LiteV7 and CCX variant. At least, work on these 2 algos first before venturing into other profitable algos like Cuckaroo29/CuckooCycle.

Also, what do you think of GCN chances of overthrowing Green Team's dominance over Zhash algos? Can this be done?

[fmz89]

Threadripper 64 core releaae on September, so will be considering to try one, for random x its should be the king

[Iamtutut]

Threadripper 64 core releaae on September, so will be considering to try one, for random x its should be the king

Won't AMD release a new chipset for the new TRs ? They also should go PCI-E 4.0

[kkkwww]

I can not find ... how to specify backup pools in TPM?

[kerney666]

I can not find ... how to specify backup pools in TPM?

Man, I'm almost ashamed to admit we still have that on the our TODO list. It has been there for ages. It will happen shortly though, promise.

[netmebtc]

Hello everyone, I have 6 vega64 (Samsung memory) rig windows10 18.5.1drive, core 1408/900mv, mem 1100/900mv, when I use the 0.5.2 version to mine XMR, each card can reach 2.4Kh, the wall power consumption of the whole machine  is 1800 watts. Except for the power consumption of the motherboard of 200 watts, the average  power consumption of a vega64 reaches 267w. Is this power consumption normal?

Is there a way to reduce the power consumption of vega to less than 185w, even if it is a little less than 2.4kh?