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

"Screwed" is probably an exaggeration: that's only 3% on one block and the node lost these 3% too. That could be unintentional too (a freshly restarted node which didn't have the time to fill it's memory pool will generate a block with fewer transactions).

What's important is that it's not an exception: that's the second time I check recent P2Pool blocks and I found that they were small ones which missed potentially higher fee income.

So the node that got it screwed us?

Some people didn't get the memo: this block is only ~73kB with ~0.11BTC fees. With the current amount of transactions waiting confirmation (2500+, ~20MB, more than 25BTC in fees) generating such a short block is unlikely without messing with maxblocksize, mintxfee or minrelaytxfee.

With bitcoind 0.8.2 default configuration in the current situation my node would generate a ~450kB block with ~0.80BTC fees (look at your bitcoind getmininginfo to get the size of the block template and at P2Pool logs or interface for the fees' value).

Assuming the block was generated under similar circumstances that's nearly 3% income lost for everyone. At this point people should use the default bitcoind configuration if they don't fully understand how to tune it.

Well like 8 hours ago.

Two? I saw only this one http://blockexplorer.com/block/0000000000000026b9f1a978acd4d263b0889ed36bfa35106299b9a54f6b6e52

Two LARGE payouts already today! Be patient fuckers.

I like it, soon we get 5 payments in one day!

bad luck sucks 

Doesn't matter some days we get 4. Statistics bro

So, how 'bout that crappy streak of bad luck these past few days, eh?

Probably the recent rise in difficulty. I think we are all feeling it.

After upgrading bitcoind to 0.8.2, p2pool seems rock solid and has been up for over a week without a restart. No more big jumps in latency.

However it seems to have stopped finding blocks and my CGMiner hasn't found a block in two days so consequently my payout has fallen to 0 and stayed there for at least a day.

I mine at 275 MH/s and normally have a payout in the range 0.008 to 0.015 and probably find around 5 blocks a day. It seems highly unlikely that I would go 2 days with nothing and that my payout would fall to zero. Has anybody else experienced this and could there be a bug in p2pool as a result of running for so long without a restart ?

Thanks

Hi all,

Every now and then on my Litecoin P2Pool node I get the following messages :

"Failure: twisted.internet.error.ConnectBindError: Couldn't bind: 24: Too many open files"

I've adjusted my OS settings to the following to allow more open files but still seems to be happening every now and then.
* soft nofile 16384
* hard nofile 65536
* soft nproc 4096
* hard nproc 16384

If anybody could point me in the right direction it would be greatly appreciated.

F.

Mine below in sig is running on aws
try min, its fee free

Yeah I have done it with
Memory optimized    m2.xlarge    64-bit    2    6.5    17.1    1 x 420    -    Moderate

using 10gig as a ram drive  for bitcoind.

But it was getting close to/was using all the memory running two bitcoinds.

So was contemplating Memory optimized    m2.2xlarge    64-bit    4    13    34.2    1 x 850

If you dont need rock solid uptime, you can do it on the cheap using spot instances using your own ami and a ebi volume for persistent data for p2pool and first bitcoind data.

Without volume charge your looking at around $25 to $30 for the 17gig memory one and double that for the 34gig memory one a month for usa. Other pricing areas you'll have to check.

With the second bitcoind  in ram drive the getwork latencies were pretty low  and was about 115% efficiency.

Was getting jumps now and then but, might have been the instance running out of memory, didnt look into it much more.

I tried running my jalapeno on a segregated p2pool network (2 nodes only, both nodes on computers I control, no outside connections permitted).

The problem I've been observing using the jalapeno with p2pool is definitely revolving around how the jalapeno returns work. It doesn't look like valid work is returned as soon as it was found, but sending back multiple valids at the same time.

The effect is, the first valid has a good chance of being a valid share, but the rest of the valids sent after it are always rejected.

While they may still be a valid block, I think the same problem arises there too. First valid solves the block, the rest of the valids are rejected as they won't build on the block the first valid solved. Granted, this won't happen often, but it will happen.

The problem when it comes to p2pool is, the miner using the jalapeno, might not get accurate credit for the amount of work they're doing, just because the jalapeno won't abort the work it is doing to start new work, so those miners that are using equipment that will do that, will always have an edge just because they will be more responsive to change.

As the jalapeno keeps mining for more results after it already found a valid result, and not yet sending it along, it is just wasting power at that point.

Just my observations this past week.

Protocol-wise, it seems to behave, it just doesn't appear to handle valid results efficiently.

All that said... after almost 2 years of being stuck at ~160MH/s, now mining at ~5.2GH/s? I don't quite believe I'm watching my own stats yet, thinking I'm being punked by a feed of someone else's screenshots. This is taking some getting used to. XD

-- Smoov

Is there anyone out there running p2pool on Amazon AWS for themselves and a few friends? How is performance/efficiency? What instance size do you use and what is the monthly cost? I was starting to test this out on the free tier as a proof-of-concept, but the free tier can't even keep bitcoind up with the memory usage.

This may be a good place to ask
 Looking for a developer to patch bytecoin https://bitcointalksearch.org/topic/4000-bte-bounty-for-patching-bytecoin-to-merged-mine-223904

I wouldn't hold my breath: although they have mining software on board, AFAIK there's no way to update it if the problem lies on their end (which it seems to be if other software can use the stratum proxy with p2pool fine). You would be better off asking friedcat for help than p2pool devs.

Last time someone pointed his fingers to p2pool as a source of problems with an ASIC device, the problem was the ASIC device itself (BFL SC with no support for interrupting work or short nonce ranges). There are devices that simply won't work or work properly with short intervals between LPs or stratum work restarts.

Is there anyone willing to make BE Blades working with p2pool?
Just to remind Last forrestv patch to stratum mining proxy make it working now nicely with p2pool, (c)gminer or any other now can connect to stratum proxy and to p2pool. But BE Blades still not working that way