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

[vmozara]

Is it normal that with drivers 18.5.1 I had 1850h/s and now i installed 18.11.2 (for battlefield5) and I have 1130h/s with vega 56

I didnt change shit on config

you probably had power tables before. now that you installed the driver, your power table is overwritten and vega hashes bad and consumes a lot. I am not sure how to connect good miner vega and good gaming vega into same PC. Try to apply power table and see if your vega now hashes correct, and if the game plays alright (nowthe game will probably have reduced performance)

[1714613434]

1714613434

[1714613434]

1714613434

[1714613434]

1714613434

[arierep60]

Guys please fix this:
If my rig have more than 10 gpu I don't get the gpu information like I had in version 0.3.1  

Here is a Rig with 9 GPU, everything looks fine

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



And here is a Rig with 13 GPU

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

I get no GPU info and 3 gpus appear black squares.
Could you fix this please?
Thank you

Hi! Hmm, I'm guessing you have some externally provided HiveOS integration for tdxminer? Since we've changed the output, maybe some log/output parsing is broken now? Do you remember how you set things up way back when for 0.3.1?

still have this problem not showing all gpus...
any update on this?
thanks

[kerney666]

Anyone have a tip about get optimal hashrates on RX 550 4GB and 560 4GB? I'm getting a little bit more than 400 H/s with both 550/560s, in best case scenario. Running RX 560 at 1200 MHz Core, 1980 MHz Mem. 550 at 1200 MHz Core, 2000 MHz Memory.

TeamRedMiner prefer 2+2 on the 550's and 4+2 on the 560's I think. But I manually set them to 3+3 to 550 and 4+4 to 560... Any help?

In the upcoming version we have made a better optimization run for 550/560s. This is one reason for it being delayed, we wanted to wrap that up properly. Todxx knows more, but afaik the results have been very good in many cases.  So, stay tuned...

[kerney666]

Guys please fix this:
If my rig have more than 10 gpu I don't get the gpu information like I had in version 0.3.1  

Here is a Rig with 9 GPU, everything looks fine





And here is a Rig with 13 GPU



I get no GPU info and 3 gpus appear black squares.
Could you fix this please?
Thank you

Hi! Hmm, I'm guessing you have some externally provided HiveOS integration for tdxminer? Since we've changed the output, maybe some log/output parsing is broken now? Do you remember how you set things up way back when for 0.3.1?

still have this problem not showing all gpus...
any update on this?
thanks

I'm no HiveOS expert, but I'm guessing this integration is based on parsing the output from the miner rather than using the sgminer-compatible API that we provide. That output format has changed between versions, and I believe one thing is that the ninth gpu is still printed as "GPU 9" but you now see "GPU10" rather than "GPU 10" to keep things aligned vertically. Hence, I'm guessing there is some script parsing output that now is broken for GPU10 and forth.

However, unless you can point me to the specific implementation you're using, there's not much I can do. I need to see the shell/Python/Perl/awk/sed/whatever script running on your box that is parsing the output. I'm guessing it could be a trivial patch of some regular expression or awk statement. When we have the time we might make sure there's a proper HiveOS custom miner integration ourselves, this time using the API rather than parsing miner output.

[kerney666]

Is it normal that with drivers 18.5.1 I had 1850h/s and now i installed 18.11.2 (for battlefield5) and I have 1130h/s with vega 56

I didnt change shit on config

Well, I'm quite sure we didn't change shit in the miner code either when you switched driver version .

This is the painful world of trying to develop against AMD's drivers. CN is perhaps the most sensitive algo of all when it comes to mem controller tweaks in the driver, and man do they hack that shit between driver versions sometimes. Unfortunately, AMD's incentives are rather to maximize the frame rate in the latest and greatest games than making sure CN miners are happy. So, there's not that much we can do unfortunately .

[pbfarmer]

Is it normal that with drivers 18.5.1 I had 1850h/s and now i installed 18.11.2 (for battlefield5) and I have 1130h/s with vega 56

I didnt change shit on config

First, check if the Compute mode is on. Second, from what i have heard, Vegas have issues with drivers past 18.6.1. So you may have to downgrade the drivers.

The 18.6.1 issue was just on xmr-stak/variants, or any other miner using the old wolf codebase which generated opencl kernel binaries at runtime.   I have had no issues w/ any driver version through 18.10.x on other miners including this one - though I can't vouch specifically for 18.11 yet.

[arierep60]

Guys please fix this:
If my rig have more than 10 gpu I don't get the gpu information like I had in version 0.3.1  

Here is a Rig with 9 GPU, everything looks fine

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



And here is a Rig with 13 GPU

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

I get no GPU info and 3 gpus appear black squares.
Could you fix this please?
Thank you

Hi! Hmm, I'm guessing you have some externally provided HiveOS integration for tdxminer? Since we've changed the output, maybe some log/output parsing is broken now? Do you remember how you set things up way back when for 0.3.1?

still have this problem not showing all gpus...
any update on this?
thanks

