Topic: [1500 TH] p2pool: Decentralized, DoS-resistant, Hop-Proof pool - page 259. (Read 2591928 times)
November 29, 2014, 10:53:46 AM
Im trying to run my 1 t/h rig i follow the steps and it says there are no workers or my url is wrong which i pointed my rig to my laptop IP becuase thats where i am running the programs off of. if anyone could help me out i would greatly appreciate it !
November 29, 2014, 10:38:42 AM
i have no idea why but i am having the most difficult time trying to join this pool!!
What specifically is the issue? (provide error messages, log details, etc...) Are you running your own node, or trying to mine on another node? If you have not read it already, you may want to read the P2Pool Wiki. https://en.bitcoin.it/wiki/P2Pool
November 29, 2014, 10:23:40 AM
i have no idea why but i am having the most difficult time trying to join this pool!!
November 29, 2014, 05:13:23 AM
In other words: Hi, I have no idea what the fuck you're talking about in any depth because my grasp of the English language isn't good enough. We good do you by me bitcoin.
I'm half way through switching my gear over to SP-Tech, I just grow tired of Bitmain not listening to either you guys or p2pool users - & their latest fiasco with their own version of p2pool was the last straw for me.
I'm totally sold on these SP20's too - they just work.
November 29, 2014, 04:19:45 AM
This is what they answered from bitmain of new s4 ive ordered to umisoo hosting when i asked about this prob.
"Hi,
no worries, we've updated the firmware.Our antpool is open public and you may try with solo.antpool.com to try. it's more stable than p2pool.
Engineers are still working on the popool issue to get it more stable:)"
In other words: Hi, I have no idea what the fuck you're talking about in any depth because my grasp of the English language isn't good enough. We good do you by me bitcoin. "Hi,
no worries, we've updated the firmware.Our antpool is open public and you may try with solo.antpool.com to try. it's more stable than p2pool.
Engineers are still working on the popool issue to get it more stable:)"
November 29, 2014, 03:44:16 AM
The number 1 issue is fixed with latest firmware, which runs cgminer 4.6.1. When the work restart request comes in, I usually see the flush work within 1 second, then the new block task usually arrives in another second. Often there are new accepted shares submitted within 2 seconds of the work restart request. The new cgminer 4.6.1 has brought new life to the S2. I used to point the S2's to a different pool, while all my other miners used P2Pool. It's so nice to see them doing the full 1000 GH/s with P2Pool. I have 2x S2's and 2x C1's, and all 4 of them run neck-and-neck.
Bear in mind if you are pointing an S1/2/3/4 to p2pool with bitmain's default firmware binaries, they throw out stale shares which is potentially disastrous on p2pool because that can throw out a valid block solve. Kano and I have pointed this out to them numerous times but that behaviour is still in their fork.Is it enough to get rid of this prob if cgminer is replaced with http://ck.kolivas.org/apps/cgminer/antminer/s3/4.6.1-141020/ ? Or some option in /etc/config/cgminer params line --submit-stales or similiar??
Any info where to get working or updated cgminers to other ants, heres few s1:s still making noise
"Hi,
no worries, we've updated the firmware.Our antpool is open public and you may try with solo.antpool.com to try. it's more stable than p2pool.
Engineers are still working on the popool issue to get it more stable:)"
November 29, 2014, 01:08:28 AM
The number 1 issue is fixed with latest firmware, which runs cgminer 4.6.1. When the work restart request comes in, I usually see the flush work within 1 second, then the new block task usually arrives in another second. Often there are new accepted shares submitted within 2 seconds of the work restart request. The new cgminer 4.6.1 has brought new life to the S2. I used to point the S2's to a different pool, while all my other miners used P2Pool. It's so nice to see them doing the full 1000 GH/s with P2Pool. I have 2x S2's and 2x C1's, and all 4 of them run neck-and-neck.
Bear in mind if you are pointing an S1/2/3/4 to p2pool with bitmain's default firmware binaries, they throw out stale shares which is potentially disastrous on p2pool because that can throw out a valid block solve. Kano and I have pointed this out to them numerous times but that behaviour is still in their fork.Is it enough to get rid of this prob if cgminer is replaced with http://ck.kolivas.org/apps/cgminer/antminer/s3/4.6.1-141020/ ? Or some option in /etc/config/cgminer params line --submit-stales or similiar??
Any info where to get working or updated cgminers to other ants, heres few s1:s still making noise
November 29, 2014, 12:56:51 AM
EDIT: You'll have to do this after every reboot unfortunately, as it will reset to defaults. Just don't reboot it...... 
Seriously?? Wow.
Isn't this easier?
Code:
/usr/bin/cgminer-api "setconfig|queue,0"
M
Dunno, never tried it.....if it works - let me know
It works on S2s. Haven't figured out how to get privileged API commands to work on S3s yet.
M
The S3's are even easier because it will save over a power cycle, unlike the S2/S4/C1. Just change the PARAMS variable in /etc/init.d/cgminer. That is where you add --api-allow and whatever other cgminer params you want.
Like so:
PARAMS="$AOPTIONS $POOL1 $POOL2 $POOL3 $_pb $_ow $_bec --api-listen --api-allow W:0/0 --bitmain-checkn2diff --bitmain-hwerror --queue 0"
Yes, thanks, I figured that out. Now if I could just get the API commands to work. I tried --api-allow W:192.168.0/32 and cgminer wouldn't start.
M
That is not a valid subnet mask setting for cgminer. /32 is a single IP, but you are providing 3 octets. I think you mean to use /24, which is equal to 255.255.255.0.
November 29, 2014, 12:42:49 AM
The number 1 issue is fixed with latest firmware, which runs cgminer 4.6.1. When the work restart request comes in, I usually see the flush work within 1 second, then the new block task usually arrives in another second. Often there are new accepted shares submitted within 2 seconds of the work restart request. The new cgminer 4.6.1 has brought new life to the S2. I used to point the S2's to a different pool, while all my other miners used P2Pool. It's so nice to see them doing the full 1000 GH/s with P2Pool. I have 2x S2's and 2x C1's, and all 4 of them run neck-and-neck.
Bear in mind if you are pointing an S1/2/3/4 to p2pool with bitmain's default firmware binaries, they throw out stale shares which is potentially disastrous on p2pool because that can throw out a valid block solve. Kano and I have pointed this out to them numerous times but that behaviour is still in their fork.Does this also apply to the latest firmware with the 4.6.1 build?
Edit: I guess since you are replying to my previous post where I am referring to 4.6.1, then your statement does apply. But I want to double check. Cheers.
November 29, 2014, 12:05:42 AM
The number 1 issue is fixed with latest firmware, which runs cgminer 4.6.1. When the work restart request comes in, I usually see the flush work within 1 second, then the new block task usually arrives in another second. Often there are new accepted shares submitted within 2 seconds of the work restart request. The new cgminer 4.6.1 has brought new life to the S2. I used to point the S2's to a different pool, while all my other miners used P2Pool. It's so nice to see them doing the full 1000 GH/s with P2Pool. I have 2x S2's and 2x C1's, and all 4 of them run neck-and-neck.
Bear in mind if you are pointing an S1/2/3/4 to p2pool with bitmain's default firmware binaries, they throw out stale shares which is potentially disastrous on p2pool because that can throw out a valid block solve. Kano and I have pointed this out to them numerous times but that behaviour is still in their fork.Is it enough to get rid of this prob if cgminer is replaced with http://ck.kolivas.org/apps/cgminer/antminer/s3/4.6.1-141020/ ? Or some option in /etc/config/cgminer params line --submit-stales or similiar??
Any info where to get working or updated cgminers to other ants, heres few s1:s still making noise
November 28, 2014, 11:56:03 PM
Bear in mind if you are pointing an S1/2/3/4 to p2pool with bitmain's default firmware binaries, they throw out stale shares which is potentially disastrous on p2pool because that can throw out a valid block solve. Kano and I have pointed this out to them numerous times but that behaviour is still in their fork.
Could this behavior impact p2pool's luck?
November 28, 2014, 09:12:10 PM
The number 1 issue is fixed with latest firmware, which runs cgminer 4.6.1. When the work restart request comes in, I usually see the flush work within 1 second, then the new block task usually arrives in another second. Often there are new accepted shares submitted within 2 seconds of the work restart request. The new cgminer 4.6.1 has brought new life to the S2. I used to point the S2's to a different pool, while all my other miners used P2Pool. It's so nice to see them doing the full 1000 GH/s with P2Pool. I have 2x S2's and 2x C1's, and all 4 of them run neck-and-neck.
Bear in mind if you are pointing an S1/2/3/4 to p2pool with bitmain's default firmware binaries, they throw out stale shares which is potentially disastrous on p2pool because that can throw out a valid block solve. Kano and I have pointed this out to them numerous times but that behaviour is still in their fork. 
November 28, 2014, 08:50:48 PM
EDIT: You'll have to do this after every reboot unfortunately, as it will reset to defaults. Just don't reboot it......
Seriously?? Wow.
Isn't this easier?
Code:
/usr/bin/cgminer-api "setconfig|queue,0"
M
Dunno, never tried it.....if it works - let me know
It works on S2s. Haven't figured out how to get privileged API commands to work on S3s yet.
M
The S3's are even easier because it will save over a power cycle, unlike the S2/S4/C1. Just change the PARAMS variable in /etc/init.d/cgminer. That is where you add --api-allow and whatever other cgminer params you want.
Like so:
PARAMS="$AOPTIONS $POOL1 $POOL2 $POOL3 $_pb $_ow $_bec --api-listen --api-allow W:0/0 --bitmain-checkn2diff --bitmain-hwerror --queue 0"
Yes, thanks, I figured that out. Now if I could just get the API commands to work. I tried --api-allow W:192.168.0/32 and cgminer wouldn't start.
M
November 28, 2014, 03:36:30 PM
P2Pool looks busy lately. I noticed the P2Pool stale rate is now at 20%
Nothing to panic about, as with a 30 second share chain interval, that works out to a block propagation lag of only 6 seconds.
My node is using ~40% of one CPU core for P2Pool at the moment (need a new machine with moar CPU and disk space).
Code:
2014-11-28 13:29:18.898450 P2Pool: 17324 shares in chain (17328 verified/17328 total) Peers: 22 (16 incoming)
2014-11-28 13:29:18.898605 Local: 0H/s in last 0.0 seconds Local dead on arrival: ??? Expected time to share: ???
2014-11-28 13:29:18.898680 Shares: 0 (0 orphan, 0 dead) Stale rate: ??? Efficiency: ??? Current payout: 0.0000 BTC
2014-11-28 13:29:18.898768 Pool: 2548TH/s Stale rate: 21.6% Expected time to block: 18.9 hours
My node is using ~40% of one CPU core for P2Pool at the moment (need a new machine with moar CPU and disk space).
November 28, 2014, 12:29:00 PM
EDIT: You'll have to do this after every reboot unfortunately, as it will reset to defaults. Just don't reboot it......
Seriously?? Wow.
Isn't this easier?
Code:
/usr/bin/cgminer-api "setconfig|queue,0"
M
Dunno, never tried it.....if it works - let me know
It works on S2s. Haven't figured out how to get privileged API commands to work on S3s yet.
M
The S3's are even easier because it will save over a power cycle, unlike the S2/S4/C1. Just change the PARAMS variable in /etc/init.d/cgminer. That is where you add --api-allow and whatever other cgminer params you want.
Like so:
PARAMS="$AOPTIONS $POOL1 $POOL2 $POOL3 $_pb $_ow $_bec --api-listen --api-allow W:0/0 --bitmain-checkn2diff --bitmain-hwerror --queue 0"
November 28, 2014, 09:33:44 AM
I think your formulas are a bit arbitrary. For instance, getwork latency is given way too much importance in the pool formula. And everything is linear.. and so on (latencies are mostly ok within a range before the problems they cause skyrocket).
November 27, 2014, 11:09:59 PM
I have introduced the concept of "Miner Power" on my p2pools located at us-east.p2pool.co and europe.p2pool.co. "Miner Power" is the effective rate of a miner on a particular node compared to other p2pool nodes. It is calculated by taking a miner's DOA % rate and comparing it the DOA rate of all miners on the global p2pool network. It is then multiplied by the efficiency of that particular p2pool node. Is it correct that that is the rate of increase of payout of the miner on that p2pool node compared to other p2pool nodes? If so shouldn't "efficiency if miner perfect" be used over just efficiency (where other miners can take the efficiency rate down)?
For those interested in the code:
For those interested in the code:
Code:
doa = local_stats.miner_dead_hash_rates[address] || 0;
doa_prop = (parseFloat(doa) / parseFloat(hashrate)) * 100;
doa_global = (global_stats.pool_hash_rate - global_stats.pool_nonstale_hash_rate) / global_stats.pool_hash_rate * 100;
miner_power = 100 * ((100 - doa_prop) / (100 - doa_global)) * local_stats.efficiency;
November 27, 2014, 10:19:36 PM
EDIT: You'll have to do this after every reboot unfortunately, as it will reset to defaults. Just don't reboot it......
Seriously?? Wow.
Isn't this easier?
Code:
/usr/bin/cgminer-api "setconfig|queue,0"
M
Dunno, never tried it.....if it works - let me know
It works on S2s. Haven't figured out how to get privileged API commands to work on S3s yet.
M
November 27, 2014, 10:18:49 PM
EDIT: You'll have to do this after every reboot unfortunately, as it will reset to defaults. Just don't reboot it......
Seriously?? Wow.
Isn't this easier?
Code:
/usr/bin/cgminer-api "setconfig|queue,0"
M
Dunno, never tried it.....if it works - let me know
November 27, 2014, 10:16:16 PM
EDIT: You'll have to do this after every reboot unfortunately, as it will reset to defaults. Just don't reboot it......
Seriously?? Wow.
Isn't this easier?
Code:
/usr/bin/cgminer-api "setconfig|queue,0"
M
Jump to: