Topic: [1500 TH] p2pool: Decentralized, DoS-resistant, Hop-Proof pool - page 584. (Read 2591920 times)

Aside from the fact p2pool's 90 day "luck" is at 88.5%, and 30 day "luck" is at 57.1%.  Aside from that, yes, it's great.

M

I just upgraded p2pool from 11.1 to 11.2, and am informed that I need to update twisted. I'm running Ubuntu 11.04. Synaptic shows that I have python-twisted 10.2.1 installed and also indicates that is the latest version. Does this mean I must upgrade Ubuntu or ... ?

Many people have said this, but I want to make sure lenny_ understands: The 10-15% "rejects" you see in p2pool have nothing to do with a decrease in income nor with wasted work. 10-15% rejects on p2pool is the same as 2-2.5% rejects on any other pool. The reason is that the p2pool sharechain is different (in behaviour) than the bitcoin blockchain.

I'm periodically fighting FUD of "p2pool sucks because they have a ridiculous reject ratio." I then explain it to people, with examples showing how you make more money with a 10-15% reject rate on p2pool than you would on a 2% reject rate on another pool. A few days later, someone else pops up and says the same thing.

The 10 second LPs have nothing to do with lost income and does not create a disaster, the sharechain is different than the blockchain.

This is a phenomenal description of p2pool:

Can you please share your settings with me? cgminer is able to get similar results?

no need to move away aslong u need 0.7, still this dosnt matter anymore.

Pool Hashrate: 166 GH/s
Come on guys, stop your miners! Move mining machines to any other 0.7 central pool, like BTCGUild until it's all sorted.
P2pool work now against main blockchain.
Read: https://bitcointalk.org/index.php?topic=152030.200

Yeah, I have been following the developments and it sounds like soon, there will a patch to 0.8 that I'll install instead of downgrading.  Still, I advise not trusting p2pool.info for now.

in 1-2 days the invalid 0.8 chain is gone, u dont have to do anything in this case since ur bitcoind isnt mining. just wait in this case.

I can't downgrade the bitcoind that p2pool.info gets information from quickly.  I may be able to do it in a day or two.  Until then, FYI, that p2pool.info may be confused or just plain wrong about blocks and orphans (and luck and round duration).

most ppls are being scared of because they think their rejects are wasted work, donst matter how often u say it, dosnt help we would need somewhat like a FAQ explaining it maybe.

That's much too high. I have ~2.5% rejects on all my Spartan6 (CM1 and Icarus with MPBM). I have 2.6% rejects on my GPUs (5870 and 5970 with cgminer).
So I really don't see any problem with FPGAs and P2Pool: in fact they react slightly faster than my GPUs (cgminer autotune the intensity on each one to react in 50ms).


They don't waste resource, a share is only rejected if it both arrives too late and doesn't solve a block so there's no,zero,0 income wasted by these rejects. I repeat: rejects don't reduce the pool's income.


Now that's mixing your particular configuration which is clearly not optimized for p2pool and plain FUD (since when the target is a couple of seconds?).


Nope, it isn't a disaster: I earned more with p2pool in 6 months than I would have on a 100% PPS pool since I started (I keep track of each and every payment and compare it to my theoretical income on a no fee PPS pool).


Probably depends on the actual node and who connects to it: some have better connectivity than others. I used to mine on one of my rented VPS servers with a 45ms round-trip time with my miners and it worked OK (it was around 98% efficiency IIRC).


I think p2pool is for geeks who like to setup and tune everything themselves. When you can host a node properly (for me this means locally on a host with a good CPU, 2GB RAM on a Linux server dedicated to bitcoind+p2pool, a SSD to store bitcoind's data and with a good QoS setup so that both bitcoind and p2pool don't suffer from other traffic on your WAN connection) and configure a backup pool it's arguably the most reliable and profitable option.

It's not for everyone, but if you are a serious miner and have the network connection and hardware available it's simply the best solution. From what you wrote there are surprising latencies in your setup: it probably isn't for you.

I think we completely misunderstand each other.
I am talking about:
my FPGA hardware doing 0.01% rejects or less on Bitminter using Stratum. Same hardware, exactly same configuration doing 15% rejects on p2pool. I tried to tweak config and got slightly better results about 10% but that's still not the main case. 15% - That's reported by miner and by p2pool stats as well. That's wasting resources, nothing else. When we invest our money and time in something, we should do it right. FPGAs just react too slow to change nonce every couple of seconds, to top of that add remote node's bitcoind latency + network latency + time to prepare getwork etc... This is just not working for LP= 10s, it's a disaster. No one is mining of remote p2pool nodes as it will just not work as it is right now.
If you guys are saying there is no solution for that - so beware, because one day p2pool will die.

What matters is your efficiency vs the rest of P2Pool's network. As long as you average above 97% most of the time you should be fine. You can ignore transient variations: I think (didn't check the code) P2Pool compares your overall stale shares since the node startup vs the recent stale share rate of the network so recent changes in the network make the value computed for efficiency move around.

If your 10-15% are the total rejects as reported by your node, there's no problem (I have 10+% rejects and am usually slightly over 100% efficiency).
If it's the amount of rejects as reported by your miner (should be the amount reported as DOA by P2Pool), then either :

• you can afford a better setup (less network latency between node and miners and more CPU power if P2Pool is running on a weak CPU): do that
• you can't: consider other pools based on what you value most (variance in income, total expected income, admin policies, ...)

In the end everyone choose their pool based on their needs. At a time I even split my mining power across several pools. If some of your gear gets high rejects but not all of it, you might want to split too.

So what's your solution for 10-15% rejects?

In fact it's not a solution at all for this.

Increasing the target delay between shares is the only way to reduce the DOA rate when you have latency between miners and node. But if you do so and don't want to increase variance in payment amounts, you'll have to wait longer for them to stabilize: if N is constant in PPLNS and time between shares is higher, you must mine proportionally longer to reach the full payment amount.

If you do this then most newcomers will be discouraged as first payments will be low for more time. This doesn't help p2pool grow (and make global income variance lower).

I don't care about variance. I am patient (wise?) enough, to not follow "luck" drama.
I tried Icarus, CM1 and Ztex on remote nodes - result was 10-15% doa/orphan. Absolutely not acceptable. On local p2pool indeed I have nice results, but I cannot afford to run another spare computer 24/7 with Phenom II onboard just to get bitcoind latency lower. I just want to mine on remote nodes like I do with any other central pool. Increasing difficulty is only one solution for this.

If you are reacting to rav2n_pl post just before yours, I think you are mistaken. Read my previous post: if N remains the same in the PPLNS system payment amounts variance will not change unless big miners leave more place in the sharechain by using a greater difficulty than small miners.


The only FPGAs having problems are the ones from BFL in Singles and early Minirigs, I have 16 Spartan6 and don't have any problem on P2Pool with them. But you are right for a local node: P2Pool efficiency takes a hit (although a small one if you have good QoS settings) when you use a high latency connection between the miners and the P2Pool node.

Note that if you change the target time between share and don't change N in PPLNS you won't change variance at all (the difficulty will rise in the same proportions than the time covered by the PPLNS window) : you will only make payments increase slower when someone begins mining on P2Pool (which is not a big selling point) and decrease slower when it stops (better, but people want instant gratification not promises for the future).

If you make N bigger, variance in mining rewards won't be as high for small miners but it won't change much for people with 10+GH/s as their variance for payment amounts is already low. The variance due to the low global hashrate can't be solved by tuning N or time between shares but only with more hashrate. Several Avalon customers (myself included) have stated that they will run them on P2Pool, so this problem should go away in the following months if Avalon delivers.

If N is bigger this will probably have some CPU/disk costs too.

A solution to make p2pool more friendly for small miners might be to automatically adjust a miner's difficulty according to the aggregated hashrate of the Bitcoin address it works for. The difficulty would be set to keep share submission around an healthy rate (always higher than the minimum difficulty set by the current P2Pool global hashrate and around a level where variance in payment amounts is considered acceptable if its higher than the minimum). In a later hardfork of the sharechain P2Pool could even enforce a limitation on the number of shares for each payment address in the PPLNS window to make sure a big miner can't circumvent this and take all the place in the sharechain.

There's already code supporting arbitrary high share difficulty for big miners but it's only used on a voluntary basis. I hope its not difficult to implement automatic difficulty change on top of it: this might help attract more small miners (it seems the most of the big ones are still here) by lowering the difficulty they would get on P2Pool.

Good idea. It will be exactly same as it is now, but 5x greater chance to have block and payout within 5 days, especially matter for small miners. And LP 50sec will greatly decrease orphan+DOA ratio. Right now there is no point to mine on p2pool unless: we have GPU only with low intensity + we have fast CPU + fast Internet and local node on it. I tried remote nodes with many configurations, with GPUs, many FPGAs, result was always tragic.

Not necessary bigger share chain, if we put higher diff and longer long pool share chain can be same length aka consume same memory.
Make it 5 days long and 50sec longpool. It will be the same like it is now. Diff of next share need to be calculated every share from last 10/20 shares.