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

[Richy_T]

Guys, I don't know what's going on but I haven't had a payout in a long time. I think P2Pool version has moved on and I'm sitting mining on my own. I haven't had the time to pay attention recently but every time I've looked at the p2pool screen, it's been happily scrolling along with no apparent warnings. I have no problem with upgrades, I have no problem with obsoleting versions but when we do it, could we make it a bit more obvious, please? It's one thing to pay out more or less than other pools but if you're not paying out at all, that's going to put a dent in things pretty quickly. This is not a demand, just a courteous request. I don't have --give-author set to 0 so you're sharing the love.

[1714126353]

1714126353

[1714126353]

1714126353

[1714126353]

1714126353

[1714126353]

1714126353

[1714126353]

1714126353

[forrestv]

Guys, I don't know what's going on but I haven't had a payout in a long time. I think P2Pool version has moved on and I'm sitting mining on my own. I haven't had the time to pay attention recently but every time I've looked at the p2pool screen, it's been happily scrolling along with no apparent warnings. I have no problem with upgrades, I have no problem with obsoleting versions but when we do it, could we make it a bit more obvious, please? It's one thing to pay out more or less than other pools but if you're not paying out at all, that's going to put a dent in things pretty quickly. This is not a demand, just a courteous request. I don't have --give-author set to 0 so you're sharing the love.

In the days before the switch, your P2Pool instance would have been displaying a lot of messages and warnings about the impending change, but once it's happened, your instance is alone with only the other nodes that didn't upgrade and there's no easy way for it to know that it should have upgraded. (I suppose it could see that there are lots of peers with higher version numbers that refuse to talk to it...)

You should subscribe to the mailing list mentioned in the first post if you don't obsessively monitor your P2Pool daemon.

[zkfq12345]

” Graphs

Version: 13.3

Pool rate: 15.9TH/s (12% DOA+orphan) Share difficulty: 70300

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

Local rate: 389GH/s (14% DOA) Expected time to share: 0.216 hours

Shares: 1246 total (183 orphaned, 184 dead) Efficiency: 80.54% “


my speed is  82g,but in p2pool.info it show  my speed is  66g !

does everyone knows about my speed is slower?

why it show :  Efficiency: 80.54%  and  66g ?

[rav3n_pl]

80% of 82G is ~66G...

[nibor]

Mining with 60Ghash so fine at moment.

At what point would it better for my variance if the pool split into 2?

Currently 2hrs to get a share and 8 for pool to get a block.

Once the pool is getting blocks 3 times more often than I get a share (so I miss out on some payments) would it at that point be benifical for me for the pool to split into 2?

[maqifrnswa]

Mining with 60Ghash so fine at moment.

At what point would it better for my variance if the pool split into 2?

Currently 2hrs to get a share and 8 for pool to get a block.

Once the pool is getting blocks 3 times more often than I get a share (so I miss out on some payments) would it at that point be benifical for me for the pool to split into 2?

ok, i'll take a shot - this is an approximation, I'm not 100% sure it's analytically correct but it may be close at least...

assuming each share solved a day has the same value (i.e., constant pool rate, constant difficulty across the day)

Payout events per day = the number of shares you find times the number of shares the pool finds, per day.

number of shares you find = your_rate/pool_rate*2880 +/- sqrt(your_rate/pool_rate*2880)
number of blocks pool solves = pool_rate/network_rate*144 +/- sqrt(pool_rate/network_rate*144)

number of payout events in a day=your_rate/network_rate*414720
variance in payout events = sqrt(your_rate/pool_rate*2880+pool_rate/network_rate*144)

variance has a minimum when pool_rate=20*sqrt(your_rate*pool_rate)

for a 5 GH/s miner, optimal p2pool hash rate is around 50 TH/s
60 Gh/s, optimal p2pool hashrate is around 175 TH/s

i did this on a cell phone, so there probably are errors, but I think it's all there

I know of one: payout events per day is actually
(# of shares found in a window = 3x the work needed for one block)/(length of a window)

However, our window is now 1 day long, approximately on average, so the above approximation holds for the time being

[gnar1ta$]

Well Jupiters don't play well with p2pool.  They remind me of the early BFL FPGAs, they are extremely slow to recover when they get new work.  Anyone have any settings to to try out?

[lenny_]

Well Jupiters don't play well with p2pool.  They remind me of the early BFL FPGAs, they are extremely slow to recover when they get new work.  Anyone have any settings to to try out?

What's exact stats you're getting? How many DOA?

[jamesg]

Well Jupiters don't play well with p2pool.  They remind me of the early BFL FPGAs, they are extremely slow to recover when they get new work.  Anyone have any settings to to try out?

What's exact stats you're getting? How many DOA?

I am seeing higher stale rates from KNC equipment so it looks like they are not flushing work when the stratum server requests but are instead finishing old work and submitting it.

[gnar1ta$]

Right it's not DOA and stales, when it's pushed new work it takes 10 seconds or more to flush and come back up to speed. The miner reports 300 Ghash and the pool reports 350. Not a huge issue on 10 min blocks, but not very good on 30 sec work.

[lenny_]

Christ.... we have another BE BLADE situation here? Can't they do proper LP/work restart implementation? 

[Richy_T]

You should subscribe to the mailing list mentioned in the first post if you don't obsessively monitor your P2Pool daemon.

Thanks. I'll do that. I've just dropped to another pool until I can get it sorted but I'm a fan of the p2pool concept.

[-ck]

Christ.... we have another BE BLADE situation here? Can't they do proper LP/work restart implementation? 

That's what happens when... ah fuck it I'm sick of saying the same shit every time. You all know the drill by now.

[gnar1ta$]

lol...but we just love to hear you say it Con 

[jamesg]

lol...but we just love to hear you say it Con 

Worst thing KNC has done was to not include Con in their efforts.

Such a shame. 

[kano]

lol...but we just love to hear you say it Con 

Anyone seen any GPL3 source code yet?

[gnar1ta$]

Here you go, 24 unproductive hours with a Jupiter on p2pool  (.93 firmware)

[HellDiverUK]

Nice to see that totally unproductive 0.3BTC in your payout queue. 

[kano]

Here you go, 24 unproductive hours with a Jupiter on p2pool  (.93 firmware)



https://i.imgur.com/DcIYr1i.png

https://i.imgur.com/Y17eq5S.png

https://i.imgur.com/mJRwRJr.png

Hmm calculation time on your picture
Elapsed = 96511s
Accepted = 7963136 1diff shares
Rejected = 166912 1diff shares
Hardware errors = 657472 1diff nonces

So Accepted hash rate is 2^32 * Accepted / Elapsed
354.4GH/s

Full hash rate (Accepted + Rejected) is 2^32 * (Accepted + Rejected) / Elapsed
361.8GH/s

Only one minor comment on those - you can only count the Rejected in the device GH/s if KnC hasn't fucked with the submit_nonce() code and also you can verify that by seeing why the shares were Rejected.
As far as I know there's been no sign of the GPL3 code as should have been given to anyone with a KnC who asks for it ... and it must have all versions of the code asked for.

Gee ... I wonder if I'll have another Kano vs GitSyncom ... what'll it be called this time ... Kano vs KFC
Nom nom.

Anyway, now for the fun numbers there ...
Hardware % = Hardware / (Accepted + Rejected + Hardware)
7.48%
which, BTW, is 29.3GH/s of hardware errors

Well at least it's less than the original 16% when they were boasting about how good it was ... lolololol

Now ... what are these things supposed to be doing?

I'm sure I saw them boasting in that video how they were doing 500GH ... how did it that boasting go ... ?
"... Back in May we promised you 250 ... well it's not 250
Then we upped it to 300 ... it's not 300
In June we said 350. We published that on the web site ... it's not 350 (tears paper in half)
In August we said 400 ... well it's not 400 (screws up the page and throws it on the floor)
We have a 500 machine here for you today and as evidence of the 500 machine we have a laptop in front of us running a full copy of cgminer.
We can see here that we are actually achieving, on average, over 500
In fact the theoretical limit is 576+
576 gigahashes a second and it's fully working and we start shipping today ..."

Interesting definition of "fully working" ...

So do you feel like telling them to go fuck themselves about the red comments for your hardware?

I will add they failed to see that it wasn't even showing 500GH/s on the screen as I pointed out here:
https://bitcointalk.org/index.php?topic=170332.msg3276727#msg3276727

But of course the most important point being firstly that they seem to think that cgminer showing that on the screen is all the proof they needed.
Yay cgminer

Pity they wrote the driver and fucked up cgminer's reputation ... well ... we didn't have anything to do with their driver code.

[matthewh3]

Here you go, 24 unproductive hours with a Jupiter on p2pool  (.93 firmware)



https://i.imgur.com/DcIYr1i.png

https://i.imgur.com/Y17eq5S.png

https://i.imgur.com/mJRwRJr.png

Hmm calculation time on your picture
Elapsed = 96511s
Accepted = 7963136 1diff shares
Rejected = 166912 1diff shares
Hardware errors = 657472 1diff nonces

So Accepted hash rate is 2^32 * Accepted / Elapsed
354.4GH/s

Full hash rate (Accepted + Rejected) is 2^32 * (Accepted + Rejected) / Elapsed
361.8GH/s

Only one minor comment on those - you can only count the Rejected in the device GH/s if KnC hasn't fucked with the submit_nonce() code and also you can verify that by seeing why the shares were Rejected.
As far as I know there's been no sign of the GPL3 code as should have been given to anyone with a KnC who asks for it ... and it must have all versions of the code asked for.

Gee ... I wonder if I'll have another Kano vs GitSyncom ... what'll it be called this time ... Kano vs KFC
Nom nom.

Anyway, now for the fun numbers there ...
Hardware % = Hardware / (Accepted + Rejected + Hardware)
7.48%
which, BTW, is 29.3GH/s of hardware errors

Well at least it's less than the original 16% when they were boasting about how good it was ... lolololol

Now ... what are these things supposed to be doing?

I'm sure I saw them boasting in that video how they were doing 500GH ... how did it that boasting go ... ?
"... Back in May we promised you 250 ... well it's not 250
Then we upped it to 300 ... it's not 300
In June we said 350. We published that on the web site ... it's not 350 (tears paper in half)
In August we said 400 ... well it's not 400 (screws up the page and throws it on the floor)
We have a 500 machine here for you today and as evidence of the 500 machine we have a laptop in front of us running a full copy of cgminer.
We can see here that we are actually achieving, on average, over 500
In fact the theoretical limit is 576+
576 gigahashes a second and it's fully working and we start shipping today ..."

Interesting definition of "fully working" ...

So do you feel like telling them to go fuck themselves about the red comments for your hardware?

I will add they failed to see that it wasn't even showing 500GH/s on the screen as I pointed out here:
https://bitcointalk.org/index.php?topic=170332.msg3276727#msg3276727

But of course the most important point being firstly that they seem to think that cgminer showing that on the screen is all the proof they needed.
Yay cgminer

Pity they wrote the driver and fucked up cgminer's reputation ... well ... we didn't have anything to do with their driver code.

I've got a Jupiter mining on Slush but one of its boards died on a firmware update.  Tho still with only three of the four chips I'm getting an average of 400GH over ten rounds on Slush.