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

[MissouriMiner]

Pseudo share doesnt affect in founding block anyotherway than it restarts works everytime that changes, so selecting constant could help abit keeping miner busy. Large miners should use bigger sharedifficulty - that would help poolwide. Like btcaddress+501/100000000, then there should be less 5 s restart times, and big miners earn that way more too. Ckolivas proxy helps keeping miners busy also, I have got very good results with it in p2pool and solo pool, it squeezes juice out of miners, with s3s mindiff and startdiff have to be chosen so that you can see best share..

Last weeks bests with 2th= 2,347,645,293, one ~1,500000000,   537,352,921 .. newer got those kind of results without proxy.

S3:s doesnt show best share with all share diff + 512, 1024, 4096 doesnt show, 500, 4000 ... it shows

nohup ./ckpool -p -A -k> /dev/null 2>&1 &

Wondering how ants would perform if those are turned to diskless nodes and booted with tftp, that way cgminer could be running on some more powerfull machine, i think s2 s3 s4 are suffering constan restarts - the mainoboard doesnt have enough power. And that way I doesnt have to wait new firmware and cgminer...

http://wiki.gentoo.org/wiki/Diskless_nodes

It does matter with the S4, and the S2.  The S3 works correctly.

[mdude77]

Pseudo share doesnt affect in founding block anyotherway than it restarts works everytime that changes, so selecting constant could help abit keeping miner busy. Large miners should use bigger sharedifficulty - that would help poolwide. Like btcaddress+501/100000000, then there should be less 5 s restart times, and big miners earn that way more too. Ckolivas proxy helps keeping miners busy also, I have got very good results with it in p2pool and solo pool, it squeezes juice out of miners, with s3s mindiff and startdiff have to be chosen so that you can see best share..

Last weeks bests with 2th= 2,347,645,293, one ~1,500000000,   537,352,921 .. newer got those kind of results without proxy.

S3:s doesnt show best share with all share diff + 512, 1024, 4096 doesnt show, 500, 4000 ... it shows

nohup ./ckpool -p -A -k> /dev/null 2>&1 &

Wondering how ants would perform if those are turned to diskless nodes and booted with tftp, that way cgminer could be running on some more powerfull machine, i think s2 s3 s4 are suffering constan restarts - the mainoboard doesnt have enough power. And that way I doesnt have to wait new firmware and cgminer...

http://wiki.gentoo.org/wiki/Diskless_nodes

It does matter with the S4, and the S2.  The S3 works correctly.

It doesn't work with my S2.  Doesn't matter what difficulty I set it to, I lose up to 10% of my hash rate by pointing it to p2pool.

M

[-ck]

The default Bitmain 4.6.1 has been working pretty good for me.  I get 1.9 TH/s average.  And you have to set pseudo difficulty.  It doesn't work properly without it.  I haven't tried the latest version from ckolivas that was released within the last 24 hours, but I will try it now.

If you used pseudo difficulty with the existing S4 binary, you have circumvented the bulk of the issues, but there is still some gain with the new binary I provided due to the way stales are handled. Just remove any queue value from the init script since 8192 is a crazy default.

[MissouriMiner]

Pseudo share doesnt affect in founding block anyotherway than it restarts works everytime that changes, so selecting constant could help abit keeping miner busy. Large miners should use bigger sharedifficulty - that would help poolwide. Like btcaddress+501/100000000, then there should be less 5 s restart times, and big miners earn that way more too. Ckolivas proxy helps keeping miners busy also, I have got very good results with it in p2pool and solo pool, it squeezes juice out of miners, with s3s mindiff and startdiff have to be chosen so that you can see best share..

Last weeks bests with 2th= 2,347,645,293, one ~1,500000000,   537,352,921 .. newer got those kind of results without proxy.

S3:s doesnt show best share with all share diff + 512, 1024, 4096 doesnt show, 500, 4000 ... it shows

nohup ./ckpool -p -A -k> /dev/null 2>&1 &

Wondering how ants would perform if those are turned to diskless nodes and booted with tftp, that way cgminer could be running on some more powerfull machine, i think s2 s3 s4 are suffering constan restarts - the mainoboard doesnt have enough power. And that way I doesnt have to wait new firmware and cgminer...

http://wiki.gentoo.org/wiki/Diskless_nodes

It does matter with the S4, and the S2.  The S3 works correctly.

It doesn't work with my S2.  Doesn't matter what difficulty I set it to, I lose up to 10% of my hash rate by pointing it to p2pool.

M

True.  I should have said, it does work except lose up to 10%.  I still use it.  Some other brand miners are much worse, so I considered mining at 90% of normal as "working".  I know many will disagree.  Sorry...  

I would then say that the S4 is currently working at only 95% of normal.

[PatMan]

The default Bitmain 4.6.1 has been working pretty good for me.  I get 1.9 TH/s average.  And you have to set pseudo difficulty.  It doesn't work properly without it.  I haven't tried the latest version from ckolivas that was released within the last 24 hours, but I will try it now.

If you used pseudo difficulty with the existing S4 binary, you have circumvented the bulk of the issues, but there is still some gain with the new binary I provided. Just remove any queue value from the init script since 8192 is a crazy default.

Does removing the queue command completely set it to zero?

[MissouriMiner]

The default Bitmain 4.6.1 has been working pretty good for me.  I get 1.9 TH/s average.  And you have to set pseudo difficulty.  It doesn't work properly without it.  I haven't tried the latest version from ckolivas that was released within the last 24 hours, but I will try it now.

If you used pseudo difficulty with the existing S4 binary, you have circumvented the bulk of the issues, but there is still some gain with the new binary I provided. Just remove any queue value from the init script since 8192 is a crazy default.

OK. I tried your new binary and it appears the same.  I assume because I'm using the pseudo difficulty as you stated.  BTW, I am using "--queue 0 --scan-time 1 --expiry 1", which is the typical recommended settings for p2pool.

[-ck]

Does removing the queue command completely set it to zero?

1 is the default. Also I edited the previous post to mention submitting stales.

[MissouriMiner]

The default Bitmain 4.6.1 has been working pretty good for me.  I get 1.9 TH/s average.  And you have to set pseudo difficulty.  It doesn't work properly without it.  I haven't tried the latest version from ckolivas that was released within the last 24 hours, but I will try it now.

If you used pseudo difficulty with the existing S4 binary, you have circumvented the bulk of the issues, but there is still some gain with the new binary I provided. Just remove any queue value from the init script since 8192 is a crazy default.

Does removing the queue command completely set it to zero?

No.  It will use the default, which is 1.  I would set it to 0 for p2pool use, but 1 is good for other pools.

[-ck]

OK. I tried your new binary and it appears the same.  I assume because I'm using the pseudo difficulty as you stated.  BTW, I am using "--queue 0 --scan-time 1 --expiry 1", which is the typical recommended settings for p2pool.

Give it time too since the original does not submit stales. Scan time and expiry are irrelevant and recommendations for this stem from the dark ages of getwork mining, not stratum. The difference between queue 1 and zero at thousands of work items per second is nothing but it may slow the device down.

[PatMan]

Does removing the queue command completely set it to zero?

1 is the default. Also I edited the previous post to mention submitting stales.

Right, thanks. I've always run mine with the zero value - seems to work the best with p2pool for me 

[MissouriMiner]

For the last block found (325976), I received a payment much higher than normal or expected.  I'm definitely not complaining.  This is great!   But I want to understand why?  The payout tab showed the normal expected amount, by my payment was 4x that amount.  Anyone know why this could happen?

Edit:  To add a bit more info.  My P2Pool server and default payout address is a different address.  I'm talking about my mining address only.

[mdude77]

For the last block found (325976), I received a payment much higher than normal or expected.  I'm definitely not complaining.  This is great!   But I want to understand why?  The payout tab showed the normal expected amount, by my payment was 4x that amount.  Anyone know why this could happen?

Edit:  To add a bit more info.  My P2Pool server and default payout address is a different address.  I'm talking about my mining address only.

Usually that means you found the block.

M

[MissouriMiner]

For the last block found (325976), I received a payment much higher than normal or expected.  I'm definitely not complaining.  This is great!   But I want to understand why?  The payout tab showed the normal expected amount, by my payment was 4x that amount.  Anyone know why this could happen?

Edit:  To add a bit more info.  My P2Pool server and default payout address is a different address.  I'm talking about my mining address only.

Usually that means you found the block.

M

Wow!  You are right.  First time ever.  I didn't even notice!  lol

2014-10-18 22:43:49.668550 GOT BLOCK FROM MINER! Passing to bitcoind! https://blockchain.info/block/00000000000000001928
73ad7facbe0898a86dc8426702c5bf19e37e7f93380b

[mdude77]

For the last block found (325976), I received a payment much higher than normal or expected.  I'm definitely not complaining.  This is great!   But I want to understand why?  The payout tab showed the normal expected amount, by my payment was 4x that amount.  Anyone know why this could happen?

Edit:  To add a bit more info.  My P2Pool server and default payout address is a different address.  I'm talking about my mining address only.

Usually that means you found the block.

M

Wow!  You are right.  First time ever.  I didn't even notice!  lol

2014-10-18 22:43:49.668550 GOT BLOCK FROM MINER! Passing to bitcoind! https://blockchain.info/block/00000000000000001928
73ad7facbe0898a86dc8426702c5bf19e37e7f93380b

Grats!

M

[-ck]

All going well I'm going to be helping drop the biggest mine onto p2pool yet over the next day. Watch for it 

[PatMan]

All going well I'm going to be helping drop the biggest mine onto p2pool yet over the next day. Watch for it 

Where do you keep finding them?........

[HellDiverUK]

Looking forward to someone rewriting p2pool, I was running it earlier on a Q6700, and was getting terrible latency - one core was flat out.   Single threaded .exe sucks.  A Core2Quad 2.66GHz with 6GB RAM should be able to totally maul p2pool.

[PatMan]

Can't see it happening tbh. I can't see Bitmain keeping their promise about doing something with it either......

[naplam]

Looking forward to someone rewriting p2pool, I was running it earlier on a Q6700, and was getting terrible latency - one core was flat out.   Single threaded .exe sucks.  A Core2Quad 2.66GHz with 6GB RAM should be able to totally maul p2pool.

If you have tons of clients hashing at high hashrates, run several p2pool instances and load-balance with iptables or something.

[mdude77]

Looking forward to someone rewriting p2pool, I was running it earlier on a Q6700, and was getting terrible latency - one core was flat out.   Single threaded .exe sucks.  A Core2Quad 2.66GHz with 6GB RAM should be able to totally maul p2pool.

Would running it in a VM with 1 thread help?  I've often theorized that a VM with 1 thread on a multicore machine performs better than on the multicore machine, as those multiple threads are used to run the "one" thread in the VM.

But I never actually tried it.

M