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

[entr04y]

Might be worth while asking ckolivas if the S3 binary he done to fix the stale shares filtering can also be used in the C1? I don't have a C1, but it might be compatible......

If S3 binaries run on the C1, my binary is compatible.

Doesn't look like it:

Code:

root@ant1:~# /usr/bin/cgminer --help
/usr/bin/cgminer: line 1: syntax error: unexpected "("

$ file cgminer
cgminer: ELF 32-bit MSB executable, MIPS, MIPS32 rel2 version 1 (SYSV), dynamically linked (uses shared libs), with unknown capability 0x41000000 = 0xf676e75, with unknown capability 0x10000 = 0x70403, stripped

$ file cgminer.orig
cgminer.orig: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, stripped

cgminer.orig  is the one that came with the c1.

[mahrens917]

> Error submitting primary block: (will retry)
2014-12-01 08:58:52.269638 > Traceback (most recent call last):
2014-12-01 08:58:52.269676 >   File "/usr/lib64/python2.7/site-packages/twisted/internet/defer.py", line 490, in _startRunCallbacks
2014-12-01 08:58:52.269704 >     self._runCallbacks()
2014-12-01 08:58:52.269738 >   File "/usr/lib64/python2.7/site-packages/twisted/internet/defer.py", line 577, in _runCallbacks
2014-12-01 08:58:52.269780 >     current.result = callback(current.result, *args, **kw)
2014-12-01 08:58:52.269832 >   File "/usr/lib64/python2.7/site-packages/twisted/internet/defer.py", line 1155, in gotResult
2014-12-01 08:58:52.269856 >     _inlineCallbacks(r, g, deferred)
2014-12-01 08:58:52.269880 >   File "/usr/lib64/python2.7/site-packages/twisted/internet/defer.py", line 1099, in _inlineCallbacks
2014-12-01 08:58:52.269913 >     result = g.send(result)
2014-12-01 08:58:52.269954 > --- <exception caught here> ---
2014-12-01 08:58:52.269987 >   File "/mnt/60gb/p2pool/p2pool/util/deferral.py", line 41, in f
2014-12-01 08:58:52.270028 >     result = yield func(*args, **kwargs)
2014-12-01 08:58:52.270059 >   File "/mnt/60gb/p2pool/p2pool/bitcoin/helper.py", line 67, in submit_block_p2p
2014-12-01 08:58:52.270112 >     factory.conn.value.send_block(block=block)
2014-12-01 08:58:52.270136 >   File "/mnt/60gb/p2pool/p2pool/util/p2protocol.py", line 102, in <lambda>
2014-12-01 08:58:52.270169 >     return lambda **payload2: self.sendPacket(command, payload2)
2014-12-01 08:58:52.270201 >   File "/mnt/60gb/p2pool/p2pool/util/p2protocol.py", line 93, in sendPacket
2014-12-01 08:58:52.270224 >     raise TooLong('payload too long')
2014-12-01 08:58:52.270247 > p2pool.util.p2protocol.TooLong: payload too long

Whatsup?


It became orphan because payload too long? Too many users on pool or too many transactions in a block or what?

I received the same error as well at around the same time.  I will post it on github if anyone hasn't already.

[mahrens917]

The latest algorithm change definitely boosted my node's standing (currently 112% score in your list).

Could you change the listing from the IP  71.172.92.76 to the host name galactica.geekgalaxy.com?

Also, the algorithm FAQ at the bottom still lists GWL.

I changed your hostname and updated the FAQ on the bottom of the page.  You should be all set now. 

Note, that your score is relative to your location so 112% for you in NJ will be (slightly) different for me in NY.

[mahrens917]

2014-12-01 08:58:52.270247 > p2pool.util.p2protocol.TooLong: payload too long

Whatsup?


It became orphan because payload too long? Too many users on pool or too many transactions in a block or what?

I received the same error as well at around the same time.  I will post it on github if anyone hasn't already.

I posted the issue here https://github.com/forrestv/p2pool/issues/238 so others can update as well.

Did this happen to anyone else?

[entr04y]

Might be worth while asking ckolivas if the S3 binary he done to fix the stale shares filtering can also be used in the C1? I don't have a C1, but it might be compatible......

If S3 binaries run on the C1, my binary is compatible.

Doesn't look like it:

Code:

root@ant1:~# /usr/bin/cgminer --help
/usr/bin/cgminer: line 1: syntax error: unexpected "("

$ file cgminer
cgminer: ELF 32-bit MSB executable, MIPS, MIPS32 rel2 version 1 (SYSV), dynamically linked (uses shared libs), with unknown capability 0x41000000 = 0xf676e75, with unknown capability 0x10000 = 0x70403, stripped

$ file cgminer.orig
cgminer.orig: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, stripped

cgminer.orig  is the one that came with the c1.

The S4 binary seems to run ok (actually it seems to give quite a boost in hash rate), but the GH/s (5s) field is 0 (the avg field looks right) and the discarded field is really high... p2pool says 1.34THS/s and 5.5% discard rate, and the temperature seemed stable.  I've switched back to the original binary for now... it seems like it was running too fast and if the GH/s field isn't working, I'm not sure that I trust the rest of the stats on the miner.

ckolivas (or anyone else), any opinion on running the s4 binary on a c1?

[-ck]

The S4 binary seems to run ok (actually it seems to give quite a boost in hash rate), but the GH/s (5s) field is 0 (the avg field looks right) and the discarded field is really high... p2pool says 1.34THS/s and 5.5% discard rate, and the temperature seemed stable.  I've switched back to the original binary for now... it seems like it was running too fast and if the GH/s field isn't working, I'm not sure that I trust the rest of the stats on the miner.

