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

[smilodon]

very good miner!my lexa rx550 saphire 2gb elpida memory 575 hash with my custom straps.baffin only 450hash on ethos.why low hashrate baffin?any idea?

We do have a few theories but need to do a separate project to sort it out. It is surprising really. We focused on the lexas this time though, 575 h/s for a 550 2GB is very impressive .

Yes, it's very impressive. For 1 month I was trying to fix the card BIOS and it helps a lot that her memory is Elpida. In Windows with CRYPTONIGHTV7 pi? Anei 550 hash with XMR-Stak 2.4. Respectively the Baffin 570 hash. In Linux the Baffin always had a low hashrate.

[bubaba]

i would love to try this miner
checked windows download file and found something suspicious

Arcabit    Trojan.BZC.ONG.Pantera.13.0DC71EE4    20181129
BitDefender    Gen:Heur.BZC.ONG.Pantera.13.0DC71EE4    20181129
Comodo    Application.Script.Miner.A@7wv4f2    20181129
Cylance    Unsafe    20181129
Emsisoft    Gen:Heur.BZC.ONG.Pantera.13.0DC71EE4 (B)    20181129
GData    Gen:Heur.BZC.ONG.Pantera.13.1162CBC9    20181129
Kaspersky    not-a-virus:HEUR:RiskTool.Script.BitMiner.gen    20181129
MAX    malware (ai score=82)    20181129
Microsoft    PUA:Win32/CoinMiner    20181129
eScan    Gen:Heur.BZC.ONG.Pantera.13.0DC71EE4    20181129
Qihoo-360    Win32/Virus.Script.4bc    20181129
ZoneAlarm by Check Point    not-a-virus:HEUR:RiskTool.Script.BitMiner.gen    20181129

I know some of these are shown at all mining programs but the pantera thing is new to me.
Can anyone confirm this readout?

[vmozara]

I have put 0.3.8 to one of my Vega rigs. So far, working with 0 issues. I did not set up anything, just copied the exe over 037. Do i need to setup something to have watchdog active? lol sorry i was lazy to read

To the guy above with big hashrate issue, i don't know of rx550, but my vegas hash around 2k, when one thread crashed, hashrate goes to 3200 for some reason. I just drop the clocks a bit for that card and never experience it again. So I assume your clocks are too agressive and that is why you get funny hashrates

[Marvell2]

So I took stock of my pdus using SRB and converted all my rigs to Team red to see the power use differences
hash rate is only 5 to 10 percent better than srb in most cases fo my rigs since i use very low core on all my rigs.

I will report power difference but In the mean time i have two rigs , one is a R9 nano rig and the other a mix of rx480 and rx470s and a few 580s that constantly either reboot or freeze using team red ( they ran fine on srb)

This was using cnv8. , I might try cnheavy and see if they can stabilize on that.  

I tired stock settings as well as 7+7 , to no avail , other than disabling the cards one by one to see if its a single unstable card killing the rig , is there any other way to figure out what is going on here?

[kerney666]

I have put 0.3.8 to one of my Vega rigs. So far, working with 0 issues. I did not set up anything, just copied the exe over 037. Do i need to setup something to have watchdog active? lol sorry i was lazy to read

To the guy above with big hashrate issue, i don't know of rx550, but my vegas hash around 2k, when one thread crashed, hashrate goes to 3200 for some reason. I just drop the clocks a bit for that card and never experience it again. So I assume your clocks are too agressive and that is why you get funny hashrates

Yeah, the watchdog thread will be monitoring, but it won't actually active the mechanism on init problems or a dead gpu, you need to setup a script that handles the situation (reboot or restart miner etc). It is active for a few other use cases we monitor for though, like weird pool behavior, stuck API etc.

For the restart event, either you call your script watchdog.bat/watchdog.sh and add "--watchdog_script", or you have to provide an optional argument with "--watchdog_script=my_restart_script.bat".

[kerney666]

So I took stock of my pdus using SRB and converted all my rigs to Team red to see the power use differences
hash rate is only 5 to 10 percent better than srb in most cases fo my rigs since i use very low core on all my rigs.

I will report power difference but In the mean time i have two rigs , one is a R9 nano rig and the other a mix of rx480 and rx470s and a few 580s that constantly either reboot or freeze using team red ( they ran fine on srb)

This was using cnv8. , I might try cnheavy and see if they can stabilize on that.  

I tired stock settings as well as 7+7 , to no avail , other than disabling the cards one by one to see if its a single unstable card killing the rig , is there any other way to figure out what is going on here?

