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

[jonnybravo0311]

That everyone updated their gear to S7s, but because they did now p2pool doesn't find any blocks because those same S7s throw away potential solutions?

Sure... I suppose that could be one of the reasons... but it certainly isn't the only one .

[wariner]

Runs fine yes, but the bitmain driver throws away what could be potential block solves on p2pool...

the problem is only for s7? or even s5 - s3....?

There is a discussion that contains all modified antminer drivers for p2pool?

.. but it certainly isn't the only one .

Do you think it's just bad luck or other?

[AndreyNag]

What Forrest thinks about this situation? His help here is very needed!
All want hear him here.
I think that need rewriting of p2pool sources whith multicore computing support.

[-ck]

Runs fine yes, but the bitmain driver throws away what could be potential block solves on p2pool...

the problem is only for s7? or even s5 - s3....?

There is a discussion that contains all modified antminer drivers for p2pool?

Except for Kano's firmware and my drivers for S1-3, all antminer S* cgminer forks from bitmain have the same driver design flaw. We mention it at regular intervals but it keeps getting forgotten or lost in the discussion by p2pool miners...

[p3yot33at3r]

Runs fine yes, but the bitmain driver throws away what could be potential block solves on p2pool...

the problem is only for s7? or even s5 - s3....?

There is a discussion that contains all modified antminer drivers for p2pool?

.. but it certainly isn't the only one .

Do you think it's just bad luck or other?

Antminer binaries:   http://ck.kolivas.org/apps/cgminer/antminer/

Bad luck, rising diff, crap firmware, lack of hash power - all of these are contributory factors I'm afraid, although bad luck & high diff affects all pools, not just p2pool.

[wariner]

Antminer binaries:   http://ck.kolivas.org/apps/cgminer/antminer/

thank you

I have 3 s5 ... you can write me the command ssh for install?

ty

What Forrest thinks about this situation? His help here is very needed!
All want hear him here.
I think that need rewriting of p2pool sources whith multicore computing support.

+1

[p3yot33at3r]

Antminer binaries:   http://ck.kolivas.org/apps/cgminer/antminer/

thank you

I have 3 s5 ... you can write me the command ssh for install?

ty

S5 binary install:

Code:

cd /tmp
wget http://ck.kolivas.org/apps/cgminer/antminer/s5/4.9.0-150105/cgminer
chmod +x cgminer
mv /usr/bin/cgminer /usr/bin/cgminer.bak
cp cgminer /usr/bin
/etc/init.d/cgminer.sh restart

This is NOT persistent - re-do after reboot.

Or you can use this firmware version:

https://www.dropbox.com/s/a3qqhgh3awcrw1i/SD-S5-20150107_cgm_4_9_0-queue_1_submit.tar.gz?dl=0

Which is persistent through reboots.

[wariner]

ty but fan go to 100%....normal?

[p3yot33at3r]

ty but fan go to 100%....normal?

Only on startup, then it calms down  otherwise re-do it.

[sawa]

Runs fine yes, but the bitmain driver throws away what could be potential block solves on p2pool...

the problem is only for s7? or even s5 - s3....?

There is a discussion that contains all modified antminer drivers for p2pool?

Except for Kano's firmware and my drivers for S1-3, all antminer S* cgminer forks from bitmain have the same driver design flaw. We mention it at regular intervals but it keeps getting forgotten or lost in the discussion by p2pool miners...

Maybe does not make sense to do firmware forks for S *, so we are constantly catching up and more and more losing hashrate.
Now it is so small that it can be said that p2pool is dead.
And many of those who get ASICs, can never replace firmware and failing on p2pool they switch to a another type of pools.

Maybe it's time  for develpers to join and modify and adapt it for the new ASICs? Perhaps it's needed to rewrite it on C, as in Python it loads only one core and often on 100%
We need creative solutions, or this topic can be closed and we should stop our nodes and move to antpool, f2pool and etc.

[jonnybravo0311]

Runs fine yes, but the bitmain driver throws away what could be potential block solves on p2pool...

the problem is only for s7? or even s5 - s3....?

There is a discussion that contains all modified antminer drivers for p2pool?

.. but it certainly isn't the only one .

Do you think it's just bad luck or other?

