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

I don't understand your math.

Current diff as reported by p2pool is 5.9mil, not 6.5mil, meaning 47 instead of 52.  
Yesterday the diff was lower, it increased overnight with the block adjustment.
I don't understand where you're coming up with the 32mil after day 2.
This sample size is 1.5 days total, not 2.  I only counted the last 27 shares in my last post, not the full 54 over the past 1.5 days, but I'm going to assume it's equally proportional.

Yes.

M

dude look at them number close they are no where near what they should be for an s1 diff 1 share rate.......      the 1st group has hit at less than a share each in 1.5 days    and it get worst from there I rest my case    


8 * 6.5 mil =   5200000 diff 1 share    for that 1st group of 12 miners they should be around 32000000 diff 1 share at the end of day 2 they are about 26 mil shares down atm vs ya mining a normal pool...... diff 1 share wise  so there a huge loss there atm vs mining at a normal pool

Are these still current and correct?

The last 27 shares found on my node (out of 52 total for 1.5 day uptime):

8 shares - S1 group 1
5 shares - S1 group 2
5 shares - S1 group 3
9 shares - Terraminer group

Very appropriately proportional.  Roughly 7TH/s for the S1's, roughly 3TH/s for the Terraminers.  2:1 hash ratio, 2:1 share ratio.

This is regularly stated here, however it only holds true *if* bitcoin difficulty remains the same.  Which it doesn't, so therefore it's false.

If your luck averages out over the difficulty period, then yes, it will.  However, the lower your hashrate, the less likely it is to average out over a fixed period of time (a given difficulty period).  The higher the difficulty, the worse it gets.

M

hash rate they may be out doing the 2 terra's but earning wise what happening may pay to look at how many shares they are putting in ......   in theory on a s1 you should hit around 16mil diff 1 shares every 2 days on normal mining pools    that is 2-3 shares p2 wise they are luck to hit 1 so off your example above 3 by 12 ants = 36 ant miners in total you should be seeing around 90 odd share every 2 days between them or there abouts to be on par with their diff 1 share rate and that the issue they are hitting no where near their diff 1 share rates......

I don't necessarily agree with this statement, although I don't have empirical data to back it up.  Hashrate is hashrate, it should even out in the end.  Even if you don't get a share today in this block, your share will count for the next block and you would get a payout then.
This is patently false.  I have 3 groups of 12 S1's running "together", meaning they are all using the same miner address, for a total of roughly 2.4TH/s per group.  Each group of S1's is completely out-performing the group of 2 Terraminers I have with a slightly higher hashrate.  I can show the graphs to prove it.

Dude that easy to see 1st hand lol that /0 is a manual diff setting override try this and watch what happens on ya miner diff....   1st set to 7500000 watch ya miner diff rise above the node diff and set at 7.5mil....     Then set any number under the current node diff eg 4mil it will default to the min node diff as it will NOT allow you to set a diff under the current min diff of the node share rate so basically a 0 setting or a 4mil or 5 mil setting is going to gave a min diff or the node at 6.5 .....

I'd say you're right on target, although your DOA rate seems a little high:

Version: 13.4-40-gce9e5a2
Pool rate: 1.67PH/s (13% DOA+orphan) Share difficulty: 6320000
Node uptime: 1.5 days Peers: 6 out, 0 in

Local rate: 8.65TH/s (2.7% DOA) Expected time to share: 52.3 minutes

Shares: 50 total (4 orphaned, 2 dead) Efficiency: 101.2%

Payout if a block were found NOW: 0 BTC to . Expected after mining for 24 hours: 0.130 BTC per block.

Current block value: 25.15205561 BTC Expected time to block: 14.1 hours

I'm a little over double your hashrate, and double your payout, it adds up.

And yes, a month ago my payout rate was higher (.18/day on BTCGuild), due to 2 things - first the pool rate was under 1PH/s with 100 less miners, and we've had at least 2 diff increases since then (last one happened overnight).  Unfortunately the pool rate has grown enough to down our earnings due to more total hashrate but we've been unlucky in not seeing enough of an increase in blocks yet to offset it.  However I believe the numbers are properly in-line for what has happened.

As more hashpower is added to the pool, payouts amounts will decrease in size, but payout frequency will increase.  It should balance out.  Also keep in mind overall Bitcoin difficulty keeps increasing, although not quite as much per jump as it used to.

M

This is running 16 s-1's
Version: unknown 7032706f6f6c2d6e2d6d6173746572

Pool rate: 1.67PH/s (13% DOA+orphan) Share difficulty: 6520000

Node uptime: 2.8 days Peers: 6 out, 0 in

Local rate: 3.99TH/s (6.6% DOA) Expected time to share: 2.0 hours

Shares: 44 total (4 orphaned, 0 dead) Efficiency: 104.5%

Payout if a block were found NOW: 0.0698682 BTC to xxxxxxxxxxxxxxxxxxxxxxxxxxx. Expected after mining for 24 hours: 0.0691 BTC per block.

Current block value: 25.084773600000002 BTC Expected time to block: 14.1 hours
_______________________________________________________________________________ __________________________

Any opinions?
I think I am finding a good amount of shares, its just that the blocks are not paying enough.
If we had a few more blocks it would be better??
But we really are not.

1 month ago my payouts were 0.14xxxxxxx

Show me the proof in the code that it does so.  I have linked multiple places in the code that completely contradict this statement.  All I've gotten back so far is, "based on my personal experience" and other anecdotal evidence.  As is the saying, "Show me the money!" Someone show me where setting the address to /0 sets share difficulty to p2pool minimum share difficulty by quoting the actual CODE from p2pool (and not some modified version of the code like the vardiff patch or some scrypt coin) from forrestv github.

As I wrote a number of times a few pages back, manually setting the share difficulty only makes sense if you're mining on a node where there is a very large discrepancy between your hash rate and the total hash rate of the node.  For example, if you were to bring a 180GH/s miner to a node with 10TH/s, set that S1s difficulty manually.  The same holds true going the other way.  If you're bringing 10TH/s to a node with 1TH/s, set your share difficulty HIGHER than the default p2pool share value.  I even provided a way for you to calculate what you should set it to to get an average of 1 share an hour.

Regarding your comments on the minimum requirements to join p2pool, you've hit it pretty much dead on accurate.  If you want to ensure you've got a good chance of having a share on the chain for every block found, that means you're going to need enough hardware to find a share every 12 hours or so.  Currently the share difficulty is 6.5M.  So, to find 2 shares a day, you'd need just about 650GH/s.

Your statement about the hardware to bring to the party is incorrect, though.  It's not like a dragon or an S2 is somehow better at finding shares than an S1 is.  Hash rate is hash rate, no matter how you get there.

How do that has been hashed and re-hashed here.  If you decrease the share difficulty, you increase the time between job restarts.  Right now it's at 30 seconds, which I believe is what causes the problem with S2s and likely other ASIC hardware.  Those that have been with p2pool for a while will remember that it used to be 10 seconds, and it was changed to 30 seconds because 10 seconds was way too short for ASICs.

I don't believe this "more hashrate means higher share difficulty means harder for smaller miners" problem is solvable with the current p2pool design.

That's why I suggested a new design not that long ago.  If I was single, didn't have two kids, and wasn't working on moving across the country I'd try to code my design a proof of concept, and maybe become the new p2pool author. 

Alas, I barely have time to do what I need to do anymore, let alone what I'd like to do.

M

I think what flound getting at here is the diff issue as that hash rate goes up the diff will also keep rising and knocking more and more rigs off the face the earth of hitting shares unless ya running mining farms.....     Think of it in terms of the BTC diff the more hash added the faster the blocks are found the higher the diff rises....    The same issue applies here to P2POOL as that hash rate keeps rising that share diff will keep going up as the find times will be faster....     What someone needs to do somewhere down the line is change the amount of shares from what is is 3000 odd per block   to a larger number eg 12000 odd per block to match the rise in the hash rate on the network to bring it back down diff wise on the shares to gave the smaller miner a chance of hitting the shares as they once were able to do when the hash rate was low..... And in flound case been multipool they would have a mix of rigs in that 250 ths from small to large and if the s1 and s3 can not hit shares now and they make up alot of the network harsh rate on the btc what it going to be like in a pool double the hash it is today.

eg 3.6 ph   that would mean a diff off 13 mill +

What do you mean by handle the load?  It's at 1.81PH/s right now, share difficulty is at 6.5 million.  If you've got hardware that works with p2pool, this is as good as it gets right now.

M

also further to this current talk in here lol the /0 command sets to the bear min of the share diff on the miner as per the node diff so if the diff is 5mil for example it set the diff to 5mil   if it 7mil it sets to 7mil....      

But on saying this that /0 command can be used to set a diff higher than the min diff only for example if the diff was 5mil    you can set ya rig to a diff via the / number command to say 7.5 mil   eg /7500000   if this set under the current share diff on the nodes it defaults to the min diff on the node eg if you set it for 2.5 mil for example and the current diff was 5mil for a share it would default to the min diff of 5mil as that 2.5mil setting is below the current diff of 5mil
 

I have sat back and read a few pages now of this....   I going to add my bit here lol....   I will start of saying I use to mine on p2pool with s1 ants...  It used to be good when the share diff was around 1mil use to hit a few each day...

But I left the p2pool set up when the diff shoot up to 2.5 mil as was not hitting share often enough vs a normal bitcoin pool and found the normal bitcoin pools were out doing the p2 earning wise....  

Now after sitting back for the last 2 days and watching the ants vs the diff of the p2 of 5 mil I would of hit a total of 1 shares for the 2 days on 3 ants so glad I moved the ants off P2 when I did a couple months back ......    

Unless you are running 1th rigs forgot p2pool as you will earn no where the amount you would on a normal pool...

A few may want to try this experment above on their rigs and take note of ya best shares vs the p2 share diff and it will wake a few up to why ya not hitting shares....   As I said here unless ya running 1th + rigs these days p2 will hurt ya earnings wise from my testing over the last couple days.

Ps by 1th rigs I mean 1th rigs eg s2 ants knc eg   and not 4-5 s1 ants or 2-3 s3's to get that 1th figure

Try this one:
https://github.com/johndoe75/p2pool-node-status

Its similar to the one from coincadence at the node level. In fact he links to it at the bottom of the node page (click "Node Stats Front-end" to see it). I use it in a subdirectory of the regular extended one and it works just fine.

It would be great if someone could take p2pool over and make it perform better and address the issues.  I would move Multipool's ~250TH back to BTC p2pool in a heartbeat if it could handle the load.