Bitcoin Forum
November 10, 2024, 12:57:25 AM *
News: Latest Bitcoin Core release: 28.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: How pools calculate worker hashrates?  (Read 3019 times)
Dargo (OP)
Legendary
*
Offline Offline

Activity: 1820
Merit: 1000


View Profile
July 12, 2011, 05:16:27 PM
 #1


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!
gentakin
Member
**
Offline Offline

Activity: 98
Merit: 10


View Profile
July 12, 2011, 05:19:11 PM
 #2

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.

1HNjbHnpu7S3UUNMF6J9yWTD597LgtUCxb
Dargo (OP)
Legendary
*
Offline Offline

Activity: 1820
Merit: 1000


View Profile
July 12, 2011, 05:23:02 PM
 #3

Thanks - lol, maybe I should join bitcoinpool so I can pretend I have twice the hashing power!
phorensic
Hero Member
*****
Offline Offline

Activity: 630
Merit: 500



View Profile
July 13, 2011, 07:29:38 AM
 #4

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.
Graet
VIP
Legendary
*
Offline Offline

Activity: 980
Merit: 1001



View Profile WWW
July 13, 2011, 08:11:41 AM
 #5

+1
we do 10 minutely

| Ozcoin Pooled Mining Pty Ltd https://ozcoin.net Double Geometric Reward System https://lc.ozcoin.net for Litecoin mining DGM| https://crowncloud.net VPS and Dedicated Servers for the BTC community
EskimoBob
Legendary
*
Offline Offline

Activity: 910
Merit: 1000


Quality Printing Services by Federal Reserve Bank


View Profile
July 13, 2011, 09:49:20 AM
 #6

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. Smiley

 

While reading what I wrote, use the most friendliest and relaxing voice in your head.
BTW, Things in BTC bubble universes are getting ugly....
Dargo (OP)
Legendary
*
Offline Offline

Activity: 1820
Merit: 1000


View Profile
July 13, 2011, 08:06:58 PM
 #7

It's just looks cool on the webpage.

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.
fpgaminer
Hero Member
*****
Offline Offline

Activity: 560
Merit: 517



View Profile WWW
July 13, 2011, 10:00:19 PM
 #8

Quote
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.
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:

Code:
Estimated Hashrate in MHash/s = Total # of Shares * 4294.97 / Time in Seconds

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.

Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!