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

Greetings mdude - welcome back, you glutton for punishment you 

768k up is more than enough dude - I have the same (on a good day).

i7 & 24gb RAM is overkill my man. I run an unlocked Sempron mildly OC'd with 16gb RAM on my node merge mining 6 coins no problem (no weekly reboots/resets/restarts needed here  ), check my sig for stats if you need a comparison. Are you on windoze or Linux?

I'm going try P2pool again, running it locally.  I intend to point one Ant S1 at it.  I have a DSL connection with only 768k up speed.  Any suggestions/recommendations?

If I can't get it working locally, I'll find a good public node.

Thanks,

M.

EDIT: Bitcoin and p2pool will be running on my main workstation, an i7 with 24gb ram and the blockchain and p2pool chain on my SSD.

I'd guess that absolutely nothing has kept pace with hash rate. Number of miners, number of users etc. In fact not even bitcoin value. The big driver there is more advanced ASIC technology.

As far as the number of miners compared to the number of bitcoin nodes, I have no idea. Both have consolidated as things have become a bit more centralized I would guess.

Yes, I think we can both agree on both parts of that sentence.
If someone is already running a full bitcoin node, p2pool is a much easier sell.
My guess would be that while the hashrate has risen massively in the last year, the number of full bitcoin nodes has nowhere near kept pace?

Massive is relative. By your definition $1 would be "massively more" than $0.01 ("It's 100 times more!") but its still only a dollar.

As I said, if you are running a bitcoin node already, the added cost running a p2pool node is minimal. Certainly not everyone does have a bitcoin node.

The risk is much lower because the pool never holds the coins. You can verify -- independently (try that on a centralized pool) -- that your shares are being accepted (and will be paid) by looking at the current payouts on any other public node. Even eligius, which claims to make coinbase payouts, has had a huge amount of coins going to their own wallets recently. So far all of those coins have been paid out (if slowly) but this makes them a big target for hackers and exposes everyone to the risk of large operator errors. At times there has been over 3000 BTC being held and paid out "manually."

The other reason it is unlikely you get ripped off by a public node is that each public node tends to be very small. There is so little incentive to be gained by a public node operator skimming a small number of shares it's very unlikely to ever happen. Skimming a tiny (or maybe even not so tiny) amount from a big pool, by contrast, might well be enough to get rich.


That's one reason, but not the only reason. Guaranteed coinbase payouts are another reason, and potentially lower fees (not compared to ghash.io but compared to nearly all of the others).

If a few large miners do care about protecting the network, and a bit of a nudge can get them using p2pool, that too can make a difference.

Most of the new ASIC hardware either includes, or can be controlled by, tiny computers like a Raspberry Pi or a BeagleBone.
Mining on a standard pool means no need to store the blockchain, almost no CPU or memory requirements, and no network bandwidth required for all of the transactions.
Compared to that, runnng a p2pool node does require massively more resources.


Which opens you back up again to your pool being dishonest or incompetent.
Daily withdrawals from a 'normal' pool reduces the exposure to loss.

The primary reason to use p2pool is to 'protect the network'.
Most new miners don't care about that.

That's valid feedback here. It doesn't help recruit people to use the p2pool software that exists today. For that matter, I'm not a p2pool developer, so for that reason alone it isn't useful or on-topic feedback on my thread. Give your "advice" to them (or better yet contribute), not me.


Please see the FUD-repellant thread (https://bitcointalksearch.org/topic/a-guide-for-mining-efficiently-on-p2pool-includes-fud-repellent-and-faq-153232) and stop spreading it. P2pool doesn't require "a lot" of effort or resources. I did so for in a few hours on hardware that cost me a few hundred dollars (a tiny fraction of what I've spent on miners), and it is probably possible to use cheaper hardware or run on existing hardware in many cases. That's a small price to pay for for the benefits of immunity from the risks of pools being dishonest, getting hacked, or just having screw ups.

In fact it doesn't require any resources at all since you can use an existing public node.

I do agree it isn't suitable for small miners due to the need to run a bitcoin node, although some people do that anyway. The p2pool part itself is minimal.

"You need to make it much easier to install and understand" is a legitimate bit of advice, and just removing posts won't stop that being true.
The 'problem' is that almost all of the new mining power joining the Bitcoin network is motivated purely by profit, and has no altruistic interest in securing the Bitcoin network as an end in itself.
P2Pool requires a lot of extra effort and resources, for little, if any, actual additional benefit over using Eligious/GHash.

My ASIC is an ASICminer blade V2. The 22% haircut is barely tolerable (consider it a donation). Extending the share target to 30 seconds really helped though.


I posted the error messages in my earlier posts.
- https://bitbucket.org/pypy/compatibility/wiki/twisted

Since pypy did not detect the installed modules, they must have been using the C optimizations (Python detected them).

- https://bitbucket.org/pypy/compatibility/wiki/c-api

The "problem" with pure python modules is that they are interpreted. This is slower than native machine code.

Are you using one of the new ASICs that I mentioned earlier? The real fix is to natively support longpolling or stratum (or shorter rounds), as the recent ASICs do. Otherwise, your ASIC will just not work well with any pool or coin with fast rounds.

As much a supporter of p2pool I might be, I'd suggest you move that hardware elsewhere if it can't be fixed. When I was running older ASICs I tried p2pool and then stopped using it. Wasn't fixable given the latency inherent in the hardware.


Which modules? I'm using whatever python module come from apt-get on ubnutu 13.10? (Pretty much the default install instructions for p2pool if I recall correctly.) Do you know if there is problem with those?

You can see from my graph that it is not fixed for me. The fix was to extend the block-target to 30 seconds. With a 10 second block target, I would have >65% DOA shares on average because the round time on my ASIC is 12.8 seconds (and does not support longpolling). As it is, I expect at least 22% DOA. In practice, I am getting 30% or more.


A P2Pool getblock template lantency graph would tell me how long P2Pool spends processing it's own blocks. I suspect that it runs several seconds on my machine. I could artificially lower the bitcoind getblocktemplate time by:

• Un-nice-ing  bitcoind. This will actually slow down P2Pool
• Closing bitcoind to incoming connections as suggested. I want to contribute to the Bitcoin network as much as possible. Mining is just a bonus.

Edit: If I assume the P2Pool getblocktemplate processing always takes the same amount to time (thus makes a graph pointless), I can calculate it from my hash-rate graph. 30% DOA - 22% Expected DOA = 8% of 30 seconds of round time being CPU latency.
30secondsx8%=2.4 seconds - 0.7s  Bitcoind latency = 1.7 seconds P2Pool latency
--some of that may be due to limited network bandwidth too.
--My machine is dual-core as well, so that simple math may not hold.


My machine is one of those ought's machines that supports 64bit processing, but only has 32 bits of address space. I suspect if pypy worked with no problems for you; your python modules were probably not c-optimized.

Getblocktemplate itself shouldn't have to go to disk (the mempool is in memory, obviously). Yes the rest of bitcoind does hit disk and maybe this slows down GBT (due to locks), but that shouldn't be a major issue with an SSD. One guess would be maybe with the increased pypy memory usage (not sure why that happens) you have less available RAM for caching so you hit disk (even SSD) more, slowing things down. Perhaps that offsets the CPU gains from pypy.


Ah, that could be. One thing I do is block incoming connections on my bitcoind node, which has the effect of avoiding blockchain downloads (since the standard client only does them on outgoing connections -- to them, incoming to you). Downloading the block chain is really bad with p2pool, especially if you have any ISP bandwidth issues, but probably for other performance reasons, as you point out.


How would this be different from the graph that is currently displayed?

Regarding my hardware it isn't that the system is so new (or fast), it is just that I had some extra 4 GB modules sitting around so I used them. It is actually an nettop type system with a dual-core but otherwise severely underpowered AMD. It may be that I was more CPU limited without pypy compared to a more conventional PC so I saw more improvement.

I never said reboot. And for that matter, there is nothing bad that happens specifically after a week. I have noticed there are some resource leaks that come up, so to avoid problems, I set things up to restart p2pool (only, I don't reboot or restart bitcoind) once per week, before any problems occur. Others have reported the exact same resource leaks. There is nothing wrong with my setup. My node works wonderfully (consistently >100% efficiency).

There is a bit of irony here, as you talk about "gurus" claiming there is nothing wrong with p2pool and accusing miners of not knowing what they are doing then you show up here and do the exact same thing.

Most of the ASIC problems you identified last year don't exist any more. This was mostly solved by the ASIC miners working better. As you correctly state, there hasn't been

I will be reopening a new recruiting thread, and it will be self moderated. If you have something to add in terms of recruiting miners to p2pool and therefore helping bitcoin, you and IYFTech are welcome to join. General complaints about p2pool, especially when you haven't even tried using it recently with current hardware are unwelcome. "It's not as good as my vaporware idea of a project" is even more useless.

There is a little bit of swap use, but the only things using more than about 16MB are Bitcoind and P2Pool. Together they use about 2GB of my 3.3GB of available memory. By "cache miss", I meant the OS had to go to disk at all (the Bitcoin blockchain does not fit in RAM).

Looking at that graph a second time, it appear that the first spike starts to ramp up over an hour or so. Not sure what would cause that (maybe a peer downloading the block-chain?). If your machine has 8GB of RAM, it is probably newer than mine. Maybe pypy JIT overhead is negligible on newer hardware.

One other possibility is that pypy did lower latency, making my machine the first choice for information on the network. The resulting work then increased latency (Bitcoind is running "niced" for some reason). Edit: The spike in data-out after the latency spike may indicate this if the time-scale was not days. May need to re-test if I get a new CPU/motherboard.

Keep in mind the the python packages on FreeBSD appear to use c-optimized modules by default. This may diminish any JIT performance advantages.

Edit: While we are making feature requests: I would like to see a p2pool block template latency graph, if that is possible. Would take a lot of guess-work out of my testing.

+1

Dude, great minds & all that........

Think I'll chime in here - been a while since I posted anything on the p2pool thread, mainly because I gave up with p2pool a while ago due to the exact reasons IYFTech pointed out in your doomed thread begging for miners.

Offering to help new users setup p2pool correctly when you are obviously having difficulty setting up your own node is unwise. Having to reboot every week means you have done something wrong, even with all the bugs in p2pool, you should not have to do this.

I used to mine at p2pool in the pre-asic age when it worked pretty well. Things started going tits up when stratum was implemented, but this was finally sorted out after many months of wrangling due to a few so called "gurus" denying that there was anything wrong, when there obviously was. Next up was the asic problem, nothing worked with p2pool apart from a select few items that had to be fiddled with & coaxed into playing nicely with p2pool (including special firmware) while all the time the same "gurus" denied there was ever a problem & it was every body else's fault. If you scroll back through the p2pool pages you will see this, every mention of any problem with p2pool was instantly dismissed by the "gurus" who would accuse miners of not knowing what they were doing & even told to go mine somewhere else. Great PR eh? Although I notice that things have slightly improved in this respect as most of the "gurus" seem to have moved on themselves......

I got so frustrated with not only the lack of development with p2pool but also the unwillingness of certain "guru" users to even admit that p2pool could be improved, that I even tried to set up a more user friendly version over 10 months ago:

https://bitcointalksearch.org/topic/an-enhanced-alternative-p2p-pool-a-think-tank-213051

My problem was not finding someone capable of coding such a program, it was finding a coder who understood the bitcoin protocol/mining process & implementing that into the software - but after much discussion & searching I was reluctantly forced into dropping the project. What IYFTech said in your thread about ease of use, GUI, wizard installer etc is 100% correct & is exactly what I was trying to achieve & I can't help but think that if I had been able to get the project off the ground p2p mining would be in a much healthier state than it is now, as would the network in general due to the decentralized nature of p2p mining, which is the one thing everyone seems to agree on.

Nothing changes with p2pool. It is a classic case of someone having a good idea a few years ago & then resting on their laurels expecting it to be fine forever more, while watching the donations roll in. It's the same old story here, always has been, always will be. Adapt & improve or die - it's as simple as that.

Peace  

Edit: The issues that you say you have identified have been known about for well over a year - the problem is that nothing has been done about it.

As I said, if you don't like the job the developers are doing, tell them about it here. That's appropriate.  Better yet offer specific suggestions or volunteer to do some of the work yourself, or sponsor it.

Crashing a thread asking miners to try p2pool (and offering to help them do so) with complaints about the p2pool developers is not appropriate. Especially while doing nothing constructive about any of the issues you or I have identified.

That went well.........



Don't be upset with a p2pool user because he pointed out the blindingly obvious - be upset about the lack of development/bug fixing/improvements by the "devs" of p2pool who are taking donations for nothing

PS: If you are having to restart your node every week I suggest you take another look at your setup/hardware - something ain't right there dude.

Somewhat odd results there. Are you short on RAM, maybe swapping? I get a pretty big drop in latency and CPU usage using pypy on a low end dual-core AMD box, but I also see the increased memory usage (but I have 8 GB so not an issue). I don't see latency spikes at all.

Does FreeBSD do huge pages? I found that helps on Linux, probably even more with pypy given the bigger memory footprint, though I didn't measure that.

Well I think the results are in: pypy is not really faster than python c modules on my machine (FreeBSD 9.2).



The left grouping is python2.7, the grouping on the right is pypy(2.0 I believe).

CPU usage is hard to compare directly.  It appears to be proportional to the amount of data relayed on the network though. It takes time for the number of active connections to recover after a restart. The drop-off near the end was caused by an Internet outage.

I am assuming the large spikes in the pypy side of the graph are caused by disk cache misses. The disk is a SSD, so a lag of an extra second would probably have to correspond to over 500 seeks (assuming 2ms each). P2Pool being run by pypy appears to use about 3x the memory as P2Pool run by python (1200 vs 400 MB). My memory usage graph is blank for some reason.



As you can see, the DOA rate does not change much. If anything overall hash-rate goes down a bit as the number of connections go up. My machine is limited to 16 connections.

When going back to python, I used the following options:

The first option was used just in case it helps. The second option was intended to undo/ignore my handywork in this post.