The problem is for ALL Antminers unless you have installed the proper binaries from -ck and kano.  If you are using any other binaries (Bitmain's, some other forks for extranonce, etc) then you do not have the updated code that submits stale shares.  In other words, you are potentially throwing away possible block solutions.

As to your other question regarding luck... yes, I believe it is just poor luck.  We are experiencing normal swings in variance.  As I initially mentioned, S7s are certainly a potential influencing factor since there are no (to my knowledge, -ck/kano can correct me) updated cgminer binaries for it.  However, I don't know how many people currently mining on p2pool are using S7s, so I don't have any reference for how much of an impact it might have .

[jonnybravo0311]

Runs fine yes, but the bitmain driver throws away what could be potential block solves on p2pool...

the problem is only for s7? or even s5 - s3....?

There is a discussion that contains all modified antminer drivers for p2pool?

Except for Kano's firmware and my drivers for S1-3, all antminer S* cgminer forks from bitmain have the same driver design flaw. We mention it at regular intervals but it keeps getting forgotten or lost in the discussion by p2pool miners...

Maybe does not make sense to do firmware forks for S *, so we are constantly catching up and more and more losing hashrate.
Now it is so small that it can be said that p2pool is dead.
And many of those who get ASICs, can never replace firmware and getting out on p2pool they switch to a another type of pools.

Maybe it's time  for develpers to join and modify and adapt it for the new ASICs? Perhaps it's needed to rewrite it on C, as in Python it loads only one core and often on 100%
We need creative solutions, or this topic can be closed and we should stop our nodes and move to antpool, f2pool and similar.

We should absolutely not, in any way, shape or form, EVER move to AntPool or f2pool.  Not only are those pools way too big as it is, but they are also poorly written and take shortcuts that are bad for Bitcoin.  In case you don't remember, they caused a fork in BTC earlier this year precisely because of their shoddy software and mining practices.

As to your other points, we've discussed numerous times rewriting p2pool in a language that can handle multiple threads.  Thus far, nobody's stepped up to take on that challenge.  Even so, rewriting the pool code in C or some other language will not handle the underlying problem of crappy cgminer forks not submitting shares which could be solving blocks.

[wariner]

ty but fan go to 100%....normal?

Only on startup, then it calms down  otherwise re-do it.

solved with this
https://www.dropbox.com/s/a3qqhgh3awcrw1i/SD-S5-20150107_cgm_4_9_0-queue_1_submit.tar.gz?dl=0

thank you, and thank you -ck for this version

[sawa]

Runs fine yes, but the bitmain driver throws away what could be potential block solves on p2pool...

the problem is only for s7? or even s5 - s3....?

There is a discussion that contains all modified antminer drivers for p2pool?

Except for Kano's firmware and my drivers for S1-3, all antminer S* cgminer forks from bitmain have the same driver design flaw. We mention it at regular intervals but it keeps getting forgotten or lost in the discussion by p2pool miners...

Maybe does not make sense to do firmware forks for S *, so we are constantly catching up and more and more losing hashrate.
Now it is so small that it can be said that p2pool is dead.
And many of those who get ASICs, can never replace firmware and getting out on p2pool they switch to a another type of pools.

Maybe it's time  for develpers to join and modify and adapt it for the new ASICs? Perhaps it's needed to rewrite it on C, as in Python it loads only one core and often on 100%
We need creative solutions, or this topic can be closed and we should stop our nodes and move to antpool, f2pool and similar.

We should absolutely not, in any way, shape or form, EVER move to AntPool or f2pool.  Not only are those pools way too big as it is, but they are also poorly written and take shortcuts that are bad for Bitcoin.  In case you don't remember, they caused a fork in BTC earlier this year precisely because of their shoddy software and mining practices.

I agree with you, but most people do not understand this.

As to your other points, we've discussed numerous times rewriting p2pool in a language that can handle multiple threads.  Thus far, nobody's stepped up to take on that challenge.  Even so, rewriting the pool code in C or some other language will not handle the underlying problem of crappy cgminer forks not submitting shares which could be solving blocks.

I'm not sure, but why don't we raise funds for the development team that can do this (maybe it's a bad idea).
I think we should act more active rather than passively wait for volunteers.

[p3yot33at3r]

ty but fan go to 100%....normal?

Only on startup, then it calms down  otherwise re-do it.

solved with this
https://www.dropbox.com/s/a3qqhgh3awcrw1i/SD-S5-20150107_cgm_4_9_0-queue_1_submit.tar.gz?dl=0

thank you, and thank you -ck for this version

This version is not -ck's, but it is using the mainline cgminer.

[wariner]

This version is not -ck's, but it is using the mainline cgminer.

ah ok! but fix the problem with p2pool, true?!

[p3yot33at3r]

I'm not sure, but why don't we raise funds for the development team that can do this (maybe it's a bad idea).
I think we should act more active rather than passively wait for volunteers.

This has also been discussed many times in the past, but finding a coder willing to step up (huge task) as well as people who are willing to donate has proven impossible unfortunately. I've read through this thread many times & it seems some users think that either there is no need for development because it's perfect already, or that it is some kind of crime to even think about it - so nothing happens & miners go elsewhere.

**waits for torrent of abuse**

[jonnybravo0311]

I'm not sure, but why don't we raise funds for the development team that can do this (maybe it's a bad idea).
I think we should act more active rather than passively wait for volunteers.

This has also been discussed many times in the past, but finding a coder willing to step up (huge task) as well as people who are willing to donate has proven impossible unfortunately. I've read through this thread many times & it seems some users think that either there is no need for development because it's perfect already, or that it is some kind of crime to even think about it - so nothing happens & miners go elsewhere.

**waits for torrent of abuse**

I don't think it's that people think it's perfect already... it's that people haven't come up with a better way to do it.  A number of ideas have been thrown around, but none solve the problems inherent in the system.  As much as we all want p2pool to represent a larger percentage of the network hash, if it were to do so, then the miners would experience more and more variance as share difficulty rose.  Nobody's been able to come up with a way to manage that, and nobody's willing to simply translate the pool code from python to C.  Heck, windpath even started a bounty months ago to get some work done.  Nobody took him up on the offer.

[p3yot33at3r]

Yeah, I read about that. Unfortunately it seems it's easier/cheaper/less risky for miners just to up & leave instead of being prepared to "chip in" towards a long-term improvement - which at the rate the diff is rising, I can't say I blame them 

[jonnybravo0311]

I think the vast majority of miners that leave p2pool do so because they can't deal with the variance.  It's also why pools like AntPool and f2pool continue to grow.  Less variance... regular payouts... regardless of how bad they are for the network.