Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Strange API values for HMQ1725 #1043

Closed
acos0874 opened this issue Jun 9, 2020 · 10 comments
Closed

Strange API values for HMQ1725 #1043

acos0874 opened this issue Jun 9, 2020 · 10 comments
Assignees
Labels
enhancement New feature or request implemented an enhancement has been implemented pool issue

Comments

@acos0874
Copy link

acos0874 commented Jun 9, 2020

I have zergpoolcoins enabled and I keep getting crazy estimates from the API, even though I have it set to an hour average....

image
I've checked the zergpool page and the estimates seem fine, so could there be an issue with the API?

@acos0874
Copy link
Author

acos0874 commented Jun 9, 2020

I just realised my config files weren't on hour average as I expected, but were on minute_10. So I've switch over now to see if it's better. Is there a way to check on local host which average is in play?

@RainbowMiner RainbowMiner self-assigned this Jun 9, 2020
@RainbowMiner
Copy link
Owner

RainbowMiner commented Jun 9, 2020

Only possiblity to find the infos on localhost, is the "Running Config" page. Just search for "ZergPoolCoins" on that page. I have best results with "DataWindow": "estimate_current", and "StatAverage": "Hour",, on ZergPoolCoins.

@acos0874
Copy link
Author

acos0874 commented Jun 9, 2020

Yea I use current estimates too but have been using a value other than 'live' for the stat average. I think I figured it out though. I was using hour as the stat average for anything other than nicehash in the expectation that this, along with the switch prevention, would keep my miners away from highly volatile shitcoins.

Unfortunately it seems this had an unintended consequence, because the HMQ1725 coins are crazy volatily it actually meant the hour average was pushed so high, that the estimate stayed high for a long time. This probably wouldn't have been so bad with minute_10. I've switch back to live and the estimates seem more reasonable again.

@acos0874
Copy link
Author

acos0874 commented Jun 9, 2020

Were you experiencing the same high estimates using 'hour' as your stat average?

@RainbowMiner
Copy link
Owner

Yes, there has been a high (but reasonable) value for the HMQ1725 BRAZ coin. I think, the major uplift has been with ESP coin - which I have on my ExcludeCoinSymbol list on ZergPoolCoins. So I expect I didn't see much of a shocking value.
But since the API's estimates for ESP are most of the times out of range, I think, I'll put this coin onto the auto-ignore-shitcoins-list.

@RainbowMiner
Copy link
Owner

Ok, I have listed "ESP" on ZergPoolCoins as unprofitable.

@acos0874
Copy link
Author

acos0874 commented Jun 9, 2020

Ok. I don't mind if you leave it in there if it's due to a legitimate difficulty drop. I'm mining BRAZ coin right now.

@acos0874
Copy link
Author

acos0874 commented Jun 9, 2020

I discovered the error ratio for the HMQ coins had hit as high as 2, which seems a bit silly so I have disabled the error ratio setting. Is there a way to limit the error ratio number to have a maximum value?

RainbowMiner added a commit that referenced this issue Jun 10, 2020
- add param "MaxErrorRatio" to config.txt (issue #1043)
  - "MaxErrorRatio": Maxium error ratio for yiimp pool price auto-correction [default=1.5]
@RainbowMiner
Copy link
Owner

I have added a "MaxErrorRatio" parameter to config.txt (which defaults to 1.5, currently)

@RainbowMiner RainbowMiner added enhancement New feature or request implemented an enhancement has been implemented labels Jun 10, 2020
@acos0874
Copy link
Author

Nice thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request implemented an enhancement has been implemented pool issue
Projects
None yet
Development

No branches or pull requests

2 participants