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

[jonnybravo0311]

Code:

Local: 1946GH/s in last 5.8 minutes Local dead on arrival: ~37.2% (35-39%) Expected time to share: 4.0 hours

Why is my "Local dead on arrival" so high?

Update: It just now improved:

Code:

Local: 2017GH/s in last 10.0 minutes Local dead on arrival: ~1.8% (1-4%) Expected time to share: 3.8 hours

Was it just "adjusting" or something?

Update: p2pool casuse my S5 to lock up after a certain amount of time! Why?
I don't get this problem with Eligius pool. Also, I get much higher hashrates with Eligius, which seems strange to me.

Update #3: I corrected this issue by (1) making each of my miners mine to a separate user and (2) adding these options to `cgminer`:
--queue 0 --failover-only --expiry 1 --scan-time 1

Are these good settings?

The queue setting is the one that will make the difference.  The others won't help you.  Also, you should use --submit-stale since by default the cgminer binaries in the Ants all throw away stale work, which is a very bad thing for p2pool.

I'm not sure if kano/ck have built a cgminer binary for the S5... if they have, then I'd suggest using theirs.

[1714023577]

1714023577

[1714023577]

1714023577

[1714023577]

1714023577

[1714023577]

1714023577

[Geremia]

The queue setting is the one that will make the difference.  The others won't help you.  Also, you should use --submit-stale since by default the cgminer binaries in the Ants all throw away stale work, which is a very bad thing for p2pool.

Okay, thanks; I'll try "--submit-stale" and see if that improves things.
Update: It appears `cgminer` doesn't have a "--submit-stale" option. I think my S5s build (and ck's, too) submits stales by default because there is a "--no-submit-stale" option.

I'm not sure if kano/ck have built a cgminer binary for the S5... if they have, then I'd suggest using theirs.

Yes, he does: http://ck.kolivas.org/apps/cgminer/antminer/s5/4.9.0-150105/cgminer

However, ck's version doesn't have a "--btc-address" option for solo mining. Is there a way to solo-mine with ck's version?

Update: Wow, I'm getting up to 2.54 Thash/s (as reported by P2Pool) with two S5s and ck's cgminer 4.9. Thank you, jonnybravo0311!

[jonnybravo0311]

The queue setting is the one that will make the difference.  The others won't help you.  Also, you should use --submit-stale since by default the cgminer binaries in the Ants all throw away stale work, which is a very bad thing for p2pool.

Okay, thanks; I'll try "--submit-stale" and see if that improves things.
Update: It appears `cgminer` doesn't have a "--submit-stale" option. I think my S5s build (and ck's, too) submits stales by default because there is a "--no-submit-stale" option.

I'm not sure if kano/ck have built a cgminer binary for the S5... if they have, then I'd suggest using theirs.

Yes, he does: http://ck.kolivas.org/apps/cgminer/antminer/s5/4.9.0-150105/cgminer

However, ck's version doesn't have a "--btc-address" option for solo mining. Is there a way to solo-mine with ck's version?

Update: Wow, I'm getting up to 2.54 Thash/s (as reported by P2Pool) with two S5s and ck's cgminer 4.9. Thank you, jonnybravo0311!

If you're going to solo mine, just point the miners to solo.ckpool.org.  Not really worth trying to solo mine directly to the coin daemon, so there's really no need for the --btc-address parameter.  If you really want to do it yourself, then you'd be better off setting up your own instance of ckpool; however, unless you're well connected you run a high risk of submitting an orphaned block, and seeing that 25BTC go down the drain would really suck.

I swear I read from ck/kano that the Bitmaintech fork of cgminer tossed stale work... and that was one of the reasons to use the binary from them instead of Bitmain's.

[-ck]

The queue setting is the one that will make the difference.  The others won't help you.  Also, you should use --submit-stale since by default the cgminer binaries in the Ants all throw away stale work, which is a very bad thing for p2pool.

Okay, thanks; I'll try "--submit-stale" and see if that improves things.
Update: It appears `cgminer` doesn't have a "--submit-stale" option. I think my S5s build (and ck's, too) submits stales by default because there is a "--no-submit-stale" option.

I'm not sure if kano/ck have built a cgminer binary for the S5... if they have, then I'd suggest using theirs.

Yes, he does: http://ck.kolivas.org/apps/cgminer/antminer/s5/4.9.0-150105/cgminer

However, ck's version doesn't have a "--btc-address" option for solo mining. Is there a way to solo-mine with ck's version?

Update: Wow, I'm getting up to 2.54 Thash/s (as reported by P2Pool) with two S5s and ck's cgminer 4.9. Thank you, jonnybravo0311!

If you're going to solo mine, just point the miners to solo.ckpool.org.  Not really worth trying to solo mine directly to the coin daemon, so there's really no need for the --btc-address parameter.  If you really want to do it yourself, then you'd be better off setting up your own instance of ckpool; however, unless you're well connected you run a high risk of submitting an orphaned block, and seeing that 25BTC go down the drain would really suck.

I swear I read from ck/kano that the Bitmaintech fork of cgminer tossed stale work... and that was one of the reasons to use the binary from them instead of Bitmain's.

Yes that is correct. The --submit-stale option was removed from cgminer something like 3 years ago and it was made default to submit stale. What bitmain did was they unnecessarily added even more stale test code in their driver and deleted stale submissions. Only the firmwares/binaries myself and kano made do not do that. Anyone mining on p2pool with bitmain hardware should not be using their firmwares.

[Geremia]

The --submit-stale option was removed from cgminer something like 3 years ago and it was made default to submit stale. What bitmain did was they unnecessarily added even more stale test code in their driver and deleted stale submissions. Only the firmwares/binaries myself and kano made do not do that. Anyone mining on p2pool with bitmain hardware should not be using their firmwares.

All I know is that I'm hashing faster with your build, -ck, than the default Bitmain one; so, even though Bitmain's build reported 0 stale shares, I'm pretty sure I was getting some, as P2Pool reported lower hash rates then, too.

thanks again, -ck

[Geremia]

The queue setting is the one that will make the difference.

How does "--queue 0" speed up P2Pool?

The hashrate on one of my S5s just plummeted down about ~90%. Could this be because I set "--queue 0"?

[roy7]

In celebration of forrestv merging in the extended API stats pull request, I spun up an old server, refreshed everything, and got a public node online to try it out. And since I don't mine any more, I rented some hash power to make the stats fill in.

With baseline p2pool and the devel branch of p2pool-node-status we end up with this:

http://us-east.royalminingco.com:9332/static/

The extended API stats is what allows the per-miner "time to share" info to appear on the interface under the active miners section. It also shows the difficulty target of work last served out to the miner (to earn a share, not to be confused with pseudo difficulty for hash rate calculations).

All miners on the node would be served the same difficulty target in base p2pool, you'd need to apply my vardiffbyaddress patch to make it so small miners work on the lowest difficulty allowed whereas bigger miners have the variable difficulty based on their hashrate. Back in the day on alt coins, it was very cool to watch small miners have lower targets than big miners. (That was the whole motivation for doing it.)

And while supply lasts... bonus fun things!

Graph of share chain difficulty: http://us-east.royalminingco.com/p2pool_share_history/
Geographic map of my p2pool peers: http://us-east.royalminingco.com/map.php

[jonnybravo0311]

The queue setting is the one that will make the difference.

How does "--queue 0" speed up P2Pool?

The hashrate on one of my S5s just plummeted down about ~90%. Could this be because I set "--queue 0"?

Setting the queue to 0 means the miner doesn't have a whole bunch of stale work to complete when p2pool tells it to start fresh.  You are not speeding up p2pool, you are having your miner work on relevant data in a timely fashion.  By default, the Ants set the queue to some absurdly high numbers.  The release of cgminer by ck sets it to 1 by default.

I'm not sure why your hash rate would drop by 90%, but the queue setting is not the cause.

[OgNasty]

Yes, he does: http://ck.kolivas.org/apps/cgminer/antminer/s5/4.9.0-150105/cgminer

How do you use this?  Do you update it the same way you would update the s5 firmware?  Anyone want to point me in the right direction of some instructions?

[jonnybravo0311]

Yes, he does: http://ck.kolivas.org/apps/cgminer/antminer/s5/4.9.0-150105/cgminer

How do you use this?  Do you update it the same way you would update the s5 firmware?  Anyone want to point me in the right direction of some instructions?

ssh into your S5
cd /usr/bin
mv cgminer cgminer.old
wget http://ck.kolivas.org/apps/cgminer/antminer/s5/4.9.0-150105/cgminer
chmod +x cgminer
Reboot

[MissouriMiner]

Yes, he does: http://ck.kolivas.org/apps/cgminer/antminer/s5/4.9.0-150105/cgminer

How do you use this?  Do you update it the same way you would update the s5 firmware?  Anyone want to point me in the right direction of some instructions?

I just run a little script, which I think I copied from someone here.  Note that files stored in /config are persistent.  

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

[MissouriMiner]

My predicted payout went from .06 to .25.  Sounds good to me, but what gives?   I'm seeing 111.18384982 BTC total to be paid.

[jonnybravo0311]

My predicted payout went from .06 to .25.  Sounds good to me, but what gives?

No clue... I'm seeing the same thing.  All predicted payouts are off.  Look at the top 2 miners... their combined expected payout is over 34BTC.

[Geremia]

Yes, he does: http://ck.kolivas.org/apps/cgminer/antminer/s5/4.9.0-150105/cgminer

How do you use this?  Do you update it the same way you would update the s5 firmware?  Anyone want to point me in the right direction of some instructions?

Use an SSH client to SSH into the S5.