Hi! We don't officially support the R9 series though, only RX550-560, RX470-580 and Vegas. Interesting if you get it working at all . For your mixed Polaris rigs it's hard to say. We do have a different power draw profile in this miner, over time we typically draw less power than other CN miners, but we do have aggressive transients, it goes from low to high power draw in a very short period of time, albeit just for a little while, then back to low power draw again. In a multi-gpu rig, when this transition happens for multiple gpus at the same time some PSUs can't keep up. I personally think many issues with rigs hanging randomly after a while are due to this.

We have a finished 2.0 design ready that should be major improvement in this area, but it's all about time time time. We'll get there though. For the time being, it would be interesting to hear if disabling a card or two or tweaking your clocks/volt helps with the problem. I do believe pretty much all of our users have arrived at stable setups in the end, but the power draw profile above means that many times rigs trimmed for SRB or JCE don't behave 100% well with TRM out of the box.

[Marvell2]

So I took stock of my pdus using SRB and converted all my rigs to Team red to see the power use differences
hash rate is only 5 to 10 percent better than srb in most cases fo my rigs since i use very low core on all my rigs.

I will report power difference but In the mean time i have two rigs , one is a R9 nano rig and the other a mix of rx480 and rx470s and a few 580s that constantly either reboot or freeze using team red ( they ran fine on srb)

This was using cnv8. , I might try cnheavy and see if they can stabilize on that.  

I tired stock settings as well as 7+7 , to no avail , other than disabling the cards one by one to see if its a single unstable card killing the rig , is there any other way to figure out what is going on here?

Hi! We don't officially support the R9 series though, only RX550-560, RX470-580 and Vegas. Interesting if you get it working at all . For your mixed Polaris rigs it's hard to say. We do have a different power draw profile in this miner, over time we typically draw less power than other CN miners, but we do have aggressive transients, it goes from low to high power draw in a very short period of time, albeit just for a little while, then back to low power draw again. In a multi-gpu rig, when this transition happens for multiple gpus at the same time some PSUs can't keep up. I personally think many issues with rigs hanging randomly after a while are due to this.

We have a finished 2.0 design ready that should be major improvement in this area, but it's all about time time time. We'll get there though. For the time being, it would be interesting to hear if disabling a card or two or tweaking your clocks/volt helps with the problem. I do believe pretty much all of our users have arrived at stable setups in the end, but the power draw profile above means that many times rigs trimmed for SRB or JCE don't behave 100% well with TRM out of the box.

Thanks for the response, Power supplies are not the issue since I use 2k server power supplies for the Fury Nano rig and 1600 watt psus on the rx rig.

 Ok that’s strange that you don’t support r9 furys those are tahiti right? I have a second fury rig that works fine
with team red, nice hash rates too 850 per card with -15 power limit.

So I do know r9 nanos work with team red.  My clocks for nanos are 915 core and stock memory at 500
Ill try an either lower power limit first before disabling cards using -d flag

btw in future releases can you have the gpu order to be the same as what overdriven tool uses? and maybe even display mem clock and core speeds similar to srb , that helps troubleshoot since I can see what physical card i and tweaking.  one trick i use is set slightly differt core or mem to help identify cards:

i.e 1130 core vs 1131 core for example

[kerney666]

Thanks for the response, Power supplies are not the issue since I use 2k server power supplies for the Fury Nano rig and 1600 watt psus on the rx rig.

 Ok that’s strange that you don’t support r9 furys those are tahiti right? I have a second fury rig that works fine
with team red, nice hash rates too 850 per card with -15 power limit.

So I do know r9 nanos work with team red.  My clocks for nanos are 915 core and stock memory at 500
Ill try an either lower power limit first before disabling cards using -d flag

btw in future releases can you have the gpu order to be the same as what overdriven tool uses? and maybe even display mem clock and core speeds similar to srb , that helps troubleshoot since I can see what physical card i and tweaking.  one trick i use is set slightly differt core or mem to help identify cards:

i.e 1130 core vs 1131 core for example

Yep, a server psu at 2k should not have any problems with the power draw profile. We support all GPUs with the necessary GCN3 instruction set, so Fiji and Tonga cards could/should work, it's just that we have done zero testing ourselves. Tahiti, Hawaii and earlier just isn't possible for us to support, we don't have the dev bandwidth.

Afaik OverdriveNTool uses bus order, so if you add --bus_reorder you should get the matching order in the miner. You can run the miner with just "teamredminer.exe --bus_reorder --list_devices" to verify the order and compare with OpenCL as well.

We also have the clocks from ADL/sysfs, but we only pass that data over the API currently. We should really add some keypress commands so we can display more stats around the cards, it's a bit crowded in the periodic stats output right now so we opted to not include coreclk/memclk/voltage there for the time being. We could do an early init dump right before mining begins though with that data, could be nice to get yet another way of verifying the gpu order when using your trick of unique clk values per gpu.

[Marvell2]

Thanks for the response, Power supplies are not the issue since I use 2k server power supplies for the Fury Nano rig and 1600 watt psus on the rx rig.

 Ok that’s strange that you don’t support r9 furys those are tahiti right? I have a second fury rig that works fine
with team red, nice hash rates too 850 per card with -15 power limit.

So I do know r9 nanos work with team red.  My clocks for nanos are 915 core and stock memory at 500
Ill try an either lower power limit first before disabling cards using -d flag

btw in future releases can you have the gpu order to be the same as what overdriven tool uses? and maybe even display mem clock and core speeds similar to srb , that helps troubleshoot since I can see what physical card i and tweaking.  one trick i use is set slightly differt core or mem to help identify cards:

i.e 1130 core vs 1131 core for example

Yep, a server psu at 2k should not have any problems with the power draw profile. We support all GPUs with the necessary GCN3 instruction set, so Fiji and Tonga cards could/should work, it's just that we have done zero testing ourselves. Tahiti, Hawaii and earlier just isn't possible for us to support, we don't have the dev bandwidth.

Afaik OverdriveNTool uses bus order, so if you add --bus_reorder you should get the matching order in the miner. You can run the miner with just "teamredminer.exe --bus_reorder --list_devices" to verify the order and compare with OpenCL as well.

We also have the clocks from ADL/sysfs, but we only pass that data over the API currently. We should really add some keypress commands so we can display more stats around the cards, it's a bit crowded in the periodic stats output right now so we opted to not include coreclk/memclk/voltage there for the time being. We could do an early init dump right before mining begins though with that data, could be nice to get yet another way of verifying the gpu order when using your trick of unique clk values per gpu.

-bus_reorder sounds like a winner Ill give that a shot thanks, yeah adding that to the early init dump would be fine as well, I run so many mixed rigs, 480s , 470s 570s, 580s all with 4 or 8 gb mixed the init dump similar to what claymore and srb do with the clock data included would help sort things out for sure.

any chance you will be adding cn-heavy and cn-tube ?

also your main page/faq doesn’t give info on expected hash rates for the other algos ? i.e rx 580 8gb ~ 2mhs phi2 etc

thanks

[visari]

Updated miner to 3.8 via hive official update
Issue with funny hashrate appeared: my 470s and 570 report 1.6-1.8kH hashrate each while avg is lower than before the update
at the same time my 580 reports some 2 hashes increase while having the same 1030 kH as before the update
clocks are OK with the old version

[kerney666]

Updated miner to 3.8 via hive official update
Issue with funny hashrate appeared: my 470s and 570 report 1.6-1.8kH hashrate each while avg is lower than before the update
at the same time my 580 reports some 2 hashes increase while having the same 1030 kH as before the update
clocks are OK with the old version

Hi! What drivers are you running in Hive, and what Hive version is this? There is this weird driver issue where one opencl command queue goes nuts every third restart of the miner, not sure it’s applicable here though, seems we have yet another driver battle in the new release. Solve some old stuff for some, new weird things due to more kernels... I think we need to get Hive going ourselves and see if we can reproduce the issue(s).

[kerney666]

i would love to try this miner
checked windows download file and found something suspicious

Arcabit    Trojan.BZC.ONG.Pantera.13.0DC71EE4    20181129
BitDefender    Gen:Heur.BZC.ONG.Pantera.13.0DC71EE4    20181129
Comodo    Application.Script.Miner.A@7wv4f2    20181129
Cylance    Unsafe    20181129
Emsisoft    Gen:Heur.BZC.ONG.Pantera.13.0DC71EE4 (B)    20181129
GData    Gen:Heur.BZC.ONG.Pantera.13.1162CBC9    20181129
Kaspersky    not-a-virus:HEUR:RiskTool.Script.BitMiner.gen    20181129
MAX    malware (ai score=82)    20181129
Microsoft    PUA:Win32/CoinMiner    20181129
eScan    Gen:Heur.BZC.ONG.Pantera.13.0DC71EE4    20181129
Qihoo-360    Win32/Virus.Script.4bc    20181129
ZoneAlarm by Check Point    not-a-virus:HEUR:RiskTool.Script.BitMiner.gen    20181129

I know some of these are shown at all mining programs but the pantera thing is new to me.
Can anyone confirm this readout?

Well, it’s one of those very frustrating aspects of building a miner that you want people to use. You can google teamredminer yourself and you’ll start seeing repackaged malware versions from the second or third page, mostly in countries where the general public don’t speak English so they hang out on local forums where these copies are found. Those versions gets downloaded, scanned and reported, and here we are. Think we were clean for about two weeks after the CNv2 release, then the shitshow began .

All I can say is that the GitHub version will be clean from any type of malware and unwanted behavior, regardless of the heuristics that the virus scanners use to connect the clean version to the repackaged ones...

[pbfarmer]

So I took stock of my pdus using SRB and converted all my rigs to Team red to see the power use differences
hash rate is only 5 to 10 percent better than srb in most cases fo my rigs since i use very low core on all my rigs.

I will report power difference but In the mean time i have two rigs , one is a R9 nano rig and the other a mix of rx480 and rx470s and a few 580s that constantly either reboot or freeze using team red ( they ran fine on srb)

This was using cnv8. , I might try cnheavy and see if they can stabilize on that. 

I tired stock settings as well as 7+7 , to no avail , other than disabling the cards one by one to see if its a single unstable card killing the rig , is there any other way to figure out what is going on here?

Hi! We don't officially support the R9 series though, only RX550-560, RX470-580 and Vegas. Interesting if you get it working at all . For your mixed Polaris rigs it's hard to say. We do have a different power draw profile in this miner, over time we typically draw less power than other CN miners, but we do have aggressive transients, it goes from low to high power draw in a very short period of time, albeit just for a little while, then back to low power draw again. In a multi-gpu rig, when this transition happens for multiple gpus at the same time some PSUs can't keep up. I personally think many issues with rigs hanging randomly after a while are due to this.

We have a finished 2.0 design ready that should be major improvement in this area, but it's all about time time time. We'll get there though. For the time being, it would be interesting to hear if disabling a card or two or tweaking your clocks/volt helps with the problem. I do believe pretty much all of our users have arrived at stable setups in the end, but the power draw profile above means that many times rigs trimmed for SRB or JCE don't behave 100% well with TRM out of the box.

Thanks for the response, Power supplies are not the issue since I use 2k server power supplies for the Fury Nano rig and 1600 watt psus on the rx rig.

 Ok that’s strange that you don’t support r9 furys those are tahiti right? I have a second fury rig that works fine
with team red, nice hash rates too 850 per card with -15 power limit.

So I do know r9 nanos work with team red.  My clocks for nanos are 915 core and stock memory at 500
Ill try an either lower power limit first before disabling cards using -d flag

btw in future releases can you have the gpu order to be the same as what overdriven tool uses? and maybe even display mem clock and core speeds similar to srb , that helps troubleshoot since I can see what physical card i and tweaking.  one trick i use is set slightly differt core or mem to help identify cards:

i.e 1130 core vs 1131 core for example

Running TRM on SRB settings is not a great idea, esp if you run high-eff/low-voltage setups.  As kerney explained, while TRM does use less power on average, the transients can cause problems - not just for PSUs, but also (and probably more commonly) for highly tuned GPUs.  I have had to bump voltages at least 10+mv from SRB settings for most of my GPUs to cover these spikes (but have also been able to dial up core clock significantly as well.)

*Now that i'm writing this, I'm wondering if maybe you can set a lower power limit value, to force GPU throttling during spikes, rather than always running at the higher voltage.  The spikes are pretty frequent tho, so maybe counterproductive...

[Iamtutut]

Is there a reference setup for RX574 ?

[iSparta]

Miner with good hashrate. It would be nice to include support for R9 280 R9 290 video cards. These are powerful graphics cards, whose potential is quite large. I have 455 h/s on the last version of Monero with XMR-Stak Monero Miner on the R9 280. I think that TeamRedMiner is capable of more.

[Marvell2]

So I took stock of my pdus using SRB and converted all my rigs to Team red to see the power use differences
hash rate is only 5 to 10 percent better than srb in most cases fo my rigs since i use very low core on all my rigs.

I will report power difference but In the mean time i have two rigs , one is a R9 nano rig and the other a mix of rx480 and rx470s and a few 580s that constantly either reboot or freeze using team red ( they ran fine on srb)

This was using cnv8. , I might try cnheavy and see if they can stabilize on that. 

I tired stock settings as well as 7+7 , to no avail , other than disabling the cards one by one to see if its a single unstable card killing the rig , is there any other way to figure out what is going on here?

