[ANN] TeamRedMiner - Old Thread

[kokodesu]

Using TRMv0.5.7 with algo mtp, d29, c31 causes HW error and crashes.
This does not occur with TRMv0.5.6.
The cause is unknown, but I will report it.

OS HiveOS or mmpOS
LINUX driver 19.2 or 18.40
RIG VEGA56x1, RX570x5, RX580x2

Hi! MTP and c31 didn’t change at all between 0.5.6 and 0.5.7, goes for both gpu and host-side code, so it’s very strange if you see reproducible issues appearing in 0.5.7 for those two . C29d was added in 0.5.7 and can be problematic to tune at times.

Which gpu(s) are crashing? Always the same or random? Always a Vega or Polaris?

HW errors and crashes are random. HW error occurs on many GPUs. Crashes don't happen often, but they are not fixed and happen regardless of VEGA or polaris.

[1714687341]

1714687341

[1714687341]

1714687341

[SigiSinatra]

Will you please consider to implement equihash and/or some of it's variants ?
96/5,  144/5, 125/4, 150/5, 192/7, 210/9

[kerney666]

Will you please consider to implement equihash and/or some of it's variants ?
96/5,  144/5, 125/4, 150/5, 192/7, 210/9

Equihash is the last major algo family we haven’t touched (well ethash too), of course we’ve discussed it. We did cuckoo for grin first, we’ll see what happens next. It’s def on the roadmap, we’ll get there at some point.

[sharmanov]

Beam, please add Beam Equihash 

[SigiSinatra]

Beam, please add Beam Equihash 

Yeah...1080ti provides almost double hashrate comparing to vega on equihash.
1080ti did 2x Vega on c31 and c29 too but look at us now 

[SigiSinatra]

We should be ready for Raven hardfork.

https://github.com/traysi/x16rv2_hash

[kerney666]

We should be ready for Raven hardfork.

https://github.com/traysi/x16rv2_hash

Yep, saw the announcement yesterday, x16rv2 will be ready for the fork, tons of time left.

[astark052970]

Great job guys this miner is awesome. Easy to use, good hashrates, and zero rejected shares. Here are my results hope this helps someone!

Driver: Adrenalin 19.8.1
Miner: TRM 0.5.7
Afterburner: 4.6.1
GPU: XFX Radeon VII
Test system: 7600K, Asus Z270E, 8GB RAM, EVGA 850 G2, Open Benchtable (open air)

Power consumption numbers are total system power as measured by a Kill A Watt. The system uses about 30w without a GPU so you can deduct 30w from these numbers to get an estimate of the GPU power consumption. I selected what I believe to be my weakest VII so I would expect most cards to do better than this.

Format is:
Voltage/Core Clock/Mem Clock - cn config that the auto tune ended up with, power usage range, GPU temp/junction temp, hash rate range

The following tests were done over two days with the AC off. Temps are probably a little off as a result.

821/1408/1000 - 13*12:AAA, 162w-177w, 49C/60C, 2600-2640
821/1408/1100 - 13*12:AAA, 168w-180w, 51C/61-64C, 2628-2680
821/1508/1100 - FAIL
830/1508/1100 - FAIL
840/1508/1100 - 13*13:CAB, 178w-186w, 53C/65C, 2790-2825, FAIL hw errors
850/1508/1100 - 13*12:AAA, 181w-194w, 53C/66C, 2778-2853
850/1608/1100 - FAIL init
860/1608/1100 - FAIL GPU Dead
870/1608/1100 - FAIL hw errors
880/1608/1100 - FAIL hw errors
890/1608/1100 - 13*13:AAA, 201w-212w, 57C/70-74C, 2873-3033
890/1658/1100 - FAIL hw errors
900/1658/1100 - FAIL hw errors
905/1658/1100 - FAIL hw errors
910/1658/1100 - FAIL hw errors
915/1658/1100 - 13*12:CAB, 206w-219w, 56C/70C, 3009-3039
915/1708/1100 - FAIL GPU Dead
920/1708/1100 - FAIL hw errors
925/1708/1100 - FAIL hw errors
930/1708/1100 - FAIL hw errors
935/1708/1100 - FAIL hw errors
940/1708/1100 - 13*12:CAB, 220w-233w, 57C/72-75C, 3078-3130

Retested the good settings to verify. Didn't record the cn config since it usually ended up at 13*12 CAB or AAA. Also these tests were done one the same day with the AC on so the temps should be more accurate.

821/1408/1100 - 168w-175w, 50C/60C, 2630-2700
850/1508/1100 - 180w-192w, 52C/63C, 2780-2840
890/1608/1100 - 196w-210w, 54C/66C, 2930-2990
915/1658/1100 - 206w-222w, 56C/69C, 3010-3060
940/1708/1100 - 224w-235w, 57C/72C, 3070-3130
 

[dastardlyman12]

