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

Hi,

Looking to start a Razor coin p2pool, does anyone have the detail for the networks.py file?

Or point me in the right direction where to get it all?



Thanks

You can also do a manual addnode to bluematts backbone network

Sorry, that was not totaly clear was it?

Yes, bitcoind on both machines and edit the bitcoin.conf on both, adding;-

addnode=IP.OF.GAMES.MACHIENE

To the bitcoin.conf of the p2pool machine and;-

maxconnections=80

On my games machine.

In theory it may help in 2 ways;-

1. Less open connections on your p2pool. (saving resources)

3. When you find a block it is propagated quicker (less orphans of blockchain blocks YOU find).

It is all theory of coarse but it is an easy way to reduce the resource load on your p2pool server if you are worried about it.

Neil

That's an interesting thought... adding your machine running the bitcoind.  I'm a bit confused, though.  Are you running the bitcoin daemon on both your games machine and your p2pool one, or are you using
when you start up your p2pool node?

@kgb2mining, another option to consider is ensuring you have connections to nodes that are close to you.  There is a command that you can pass when you start your node:
This forces your node to connect to this particular in addition to the ones it will randomly connect to on startup.  Remember, the orphan race completely depends on which share chain is longer and gets broadcast across the network first.  If you're broadcasting your own version of the chain to a node that's 500ms away, and I'm broadcasting my chain to that same node, but it's only 50ms from me, I win the race.

If you are really concerned about it here is something I do.  I am not sure it helps but it makes sure my node is fully connected.  On my p2pool node I just leave maxconnections alone BUT I have a full node on my windows machine (to play games with) that I bump maxconnections up to 80.

I then addnode=10.1.1.5:8333 from my p2pool to my games machine.

I cannot say it really makes a difference because I have never really thought of a good way to test it, just the simple maths of 87*n (87 being the outside connections and n being the total connections of my pairs) makes me think that I should have a fairly decent "2 hop" reach.

Of course, it only matters when you are the person that finds the block, and in all my years of mining that has been 5

Neil

Ahh ok, that makes enough sense, thank you.  That being the case, looks like I'm going to want to open inbound connections then.

Currently Expected time to share: 2.6 days. I would say the average is about 2 days. What should I look for when I press P? I really do not know what is going on.

I think he means that there is a better chance that your p2pool shares do not get orphaned if more nodes are notified the moment you find your shares. It is a known fact that a p2pool node with poor connectivity to other p2pool nodes would end up having more orphaned shares, and you don't get credit for them. Forwarding your p2pool port means that you have total connectivity from both outgoing as well as incoming connections. If you don't port forward then you don't have incoming connections and have to rely solely on your outgoing connections to broadcast your shares.

Ok, can you explain a little more the bold part?  Not sure I follow why letting other connections in helps.

I would have thought that the server running bitcoind would be just pulling down shares and feeding them to my miners, then putting them back up when solved to whatever peer it connected to get them from in the first place.

One of them is actually running at stock, with the same degredation over time. When I started them, they were running at 440Gh/s and 504 Gh/s respectively, then over a day went down to 410 and 440. Now they seem stable at those rates. Haven't tried them on another pool, yet.

Apparently, it's better to have a low number of low latency connections than to have a large absolute number of varying latencies. I'm not sure how much difference it makes in practice, but I limit connections from bitcoin and p2pool clients to 10. The original advice (I think from bitocintalk user zvs) was to limit the number lower, but I figured a compromise was better than doing a load of testing while mining live.

You should at least forward the p2pool port.  That'll get you more connections and make you more likely to win the share race.  Same for the Bitcoin port.  But technically you don't need to.

M

yes.


10Mbit/s is more than enough, not sure about the exact figures for what p2pool consumes, but they're orders or magnitude lower than 10Mbit/s. 10Mbits is bigger than the current block size limit, I have a slower connection than that and can achieve getblocktemplate latencies of less than 0.3 seconds (which does not include the p2pool activity that will be happening simultaneously)

We just switched mining to p2pool from BTCGuild.  No general problems over there, but I have been reading about p2pool and think it may be a better choice in the long term for many reasons.

I'm considering building our own pool node since we have the computing resources to do it in a proper datacenter setting.  I have a couple main questions about resource needs, if anyone who's running pools currently could chime in with real-world experiences I'd appreciate it.

First off, can I run a "private" node, inside the firewall without opening any ports inbound?  Just something that is part of the network that we could point our miners to for our use for now.  Having the ability to do this would help the decision on where to run the node, being inside would help the latency between the miners and the node.  Eventually I could see us opening it up for others to use if there's enough need for a local node (Northern NJ, which seems to have good coverage for now I think).

Second, what are you seeing for bandwith needs, both spike and average consistent rate?  Pulling up to 10Mbit/s is doable without much notice or problem, but if we're pulling more than that on a consistent basis that wouldn't be too good.

The node would be based off of Ubuntu 14.04 virtual machines (4CPU, 8GB RAM to start).

Thanks.

Sounds like S2 behavior.

M

Yea, the S1s came littered with thermal paste as well, little easier to clean up without the extra heat sinks though....

So far, yes, I've seen the best results on stock clocks.  One thing I have noticed is that one of my S3's performance slowly degrades.  It hashes at 440GH/s for a while... then slows down to 430 and 420.  Rebooting it sometimes helped, but a lot of times on reboot, I'd notice one of the ASIC would show a status of "-" instead of "o".

So, this morning I completely stripped the thing.  When I pulled off the heatsinks, I saw thermal paste everywhere.  It was on the chips, on the PCB, on everything.  So, I cleaned it all up and re-applied to the chips.  Everything is put back together and it's up and hashing again.  Hopefully, it will stay consistent now.  We'll see .

I'm probably going to do the same to my other one as well.  Then, I'll retry over clocking them both.  Some people have reported amazing success.  For example, Goxed has his happily hashing away at 504GH/s (250 clock).  Now that would be nice!

Your error rates look great, both well under 1%, have you tried another pool to see how they preform?

jonnybravo0311 seemed to get the best results running them at stock clocks....

Edit: Ant error rate calculator: http://www.coincadence.com/antminer-s1-hardware-error/

(was built for S1, but works the same for S3...)

I'm a bit disappointed by my S3's on P2Pool. After 1 day mining:

The top one got a lot of hardware errors so I just run it at stock, the bottom one overclocked quite well to 250...started off well on P2Pool, but reported hashrate is pretty bad on both. Note: the node is not close to me, but it shouldn't show this much difference - my old S1's did fine with it.

EDIT: anyone know what the discarded shows? Mine seems pretty high.

This is good great news, looks like Bitmain came through!

My batch 1s are in transit, should be a Monday delivery.

Thanks for sharing

Edit: And look at that error rate:

Top miner: 0.00125648267%
Bottom miner: 0.00073813656%

WOW!