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

[carlosmonaco]

What is the best tuning for RX Vega 56 and 64 reference blower.

I Use 1408/1090 (16+14) for vega 64
and 1413/945 (16+14) for Vega 56
I get 2030 Vega 64 and 1980 Vega 56, is it possible to get better ?

PS : Win 10 / 18.5.1 / PPT
I also get a lot of error -1 block expired
I find something weird too, even if I set 900mv or other things in OverdriveNtool I get 1250mv on HWInfo for memory voltage. For core it is the opposite when I set 905 it show 881mV and Core clock is also lower than the one set with overdrivntool. Any idea ?

https://ibb.co/b5ekC0

When you're running around 1408 core clk on a Vega 64, 15+15 is usually a better config than 16+14. On my Vega 64 LC at 1408/1100, I see ~2030 h/s with 16+14 and ~2095 h/s with 15+15, so that's probably worth trying. For the 56, just cycle through 16+14, 15+15, 14+14, 14-14 and see which one gives you the best results!

I can't say I have anything intelligent to say around the nrs you're ssing in HWInfo though .

Thanks I will try tomorrow .
Whatever I put on memory voltage with overdriventool hwinfo show 1250mv memory voltage for vega 56 and 1356mV for vega 64.
Is it possible to get the bus number for each card on the hashrate report ( I know it is at the begining) ?

[pbfarmer]

What is the best tuning for RX Vega 56 and 64 reference blower.

I Use 1408/1090 (16+14) for vega 64
and 1413/945 (16+14) for Vega 56
I get 2030 Vega 64 and 1980 Vega 56, is it possible to get better ?

PS : Win 10 / 18.5.1 / PPT
I also get a lot of error -1 block expired
I find something weird too, even if I set 900mv or other things in OverdriveNtool I get 1250mv on HWInfo for memory voltage. For core it is the opposite when I set 905 it show 881mV and Core clock is also lower than the one set with overdrivntool. Any idea ?

When you're running around 1408 core clk on a Vega 64, 15+15 is usually a better config than 16+14. On my Vega 64 LC at 1408/1100, I see ~2030 h/s with 16+14 and ~2095 h/s with 15+15, so that's probably worth trying. For the 56, just cycle through 16+14, 15+15, 14+14, 14-14 and see which one gives you the best results!

I can't say I have anything intelligent to say around the nrs you're ssing in HWInfo though .

Thanks I will try tomorrow .
Whatever I put on memory voltage with overdriventool hwinfo show 1250mv memory voltage for vega 56 and 1356mV for vega 64.
Is it possible to get the bus number for each card on the hashrate report ( I know it is at the begining) ?

1.25v (56) and 1.356mv (64) are the real, coded in bios, voltages for the mem.  The values in your profile tool of choice are for the controller/infinityfabric/SOC/whatever you call it, and are really a floor under the core voltage, as they seem to share the same line.

As for the clock/voltage drop in hwinfo64 vs your settings, it's a result of the applied load, and the AVFS feature of vegas.  In general, higher load + lower voltage = bigger clock throttle.

[Doucesti]

You know, this is a little interesting. Nanopool has a broken rpc implementation which causes issues when e.g. submitting two or more shares in quick succession. Now, we assumed that we'd still get replies for all submitted shares, but there could cases where they actually drop rpc requests. I didn't do the fix though, need to check with todxx.

Comparing pool payouts is a different thing though. Unless you're sure the pools hit exactly 100% avg luck over the same period, it doesn't say much. The poolside hashrate displayed in the miner should match your miner hashrate minus dev fee and any rejected shares. If that looks good, we can't really do much more from a miner dev perspective. If that number is ok, but the pool reports a different hashrate, something is fishy.

After mining for a while on supportxmr, everything was good, readings on miner were avg 1850h/s and pool 1790h/s.
Yesterday my readings were avg 1850h/s and pool was down at 1750, now I'm down at avg 1850h/s and pool 1662h/s.

I've also switched to this pool yesterday, two really slow miners sometime before readings. I'll try switching them back to another pool..!

[kerney666]

You know, this is a little interesting. Nanopool has a broken rpc implementation which causes issues when e.g. submitting two or more shares in quick succession. Now, we assumed that we'd still get replies for all submitted shares, but there could cases where they actually drop rpc requests. I didn't do the fix though, need to check with todxx.

Comparing pool payouts is a different thing though. Unless you're sure the pools hit exactly 100% avg luck over the same period, it doesn't say much. The poolside hashrate displayed in the miner should match your miner hashrate minus dev fee and any rejected shares. If that looks good, we can't really do much more from a miner dev perspective. If that number is ok, but the pool reports a different hashrate, something is fishy.

After mining for a while on supportxmr, everything was good, readings on miner were avg 1850h/s and pool 1790h/s.
Yesterday my readings were avg 1850h/s and pool was down at 1750, now I'm down at avg 1850h/s and pool 1662h/s.

I've also switched to this pool yesterday, two really slow miners sometime before readings. I'll try switching them back to another pool..!

Supportxmr is generally nice allowing a static diff for maybe 1 share every 5 secs. It’s not super nice to run that way 100% of the time, but if you’re nervous about poolside hashrate not lining up with miner hashrate, that’s the way to go. 10k diff is the lowest allowed though, so add +10000 after your wallet.

[Mashy81]

What is the best tuning for RX Vega 56 and 64 reference blower.

I Use 1408/1090 (16+14) for vega 64
and 1413/945 (16+14) for Vega 56
I get 2030 Vega 64 and 1980 Vega 56, is it possible to get better ?

PS : Win 10 / 18.5.1 / PPT
I also get a lot of error -1 block expired
I find something weird too, even if I set 900mv or other things in OverdriveNtool I get 1250mv on HWInfo for memory voltage. For core it is the opposite when I set 905 it show 881mV and Core clock is also lower than the one set with overdrivntool. Any idea ?

When you're running around 1408 core clk on a Vega 64, 15+15 is usually a better config than 16+14. On my Vega 64 LC at 1408/1100, I see ~2030 h/s with 16+14 and ~2095 h/s with 15+15, so that's probably worth trying. For the 56, just cycle through 16+14, 15+15, 14+14, 14-14 and see which one gives you the best results!

I can't say I have anything intelligent to say around the nrs you're ssing in HWInfo though .

Thanks I will try tomorrow .
Whatever I put on memory voltage with overdriventool hwinfo show 1250mv memory voltage for vega 56 and 1356mV for vega 64.
Is it possible to get the bus number for each card on the hashrate report ( I know it is at the begining) ?

Try 1480cc  1080mc  for vega64 and 56 flashed to 64  i get 2100-2190hs depending on brand
And  1480cc  925mc  for vega 56  I get 2050hs for this.
All at 16+14.
Power table reg mod for 899mv

[kamisama233]

Here's an HTTP interface I wrote for the API.  Requires python/pip to be installed first, docs on GitHub should explain the rest.

https://github.com/rdugan/cgminerhttpinterface

Should be somewhat familiar to anyone used to stak/cast/srb/jce http reporting, and should hopefully make tuning/monitoring a little bit easier. 

After install, add the following to your miner startup .bat file, to auto-start the server in a new window alongside the miner.  Parameters are optional - values here are server defaults. Ctrl-c to exit.

Code:

SET HTTP_PORT=80
SET API_HOST=localhost
SET API_PORT=4028

start "TRM Monitor" chi-server -w %HTTP_PORT% -a %API_HOST% -p %API_PORT%

Enjoy!

excellent!
can you add a function reload config files, so it do not need to restart the miner?

[carlosmonaco]

What is the best tuning for RX Vega 56 and 64 reference blower.

I Use 1408/1090 (16+14) for vega 64
and 1413/945 (16+14) for Vega 56
I get 2030 Vega 64 and 1980 Vega 56, is it possible to get better ?

PS : Win 10 / 18.5.1 / PPT
I also get a lot of error -1 block expired
I find something weird too, even if I set 900mv or other things in OverdriveNtool I get 1250mv on HWInfo for memory voltage. For core it is the opposite when I set 905 it show 881mV and Core clock is also lower than the one set with overdrivntool. Any idea ?

https://ibb.co/b5ekC0

When you're running around 1408 core clk on a Vega 64, 15+15 is usually a better config than 16+14. On my Vega 64 LC at 1408/1100, I see ~2030 h/s with 16+14 and ~2095 h/s with 15+15, so that's probably worth trying. For the 56, just cycle through 16+14, 15+15, 14+14, 14-14 and see which one gives you the best results!

I can't say I have anything intelligent to say around the nrs you're ssing in HWInfo though .

Thanks I will try tomorrow .
Whatever I put on memory voltage with overdriventool hwinfo show 1250mv memory voltage for vega 56 and 1356mV for vega 64.
Is it possible to get the bus number for each card on the hashrate report ( I know it is at the begining) ?

Try 1480cc  1080mc  for vega64 and 56 flashed to 64  i get 2100-2190hs depending on brand
And  1480cc  925mc  for vega 56  I get 2050hs for this.
All at 16+14.
Power table reg mod for 899mv

Thanks I will try it this weekend, the rig using teamredminer crash during the night ( same setting I use without problem on srb) and I lost remote access to reboot it.
Is there a way to force win 10 restart when miner crash ?

[kerney666]

Thanks I will try it this weekend, the rig using teamredminer crash during the night ( same setting I use without problem on srb) and I lost remote access to reboot it.
Is there a way to force win 10 restart when miner crash ?

The watchdog will be included in the next release, should be out in a few days.

[carlosmonaco]

oh great , I will wait 

[peterboy1]

can you add versioning on the thread title? so we can be informed if there is an update?

btw, cast xmr has -fastjobswitch. does trm already implements this native? if not, it would be better if we have that option.

[pbfarmer]

can you add versioning on the thread title? so we can be informed if there is an update?

btw, cast xmr has -fastjobswitch. does trm already implements this native? if not, it would be better if we have that option.

What pool do you use?  supportxmr accepts most stales - if your pool does too, then you don't want to use fastjobswitch.  You'd just be throwing away work.

[pbfarmer]

Here's an HTTP interface I wrote for the API.  Requires python/pip to be installed first, docs on GitHub should explain the rest.

https://github.com/rdugan/cgminerhttpinterface

Should be somewhat familiar to anyone used to stak/cast/srb/jce http reporting, and should hopefully make tuning/monitoring a little bit easier. 

After install, add the following to your miner startup .bat file, to auto-start the server in a new window alongside the miner.  Parameters are optional - values here are server defaults. Ctrl-c to exit.

Code:

SET HTTP_PORT=80
SET API_HOST=localhost
SET API_PORT=4028

start "TRM Monitor" chi-server -w %HTTP_PORT% -a %API_HOST% -p %API_PORT%

Enjoy!

excellent!
can you add a function reload config files, so it do not need to restart the miner?

I have no affiliation w/ this miner, and the API is read only at this point - you'd have to ask the developers of the miner for this feature.

[kerney666]

can you add versioning on the thread title? so we can be informed if there is an update?

Excellent idea, we'll add it for the next release.

can you add versioning on the thread title? so btw, cast xmr has -fastjobswitch. does trm already implements this native? if not, it would be better if we have that option.

We can support an early abort mechanism, but it's not included right now. NiceHash is the only place where you would want it really. Like pbfarmer replied, you are throwing away gpu work every time a new job arrives otherwise. But, if you are 100% guaranteed than any found shares in the ongoing work will be rejected by the pool, then you should abort. We can look into introducing this mechanism if you want to try it.

[kerney666]

Here's an HTTP interface I wrote for the API.  Requires python/pip to be installed first, docs on GitHub should explain the rest.

https://github.com/rdugan/cgminerhttpinterface

Should be somewhat familiar to anyone used to stak/cast/srb/jce http reporting, and should hopefully make tuning/monitoring a little bit easier. 

After install, add the following to your miner startup .bat file, to auto-start the server in a new window alongside the miner.  Parameters are optional - values here are server defaults. Ctrl-c to exit.

Code:

SET HTTP_PORT=80
SET API_HOST=localhost
SET API_PORT=4028

start "TRM Monitor" chi-server -w %HTTP_PORT% -a %API_HOST% -p %API_PORT%

Enjoy!

excellent!
can you add a function reload config files, so it do not need to restart the miner?

Hi! I can't say that is on our TODO list, the downside of restarting the miner shouldn't be that big. Can you tell me more about what you would like to achieve with the changed config? Switching to another pool, another algo, turning on/off some gpus?

[ElvinCh]

Hello,
first I want to thank you for your hard work, you have done this very good software.
A few days ago I transferred a lot of my mining rings and I am very pleased with the results so far.
I have difficulty and I would like advice on how to achieve a better results with Saphire RX580 8GB Hynix.
What I have done so far:
1. I did tests with several types of BIOS: custom straps for Hynix whit nice result in ETH, one click BIOS from SRBPolarisV3.5 and PolarisBiosEditor1.6.7
2. I have used configurations 8+8, 8+7, 7+7, 15+15, 16+14
3. My settings are: core 1250/900mV and memory 2250/920mV with no hardware errors

In all cases my best results are 900H/s. 

Thanks in advance!

[ku4eto]

Hello,
first I want to thank you for your hard work, you have done this very good software.
A few days ago I transferred a lot of my mining rings and I am very pleased with the results so far.
I have difficulty and I would like advice on how to achieve a better results with Saphire RX580 8GB Hynix.
What I have done so far:
1. I did tests with several types of BIOS: custom straps for Hynix whit nice result in ETH, one click BIOS from SRBPolarisV3.5 and PolarisBiosEditor1.6.7
2. I have used configurations 8+8, 8+7, 7+7, 15+15, 16+14
3. My settings are: core 1250/900mV and memory 2250/920mV with no hardware errors

In all cases my best results are 900H/s. 

Thanks in advance!

good ETH straps =/= good CN straps.

One click BIOS straps are crap anyway.

And this miner benefits more from higher core clocks.

[peterboy1]

can you add versioning on the thread title? so we can be informed if there is an update?

Excellent idea, we'll add it for the next release.

can you add versioning on the thread title? so btw, cast xmr has -fastjobswitch. does trm already implements this native? if not, it would be better if we have that option.

We can support an early abort mechanism, but it's not included right now. NiceHash is the only place where you would want it really. Like pbfarmer replied, you are throwing away gpu work every time a new job arrives otherwise. But, if you are 100% guaranteed than any found shares in the ongoing work will be rejected by the pool, then you should abort. We can look into introducing this mechanism if you want to try it.

great! an option for an early abort would be nice. sometimes i like to mine at nicehash. since they wont pay for stales anyway, so an option for this will be helpful.

thanks.

oh, and btw, i tried srb with micron, and it can achieve 1kh/s. maybe you can do something about it. no bios/oc changed.

[peterboy1]

ok, here are my reports so far.

sometimes, the miner just doesnt submit any share for a long time, and needs to restart the miner. it hashes though, but no submits.

and my mixed gpu rig just cannot get the reported hashrate, both pool, and and client (pool report).

my uniform rig (all the same gpus) is ok.

sorry, cant back my reports with facts since we dont have logging yet.

[ku4eto]

Having some weird issue.

0.3.7 is far less stable than 0.3.6 when initiating.

Running 7-7 conf on 4 4GB cards.

When initiating the miner, one of the GPUs will have a thread failing and producing tons of HWs.

For some reason, seems to happen more often on XMR. When starting to mine graft, it does not appear so often.

WHen launching it on 0.3.6, no issues.

[kerney666]

Having some weird issue.

0.3.7 is far less stable than 0.3.6 when initiating.

Running 7-7 conf on 4 4GB cards.

When initiating the miner, one of the GPUs will have a thread failing and producing tons of HWs.

For some reason, seems to happen more often on XMR. When starting to mine graft, it does not appear so often.

WHen launching it on 0.3.6, no issues.

Yeah, with 0.3.7 we solved a lot of init issues, but a few weird new ones appeared as well. Are you under Linux or Windows? All known bugs right now are actually driver bugs. One example is the win driver that allocates the same mem space for two kernels in some multiple Polaris gpu settings. We triggered it when solving an earlier bug. We should hopefully solve it in the next version by addressing some code sizes.

The bug you’re describing sounds more like a Linux driver bug we’ve seen though. On every fourth restart of the miner, one command queue will go nuts and just fail running the kernels, but there is no error returned from the opencl api. On the next restart, all is fine again. Three more restarts and the same thing happens. Haven’t seen this on win though, so curious what os you’re running...