It seems that I have some problem with nethash, whether I buy it from for example BSOD, or even selecting CTM or CC, to obtain Nethash. There are moments that correctly shows the nethash and gives a realistic profir, in this case right now about 500 ghs for veil, but at times it goes to 240 Th / s of nethash and the currency sinks.

At times shows the nethash well, at times shows the burrada of 240 THs.

If I use the CC APi in custom and look for the value, I exceed 500 requests per day, because each currency is a request. In addition, the CC data is well below the real hash according to other sources.

https://www.coincalculators.io/api.aspx?name=veil&hashrate=1
json currentNethash

VEIL has a pretty weird explorer
https://explorer.veil-project.com/
where we can not extract the nethash. IF I use the providers, because you give to choose the 3 that there are, it also gives me failure.

If I use the BSOD data, I get the data well for a while and more or less well, but then it goes to 240 Ths, then it's fine again then again it gives it badly
http://api.bsod.pw/api/currencies
json VEIL.network_hashrate

I do not put data out of laziness.

For that I ask who can pass me the general API of Yiimp, where all the pools based on Yiimp take the data, to request them there, or could even be defined as a nethash provider.

Anyway the formula of obtaining BSOD serves me, the problem is that at times I show the correct nethash, about 500 right now and suddenly it goes to more than 200 ths, then it goes well, then badly and so all the time .

@patrike or @moppidoo can you provide me with the general Yiimp API url, where all the yimmp pools take the data?

As always, thank you for your compression of the problems and be the first to want to solve them. That says a lot about you as a good programmer.

As a last suggestion doubt. A rule that changes the fan speed of the rigs graphics without having to restart the mining.

Thanks in advance for the types of profit. It is clear that the other type of profit requires much more work, we in our group assume it, and when closer to reality better.

Last detail, the benchmark. When I do a 2 or 5 hour test, what value does it give?

The last value he had at the end of the test
The highest peak of hash
The average of the hash of those 5 hours (This would be the correct one)

I do not know exactly what data is the one that shows and saves the benchmark.

I will answer my previous question. It does not matter 2 hours, 5 hours or 10 hours, it will always give you the last value of the last share. It does not average

So it does not work to put x16r, x16rt, x16s, X17 and the other X, because it will not make an average hash, it will only take the last hash sent after 5 hours.

So far I do it manually, I set to mine x16R I leave it at least 2 hours, I take captures every 10 minutes and then average the hash value of all the captures. That is a very heavy work, and more when each rig is different.

@patrike should average the benchmar hash, if not, the benchmark is totally useless for AL-GOS that change subalways, it just is not worth it.

@PAtrike is there no way to average the hash value of 2, 5 or 10 hours, during a benchmark?

https://www.dropbox.com/s/6i4nu2mjviw3y67/Captura%20de%20pantalla%202019-04-13%20a%20las%206.35.30.png?dl=0


You will see the Xfox currency and its estimate of more than 7000 coins in a day (rigti 1080ti). But it's wrong, I think the formula of your profit is not very accurate and I can say it because we measure and test all the currencies / pool and elprofit is between 0.70 to 0.95 90% of the time, but it's not what same mine to 0.80 that to 1.

In this case, this Xfox coin has a blocking time of 2 minutes and has a reward of 2.79 (removing fee from the pool), the maximum coins per day is from 2008, it does not matter how many machines and the hash is the same because the difficulty it adjusts itself, the maximum is 2008 coins per day.

With which his estimate is completely wrong in this currency and slightly deviated in many others, but it is no longer a question of data, it is a question of formula.

You must take into account block time, reward and nethash, to have a more accurate profit. It is a more complex formula, more data to take into account and we must take into account the maximum coins per day for the estimates offered by AM

It is only a constructive criticism, we customize all fields, difficulty, recommensa, price of exchanges directly (that's why it would be good to cache results between requests)

It's just an example where the formula is not right. Neither can it be to mine ZEL when its real profit is 0.65 and so many currencies. You imagine mining ZEL to profit 1, but then only receive 65% of the mined. That's why I recommend everyone to do pool and coin tests, if you change the pool you have to repeat the test.


Last detail, the benchmark. When I do a 2 or 5 hour test, what value does it give?

The last value he had at the end of the test
The highest peak of hash
The average of the hash of those 5 hours (This would be the correct one)

I do not know exactly what data is the one that shows and saves the benchmark.

I feel so critical, it's a huge job, full of great difficulties, all this is normal.

Your current formula can be used in some way for the autoexchanges, because there you do not know what currency mines or their data, and there their formula makes sense.

To mine direct currencies, it is not adequate, it can and must be improved.

What produces maximum to the day (block and reward). What is the total hashnet, how much do I contribute (my participation), therefore how many coins per day can I get x price of the currency (profit)

And take into account the maximum daily production of coins per day, so as not to give strange numbers very high as in the example I have set.

I think you're wrong in what you say. Although I create another profile, if I leave the other values at 0, in the end it will be 100PL 0 core 0 memory and fan speed.

When you apply an oc profile, the entire complete profile is applied, not just one parameter.

If I'm wrong, leave me here a screenshot of how I should leave the OC profile, but before you try it, it really works.

through modification of profile clocking, I must choose another complete profile that has the quality of 80% of fixed FAN. But that's what I say. If I have 100 OC profiles, I have to make another 100 equal ones that only change from automatic to one with fixed speed. It is not an option for me. I work with more than 20 people, I work with 1060, 1070, 1080ti and RTX, you know how many OC profiles I have. To think that I have to duplicate all of them and have another with fixed speed does not work for me.

I hope that ne future add a rule option in which only change the speed (internally load the chosen profile or change the car to a fixed number determined by me), I do not see it complicated. And with only one rule I have everything solved.


https://www.dropbox.com/s/e2icft05d0cll2b/Captura%20de%20pantalla%202019-04-11%20a%20las%2019.19.51.png?dl=0

That option of the image, as you said is for ASIC, but it would be perfect as is for GPU, that respects the OC of Pl, Core and MEM, and that only changes the FAN. As I already have other rules that if it reaches 82 degrees it changes to another profile, it works very well and if it reaches 84 it turns it off. I do this in case fans are broken, the miner shuts down.

I hope you add it someday, something as simple as capture and work in GPU. Internally the rule would throw the same OC just by changing the fan.

----
When you use the GPU Clocking dialog and select Save As, you can specify which GPU parameters to save to the profile. You can for example save only the fan speed property set to a value like 85%. I can agree that the usability should be improved a bit here.

You can then have a rule to apply this "Fan 85%" clocking profile to a running miner. It will not change the Clocking Profile permanently, but it will change the fan to 85% for a running mining.

-----------

as you say in those two paragraphs. What I propose is to create two equal profiles, one with AUTO and another with a fixed speed fan, and by a rule use it. I do that when the temperature reaches 84 degrees and change to a very smooth OC and if it reaches 85 the miner stops.

But when applying a rule I can only choose an OC to change. Whatever my OC, the rule will only change to an OC that I choose. It is not the solution I am looking for, since I use multiple OCs according to the AL-GO and the miner in question, I would have to make hundreds of rules, one for miners and for each personalized OC.

If you already know that you can change the OC in real time and really use it to protect the cards. I do not understand why there can not be a rule that only changes the FAN regardless of the OC configuration that you are using, which are many. It is only the FAN is not complicated, the rule can take the current data of the OC that is in progress and only change the value of the FAN of AUTO to a fixed Speed, as easy as that.

I hope you have explained me well.

The problem I see with the overclock groups is that I should do many, but many. I already have about 100 individual profiles, type

85 90 +400
85 85 +400
85 85 -400

PL - Core - MEM

and they are called like that, and then from each miner in each protocol or AL-GO to be able to choose an OC that just by reading the name on the OC that I am going to apply. But do 100 groups and customize card to card is not an idea, because then a group would only serve for a rig in question, for their cards and their independent oce. At the end there would be many more groups, a lot of extra work

I have no choice but to work with fixed speed, but it seems like a savage to have 80% a whole year a fan, that's why I like the automatic one more. What I propose are two easier solutions for everyone.

At the time of defining an OC, I know that I can choose either fixed or auto, but inside the car there could be a box marked something like "aggressive" where the AUTO is higher than normal. Or a rule that really works in real time with the rig GPU without resigning.

With aftherburner if you changed from auto to manual the fan, it did it without stopping to mine, because you can not do that AM through a rule ?. They have already passed the Nvidia documentation on the commands they use, sure there is a way to do it.

That will allow an automatic use of the fan, and only if a card exceeds the limit, raise the speed to the whole rig, without having to restart mining. Creating Groups is not feasible for me having more than 100 profiles already made of OC, and OC groups are taking into account card by card, which would be many more. There must be something simpler, Just for that reason I'm rethinking Aftherburner although I know it has problems, but I can define an aggressive line of Automatico and leave the problem aside, but then every X time does not work and I have to change the folder The remote server is very messy.

If all my rigs were equal, their option would be valid, but since each rig is different in card and power brands, I can not stop making OC groups that should be customized to that rig, and then other dozens of OC groups to another rig etc ...

@Patrike, in the rules, you can know the temperature of the cards and put a rule. But I do not see that it works. The rule can detect the temperature, 80 degrees in my case, and I indicate that the fan works fixed at 80%, but it does not. It seems to me that this one more thought for asic, surely it would have to restart miner in GPU, but to do it also it lowers the temperature and the rule does not shoot.

There some way to do what I indicate, and to apply a fixed speed to all the cards of the rig, without having to restart miner ?, would be an ideal solution for this situation, and summer is near.

It is not feasible to do so, power can be, but it is not appropriate. I have 6 rigs, and I use about 20 Algos. I have established about 100 OC profiles.

What you are saying is that you make another 100 OC profiles with a fixed fan speed. I'm sorry but that's Chinese work.

There must be simpler options than what is proposed, which for an RIG may be worth and even so, there would be several profiles, at least 2 for each SOMETHING.

Well, what a silly problem, I have corrected it, but this poses another problem.

Because using an OC profile with automatic FAN, some cards reach 80 degrees and do not exceed 60% of FAN? it is assumed that at that temperature in automatic, the fan should go much faster than 60%.

We know that in Aftherburner you can create a speed line based on temperature and it would go automatically. Here it does not exist, but there could be a slider button or a number from 1 to 10, where the FANS were more aggressive, that means they go faster than revolutions at a lower temperature, or higher. Being 10 very aggressive and 1 very soft. Or something similar. Because although native OC works very well, its big problem is the automatic control of the fans.

As I say I see more than one card at 80 degrees and the fan at 60%. This happens to me in several cards of different rigs, it is as if some mark of Nvidia is not controlled well. In the capture you can see one at 80 degrees and 60%, but you will see others that have more speed and less temperature. I really do not know how to correct that, unless I use fixed fan speeds

where I get the Api report, I have looked and I do not see anything to have it. Please tell me how I do it

Sorry, I found it, I sent it to MP. Let's see if we can see what happens. Because to me the problem that it gives me is that it does not do a good control of the automatic fan and it is 80 degrees and 60% fan. I have to put profiles with the FAN fixed at 70 or 80% but I like more the performance of the car, but this confusion of cards must be.

https://www.dropbox.com/s/udd9r53npzgcbu7/Captura%20de%20pantalla%202019-04-09%20a%20las%2021.27.52.png?dl=0


I have a problem that I do not know how to fix. Please see the image

The rig 4 you can see in the capture, down in GPU says that I have 1050, 1050, 1060 And that was before, some time ago.

In the MAP GPU box if you see correctly 5x1070 1x1080ti, that is correct. But even if I map the cards, I still see 1050, 1050, 1060 etc ... And above all I have problems with the automatic speed, as it assumes other GPUs because it uses a different speed, usually a low speed, with which the GPU heats me. I had to force 80% GPUs in that profile.

How can I make AM recognize my real cards in GPU with their real names and real characteristics? As much as I remove the Mapping mark and then map again, the old cards keep appearing.

It would also be interesting that if an api gives a failure (it can not read the api) it appears in notifications, thus I will not be hours undermining the same difficulty without knowing that something fails.

good decision, those two values ​​through http api as we are using difficulty or price, will make the data much more realistic.

I am not a user as advanced as moppidoo, I will not use an external Exel and handle my own data. But if you read the apis and Json, and the power to add blocktime and nethash, you could give us something of value by choosing between the two possible ways of doing the profit calculation that you explained to me.

We in our group use an online excel and we have pointed the urls of difficulty, price, request of the price, profit of the currency etc ... We have noticed that when a currency its blocktime is higher than 1, the profit is usually lower . If the blocktime is 1, the value is usually quite close to what AM indicates. There are coins that we have to use profit of 0.65 so that the estimate of AM and what is obtained is the same.

To be able to add these two data and be able to use them for self-profit in some way, instead of its classic formula, could be interesting. Have two types of profit to choose, two different formulas. One based more on the nethash and blocktime, and the classic one of you.

One last suggestion Is there any way that all the data in AM can be saved from the last time data has been requested from the APIs? I explain. I use CC and make a request every 7 minutes and read all the data, but then I make requests from loose currencies defined by us that if we do not find the Explorer or we can not read the explorer, we use WTM, CC or the one we see more realistic. But then we exhaust the requests per day, because each currency that I ask for a data, is a request to the api.

If in each complete request of api of WTM, CC, CTM, Coinwarz, the last one is stored in AM, and that data could be read from the cache of the last time within the AM itself, the problem of excess requests to these services.

But that's basic, we also make requests to Exchanges to extract the price, if every 7 minutes I read 24 coins of the same exchange, make 24 requests, and in a few hours I am unable to ask for more data to that exchange. I do not know if once an API is read, whatever it is, it is saved in a kind of cahe, whether it is an exchange or a provider, and only save the last time it was requested, in my case every 7 minutes. So if I have to read several prices of different currencies of the same exchange, I read it in local because I have the copy of the received in the api.

I hope you understand my idea.

when you add the times you made the change, and know how many times I change each coin to get the% they have. For me it is an important fact to know if a currency with a small percentage has many changes, it is a currency that I do not want to undermine. It would be nice to have that data in that panel of statistics next to the% of time of use of that currency.

If so, then it works. But is not it easier to know the blocking time than the exponential factor? They are just my doubts.

A technical question Patrike

The other day you told me that you do not take into account the blocking time to calculate the auto profit, it surprised me a lot. Because the reward + blocking time determines the amount of maximum coins produced per day.

A coin with 2 minutes of blocking and 100 of reward, will make a maximum of 72,000 coins a day, but if the time of blocking is 1 minute will make 144,000 coins per day

How can profit be calculated without this data?
  In AM CU I asked for it and I see it logical. There are coins with blocking time of 5 and up to 10 minutes.

How can you compensate for that lack of this data in the system of self-profit, when it is crucial to know how often it will give a block and therefore reward and therefore profit.

I have a problem with Miniz, I have activated it before using it in the rig. Then I went to Zhash and I changed Gminer for Miniz, but it does not start, it's more, I think it tries to start Bminer.

I have not changed anything in the pool, it is assumed that if the pool is fine for Gminer, it should be fine for Miniz. I leave the log here, and I continue with Gminer.



Initialize diagnostics (20)
Starting Diagnostics. Awesome Miner Remote Agent version: 6.2.12
OS: Microsoft Windows 10 Pro 64-bit
nVidia driver version: 418.96
nVidia OpenCL Platform ID: 0
Microsoft VC++ 2013 runtime installed: Yes
Microsoft VC++ 2015 runtime installed: Yes
Starting Mining Software
Setting up Miner Engine. Instance: 1
Engine Type: BMiner, Auto Download: True, EnginePath: , Subtype: Disabled, CustomExecutable:
Set clocking start profile: 135, RTX 70 +100 +600 (when stopping, the following will be used: -1, type: Single, Use: False)
Properties: (WindowMode: ConsoleFormat, EngineType: BMiner, IsProfitMiner: True)
====================================================================================================
C:\Users\truco\AppData\Roaming\AwesomeMinerService\bminer-v15.4.0-9e272fc-amd64_1\bminer-v15.4.0-9e272fc\bminer.exe  --pass minpayout=625 --pers BitcoinZ -uri stratum://t1dcY5Vwz8ABGgnrMCzzfWz1XLHRh1mK4m5.rig6@btcz.2miners.com:2020 -watchdog=false -api=0.0.0.0:4028
====================================================================================================
Mining Engine Process started, PID: 6796
> Bminer: When Crypto-mining Made Fast (v15.4.0-9e272fc)
>
> flag provided but not defined: -pass
>   -api <host>:<port>
>        The endpoint (i.e., <host>:<port>) that bminer serves its REST API. The REST API is disabled if it is unspecified.
>   -devices GPUs
>        List of GPUs that Bminer should run on. By default bminer runs on all GPUs available on the system.
>   -dual-intensity int
>        The intensity of the secondary mining. Valid values are 0 to 300. Default is 0, which is to tune automatically.
>   -dual-subsolver int
>        The sub-solver for dual mining. Valid values are 0, 1, 2, 3. Default is -1, which is to tune automatically. (default -1)
>   -failover sameHost|immediateNext|random
>        Fail-over strategy between multiple pools. Bminer can retry the connection, failover to the next pool or a pool that is randomly chosen in the lists of available pools. (sameHost|immediateNext|random) (default "immediateNext")
>   -fast
>        Enable agressive optimizations. Bminer is more performant under this setting but it might be unstable on some OS/drivers
>   -gpucheck uint
>        The interval in seconds that Bminer polls whether the GPUs have hung. Set to 0 to disable the checks. (default 90)
>   -intensity int
>        The intensity of the CPU for grin/AE mining. Valid values are 0 to 12. Default is 6. Higher intensity may give better performance but more CPU usage. (default -1)
>   -logfile <path>
>        Append the logs to the file <path>.
>   -max-network-failures int
>        Number of consecutive attempts that Bminer tries to recover from network failures. Set to -1 to keep on recovering. (default -1)
>   -max-temperature int
>        Hard limits of the temperature of the GPUs. Bminer slows down itself when the temperautres of the devices exceed the limit. (default 85)
>   -no-runtime-info
>        Disable runtime information collection for Bminer.
>   -no-timestamps
>        Suppress timestamps in the logging messages.
>   -nofee
>        Disable the devfee but it also disables some optimizations.
>   -pers string
>        Personalization string for equihash 144,5 based coins. Default: BgoldPoW. Valid values include BitcoinZ, Safecoin, ZelProof, etc. (default "BgoldPoW")
>   -share-check uint
>        The interval of seconds that Bminer polls to ensure there are accepted shares. Set to 0 to disable the checks. (default 900)
>   -strict-secure
>        Verify the certificates of servers when connecting to a SSL-enabled Stratum server.
>   -uri <scheme>://<username>[:<password>]@<host>:<port>
>        A comma-seperated list of URIs that bminer should mine towards. It has the format of <scheme>://<username>[:<password>]@<host>:<port>. Please refer to https://www.bminer.me for the specification of the URIs.
>   -uri2 <scheme>://<username>[:<password>]@<host>:<port>
>        A comma-seperated list of URIs that bminer should mine towards secondarily. It has the format of <scheme>://<username>[:<password>]@<host>:<port>. Currently Bminer supports blake14r:// or blake2s:// as secondary for ETH mining. Please refer to https://www.bminer.me for the specification of the URIs.
>   -watchdog
>        Automatically restart to recover from hung GPUs. Bminer exits itself in case of errors if watchdog is disabled. (default true)

====================================================================================================
Unexpected exit of mining software. Possible cause: Incorrect configuration or crashing software
Diagnostics completed

I have seen patrike that you have returned add the PRofit value in the properties of the coin, in tabs coin by double clicking on a coin

That was before and it was removed, and let's say that the one that has preference is the profit of the currency pool.

How does this new Profit affect the Specs of the currency? It seems to me redundant. If people have problems in finding the profit in the coin pool, pass it from the AVANCED tab and put it under the Password of the pool or a more visible site

TEner two profit can lead to confusion. Can I continue using the currency pool in avance as it is now, and this will affect the currency, profit and the coins tab?