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

powerstr

newbie

Activity: 107

Merit: 0

Kernels from the archives lured you mtp_yloop missing you missed them

powerstr

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.

patrike

legendary

Activity: 3346

Merit: 1094

Quote from: powerstr on December 23, 2018, 03:40:53 AM

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

patrike

legendary

Activity: 3346

Merit: 1094

Quote from: baf28 on December 22, 2018, 10:47:39 PM

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.

patrike

legendary

Activity: 3346

Merit: 1094

Quote from: trucobit on December 22, 2018, 10:23:26 PM

Quote from: patrike on December 22, 2018, 05:15:22 PM

Quote from: trucobit on December 22, 2018, 11:06:24 AM

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/

patrike

legendary

Activity: 3346

Merit: 1094

Quote from: darius510 on December 22, 2018, 09:07:16 PM

Quote from: patrike on December 22, 2018, 05:00:16 PM

Quote from: darius510 on December 22, 2018, 09:52:58 AM

Quote from: patrike on December 22, 2018, 05:37:53 AM

Quote from: darius510 on December 21, 2018, 07:13:26 PM

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.

Quote from: darius510 on December 21, 2018, 10:02:50 PM

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!

bensam1231

legendary

Activity: 1764

Merit: 1024

Quote from: patrike on December 22, 2018, 04:58:36 PM

Quote from: bensam1231 on December 22, 2018, 06:26:11 AM

Quote from: patrike on December 22, 2018, 06:14:10 AM

Quote from: bensam1231 on December 22, 2018, 03:26:42 AM

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.

powerstr

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

baf28

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.

trucobit

jr. member

Activity: 756

Merit: 2

Quote from: patrike on December 22, 2018, 05:15:22 PM

Quote from: trucobit on December 22, 2018, 11:06:24 AM

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

darius510

newbie

Activity: 45

Merit: 0

Quote from: patrike on December 22, 2018, 05:00:16 PM

Quote from: darius510 on December 22, 2018, 09:52:58 AM

Quote from: patrike on December 22, 2018, 05:37:53 AM

Quote from: darius510 on December 21, 2018, 07:13:26 PM

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.

Quote from: darius510 on December 21, 2018, 10:02:50 PM

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

patrike

legendary

Activity: 3346

Merit: 1094

Awesome Miner version 6.0.8 ( Development preview of 6.1 )

ASIC mining
- Antminer S15 supported
Features
- Exchange filtering redesigned and can be configured both globally and per coin. Supported for CoinCalculators.io and CoinToMine
- Note: Any previously specified exchange filter settings based on API string matching must be re-defined with the new filtering concept
- Exchange volume filtering implemented for all coin statistics providers
- The Coins tab will indicate the information that didn't pass the filter settings
- Additional power usage and operating cost can be defined globally in the new Profitability section of the Options dialog. The values will affect the total power usage and profitability displayed on the dashboard and the total values in the miner column header.
- Additional power usage and operating cost per miner can be defined in the Profit Profile. The values will reduce the profitability of a miner.
- Display actual power usage in the Speed column for the cases where mining software can report the power. This feature will be improved in one of the next releases to provide power usage for both AMD and nVidia GPU's no matter which mining software are running.
API
- Improved the HTTP API for coins with a new property to set the profit factor property
- Improved the HTTP API for coins with a new property to set if the custom properties of a coin should be used
User interface
- The Coins & Profit section in the Options dialog has been split into two new sections - Profitability and Coins.
- Coins with custom properties enabled will be highlighted in blue color on the Coins tab
Mining software
- Z-enemy Miner 1.28
- T-Rex miner 0.8.9
- Lolminer 0.6
- NBMiner 12.0
- Gminer Cuda Miner 1.12
- WildRig Multi Miner 0.15.0.6 beta
Corrections
- More detailed error messages in the log file if MSI Afterburner Remote Server is returning a failure code

This is a smaller development release update with mainly new mining software versions included.

