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

[toptek12]

CPU mining
  - Update library for reading CPU information to improve temperature reading support for Ryzen CPUs

is there a way now to turn the temps on or is it a bug

I don't see any CPU temps after updating to 8.1.4 I have five Ryzen 3900X CPUs.

[patrike]

Awesome Miner version 8.1.5

 GPU mining
  - Added the EtcHash algorithm to support the upcoming changes for Ethereum Classic
 CPU mining
  - Improved detection of number of cores for AMD Ryzen
 Mining software
  - Lolminer 1.12
  - Nanominer 1.12
 Corrections
  - Correction to Ryzen temperature display

[cylshan]

Is it possible to supply the memory temperature sensor reading statistics?
-mvdd=        - Memory voltage, mV (1350 mV by default)  RaveOS
And can I lower it for W10 somehow by means of AM?

[sxemini]

Awesome Miner version 8.1.5

 GPU mining
  - Added the EtcHash algorithm to support the upcoming changes for Ethereum Classic
 CPU mining
  - Improved detection of number of cores for AMD Ryzen
 Mining software
  - Lolminer 1.12
  - Nanominer 1.12
 Corrections
  - Correction to Ryzen temperature display

Now i see no temps on all of my ryzen (1200, 1600, 2600x, G2400) In system tab it show me the temp, but status and the CPU tab give only 0°C, with v8.1.4 all works fine.

[joseph32]

Hi Patrik,

found some small bugs.

GPU Clocking Profiles / Clocking Profiles / Properties

Originally the core voltage limit was on auto. Now i switched to a fixed value, in this example 800. AM will apply the correct 800 mV from the profile to the card. But just shows the old "Auto" value in the Clocking Profiles summary.
Its clearly just a display error (but annoying   ). Tested with a fresh profile and a value of 800 and AM shows correctly VL: 800 in the Clocking Profile summary.



And below in AM in the GPU tab, dunno why, but on some rigs AM shows the wrong PCI Bus ID's. Even a reload shows the same wrong ID's. All that wrong rigs running on Win 10 with T-Rex, maybe you need that info. Everything in AM is working correctly, it just shows the wrong ID's. Maybe its also just a display error. If you need something to help fixing this, let me know.

Left picture should be ID 7, 9, 11. Right picture should be ID 2, 12.



Edit:

GPU Clocking / View GPU details shows the correct ID's. Map to system monitoring also shows the correct ID's. Its just the summary which shows wrong numbers.

[cylshan]

Is it possible to make a guide on how to install AM on hiveos or raveos or another linex OS
To make everything work?
Step by step

Can you please let me know if the general instructions are working in your setup?

Once you login to the Linux system like HiveOS, please run:
sudo -s
ldconfig /hive/lib/
wget http://www.awesomeminer.com/download/setup/awesomeminer-remoteagent.tar.xz
tar xvJf awesomeminer-remoteagent.tar.xz
cd awesomeminer-remoteagent
./service-install.sh

Please also see the guide for Remote Agent on Linux:
https://support.awesomeminer.com/support/solutions/articles/35000086210-remote-agent-for-linux

https://ibb.co/Y77WPxv
https://ibb.co/fHm1VGm

Everything seems to work. Incorrect display of temperature.
and something is not displayed other parameters
after reboot sees only 4 cards

https://ibb.co/dB0qLFW

HiveOS has six cards


How I did:
1.hiveos-beta-0.6-157@200909
2.recorded to SSD HDDRawCopy1.10Portable
3.Connected to the rig via PuTTY PORTABLE
Default login - user password 1



And all the items below and everything


sudo -s
ldconfig /hive/lib/
wget http://www.awesomeminer.com/download/setup/awesomeminer-remoteagent.tar.xz
tar xvJf awesomeminer-remoteagent.tar.xz
cd awesomeminer-remoteagent
./service-install.sh


./AwesomeMiner.RemoteAgent.Linux /setpassword=mypass

https://ibb.co/rbM4tML
https://ibb.co/DVLGgRp

[patrike]

Now i see no temps on all of my ryzen (1200, 1600, 2600x, G2400) In system tab it show me the temp, but status and the CPU tab give only 0°C, with v8.1.4 all works fine.

Thanks for the feedback. I will try to reproduce this.
Are you using XmRig or any other CPU mining software? Are all CPU cores reported with 0°C?

[patrike]

Hi Patrik,

found some small bugs.

GPU Clocking Profiles / Clocking Profiles / Properties

Originally the core voltage limit was on auto. Now i switched to a fixed value, in this example 800. AM will apply the correct 800 mV from the profile to the card. But just shows the old "Auto" value in the Clocking Profiles summary.
Its clearly just a display error (but annoying   ). Tested with a fresh profile and a value of 800 and AM shows correctly VL: 800 in the Clocking Profile summary.

Thanks, I will correct this one.

And below in AM in the GPU tab, dunno why, but on some rigs AM shows the wrong PCI Bus ID's. Even a reload shows the same wrong ID's. All that wrong rigs running on Win 10 with T-Rex, maybe you need that info. Everything in AM is working correctly, it just shows the wrong ID's. Maybe its also just a display error. If you need something to help fixing this, let me know.

Left picture should be ID 7, 9, 11. Right picture should be ID 2, 12.

Edit:

GPU Clocking / View GPU details shows the correct ID's. Map to system monitoring also shows the correct ID's. Its just the summary which shows wrong numbers.

In this case I see you manually defined the GPU order, so the order will depend on what you defined in the GPU mapping dialog. What is the result if you open the GPU mapping dialog and uncheck the first checkbox? In this case Awesome Miner will automatically try to resolve this. Do you still see the same problem after making this change?

[joseph32]

Hi Patrik,

tried what you have suggested.

1. (left picture) I just unchecked the box. Restarted the rig, restarted AM, restarted the whole Windows. AM still shows ID 9, 11, 11.
2. (right picture) I corrected the order in the list and then unchecked the box. Restarted everything. Still ID 9, 11, 11.

Same with the other rig. Its like AM moves the ID's one slot up and fillst the last spot with the last ID again. Any other idea what else I can do or check? I also dont know if this is a new bug or I just never realized it.
But its clearly just a display error here. Everything works fine. So its not a high priority to fix this.

1) 2)


Edit: Its a T-Rex bug! Just started GMiner to check the GPU tab and it shows the correct ID's 7, 9, 11, even with and without the GPU mapping. Back to T-Rex and its again 9, 11, 11.

Maybe it is the --pci-indexing which is not working properly? Cant test without, but I would bet on it. But its a strange bug. Its just on a few rigs, not all. And it seems only on rigs which are splitted into multiple miners, running all T-Rex. Non-Splitted rigs or rigs with multiple mining software running seems not affected.

[narousberg]

Patrike, please add a Progpow-veil algo to AM for T-Rex and WildRig.
Miner works only with CUDA 10.0 lib
Regards

[patrike]

Edit: Its a T-Rex bug! Just started GMiner to check the GPU tab and it shows the correct ID's 7, 9, 11, even with and without the GPU mapping. Back to T-Rex and its again 9, 11, 11.

Maybe it is the --pci-indexing which is not working properly? Cant test without, but I would bet on it. But its a strange bug. Its just on a few rigs, not all. And it seems only on rigs which are splitted into multiple miners, running all T-Rex. Non-Splitted rigs or rigs with multiple mining software running seems not affected.

Can you please send me the following when mining with T-Rex miner:
1) API-Report (toolbar: Tools -> API Report)
2) GPU details (via the GPU tab, View GPU Details)

Please send me the information via PM. Thanks!

[patrike]

Patrike, please add a Progpow-veil algo to AM for T-Rex and WildRig.
Miner works only with CUDA 10.0 lib
Regards

Thanks for the feedback. I've updated the mining definitions to include this algorithm.

[danielocdh]

ethminer API timing out, but only on remote agent connections

I have hundreds of messages like this on the remote agent log per day on my miners(which eventually lead to false positive offline detection):

Code:

2020/11/01 6:51:23.796 [016] [E]Failed to process API request (localhost, time: 13006 ms): {"id":0,"jsonrpc":"2.0","method":"miner_getstatdetail"}

Unable to read data from the transport connection: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.

48 hours ago I started running a script I made that reads the API on localhost every 5 seconds on every miner, I also ran the script 3 times on my machine with each instance pointing to the IP of each miner, the script instances never failed to connect and always took just a few milliseconds everywhere(only once in the 48 hours from my machine one instance took around one second to respond but responded correctly). I made this test with firewall disabled and freshly restarted miners.

I tried setting the priority of the remote agent process to high, I don't think it made a difference.

This is happening with ethminer 0.17.1 (chosen via awesome miner) and ethminer-0.19.0-7+commit.66186f1b (manually uploaded via awesome miner custom software). Although it seems to happen more on the updated version. I'm not using 0.18.0 (chosen via awesome miner) as it that version of ethminer has a bug that prevents the api from responding. I'm using the later version mainly because 0.17.1 won't show any data while mining, I believe the only data missing when using the later version is the individual progress details for each gpu.

Any suggestion on what else I could try? thanks

[patrike]

ethminer API timing out, but only on remote agent connections

I have hundreds of messages like this on the remote agent log per day on my miners(which eventually lead to false positive offline detection):

Code:

2020/11/01 6:51:23.796 [016] [E]Failed to process API request (localhost, time: 13006 ms): {"id":0,"jsonrpc":"2.0","method":"miner_getstatdetail"}

Unable to read data from the transport connection: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.

48 hours ago I started running a script I made that reads the API on localhost every 5 seconds on every miner, I also ran the script 3 times on my machine with each instance pointing to the IP of each miner, the script instances never failed to connect and always took just a few milliseconds everywhere(only once in the 48 hours from my machine one instance took around one second to respond but responded correctly). I made this test with firewall disabled and freshly restarted miners.

I tried setting the priority of the remote agent process to high, I don't think it made a difference.

This is happening with ethminer 0.17.1 (chosen via awesome miner) and ethminer-0.19.0-7+commit.66186f1b (manually uploaded via awesome miner custom software). Although it seems to happen more on the updated version. I'm not using 0.18.0 (chosen via awesome miner) as it that version of ethminer has a bug that prevents the api from responding. I'm using the later version mainly because 0.17.1 won't show any data while mining, I believe the only data missing when using the later version is the individual progress details for each gpu.

Any suggestion on what else I could try? thanks

Thanks for the detailed description and for your analysis. So at the same time Remote Agent get a timeout after 13 seconds, your tool connecting to the same EthMiner API is receiving a response without any problems? Do you see a timeout error like this and then it works fine for a while and then another timeout and so on?

I will have to look into this a bit more because I cannot see any obvious reason why Remote Agent would timeout if the API is in fact working.

For the API data processing, I can make a few adjustments to make sure it parses the API response correctly once received.

[narousberg]

Patrike, pls add algo Octopus for NBMiner, Bminer
Push update for NBMiner 33.3  TT-Miner 6.0.0
Regards

[forato]

I Know that we can use HIVEOS in free version with AM.

But i think it will be so nice to have an linux OS based on AM, I already read a lot of messages here with some user asking for it...

Nobody with skills here are interest in make an image for us?

[cylshan]

I Know that we can use HIVEOS in free version with AM.

But i think it will be so nice to have an linux OS based on AM, I already read a lot of messages here with some user asking for it...

Nobody with skills here are interest in make an image for us?

