Alternative p2pool.info Suggestions:I'm working on getting this live this week. I plan to try and reproduce all the data from the original, and include some other stuff we are already storing. I've looked over the p2pool.info Azure code (not something I am familiar with) and have decided that it will be faster to write my own version on a LAMP stack as that is already the foundation of the Coin Cadence site.
As you might expect there are already some substantial differences between Coin Cadence and p2pool.info as to what and how p2pool data is stored and collected.
The biggest change/advantage of my version will be the fact that all data is gathered locally from p2pool and bitcoind compared with the current p2pool.info implementation which pulls block data from blockchain.info
I have a few questions for the community as a whole as to how to calculate and present some of the stats:
Estimated time to block: This is currently calculated on the fly by p2pool using the pool hash rate and "attempts_to_block" from:
http://mining.coincadence.com:9332/local_stats attempts_to_block=
parseInt(local_stats.attempts_to_block || 0);
time_to_block= attempts_to_block / pool_hash_rate;
$('#expected_time_to_block').text((''+time_to_block).formatSeconds());
The problem I see is when to store this value in the DB. The pool hash rate fluctuates pretty wildly even when miners are relatively consistent, this is a fact of life when trying to calculate the global rate of the distributed pool. Add the fact that miners are joining and leaving p2pool on a regular basis and it becomes even more complicated.
Should the expected time to block be stored immediately after or before a block is found? Should it be stored every x minutes and an average calculated on a per block basis? Very open to suggestions!
Pool Luck:Assuming we have decided on a satisfactory answer to storing the expected time to block above, this is pretty straight forward...
The question is how the luck stats are presented. In the current p2pool.info implementation luck is presented as a % over the last 7, 30 and 90 days.
I'm considering 2 alternatives:
1. Borrowing Slush's time frame and using 1, 7 and 30 days.
2. Basing it on blocks rather then time, i.e. current block luck, last 5 blocks, last 15 blocks, etc...
What do you think?
Estimated Hashrate:in current p2pool.info implementation:
The following users / addresses have submitted at least 1 valid share in the past 24 hours. Note: Hashrates are very rough estimates based on the number of shares submitted in the past day. They may be off by 10-20% or more due to variance.
This uses some fuzzy math that I don't fully understand. If anyone has a method of calculating this and can explain it to me I'd love to hear it....
Here is my proposed solution, and to be honest I'm not sure if it is better or worse then the current implementation, and am very open to suggestions:
Using data provided by p2pool here:
http://mining.coincadence.com:9332/current_payoutsRetrieve the following: current total block payout (including tx fees), payout per miner, global pool hashrate
Calculate miner % of total expected block payout.
Miner estimated hash rate = % of global pool speed based on % of expected payout??
So for example if a miner has 10% of the expected total payout, we can assume they have 10% of the global hash rate...
Again, fuzzy math at best and am open to suggestions....
SummaryI'd like feedback on my 3 suggested methods:
1. When to store estimated time to block (every x minutes and use average, just before or just after a block is found)
2. Calculating/Display format for pool luck
3. Estimating miner hash rates
Thanks!
Hey windpath,
You can always calculate the expected time to block. I'm not sure why they use the formula "attempts / rate". Expected time to block is based on the following:
Difficulty * 2**32 / hashrate / 86400 = number of days to find a block
As you can see, that value is going to fluctuate considerably based on hash rate. One minute it could be 1.2 days, and the next 0.5 days. This actually happened just a few days ago when one minute the pool reported about 500TH/s and the next it reported just over 1PH/s.
I guess what I'm stating is that the best you can hope for providing is an "average" value. Collect expected time to block values every X units of time. You can't just use either just before, or just after the block is found.
This will impact your luck calculations as well. The constant in that equation is the time between blocks. Since they are timestamped, you know exactly how long it took. Then, depending on how many "expected time to block" values you've recorded, you can make an educated guess on the luck. By the way, you'd have to start your stats collection immediately after p2pool finds a block for the most "accurate" calculations.
The reason the other calculations are so far off is because they are all based on submitted shares. That's your "fuzzy math". Your miners know their own hashing rate. Why? Because every single work unit is considered. The pool does not, because not every work unit is considered. It's an estimate based upon how much work of a given value is submitted. Therefore, while extremely unlikely, it is entirely possible that a miner with 1GH/s submits 100 shares in a minute. The pool would report that miner having a substantially higher hash rate that it actually does because of it.
Unfortunately, that's what we're stuck with. Using a variation of the formula I gave above, you can estimate the miner's hash rate, since you know all of the other variables. Let's use my example of the miner submitting 100 shares in a minute. For simplicity's sake, we're going to make the assumption that those 100 shares were all that were submitted in a 24 hour period.
100 shares in 24 hours = 864 seconds to find a share.
Current share difficulty = 1508968.56
1508968.56 * 2**32 / hashrate = 864
hashrate = 7501123398023.39555555555556 hashes per second = 7.5TH/s
So, the miner is actually a 1GH/s unit, but p2pool thinks it's 7.5TH/s. Obviously, this is a contrived example to display the effect of a miner not falling within expected parameters. However, looking at the expected payouts, you would think this miner is in reality 7.5TH/s.
Alright, I've rambled on long enough and should probably get back to work
Ah, well. Maybe I'll qualify next time. 