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

NastyPool is part of a integrated service on nastyfans.org. Opening this code would not help anyone else to run it on their node because it is not a standalone solution.

The new NastyPoP payout method running on NastyPool is not black magic. I put together now information web pages that describe exactly how it works. It is quite simple. I think longtime P2Pool miners would see how fun it is to mine on. Especially if they are <1TH/s miners.

What makes NastyPoP so interesting is not that it is some magical payout method that magically uses P2Pool. It is interesting because it allows a sub-pool of miners to work together fairly on P2Pool. And it does this without taking any Bitcoin fees and makes all mining data public.

I expect the idea of sub-pools within P2Pool to become more popular as P2Pool gets bigger. It is obvious from the AntPool code that this is what they do also.

Looks like lady luck is paying us a visit.

I found this quote from forrestv in /etc/newsyslog.conf:
(newsyslog rotates logs so programs don't have to)

cat /home/P2Pool/sighup.sh

That's good to know.  I haven't tried p2pool since recently with my limited hashrate.

M

The number 1 issue is fixed with latest firmware, which runs cgminer 4.6.1.  When the work restart request comes in, I usually see the flush work within 1 second, then the new block task usually arrives in another second.  Often there are new accepted shares submitted within 2 seconds of the work restart request.  The new cgminer 4.6.1 has brought new life to the S2.  I used to point the S2's to a different pool, while all my other miners used P2Pool.  It's so nice to see them doing the full 1000 GH/s with P2Pool.  I have 2x S2's and 2x C1's, and all 4 of them run neck-and-neck.

From my testing of my S1s and S2s on my home grown proxy, Ants have two significant problems with p2pool:

1 - They can't restart work fast enough.  Supposedly the latest S2 firmware addresses this, but I have not tried it.  I can't imagine them fixing it entirely, but I could see it being much better than it was.  That means every 30 seconds when p2pool tells your miners "hey, stop what you're doing and start over with this data instead!", it takes a few seconds for the Ant to do so.  In those few seconds there's a good chance it'll submit a share that is no longer valid.  In the S2s case, it was a lot more than a few seconds, and if the work restarted back to back in less than 30 seconds, it quickly gets out of hand.

2 - This is what pertains to your question.  It also can't respond to share size changes that quickly.  If you don't fix the share size, p2pool will at some point increase the minimum share size required, and your Ant can't stop what's it's doing fast enough to switch and then ends up submitting a share that's undersized.  This is what generates the somewhat confusing "share submitted larger than difficulty" message in p2pool.  That said, this is all pseudo share stuff, missing this share really doesn't matter.  It'll just mess with your stats.  It may also decrease your throughput, as your Ant has to switch gears, although I would suspect it's not as bad as the "stop and restart" message I refer to in part 1.

M

I don't think I can articulate the value of incoming peers, but I will try. Their value is sharing information on shares, transactions, blocks, and should help reduce stales and reduce your orphans.  Something like that.  I'm sure someone will correct me.  :-)

For p2pool, set queue to 0.  This is still being debated.  Some say 1.  I've done my own testing and 0 works best for me.  I don't have any hard data to share.  I still add --expiry 1 --scan-time 1, but people tell me those don't matter anymore and were for GPU's.  But...  I still set them out of habit.    I also sent you a PM yesterday.  I would set pseudo share to +518.  For some reason, when you use +512, the UI will not show Best Share, and I like to see the best share on each miner.  +518 was also recommended by the people working on Antpool P2P.  And they recommend +1028 for the S2.  I also use +1028 for the C1's.  And I use +2240 for my S4's.  All my graphs look better this way. 

That's good advice on the upnp, I could swear I had it disabled but, now that I think about it I'm not sure I reconfigured it the last time they swapped my broken modem.  I'll see if it lets me disable it on this one, and forward the port.

Do you know what value is added when having incoming peers?  I mean, is it a matter of being a good netizen or, is there some technical value to it?

I'm playing with the cgminer command now, noticed --queue 4096, which according to some others is way too high.  I set my --queue to 1 and my miners now have a load average of ~1.6 as opposed to 2+ load when it was set to 4096.  Hashrate and temperature seems the same, seems a little more responsive now when I ssh in.  Any ideas on the queue size?

Anyone have an Antminer S3 cgminer command tuned for p2pool they care to share?

