Topic: How pools calculate worker hashrates? (Read 3022 times)

Your best bet is to average it over a very long period of time (3 hours and up) and graph it. Graphing it will show fluctuations very easily, so you can eyeball what your average is, and the standard deviation. You can do this by logging the output of your client to a text file, which, depending on your mining software, should output timestamps, accepted shares, and rejected shares. From there you can filter out everything except the lines with accepted or rejected shares, parse it into a spreadsheet, and use your spreadsheet to generate a graph. I would include rejected shares in the estimated hashrate calculations, because they are still work performed by your miner. You can look at them on a separate graph to determine if certain configurations are giving you higher rejection rates.

If you don't know the math, simply determine how long you ran your miner for and count up the number of shares (both accepted and rejected) and:


To make a graph you'd have to do a moving average type calculation.

If you are overclocking your card or trying experimental kernels, and you are concerned that your graphics card is making mistakes, I know that at least poclbm verifies shares produced by the GPU prior to submitting them to the pool, and will report an error if it finds one. So, with logging to a file you can easily search for "Verification failed, check hardware!" to see how many times your GPU made a mistake.

Yep. I don't even take the hash rate on my end too seriously past a certain point. For my card that is most amenable to tweaking, I've noticed that trying to press the hashrate past a certain point chokes my share submission rate a bit, so the card pays better at slightly lower hashrate. I haven't done enough testing, though, to be certain that there is a genuine pattern here as opposed to mere variance. But I am trying to tweak my cards for submission rate rather than just trying to max out my hash rate.

accepted at 11%
...
accepted at  2%
...
accepted at  4% 

etc are probably the cause for faster rate at the pools web page.

At 317M I see it varies about 2-4% so we must be doing something right.

 

+1
we do 10 minutely

The hashrate you see on your pool website is purely and estimate and can be a wild shot in the dark compared to what your mining program shows.  Our pool takes an average from the last 5 minutes, but it's always lower than what I show in my mining program.  There is honestly no way to make it accurate or match what your mining program shows.  It's just looks cool on the webpage.

Thanks - lol, maybe I should join bitcoinpool so I can pretend I have twice the hashing power!

You are right. For every share submitted, pools assume that 2^32 hashes have been calculated to find the share. (This is correct on average.)

Unless you are using bitcoinpool.com, they somehow got the calculations wrong and show a hashrate that is about 2 times of what you actually have.

I think I already answered this question for myself with a forum search, but want to verify:

Do most/all pools calculate reported hashrates for an individual worker by looking at the shares submitted by that worker over some fixed time span and using some kind algorithm to estimate the hashrate of the worker?

I've noticed quite a bit of variance between the hashrate I'm seeing on my end compared to the hashrate stats reported by pools. Earlier this morning, I logged into my pool, and one worker was listed at 444 Mh/s (while I was seeing about 370 on my end), and the other worker was listed at 272 Mh/s (while seeing about 340 on my end). So at that time there was about a 70 Mh/s variance for each worker! I assume all this means is that one worker was very lucky while the other was very unlucky over whatever time span the pool uses to estimate hash rates (I think for the pool in question the time span is pretty short).

I would appreciate it if someone could let me know if I am right/wrong in my understanding of what lies behind this variance. Thanks!