Quote from: JCE-Miner on July 04, 2018, 09:02:54 PM

hello,

When i say the fees are included, that means the displayed hashrate is the same no matter if you're in a devfee session or not. This is the raw physical hashrate.
If you punch h, you lock the mining thread to force it to update the hashrate counter and display it on screen, so if you punch again and again, it will lower the hashrate, that's normal. This is the same for the CPU version. Better use the JSON http output which is updated in the network thread, and does not cause such a problem. From your browser, you can press F5 as much as you want. But not H from the console.

Effective hashrate should converge mathematicaly to lower than the average physical hashrate. Normaly by ~2% on a very long term.
If it's higher, so you had a good luck biasis. You can check that number two ways :
1. Look at your pool, you should get a similar hashrate (the computation range of the pool may be different from JCE, but on the long term, they should converge).
2. Get your total hashes and divide it by the uptime. You should get the same value. The hashes themselve can be checked against your pool history, or JCE log, and the uptime by... your wall clock

A difference can be explained by some instant peaks from your cards that make you mine faster but may not be reported by the blue instant hashrate, if you mine so fast that the 512 hashes are obsoleted fast. I admit that 512 was good for CPU, which can mine at 150h/s per core at best, but that's just half a second for a Vega. Average rate over half a second is too low. This is the problem. Good remark, i'll increase the time period for average of fast cards like Vega Wink

Version 0.30c online

Quote

Netcode fixes
Bittube v4

Thanks for the thorough reply. I will indeed use the JSON to monitor moving forward. I fully understand the way luck is involved and that a hashrate shown poolside based on shares found will need considerable time to converge with physical hashrate. I now see that you are simply multiplying shares found for the non-dev pool x difficulty value and that luck is included in this Effective Hashrate number.

I suspect that you are right about the possible spikes in physical h/s on Vegas causing confusion since the current sample size for physical averages is actually closer to .25 seconds!