hey astark052970

ive got a couple of radeon VIIs
i can verify that TRM is amzing

my two are at 1700 mhz core 1050hbm speed and 940 mv core volts
and get 3015 hashes each on monero.   drawing about 230 watts from the wall each.
the way to look at it is the VIIs are hashing like three rx470 nitros but drawing the power of
TWO rx470 nitros.

amazing TRM amazing Radeon VII

also ran TRM on an rx470 8gb nitro and itwas SO EASY to get 1000hash on monero cnr.

well done TRM - its great software.
PS im running latest TRM with latest amd drivers- i love the way the latest amd drivers
read out the gpu watts in the actual driver near the bottom in blue

[sharmanov]

Are you guys working on RandomX at all? I really hope you guys do your magic on RandomX for AMD hardware

[kerney666]

Are you guys working on RandomX at all? I really hope you guys do your magic on RandomX for AMD hardware

Hi sharmanov! I'm sorry to say we're not. RandomX in its current form just isn't doable (in any efficient way I can think of at least) on GPUs, there are too many aspects that clash with what the gpu hardware is built and optimized for.

Sech1 (one of the RandomX people) has done a solid job at a reference OpenCL+GCN asm implementation, I'd say it's by far the most advanced open source miner for AMD available. He has issued a pull request into xmrig, hashrates are maybe 400-500 h/s for a Polaris gpu, 1000-1200 h/s for a Vega 64, all at crap efficiency compared to a modern cpu. So, cpus will crush gpus at Monero mining after the October fork, and that's that, it should be said out loud repeatedly rather than giving gpu miners false hope .

It would be really nice if I'm wrong and someone comes up with a viable way of running RandomX on gpus, but, not too likely, if I may say so myself...

[du44]

any plans to add kernels for Navi?

[kerney666]

any plans to add kernels for Navi?

Of course, they will appear in due time. The combo of a crappy compiler _and_ lower level tools also not being ready, and then not being able to run any mem-bound algo that needs a live data set > 20-30MB due to driver issues, well, we decided to not kill ourselves just yet but rather wait and observe a little.

[Apprentice]

how to define multiple pools?

i really like this miner?

thanks.

[kerney666]

TeamRedMiner discord now open!

You're all welcome to join the TRM public discord for support and interaction with other users as well as myself and todxx.

https://discord.gg/GDFBVX5

[kerney666]

how to define multiple pools?

i really like this miner?

thanks.

Hehe, this is probably the 10th time I apologize that we still have pool failover support on our TODO list, it has been there from v0.3, we have continued to prioritize adding more algos rather than host-side work though. We should really add basic pool failover though, our bad. I'll discuss with todxx and see if/when we can slot it in.

[Apprentice]

how to define multiple pools?

i really like this miner?

thanks.

Hehe, this is probably the 10th time I apologize that we still have pool failover support on our TODO list, it has been there from v0.3, we have continued to prioritize adding more algos rather than host-side work though. We should really add basic pool failover though, our bad. I'll discuss with todxx and see if/when we can slot it in.

well in my honest humble opinion, the miner is good but in comparison to other miners and provided options (especially the fail over pool) your dev fees are really high. Some other miners are below 1%. But a 1% is good number that you should consider.

[kerney666]

how to define multiple pools?

i really like this miner?

thanks.

Hehe, this is probably the 10th time I apologize that we still have pool failover support on our TODO list, it has been there from v0.3, we have continued to prioritize adding more algos rather than host-side work though. We should really add basic pool failover though, our bad. I'll discuss with todxx and see if/when we can slot it in.

well in my honest humble opinion, the miner is good but in comparison to other miners and provided options (especially the fail over pool) your dev fees are really high. Some other miners are below 1%. But a 1% is good number that you should consider.

Honestly, if you don't clearly earn more with TRM and/or have a hard time accepting the dev fee, then you should use another miner. For the dev fee, it won't change. If you don't want to pay for the kind of work we do, which means grinding instructions in GCN ASM and many times probably spending 5-10x more time (at least!) on our kernels than the other miners you refer to, then it's a no brainer, just use one of the other miners instead. For the specific issue of failover pool support, it's the last TODO item in that category, and no one has asked about it for 2-3 months.

My sincerest apologies for getting you in the line of fire now since you were quite gracious with your suggestion, but since you aren't the first one to imply that we'd be better off slashing our current income with -60% so they can increase their mining profits +1.5%, please allow me one last public rant about this.

This project is about putting your heart and soul into getting AMD GPUs to perform. Either we can make enough money from it to support two highly qualified devs spending a significant part of their available time on this, or we exit the market. And trust me, we're not getting rich from this, we're rather right at the level of it being worthwhile. So yeah, 1% dev fee means 0% for both you and for us, because we will be back to doing more lucrative work in other industries instead, or just doing private work in this space where you deal with business entities that do simple bottom line math and pay a premium for exclusivity. But no, we wanted to try to take our work public, benefitting all and making it much more difficult for private gpu miners to have a significant edge.

Many times people seem to think our +20-40% advantages in the compute algos (except for MTP, which is a different beast) is something that comes for free. "Oh, they just use GCN ASM, maybe I'll look into it later and I'll be just as good". Right. Good luck with that. It's not the toolset that matters, it's your skill and experience using it. We've spent _months_ in total on c29/c31, all as a service for Vega users to have something to do when XMR forks in October, drawing from 2 yrs of experience trying to squeeze perf out of AMD GPUs, which isn't trivial to begin with. Same thing investing time in MTP, which didn't have a proper Vega miner at all. Last, don't even get me _started_ on the work we've done with the x16 family of algos. Months and months of grinding away finding small opts in each of the 16 algos.

So, for everyone that feels the 2.5% TRM dev fee is unacceptable, please shop around for other AMD miner devs that right now are working proactively and are producing options that can at least compete with Team Green when XMR is out of the picture, and that has spent the same obscene amount of time as we have doing R&D just to be able to come close to Team Green. Then please use those miners instead.

[Apprentice]

how to define multiple pools?

i really like this miner?

thanks.

Hehe, this is probably the 10th time I apologize that we still have pool failover support on our TODO list, it has been there from v0.3, we have continued to prioritize adding more algos rather than host-side work though. We should really add basic pool failover though, our bad. I'll discuss with todxx and see if/when we can slot it in.

well in my honest humble opinion, the miner is good but in comparison to other miners and provided options (especially the fail over pool) your dev fees are really high. Some other miners are below 1%. But a 1% is good number that you should consider.

Honestly, if you don't clearly earn more with TRM and/or have a hard time accepting the dev fee, then you should use another miner. For the dev fee, it won't change. If you don't want to pay for the kind of work we do, which means grinding instructions in GCN ASM and many times probably spending 5-10x more time (at least!) on our kernels than the other miners you refer to, then it's a no brainer, just use one of the other miners instead. For the specific issue of failover pool support, it's the last TODO item in that category, and no one has asked about it for 2-3 months.

My sincerest apologies for getting you in the line of fire now since you were quite gracious with your suggestion, but since you aren't the first one to imply that we'd be better off slashing our current income with -60% so they can increase their mining profits +1.5%, please allow me one last public rant about this.

This project is about putting your heart and soul into getting AMD GPUs to perform. Either we can make enough money from it to support two highly qualified devs spending a significant part of their available time on this, or we exit the market. And trust me, we're not getting rich from this, we're rather right at the level of it being worthwhile. So yeah, 1% dev fee means 0% for both you and for us, because we will be back to doing more lucrative work in other industries instead, or just doing private work in this space where you deal with business entities that do simple bottom line math and pay a premium for exclusivity. But no, we wanted to try to take our work public, benefitting all and making it much more difficult for private gpu miners to have a significant edge.

Many times people seem to think our +20-40% advantages in the compute algos (except for MTP, which is a different beast) is something that comes for free. "Oh, they just use GCN ASM, maybe I'll look into it later and I'll be just as good". Right. Good luck with that. It's not the toolset that matters, it's your skill and experience using it. We've spent _months_ in total on c29/c31, all as a service for Vega users to have something to do when XMR forks in October, drawing from 2 yrs of experience trying to squeeze perf out of AMD GPUs, which isn't trivial to begin with. Same thing investing time in MTP, which didn't have a proper Vega miner at all. Last, don't even get me _started_ on the work we've done with the x16 family of algos. Months and months of grinding away finding small opts in each of the 16 algos.

So, for everyone that feels the 2.5% TRM dev fee is unacceptable, please shop around for other AMD miner devs that right now are working proactively and are producing options that can at least compete with Team Green when XMR is out of the picture, and that has spent the same obscene amount of time as we have doing R&D just to be able to come close to Team Green. Then please use those miners instead.

ouch! where did this come from?!
I've already have 6 rigs using this miner.....!
and since I mine to a proxy, I need fail over pool
Will monitor the hashrate and compare hashrate with the fees and manage my profitability.

also to let you know that it does work on other AMD GPUs. I have tried WX 4100/7100 and fire pro, think cause they have polaris too.

[kerney666]

ouch! where did this come from?!
I've already have 6 rigs using this miner.....!
and since I mine to a proxy, I need fail over pool
Will monitor the hashrate and compare hashrate with the fees and manage my profitability.

also to let you know that it does work on other AMD GPUs. I have tried WX 4100/7100 and fire pro, think cause they have polaris too.

Hi, sent you a PM. Nice with the other GPUs, there are a few that we haven't tested on ourselves. It's all about what device string the driver is presenting the GPU with, if we recognize it we present our kernels for that architecture, if we don't recognize it we crap out.