API reporting inaccurate data for topminers

[magecrimson]

Describe the bug API reporting miners who are no longer connected. Current Hash for miners do not represent actual hash. Share % wrong.

To Reproduce Steps to reproduce the behavior:

1. Visit your API URL : /api/pools//miners
2. Compare with API URL: /api/pools//miners//performance
3. compare the two.

Expected behavior top miners in API and miners should reflect current miners with correct hash and share%

Screenshots

Using /api/pools//miners

[ { "miner": "GeXP26AAya5U6AaiG3WbXDQjV93cnr9Sxk", "hashrate": 93004, "sharesPerSecond": 1.4420000000000002 }, { "miner": "GceevmEmQDCRNFaJsUXuhQiEpwawaaAw6Y", "hashrate": 8542, "sharesPerSecond": 6.517 }, { "miner": "GVKL5aS8n2e2GX3JAtniR814kSCfGwr3tV", "hashrate": 1431, "sharesPerSecond": 0.137 } ]

Below is from the performance for the top miner above: using /api/pools//miners//performance

"created": "2022-07-28T12:00:00Z", "workers": { "ironman": { "hashrate": 549, "sharesPerSecond": 0.07920000000000002 }, "ironmancpu": { "hashrate": 479.6333333333333, "sharesPerSecond": 0.09096666666666665 }, "moose": { "hashrate": 312.8333333333333, "sharesPerSecond": 0.07380000000000002 }, "test": { "hashrate": 4659.1, "sharesPerSecond": 0.18983333333333338 }, "test10": { "hashrate": 2509.4666666666667, "sharesPerSecond": 0.14936666666666673 }, "test11": { "hashrate": 2706.5, "sharesPerSecond": 0.14383333333333334 }, "test12": { "hashrate": 2691.6666666666665, "sharesPerSecond": 0.14436666666666667 }, "test2": { "hashrate": 4885.9, "sharesPerSecond": 0.19196666666666665 }, "test3": { "hashrate": 4768.633333333333, "sharesPerSecond": 0.19056666666666666 }, "test4": { "hashrate": 1244.4666666666667, "sharesPerSecond": 0.09406666666666667 }, "test5": { "hashrate": 1682.6333333333334, "sharesPerSecond": 0.11276666666666668 }, "test6": { "hashrate": 1989.5, "sharesPerSecond": 0.1216 }, "test7": { "hashrate": 2358.4666666666667, "sharesPerSecond": 0.1331333333333333 }, "test8": { "hashrate": 2434.5333333333333, "sharesPerSecond": 0.12660000000000002 }, "test9": { "hashrate": 2159.3, "sharesPerSecond": 0.14190000000000003 } }

[oliverw]

Known problem. Needs to be fixed. Agreed.

[jon4hz]

And will it be fixed or do we just all agree that there's a problem? xD

[seperatis]

@jon4hz nobody is stopping you from solving it. Mining Core is open-source... finding a solution for the above issue would be a great way to get involved in this project. Just submit a PR if you get it working correctly. 😊

[Konstantin35]

I think this is not a problem everyone can change the time for themselves https://github.com/oliverw/miningcore/blob/master/src/Miningcore/Api/Controllers/PoolApiController.cs#L73 example: 10 minutes var from = clock.Now.AddMinutes(-10); 5 minutes var from = clock.Now.AddMinutes(-5);

[jon4hz]

I disagree. I think the problem is the following:

As far as I can tell, the "top miners" is supposed to show the highest hashrate a miner had in the last 24h hours. The way this value is gathered, is simply by fetching the raw hashrate of the miners per worker sum it up and return the top 15.

https://github.com/oliverw/miningcore/blob/8d4073394637a93e22bd39ef04e0cdc3ac45d531/src/Miningcore/Persistence/Postgres/Repositories/StatsRepository.cs#L317

However, when you're fetching the historical performance of a miner, miningcore makes samples of your average hashrate (1h avg by default if I'm not mistaken).

https://github.com/oliverw/miningcore/blob/8d4073394637a93e22bd39ef04e0cdc3ac45d531/src/Miningcore/Api/Controllers/PoolApiController.cs#L629 https://github.com/oliverw/miningcore/blob/8d4073394637a93e22bd39ef04e0cdc3ac45d531/src/Miningcore/Persistence/Postgres/Repositories/StatsRepository.cs#L254

This leads to a mismatch how the data is presented. For example if you have very high spikes in your hashrate, one of these spikes will be shown as "Top 24h" value but never appear in your historical hashrate, because getting averages there smooths it out.

If you change the value mentioned by @Konstantin35 you'd only change the time window but not the way the data is gathered. E.g. var from = clock.Now.AddMinutes(-10); would return the top 15 miners from the last 10 minutes.

A possible solution in my opinion would be to calculate the avg hashrate (time window tbh) first, and then return the highest values from these averages to smooth out spikes in your hashrate.

And now for the contributing part: @seperatis I very much appreciate that miningcore is open source but that doesn't mean that just anyone can contribute anything. For example my c# and sql skills are very much stopping me from implementing this myself in a timely manner. But I took some time to analyze the problem in more details instead of calling out people who simply wanted to know if @oliverw will address this issue in the near future.

[Konstantin35]

why 24 hours, I suggested changing the update time

[jon4hz]

It doesn't matter which time window you're setting to fetch the miners. As long as this endpoint doesn't use an average logic, it will never return the same data as /api/pools/{poolid}/miners/{miner}/performance. I agree, that changing the time window will update the top miners more frequently, but it wont calculate the same hashrate