Topic: Estimating worker hashrate for scrypt using submitted shares (vardiff) (Read 902 times)
January 14, 2014, 01:50:22 AM
To calculate the hashrate for Scrypt, use what you would for Bitcoin but do 2^16 instead of 2^32. Something related to 'target bits' and I haven't fully looked into it but the numbers I get back are reasonably accurate. Certain pool front-ends also use this math for their calculations.
January 06, 2014, 09:27:28 AM
I'm using stratum-mining to run a stratum server for various coins and I'm trying to put a basic frontend on it to show things such as est. hashrate for workers. I'm using vardiff.
For SHA256 coins this is easy, as the 'shares' table has a 'difficulty' column and all I need to do is grab all the shares for a given period, sum the difficulty and multiply by 2^32 and divide by the number of seconds.
For Scrypt this doesn't work as the numbers that come out aren't right (unless I have radeons that have magically started working at 2.5Gh/s - I wish!) so obviously share difficulty means something else here. The numbers certainly look different -- for SHA256 they're something like 16, 32, 128, etc... - for scrypt they're floating point numbers like 1.32501.
What method should I use to estimate worker hashrate given these numbers?
For SHA256 coins this is easy, as the 'shares' table has a 'difficulty' column and all I need to do is grab all the shares for a given period, sum the difficulty and multiply by 2^32 and divide by the number of seconds.
For Scrypt this doesn't work as the numbers that come out aren't right (unless I have radeons that have magically started working at 2.5Gh/s - I wish!) so obviously share difficulty means something else here. The numbers certainly look different -- for SHA256 they're something like 16, 32, 128, etc... - for scrypt they're floating point numbers like 1.32501.
What method should I use to estimate worker hashrate given these numbers?
Jump to: