Author

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

newbie
Activity: 31
Merit: 0
member
Activity: 418
Merit: 21
Patrike,

temperature rules for TeamRedMiner doesnt work, AM ignore them or just dont execute them (dunno). Can you check that please?

Maybe its because TRM have restricted API access? Is there any way to make that work? I really need an alert when a specific temperature is reached.
newbie
Activity: 107
Merit: 0
https://github.com/andru-kun/wildrig-multi/releases/tag/0.15.0

added mtp algo
added SSE4.1 instructions to boost MerkleTree generation on low-end CPU's
added huge pages support for faster memory operations(need fresh Windows start and enough memory)
reworked --mtp-stable-power
legendary
Activity: 3346
Merit: 1094
New version of NBminer 12.1

https://github.com/NebuTech/NBMiner/releases/tag/v12.1

API doesn't works for me, hashrate is displayed in console but not in AM.
Thanks for letting me know. I will take a look at this one as the latest version may have introduced some API changes. The plan is to support the new NBMiner version in the next release.
newbie
Activity: 52
Merit: 0
Initialize diagnostics (10)
Starting Diagnostics. Awesome Miner Remote Agent version: 6.0.8
OS: Microsoft Windows 10 Enterprise 64-bit
AMD driver version: BETA
Microsoft VC++ 2013 runtime installed: Yes
Microsoft VC++ 2015 runtime installed: No
Starting Mining Software
Setting up Miner Engine. Instance: 1
Engine Type: WildRigMiner, Auto Download: True, EnginePath: , Subtype: Disabled, CustomExecutable:
Properties: (WindowMode: ConsoleFormat, EngineType: WildRigMiner, IsProfitMiner: True)
====================================================================================================
C:\Users\RED\AppData\Roaming\AwesomeMinerService\wildrig-0.15.0.6-beta_1\wildrig_avx.exe  --opencl-launch=256x0 --send-stale  -a x17 -o stratum+tcp://x17.eu.mine.zpool.ca:3737 -u 15NRifmpqUx8DeNg1E6EZM2wNoykf2muDy -p c=BTC --api-port=4028
Configured command line:
--opencl-launch=256x0 --send-stale
====================================================================================================
>  * VERSIONS:     WildRig/0.15.0.6 beta libuv/1.21.0 OpenCL/2.0 MSVC/2015
>  * CPU:          Intel(R) Celeron(R) CPU G1840 @ 2.80GHz x64 -AES-NI
>  * ALGO:         x17
>  * POOL #1:      x17.eu.mine.zpool.ca:3737
>  * API PORT:     4028
>  * COMMANDS:     'h' hashrate, 'p' pause, 'r' resume
Mining Engine Process started, PID: 3664
> [08:50:39] donation: 2%
> [08:50:39] strategy: 0
> [08:50:39] send-stale: yes
> [08:50:39] watchdog: disabled
> [08:50:39] good-risers: default
> [08:50:39] compiling code and initializing GPUs. This will take a while...
> [08:50:39] GPU #0 [BusID: #1] [Ellesmere] Radeon (TM) RX 480 Graphics
> [08:50:39] threads: 1, intensity: 256, worksize: 0/256, cu: 36, memory: 8192Mb
> [08:50:40] Error CL_INVALID_KERNEL_NAME when calling clCreateKernel for kernel 'mtp_yloop'
> [08:50:40] Failed to start OpenCL threads
Have you used WildRig successfully on this computer before, or is it the first time? The reason I'm asking is about the highlighted line above indicating that the Microsoft VC++ 2015 runtime is missing and this could be the issue.

Download link:
https://download.microsoft.com/download/9/3/F/93FCF1E7-E6A4-478B-96E7-D4B285925B00/vc_redist.x64.exe

From the wildrig-0.15.0.6-beta_2 README!!

8GB of RAM is MUST HAVE. Same for GPU, 8Gb only cards. 4Gb will be too slow.

Use older version to run wildrig successfully.
newbie
Activity: 21
Merit: 0
New version of NBminer 12.1

https://github.com/NebuTech/NBMiner/releases/tag/v12.1

API doesn't works for me, hashrate is displayed in console but not in AM.
newbie
Activity: 58
Merit: 0
[2A48:3B64][2018-12-23T17:07:18]i001: Burn v3.7.3813.0, Windows v10.0 (Build 17134: Service Pack 0), path: C:\Users\KISAK\Downloads\vc_redist.x64.exe, cmdline: ''

[2A48:3B64][2018-12-23T17:07:18]i108: Detected compatible package: vcRuntimeMinimum_x64, provider: Microsoft.VS.VC_RuntimeMinimumVSU_amd64,v14, installed: {03EBF679-E886-38AD-8E70-28658449F7F9}, version: 14.14.26429, chained: {0D3E9E15-DE7A-300B-96F1-B4AF12B96488}


Just a shot in the dark;
Is the miner program 32-bit?
And you tried to install vc 64-bit (but already had it installed)?
Does it work when installing vc 32-bit?

newbie
Activity: 107
Merit: 0
Roll back the version, it is only for the MTP and everything else practically does not work...
newbie
Activity: 107
Merit: 0
Kernels from the archives lured you mtp_yloop missing you missed them
newbie
Activity: 107
Merit: 0
[2A48:3B64][2018-12-23T17:07:18]i001: Burn v3.7.3813.0, Windows v10.0 (Build 17134: Service Pack 0), path: C:\Users\KISAK\Downloads\vc_redist.x64.exe, cmdline: ''
[2A48:3B64][2018-12-23T17:07:18]i000: Setting string variable 'WixBundleLog' to value 'C:\Users\KISAK\AppData\Local\Temp\dd_vcredist_amd64_20181223170718.log'
[2A48:3B64][2018-12-23T17:07:18]i000: Setting string variable 'WixBundleOriginalSource' to value 'C:\Users\KISAK\Downloads\vc_redist.x64.exe'
[2A48:3B64][2018-12-23T17:07:18]i000: Setting string variable 'WixBundleOriginalSourceFolder' to value 'C:\Users\KISAK\Downloads\'
[2A48:3B64][2018-12-23T17:07:18]i000: Setting string variable 'WixBundleName' to value 'Microsoft Visual C++ 2015 Redistributable (x64) - 14.0.23026'
[2A48:3B64][2018-12-23T17:07:18]i100: Detect begin, 10 packages
[2A48:3B64][2018-12-23T17:07:18]i000: File search: windows_uCRT_DetectKey, did not find path: C:\WINDOWS\system32\api-ms-win-crt-runtime-l1-1-0.dll
[2A48:3B64][2018-12-23T17:07:18]i000: File search: windows_uCRT_DetectKeyExists, did not find path: C:\WINDOWS\system32\api-ms-win-crt-runtime-l1-1-0.dll
[2A48:3B64][2018-12-23T17:07:18]i000: Setting numeric variable 'windows_uCRT_DetectKeyExists' to value 0
[2A48:3B64][2018-12-23T17:07:18]i102: Detected related bundle: {80586c77-db42-44bb-bfc8-7aebbb220c00}, type: Upgrade, scope: PerMachine, version: 14.14.26429.4, operation: Downgrade
[2A48:3B64][2018-12-23T17:07:18]i108: Detected compatible package: vcRuntimeMinimum_x64, provider: Microsoft.VS.VC_RuntimeMinimumVSU_amd64,v14, installed: {03EBF679-E886-38AD-8E70-28658449F7F9}, version: 14.14.26429, chained: {0D3E9E15-DE7A-300B-96F1-B4AF12B96488}
[2A48:3B64][2018-12-23T17:07:18]i103: Detected related package: {03EBF679-E886-38AD-8E70-28658449F7F9}, scope: PerMachine, version: 14.14.26429.0, language: 0 operation: Downgrade
[2A48:3B64][2018-12-23T17:07:18]i108: Detected compatible package: vcRuntimeAdditional_x64, provider: Microsoft.VS.VC_RuntimeAdditionalVSU_amd64,v14, installed: {B12F584A-DE7A-3EE3-8EC4-8A64DBC0F2A7}, version: 14.14.26429, chained: {BC958BD2-5DAC-3862-BB1A-C1BE0790438D}
[2A48:3B64][2018-12-23T17:07:18]i103: Detected related package: {B12F584A-DE7A-3EE3-8EC4-8A64DBC0F2A7}, scope: PerMachine, version: 14.14.26429.0, language: 0 operation: Downgrade
[2A48:3B64][2018-12-23T17:07:18]i052: Condition '(windows_uCRT_DetectKeyExists AND windows_uCRT_DetectKey >= v10.0.10137.0)' evaluates to false.
[2A48:3B64][2018-12-23T17:07:18]i052: Condition '(windows_uCRT_DetectKeyExists AND windows_uCRT_DetectKey >= v10.0.10137.0)' evaluates to false.
[2A48:3B64][2018-12-23T17:07:18]i052: Condition '(windows_uCRT_DetectKeyExists AND windows_uCRT_DetectKey >= v10.0.10137.0)' evaluates to false.
[2A48:3B64][2018-12-23T17:07:18]i052: Condition '(windows_uCRT_DetectKeyExists AND windows_uCRT_DetectKey >= v10.0.10137.0)' evaluates to false.
[2A48:3B64][2018-12-23T17:07:18]i052: Condition '(windows_uCRT_DetectKeyExists AND windows_uCRT_DetectKey >= v10.0.10137.0)' evaluates to false.
[2A48:3B64][2018-12-23T17:07:18]i052: Condition '(windows_uCRT_DetectKeyExists AND windows_uCRT_DetectKey >= v10.0.10137.0)' evaluates to false.
[2A48:3B64][2018-12-23T17:07:18]i052: Condition '(windows_uCRT_DetectKeyExists AND windows_uCRT_DetectKey >= v10.0.10137.0)' evaluates to false.
[2A48:3B64][2018-12-23T17:07:18]i052: Condition '(windows_uCRT_DetectKeyExists AND windows_uCRT_DetectKey >= v10.0.10137.0)' evaluates to false.
[2A48:3B64][2018-12-23T17:07:18]i101: Detected package: vcRuntimeMinimum_x64, state: Obsolete, cached: None
[2A48:3B64][2018-12-23T17:07:18]i101: Detected package: vcRuntimeAdditional_x64, state: Obsolete, cached: None
[2A48:3B64][2018-12-23T17:07:18]i101: Detected package: Windows81_x86, state: Absent, cached: None
[2A48:3B64][2018-12-23T17:07:18]i101: Detected package: Windows81_x64, state: Absent, cached: None
[2A48:3B64][2018-12-23T17:07:18]i101: Detected package: Windows8_x86, state: Absent, cached: None
[2A48:3B64][2018-12-23T17:07:18]i101: Detected package: Windows8_x64, state: Absent, cached: None
[2A48:3B64][2018-12-23T17:07:18]i101: Detected package: Windows7_MSU_x86, state: Absent, cached: None
[2A48:3B64][2018-12-23T17:07:18]i101: Detected package: Windows7_MSU_x64, state: Absent, cached: None
[2A48:3B64][2018-12-23T17:07:18]i101: Detected package: WindowsVista_MSU_x86, state: Absent, cached: None
[2A48:3B64][2018-12-23T17:07:18]i101: Detected package: WindowsVista_MSU_x64, state: Absent, cached: None
[2A48:3B64][2018-12-23T17:07:18]i052: Condition 'VersionNT64 >= v6.0 OR (VersionNT64 = v5.2 AND ServicePackLevel >= 1)' evaluates to true.
[2A48:3B64][2018-12-23T17:07:18]i199: Detect complete, result: 0x0
[2A48:0B24][2018-12-23T17:07:57]e000: Error 0x80070666: Cannot install a product when a newer version is installed.
legendary
Activity: 3346
Merit: 1094
Initialize diagnostics (10)
Starting Diagnostics. Awesome Miner Remote Agent version: 6.0.8
OS: Microsoft Windows 10 Enterprise 64-bit
AMD driver version: BETA
Microsoft VC++ 2013 runtime installed: Yes
Microsoft VC++ 2015 runtime installed: No
Starting Mining Software
Setting up Miner Engine. Instance: 1
Engine Type: WildRigMiner, Auto Download: True, EnginePath: , Subtype: Disabled, CustomExecutable:
Properties: (WindowMode: ConsoleFormat, EngineType: WildRigMiner, IsProfitMiner: True)
====================================================================================================
C:\Users\RED\AppData\Roaming\AwesomeMinerService\wildrig-0.15.0.6-beta_1\wildrig_avx.exe  --opencl-launch=256x0 --send-stale  -a x17 -o stratum+tcp://x17.eu.mine.zpool.ca:3737 -u 15NRifmpqUx8DeNg1E6EZM2wNoykf2muDy -p c=BTC --api-port=4028
Configured command line:
--opencl-launch=256x0 --send-stale
====================================================================================================
>  * VERSIONS:     WildRig/0.15.0.6 beta libuv/1.21.0 OpenCL/2.0 MSVC/2015
>  * CPU:          Intel(R) Celeron(R) CPU G1840 @ 2.80GHz x64 -AES-NI
>  * ALGO:         x17
>  * POOL #1:      x17.eu.mine.zpool.ca:3737
>  * API PORT:     4028
>  * COMMANDS:     'h' hashrate, 'p' pause, 'r' resume
Mining Engine Process started, PID: 3664
> [08:50:39] donation: 2%
> [08:50:39] strategy: 0
> [08:50:39] send-stale: yes
> [08:50:39] watchdog: disabled
> [08:50:39] good-risers: default
> [08:50:39] compiling code and initializing GPUs. This will take a while...
> [08:50:39] GPU #0 [BusID: #1] [Ellesmere] Radeon (TM) RX 480 Graphics
> [08:50:39] threads: 1, intensity: 256, worksize: 0/256, cu: 36, memory: 8192Mb
> [08:50:40] Error CL_INVALID_KERNEL_NAME when calling clCreateKernel for kernel 'mtp_yloop'
> [08:50:40] Failed to start OpenCL threads
Have you used WildRig successfully on this computer before, or is it the first time? The reason I'm asking is about the highlighted line above indicating that the Microsoft VC++ 2015 runtime is missing and this could be the issue.

Download link:
https://download.microsoft.com/download/9/3/F/93FCF1E7-E6A4-478B-96E7-D4B285925B00/vc_redist.x64.exe
legendary
Activity: 3346
Merit: 1094
I noticed that the ANON is not correctly displayed on coincalculators, but on whattomine is correct.
I did a rewrite in the awesome ANON to ZHASH settings but it didn’t work.
I think coincalculators report incorrect data.

It would be nice to add to the awesome calculator priority function for a single coin.
Thanks for the suggestion. This might however add a bit too much complexity to the configuration - but I understand the scenario you describe. Hopefully the coin statistics providers resolve any reported issues as soon as possible.
legendary
Activity: 3346
Merit: 1094


I have something to say about something that they always ask me about the telegram group, and from so much explaining it, I myself have doubts. I hope to explain it well because then when translating everything is changed.

It is about the change of profit 0.9 or 90% etc ... And especially in the auto exchanges like Zpool.

I think, and I repeat, I think it's not quite right or at least it does not look good.

I have for example Zpool with Skun, and there I mark a profit calculated of 0.69% for that protocol, but the price that I get on the screen is the price of Zpool without applying the profit reduction, that is 69%. That is true?

If so, any currency that I change the profit, or in the auto exchanges that auto calculate the Profit, should reflect the price already modified by the corresponding profit.

for example if SKUN in Zpool says that I get 0.0020, that's what it says in Online Services, but I really should dial 0.0020 - Profit, in this case 0.67, would be equal to 0.00134 which is what I should show.


Because to show the prices without modifying the profit, the listings when ordering them for benefits, it does without calculating the profit change and this drives me crazy and they ask me hundreds of questions in the group related to that.

Sometimes there are users who are excited to see a high amount and leave only one Al-go because it marks a very high profit, but that amount has not been subtracted from the profit. Be a loose coin or the al-go of an auto exchange.

Then in the group they tell me, is that I mined X but I won -X, I mean less, because they only pay attention to the profit of the currency that has not applied the profit in real time, which is how it should be. or that or Zpool is cheating us. But also useful when I measure currency / pool and get 0.85, the price that should appear on the AM screen should be the (price - profit) already applied to give more truthful information and close to reality.

Sometimes I get the impression that the change of profit is not taken into account, but that is an observation of mine that can be wrong.

I really have serious doubts if that modification of profit is being applied both in the prices that we see and in auto profit. Because there are many who ask me and drive me crazy in the telegram group with this topic. I think I remember, that is taken into account but do not reflect it on the screen and I personally believe that the price should be reflected on the screen already modified by the profit, thus avoiding mistakes and giving the most accurate information.

I await your comments @Patrike
I'm looking at Zpool Skunkhash right now like you suggested.

The Zpool API reports the current profitability per MH/day:
"estimate_current":"0.00000235"

You can use this link to see the values provided for zpool for each of the algorithms: https://www.zpool.ca/api/status

My Awesome Miner shows BTC/GH/day as 0.0014 BTC, Actual Payout as 61.68% and Revenue as 0.00062 BTC right now using your hashrate. This is close to the numbers in your screenshot.

If I take the reported profit from Zpool, convert it from MH/day to GH/day and multiply with 61.68%, I get the following value for BTC/GH/day:
0.00000235 * 1000 * 0.6168 = 0.00144 BTC

This is the value you I see in the BTC/GH/day column in Awesome Miner - so the calculations are correct. It's also very close to the numbers you showed a few hours earlier. Multiply with your hashrate in GH (0.43269), you will get the Revenue of 0.00062 as displayed in my case.

If I set a custom Profit Factor for Zpool of 0.5 - I also verified that all BTC values on the Online Services tab are cut in half for Zpool Skunkhash - so that also looks fine.

What I'm not sure about in your screenshot is the Profit column as it looks like the same as the Revenue column. This will of course depend on power cost settings and so on so I cannot verify if it's correct. Is the Profit column an issue here?


Thanks for the explanation, now everything is clearer and I can explain it better to my people.

In the discord channel of the owner of CTM I have reported several currencies that the result they show is always the lowest sale price, instead of the highest bid, which I always use.

The API programmer constantly refuses me and gives me examples and says it's more your fault than your API.

I tell you what you tell me, you can enter the general channel of the discord where I have developed the conversation to see my captures and evidence that the price is wrong and its explanations like that he does it well and that you are really reading poorly the API. Something that I do not believe and that surely has been solved in these days but is too proud to recount failures. Whatever it is, please read the Cointomine channel, in your discord, give examples of the API.

regards
I think the easiest way to troubleshoot any exchange rates is to use the CoinToMine web site without using Awesome Miner. For each of the coins you will find Lowest Ask / Highest Bid and Last Price. For example this one as we discussed earlier where all these three values are the same:
https://cointomine.today/calculator/coin/STL/
legendary
Activity: 3346
Merit: 1094
I've been having a very frustrating problem the last couple of weeks - every few hours a miner randomly "fails to start", and then I get the modal dialog asking me to run diagnostics. Every single time I run diagnostics absolutely nothing is wrong. So one by one my miners are stopping, and I have to check every few hours, clear 5-10 of these dialogs, start the miners back up, and they work every single time. So there has to be some bug in AM causing this, because there's certainly not a problem with the miners or the rigs if the miner starts right up every time.
Nope, that's definitely not it. Something must have changed in awesome miner, because this only started happening recently.
If you get the dialog that the miner failed to start, it's because the mining software has crashed a number of times over the last few minutes. After a number of attempts of restarting it, Awesome Miner will give up and show this error.

You can configure Awesome Miner to continue trying to restart the crashed mining software via the Options dialog, Mining Settings section, where you can set the restart attempts to 99. As the number of attempts are based on the last few minutes, a value of 99 will basically make Awesome Miner trying to restart the mining every time it's crashes and never give up.

There are no recent changes in Awesome Miner to this behavior.

There can be instances where mining software crashes a number of times for a while, but when starting it with the exact same settings a little later, it will no longer crash. Temperature is a common cause why the problem resolves itself, but I suppose there can be many other reasons why mining software don't give consistent behaviors with the crashes.

For the crashes you may have to do general troubleshooting to find out if it's a specific algorithm or mining software or mining rig or clocking settings that causes the problem.

I've set it to restart as many as 10 times, and while I'm using the program if the dialog pops up, I can click it *immediately* and it always still works. Furthermore, I tried to set a rule where it would wait 10 seconds before starting the miner again, but the modal dialogs seem to block that rule from executing (and who knows what else). For instance this morning I had 3 of those dialogs on top of each other, I clicked no to all of them, and then a few seconds later, the rule triggered and all three started up just fine. There at least has to be some way to turn this blocking dialog off if it's going to prevent me from setting rules to correct this inexplicable behavior.
Thanks for the update, I understand your point.

Do you get any entry on the Notifications tab about this issue?

Could you please send me the log file for this Remote Agent and also for the Awesome Miner main application - and let me know the time and the name of the miner? I will investigate to find out what the scenario looks like. Thanks!


Code:
12/22/2018 6:16:22 PM.152 [009] [S][ManagedMiner#290 - J7 4x 1070 GB 2x 1080TI MSI-X] Starting...
12/22/2018 6:16:23 PM.167 [009] [S][ManagedMiner#290 - J7 4x 1070 GB 2x 1080TI MSI-X] Starting Mining Software
12/22/2018 6:16:23 PM.167 [009] [S][ManagedMiner#290 - J7 4x 1070 GB 2x 1080TI MSI-X] Setting up Miner Engine. Instance: 1
12/22/2018 6:16:23 PM.167 [009] [S][ManagedMiner#290 - J7 4x 1070 GB 2x 1080TI MSI-X] Engine Type: CcCryptoDredgeEngine, Auto Download: True, EnginePath: , Subtype: Disabled, CustomExecutable:
12/22/2018 6:16:23 PM.167 [009] [S]EngineSetup: CcCryptoDredgeEngine
12/22/2018 6:16:23 PM.167 [009] [S][ManagedMiner#290 - J7 4x 1070 GB 2x 1080TI MSI-X] Set clocking start profile: 59, 60%/+100/0/Auto (when stopping, the following will be used: -1, type: Single, Use: False)
12/22/2018 6:16:23 PM.167 [022] [S]ApplySingleProfile Begin
12/22/2018 6:16:23 PM.167 [022] [S]Preparing authentication header for MSI Afterburner requests: MSIAfterburner:17cc95b4017d496f82
12/22/2018 6:16:23 PM.199 [022] [S]Number of GPU commands: 20
12/22/2018 6:16:23 PM.199 [022] [S]Executing GPU clocking command: /setmacm, powerLimit0=60&coreClockBoost0=100000&memoryClockBoost0=0&fanSpeed0=auto&powerLimit1=60&coreClockBoost1=100000&memoryClockBoost1=0&fanSpeed1=auto&powerLimit2=60&coreClockBoost2=100000&memoryClockBoost2=0&fanSpeed2=auto&powerLimit3=60&coreClockBoost3=100000&memoryClockBoost3=0&fanSpeed3=auto&powerLimit4=60&coreClockBoost4=100000&memoryClockBoost4=0&fanSpeed4=auto
12/22/2018 6:16:23 PM.199 [022] [S]Preparing authentication header for MSI Afterburner requests: MSIAfterburner:17cc95b4017d496f82
12/22/2018 6:16:24 PM.183 [020] [I][ManagedMiner#290 - J7 4x 1070 GB 2x 1080TI MSI-X] : ProcessMiner
12/22/2018 6:16:24 PM.183 [009] [E]System.NullReferenceException: Object reference not set to an instance of an object.
12/22/2018 6:16:24 PM.183 [009] [E]   at AwesomeMiner.Service.Core.Engines.EnginePrepareBase.GetStaticSortedPools()
   at AwesomeMiner.Service.Core.Engines.EnginePrepareBase.ProcessVirtualEffectivePoolList()
   at AwesomeMiner.Service.Core.Engines.CcMiner.CcEnginePrepare.BuildArguments()
   at AwesomeMiner.Service.Core.Engines.MinerEngine.Start(Int32 #=znFEPBq4WhQQq, Boolean #=zm8OVyhw=, Boolean #=z3_DDggA=, BenchmarkCommand #=zG2LTkxarwMBnUeaT5w==)
[b]12/22/2018 6:16:24 PM.183 [009] [E][ManagedMiner#290 - J7 4x 1070 GB 2x 1080TI MSI-X] Failed to start miner process: Object reference not set to an instance of an object.[/b]
12/22/2018 6:16:24 PM.183 [009] [E][ManagedMiner#290 - J7 4x 1070 GB 2x 1080TI MSI-X]Failed to start miner
12/22/2018 6:16:25 PM.199 [020] [I][ManagedMiner#531 - CPU-J7] : ProcessMiner
12/22/2018 6:16:27 PM.027 [022] [S]ApplySingleProfile End
12/22/2018 6:16:29 PM.246 [038] [I][ManagedMiner#290 - J7 4x 1070 GB 2x 1080TI MSI-X] : ProcessMiner
12/22/2018 6:16:30 PM.262 [038] [I][ManagedMiner#531 - CPU-J7] : ProcessMiner
12/22/2018 6:16:34 PM.325 [020] [I][ManagedMiner#290 - J7 4x 1070 GB 2x 1080TI MSI-X] : ProcessMiner
12/22/2018 6:16:35 PM.341 [020] [I][ManagedMiner#531 - CPU-J7] : ProcessMiner
12/22/2018 6:16:39 PM.388 [022] [I][ManagedMiner#290 - J7 4x 1070 GB 2x 1080TI MSI-X] : ProcessMiner
12/22/2018 6:16:40 PM.404 [016] [I][ManagedMiner#531 - CPU-J7] : ProcessMiner
12/22/2018 6:16:44 PM.435 [007] [I][ManagedMiner#290 - J7 4x 1070 GB 2x 1080TI MSI-X] : ProcessMiner
12/22/2018 6:16:45 PM.451 [038] [I][ManagedMiner#531 - CPU-J7] : ProcessMiner[/quote]

Thanks for the details. I can see the method where it goes wrong and I'm about to make it a bit more fail safe and also add additional logging to explain why it's going wrong. However, I cannot verify the solution without fully understanding what caused it.

If possible, please provide me with both the log files so I can see the full scenario so I understand why you ended up with this issue to begin with. Thanks!
legendary
Activity: 1764
Merit: 1024
Small request for the properties > general > add to worker name - Please add a checkbox here that will auto fill with the current miner name. So when you apply a template it will pull the miner name.
There is actually a variable you can put into this Add to Worker Name field:
[MinerDescription]

It will be replace with what you have entered in the Description field of the miner. You can also add additional text before or after the variable name if needed.

Good stuff.


Anyway, another thing, I've asked a few times for a way to manage the upload directories on AM agents, I think a better method for this would be a local repository on whatever computer is running AM. Then it automatically uploads the folders from the AM client to the AM agents whenever the agents request a directory that isn't currently present on the agent computer. This is basically a version of sync. Furthermore, when a miner isn't used for X amount of time (two months?) it automatically deletes it from the agent PC, but not from the client PC and then reuploads it if it's needed again. A lot of this stuff is configurable, but very easy to understand and would help immensely with agent management.
The Managed Software concept (see Options dialog, Managed Software section) supports download URL's that are file shares. Although this isn't exactly the repository feature you are asking for, it might be a decent solution.

If you create a Windows File Share on a computer on the network and enter the Download URL for the mining software as "\\somecomputer\somefolder\myminer-1.0.5.zip", your Remote Agents will automatically download and use this one if missing. Please note that the only way for the Remote Agent to get a newer version is if you actually change the filename to a new version number.

There is a rule for doing cleanup of all downloaded/uploaded mining software. Via the acton "Miner command" you will find the Cleanup-command. It can either be scheduled or used with "manual activation" via the toolbar. It's however not as perfect as you describe as it's currently doing cleanup of all mining software - so I don't think it can be used while mining. Your point about doing cleanup of only older software is a good point and can be a good improvement to make.

Yeah, that sounds like a big bandaid which isn't all that different then manually managing everything myself (which I currently do). I can custom sync everything, but it would be nice if there was actually a feature in AM so I don't have to make custom rules or manually clean things up with batfiles.
newbie
Activity: 107
Merit: 0
Initialize diagnostics (10)
Starting Diagnostics. Awesome Miner Remote Agent version: 6.0.8
OS: Microsoft Windows 10 Enterprise 64-bit
AMD driver version: BETA
Microsoft VC++ 2013 runtime installed: Yes
Microsoft VC++ 2015 runtime installed: No
Starting Mining Software
Setting up Miner Engine. Instance: 1
Engine Type: WildRigMiner, Auto Download: True, EnginePath: , Subtype: Disabled, CustomExecutable:
Properties: (WindowMode: ConsoleFormat, EngineType: WildRigMiner, IsProfitMiner: True)
====================================================================================================
C:\Users\RED\AppData\Roaming\AwesomeMinerService\wildrig-0.15.0.6-beta_1\wildrig_avx.exe  --opencl-launch=256x0 --send-stale  -a x17 -o stratum+tcp://x17.eu.mine.zpool.ca:3737 -u 15NRifmpqUx8DeNg1E6EZM2wNoykf2muDy -p c=BTC --api-port=4028
Configured command line:
--opencl-launch=256x0 --send-stale
====================================================================================================
>  * VERSIONS:     WildRig/0.15.0.6 beta libuv/1.21.0 OpenCL/2.0 MSVC/2015
>  * CPU:          Intel(R) Celeron(R) CPU G1840 @ 2.80GHz x64 -AES-NI
>  * ALGO:         x17
>  * POOL #1:      x17.eu.mine.zpool.ca:3737
>  * API PORT:     4028
>  * COMMANDS:     'h' hashrate, 'p' pause, 'r' resume
Mining Engine Process started, PID: 3664
> [08:50:39] donation: 2%
> [08:50:39] strategy: 0
> [08:50:39] send-stale: yes
> [08:50:39] watchdog: disabled
> [08:50:39] good-risers: default
> [08:50:39] compiling code and initializing GPUs. This will take a while...
> [08:50:39] GPU #0 [BusID: #1] [Ellesmere] Radeon (TM) RX 480 Graphics
> [08:50:39] threads: 1, intensity: 256, worksize: 0/256, cu: 36, memory: 8192Mb
> [08:50:40] Error CL_INVALID_KERNEL_NAME when calling clCreateKernel for kernel 'mtp_yloop'
> [08:50:40] Failed to start OpenCL threads
newbie
Activity: 117
Merit: 0
I noticed that the ANON is not correctly displayed on coincalculators, but on whattomine is correct.
I did a rewrite in the awesome ANON to ZHASH settings but it didn’t work.
I think coincalculators report incorrect data.

It would be nice to add to the awesome calculator priority function for a single coin.
jr. member
Activity: 756
Merit: 2


I have something to say about something that they always ask me about the telegram group, and from so much explaining it, I myself have doubts. I hope to explain it well because then when translating everything is changed.

It is about the change of profit 0.9 or 90% etc ... And especially in the auto exchanges like Zpool.

I think, and I repeat, I think it's not quite right or at least it does not look good.

I have for example Zpool with Skun, and there I mark a profit calculated of 0.69% for that protocol, but the price that I get on the screen is the price of Zpool without applying the profit reduction, that is 69%. That is true?

If so, any currency that I change the profit, or in the auto exchanges that auto calculate the Profit, should reflect the price already modified by the corresponding profit.

for example if SKUN in Zpool says that I get 0.0020, that's what it says in Online Services, but I really should dial 0.0020 - Profit, in this case 0.67, would be equal to 0.00134 which is what I should show.


Because to show the prices without modifying the profit, the listings when ordering them for benefits, it does without calculating the profit change and this drives me crazy and they ask me hundreds of questions in the group related to that.

Sometimes there are users who are excited to see a high amount and leave only one Al-go because it marks a very high profit, but that amount has not been subtracted from the profit. Be a loose coin or the al-go of an auto exchange.

Then in the group they tell me, is that I mined X but I won -X, I mean less, because they only pay attention to the profit of the currency that has not applied the profit in real time, which is how it should be. or that or Zpool is cheating us. But also useful when I measure currency / pool and get 0.85, the price that should appear on the AM screen should be the (price - profit) already applied to give more truthful information and close to reality.

Sometimes I get the impression that the change of profit is not taken into account, but that is an observation of mine that can be wrong.

I really have serious doubts if that modification of profit is being applied both in the prices that we see and in auto profit. Because there are many who ask me and drive me crazy in the telegram group with this topic. I think I remember, that is taken into account but do not reflect it on the screen and I personally believe that the price should be reflected on the screen already modified by the profit, thus avoiding mistakes and giving the most accurate information.

I await your comments @Patrike
I'm looking at Zpool Skunkhash right now like you suggested.

The Zpool API reports the current profitability per MH/day:
"estimate_current":"0.00000235"

You can use this link to see the values provided for zpool for each of the algorithms: https://www.zpool.ca/api/status

My Awesome Miner shows BTC/GH/day as 0.0014 BTC, Actual Payout as 61.68% and Revenue as 0.00062 BTC right now using your hashrate. This is close to the numbers in your screenshot.

If I take the reported profit from Zpool, convert it from MH/day to GH/day and multiply with 61.68%, I get the following value for BTC/GH/day:
0.00000235 * 1000 * 0.6168 = 0.00144 BTC

This is the value you I see in the BTC/GH/day column in Awesome Miner - so the calculations are correct. It's also very close to the numbers you showed a few hours earlier. Multiply with your hashrate in GH (0.43269), you will get the Revenue of 0.00062 as displayed in my case.

If I set a custom Profit Factor for Zpool of 0.5 - I also verified that all BTC values on the Online Services tab are cut in half for Zpool Skunkhash - so that also looks fine.

What I'm not sure about in your screenshot is the Profit column as it looks like the same as the Revenue column. This will of course depend on power cost settings and so on so I cannot verify if it's correct. Is the Profit column an issue here?


Thanks for the explanation, now everything is clearer and I can explain it better to my people.

In the discord channel of the owner of CTM I have reported several currencies that the result they show is always the lowest sale price, instead of the highest bid, which I always use.

The API programmer constantly refuses me and gives me examples and says it's more your fault than your API.

I tell you what you tell me, you can enter the general channel of the discord where I have developed the conversation to see my captures and evidence that the price is wrong and its explanations like that he does it well and that you are really reading poorly the API. Something that I do not believe and that surely has been solved in these days but is too proud to recount failures. Whatever it is, please read the Cointomine channel, in your discord, give examples of the API.

regards
newbie
Activity: 45
Merit: 0
I've been having a very frustrating problem the last couple of weeks - every few hours a miner randomly "fails to start", and then I get the modal dialog asking me to run diagnostics. Every single time I run diagnostics absolutely nothing is wrong. So one by one my miners are stopping, and I have to check every few hours, clear 5-10 of these dialogs, start the miners back up, and they work every single time. So there has to be some bug in AM causing this, because there's certainly not a problem with the miners or the rigs if the miner starts right up every time.
Nope, that's definitely not it. Something must have changed in awesome miner, because this only started happening recently.
If you get the dialog that the miner failed to start, it's because the mining software has crashed a number of times over the last few minutes. After a number of attempts of restarting it, Awesome Miner will give up and show this error.

You can configure Awesome Miner to continue trying to restart the crashed mining software via the Options dialog, Mining Settings section, where you can set the restart attempts to 99. As the number of attempts are based on the last few minutes, a value of 99 will basically make Awesome Miner trying to restart the mining every time it's crashes and never give up.

There are no recent changes in Awesome Miner to this behavior.

There can be instances where mining software crashes a number of times for a while, but when starting it with the exact same settings a little later, it will no longer crash. Temperature is a common cause why the problem resolves itself, but I suppose there can be many other reasons why mining software don't give consistent behaviors with the crashes.

For the crashes you may have to do general troubleshooting to find out if it's a specific algorithm or mining software or mining rig or clocking settings that causes the problem.

I've set it to restart as many as 10 times, and while I'm using the program if the dialog pops up, I can click it *immediately* and it always still works. Furthermore, I tried to set a rule where it would wait 10 seconds before starting the miner again, but the modal dialogs seem to block that rule from executing (and who knows what else). For instance this morning I had 3 of those dialogs on top of each other, I clicked no to all of them, and then a few seconds later, the rule triggered and all three started up just fine. There at least has to be some way to turn this blocking dialog off if it's going to prevent me from setting rules to correct this inexplicable behavior.
Thanks for the update, I understand your point.

Do you get any entry on the Notifications tab about this issue?

Could you please send me the log file for this Remote Agent and also for the Awesome Miner main application - and let me know the time and the name of the miner? I will investigate to find out what the scenario looks like. Thanks!


Quote
12/22/2018 6:16:22 PM.152 [009] [ManagedMiner#290 - J7 4x 1070 GB 2x 1080TI MSI-X] Starting...
12/22/2018 6:16:23 PM.167 [009] [ManagedMiner#290 - J7 4x 1070 GB 2x 1080TI MSI-X] Starting Mining Software
12/22/2018 6:16:23 PM.167 [009] [ManagedMiner#290 - J7 4x 1070 GB 2x 1080TI MSI-X] Setting up Miner Engine. Instance: 1
12/22/2018 6:16:23 PM.167 [009] [ManagedMiner#290 - J7 4x 1070 GB 2x 1080TI MSI-X] Engine Type: CcCryptoDredgeEngine, Auto Download: True, EnginePath: , Subtype: Disabled, CustomExecutable:
12/22/2018 6:16:23 PM.167 [009] EngineSetup: CcCryptoDredgeEngine
12/22/2018 6:16:23 PM.167 [009] [ManagedMiner#290 - J7 4x 1070 GB 2x 1080TI MSI-X] Set clocking start profile: 59, 60%/+100/0/Auto (when stopping, the following will be used: -1, type: Single, Use: False)
12/22/2018 6:16:23 PM.167 [022] ApplySingleProfile Begin
12/22/2018 6:16:23 PM.167 [022] Preparing authentication header for MSI Afterburner requests: MSIAfterburner:17cc95b4017d496f82
12/22/2018 6:16:23 PM.199 [022] Number of GPU commands: 20
12/22/2018 6:16:23 PM.199 [022] Executing GPU clocking command: /setmacm, powerLimit0=60&coreClockBoost0=100000&memoryClockBoost0=0&fanSpeed0=auto&powerLimit1=60&coreClockBoost1=100000&memoryClockBoost1=0&fanSpeed1=auto&powerLimit2=60&coreClockBoost2=100000&memoryClockBoost2=0&fanSpeed2=auto&powerLimit3=60&coreClockBoost3=100000&memoryClockBoost3=0&fanSpeed3=auto&powerLimit4=60&coreClockBoost4=100000&memoryClockBoost4=0&fanSpeed4=auto
12/22/2018 6:16:23 PM.199 [022] Preparing authentication header for MSI Afterburner requests: MSIAfterburner:17cc95b4017d496f82
12/22/2018 6:16:24 PM.183 [020] [ManagedMiner#290 - J7 4x 1070 GB 2x 1080TI MSI-X] : ProcessMiner
12/22/2018 6:16:24 PM.183 [009] [E]System.NullReferenceException: Object reference not set to an instance of an object.
12/22/2018 6:16:24 PM.183 [009] [E]   at AwesomeMiner.Service.Core.Engines.EnginePrepareBase.GetStaticSortedPools()
   at AwesomeMiner.Service.Core.Engines.EnginePrepareBase.ProcessVirtualEffectivePool List()
   at AwesomeMiner.Service.Core.Engines.CcMiner.CcEnginePrepare.BuildArguments()
   at AwesomeMiner.Service.Core.Engines.MinerEngine.Start(Int32 #=znFEPBq4WhQQq, Boolean #=zm8OVyhw=, Boolean #=z3_DDggA=, BenchmarkCommand #=zG2LTkxarwMBnUeaT5w==)
12/22/2018 6:16:24 PM.183 [009] [E][ManagedMiner#290 - J7 4x 1070 GB 2x 1080TI MSI-X] Failed to start miner process: Object reference not set to an instance of an object.
12/22/2018 6:16:24 PM.183 [009] [E][ManagedMiner#290 - J7 4x 1070 GB 2x 1080TI MSI-X]Failed to start miner
12/22/2018 6:16:25 PM.199 [020] [ManagedMiner#531 - CPU-J7] : ProcessMiner
12/22/2018 6:16:27 PM.027 [022] ApplySingleProfile End
12/22/2018 6:16:29 PM.246 [038] [ManagedMiner#290 - J7 4x 1070 GB 2x 1080TI MSI-X] : ProcessMiner
12/22/2018 6:16:30 PM.262 [038] [ManagedMiner#531 - CPU-J7] : ProcessMiner
12/22/2018 6:16:34 PM.325 [020] [ManagedMiner#290 - J7 4x 1070 GB 2x 1080TI MSI-X] : ProcessMiner
12/22/2018 6:16:35 PM.341 [020] [ManagedMiner#531 - CPU-J7] : ProcessMiner
12/22/2018 6:16:39 PM.388 [022] [ManagedMiner#290 - J7 4x 1070 GB 2x 1080TI MSI-X] : ProcessMiner
12/22/2018 6:16:40 PM.404 [016] [ManagedMiner#531 - CPU-J7] : ProcessMiner
12/22/2018 6:16:44 PM.435 [007] [ManagedMiner#290 - J7 4x 1070 GB 2x 1080TI MSI-X] : ProcessMiner
12/22/2018 6:16:45 PM.451 [038] [ManagedMiner#531 - CPU-J7] : ProcessMiner
Jump to: