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

[kwukduck]

fixed... no idea why it doesn't work well with diablominer but oh well..

Code:

Local: 637MH/s in last 10.0 minutes Local dead on ar
rival: ~1.1% (0-7%) Expected time to share: 56.4 minutes

The reward is still low but i'm sure it will go up after running for a bit.

[1714246383]

1714246383

[1714246383]

1714246383

[1714246383]

1714246383

[1714246383]

1714246383

[twmz]

Some changes have been made to p2pool.info to slightly improve the performance of the page load:

• The hashrate graph and the stats API (http://p2pool.info/stats) only include one data point per hour instead of one per 5 minutes.  If someone needs/wants the 5 minute data, it still exists in the database (and still gets used behind the scenes), they can contact me and we'll work something out.
• The block list only shows blocks for the past 90 days.  If you want to see blocks older than that, you'll need to use the API (see the next point)
• The blocks API (http://p2pool.info/blocks) also only returns the last 90 days of blocks by default, but you can get all blocks by adding a parameter to the request: http://p2pool.info/blocks?all=true

[mdude77]

After running on a pool for 12 hours or so i noticed that also the pool only registers about half of my speed. So i changed my miner, guess what, looking much much better now! I'm going to try on p2pool now see what it does.

I was using DiabloMiner, now changing to CGMiner.

You know.. I've observed similar with phoenix.  Phoenix tells me one thing, everything else receiving the data from Phoenix tells me something else.  The apparent higher hash rate is why I use phoenix on my 5870s, but cgminer's output matches what the pools (including p2pool) tell me.  So... I tend think phoenix is lying.

M

[mdude77]

Come to think of it, since the pool seems to fluctuate between 200g/h and 300g/h, there's either something funny going on or a lot of people are shorting themselves.

well, mine varies based on outside temperature and if i'm using my main computer or not, from 2500-6000, i've got another 2000mhash or so, but p2pool doesn't like my hub and the computers that use it get like 50% reject rates.

but i did finally decide to just buy a switch, prolly get here on mon or tues

Wouldn't you do better with something like pps from ozcoin if you are varying that much?  You're shorting yourself in p2pool because it's based on the last 24 hours.

M

[kjj]

After running on a pool for 12 hours or so i noticed that also the pool only registers about half of my speed. So i changed my miner, guess what, looking much much better now! I'm going to try on p2pool now see what it does.

I was using DiabloMiner, now changing to CGMiner.

You know.. I've observed similar with phoenix.  Phoenix tells me one thing, everything else receiving the data from Phoenix tells me something else.  The apparent higher hash rate is why I use phoenix on my 5870s, but cgminer's output matches what the pools (including p2pool) tell me.  So... I tend think phoenix is lying.

M

No, phoenix is actually measuring the actual hashrate of the card.  Everything else is an estimate, and all of the estimates are based random proxies, and all of the proxies have means less than 100% of the actual hashrate (over infinite time).

[Ente]

Wouldn't you do better with something like pps from ozcoin if you are varying that much?  You're shorting yourself in p2pool because it's based on the last 24 hours.

M

Shouldn't you get a proportional payout nevertheless? Like 1gh/s which runs 12h a day sould give you the same as 500mh/s on 24/7? You receive payments for blocks for the next 24 hours for that.
As long as we don't dip into extremes (super long block round, super low hashrate or the like) it shouldn't do any harm?

Ente

[organofcorti]

Every share submitted has exactly the same expected value as any other share. The only difference changing the length of the inclusion bracket would be to change the variance. For example, increasing the length of the inclusion bracket (to say 48 hours) would decrease variance - at the cost of taking longer to get the full value out of each share. With an infinite inclusion bracket, you would have zero variance (same as PPS) with the only downside being you'd have to wait an infinite amount of time to get paid. Picking an inclusion bracket is a trade of between variance and maturity time. A low variance DGM like Ozcoin's is less stressful for low hashrate miners than pure PPLNS.

[kano]

After running on a pool for 12 hours or so i noticed that also the pool only registers about half of my speed. So i changed my miner, guess what, looking much much better now! I'm going to try on p2pool now see what it does.

I was using DiabloMiner, now changing to CGMiner.

You know.. I've observed similar with phoenix.  Phoenix tells me one thing, everything else receiving the data from Phoenix tells me something else.  The apparent higher hash rate is why I use phoenix on my 5870s, but cgminer's output matches what the pools (including p2pool) tell me.  So... I tend think phoenix is lying.

M

No, phoenix is actually measuring the actual hashrate of the card.  Everything else is an estimate, and all of the estimates are based random proxies, and all of the proxies have means less than 100% of the actual hashrate (over infinite time).

cgminer's hash rate is correct.
For BFL and GPU it is simply a count - no estimate involved at all.

I've seen some code around that doesn't 'count' hashes but estimates them -
I'd be curious to know which miners do actually count the numbers ...
(look in the code yourself if you want to be sure ...)

The only estimate anywhere in the cgminer code is my icarus code that estimates the number of hashes done when it aborts work that didn't find a share (since Icarus will not report a value)
Any software that hashes on an Icarus must do this estimate.

However, that estimate is also correct in cgminer since it is based on the correct value of the performance of the bitstreams (and anyone who wants to challenge it can even ask cgminer to verify it with --icarus-timing)

[megatron]

After running on a pool for 12 hours or so i noticed that also the pool only registers about half of my speed. So i changed my miner, guess what, looking much much better now! I'm going to try on p2pool now see what it does.

I was using DiabloMiner, now changing to CGMiner.

i got exactly same problem,

for a few days my reward from block reduced from ,2 btc to 0,13btc and p2pool.info says my hashrate 683mh but in real its ~950mh.

my hw works for 24/7 with low stale rate (4.1% DOA).
mining sw - guiminer(poclbm)
so what changed in last few days?

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

[racerguy]

After running on a pool for 12 hours or so i noticed that also the pool only registers about half of my speed. So i changed my miner, guess what, looking much much better now! I'm going to try on p2pool now see what it does.

I was using DiabloMiner, now changing to CGMiner.

i got exactly same problem,

for a few days my reward from block reduced from ,2 btc to 0,13btc and p2pool.info says my hashrate 683mh but in real its ~950mh.

my hw works for 24/7 with low stale rate (4.1% DOA).
mining sw - guiminer(poclbm)
so what changed in last few days?

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

There's a huge variance involved when estimating your hashrate based on the number of p2pool shares you've produced in the last 24hrs.  Yesterday my hashrate based on p2pool share production was 350mhs and today it's 129mh/s for a 5770 that cgminer says is averaging 200mh/s, I wouldn't rely on speed estimates based on p2pool share production unless it's over the last week or something.  Also just looking at your stats page it says you have no incoming connections, you need to forward the p2pool port on your router to reduce stales.

[rav3n_pl]

Use week stats

[kano]

...
There's a huge variance involved when estimating your hashrate based on the number of p2pool shares you've produced in the last 24hrs.  Yesterday my hashrate based on p2pool share production was 350mhs and today it's 129mh/s for a 5770 that cgminer says is averaging 200mh/s, I wouldn't rely on speed estimates based on p2pool share production unless it's over the last week or something.  Also just looking at your stats page it says you have no incoming connections, you need to forward the p2pool port on your router to reduce stales.

Acutally, I've never seen it 'that' huge on any rig.
As I usually say regarding cgminer, given an hour and about 400-800 MH/s, you should be within about 10%
(I think I've only once ever seen close to 10% after an hour)

If one of the stats guys ... organofcorti? ... wants to actually work out the expected % and given confidence levels (say 99%, 99.9% or even 99.99%) accurately (and provide an equation) then we could see how reasonable what I suggest is

But your figures of a variance of over ~75% and ~35% for 24 hours at 200MH/s seem rather ... unlikely ... to be share variance
(since they are diff 1 shares)

[racerguy]

...
There's a huge variance involved when estimating your hashrate based on the number of p2pool shares you've produced in the last 24hrs.  Yesterday my hashrate based on p2pool share production was 350mhs and today it's 129mh/s for a 5770 that cgminer says is averaging 200mh/s, I wouldn't rely on speed estimates based on p2pool share production unless it's over the last week or something.  Also just looking at your stats page it says you have no incoming connections, you need to forward the p2pool port on your router to reduce stales.

Acutally, I've never seen it 'that' huge on any rig.
As I usually say regarding cgminer, given an hour and about 400-800 MH/s, you should be within about 10%
(I think I've only once ever seen close to 10% after an hour)

If one of the stats guys ... organofcorti? ... wants to actually work out the expected % and given confidence levels (say 99%, 99.9% or even 99.99%) accurately (and provide an equation) then we could see how reasonable what I suggest is

But your figures of a variance of over ~75% and ~35% for 24 hours at 200MH/s seem rather ... unlikely ... to be share variance
(since they are diff 1 shares)

p2pool shares aren't diff 1 shares they're around 400-600.

[rav3n_pl]

"Local rate" is calculated form diff1 shares
"Local rate reflected in shares" is calculated from share chain shares
Miner is showing actual GPU rate.
There CAN be difference, all depends on LUCK.
If UR lucky you can have many diff1 shares and very few pool shares
If UR VERY lucky you will have lots of pool shares and calculated rate will be higher than real rate.
If UR really unlucky you will not have any share in 24hrs and get 0 btc each block

[kano]

...
There's a huge variance involved when estimating your hashrate based on the number of p2pool shares you've produced in the last 24hrs.  Yesterday my hashrate based on p2pool share production was 350mhs and today it's 129mh/s for a 5770 that cgminer says is averaging 200mh/s, I wouldn't rely on speed estimates based on p2pool share production unless it's over the last week or something.  Also just looking at your stats page it says you have no incoming connections, you need to forward the p2pool port on your router to reduce stales.

Acutally, I've never seen it 'that' huge on any rig.
As I usually say regarding cgminer, given an hour and about 400-800 MH/s, you should be within about 10%
(I think I've only once ever seen close to 10% after an hour)

If one of the stats guys ... organofcorti? ... wants to actually work out the expected % and given confidence levels (say 99%, 99.9% or even 99.99%) accurately (and provide an equation) then we could see how reasonable what I suggest is

But your figures of a variance of over ~75% and ~35% for 24 hours at 200MH/s seem rather ... unlikely ... to be share variance
(since they are diff 1 shares)

p2pool shares aren't diff 1 shares they're around 400-600.

The miner reports diff 1 shares since p2pool tells it to.
I think the term used is psedo-shares.

[organofcorti]

If one of the stats guys ... organofcorti? ... wants to actually work out the expected % and given confidence levels (say 99%, 99.9% or even 99.99%) accurately (and provide an equation) then we could see how reasonable what I suggest is

But your figures of a variance of over ~75% and ~35% for 24 hours at 200MH/s seem rather ... unlikely ... to be share variance
(since they are diff 1 shares)

Just a quick response, and I could be wrong, but it seems to me that the number of shares accepted in a given time period is best described as a Poisson distributed variable.

At 200 Mhps, we expect to find the following number of shares:
D400 shares = 200 * 1e06 / 2^32 / 400 *3600 * 24 ~ 10
D400 shares = 200 * 1e06 / 2^32 / 400 *3600 * 24 ~ 6.7

So to find the probability 95% confidence intervals for the local hashrate (as calculated using R):

Code:

> qpois(0.025,6.7)*600*2^32/3600/24/1e06
[1] 59.65232
> qpois(0.925,6.7)*600*2^32/3600/24/1e06
[1] 328.0878
> qpois(0.025,10)*400*2^32/3600/24/1e06
[1] 79.53643
> qpois(0.925,10)*400*2^32/3600/24/1e06
[1] 298.2616
> 

So at D400, you'd expect to see a local hashrate between 59 and 328 Mhps with 95% confidence, and at D600 you'd expect to see a local hashrate between 79 and 298 Mhps. The standard deviation is about 63 Mhps at D400 and  77 Mhps at D600, with a mean and median of 200 Mhps.

There's much more variance than you might expect as you increase local D significantly compared to hashrate. The standard deviation varies with the square root of the mean submitted shares per day,so the higher the D, the lower the hashrate and the larger the square root of the hashrate (standard deviation) becomes closer to the mean.

tl;dr: The lower the local hashrate is for a given D,  the larger the variability in local hashrate you'll see reported by the pool.

[zvs]

i encountered the bizarre issue with all the DOA shares again after a peer joined:







any clues?   exact same thing that happened last time.   closed + reopened and it fixed it.

[rav3n_pl]

Limit connections to 30 or 20:
--max-conns 30

[mdude77]

i encountered the bizarre issue with all the DOA shares again after a peer joined:

I've observed this twice now as well, but I never figured out that it was related to a peer joining.

The first time, it caused one my cgminer instances to go beserk and submit endless stales.
Last time, just this morning, my phoenix instance did it. 
Like you, restarting the miners and p2pool fixed it.

p2pool bug or attack?

M

[Soros Shorts]

Limit connections to 30 or 20:
--max-conns 30

But there were about only 20 connections on his chart (10 outgoing and 10 incoming).

It's got to be something else.