My predicted payout went from .06 to .25. Sounds good to me, but what gives?
Topic: [1500 TH] p2pool: Decentralized, DoS-resistant, Hop-Proof pool - page 189. (Read 2591920 times)
April 25, 2015, 12:29:06 PM
My predicted payout went from .06 to .25. Sounds good to me, but what gives?
April 25, 2015, 12:24:48 PM
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.
April 25, 2015, 12:23:44 PM
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
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
April 25, 2015, 12:23:15 PM
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?
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
April 25, 2015, 11:38:28 AM
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?
April 25, 2015, 09:54:14 AM
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"?
I'm not sure why your hash rate would drop by 90%, but the queue setting is not the cause.
April 24, 2015, 11:55:18 PM
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
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
April 24, 2015, 11:21:13 PM
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"?
April 24, 2015, 07:27:23 PM
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
April 24, 2015, 06:02:43 PM
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/cgminerHowever, 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!
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.
April 24, 2015, 05:50:08 PM
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/cgminerHowever, 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!
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.
April 24, 2015, 03:27:19 PM
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/cgminerHowever, 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!
April 24, 2015, 09:59:06 AM
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?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?
I'm not sure if kano/ck have built a cgminer binary for the S5... if they have, then I'd suggest using theirs.
April 24, 2015, 08:27:57 AM
Anyone know why im getting this fault?
user@ubuntu:~$ bitcoin-cli getblockcount
error: {"code":-28,"message":"Verifying blocks..."}
Thanks
That's what it does when bitcoind or bitcoin-qt first starts up.user@ubuntu:~$ bitcoin-cli getblockcount
error: {"code":-28,"message":"Verifying blocks..."}
Thanks
Nothing to be concerned about then?
Thanks
April 24, 2015, 08:24:34 AM
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?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?
April 24, 2015, 02:19:40 AM
Anyone know why im getting this fault?
user@ubuntu:~$ bitcoin-cli getblockcount
error: {"code":-28,"message":"Verifying blocks..."}
Thanks
That's what it does when bitcoind or bitcoin-qt first starts up.user@ubuntu:~$ bitcoin-cli getblockcount
error: {"code":-28,"message":"Verifying blocks..."}
Thanks
Nothing to be concerned about then?
Thanks
April 24, 2015, 02:14:56 AM
Anyone know why im getting this fault?
user@ubuntu:~$ bitcoin-cli getblockcount
error: {"code":-28,"message":"Verifying blocks..."}
Thanks
That's what it does when bitcoind or bitcoin-qt first starts up. user@ubuntu:~$ bitcoin-cli getblockcount
error: {"code":-28,"message":"Verifying blocks..."}
Thanks
April 24, 2015, 02:14:15 AM
Anyone know why im getting this fault?
user@ubuntu:~$ bitcoin-cli getblockcount
error: {"code":-28,"message":"Verifying blocks..."}
Thanks
user@ubuntu:~$ bitcoin-cli getblockcount
error: {"code":-28,"message":"Verifying blocks..."}
Thanks
April 23, 2015, 11:51:05 PM
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?I don't get this problem with Eligius pool. Also, I get much higher hashrates with Eligius, which seems strange to me.
April 23, 2015, 02:58:19 PM
interesting ... 
Jump to: