I'm also getting the "2012-02-26 02:31:41.256425 > raise ValueError('old share an hour after switch time') 2012-02-26 02:31:41.256481 > exceptions.ValueError: old share an hour after switch time" error message  This is normal. Some other people haven't upgraded P2Pool and are messing with the rest.. |
|
|
|
Hmm heading off to check log, I just noticed I am now constantly getting "2012-02-26 01:51:47.863969 Bitcoin connection lost. Reason: Connection was closed cleanly." and/or not cleanly. Often its non-cleanly once followed by cleanly twice. This is with my instance that is mining litecoins and no merged ming so there aren't three daemons its talking too it must be makign and breacking connections to litecoind over and over very fast or something but neither the litecoind nor the minerd outputs show any inidcation they thing anythign is wrong.
Hmm where does p2pool put its log? Offhand I don't see one in the current directory of the tasks running it nor in its own directory nor in /var/log ...
Have you updated P2Pool recently? Bitcoin/Litecoin changed their protocols on Feb 20. The log is in data/<NET>/log |
|
|
|
On P2Pool stales refer to shares which can't make it into the sharechain. Because the sharechain is 60 times faster than the Bitcoin chain many stales are common and expected. However, because the payout is PPLNS only your stale rate relative to other nodes is relevant; the absolute rate is not. Which is misleading. Stales don't affect your payout relative to other p2pool nodes (assuming everyone is equally well connected, which is actually not a good assumption), but they do affect the overall payout per unit of work crunched of p2pool vs. other pools. No, it isn't misleading. It doesn't affect the payout per unit of worked as compared to other pools because stale shares on P2Pool can still be valid block solutions. P2Pool's effective block solving ability is exactly equal to an equally sized normal pool. |
|
|
|
I am merged mining, BTC, NMC, IXC, I0C, DVC, GRP and CLC all at once.
I0coin has a much lower difficulty than IXCoin, yet I am seeing IXCoin blocks but no I0Coin blocks.
Does it actually submit the work to all the daemons it has enough difficulty for?
It should, though it hasn't been tested well. Can you check P2Pool's log for any mentions of "Merged block submittal"? |
|
|
|
been there done that. still no good im just cursed i guess
Is the machine running P2Pool overloaded or underprovisioned? Some people running it on Atom processors have reported higher miner rejection rates. |
|
|
|
anyone have any recommended settings for cgminer I have been getting a lot of rejects.. about 10% even at a low intensity.. tried dynamic and its still at 10% anyone got a magic number?
Are you using the latest version of CGminer? With no options (=dynamic, 2 gpu threads), I only get ~1% rejected. You are talking about the rejects that cgminer shows, right? |
|
|
|
I wasn't referring to the rejected field but the "DW" field which is discarded work. My reject rate is 0.9%.
The DW field increments every time cgminer shows a long poll but not an accept.
Ah, oops, thought you were talking about rejects.. Anyway, it isn't harmful. Mine is about 80%. |
|
|
|
What kind of discarded work rates are people getting with cgminer on p2pool?
I read that it's normal on p2pool to have a higher discarded work rate than on a traditional pool. I'm just trying to figure out how much is normal to see if I have problems or not.
My discarded work is about 1.5x the accepted.
That's definitely not normal. You should get at most 2% of shares rejected, as displayed in cgminer. If you're getting anything more, upgrade cgminer and decrease its intensity. |
|
|
|
P2Pool users: An upgrade is required in the next 24 hours in order to continue mining. There is a scheduled protocol change that breaks compatibility with older nodes, but adds support for raising your local difficulty and is more robust against DoS attacks. See https://bitcointalk.org/index.php?topic=18313.msg758574#msg758574 . Thanks! |
|
|
|
It stopped after a while, but it popped up every dozen seconds or so for several minutes while it was happening.
But, if bitcoind and p2pool had different ideas about which block they should be building on, that is a pretty big problem, is it not?
The problem was other users building on blocks that you didn't think were the right ones to build on, not any disagreement between your local daemons. There is no problem, except that the error shouldn't be displayed, or at least should be smaller with an explanation. |
|
|
|
I'm getting this using p2pool 0.9 (1bdeed1) and bitcoind 0.6rc1:
Constantly or just occasionally? Maybe you were on a Bitcoin block fork.. |
|
|
|
forrestv, are you considering acting on any of these ideas? What are you current thoughts on this?
I've though about it quite a bit  I plan to start a second P2Pool once P2Pool reaches about 400GH/s, because only then will we have enough power to make splitting into two okay. The upcoming protocol change lets new P2Pools safely be created. Any method of dynamically creating P2Pools runs the risk of hurting miners because a pool can't simply be terminated if the hash rate lowers, since the last day of shares that were mined won't be built on top of and won't get their fair reward. I intend to move towards the high-difficulty p2pool backbone idea eventually, but that will obviously require a lot of thought and changes. |
|
|
|
2012-02-20 17:44:44.173000 Bitcoin connection lost. Reason: Connection was closed cleanly.
2012-02-20 17:44:45.036000 Bitcoin connection lost. Reason: Connection was closed cleanly.
2012-02-20 17:44:45.943000 Bitcoin connection lost. Reason: Connection was closed cleanly.
2012-02-20 17:44:46.986000 Bitcoin connection lost. Reason: Connection was closed cleanly. Strange.. never seen that before. Check the date on your computer, maybe. If it's about a day behind, Bitcoin's Feb 20 protocol change could be causing this. |
|
|
|
Yes, my post is from after 0.9, I installed it last night right after the email went out. It has happened twice today, once when I saw all my shares go orphan and other time they didn't. How does something like this happen? Not that I claim to know much about how this all works but, to me, it doesn't seem like it should be possible that P2Pool gets confused, I get 10% of what my payout should be then I restart and it goes back to normal.. Where did the extra coins go?
Ah, sorry. I thought you meant in your first post that you hadn't seen the problem with 0.9 yet. Looking into it now. |
|
|
|
Having a Litecoin mining problem. Usually when a mined block comes in, I get little over 1LTC but a few times a day, the transaction randomly comes in at .3 or .2, something like that. About 50% of the time, I see that all my shares in P2Pool go instantly from normal to orphaned eg: 125 (8 orphan, 1 dead) to 125 (124 orphan, 1 dead) which drops my payout down to a fraction of what it should be. If I reset P2Pool, my shares go back to normal and resume normal payouts.
There was a fix for behavior this in the most recent release, 0.9. Litecoin's blocks are 4x as fast as Bitcoins, but P2Pool cached the last 1000 shares regardless of which blockchain you were mining on, and chose the wrong chain if the block headers from 24 hours ago weren't known. However, if you still have problems, please do tell me. I'm having problems with LTC p2pool mining too now after updating to latest version,for some reason when i start minerd my hashrate in cgminer plummets by about 50%.
This doesn't sound like it could be P2Pool's fault... Try Litecoin mining with less threads so cgminer has some cpu headroom? |
|
|
|
Unable to mine on the latest p2pool with ufasoft .28. No error message given, just sits at 0 KHash/second. Anyone else having a problem like that?
What was the last version of P2Pool that worked? |
|
|
|
... We performed 114% better than PPS pool, at least in last week(even with a 1day 7hours long block).  i.e. pool had something like +14% luck in that period. However it's missing some accuracy since you went from TimeA to TimeB not BlockA to BlockB There is extra time used to get the first block before 00:00:00 (which makes the total time for those block go up) and extra time wasted after the last block until 23:59:59 (which makes the total time for those blocks go down) Actually, I believe that measuring between two times is more accurate than two blocks. If you measure between two blocks, you're estimate is biased towards more luck. Look at the case of just one block - in 0 time, we got one block and therefore we have infinite hash power. If you look at any one second period, you'll usually get 0 H/s, sometimes some really large number, but never infinity. |
|
|
|
P2Pool release 0.9 - tag: 0.9 - UPDATE REQUIRED before Mar 4 for Bitcoin and Feb 26 for Litecoin Windows py2exe binary: http://u.forre.st/u/daowkjuo/p2pool_win32_462b252.zipSource tarball: https://github.com/forrestv/p2pool/tarball/0.9Source zip: https://github.com/forrestv/p2pool/zipball/0.9Changes: - Compatibility-breaking protocol change
- Let miners voluntarily raise their share difficulty so P2Pool's required difficulty can drop, which will lower variance for small miners
- Include SHA256 midstate in shares so that PoW can be verified in isolation, which enables future stronger DoS-proofing
- No longer allow payouts to go to any script. All payouts will go to pubkey hashes (as with normal transactions), which also reduces the size of shares slightly
- Fix for fork issue on Litecoin network only caused by recent period of fast blocks
Persistent note: I would recommend switching to Bitcoin 0.6.0 RC 1, which includes the RPC getblock call. The getblock call lets P2Pool keep track of block heights more robustly, and so might protect you from sharechain forks. Download it from https://bitcointalk.org/index.php?topic=63165.0
|
|
|
|
|
Show Posts
