I think there's something wrong with the p2Pool 7 day stats. If you calculate manually, the last 7 days is better than average luck. In fact, there's been better than average luck at p2Pool for the last 6 weeks now. Check the last 7 days for yourself: Timestamp ActualShares ExpectedShares
1 1344745354.000000 547055.000000 2036671.000000
2 1344740792.000000 9116832.000000 2036671.000000
3 1344649552.000000 134207.000000 2036671.000000
4 1344648269.000000 2121584.000000 2036671.000000
5 1344627801.000000 3184026.000000 2036671.000000
6 1344596756.000000 7983068.000000 2036671.000000
7 1344487657.000000 3886934.000000 2036671.000000
8 1344430970.000000 839057.000000 2036671.000000
9 1344418762.000000 1225598.000000 2036671.000000
10 1344401496.000000 814265.000000 2036671.000000
11 1344389344.000000 395892.000000 2036671.000000
12 1344383399.000000 2019198.000000 2036671.000000
13 1344353201.000000 279105.000000 2036671.000000
14 1344349060.000000 1526951.000000 2036671.000000
15 1344325803.000000 644660.000000 2036671.000000
16 1344315777.000000 35732.000000 2036671.000000
17 1344315245.000000 271678.000000 2036671.000000
18 1344311286.000000 1395283.000000 2036671.000000
19 1344289928.000000 1986950.000000 2036671.000000
20 1344258323.000000 152132.000000 2036671.000000
21 1344256008.000000 815393.000000 2036671.000000
22 1344243762.000000 1675975.000000 2036671.000000 The average round length / difficulty = 0.91. This is better than average. You didn't include this very long block in your calculation (and p2pool.info did): 23 1344216828.000000 11306170.000000 2036671.000000
Probably you and p2pool.info just used a different definitions of "last 7 days". p2pool.info includes rounds based on their end time (the timestamp of when the block was found). So, the 7 day luck calculation include all blocks that were found in the 604,800 seconds (7 days) since the most recent block was found (not since "now"). At the time of your post, the most recent block had been found at 1344745354. So the cuttoff was 1344745354 - 604800 = 1344140554, which means that the long block found at 1344216828 was included in the 7 day range. |
|
|
|
Aren't there other public nodes?
Yes Also, would changing the difficulty from p2pool help?
No. The issue is the frequency of LPs. The pseudo share difficulty and the share difficulty (i.e. when people with lots of hash power volunteer for higher difficulty shares) is irrelevant since all that matters is that LPs come every 10 seconds and so BFL Singles will spend a significant amount of time working on stale work. |
|
|
|
So ... nothing you can do about it ... don't mine on p2pool with BFL Singles or MiniRigs
(MiniRigs only lose ~half as much work since they are a bit less than 2 times as fast per card vs a Single)
My understanding is that BFL added the ability to tell a MiniRig to search less than the entire nonce range (and so you can dramatically reduce stales), so it should be possible to use it on p2pool if you have a miner that implements that feature. The assumption is that the Single SCs will also have that firmware feature when they come out. So in theory it is just the normal Singles that are unusable. |
|
|
|
You could use a javascript timer to browse away from the login page to a "session expired" page just before the csrf_token expires.
good idea, thanks... wasn't sure yet what to do about it but that would work. Or just use the same javascript timer to refresh the page. |
|
|
|
Your getting .33 a block on a 560 ti? The hardware charts say that card only does ~80 mhz
are you sure your not getting .033?
I'm getting ~.20 -.30 per block on 1200 mh\s or 1.2 Gh\s
He may have had an extremely lucky streak of shares. I only average 0.1 BTC per block with ~580 MH/s. It's probably a typo and really is 0.033. If you look at his screenshot, he is currently at 0.0221. |
|
|
|
I have had an annoying hardware failure of one of the machines that provides data for p2pool.info behind the scenes. Until I can rebuild this machine, it means p2pool.info may be intermittently out of action or inaccurate.
Your not the only one to have a hardware failure related to p2pool. My hardware issue had nothing to do with p2pool. The motherboard and/or CPU of the host machine for my home web server's VM died. I haven't bothered to diagnose which failed--I just built a new host computer and moved the VM there. This was a Windows Server 2008 R2 virtual machine that runs the web server and SQL server I use at home for managing my farm of mining rigs. It was also a convenient machine to run my internal caching DNS server on which meant when it died, none of my computers could resolve hostnames anymore. That is why p2pool.info was slightly affected (my p2pool nodes could not communicate to p2pool.info to send it data because they couldn't resolve the hostname). Neither p2pool nor bitcoin were running on this machine and could not have been associated with the hardware failure, so you'll have to look elsewhere for your conspiracy theories. The fact that p2pool.info is experiencing an issue, makes it difficult to prove how profitable p2pool is compared to other pools. How convenient.
I knew there was a reason I ignored you. I should have trusted my instinct and not unignored you to see what you were asking. Fixed. |
|
|
|
I have had an annoying hardware failure of one of the machines that provides data for p2pool.info behind the scenes. Until I can rebuild this machine, it means p2pool.info may be intermittently out of action or inaccurate.
It's fixed. And no comment...  |
|
|
|
|
I have had an annoying hardware failure of one of the machines that provides data for p2pool.info behind the scenes. Until I can rebuild this machine, it means p2pool.info may be intermittently out of action or inaccurate.
|
|
|
|
Some changes have been made to p2pool.info to slightly improve the performance of the page load: - The hashrate graph and the stats API (http://p2pool.info/stats) only include one data point per hour instead of one per 5 minutes. If someone needs/wants the 5 minute data, it still exists in the database (and still gets used behind the scenes), they can contact me and we'll work something out.
- The block list only shows blocks for the past 90 days. If you want to see blocks older than that, you'll need to use the API (see the next point)
- The blocks API (http://p2pool.info/blocks) also only returns the last 90 days of blocks by default, but you can get all blocks by adding a parameter to the request: http://p2pool.info/blocks?all=true
|
|
|
|
Yes, i'm running 24/7.
p2pool tells me my hash rate is much lower then my actual mining speed (about 60%) and whenever my miner finds a new share it's not added to the p2pool count.
I recently started it and my miner tells me i found 50 shares (all accepted), p2pool says 15?
very confused...
What does this line say from the p2pool console? Local: 1639MH/s in last 10.0 minutes Local dead on arrival: ~0.9% (0-4%) Expected time to share: 24.4 minutes It should be very close to what your actual hashrate is as it is based on diff 1 shares which have reasonably low variance. Let us know what the reported hashrate is along with the local dead on arrival rate. |
|
|
|
I was wondering how this page calculates the performance of finding blocks (7 days, 30 days, 90 days). Is it based upon when the block is found, or the average for the block?
Pool hashrate is sampled every 5 minutes, and the luck estimate/calculation uses the average of those samples over the duration of the round. The fact that pool hashrate is sampled every 5 minutes is actually the reason the page loads so slowly (there are a zillion 5 minute data points between now and last february when I started collecting 5 minute samples). The 5 minute sample are useful for the luck calculation, but the graph doesn't really need to be that precise so I will be changing JSON API to return fewer data points to the graph which will cut down the time for the page to load (block luck calculations happen on the server and will still use the 5 minute samples). Yes but hash rate is an estimate ... Really it should keep the history of shares and use that - which is accurate. Shares is the only accurate measurement of a pool. I agree completely that in a perfect world that would be better. I just don't care about the difference enough to invest my free time to make the substantial changes required to make that work. If someone else wants to do it and provide me a JSON feed of p2pool blocks along with the actual number of diff 1 shares that went into that block, I'm happy to replace the current hashrate based estimates. |
|
|
|
I was wondering how this page calculates the performance of finding blocks (7 days, 30 days, 90 days). Is it based upon when the block is found, or the average for the block?
Pool hashrate is sampled every 5 minutes, and the luck estimate/calculation uses the average of those samples over the duration of the round. The fact that pool hashrate is sampled every 5 minutes is actually the reason the page loads so slowly (there are a zillion 5 minute data points between now and last february when I started collecting 5 minute samples). The 5 minute sample are useful for the luck calculation, but the graph doesn't really need to be that precise so I will be changing JSON API to return fewer data points to the graph which will cut down the time for the page to load (block luck calculations happen on the server and will still use the 5 minute samples). |
|
|
|
On a different note, the stats webpage will not load for me today from any comp I have. Does anyone know what's up?
Temporary fix is in place. A better fix in the works that should also improve performance. |
|
|
|
Can I invest as little as 1 btc or is 10 btc the minimum?
F.A.Q.
Q. What is the minimum deposit amount?
A. To open an account, you must send at least 10 BTC for your first deposit. After that, subsequent deposits can be any amount.
|
|
|
|
If you submit a pseudo share (i.e. a diff 1 share) and it doesn't meet the requirements of the current share difficulty, it is just not a share. It's not orphaned or DOA just because it doesn't meet the difficulty. This is common as most shares that the miner submits meet the diff 1 requirements but not the diff 800 requirements.
I follow - I was assuming the miner would be mining at the appropriate difficulty and only sending shares that met it. But if you're sending D1 shares which then may be rejected if they don't meet diff 800, then this isn't an issue. Thanks for the explanation, twmz. Yes, p2pool "lies" to the miner and tells it to look for diff 1 shares. This was done for multiple reasons. It helps verify the miner is working more quickly because shares are found 800 times faster. It allows p2pool to estimate hashrate of local miners more accurately. Also, some miners choke on shares that are higher than diff 1 and so this is also done to be as compatible with existing miners as possible. |
|
|
|
How dynamic is the difficulty? How often does it change?
If it changes often and this causes orphaned shares, what would the downside of changing it less frequently be?
If, when you started looking for a share the difficulty was 800 and you find a share that is valid for difficulty <= 800, the only way that that wouldn't be valid is if someone else found a share in between when you started looking and when you found a share (which is the only time the difficulty changes). If you start looking for a solution at difficulty, but by the time you submit it the difficulty is 900 and your solution is too large for the retarget, it will get rejected - is that DOA or orphaned? Not sure. Either way, if difficulty changes too often then when it increase you'd expect to have an increase in submitted shares that do not solve the current difficulty. Or is the LP mechanism fast enough to prevent this? If you submit a pseudo share (i.e. a diff 1 share) and it doesn't meet the requirements of the current share difficulty, it is just not a share. It's not orphaned or DOA just because it doesn't meet the difficulty. This is common as most shares that the miner submits meet the diff 1 requirements but not the diff 800 requirements. Now, if a pseudo share comes in that builds off of share X, but share X+1 has arrived at the node in the mean time, then that is a DOA pseudo share, regardless of if it meets the difficulty requirements. If it happens to meet the difficulty requirements it will be counted in the "dead shares" statistics. Since share difficulty only changes in response to new shares being added to the share chain, the only way difficulty could change while your pseudo share was "in flight" would be if a new share had been added to the sharechain. In that case, your pseudo share is DOA no matter what because it isn't building off the head of the sharechain. Again, difficulty change or not, it's DOA, so I don't think the difficulty change rate matters. |
|
|
|
How dynamic is the difficulty? How often does it change?
If it changes often and this causes orphaned shares, what would the downside of changing it less frequently be?
I don't know if it changes every share or every few shares, but I'm not sure how the frequency of difficulty changes, alone is causing extra DOA/orphaned shares. If, when you started looking for a share the difficulty was 800 and you find a share that is valid for difficulty <= 800, the only way that that wouldn't be valid is if someone else found a share in between when you started looking and when you found a share (which is the only time the difficulty changes). But if that happens, then your share is DOA anyway because your share doesn't build off the most recent share (which arrived at your node and changed the difficulty). Maybe I am missing something, though? |
|
|
|
Outdated clients/nodes/miners:
...
Check your P2pool software and update it!
Sadly, people running outdated clients are almost certainly not reading this thread. Pretty much the only way to get their attention is to force an upgrade (i.e. fork them so that they stop getting paid regularly). |
|
|
|
Fixing it now. I had a power failure and when the computers restarted, the wrong version of bitcoind started up which caused problems with the p2pool.info block detection code. I no longer see the blocks as rejected.  Did the luck chart get re-calculated? The luck chart is calculated from raw data on your own browser every time you look at it. Also, luck calculations are not affected by orphaned blocks (orphaned blocks still count as found blocks from a pure probability perspective and so are counted the same as a non-orphaned block), so it doesn't matter in this case. |
|
|
|
|
Show Posts
