Topic: [Awesome Miner] - Powerful Windows GUI to manage and monitor up to 200000 miners - page 273. (Read 703148 times)
October 03, 2018, 08:41:33 AM
I need to have the capacity to switch between various mineworkers and furthermore include ewbf digger for zcash. Is there an approach to include ewbf or other right now non-recorded diggers and have them show measurements so it can participate in the multi motor benefit exchanging?
October 03, 2018, 08:23:38 AM
I configured rules for idle/use scenarios, but "stop miner" will also trigger if I manually press a Start button
How to prevent that?
I think the reason it will trigger Stop Miner is because the rule will detect that the system is in use if you press the Start button.How to prevent that?
I assume the miner is running on the Awesome Miner computer itself, and not on a Remote Agent?
October 03, 2018, 08:03:57 AM
Hi patrike,
Re: Registration code: Upgrade code issued
Does the old Reg code still work as well ?
Hi,Re: Registration code: Upgrade code issued
Does the old Reg code still work as well ?
If you have a license, for example Standard Edition and then you upgrade it to Professional Edition, you will receive a new license code for Professional Edition. Because you only paid for the price difference when upgrading, you need to use the new code you got for the Professional Edition. Your old code for Standard Edition can no longer be used and will eventually expire.
October 03, 2018, 08:02:02 AM
WildRig Multi 0.11.6 Beta is Becoming Even More Useful Multi-algorithm Miner
Hi Patrike,
+1 for integrating it into AM
The miner is somewhat using compatible commandline + API as XMRig so I could add it to AM as custom software without issue. But reading from the API seemed to have a bit of issue with the hashrate units so far.
eg, mining HMQ1725, API reports hashrate of 5000 kH/s, but AM is reading 5 kH/s FYI.
edit: it applies to tribus, bcd as well (i suspect all) that kH/s are all parsed as H/s
Hi Patrike,
Seems they have fixed the API reporting unit from kH/s to H/s so on unit inconsistencies side of things, this is not an issue anymore
Quote
0.11.9
- speedup x16r/x16s in some cases on final step
- fixed regress for simd, so should speedup x16r/x16s and return speed for other algos(bcd, sonoa, etc.)
- added hex algo
- now intensity can be set using sgminer-like numbers(old one supported too)
- improved API a bit, now threads contains hashrate per GPU, not per thread, so it should be correct now for HiveOS/etc.
- fixed GPU numbering at start when --opencl-threads used
0.11.8
- regen job now per GPU, should increase poolside hashrate
- added x16r, x16s and timetravel algorithms
- 30% boost for hmq1725
- grouped print of hashrate per GPU when use --opencl-threads parameter
- H/s unit in API instead of kH/s
- speedup x16r/x16s in some cases on final step
- fixed regress for simd, so should speedup x16r/x16s and return speed for other algos(bcd, sonoa, etc.)
- added hex algo
- now intensity can be set using sgminer-like numbers(old one supported too)
- improved API a bit, now threads contains hashrate per GPU, not per thread, so it should be correct now for HiveOS/etc.
- fixed GPU numbering at start when --opencl-threads used
0.11.8
- regen job now per GPU, should increase poolside hashrate
- added x16r, x16s and timetravel algorithms
- 30% boost for hmq1725
- grouped print of hashrate per GPU when use --opencl-threads parameter
- H/s unit in API instead of kH/s
But....now a new issue arises and I don't know which party should handle this, as suggested, it's more optimal to run multiple threads per GPU (via --opencl-threads) as per example posted in software's thread, but since the update to 0.11.9 from 0.11.6, AM is only reporting hashrate of 1 thread (I think it's the first) from each GPU, so say, my hashrate is now 8MH/s (4 MH/s per GPU) but running 3 threads per GPU, it is reporting 2.3MH/s to AM (or AM is reading 2.3 MH/s from the API anyway), below is the API output from the hashrate section:
Code:
"algo": "hmq1725",
"donate_level": 2,
"uptime": 2928,
"hashrate": {
"total": [
8331449,
8336995,
8342576
],
"highest": 8444092,
"threads": [
[
1133473,
1132772,
1133680
],
[
1141292,
1140633,
1130904
]
]
},
October 03, 2018, 07:39:38 AM
WildRig Multi 0.11.6 Beta is Becoming Even More Useful Multi-algorithm Miner
Hi Patrike,
+1 for integrating it into AM
The miner is somewhat using compatible commandline + API as XMRig so I could add it to AM as custom software without issue. But reading from the API seemed to have a bit of issue with the hashrate units so far.
eg, mining HMQ1725, API reports hashrate of 5000 kH/s, but AM is reading 5 kH/s FYI.
edit: it applies to tribus, bcd as well (i suspect all) that kH/s are all parsed as H/s
Hi Patrike,
Seems they have fixed the API reporting unit from kH/s to H/s so on unit inconsistencies side of things, this is not an issue anymore
Quote
0.11.9
- speedup x16r/x16s in some cases on final step
- fixed regress for simd, so should speedup x16r/x16s and return speed for other algos(bcd, sonoa, etc.)
- added hex algo
- now intensity can be set using sgminer-like numbers(old one supported too)
- improved API a bit, now threads contains hashrate per GPU, not per thread, so it should be correct now for HiveOS/etc.
- fixed GPU numbering at start when --opencl-threads used
0.11.8
- regen job now per GPU, should increase poolside hashrate
- added x16r, x16s and timetravel algorithms
- 30% boost for hmq1725
- grouped print of hashrate per GPU when use --opencl-threads parameter
- H/s unit in API instead of kH/s
- speedup x16r/x16s in some cases on final step
- fixed regress for simd, so should speedup x16r/x16s and return speed for other algos(bcd, sonoa, etc.)
- added hex algo
- now intensity can be set using sgminer-like numbers(old one supported too)
- improved API a bit, now threads contains hashrate per GPU, not per thread, so it should be correct now for HiveOS/etc.
- fixed GPU numbering at start when --opencl-threads used
0.11.8
- regen job now per GPU, should increase poolside hashrate
- added x16r, x16s and timetravel algorithms
- 30% boost for hmq1725
- grouped print of hashrate per GPU when use --opencl-threads parameter
- H/s unit in API instead of kH/s
But....now a new issue arises and I don't know which party should handle this, as suggested, it's more optimal to run multiple threads per GPU (via --opencl-threads) as per example posted in software's thread, but since the update to 0.11.9 from 0.11.6, AM is only reporting hashrate of 1 thread (I think it's the first) from each GPU, so say, my hashrate is now 8MH/s (4 MH/s per GPU) but running 3 threads per GPU, it is reporting 2.3MH/s to AM (or AM is reading 2.3 MH/s from the API anyway), below is the API output from the hashrate section:
Code:
"algo": "hmq1725",
"donate_level": 2,
"uptime": 2928,
"hashrate": {
"total": [
8331449,
8336995,
8342576
],
"highest": 8444092,
"threads": [
[
1133473,
1132772,
1133680
],
[
1141292,
1140633,
1130904
]
]
},
October 02, 2018, 04:36:04 PM
I configured rules for idle/use scenarios, but "stop miner" will also trigger if I manually press a Start button
How to prevent that?
How to prevent that?
October 02, 2018, 09:39:02 AM
Hi patrike,
Re: Registration code: Upgrade code issued
Does the old Reg code still work as well ?
Re: Registration code: Upgrade code issued
Does the old Reg code still work as well ?
October 02, 2018, 08:01:43 AM
The ASIC count for Dashboard will be fixed in the new release that will be available soon.
thank you!
October 02, 2018, 05:49:22 AM
WildRig Multi 0.11.6 Beta is Becoming Even More Useful Multi-algorithm Miner
Hi Patrike,
+1 for integrating it into AM
The miner is somewhat using compatible commandline + API as XMRig so I could add it to AM as custom software without issue. But reading from the API seemed to have a bit of issue with the hashrate units so far.
eg, mining HMQ1725, API reports hashrate of 5000 kH/s, but AM is reading 5 kH/s FYI.
edit: it applies to tribus, bcd as well (i suspect all) that kH/s are all parsed as H/s
Hi Patrike,
Seems they have fixed the API reporting unit from kH/s to H/s so on unit inconsistencies side of things, this is not an issue anymore
Quote
0.11.9
- speedup x16r/x16s in some cases on final step
- fixed regress for simd, so should speedup x16r/x16s and return speed for other algos(bcd, sonoa, etc.)
- added hex algo
- now intensity can be set using sgminer-like numbers(old one supported too)
- improved API a bit, now threads contains hashrate per GPU, not per thread, so it should be correct now for HiveOS/etc.
- fixed GPU numbering at start when --opencl-threads used
0.11.8
- regen job now per GPU, should increase poolside hashrate
- added x16r, x16s and timetravel algorithms
- 30% boost for hmq1725
- grouped print of hashrate per GPU when use --opencl-threads parameter
- H/s unit in API instead of kH/s
- speedup x16r/x16s in some cases on final step
- fixed regress for simd, so should speedup x16r/x16s and return speed for other algos(bcd, sonoa, etc.)
- added hex algo
- now intensity can be set using sgminer-like numbers(old one supported too)
- improved API a bit, now threads contains hashrate per GPU, not per thread, so it should be correct now for HiveOS/etc.
- fixed GPU numbering at start when --opencl-threads used
0.11.8
- regen job now per GPU, should increase poolside hashrate
- added x16r, x16s and timetravel algorithms
- 30% boost for hmq1725
- grouped print of hashrate per GPU when use --opencl-threads parameter
- H/s unit in API instead of kH/s
But....now a new issue arises and I don't know which party should handle this, as suggested, it's more optimal to run multiple threads per GPU (via --opencl-threads) as per example posted in software's thread, but since the update to 0.11.9 from 0.11.6, AM is only reporting hashrate of 1 thread (I think it's the first) from each GPU, so say, my hashrate is now 8MH/s (4 MH/s per GPU) but running 3 threads per GPU, it is reporting 2.3MH/s to AM (or AM is reading 2.3 MH/s from the API anyway), below is the API output from the hashrate section:
Code:
"algo": "hmq1725",
"donate_level": 2,
"uptime": 2928,
"hashrate": {
"total": [
8331449,
8336995,
8342576
],
"highest": 8444092,
"threads": [
[
1133473,
1132772,
1133680
],
[
1141292,
1140633,
1130904
]
]
},
October 02, 2018, 03:45:51 AM
Awesome Miner version 5.6.1
- Added a guide for Antminer and ASIC miner troubleshooting - can be accessed via the Antminer Diagnostics dialog
- Notification actions can be configured with a custom authorization header for webhooks
- Added more predefined Block Explorers for wallet balance
- Include more detailed information about the Awesome Miner license and subscription via the status bar button for license information
- Z-enemy miner 1.21
- CryptoDredge 0.9.2
- EWBF Equihash Miner 0.6
- Bminer 10.4, with support for Personalization flag
- Correction to path for uploaded software on Remote Agent for Linux
- Correction to ASIC device count on dashboard when running a system with a mix of GPU and ASIC miners
- Added a guide for Antminer and ASIC miner troubleshooting - can be accessed via the Antminer Diagnostics dialog
- Notification actions can be configured with a custom authorization header for webhooks
- Added more predefined Block Explorers for wallet balance
- Include more detailed information about the Awesome Miner license and subscription via the status bar button for license information
- Z-enemy miner 1.21
- CryptoDredge 0.9.2
- EWBF Equihash Miner 0.6
- Bminer 10.4, with support for Personalization flag
- Correction to path for uploaded software on Remote Agent for Linux
- Correction to ASIC device count on dashboard when running a system with a mix of GPU and ASIC miners
October 02, 2018, 03:14:47 AM
I have a question - I currently have 5 ASICs, 2 GPU and 2 CPU mining rigs connected to Awesome Miner. However on the dashboard, it shows a total of 9 and that all 9 are active. So far that is right - but then in the next area, it shows 2 GPU 8 CPU and 9 ASICs (I realize it is counting the cores for CPU but why does it have all the miners grouped under ASICs? And with my CPU's and GPU's it shows the profits that those miners make but not for the ASICs - I have to manually log into the pool to see that.
Is there also any way to link our wallets so that we can see our balances in the Awesome Miner Interface? - edit: I have found the area to do this and am working to add my various wallets. second edit... my main wallet generates a different address for each transaction, so it seems I have to link quite a few "wallets"
The ASIC count for Dashboard will be fixed in the new release that will be available soon. Is there also any way to link our wallets so that we can see our balances in the Awesome Miner Interface? - edit: I have found the area to do this and am working to add my various wallets. second edit... my main wallet generates a different address for each transaction, so it seems I have to link quite a few "wallets"
October 02, 2018, 03:13:42 AM
@patrike
Can be changed --devices to -d in the ccminer configuration?. To achieve greater compatibility in the user defined mining software. I do not know if this change would be detrimental to other mining software
This is a good point and I was considering making this change when I found out that some ccminer clones uses "--device" while other uses "--devices", while "-d" looked like a more universal solution. I was however a bit afraid of breaking things, but I can investigate this in more detail and make the change next time I make a development version available. Thanks for your feedback. Can be changed --devices to -d in the ccminer configuration?. To achieve greater compatibility in the user defined mining software. I do not know if this change would be detrimental to other mining software
October 02, 2018, 03:10:24 AM
I might need a bit more details about this scenario. Is TeamRedMiner added as a Managed Software? Compatible with Ccminer or similar? Have you explicitly enabled a few algorithms for it in the same dialog where you set the compatibility?
Yes, it is added as managed software, CCMINER command line compatible with no API. Lyra2Z algo enabled.Can you share the log lines just above those you provided, saying something like "GetStaticSortedPools, Enginetype: ". On that line it should also list the algorithms.
In the Managed Software configuration, I assume you made sure that it's not only says "Enabled" in the Default-column, but that it also says "Enabled" (or "Default") in the next column called "Enabled / Disabled"?
October 01, 2018, 10:56:08 PM
Hi to community.
Please, advice, is there any way, to do the following...
The situation: There is a managed local miner created with the selected ETH pool. There is a rule for this miner, that switch a pool to ETC at the specified time, and the 2nd rule, that switch the pool back to ETH, also st the specified time.
The problem: if the pool was changed to ETC, and during the miner work the rig hangs/crashes, after system reboot it's back to ETH, that selected in the managed miner settings.
The question: How to prevent switching back to ETH pool, after the rig crashes and Awesome Miner restarts? Is there any way to force Awesome to remember the last settings?
Tnanks in advance.
Please, advice, is there any way, to do the following...
The situation: There is a managed local miner created with the selected ETH pool. There is a rule for this miner, that switch a pool to ETC at the specified time, and the 2nd rule, that switch the pool back to ETH, also st the specified time.
The problem: if the pool was changed to ETC, and during the miner work the rig hangs/crashes, after system reboot it's back to ETH, that selected in the managed miner settings.
The question: How to prevent switching back to ETH pool, after the rig crashes and Awesome Miner restarts? Is there any way to force Awesome to remember the last settings?
Tnanks in advance.
(hypothesising) Have you tried creating this rule with 2 Time triggers? such that it gets checked say, every 5 minutes with the first trigger, and then make a following trigger based on Time/Week of the day and select "Match All" (AND), maybe it'll do the trick.
maybe you have to clone several of the above rules since the Time option only triggers at particular instant and not between x:xx to y:yy, maybe Patrike can see about this type of implementation, you'd have to make a request though.
I personally used a similar triggers to switch pool (groups), but the way I did was to have the high preference pool switch trigger at every 15min and low priority pools at 100min, bit of borrowed idea from DevFees, but of course, works rather differently as they are 2 concurrent running rules rather than a fixed percentage and overlaps are obviously, different as time lapses.
October 01, 2018, 06:36:33 PM
I have a question - I currently have 5 ASICs, 2 GPU and 2 CPU mining rigs connected to Awesome Miner. However on the dashboard, it shows a total of 9 and that all 9 are active. So far that is right - but then in the next area, it shows 2 GPU 8 CPU and 9 ASICs (I realize it is counting the cores for CPU but why does it have all the miners grouped under ASICs? And with my CPU's and GPU's it shows the profits that those miners make but not for the ASICs - I have to manually log into the pool to see that.
Is there also any way to link our wallets so that we can see our balances in the Awesome Miner Interface? - edit: I have found the area to do this and am working to add my various wallets. second edit... my main wallet generates a different address for each transaction, so it seems I have to link quite a few "wallets"
Is there also any way to link our wallets so that we can see our balances in the Awesome Miner Interface? - edit: I have found the area to do this and am working to add my various wallets. second edit... my main wallet generates a different address for each transaction, so it seems I have to link quite a few "wallets"
October 01, 2018, 06:16:59 PM
@patrike
Can be changed --devices to -d in the ccminer configuration?. To achieve greater compatibility in the user defined mining software. I do not know if this change would be detrimental to other mining software
Can be changed --devices to -d in the ccminer configuration?. To achieve greater compatibility in the user defined mining software. I do not know if this change would be detrimental to other mining software
October 01, 2018, 08:09:44 AM
Worked around this by specifying the path to the miner with a full explicit path "/root/.local/share/AwesomeMinerService/UploadedSoftware/teamredminer-v0.3.1/teamredminer"
I will correct the path issue for uploaded software in the next release. Thanks for finding out the scenario and sharing all details.EDIT: And on to the next problem. I've now converted to a managed miner and get the following strange error:
I might need a bit more details about this scenario. Is TeamRedMiner added as a Managed Software? Compatible with Ccminer or similar? Have you explicitly enabled a few algorithms for it in the same dialog where you set the compatibility?Code:
9/28/18 4:45:30 PM.964 [016] [S][ManagedMiner#20 - random] : GetStaticSortedPools, ignoring pools: stratum+tcp://blockmasters.co:4553, Lyra2z. stratum+tcp://us-east.ethash-hub.miningpoolhub.com:17020, Ethereum. etc-us-east1.nanopool.org:19999, Ethereum. stratum+tcp://eth-us-east1.nanopool.org:9999, Ethereum. pirl.minerpool.net:8004, Ethereum. stratum+tcp://us-east.lyra2z-hub.miningpoolhub.com:17025, Lyra2z. stratum+tcp://lyra2z.mine.blazepool.com:4553, Lyra2z. stratum+tcp://us-east.lyra2z-hub.miningpoolhub.com:20581, Lyra2z. stratum+tcp://lyra2z.na.mine.zpool.ca:4553, Lyra2z. stratum+tcp://lyra2z.mine.zergpool.com:4553, Lyra2z. stratum+tcp://lyra2z.mine.ahashpool.com:4553, Lyra2z. stratum+tcp://lyra2z.us.hashrefinery.com:4553, Lyra2z. stratum+tcp://67.40.164.173:3833, ProgPow.
9/28/18 4:45:30 PM.964 [016] [S][ManagedMiner#20 - random] : Adding pool:
9/28/18 4:45:30 PM.964 [016] [S]Set execution permission for: /root/.local/share/AwesomeMinerService/UploadedSoftware/teamredminer-v0.3.1/teamredminer
9/28/18 4:45:30 PM.964 [016] [S][ManagedMiner#20 - random] : Adding pool:
9/28/18 4:45:30 PM.964 [016] [S]Set execution permission for: /root/.local/share/AwesomeMinerService/UploadedSoftware/teamredminer-v0.3.1/teamredminer
October 01, 2018, 07:41:10 AM
Hi to community.
Please, advice, is there any way, to do the following...
The situation: There is a managed local miner created with the selected ETH pool. There is a rule for this miner, that switch a pool to ETC at the specified time, and the 2nd rule, that switch the pool back to ETH, also st the specified time.
The problem: if the pool was changed to ETC, and during the miner work the rig hangs/crashes, after system reboot it's back to ETH, that selected in the managed miner settings.
The question: How to prevent switching back to ETH pool, after the rig crashes and Awesome Miner restarts? Is there any way to force Awesome to remember the last settings?
Tnanks in advance.
Please, advice, is there any way, to do the following...
The situation: There is a managed local miner created with the selected ETH pool. There is a rule for this miner, that switch a pool to ETC at the specified time, and the 2nd rule, that switch the pool back to ETH, also st the specified time.
The problem: if the pool was changed to ETC, and during the miner work the rig hangs/crashes, after system reboot it's back to ETH, that selected in the managed miner settings.
The question: How to prevent switching back to ETH pool, after the rig crashes and Awesome Miner restarts? Is there any way to force Awesome to remember the last settings?
Tnanks in advance.
October 01, 2018, 07:04:26 AM
Hello Patrik,
could you please add the very very new Lyra2Z WIN miner TeamRedMiner v0.3.2 ? It is working properly but i would like to see more info in AM(i guess they need to add reports etc. too).
Thank you!
could you please add the very very new Lyra2Z WIN miner TeamRedMiner v0.3.2 ? It is working properly but i would like to see more info in AM(i guess they need to add reports etc. too).
Thank you!
I am also running new teamredminer-v.0.3.2-win windows version with Vega 56. Getting 8Mh/s phi2 and 5Mh/s lyra2z on Vega56. But no api info for AM.
October 01, 2018, 07:02:44 AM
Why hasrate/consumption does not scale linearly? I mean I have a set HR for X16 algo, 150Mh @1300W, take out some cards from the system, and it shows a negative income, while the one with all 6 cards shows positive. It happens on all algos.
You need to use the concept of Profile Groups in this scenario (see link below). It's fully possible to have a mix of different GPU types, and Awesome Miner needs to know how many of each GPU's in order to know the power consumption for the profit switching feature. https://support.awesomeminer.com/support/solutions/articles/35000086086-profit-switching-for-gpu-and-cpu-mining#profile
That is stupid, why can't you just make a normal linear relation to the set HR/W. I mean if in any set algo 10KH@1000w then 1KH&100w. Its just not working. Even if an asic board is out, its just shows false profit.
If all your GPU's are identical, I do see your point that it can make sense to support this kind of linear approximation (although it's not fully true because underclocking typically gives higher hashrate per Watt compared to Overclocking). I will consider adding a setting for this.
Jump to: