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.
Topic: [1500 TH] p2pool: Decentralized, DoS-resistant, Hop-Proof pool - page 256. (Read 2591928 times)
December 03, 2014, 04:47:56 PM
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.
December 02, 2014, 06:24:27 PM
You are the man 2 blocks Bamm 
December 02, 2014, 04:15:40 PM
Now, if someone would just find a block I could get paid too
BOOM!! Ask & ye shall receive......
December 02, 2014, 01:17:34 PM
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
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
December 02, 2014, 06:25:39 AM
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
December 02, 2014, 01:22:11 AM
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? December 01, 2014, 11:27:04 PM
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!
December 01, 2014, 10:53:42 PM
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.ckolivas (or anyone else), any opinion on running the s4 binary on a c1?
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.
December 01, 2014, 10:23:58 PM
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?
December 01, 2014, 10:04:37 PM
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?
December 01, 2014, 09:52:47 PM
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.
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.
December 01, 2014, 09:42:45 PM
> 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 > --- ---
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
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?
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 > ---
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
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.
December 01, 2014, 08:52:45 PM
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.
December 01, 2014, 08:44:02 PM
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.You'd think it's a S3 on steroids. But it's not. It's more like an S2 in every way except the physical size and power usage. Same file system, same different passwords, same annoying "features".
M
December 01, 2014, 08:31:19 PM
Yes and your rejects and stale may actually go up, but you want that since you've already mined those shares anyway and they might solve a block.
Thanks
will give it a go. (FYI I was looking at Kano's binaries not Cons lol) December 01, 2014, 08:29:43 PM
Yes and your rejects and stale may actually go up, but you want that since you've already mined those shares anyway and they might solve a block.
December 01, 2014, 08:28:40 PM
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.Are the S3 binaries still needed with the latest firmware? I'm getting ~4% rejected and ~1.5% stale on my S3's with p2pool
Yes, I use it with the latest firmware:
http://ck.kolivas.org/apps/cgminer/antminer/s3/4.6.1-141020/cgminer
December 01, 2014, 08:27:36 PM
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.Are the S3 binaries still needed with the latest firmware? I'm getting ~4% rejected and ~1.5% stale on my S3's with p2pool
EDIT: is there an S3 binary from Kano??
December 01, 2014, 08:26:27 PM
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.Blimey - that was quick!!
December 01, 2014, 08:25:06 PM
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. Jump to: