[1500 TH] p2pool: Decentralized, DoS-resistant, Hop-Proof pool

[Red Emerald]

well like i said originally, only 80mh, the payment is really basically costing more then my electricity anyway, so, oh well to the lost day.

You should look at p2pmining.com. Its a p2pool node meant for small miners

[1713463613]

1713463613

[1713463613]

1713463613

[1713463613]

1713463613

[arklan]

will do. thanks.

EDIT: checked it out. wow! excellent. easy as pie to set up and instantly earmed some payout. ...a very tiny amount mind, but every penny counts. er... every... uh... bit-penny?

[arklan]

ok, so been on p2pmining.com for a bit now - seems ot work well as i said previous. but... how do i get the payout? a block was completed, and the payment confirmed according to the website. i've tried the instant payout tab corresponding to my address, but i haven't the foggiest what to actually enteras a signature to get it to pay out. i assumed it was the provided "sign this message", like "pay-123456789" but that just returns invalid signature.

clearly, i'm some kind of ultra newb here... little help?

EDIT: ignore all that, i figured it out.

[camolist]

loving p2pool. just need to either figure out why windows 7 is crashing about once a day or switch to linux soon

would it be a disadvantage to host p2pool on a server about 50ms away from the mining computer?

how much bandwidth is transferred while connected to the pool? connected locally this is not an issue at all but curious if it were to be hosted remotely

advantages i can see right away would be guaranteed static ip and perfect uptime along with a great network. could even make it a public fee free pool if bandwidth use is low enough

after looking at the errors i think the windows problem was having 4gb of ram on a board that supports 2. it's been stable for awhile since taking a piece out

went ahead and just tried this since i didn't see any comments on it

went from 91-92% efficiency running p2pool locally (over 100 shares) to > 100 % (only 31 shares so far but just one dead) running it on a virtual server in a good datacenter


http://50.31.2.7:9332/static/
http://50.31.2.7:9332/static/graphs.html


hope this helps someone getting high dead and orphan numbers on a copy of p2pool ran locally

[Ente]

went from 91-92% efficiency running p2pool locally (over 100 shares) to > 100 % (only 31 shares so far but just one dead) running it on a virtual server in a good datacenter

Interesting! I wouldn't have expected this.. Nice find! Report back in a week, curious how this turns out!

Ente

[bitpop]

Thats why you should try my free node

[DeathAndTaxes]

So I decided to finally switch my Win7 box from the precompiled version to the python script version so I can incorporate latest changes (and some custom ones).

Is there a guide anywhere for setting up the non exe version of p2pool with Windows 7?
Should all the historical data (charts, stats) be compatible in the switch?
Also latest python version is 3.2.3.  Is p2pool not compatible w/ 3.x and that is why recommended version is 2.7.x?

[bitpop]

Python version upgrades have breaking changes and aren't necessarily updates.

[DeathAndTaxes]

went from 91-92% efficiency running p2pool locally (over 100 shares) to > 100 % (only 31 shares so far but just one dead) running it on a virtual server in a good datacenter

Now that is interesting.

Can you dig into the stats and see why?

Most likely one of the three must have changed.
a) lower orphans (maybe because hosted instance has lower latency links to peers)?*
b) lower dead rate (maybe because the local instance was unable to keep up introducing delays)?
c) higher effective hashrate (server 0 not providing work fast enough errors in cgminer?)

* On lower orphans I wonder how much latency to peers matters.  Currently IIRC nodes only pick peers based on stability (how long they have seen them) but I wonder if nodes should drop peers in favor or other peers if latency is too high and/or if peer is on an older version.  In essence a more heuristic approach to picking peers.


http://50.31.2.7:9332/static/
http://50.31.2.7:9332/static/graphs.html


hope this helps someone getting high dead and orphan numbers on a copy of p2pool ran locally
[/quote]

[twmz]

went from 91-92% efficiency running p2pool locally (over 100 shares) to > 100 % (only 31 shares so far but just one dead) running it on a virtual server in a good datacenter

Now that is interesting.

Can you dig into the stats and see why?

I have very high efficiency with my current p2pool setup.  Here are my current stats (it has been a week or two since I most recently restarted p2pool):

Code:

Shares: 896 (22 orphan, 10 dead) Stale rate: ~3.6% (2-5%) Efficiency: ~102.6% (101-104%)

I have been consistently getting approx 3.5% stale rate for the past month or so, so this is not a fluke.  Here are some musings...

• The hardware that p2pool and bitcoind runs on matters.  I went from a VM to a fast physical machine (for just p2pool and bitcoind--no change to miners) and that dropped my stale rate by half. My assumption is that CPU speed matters more than RAM amount as long as you have enough RAM that there is no swapping.  Disk performance may also matter for bitcoind.
• The conventional wisdom on parameters for cgminer is not as relevant as people make it sound.  For example, I do not use 1 thread per GPU.  I found that to be irrelevent.  My settings vary from rig to rig (my rigs are not all identical GPU hardware or even SDK/driver version).  For each rig, I experimented with combinations of thread and intensity until I found the best hashrate and stale rate.  In all cases, I ended up with either 2 or 3 threads per GPU and intensity setting different than what people normally seem to use.
• I don't have data to back this up because I don't have a "control" to compare against, but I suspect that connected-ness of p2pool matters a lot.  My node is an old node and so almost always has 40 incoming connections.  With only a few hundred nodes total, that means I am hearing about new shares directly from about 20-25% of the nodes instead of hearing about new shares second or third hand.

In my experience over the past several months, it was the hardware change that made the most dramatic and instant impact.  I went from "average" stale rate to "consistently 2-3% better than average" stale rate over night when I changed the hardware for my primary p2pool node.

Of course, I probably should just keep my mouth shut and enjoy my extra efficiency.  If everyone improves their stale rate, my great stale rate becomes just average again

[DeathAndTaxes]

So trying to setup p2pool (python source) on Windows 7.

Already have bitcoind 0.6 & p2pool 10.3 (exe) running without issue.

Installed python 2.7.3 (x64) for Windows 7
Installed Twisted 12.0.0 for python 2.7.3 Windows 7
Downloaded latest github version of p2pool:

Code:

C:\Bitcoin\p2pool-0.10.3-41>setup.py
Traceback (most recent call last):
  File "C:\Bitcoin\p2pool-0.10.3-41\setup.py", line 7, in <module>
    import py2exe
ImportError: No module named py2exe


C:\Bitcoin\p2pool-0.10.3-41>run_p2pool.py
Traceback (most recent call last):
  File "C:\Bitcoin\p2pool-0.10.3-41\run_p2pool.py", line 3, in <module> from p2pool import main
  File "C:\Bitcoin\p2pool-0.10.3-41\p2pool\main.py", line 22, in <module> from twisted.internet import defer, reactor, protocol, task
  File "C:\Python27\lib\site-packages\twisted\internet\defer.py", line 25, in <module> from twisted.python import log, failure, lockfile
  File "C:\Python27\lib\site-packages\twisted\python\log.py", line 17, in <module> from zope.interface import Interface
ImportError: No module named zope.interface

Any ideas?

On edit: looks like "zope.interface" is required.
http://www.lfd.uci.edu/~gohlke/pythonlibs/#zope.interface

Installing zope.interface-3.8.0.win-amd64-py2.7.‌exe got rid of the errors.

forrestv the dependencies on first page should likely be updated to reflect Bitcoind 0.6 (or 0.5.4 backport) and python "zope.interface".

[bitpop]

try cigwin

[kano]

Noticed a few blocks recently with coinbase payments (10 addresses) with random block sources ...
Anyone know if it is another P2Pool? Or is it just the people still mining on P2Pool who didn't update?

Blocks: 176210 (failed fork), 175998 (failed fork), 174343 (failed fork)
The blocks before that are before 1-Apr (not failed forks) so I guess that would make sense also: 172428, 172357, 172069, 171896 etc.

The address getting the largest (now failed) payments is: 1FcTuPJzdekvzTyQ5dXsnsVyT4F5G1tCjc
If it is P2Pool though, it's slightly modified
(it doesn't have the 0 BTC payment tacked on the end of all P2Pool coinbase txn's - but I wonder if it is documented anywhere what that actually is?)

[camolist]

Can you dig into the stats and see why?

running locally it was getting high orphan rates (about 3 for every 1 dead) about 15% stale overall - this was over about 4 days time period with 1200mh

running on the vps at a datacenter after two days it had 1 orphan and 3 dead - 5.8% stale



rebuilding vps to be multi core and a bit more ram once it's back up i'll be increasing from 1.2 to 1.6 gh and will let it run for a few days then try once more on a local copy of p2pool for the same amount of time and compare exact numbers

[DeathAndTaxes]

hmm given the major difference is the the # of orphans it makes me think your connectivity is the largest factor.

If the p2pool and/or bitcoind instances were slow (due to insufficient memory, I/O, or CPU time) then at least in theory one would expect to see higher deads not orphans.

Obviously more testing is needed but my guess is the datacenter has a lower latency link to the avg peer.  Thus you are learning about new shares quicker and getting your shares into the chain quicker. I may need to play around and see about recording latency to peers.  See if there is any correlation between orphan and peer latency and/or # of peers.

[camolist]

hmm given the major difference is the the # of orphans it makes me think your connectivity is the largest factor.

that's what i was thinking

but adding in 50-60ms to connect to the datacenter which then connects out to the peers i would expect close to the same results unless my connectivity to the datacenter is so much better then to the peers


waiting for setup on the vps to finish to start testing if increasing the cpu/ram (it was way low before) lowers the dead rates a bit. but i think the dead rate on the server end has more to do with the 50-60ms trip back and forth getting new work to the miners

[Krak]

What specs are on your VPS? I'm thinking about renting one that's local to me, but I dunno how much I should be looking at spending.

[forrestv]

The address getting the largest (now failed) payments is: 1FcTuPJzdekvzTyQ5dXsnsVyT4F5G1tCjc
If it is P2Pool though, it's slightly modified
(it doesn't have the 0 BTC payment tacked on the end of all P2Pool coinbase txn's - but I wonder if it is documented anywhere what that actually is?)

They can't be P2Pool blocks - the 0 output at the end is essential to P2Pool's operation. It links P2Pool's internal data for a particular share to the block that share would have mined. (The other alternative is sticking it in the coinbase, but the coinbase of the block that I looked at is nearly empty.)

[camolist]

What specs are on your VPS? I'm thinking about renting one that's local to me, but I dunno how much I should be looking at spending.

it was just 300mb of ram but that was looking to be a bit low so upping it to 512 on the reinstall

cpu was 1% guaranteed on one core am upping that to 1% guaranteed on 8 cores since the price difference is only $5.6 a month


cpu is hard to compare to other hosts because using FAR more then 1% will always be possible (i've tried litecoin mining on these and found 1% of the cpu could use 90+% the vast majority of the time) (and an interesting note was it was still not profitable only paying for 1% of the cpu and using 90% with litecoins)

[hashalfahalve]

Is someone perhaps able to help me understand why the hash rate reported on the p2pool console output says 3722MH when my miners are saying 4099MH?

I have a 2.36% reject rate, so even with that in account, shouldn't I still be seeing 4002MH?

I can't seem to figure out where the 280-300MH loss is!

When I increase aggression on cgminer and get a higher reject rate, the p2pool output shows a higher hashrate! So confusing...