ckolivas (or anyone else), any opinion on running the s4 binary on a c1?

Obviously the architecture is like an S4 then (beaglebone not mips), not an S3.

Fields are different due to random api changes that bitmain felt obliged to do breaking compatibility so it's harmless (but missing).

Huge discards is due to the ridiculous default queue that bitmain set on these devices to 8000 or so. Change it to zero.

[entr04y]

Obviously the architecture is like an S4 then (beaglebone not mips), not an S3.

Fields are different due to random api changes that bitmain felt obliged to do breaking compatibility so it's harmless (but missing).

Huge discards is due to the ridiculous default queue that bitmain set on these devices to 8000 or so. Change it to zero.

yeah.  I switched back to the S4 binary and it crashed (the c1 rebooted itself).  I had that happen once before on that miner after restarting cgminer several times, so I don't think it was the new binary that caused it.

It also completely wiped any changes I made to the filesystem, so either the entire filesystem is running in memory and not committing to "disk", or it reflashes itself on reboot.  That's not annoying at all

I sent an email to bitmain regarding the stale submission issue and they responded with "engineers are working on it, but in the meantime use antpool" 

Done messing with it for tonight... thanks for the input!

[-ck]

I sent an email to bitmain regarding the stale submission issue and they responded with "engineers are working on it, but in the meantime use antpool"  

Lolz, antpool is (allegedly) p2pool (or some bastard child of it) anyway so how does that help?

[IYFTech]

I sent an email to bitmain regarding the stale submission issue and they responded with "engineers are working on it, but in the meantime use antpool"  

Lolz, antpool is (allegedly) p2pool (or some bastard child of it) anyway so how does that help?

Exactly. They either don't get it or don't care about it 

[entr04y]

Quick update, I replaced the stock cgminer binary on my C1 with ckolivas' s4 binary this morning (about 5 hours ago) and it has been running well since... with two C1's I've been averaging slightly above 2TH/s, with 3-5% rejects and has already found three shares.  Temps look good (running about 40C) and the only problems I've seen so far is the GH/s(5s) metric is missing and the discards are high as usual.

For comparison, the stock cgminer was running at around 1.9TH/s, with 5-7% rejects and I was finding one or two shares per day.  Given the timeframe, I'm not putting much weight behind the number of shares found, but there is clearly a significant improvement in hash rate and reject rate.   Temps are about the same.

Now, if someone would just find a block I could get paid too

[PatMan]

Now, if someone would just find a block I could get paid too

BOOM!!  Ask & ye shall receive......

[jcumins]

You are the man 2 blocks Bamm

[OgNasty]

NastyPool just solved its first Bitcoin block! :-)

Block 332691

The miner to thank: NastyMining-PPS

Nice that I can claim to have mined one of the recent p2pool blocks.  

The block finder reward will be a nice little bonus for all the NastyPool -PoP miners this week as well.  Not too late to jump in and try to grab a piece of the reward.  

[jcumins]

Ok I am wondering how does one determine what miner or if there pool found the block.

I have not figured that out yet.

[norgan]

Ok I am wondering how does one determine what miner or if there pool found the block.

I have not figured that out yet.

it's on the node logs. something like Block found passing to network.

[jonnybravo0311]

Ok I am wondering how does one determine what miner or if there pool found the block.

I have not figured that out yet.

2 ways...

First is to look at your logs and you'll see the message that the block was found.

Code:

2014-04-26 04:18:51.302213 GOT BLOCK FROM MINER! Passing to bitcoind!

Second is to look at your payout.  If you found the block you get a 0.125BTC reward for it.

[norgan]

Ok I am wondering how does one determine what miner or if there pool found the block.

I have not figured that out yet.

2 ways...

First is to look at your logs and you'll see the message that the block was found.

Code:

2014-04-26 04:18:51.302213 GOT BLOCK FROM MINER! Passing to bitcoind!

Second is to look at your payout.  If you found the block you get a 0.125BTC reward for it.

Is the reward to the miner or the nodes address? It's the miner right?

[jonnybravo0311]

Ok I am wondering how does one determine what miner or if there pool found the block.

I have not figured that out yet.

2 ways...

First is to look at your logs and you'll see the message that the block was found.

Code:

2014-04-26 04:18:51.302213 GOT BLOCK FROM MINER! Passing to bitcoind!

Second is to look at your payout.  If you found the block you get a 0.125BTC reward for it.

Is the reward to the miner or the nodes address? It's the miner right?

Reward goes to the miner.

[windpath]

Ok I am wondering how does one determine what miner or if there pool found the block.

I have not figured that out yet.

You can look at your shares, the 8 character (shortened) "share hash" is the last 8 characters of the block hash (assuming the share found a block), in OG's case:

Block hash: 0000000000000000164109c6391d508781ce46149099a9d64e4d0fecfebf15ad

Share hash on node: febf15ad

I just realized that unfortunately NastyPool does not make the default front-end available at the typical URL (https://www.nastyfans.org:9332/static)...

But if it was there and they did find the block (which I assume they did), you would see the share...

OG/nonnakip: might be worth opening up the default front end (even it only shows your single combined address) for transparencies sake...

Congrats on finding the block

Edit: here is the share on my node, indeed the Nasty address
http://minefast.coincadence.com:9332/static/original/share.html#0000000000000000164109c6391d508781ce46149099a9d64e4d0fecfebf15ad

[jcumins]

Thanks so much.  Still new at this and have my first node up and running.   Working on a new Debian based server and will have to see how that works out better then the windows based servers.  So far the windows one is running great on a older used quad core dual processor desktop with 64bit win 7.  The box is running great.