I started getting a bunch of twisted errors today from the p2pool client. I have the latest p2pool, cgminer and bitcoind.
Everything has been running fine for a week and I just noticed this today.
It seems like the bitcoin client itself is unhappy. I'm using bitcoin 0.6.0rc2 which is the latest AFAIK. It reports the error "WARNING: Displayed transactions may not be correct! You may need to upgrade, or other nodes may need to upgrade."
Topic: [1500 TH] p2pool: Decentralized, DoS-resistant, Hop-Proof pool - page 755. (Read 2591916 times)
March 07, 2012, 06:56:51 PM
March 07, 2012, 06:56:17 PM
P2Pool's hash rate has dropped lower than it has been in weeks; This may be due to people using Bitcoin 6.0 RC 1 and needing to upgrade to RC 2 due to changes in the P2SH taking-effect date. Please upgrade to RC 2 at https://bitcointalksearch.org/topic/version-06-release-candidate-1-63165 .
If you haven't upgraded, all of your P2Pool shares will be orphaned and you'll see "WARNING: Displayed transactions may not be correct! You may need to upgrade, or other nodes may need to upgrade." in bitcoind's logs or the GUI.
If you haven't upgraded, all of your P2Pool shares will be orphaned and you'll see "WARNING: Displayed transactions may not be correct! You may need to upgrade, or other nodes may need to upgrade." in bitcoind's logs or the GUI.
March 07, 2012, 06:50:03 PM
Anyone know where it is documented what the structure and content of a share is in the share chain?
(i.e. technical details of the first paragraph of the wiki)
The Wiki https://en.bitcoin.it/wiki/P2Pool isn't very good for technical details
(and not up to date - e.g. Donation section is still wrong and it still tries to convince people to be happy with stales)
Anyone know if there are any technical documents around about p2pool?
(i.e. technical details of the first paragraph of the wiki)
The Wiki https://en.bitcoin.it/wiki/P2Pool isn't very good for technical details
(and not up to date - e.g. Donation section is still wrong and it still tries to convince people to be happy with stales)
Anyone know if there are any technical documents around about p2pool?
There aren't any technical documents, but the share explorer (http://forre.st:9332/web/explorer) shows the complete content of shares and https://github.com/forrestv/p2pool/blob/master/p2pool/data.py#L29 has the structure descriptions.
I updated the donation URLs (thanks for pointing that out), but I don't see what you mean about it trying to convince people to be happy with stales... It explains why you'll get more stales than other pools and gives lots of advice for reducing them.
March 07, 2012, 06:43:48 PM
Anyone know where it is documented what the structure and content of a share is in the share chain?
(i.e. technical details of the first paragraph of the wiki)
The Wiki https://en.bitcoin.it/wiki/P2Pool isn't very good for technical details
(and not up to date - e.g. Donation section is still wrong and it still tries to convince people to be happy with stales)
Anyone know if there are any technical documents around about p2pool?
(i.e. technical details of the first paragraph of the wiki)
The Wiki https://en.bitcoin.it/wiki/P2Pool isn't very good for technical details
(and not up to date - e.g. Donation section is still wrong and it still tries to convince people to be happy with stales)
Anyone know if there are any technical documents around about p2pool?
March 07, 2012, 05:51:43 PM
Another block by me, 6 blocks in 3 weeks 
. May be I should start solo mining 
. Hey Forrestv, I suggest to increase the block founder reward to 1% or at least more than current 0.5%.
2012-03-07 22:36:47.174757 GOT BLOCK FROM MINER! Passing to bitcoind! http://blockexplorer.com/block/00000000000004965dc029339e48d8c5c1c44e2d5b47fd24705809a13634a2f9
. May be I should start solo mining . Hey Forrestv, I suggest to increase the block founder reward to 1% or at least more than current 0.5%.Quote
2012-03-07 22:36:47.174757 GOT BLOCK FROM MINER! Passing to bitcoind! http://blockexplorer.com/block/00000000000004965dc029339e48d8c5c1c44e2d5b47fd24705809a13634a2f9
March 07, 2012, 05:09:12 PM
Hello Wachtwoord, I was using the one day window as an example, I've been observing this for over a week now, restarting p2pool and sometimes bitcoind when it zombies out. I should have mentioned that bit before, I've got bitcoind 0.6rc2 running on a separate machine where it has enough ram and disk yet a slower processor. I have observed p2pool reporting that bitcoind is not responding for some number of minutes and I have to kill -9 bitcoind and restart. This happens some of the time and often self-corrects (i.e. p2pool eventually reconnects with bitcoind).
p2pool and bitcoin need to be responsive. As in sub second latency. If they aren't you will never get good stales. Remember they work together to form the "getwork engine". If they are non-responsive then your miners are working on old worthless crap.
You aren't trying to run p2pool & bitcoind on a mining rig off a USB drive running BAMT are you? That is a recipe for disaster.
If you are having to kill the processes then something is horribly wrong. It would be no different than mining on a conventional pool where the pool periodically goes unresponsive and the pool admin has to manually kill the back end and restart it. Do you think your stale rate will be low at that conventional pool?
March 07, 2012, 05:04:48 PM
I had a question about staleness and efficiency. I've been mining here a while with about 3.8GH/s and I have noticed that when I start my miners on a fresh instance of p2pool/bitcoind, the stale rate starts at 0% and will climb as high as 20% over the course of a day...additionally the efficiency number will start at 112% or so and trail down to the low 90's sometimes over the same timeframe. From what I have read here, 10% is the stale target for my instance and the p2pool as well (though it's a bit higher for some reason today) and around 100% efficiency is the target where my instance should hover as well (which might explain my 20% drop in BTC payout vs. traditional pool better than variance).
I'm using the git pull on the 5th or 6th for p2pool and 0.6rc2 for bitcoind on linux. BAMT 0.5 with cgminer 2.2.7. I've got threads set to 1 on all miners and intensity seems to run well at 7.
Anything I'm overlooking?
I'm using the git pull on the 5th or 6th for p2pool and 0.6rc2 for bitcoind on linux. BAMT 0.5 with cgminer 2.2.7. I've got threads set to 1 on all miners and intensity seems to run well at 7.
Anything I'm overlooking?
Not sure why your stales are so high. First thing it always starts at 0% that is pretty much meaningless. It spiking to 112% in a short period of time is equally meaningless. When you have a small number of shares the "luck" of a single stale can affect that stat by a lot. Say hypothetically you have 10 shares w/ 1 stale (10% stale or ~100% efficiency) The 11th share is coming in. If it is stale your efficiency will drop to 91% if it is valid then your efficiency will rise to 102%. What matters if the value after some time (say 12 to 24 hours @ 3 GH/s). Once you have hundreds of shares the value of each one is less material and the number will stabilize.
Yes if you have <90% efficiency you will be getting paid <90% of expected value. You want efficiency at 100% or very close.
A couple of ideas:
1) Use latest version of cgminer. 2.2.7 may be fine but some versions are less p2pool friendly.
2) Are your stales mostly dead or orphaned? Some dead is unavoidable (similar to any other pool) but a high dead may indicate you are pushing the cards too hard and causing invalid hashes.
3) Make sure your system running bitcoind & p2pool isn't overloaded. Preferably this would be a non-mining system which is mostly idle. bitcoind & p2pool use some memory and their operations are very latency sensitive. If they are slow to issue LP you are going to have excessive stales.
4) Make sure p2pool and bitcoind have a high number of connections (this means port forwarding)
5) Make sure your internet connection is solid w/ low latency and good uptime.
As a test try using public p2pool node and see if your stale rates improve. If it does then it is something in your internet, LAN, p2pool machine which is being inefficient. If it doesn't improve then the issue lies with the miner.
March 07, 2012, 04:57:54 PM
Hello Wachtwoord, I was using the one day window as an example, I've been observing this for over a week now, restarting p2pool and sometimes bitcoind when it zombies out. I should have mentioned that bit before, I've got bitcoind 0.6rc2 running on a separate machine where it has enough ram and disk yet a slower processor. I have observed p2pool reporting that bitcoind is not responding for some number of minutes and I have to kill -9 bitcoind and restart. This happens some of the time and often self-corrects (i.e. p2pool eventually reconnects with bitcoind).
P2Pool's wiki page has some suggestions for increasing your efficiency: https://en.bitcoin.it/wiki/P2Pool#Frequently_Asked_Questions
EDIT: Any idea what's going wrong with bitcoind? If bitcoind is dead and you continue to mine, you'll get orphans because your shares aren't up-to-date (any block solutions would be invalid).
March 07, 2012, 03:46:59 PM
It is because of my low hashing power. If you have a sufficiently high hashing frequency you will get a portion of every donation. For loower frequencies it is supposed to be a chance function. Forrest showed me in this thread. So either I'm unlucky or the function is broken.
Here is the post
Do you see your address in the output of: http://forre.st:9332/patron_sendmany?total=1
How about in the output of: http://forre.st:9332/patron_sendmany?total=10000
If you address is in the second one but not the first one, then I believe that is because of the small miner lottery.
In order to prevent lots of tiny payments, the donation code takes all the people who would have received only a very small donation payment, adds up all those payments, and awards the entire amount to one of those small miners randomly.
"Small Miner" depends on the size of the donation. If someone is donating 1 BTC at a time and the pool hashrate is 200GH/s, and the small payment cutoff is 0.01, then you have to have approx 2GH/s to not fall into the "small miner" bucket. If someone donates 10 BTC in one fell swoop, then you only need to have 200 MH/s in order to be above the 0.01 payment cutoff.
P.S. The default cutoff is 0.01, but people doing donation can choose a different one by adding it to the URL with a '/'. For example, here is a 1 BTC donation with a 0.001 cutoff instead:
http://forre.st:9332/patron_sendmany?total=1/0.001
But the function no longer seems to work
Here is the post
Okay, then how come I didn't receive any? (see previous link for the address I use to mine)
Do you see your address in the output of: http://forre.st:9332/patron_sendmany?total=1
How about in the output of: http://forre.st:9332/patron_sendmany?total=10000
If you address is in the second one but not the first one, then I believe that is because of the small miner lottery.
In order to prevent lots of tiny payments, the donation code takes all the people who would have received only a very small donation payment, adds up all those payments, and awards the entire amount to one of those small miners randomly.
"Small Miner" depends on the size of the donation. If someone is donating 1 BTC at a time and the pool hashrate is 200GH/s, and the small payment cutoff is 0.01, then you have to have approx 2GH/s to not fall into the "small miner" bucket. If someone donates 10 BTC in one fell swoop, then you only need to have 200 MH/s in order to be above the 0.01 payment cutoff.
P.S. The default cutoff is 0.01, but people doing donation can choose a different one by adding it to the URL with a '/'. For example, here is a 1 BTC donation with a 0.001 cutoff instead:
http://forre.st:9332/patron_sendmany?total=1/0.001
But the function no longer seems to work
The URL format was changed. It was in this thread a couple of times, but tends to get lost in the flow.
Try this: http://forre.st:9332/patron_sendmany/1/0.001
March 07, 2012, 03:37:43 PM
It is because of my low hashing power. If you have a sufficiently high hashing frequency you will get a portion of every donation. For loower frequencies it is supposed to be a chance function. Forrest showed me in this thread. So either I'm unlucky or the function is broken.
Here is the post
Do you see your address in the output of: http://forre.st:9332/patron_sendmany?total=1
How about in the output of: http://forre.st:9332/patron_sendmany?total=10000
If you address is in the second one but not the first one, then I believe that is because of the small miner lottery.
In order to prevent lots of tiny payments, the donation code takes all the people who would have received only a very small donation payment, adds up all those payments, and awards the entire amount to one of those small miners randomly.
"Small Miner" depends on the size of the donation. If someone is donating 1 BTC at a time and the pool hashrate is 200GH/s, and the small payment cutoff is 0.01, then you have to have approx 2GH/s to not fall into the "small miner" bucket. If someone donates 10 BTC in one fell swoop, then you only need to have 200 MH/s in order to be above the 0.01 payment cutoff.
P.S. The default cutoff is 0.01, but people doing donation can choose a different one by adding it to the URL with a '/'. For example, here is a 1 BTC donation with a 0.001 cutoff instead:
http://forre.st:9332/patron_sendmany?total=1/0.001
But the function no longer seems to work
Here is the post
Okay, then how come I didn't receive any? (see previous link for the address I use to mine)
Do you see your address in the output of: http://forre.st:9332/patron_sendmany?total=1
How about in the output of: http://forre.st:9332/patron_sendmany?total=10000
If you address is in the second one but not the first one, then I believe that is because of the small miner lottery.
In order to prevent lots of tiny payments, the donation code takes all the people who would have received only a very small donation payment, adds up all those payments, and awards the entire amount to one of those small miners randomly.
"Small Miner" depends on the size of the donation. If someone is donating 1 BTC at a time and the pool hashrate is 200GH/s, and the small payment cutoff is 0.01, then you have to have approx 2GH/s to not fall into the "small miner" bucket. If someone donates 10 BTC in one fell swoop, then you only need to have 200 MH/s in order to be above the 0.01 payment cutoff.
P.S. The default cutoff is 0.01, but people doing donation can choose a different one by adding it to the URL with a '/'. For example, here is a 1 BTC donation with a 0.001 cutoff instead:
http://forre.st:9332/patron_sendmany?total=1/0.001
But the function no longer seems to work
March 07, 2012, 03:23:06 PM
I was thinking it would be cool if p2pool.info listed how much has been donated as subsidies. Maybe that could be added into the luck calculation, too.
That is a good idea. Maybe a separate item.
Just thinking about how I would detect these... I could look for sendmany transactions that have known addresses in them. Maybe the donation address is enough?
To incorporate these into the luck numbers is a little more tricky. Right now luck is not measuring amount of BTC earned (vs expected), but is measuring things based on hashes. I'd have to change it to be based on BTC or I'd have to translate subsidies into "hash equivalents". I'll think about it more after I look at finding a way to identify subsidy payments in the first place.
Yes please separate it because I have been mining since 30th of January with 252Mhz and still have not received any donation. I might just be really unlucky, but in my mind I've written off the donation aspect in my reasoning to move to/stay at p2pool. So I'd like the data in isolation
that stinks bud. i started at the beginning of march and received a donation the first day
March 07, 2012, 03:21:22 PM
Okay if this is the case you can ignore my previous posts. I think your still rate is indeed higher than average but I am not sure about this even and also don't know how3 to help resolve it.
March 07, 2012, 03:11:33 PM
Variance? He only mines for 1 day (though at a high hash rate) so it might take longer for the numbers to converge.
Hello Wachtwoord, I was using the one day window as an example, I've been observing this for over a week now, restarting p2pool and sometimes bitcoind when it zombies out. I should have mentioned that bit before, I've got bitcoind 0.6rc2 running on a separate machine where it has enough ram and disk yet a slower processor. I have observed p2pool reporting that bitcoind is not responding for some number of minutes and I have to kill -9 bitcoind and restart. This happens some of the time and often self-corrects (i.e. p2pool eventually reconnects with bitcoind).
In any event, when I posted earlier, I had just restarted p2pool and bitcoind and a few hours later I've got this:
Code:
2012-03-07 20:02:50.438056 Local: 3933MH/s in last 10.0 minutes Local dead on arrival: ~3.0% (1-5%) Expected time to share: 10.3 minutes
2012-03-07 20:02:50.438102 Shares: 71 (5 orphan, 4 dead) Stale rate: ~12.7% (6-23%) Efficiency: ~99.9% (88-107%) Current payout: 0.5926 BTC
2012-03-07 20:02:50.438151 Pool: 265GH/s Stale rate: 12.6% Expected time to block: 6.7 hours
It's reporting the pool rate at 12.6% which is higher than typical, no? Slightly higher orphan and dead rate than I normally see.
March 07, 2012, 02:14:20 PM
Variance? He only mines for 1 day (though at a high hash rate) so it might take longer for the numbers to converge.
March 07, 2012, 02:06:18 PM
The numbers p2pool reports are inaccurate based on the data it found since you started p2pool. So it will start out on 0% stale rate (it found no stales so far) and above average efficiency (no-one has 0% stales) and will approach the real value more and more if it gets more data.
But why is he getting 10% stales? The target is 9. When I was using cgminer, I was getting low 3.I was going to say lower intensity, but it looks like you did that. I'm not sure why your stale rate is high.
March 07, 2012, 01:58:59 PM
The numbers p2pool reports are inaccurate based on the data it found since you started p2pool. So it will start out on 0% stale rate (it found no stales so far) and above average efficiency (no-one has 0% stales) and will approach the real value more and more if it gets more data.
March 07, 2012, 01:52:37 PM
I had a question about staleness and efficiency. I've been mining here a while with about 3.8GH/s and I have noticed that when I start my miners on a fresh instance of p2pool/bitcoind, the stale rate starts at 0% and will climb as high as 20% over the course of a day...additionally the efficiency number will start at 112% or so and trail down to the low 90's sometimes over the same timeframe. From what I have read here, 10% is the stale target for my instance and the p2pool as well (though it's a bit higher for some reason today) and around 100% efficiency is the target where my instance should hover as well (which might explain my 20% drop in BTC payout vs. traditional pool better than variance).
I'm using the git pull on the 5th or 6th for p2pool and 0.6rc2 for bitcoind on linux. BAMT 0.5 with cgminer 2.2.7. I've got threads set to 1 on all miners and intensity seems to run well at 7.
Anything I'm overlooking?
I'm using the git pull on the 5th or 6th for p2pool and 0.6rc2 for bitcoind on linux. BAMT 0.5 with cgminer 2.2.7. I've got threads set to 1 on all miners and intensity seems to run well at 7.
Anything I'm overlooking?
March 07, 2012, 12:52:19 PM
I was thinking it would be cool if p2pool.info listed how much has been donated as subsidies. Maybe that could be added into the luck calculation, too.
That is a good idea. Maybe a separate item.
Just thinking about how I would detect these... I could look for sendmany transactions that have known addresses in them. Maybe the donation address is enough?
To incorporate these into the luck numbers is a little more tricky. Right now luck is not measuring amount of BTC earned (vs expected), but is measuring things based on hashes. I'd have to change it to be based on BTC or I'd have to translate subsidies into "hash equivalents". I'll think about it more after I look at finding a way to identify subsidy payments in the first place.
Yes please separate it because I have been mining since 30th of January with 252Mhz and still have not received any donation. I might just be really unlucky, but in my mind I've written off the donation aspect in my reasoning to move to/stay at p2pool. So I'd like the data in isolation
March 07, 2012, 12:13:07 PM
I was thinking it would be cool if p2pool.info listed how much has been donated as subsidies. Maybe that could be added into the luck calculation, too.
That is a good idea. Maybe a separate item.
Just thinking about how I would detect these... I could look for sendmany transactions that have known addresses in them. Maybe the donation address is enough?
To incorporate these into the luck numbers is a little more tricky. Right now luck is not measuring amount of BTC earned (vs expected), but is measuring things based on hashes. I'd have to change it to be based on BTC or I'd have to translate subsidies into "hash equivalents". I'll think about it more after I look at finding a way to identify subsidy payments in the first place.
March 07, 2012, 10:30:12 AM
I was thinking it would be cool if p2pool.info listed how much has been donated as subsidies. Maybe that could be added into the luck calculation, too.
That is a good idea. Maybe a separate item.
Jump to: