[Awesome Miner] - Powerful Windows GUI to manage and monitor up to 200000 miners - page 273.

Allo-4ka

newbie

Activity: 71

Merit: 0

patrike

I stumbled on the Internet for two more online calculators, can I also collect statistics from them?
https://crypt0.zone/
https://shittomine.com/
the second refers to the little-known coins, but in turn they are fired up to x10

Question: when statistics are collected for the same coin, IMHO to calculate the average figure? because sometimes there is a 2-3 times difference

sergw

member

Activity: 159

Merit: 12

Hello, i have some problems with Awesome Miner, i installed it on small laptop nb33 with intel atom 1.33 ghz cpu and 2MB memory, with just 35-40 devices it works very very slow and often hangs, do you have any advices on how to make it run normally?

soothaa

hero member

Activity: 1151

Merit: 528

Strange bug with the Linux client report.

Code:

./awesome-upgrade.sh

./service-install.sh

./service-start.sh

root@simpleminer:~/awesomeminer-remoteagent# ps aux | grep awesome
root 4942 0.0 0.0 14224 992 pts/0 S+ 14:02 0:00 grep --color=auto awesome
root 18900 0.0 0.0 27344 2828 ? Ss Sep28 0:04 SCREEN -dmS awesome0001 /root/.local/share/AwesomeMinerService/UploadedSoftware/teamredminer-v0.3.1/awesome-start.sh
root 18902 0.0 0.0 12528 3076 pts/2 Ss+ Sep28 0:00 /bin/bash /root/.local/share/AwesomeMinerService/UploadedSoftware/teamredminer-v0.3.1 awesome-start.sh

root@simpleminer:~/awesomeminer-remoteagent# ./service-log.sh
-- Logs begin at Thu 2018-10-04 09:23:05 CEST. --
Oct 04 14:01:30 simpleminer systemd[1]: awesome.service: Service hold-off time over, scheduling restart.
Oct 04 14:01:30 simpleminer systemd[1]: Stopped Awesome Miner Remote Agent.
Oct 04 14:01:30 simpleminer systemd[1]: Started Awesome Miner Remote Agent.
Oct 04 14:01:30 simpleminer systemd[1]: awesome.service: Main process exited, code=exited, status=203/EXEC
Oct 04 14:01:30 simpleminer systemd[1]: awesome.service: Unit entered failed state.
Oct 04 14:01:30 simpleminer systemd[1]: awesome.service: Failed with result 'exit-code'.
Oct 04 14:01:30 simpleminer systemd[1]: awesome.service: Service hold-off time over, scheduling restart.
Oct 04 14:01:30 simpleminer systemd[1]: Stopped Awesome Miner Remote Agent.
Oct 04 14:01:30 simpleminer systemd[1]: awesome.service: Start request repeated too quickly.
Oct 04 14:01:30 simpleminer systemd[1]: Failed to start Awesome Miner Remote Agent.

Mining starts. However, AwesomeMiner shows the client as service offline.

Shivoreun

member

Activity: 130

Merit: 10

Quote from: patrike on October 02, 2018, 03:45:51 AM

Awesome Miner version 5.6.1

Hi, Patrike.
Is it possible to implement such functionality in next version?..

Quote from: Shivoreun on 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?

Thanks in advance...

Shivoreun

member

Activity: 130

Merit: 10

Quote from: moppidoo on October 01, 2018, 10:56:08 PM

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.

Thanks a lot. I think, this is the idea

Will try it.

patrike

legendary

Activity: 3346

Merit: 1094

Quote from: alucard20724 on October 03, 2018, 07:06:24 PM

i found someone attempting to try and scam using awesomeminer

https://bitcointalk.org/index.php?topic=5042170.new#new

their site address is
https://blokchain.su/

which is an exact duplicate of awesomeminer.com home page

Thanks for pointing this out. They even copied the copyright notice - amazing guys. Hopefully it will smell enough scam so no one will download their malware.

I think everyone knows this already, but I might as well point it out:
1) The Awesome Miner software should always be downloaded from the official web site
2) If someone is trying to sell a license at a discount, I can assure that it's not a valid license they are trying to sell
3) I've also received reports from users that downloaded a 5000 miner version of Awesome Miner and ended up with a great collection of malware on their systems. I probably don't need to point out that it wasn't downloaded from the official web site in this case.

alucard20724

sr. member

Activity: 703

Merit: 272

i found someone attempting to try and scam using awesomeminer

https://bitcointalk.org/index.php?topic=5042170.new#new

their site address is
https://blokchain.su/

which is an exact duplicate of awesomeminer.com home page

moppidoo

jr. member

Activity: 348

Merit: 5

Quote from: 0x000216 on 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?

Both EWBF zcash and Equihash miners are by default supported and included in AM, benchmarking and profit switching works pretty much out of the box with these 2 miners

moppidoo

jr. member

Activity: 348

Merit: 5

Quote from: patrike on October 03, 2018, 08:02:02 AM

Quote from: andrucrypt on October 03, 2018, 07:39:38 AM

Hi, it's a bug in miner API, I will fix it in newer version. Just found that I forgot "+" in formula...

Thanks for the update. I was just about to point out that Awesome Miner is only reading the first value for each GPU (the current hashrate), which in this case would be GPU0: 1133473 and GPU1:1141292. If these numbers are made into the total numbers for all GPU threads in the next update, it should be working fine with Awesome Miner.

Thanks to you both for looking into the issue!

0x000216

newbie

Activity: 13

Merit: 0

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?

patrike

legendary

Activity: 3346

Merit: 1094

Quote from: Calvinz89 on 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?

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.

I assume the miner is running on the Awesome Miner computer itself, and not on a Remote Agent?

patrike

legendary

Activity: 3346

Merit: 1094

Quote from: STSMiner on October 02, 2018, 09:39:02 AM

Hi patrike,

Re: Registration code: Upgrade code issued

Does the old Reg code still work as well ?

Hi,

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.

patrike

legendary

Activity: 3346

Merit: 1094

Quote from: andrucrypt on October 03, 2018, 07:39:38 AM

Quote from: moppidoo on October 02, 2018, 05:49:22 AM

Quote from: patrike on September 24, 2018, 03:03:53 PM

Quote from: moppidoo on September 22, 2018, 05:03:56 AM

Quote from: powerstr on September 19, 2018, 08:42:43 PM

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

I will take a look at this one. Thanks for your suggestions.

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

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
            ]
        ]
    },

Hi, it's a bug in miner API, I will fix it in newer version. Just found that I forgot "+" in formula...

Thanks for the update. I was just about to point out that Awesome Miner is only reading the first value for each GPU (the current hashrate), which in this case would be GPU0: 1133473 and GPU1:1141292. If these numbers are made into the total numbers for all GPU threads in the next update, it should be working fine with Awesome Miner.

andrucrypt

member

Activity: 725

Merit: 49

Quote from: moppidoo on October 02, 2018, 05:49:22 AM

Quote from: patrike on September 24, 2018, 03:03:53 PM

Quote from: moppidoo on September 22, 2018, 05:03:56 AM

Quote from: powerstr on September 19, 2018, 08:42:43 PM

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

I will take a look at this one. Thanks for your suggestions.

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

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
            ]
        ]
    },

Hi, it's a bug in miner API, I will fix it in newer version. Just found that I forgot "+" in formula...

Calvinz89

newbie

Activity: 9

Merit: 0

I configured rules for idle/use scenarios, but "stop miner" will also trigger if I manually press a Start button
How to prevent that?

STSMiner

full member

Activity: 270

Merit: 115

Hi patrike,

Re: Registration code: Upgrade code issued

Does the old Reg code still work as well ?

MoparMiningLLC

legendary

Activity: 2254

Merit: 2419

EIN: 82-3893490

Quote from: patrike on October 02, 2018, 03:14:47 AM

The ASIC count for Dashboard will be fixed in the new release that will be available soon.

thank you!

moppidoo

jr. member

Activity: 348

Merit: 5

Quote from: patrike on September 24, 2018, 03:03:53 PM

Quote from: moppidoo on September 22, 2018, 05:03:56 AM

Quote from: powerstr on September 19, 2018, 08:42:43 PM

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

I will take a look at this one. Thanks for your suggestions.

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

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
            ]
        ]
    },

patrike

legendary

Activity: 3346

Merit: 1094

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

patrike

legendary

Activity: 3346

Merit: 1094

Quote from: MoparMiningLLC on 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"

The ASIC count for Dashboard will be fixed in the new release that will be available soon.

Topic: [Awesome Miner] - Powerful Windows GUI to manage and monitor up to 200000 miners - page 273. (Read 703547 times)