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
Topic: [ANN] TeamRedMiner v0.10.10 - Ironfish/Kaspa/ZIL/Kawpow/Etchash and More - page 130. (Read 211959 times)
November 14, 2018, 03:35:25 PM
November 14, 2018, 01:33:26 PM
I will also advertise my shell script for the API monitoring.
https://github.com/OhGodADog/sgminer-api-stats-script
The thoughts count
https://github.com/OhGodADog/sgminer-api-stats-script
The thoughts count
November 14, 2018, 01:00:43 PM
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.
November 14, 2018, 12:17:20 PM
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!
November 14, 2018, 11:19:47 AM
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.
November 14, 2018, 11:11:03 AM
2.5% fee and cant add basic features like from other miners
Well, duh, its still Beta.
November 14, 2018, 10:02:29 AM
2.5% fee and cant add basic features like from other miners
November 14, 2018, 09:27:52 AM
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?
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?
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.
November 14, 2018, 07:43:30 AM
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?
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?
November 14, 2018, 05:48:42 AM
@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.
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:
"
Restart gpus w/ devcon (vegas):
"
timeout /t 3
"
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 ...
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.
November 13, 2018, 04:31:08 PM
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...
November 13, 2018, 04:06:33 PM
@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.
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.
November 13, 2018, 03:37:02 PM
@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.
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!
November 13, 2018, 09:03:51 AM
@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.
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.
November 13, 2018, 05:10:12 AM
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.
Enjoy!
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%
SET API_HOST=localhost
SET API_PORT=4028
start "TRM Monitor" chi-server -w %HTTP_PORT% -a %API_HOST% -p %API_PORT%
Enjoy!
November 13, 2018, 03:44:16 AM
when will be api ready for monitor?
November 12, 2018, 10:15:29 PM
@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.
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.
November 12, 2018, 07:40:41 PM
@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.
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.
November 12, 2018, 06:36:27 PM
@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.
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.
November 12, 2018, 04:00:32 PM
something wrong on nanopool with this miner newer seen smthg like this on SRB.and sometimes rig power consumption decrase to 100w from 1300w's
all it's clearly possible to understand from vega's fan noise.Usualy do this every 5 min. maybe much more early.
all it's clearly possible to understand from vega's fan noise.Usualy do this every 5 min. maybe much more early.
Code:
2018-11-10 22:54:53] Pool xmr-eu1.nanopool.org invalid RPC ID received. (If this error repeats, try using the --pool_broken_rpc option.)
[2018-11-10 22:54:53] Pool xmr-eu1.nanopool.org failed to parse server rpc: {"id":40,"jsonrpc":"2.0","result":{"status":"OK"},"error":null}
[2018-11-10 22:54:54] Stats Uptime: 0 days, 00:43:01
[2018-11-10 22:54:54] GPU 0 - cnv8: 1.016kh/s, avg 1.009kh/s, pool 1.211kh/s a:26 r:0 hw:0
Yes, quite clearly documented both in the release docs, and for your convenience also in the log you’re pasting yourself.
Have you enabled —pool_broken_rpc as mentioned above? We might do this by default going forward. The issue is that nanopool can’t handle multiple outstanding requests.
Cheers, K
hi
already add" —pool_broken_rpc to config " but it seems that i'ts same same.After this stuation some of the cards on rigs takes vddc to 1.15v(and have to reconfigıre overdrivventool) and too much heat and consumption appears.i switched all rigs back to srb,no problem on vega side..
Jump to: