|
Title: Throughput calculations? Post by: kingcoin on March 19, 2013, 04:01:48 PM How do the pools calculate your mining hash throughput?
Title: Re: Throughput calculations? Post by: Graet on March 19, 2013, 04:36:13 PM if you mean hashrate
most pools take an average of shares submitted over a time period to give miners an estimate of hashrate Ozcoin uses a rolling 5 minute period Title: Re: Throughput calculations? Post by: kingcoin on March 19, 2013, 05:02:19 PM if you mean hashrate most pools take an average of shares submitted over a time period to give miners an estimate of hashrate Yes. I mean hashrate. But how do they know how many hash calculations you did per second for a given submit? Do they assume that you got there by incrementing the nonce by one until you submitted? Title: Re: Throughput calculations? Post by: eleuthria on March 19, 2013, 05:17:04 PM BTC Guild's dashboard uses a growing averaging window. After shares have been submitted for about 1 minute, it will begin to estimate your hash rate. As more time is measured, it increases the amount of data used to guess more accurately, up to 1 full hour of share submissions. If a 10 minute gap is seen in your history, it will reset that estimate to only most recent submissions until there is no longer a gap.
EDIT: More detailed explanation. Pools in general use your share submissions to GUESS your hash rate. It is known that on average, it takes 4.2 billion hashes to create a difficulty 1 share. By dividing the number of shares you've submitted over a time frame, it can guess your approximate hash rate. The faster you hash, the more accurate this will be, because the pool has a more consistent set of data to work with. This is why very slow miners (CPUs/nVidia) rarely have an accurate estimate on any pool. If your share submissions are slow, it's difficult to get a good estimate due to the small sample size. Title: Re: Throughput calculations? Post by: Graet on March 19, 2013, 05:18:32 PM if you mean hashrate most pools take an average of shares submitted over a time period to give miners an estimate of hashrate Yes. I mean hashrate. But how do they know how many hash calculations you did per second for a given submit? Do they assume that you got there by incrementing the nonce by one until you submitted? all a pool can do is estimate a hashrate based on shares returned to the pool Title: Re: Throughput calculations? Post by: kingcoin on March 19, 2013, 05:45:48 PM It is known that on average, it takes 4.2 billion hashes to create a difficulty 1 share. That was the answer to my question. But how do you come up with that number? There are 4294967296 different nonce values (32-bit). If you iterate over all possible values your will find a hit every 2147483648 on the average, or roughly 2Ghash operations. Is this the assumption? Title: Re: Throughput calculations? Post by: eleuthria on March 19, 2013, 06:08:44 PM It is known that on average, it takes 4.2 billion hashes to create a difficulty 1 share. That was the answer to my question. But how do you come up with that number? There are 4294967296 different nonce values (32-bit). If you iterate over all possible values your will find a hit every 2147483648 on the average, or roughly 2Ghash operations. Is this the assumption? Think of it like rolling dice. Your odds of getting a 6 is 1 in 6. If you're only going to make 3 rolls, you have an ~50% chance to get a 6 in one of those rolls. However, if you were going to make 3,000 rolls, you're much more likely to be in the expected 16.67% of rolls actually being 6. Title: Re: Throughput calculations? Post by: kingcoin on March 19, 2013, 07:00:58 PM Think of it like rolling dice. Your odds of getting a 6 is 1 in 6. If you're only going to make 3 rolls, you have an ~50% chance to get a 6 in one of those rolls. However, if you were going to make 3,000 rolls, you're much more likely to be in the expected 16.67% of rolls actually being 6. But miner's aren't rolling a dice. They don't use a random function to guess the nonce (or do they?). They usually start counting from 0 up to 2^32 -1 in order not to check the same value multiple times. On the average they will find the nonce half way through the sequence. Title: Re: Throughput calculations? Post by: crazyates on March 19, 2013, 10:23:25 PM Think of it like rolling dice. Your odds of getting a 6 is 1 in 6. If you're only going to make 3 rolls, you have an ~50% chance to get a 6 in one of those rolls. However, if you were going to make 3,000 rolls, you're much more likely to be in the expected 16.67% of rolls actually being 6. But miner's aren't rolling a dice. They don't use a random function to guess the nonce (or do they?). They usually start counting from 0 up to 2^32 -1 in order not to check the same value multiple times. On the average they will find the nonce half way through the sequence. Title: Re: Throughput calculations? Post by: eleuthria on March 19, 2013, 10:31:35 PM Think of it like rolling dice. Your odds of getting a 6 is 1 in 6. If you're only going to make 3 rolls, you have an ~50% chance to get a 6 in one of those rolls. However, if you were going to make 3,000 rolls, you're much more likely to be in the expected 16.67% of rolls actually being 6. But miner's aren't rolling a dice. They don't use a random function to guess the nonce (or do they?). They usually start counting from 0 up to 2^32 -1 in order not to check the same value multiple times. On the average they will find the nonce half way through the sequence. Exactly as crazyates said. You're not guaranteed to find a share in a nonce range, so it's not like you can start at 0, count up, and when you find one, you know you found "the" nonce in the range and can start over. So it is like dice. Just because you rolled a 1 doesn't mean you won't roll it again before you get your 6. Title: Re: Throughput calculations? Post by: kingcoin on March 20, 2013, 12:33:14 AM You're not looking for a nonce. You're using the nonce to look for a share. Sometimes you can find 2 shares per nonce range. Sometimes it's zero. Ah. That explains it. Thanks! |