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

Again, I have no problem with my s5's.  I migrated right from the S1 to S5 on P2Pool.

Maybe it would improve with a change in the software, but my average take and status is well above estimates on any BTC calculator.

I make less on Slush's pool than P2Pool.

Maybe I'm missing something.

I remember there was a bounty out there to see if anyone could connect S1 boards to use an rPi as the controller... not sure how that ever turned out.  Also, you might want to check out sidehack's BM1384 project.  They're trying to build their own miner based on the chips in the S5.  I think they're designing their own PCBs, so it's not a direct "take Bitmain board and use different controller".

Why would that be a problem?

the only problem of miner ... is the linux card.
not the chip or the supply.

that why USB miner don't have any problem ... on P2Pool.

  question : can i connect an bitmain product in USB without the linux card controller ?

What about Bitmain hardware makes "stop everything you're doing" hard?

You got it.  The reason is because of the share-chain shares in p2pool.  Approximately every 30 seconds (averaged, it could be 1 second, it could be 100), a new share is added to the share chain.  P2Pool broadcasts the "stop everything" message every time this happens.  In a traditional pool, that "stop everything" message only comes once a block is found.  Traditional pools will broadcast new work, i.e. they've just done a GBT call and created a new chunk of work for miners, but they don't force a restart, they'll still accept the old work from the miner.

Edit:

The only cases where p2pool behaves differently is when a miner submits a share that solves a block of BTC.  A dead share is work that a miner was doing on a previous set of work after the node has accepted a newer share on the chain.  If that share solves a block, it gets submitted and if accepted, miners are paid based on the information in that share.

This is also why sometimes you'll see a p2pool mining transaction in your wallet, but your node UI doesn't show the block.  Since that share never made it onto the share chain, the UI doesn't see it.

Bitmain hardware is awful.  IMHO the last good hardware they made were the S1s.  Everything from there has gone downhill.

As others have correctly stated, p2pool "restarts" the work a lot more often than "conventional" pools.  In layman's terms, the conversation between your miner and p2pool goes something like this:

p2pool: here is some work, stop everything you are doing and start working on this
miner: got it, I'll start working on it as soon as possible
(avg 30 seconds later): p2pool: here is some work, stop everything you are doing and start working on this
miner: got it, I'll start working on it as soon as possible

and so forth.  That "stop everything you're doing" part is what Bitmain hardware sucks at doing.  Spondoolie hardware seems to manage it just fine.  As always, YMMV.  Some folks have luck tweaking their S2/S3/S4/S5/Swhatever, sometimes regularly.  I never had any luck with it, and have long since given up on Bitmain junk hardware.

For comparison, conventional pools look like this:

pool: here is some work, switch when you can, I'll continue accepting your prior work for a while
miner: got it, I'll start working on it as soon as possible
pool: here is some work, switch when you can, I'll continue accepting your prior work for a while
miner: got it, I'll start working on it as soon as possible
pool (approx ~10 mins): here is some work, stop everything you are doing and start working on this

M

I've posted quite a few times in their thread asking them to remove the references to p2pool.  They don't.  Thankfully one of the mods (I believe it was -ck) changed their thread title to get rid of the bogus "supporting decentralization" claim it spouted.  I completely disagree with dogie's statements about it being a "lost in translation" thing.  Bitmain took forrest's code and added some database stuff to it.  They didn't create their own implementation, or attempt to fix any of the variance problems.  Whatever they did was certainly not the $100,000s effort claimed, and they abandoned it since they realized they didn't know what they were doing.

I'm having no problems with my S5's.   I'm running the Jan 2015 firmware.    I did have some anomoly recently where my shares just fell off without new ones, but a restart turned that around quickly.

Ironically, I've tried to upgrade to the latest May firmware, but keeping getting an error that the tar file is too short.   Perhaps this is a blessing in disguise?

What exactly is happening with the firmware that has hurt P2Pool mining?

While block frequency continues to be a problem with the P2Pool, I'm consistently doing better than expected in block yields with my hardware.

The network hashrate variation, also ironically, is actually advantageous for those who stay on the network 24/7, as share difficulty goes down in the 1-1.5 PH/s range, whereas blocks are found in the 2-3 PH/s range.

Staying around for the low Hashrate times builds up the shares, so when the Hashing returns to the pool, those who stayed are rewarded.

Of course, when the pool goes 3 days without a block, not so much, although this cycle actually makes the accumulation of shares even better for those who stick around.

If the hashing never returns, however, all bets are off.

my miners worked hard regardless & whoalla a block

BITCOIN BLOCK FOUND by 15zwKLxCfkoqUnffm3P9Mcj1Xu3XW61oKS! https://blockchain.info/block/0000000000000000084571719129943432b15a6c41a854c4db6f5ebcfa9693a8

Thank you -ck & kano for chiming in, your experience & knowledge is greatly appreciated    I've read a lot about this subject throughout the thread, it seems to me that bitmain are actually working against p2pool, despite their claims in their pool thread that they actively support it:


This is simply not true. Shouldn't forum rules/admins require them to change this statement? Doing so would also save a lot of confusion for new users of p2pool who wonder why they can't get the most out of their bitmain hardware while using p2pool. They seem to be trying to transfer p2pools unique decentralised nature for their own marketing needs - despite being an obviously centralised pool.

As bitmain refuse to fix their firmware (or more likely - they're unable/don't know how to), I'd be more than willing to chip in towards a bounty for a revised & fully functional S5 firmware for p2pool - if kano/-ck would be willing? The S5's are still being sold, & will remain workable for a while yet I think, so it would certainly boost p2pools attractiveness to new users if they could simply connect & mine like any other pool.  What do you think?

Tak.

Regarding them considering how to make their hardware work:
I've pointed it out to many manufacturers - Bitmain included - but they seem to think that whoever in their company who is designing how their hardware works, has the only answers on how it should work.
Pity, I made this ... free ... post long ago and have even updated it a few times ...
https://bitcointalksearch.org/topic/optimal-firmwarehardware-design-for-mining-with-cgminer-294499

The U3 is a good example of ignoring pretty much all of that post

It's not a direct answer to the above issue of work restart, but shows that they don't listen ...

-ck is right. Because the p2pool share chain expected time to share is 30 seconds vs. the bitcoin block chain expected time to block of 10 mins p2pool sends work restarts to miners far more often then solo mining or a centralized pool.

Well designed miners can handle this work restart load, some are overwhelmed by it, the S2 was for sure. I've never tested an S5 but best guess is the results are the same:

It chokes on frequent work restarts.

Is this a bitmain design flaw? Yes
Does most of their hardware contain this flaw? No, S2 and S5.
Could they fix it? Yes.
Will they? No.

Edit: Originally listed S3, S3 works fine, changed to S2 which has been known to have similar problems to what is reported with S5.

Why?

Okay, this answers my question:But does it have to?

Not clear or concise enough? Perhaps if I quote myself louder?

But why would that be unique to P2Pool? I just switched over to Eligius pool, and I'm not getting any of those issues.

I just explained precisely that... it's the fluctuations in current required during restarts and it has 10x more restarts than regular pooled mining.

I'm beginning to blame all these P2Pool issues on Python. Let's face it; Python is a turtle compared to C.

Anyone interested in porting P2Pool to C? I seem to remember someone advocating that, or perhaps they've even begun implementing it.

Why is "p2pool's workload" "much harder on the asics…" etc.?

p2pool's workload is much harder on the asics with much more frequent restarts which is when the current through the asics can vary dramatically depending on the design. More frequent fluctuations of voltage and/or current make for a much harder workload on the asics so you end up having to clock them lower.