Relevant for 4gb cards, on Windows 10 LTSC(LTSB), cards on TeamRedMiner and lolMiner fall off in random order. On Hive OS running AM TeamRedMiner works.
You can, of course, through the web interface Hive OS or RaveOS or others.
But it doesn't work that way, a lot of Stale Share, or something works crookedly, not stable


I did so if you correct something.
1.hiveos-0.6-156@200905
If on a USB flash drive then through balenaEtcher-Portable-1.5.109
2.hiveos-0.6-156@200905
If on SSD then via HDDRawCopy1.10Portable

Next, we connect to the rig via IP via
putty-0.73-ru-17-portable
The default login is user password. 1


and enter this:
sudo -s
ldconfig / hive / lib /
wget http://www.awesomeminer.com/download/setup/awesomeminer-remoteagent.tar.xz
tar xvJf awesomeminer-remoteagent.tar.xz
cd awesomeminer-remoteagent
./service-install.sh
./AwesomeMiner.RemoteAgent.Linux / setpassword = mypass


In the AwesomeMiner client
where is the host in IP
Next, put the Linux daw on the host
host = mypass

Connect and use

Or did I forget to write something here?
Add what I forgot to write or correct


Or a guide from "patrike".
Everything is step by step so that any person understands how it works.
Thanks !!!

[narousberg]

Patrike, pls add for Bminer for algo Octopus param conflux, in ver. 16.3.4 all works good.

[danielocdh]

ethminer API timing out, but only on remote agent connections

I have hundreds of messages like this on the remote agent log per day on my miners(which eventually lead to false positive offline detection):

Code:

2020/11/01 6:51:23.796 [016] [E]Failed to process API request (localhost, time: 13006 ms): {"id":0,"jsonrpc":"2.0","method":"miner_getstatdetail"}

Unable to read data from the transport connection: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.

48 hours ago I started running a script I made that reads the API on localhost every 5 seconds on every miner, I also ran the script 3 times on my machine with each instance pointing to the IP of each miner, the script instances never failed to connect and always took just a few milliseconds everywhere(only once in the 48 hours from my machine one instance took around one second to respond but responded correctly). I made this test with firewall disabled and freshly restarted miners.

I tried setting the priority of the remote agent process to high, I don't think it made a difference.

This is happening with ethminer 0.17.1 (chosen via awesome miner) and ethminer-0.19.0-7+commit.66186f1b (manually uploaded via awesome miner custom software). Although it seems to happen more on the updated version. I'm not using 0.18.0 (chosen via awesome miner) as it that version of ethminer has a bug that prevents the api from responding. I'm using the later version mainly because 0.17.1 won't show any data while mining, I believe the only data missing when using the later version is the individual progress details for each gpu.

Any suggestion on what else I could try? thanks

Thanks for the detailed description and for your analysis. So at the same time Remote Agent get a timeout after 13 seconds, your tool connecting to the same EthMiner API is receiving a response without any problems? Do you see a timeout error like this and then it works fine for a while and then another timeout and so on?

I will have to look into this a bit more because I cannot see any obvious reason why Remote Agent would timeout if the API is in fact working.

For the API data processing, I can make a few adjustments to make sure it parses the API response correctly once received.

Correct, my tool never failed to get the API data quickly, I'm using the same command I saw on the logs(miner_getstatdetail)

Update: I installed the latest updates for windows 1909 on windows update(security, servicing stack, cumulative and a .net 3.5 update but not edge), after about 10 hours the timeouts seem to be less common, one machine had 0, other 12 and other 16(6 consecutive timeouts once which triggered the offline detection that is set to 60 seconds now). The API was fully responsive all the time on all miners when requesting information from my computer with my tool (every 5 seconds never taking more than a few milliseconds).
I'll reformat one miner with latest windows to test when I can.

[patrike]

Patrike, pls add for Bminer for algo Octopus param conflux, in ver. 16.3.4 all works good.

I've pushed an update for this as well. Thanks for the feedback.