There is however one more change that might look small at the moment, but I think it will be considered helpful within the next few weeks when it's completed. From this version released today, Awesome Miner will put the Power Usage in the Speed column for each miner.

Right now the value is only displayed if it's provided by the mining software and today it's only a number of nVidia based mining software that will display this one. So it's quite limited as of today.

Early January the plan is to not depend on the mining software for the power usage - instead Awesome Miner will read the current power usage from both AMD and nVidia GPU's and display for each miner. At this point (so not today) there will also be a new default behavior for profit display, where it will use the current power usage if available. As a fallback it will use the power values in the Profit Profile. Once all this is in place, it will also be configurable to use the classic way of profit calculations where the power value only uses what's in the profile.

For profit switching purposes, you will still need the Power values to be part of the Profit Profile, but saving the current power usage will be available for many more of the mining software.

To get access to development versions, open the Options dialog in Awesome Miner. In the General section, enable Check for development versions. Then go to the Menu and click Check for updates.

Direct download links if needed:
www.awesomeminer.com/download/setupdev/AwesomeMiner.msi
www.awesomeminer.com/download/setupdev/AwesomeMinerRemoteService.msi

patrike

legendary

Activity: 3346

Merit: 1094

Quote from: baf28 on December 22, 2018, 11:54:32 AM

GMiner CUDA Equihash Miner v1.12
Windows x64 https://mega.nz/#F!2GQl0AaR!_YzlNiVNNOUbEqYwz40E8A
v1.12
+ performance improvements for Equihash 144,5/Equihash 192,7
+ improved anti-hacking system, which should make life difficult for competitors.
The miner checks the application's memory for injections, if an injection is detected, a corresponding message is displayed.
Some antiviruses are inject into the processes, if the miner has issued a message about injectionion into memory, add a miner to the antivirus exceptions, this should solve the problem.

https://bitcointalksearch.org/topic/gminer-v324-ergokaspazilkawpowequihashcortex-5034735

PLS add

Thanks - this one will be included.

patrike

legendary

Activity: 3346

Merit: 1094

Quote from: trucobit on December 22, 2018, 11:06:24 AM

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?

patrike

legendary

Activity: 3346

Merit: 1094

Quote from: darius510 on December 22, 2018, 09:52:58 AM

Quote from: patrike on December 22, 2018, 05:37:53 AM

Quote from: darius510 on December 21, 2018, 07:13:26 PM

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.

Quote from: darius510 on December 21, 2018, 10:02:50 PM

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!

patrike

legendary

Activity: 3346

Merit: 1094

Quote from: bensam1231 on December 22, 2018, 06:26:11 AM

Quote from: patrike on December 22, 2018, 06:14:10 AM

Quote from: bensam1231 on December 22, 2018, 03:26:42 AM

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.

mmartoccia

newbie

Activity: 47

Merit: 0

Has anyone tried to flash the firmware of the Antminer S9 with the new Braiin OS through the Update firmware function of Awesome Miner?

baf28

newbie

Activity: 117

Merit: 0

GMiner CUDA Equihash Miner v1.12
Windows x64 https://mega.nz/#F!2GQl0AaR!_YzlNiVNNOUbEqYwz40E8A
v1.12
+ performance improvements for Equihash 144,5/Equihash 192,7
+ improved anti-hacking system, which should make life difficult for competitors.
The miner checks the application's memory for injections, if an injection is detected, a corresponding message is displayed.
Some antiviruses are inject into the processes, if the miner has issued a message about injectionion into memory, add a miner to the antivirus exceptions, this should solve the problem.

https://bitcointalksearch.org/topic/gminer-v324-ergokaspazilkawpowequihashcortex-5034735

PLS add

trucobit

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

darius510

newbie

Activity: 45

Merit: 0

Quote from: patrike on December 22, 2018, 05:37:53 AM

Quote from: darius510 on December 21, 2018, 07:13:26 PM

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.

Quote from: darius510 on December 21, 2018, 10:02:50 PM

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.

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