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

[kerney666]

@kerney666

when's the gpu watchdog feature going to be added.  The miner loses a card after several hours and it's not usually the same card.

Detecting it is trivial really, question is what behavior you want supported next? Executing a restart.sh/restart.bat script in the current dir? Imho the best thing when you have a driver hang is a reboot anyway, not sure an in-process restart of all gpus would be successful in that many cases.

[1715380731]

1715380731

[1715380731]

1715380731

[heavyarms1912]

@kerney666

when's the gpu watchdog feature going to be added.  The miner loses a card after several hours and it's not usually the same card.

Detecting it is trivial really, question is what behavior you want supported next? Executing a restart.sh/restart.bat script in the current dir? Imho the best thing when you have a driver hang is a reboot anyway, not sure an in-process restart of all gpus would be successful in that many cases.

Reboot script would be great. Yup it's typically stuck in driver and a hard reboot is required.  However, right now GPU won't hash while it still consumes power.

[kamisama233]

when will be api ready for monitor?

[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!

[seefatlow]

@kerney666

when's the gpu watchdog feature going to be added.  The miner loses a card after several hours and it's not usually the same card.

Detecting it is trivial really, question is what behavior you want supported next? Executing a restart.sh/restart.bat script in the current dir? Imho the best thing when you have a driver hang is a reboot anyway, not sure an in-process restart of all gpus would be successful in that many cases.

Reboot script would be great. Yup it's typically stuck in driver and a hard reboot is required.  However, right now GPU won't hash while it still consumes power.

Yes, this miner desperately needs an error handler. An option to shutdown/reboot would be nice to stop GPU from consuming power with zero hashes.

[tvukoman]

@kerney666

when's the gpu watchdog feature going to be added.  The miner loses a card after several hours and it's not usually the same card.

Detecting it is trivial really, question is what behavior you want supported next? Executing a restart.sh/restart.bat script in the current dir? Imho the best thing when you have a driver hang is a reboot anyway, not sure an in-process restart of all gpus would be successful in that many cases.

Reboot script would be great. Yup it's typically stuck in driver and a hard reboot is required.  However, right now GPU won't hash while it still consumes power.

Yes, this miner desperately needs an error handler. An option to shutdown/reboot would be nice to stop GPU from consuming power with zero hashes.

kerney, when developing watchdog, can you make option to: restart miner + reset vega cards + reapply OverdriveNtool? Like SRB have?
For me, never need to reboot whole rig, restarting, reseting vega and reapply clocks and voltages and mining is ok again...

And is it possible now in start.bat input code to reset vega cards with devcon or something, apply overdriveNtool and start mining? Any examples?

Txs!

[ku4eto]

@kerney666

when's the gpu watchdog feature going to be added.  The miner loses a card after several hours and it's not usually the same card.

Detecting it is trivial really, question is what behavior you want supported next? Executing a restart.sh/restart.bat script in the current dir? Imho the best thing when you have a driver hang is a reboot anyway, not sure an in-process restart of all gpus would be successful in that many cases.

Reboot script would be great. Yup it's typically stuck in driver and a hard reboot is required.  However, right now GPU won't hash while it still consumes power.

Yes, this miner desperately needs an error handler. An option to shutdown/reboot would be nice to stop GPU from consuming power with zero hashes.

kerney, when developing watchdog, can you make option to: restart miner + reset vega cards + reapply OverdriveNtool? Like SRB have?
For me, never need to reboot whole rig, restarting, reseting vega and reapply clocks and voltages and mining is ok again...

And is it possible now in start.bat input code to reset vega cards with devcon or something, apply overdriveNtool and start mining? Any examples?

Txs!

This is really useless. You are asking for the miner to be idiot proof and friendly.

The watchdog restarting the miner is EXTREMELY HARD under Windows. And is borderline virus. Reseting Vega cards? You probably mean the "disable/enable" the Device. This is the same level of difficulty. And it can lead to LOTS of complications. Also, apply OverDriveNTool? Why would the miner need to support functionality for 3rd party software, which only some people use? SRB is NOT a good example for a good miner. For various reasons.

I would suggest you to find a way to make this script (.bat) by yourself, not to expect a miner developer to cater for stuff, that is not related with the miner itself.

[kerney666]

kerney, when developing watchdog, can you make option to: restart miner + reset vega cards + reapply OverdriveNtool? Like SRB have?
For me, never need to reboot whole rig, restarting, reseting vega and reapply clocks and voltages and mining is ok again...

And is it possible now in start.bat input code to reset vega cards with devcon or something, apply overdriveNtool and start mining? Any examples?

Txs!

We'll detect the state where the miner thread(s) for a gpu is stuck in an OpenCL API call, and there has been zero new hashes reported for the gpu for ~20 secs. At that point we (1) attempt to shut down the miner, like if you'd press ctrl-c and (2) execute a user .bat/shell script in a forked process, i.e. in parallel with the shutdown.

Now, what you choose to do in that .bat/shell script is entirely up to you. If you're sure you'll get an ok miner shutdown, then wait 20 secs + reset cards + apply clocks + start miner, in your .bat file. For others, it's more likely they'll do a "shutdown /r now". I mean, on my testing workstation I'm even having a hard time to get a clean reboot when I mistreat my Vega too badly, I need a manual power cycle. So, in the general case the guarantees we can provide are very weak. We'll let you run a .bat file, that's pretty much it.

For examples, sure, we can whip up some restart.bat examples, or other people can post theirs here. I have the devcon Vega restart snippets somewhere, been a while since I last used them...

[pbfarmer]

@kerney666

when's the gpu watchdog feature going to be added.  The miner loses a card after several hours and it's not usually the same card.

Detecting it is trivial really, question is what behavior you want supported next? Executing a restart.sh/restart.bat script in the current dir? Imho the best thing when you have a driver hang is a reboot anyway, not sure an in-process restart of all gpus would be successful in that many cases.

Reboot script would be great. Yup it's typically stuck in driver and a hard reboot is required.  However, right now GPU won't hash while it still consumes power.

Yes, this miner desperately needs an error handler. An option to shutdown/reboot would be nice to stop GPU from consuming power with zero hashes.

kerney, when developing watchdog, can you make option to: restart miner + reset vega cards + reapply OverdriveNtool? Like SRB have?
For me, never need to reboot whole rig, restarting, reseting vega and reapply clocks and voltages and mining is ok again...

And is it possible now in start.bat input code to reset vega cards with devcon or something, apply overdriveNtool and start mining? Any examples?

Txs!

As others have pointed out, this stuff doesn't really belong in the miner, and is incredibly easy to add to your startup script...

Apply settings w/ overdriventool:
"<Installation path>\OverdriveNTool.exe" -consoleonly -r<gpu_index> -p<gpu_index><gpu_profile_name>

Restart gpus w/ devcon (vegas):
"<Installation path>\devcon.exe" disable "PCI\VEN_1002&DEV_687F"
timeout /t 3
"<Installation path>\devcon.exe" enable "PCI\VEN_1002&DEV_687F"

For example:

Code:

"C:\Users\pbfarmer\mining\OverdriveNTool.exe" -consoleonly -r1 -r2 -p1vega-profile-1 -p2vega-profile-2
timeout /t 3

"C:\Users\pbfarmer\mining\devcon.exe" disable "PCI\VEN_1002&DEV_687F"
timeout /t 3
"C:\Users\pbfarmer\mining\devcon.exe" enable "PCI\VEN_1002&DEV_687F"
timeout /t 3

teamredminer.exe ...

Btw, restarting w/ devcon shouldn't be necessary w/ any recent driver version.

[MoneroCrusher]

It looks like TRM (as opposed to xmr-stak) is sending out shares for each GPU instead of the miner as a whole (I verified with xmrig-proxy with same machine and amount of GPUs running TRM vs. xmr-stak). This unnecessarily increases network and pool load.
Is it possible to let users decide with a parameter in which way shares should be sent?

Also: All my workers are offline due to OPSEC concerns and I send all my shares to my proxy which is the only thing connected to the internet and tightly controlled.
So when dev pool wants to connect it throws and error. Could somebody with good network knowledge please tell me how I can make the dev pool forward to my server/proxy so that it then sends the dev shares to the right place and that I can keep on mining?

[kerney666]

It looks like TRM (as opposed to xmr-stak) is sending out shares for each GPU instead of the miner as a whole (I verified with xmrig-proxy with same machine and amount of GPUs running TRM vs. xmr-stak). This unnecessarily increases network and pool load.
Is it possible to let users decide with a parameter in which way shares should be sent?

I'm sorry man, but this is very confusing. As you also can verify looking at tcp/ip traffic, we only have one pool connection to your xmrig-proxy per miner instance. This means all gpus in trm are always working on the same job from the same pool, anything else is impossible. This single pool connection provides the job and share difficulty target. Then, all gpus go to work scanning a nonce space. If a nonce matching the share difficulty is found, you either submit it or you are willingly lowering your poolside hashrate and throwing away time spent on the gpu. That's it. There is no other way to do mining or different ways to send shares.

For fun, we can reason more about this, but the data missing is (1) how long did you run for, (2) was the diff provided by your xmrig-proxy both static and equal during your two runs, (3) what was the miner hashrate and static diff and (4) how many shares were found by stak vs trm during your trials.

Without (1) and (2) the tests are useless since you're comparing apples and oranges. The rest is to approximate the probability of the scenario happening using a few Poisson calculations.

Also: All my workers are offline due to OPSEC concerns and I send all my shares to my proxy which is the only thing connected to the internet and tightly controlled.
So when dev pool wants to connect it throws and error. Could somebody with good network knowledge please tell me how I can make the dev pool forward to my server/proxy so that it then sends the dev shares to the right place and that I can keep on mining?

Find me on the discord and I'll help you set it up, no worries. You will need to run tcp/ip forwarding on your DMZ box.

[wtfonly16]

2.5% fee and cant add basic features like from other miners

 

[ku4eto]

2.5% fee and cant add basic features like from other miners

 

Well, duh, its still Beta.

[kerney666]

2.5% fee and cant add basic features like from other miners

 

For some reason you seem upset

The features will be there in due time, one by one. Arguing you're worth a high dev fee because you have colors feels a little weird, no? I would assume it's more about performance first, then features, and probably more look at your bottom line numbers using hashrate and power draw as a miner to determine if the dev fee is worth it or not.

Watchdog is pretty much done, we have a few more small things on the todo list, then the next release will be out.

[wtfonly16]

2.5% fee and cant add basic features like from other miners

 

For some reason you seem upset

The features will be there in due time, one by one. Arguing you're worth a high dev fee because you have colors feels a little weird, no? I would assume it's more about performance first, then features, and probably more look at your bottom line numbers using hashrate and power draw as a miner to determine if the dev fee is worth it or not.

Watchdog is pretty much done, we have a few more small things on the todo list, then the next release will be out.

i did not know the miner was beta. my numbers put this miner at #1 in all fields performance even with 2.5% fee factored in. i have put one of my rigs on the miner and looks good so far. i will patiently wait for api and watchdog in the future!

[kerney666]

2.5% fee and cant add basic features like from other miners

 

For some reason you seem upset

The features will be there in due time, one by one. Arguing you're worth a high dev fee because you have colors feels a little weird, no? I would assume it's more about performance first, then features, and probably more look at your bottom line numbers using hashrate and power draw as a miner to determine if the dev fee is worth it or not.

Watchdog is pretty much done, we have a few more small things on the todo list, then the next release will be out.

i did not know the miner was beta. my numbers put this miner at #1 in all fields performance even with 2.5% fee factored in. i have put one of my rigs on the miner and looks good so far. i will patiently wait for api and watchdog in the future!

No worries man, we're aware of what we're missing. The API already exists though, but it's compatible with the sgminer/cgminer API, not the type of API that CN miners are normally used to. It is integrated into a number of tools, Awesome Miner being one of them. Temps and fans are missing in the API though since we haven't added ADL/sysfs support yet. I also have a TODO entry about building a little proxy adapter that will give you a xmr stak-like API + web view.

For the time being, this is a community contribution that provides an http adapter for the API: https://github.com/rdugan/cgminerhttpinterface. Don't know if it could be of interest to you.

[ku4eto]

I will also advertise my shell script for the API monitoring.
https://github.com/OhGodADog/sgminer-api-stats-script

The thoughts count

[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

[tvukoman]

kerney, when developing watchdog, can you make option to: restart miner + reset vega cards + reapply OverdriveNtool? Like SRB have?
For me, never need to reboot whole rig, restarting, reseting vega and reapply clocks and voltages and mining is ok again...

And is it possible now in start.bat input code to reset vega cards with devcon or something, apply overdriveNtool and start mining? Any examples?

Txs!

As others have pointed out, this stuff doesn't really belong in the miner, and is incredibly easy to add to your startup script...

Apply settings w/ overdriventool:
"<Installation path>\OverdriveNTool.exe" -consoleonly -r<gpu_index> -p<gpu_index><gpu_profile_name>

Restart gpus w/ devcon (vegas):
"<Installation path>\devcon.exe" disable "PCI\VEN_1002&DEV_687F"
timeout /t 3
"<Installation path>\devcon.exe" enable "PCI\VEN_1002&DEV_687F"

For example:

Code:

"C:\Users\pbfarmer\mining\OverdriveNTool.exe" -consoleonly -r1 -r2 -p1vega-profile-1 -p2vega-profile-2
timeout /t 3

"C:\Users\pbfarmer\mining\devcon.exe" disable "PCI\VEN_1002&DEV_687F"
timeout /t 3
"C:\Users\pbfarmer\mining\devcon.exe" enable "PCI\VEN_1002&DEV_687F"
timeout /t 3

teamredminer.exe ...

Btw, restarting w/ devcon shouldn't be necessary w/ any recent driver version.

Thank you pbfarmer, works, and it is very simple (now for me too) :-)
I know there is no need to enable/disable Vegas on Adrenalin drivers, But, if my one problematic vega 56 "hang" on mining, i need to enable/disable it and again apply overdriveNtool (sometimes, not always, when card crash, it was reset in overdrive). I don't know why, but disable / enable and reapply ONT work for my rig in most cases on different miners.

We'll detect the state where the miner thread(s) for a gpu is stuck in an OpenCL API call, and there has been zero new hashes reported for the gpu for ~20 secs. At that point we (1) attempt to shut down the miner, like if you'd press ctrl-c and (2) execute a user .bat/shell script in a forked process, i.e. in parallel with the shutdown.

Now, what you choose to do in that .bat/shell script is entirely up to you. If you're sure you'll get an ok miner shutdown, then wait 20 secs + reset cards + apply clocks + start miner, in your .bat file. For others, it's more likely they'll do a "shutdown /r now". I mean, on my testing workstation I'm even having a hard time to get a clean reboot when I mistreat my Vega too badly, I need a manual power cycle. So, in the general case the guarantees we can provide are very weak. We'll let you run a .bat file, that's pretty much it.

For examples, sure, we can whip up some restart.bat examples, or other people can post theirs here. I have the devcon Vega restart snippets somewhere, been a while since I last used them...

Kerney thanks for clarification, now with the help and examples, everything is clear to me, and I know that reboot is safer solution...
For testing start.bat now, i was forced to close down the miner after 1 day and 22 hours of mining without a problem :-)
Great stable miner is TRM!

[kerney666]

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 .