I'm no HiveOS expert, but I'm guessing this integration is based on parsing the output from the miner rather than using the sgminer-compatible API that we provide. That output format has changed between versions, and I believe one thing is that the ninth gpu is still printed as "GPU 9" but you now see "GPU10" rather than "GPU 10" to keep things aligned vertically. Hence, I'm guessing there is some script parsing output that now is broken for GPU10 and forth.

However, unless you can point me to the specific implementation you're using, there's not much I can do. I need to see the shell/Python/Perl/awk/sed/whatever script running on your box that is parsing the output. I'm guessing it could be a trivial patch of some regular expression or awk statement. When we have the time we might make sure there's a proper HiveOS custom miner integration ourselves, this time using the API rather than parsing miner output.

sent you a PM mate

[twotwosix]

What is "Pool xmr-eu1.nanopool.org failed to parse server rpc: {"id":43,"jsonrpc":"2.0","result":{"status":"OK"},"error":null}"

[kerney666]

What is "Pool xmr-eu1.nanopool.org failed to parse server rpc: {"id":43,"jsonrpc":"2.0","result":{"status":"OK"},"error":null}"

It’s an issue with broken json-rpc implementations on some pools. Add the command line parameter --pool_broken_rpc to work around it.

[twotwosix]

What is "Pool xmr-eu1.nanopool.org failed to parse server rpc: {"id":43,"jsonrpc":"2.0","result":{"status":"OK"},"error":null}"

It’s an issue with broken json-rpc implementations on some pools. Add the command line parameter --pool_broken_rpc to work around it.

im using 0.3.6 version, i cant run 0.3.7 with same config

[iRonNuke]

Anyone have a tip about get optimal hashrates on RX 550 4GB and 560 4GB? I'm getting a little bit more than 400 H/s with both 550/560s, in best case scenario. Running RX 560 at 1200 MHz Core, 1980 MHz Mem. 550 at 1200 MHz Core, 2000 MHz Memory.

TeamRedMiner prefer 2+2 on the 550's and 4+2 on the 560's I think. But I manually set them to 3+3 to 550 and 4+4 to 560... Any help?

In the upcoming version we have made a better optimization run for 550/560s. This is one reason for it being delayed, we wanted to wrap that up properly. Todxx knows more, but afaik the results have been very good in many cases.  So, stay tuned...

Very nice! I'm really seeing forward to this!

[ku4eto]

What is "Pool xmr-eu1.nanopool.org failed to parse server rpc: {"id":43,"jsonrpc":"2.0","result":{"status":"OK"},"error":null}"

It’s an issue with broken json-rpc implementations on some pools. Add the command line parameter --pool_broken_rpc to work around it.

im using 0.3.6 version, i cant run 0.3.7 with same config

Lower the CN Algo.... I used 8-7 before, but for 0.3.7 i need 7-7 (4GB cards).

[tvukoman]

Just testing older 0.36 vs newer 0.37 version for 48 hours.

Better stability (no 0 H/s problematic Vega 56 card after few hours of mining). Same configuration, same driver 18.6.1

Same H/s.

EDIT: lol, and again, go to 0 H/s after 2 days of running :-)

[issie81]

Just testing older 0.36 vs newer 0.37 version for 48 hours.

Better stability (no 0 H/s problematic Vega 56 card after few hours of mining). Same configuration, same driver 18.6.1

Same H/s.

EDIT: lol, and again, go to 0 H/s after 2 days of running :-)

restarting miner fixes it usually, but needs to be tweaked by team

[twotwosix]

What is "Pool xmr-eu1.nanopool.org failed to parse server rpc: {"id":43,"jsonrpc":"2.0","result":{"status":"OK"},"error":null}"

It’s an issue with broken json-rpc implementations on some pools. Add the command line parameter --pool_broken_rpc to work around it.

im using 0.3.6 version, i cant run 0.3.7 with same config

Lower the CN Algo.... I used 8-7 before, but for 0.3.7 i need 7-7 (4GB cards).

Using 15+15 in my rx580 8gb in 0.3.6 , in 0.3.7 crashes when starting with 7+7, 8+8, 14+14 ... 0.3.7 fail

[kerney666]

What is "Pool xmr-eu1.nanopool.org failed to parse server rpc: {"id":43,"jsonrpc":"2.0","result":{"status":"OK"},"error":null}"

It’s an issue with broken json-rpc implementations on some pools. Add the command line parameter --pool_broken_rpc to work around it.

im using 0.3.6 version, i cant run 0.3.7 with same config

Lower the CN Algo.... I used 8-7 before, but for 0.3.7 i need 7-7 (4GB cards).

Using 15+15 in my rx580 8gb in 0.3.6 , in 0.3.7 crashes when starting with 7+7, 8+8, 14+14 ... 0.3.7 fail

Can you describe the crash that you’re referring to? Is it on startup or after working for a little while? Does the card initialize at all? I think you’re hitting an initialization corner case that should be solved in upcoming 0.3.8, but would love to get more info.

[kerney666]

Just testing older 0.36 vs newer 0.37 version for 48 hours.

Better stability (no 0 H/s problematic Vega 56 card after few hours of mining). Same configuration, same driver 18.6.1

Same H/s.

EDIT: lol, and again, go to 0 H/s after 2 days of running :-)

restarting miner fixes it usually, but needs to be tweaked by team

The miner has a quite aggressive style. When you lose a gpu after a few hours or even days there’s no bug per se in the miner, it’s the opencl api and/or driver that stops responding. The only solution (except you lowering clocks) is a redesign of the kernels, although it’s probable this is also more about your psus rather than the gpu clocks. We have the next-level design ready though, we’ll attack it in the near future.

[alucard20724]

Just testing older 0.36 vs newer 0.37 version for 48 hours.

Better stability (no 0 H/s problematic Vega 56 card after few hours of mining). Same configuration, same driver 18.6.1

Same H/s.

EDIT: lol, and again, go to 0 H/s after 2 days of running :-)

restarting miner fixes it usually, but needs to be tweaked by team

The miner has a quite aggressive style. When you lose a gpu after a few hours or even days there’s no bug per se in the miner, it’s the opencl api and/or driver that stops responding. The only solution (except you lowering clocks) is a redesign of the kernels, although it’s probable this is also more about your psus rather than the gpu clocks. We have the next-level design ready though, we’ll attack it in the near future.

i think you should attack it now.   I see the exact same problem with going to 0 h/s after a day.   It happens on 10 different machines with 470/480/570/580/Vega56/Vega64.  The problem that causes this for me is that when cpu mining, teamredminer does not initialize the gpu and so my hashrate drops to zero.   This only happens with TeamRed.  SRBminer, and CastXMR does not exhibit this problem.

[kerney666]

Just testing older 0.36 vs newer 0.37 version for 48 hours.

Better stability (no 0 H/s problematic Vega 56 card after few hours of mining). Same configuration, same driver 18.6.1

Same H/s.

EDIT: lol, and again, go to 0 H/s after 2 days of running :-)

restarting miner fixes it usually, but needs to be tweaked by team

The miner has a quite aggressive style. When you lose a gpu after a few hours or even days there’s no bug per se in the miner, it’s the opencl api and/or driver that stops responding. The only solution (except you lowering clocks) is a redesign of the kernels, although it’s probable this is also more about your psus rather than the gpu clocks. We have the next-level design ready though, we’ll attack it in the near future.

i think you should attack it now.   I see the exact same problem with going to 0 h/s after a day.   It happens on 10 different machines with 470/480/570/580/Vega56/Vega64.  The problem that causes this for me is that when cpu mining, teamredminer does not initialize the gpu and so my hashrate drops to zero.   This only happens with TeamRed.  SRBminer, and CastXMR does not exhibit this problem.

I know you have this startup problem, which is unrelated to the 0 h/s gpu hang after mining successfully for a while. It has nothing to do with the redesign of the kernels. Your issue is about cpu starvation when our miner starts up. Comparisons to srb and cast are irrelevant since we use a different initialization process. Have you tried starting the miner with a real-time process priority? Theoretically windows should preempt your cpu miner threads much more aggressively in favor of the gpu miner. When the gpu miner is running the effect on the cpu mining hashrate should be tiny.

[alucard20724]

Just testing older 0.36 vs newer 0.37 version for 48 hours.

Better stability (no 0 H/s problematic Vega 56 card after few hours of mining). Same configuration, same driver 18.6.1

Same H/s.

EDIT: lol, and again, go to 0 H/s after 2 days of running :-)

restarting miner fixes it usually, but needs to be tweaked by team

The miner has a quite aggressive style. When you lose a gpu after a few hours or even days there’s no bug per se in the miner, it’s the opencl api and/or driver that stops responding. The only solution (except you lowering clocks) is a redesign of the kernels, although it’s probable this is also more about your psus rather than the gpu clocks. We have the next-level design ready though, we’ll attack it in the near future.

i think you should attack it now.   I see the exact same problem with going to 0 h/s after a day.   It happens on 10 different machines with 470/480/570/580/Vega56/Vega64.  The problem that causes this for me is that when cpu mining, teamredminer does not initialize the gpu and so my hashrate drops to zero.   This only happens with TeamRed.  SRBminer, and CastXMR does not exhibit this problem.

I know you have this startup problem, which is unrelated to the 0 h/s gpu hang after mining successfully for a while. It has nothing to do with the redesign of the kernels. Your issue is about cpu starvation when our miner starts up. Comparisons to srb and cast are irrelevant since we use a different initialization process. Have you tried starting the miner with a real-time process priority? Theoretically windows should preempt your cpu miner threads much more aggressively in favor of the gpu miner. When the gpu miner is running the effect on the cpu mining hashrate should be tiny.

considering that this only happens with your miner, and not with any of the other 20 miners that i use, this isn't a good case for changing my system when all other software works.  my systems are set up for multi-algo, multi-software mining.