Hi! We don't officially support the R9 series though, only RX550-560, RX470-580 and Vegas. Interesting if you get it working at all . For your mixed Polaris rigs it's hard to say. We do have a different power draw profile in this miner, over time we typically draw less power than other CN miners, but we do have aggressive transients, it goes from low to high power draw in a very short period of time, albeit just for a little while, then back to low power draw again. In a multi-gpu rig, when this transition happens for multiple gpus at the same time some PSUs can't keep up. I personally think many issues with rigs hanging randomly after a while are due to this.

We have a finished 2.0 design ready that should be major improvement in this area, but it's all about time time time. We'll get there though. For the time being, it would be interesting to hear if disabling a card or two or tweaking your clocks/volt helps with the problem. I do believe pretty much all of our users have arrived at stable setups in the end, but the power draw profile above means that many times rigs trimmed for SRB or JCE don't behave 100% well with TRM out of the box.

Thanks for the response, Power supplies are not the issue since I use 2k server power supplies for the Fury Nano rig and 1600 watt psus on the rx rig.

 Ok that’s strange that you don’t support r9 furys those are tahiti right? I have a second fury rig that works fine
with team red, nice hash rates too 850 per card with -15 power limit.

So I do know r9 nanos work with team red.  My clocks for nanos are 915 core and stock memory at 500
Ill try an either lower power limit first before disabling cards using -d flag

btw in future releases can you have the gpu order to be the same as what overdriven tool uses? and maybe even display mem clock and core speeds similar to srb , that helps troubleshoot since I can see what physical card i and tweaking.  one trick i use is set slightly differt core or mem to help identify cards:

i.e 1130 core vs 1131 core for example

Running TRM on SRB settings is not a great idea, esp if you run high-eff/low-voltage setups.  As kerney explained, while TRM does use less power on average, the transients can cause problems - not just for PSUs, but also (and probably more commonly) for highly tuned GPUs.  I have had to bump voltages at least 10+mv from SRB settings for most of my GPUs to cover these spikes (but have also been able to dial up core clock significantly as well.)

*Now that i'm writing this, I'm wondering if maybe you can set a lower power limit value, to force GPU throttling during spikes, rather than always running at the higher voltage.  The spikes are pretty frequent tho, so maybe counterproductive...

well its only two of 30 rigs with issues i might just leave them on srb , but tey your suggestion on next downtime

[zarapp]

teamredminer v0.3.8 Beta Release
Changes in v0.3.8

• Added support for fan speed and temperatures.
• Added watchdog function for gpu init stuck, dead gpu, over-temp gpu, and non-responding pool.

Hello , on linux did ./teamredminer --help and the only thing i can find temperatures related is the --temp_limit and --temp_resume .
No info on fan speed or set specific temp ? Missed in the help or ?

Regards[/list]

[bigear]

Every time strictly after 15min uptime current hashrate becomes too high on all or almost all gpus (the can be different on other rig start). Avg begin to drop. Reported pool hashrate aim to avg. I've tried to reduce intensity to 3+2, L3+2, reduce overclock to extremely low - 1100/1850 on baffins and 1180/1950 on lexa but problem occures again at same time - 15min after start

What an interesting issue, not too often you get these deterministic ones that can be repeated easily! I'm trying to think of something in the miner that would be triggered after 15 mins, but there is nothing that I can think of really. I don't think this has anything to do with clocks etc, this is something else. Do you have any power management features activated in Windows? Anything that happens after 15 mins? SRB could be better than us controlling things from within the miner.

You are right! It seems that problem was simply in "turn off the display every 15 min". Of course performance mode was enabled before mining but I never thought about display turn off because nothing connected to my gpus and there was no problems with miners early.
Thanks for great miner and help!   

[Pennywis3]

any ETA on heavy support?

[robminer80]

very good miner!my lexa rx550 saphire 2gb elpida memory 575 hash with my custom straps.baffin only 450hash on ethos.why low hashrate baffin?any idea?

We do have a few theories but need to do a separate project to sort it out. It is surprising really. We focused on the lexas this time though, 575 h/s for a 550 2GB is very impressive .

Yes, it's very impressive. For 1 month I was trying to fix the card BIOS and it helps a lot that her memory is Elpida. In Windows with CRYPTONIGHTV7 pi? Anei 550 hash with XMR-Stak 2.4. Respectively the Baffin 570 hash. In Linux the Baffin always had a low hashrate.

What Elpida straps do you use to get that hashrate? I've rx550 baffin 12CU unlocked, gets 520 h/s with 3+3