Here's what I did under Linux, at the command-line:

Code:

ssh root@<your_S5's_local_IP_address>

Enter "admin" for the password.
Now you'll be at a prompt that says "root@<your_AntMiner's_hostname>:~#".
Type

Code:

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

If ever the S5 reboots, you'll have to do this process again, since the new cgminer is in volatile memory.

Another thing to do is set "--queue 0":

Code:

vi /etc/init.d/cgminer.sh

Change "--queue $queue_value" on line 69 to "--queue 0".
(If you're not familiar with how to edit files in vi, check this out.)
Basically, you can use your arrow keys to go to line 69, type "i" to go into "insertion mode", which allows inserting and deleting text. When you've made the correction, hit the ESC key and then type ":wq".
Run

Code:

/etc/init.d/cgminer.sh restart

again to make the changes take effect.

-ck's cgminer version 4.9 is really an improvement over cgminer 4.8 in Bitmain's firmware. You can be certain stales are being submitted and not ignored. Ever since I started using it, I've been getting blazing fast, stable hash rates (1.2 Thash/s per S5 average) and DOAs about ⅓ the average, pool rate. I also ceased having the strange ramping-down / plumetting hashrate issues some have reported cgminer having with S5s.

[Geremia]

My predicted payout went from .06 to .25.  Sounds good to me, but what gives?   I'm seeing 111.18384982 BTC total to be paid.

My predicted payout went from .06 to .25.  Sounds good to me, but what gives?

No clue... I'm seeing the same thing.  All predicted payouts are off.  Look at the top 2 miners... their combined expected payout is over 34BTC.

Maybe someone gave a big donation to P2Pool users? Do donations even add into the payout that way? I thought donations were sent directly to P2Pool users, not to the pool, unless there's another way to donate than mentioned in "Donating to P2Pool miners."

[OgNasty]

If ever the S5 reboots, you'll have to do this process again, since the new cgminer is in volatile memory.

That might be a deal breaker for me.  I appreciate your response, but I don't think this is a reasonable approach for a larger farm.  I will do some testing on my more stable units though thanks to your guide.  I do wish bitmain would open source their firmware so that an easier and more permanent solution could be implemented.

EDIT: I went ahead and updated my s5's to the latest cgminer.  I don't see why the version wouldn't stick after a restart, but we'll see...

[jonnybravo0311]

My predicted payout went from .06 to .25.  Sounds good to me, but what gives?   I'm seeing 111.18384982 BTC total to be paid.

My predicted payout went from .06 to .25.  Sounds good to me, but what gives?

No clue... I'm seeing the same thing.  All predicted payouts are off.  Look at the top 2 miners... their combined expected payout is over 34BTC.

Maybe someone gave a big donations to P2Pool users?

No, you would have gotten the transaction in your wallet if it were a donation.  Things seem to be back to normal now.  Weird.

[Geremia]

If ever the S5 reboots, you'll have to do this process again, since the new cgminer is in volatile memory.

That might be a deal breaker for me.  I appreciate your response, but I don't think this is a reasonable approach for a larger farm.  I will do some testing on my more stable units though thanks to your guide.  I do wish bitmain would open source their firmware so that an easier and more permanent solution could be implemented.

You might be able to edit Bitmain's firmware file and make your own custom firmware. I'm not sure.

[jonnybravo0311]

If ever the S5 reboots, you'll have to do this process again, since the new cgminer is in volatile memory.

That might be a deal breaker for me.  I appreciate your response, but I don't think this is a reasonable approach for a larger farm.  I will do some testing on my more stable units though thanks to your guide.  I do wish bitmain would open source their firmware so that an easier and more permanent solution could be implemented.

Is that something new with the S5?  I have S3s and replacing the binary is certainly not in volatile memory.  I've heard that changes you make to the init.d scripts might get lost on reboot.

In any case, couldn't you just write a simple script to execute on boot that does these steps?  Or would any script you write also get lost on the reboot?  There's got to be some place that's not lost on a reboot...

[windpath]

My predicted payout went from .06 to .25.  Sounds good to me, but what gives?   I'm seeing 111.18384982 BTC total to be paid.

My predicted payout went from .06 to .25.  Sounds good to me, but what gives?

No clue... I'm seeing the same thing.  All predicted payouts are off.  Look at the top 2 miners... their combined expected payout is over 34BTC.

Maybe someone gave a big donations to P2Pool users?

No, you would have gotten the transaction in your wallet if it were a donation.  Things seem to be back to normal now.  Weird.

My guess is you had this TX in your node unconfirmed TX pool:

https://blockchain.info/tx/860e4e6bc2b846f00a1660dcb49d84a00dcd7b87ba23100e836dfb682249a807

Over 85 BTC in miner fees, AntPool got the block, it was not an intentional fee...

http://www.reddit.com/r/Bitcoin/comments/33u2id/help_losing_over_85_btc_because_of_bitgos_flawed/