Having incoming peers does add value, but also increases your network and CPU utilization.  The increase is not that much, but something to be aware of.  If you have incoming connections and did not specifically port forward, then that means your router has UPnP enabled.   I typically recommend disabling UPnP on routers because it is a security risk, but it is also a convenience and you may have other applications using UPnP.  If you do not want p2pool to use UPnP, then add --disable-upnp to your startup command.  bitcoind will also use uPnP by default and can be disabled with upnp=0.

If you want cgminer and the charts in P2Pool to report the hashrate you are expecting, then you should set it.  If you don't care about those things, then don't set it.  As far as share solving, it doesn't matter.   I don't like seeing my hashrate jump from 25% of it's advertised rate to 200% it's advertised rate.   It drives me crazy, so I set the pseudo share and my graphs and monitor tools look good.

I found setting diff made no difference whatsoever - so I just let my node decide & run the antminers normally. Works fine 

Looking into the pseudo share difficulty setting ( SomeWalletAddress+512 ), it seems meaningless to configure, especially when running a local p2pool node.  So, now I'm confused as to why Bitmain says to set the share difficulty on Antminer S3 to 512 in their FAQ, their answer leads me to believe they don't actually understand what that value represents.  After removing the +512 my local node is assigning difficulties in the range of 500-800, is my node calculating which difficulty to give me based on the total hashrate of my miners, or the hashrate of each individual miner, or something completely different? 

If I calculate this based on a couple other sites rule of thumb, I get a difficulty around 3016 for my total hashing power, and 522 for per miner.  I don't see why the p2pool node should care about a setting based on per miner, I mean what's the difference from the view of the p2pool node if I have one 2TH miner, or four 500GH miners? It seems like the the difficulty assigned should be for the whole of the hashing power.

From Bitmain FAQ:
" AntMiners support p2pool. Static difficulty configuration recommended.
Since p2pool adjusts the difficulty frequently, therefore would bring hash rate loss when the difficulty changes at any time. As a result is that AntMiners' hash rate may be a little lower than that released officially when they are mining in p2pool.
We suggest you configure a static difficulty for AntMiner, when you mine in p2pool. Recommended difficulty is 256 or 512.

2. How to configure a static diff when AntMiner mines in p2pool?
Through ‘Status->Miner Configuration‘, configure Pool Worker as 'BTC address/256+256' or 'BTC address+256'.
"

One of my S2's just found a massive share - 3,095,261,251 !! Biggest one I ever mined - on an S2 as well! 



Block solver, gotta be........

It does not rotate it, however it is capped at a certain size, I think 100MB.

No, you can just run another instance from the same directory.

Helps finding peers, but you seem to be doing fine - so I'd leave it as is.

Not sure what you mean by the third question though, sorry 

Do I need to copy the p2pool code to a second directory to run a second instance?

And some other questions,

What is the advantage for me in opening port 9333 on my firewall, and why would p2pool tell me I have incoming peers when I don't have the port open?  "Peers: 18 (12 incoming)"  I know the port is currently closed to the outside, maybe my modems firewall allows established connections like my iptables?

Does p2pool ever rotate data/bitcoin/log ?

It isn't my pool, but NastyPool has always operated as a default p2pool node with 0% fee.  You don't need to own a NastyFans seat to mine on it or see your stats, even now with the new -PPS option.  If you did want the benefits of owning a NastyFans seat, they can be purchased currently for ~0.01 BTC.  That's hardly a boys club that only privileged are given access to.  I'm sorry you feel that way.



Fair enough, although you wouldn't be the one executing the code so even seeing it wouldn't be proof enough for you to switch to NastyPool.  Independent testing would be the only thing that would convince we are truly operating fairly with a 0% fee.

I'm happy to test it on my node and my main point of asking that was are you willing to share your efforts to benefit everyone. I looked at your pool way back but couldn't see how i could use it since all memberships were filled and you had to be a member to mine on it apparently. Nasty always to me seemed a boys club that only the privileged are given access to so I gave up on it.

Give it time  

People are wary of closed source mining software, and rightly so. Personally, I won't touch anything that's not open source, which was one of the reasons I chose p2pool in the first place. I'm not for one moment suggesting that your software isn't kosher, & I congratulate you on your efforts - I just prefer to see what code I'm using, as do most others  

I'm sure you'll get some testers soon, and look forward to seeing the results  

I find it interesting that all of the communications I've received so far are asking if there are plans to give this development away, but nobody has even tried mining on our node with it yet.