I am mining at 220 MH/s, are there any reasons why I shouldn’t raise my difficulty? If I were to put it at 512 would this have any negative impact on my side? It's just less traffic right? I already know this doesn’t change my chances of finding a share of the required difficulty. I'm just wondering what happens on my end.
At that hashrate, you probably don't want to increase difficulty. It will not significantly change network load but will increase income variance. This gets to the crux of my question. How or why would it increase income variance at a pool like p2pool where we are looking for high difficulty shares. I'm not disagreeing with you, I'm asking why? Do we need to submit these lower diff shares for some reason? |
|
|
|
|
I am mining at 220 MH/s, are there any reasons why I shouldn’t raise my difficulty? If I were to put it at 512 would this have any negative impact on my side? It's just less traffic right? I already know this doesn’t change my chances of finding a share of the required difficulty. I'm just wondering what happens on my end.
|
|
|
|
I’m late to the game here. Where do I go to buy one?
Sales should be up for US Customers within the next 4-5 hours. Canadian customers sometime this weekend (hopefully), and other overseas customers in about a week (maybe more, maybe less). It will not be hidden, if you go to the BTC Guild website once the store is launched, you won't be able to miss it  . Roger that, Thx. |
|
|
|
|
I’m late to the game here. Where do I go to buy one?
|
|
|
|
It would be nice if forrestv commented on this!
This is what I see after looking into the code. If a share C is based on a stale block (usually shortly after a block was found), it gets "punished" and nodes start working on top of its parent share P, so C is forced to orphan. However, if a node does not follow this rule (may be a result of code modification or high bitcoind latency), it works on top of C (while others are working on P!) and may eventually find a share, "save" C from orphanage and (easily since it is 1 share ahead by total work!) orphan all P's children found before it. Looks like a bug to me.
Yeah, that is exactly what I think is happening. I think it's the result of latency (internet) + bitcoind getblocktemplate latency. It doesn't help that some of the highest hash power miners on p2pool seem to be behind firewalls & are on slow connections/machines. Miner X finds a share, say, 1-3 seconds after a new block, Miner X's client thinks it is a legit share and passes it around, some of the other p2pool nodes relay it as legit.... another share is then built off of that one, and then that's it for anyone that (ed: has found a share off of) the parent of the 'punished' share... the two shares > one share, so everyone switches over. I didn't keep my old logs, but I've had a few times where I've found a share, gotten a new work (not just from the sleep time deferral, +1 to verified shares, etc), then the next work, it'll become an orphan... so then that means that some other nodes had some 3 share chain vs the 2 share chain. The 3rd share on that chain might not even necessarily be from a slow node.. This is exactly what we were talking about a few days a go. Someone suggested that your bitcoin was behind your p2pool, but that wouldn’t explain why 50% of your orphans are attributed to the same address. It seems to me that some p2pool nodes (large ones) are far behind bitcoin and those of us that are not are punished when the above scenario happens. edit: It would be nice to here from forrestv about this. There is a new p2pool branch in his github called new share I wonder if it has a fix for this. https://github.com/forrestv/p2pool/tree/newshare |
|
|
|
p2pool falsely claiming share is "dead on arrival" after block solved, orphaning valid shares over invalid shares, claiming "Dead on arrival" shares that become undead
first time, it became undead, and valid
second time, it remained dead
2013-06-27 14:59:35.699635 Shares: 58 (2 orphan, 3 dead) Stale rate: ~8.6% (3-19%) Efficiency: ~114.5% (101-121%) Current payout: 0.2480 BTC
2013-06-27 14:59:36.885926 Punishing share for 'Block-stale detected! 5eb5fbbee222c57983d44064121839f36a6b9ade5728c6bee6 < 994e796a55e58076e851ee356cc6cdae297b0ecebb41bb651d'! Jumping from b684ab9e to 82d3447f!
2013-06-27 14:59:36.888536 Punishing share for 'Block-stale detected! 5eb5fbbee222c57983d44064121839f36a6b9ade5728c6bee6 < 994e796a55e58076e851ee356cc6cdae297b0ecebb41bb651d'! Jumping from b684ab9e to 82d3447f!
2013-06-27 14:59:37.338727 Punishing share for 'Block-stale detected! 5eb5fbbee222c57983d44064121839f36a6b9ade5728c6bee6 < 994e796a55e58076e851ee356cc6cdae297b0ecebb41bb651d'! Jumping from b684ab9e to 82d3447f!
2013-06-27 14:59:40.485636 New work for worker! Difficulty: 5.000000 Share difficulty: 1115.669886 Total block value: 25.003000 BTC including 3 transactions
2013-06-27 14:59:40.701845 Shares: 58 (2 orphan, 3 dead) Stale rate: ~8.6% (3-19%) Efficiency: ~114.2% (101-121%) Current payout: 0.2480 BTC
2013-06-27 14:59:41.640140 GOT SHARE! Tempbastard 115dabec prev 82d3447f age 17.21s DEAD ON ARRIVAL
2013-06-27 14:59:45.449055 New work for worker! Difficulty: 5.000000 Share difficulty: 1107.910003 Total block value: 25.003000 BTC including 3 transactions
2013-06-27 14:59:45.704697 Shares: 59 (2 orphan, 4 dead) Stale rate: ~10.2% (4-21%) Efficiency: ~112.3% (99-120%) Current payout: 0.2480 BTC
this is the case of the DOA share remaining DOA, despite:
the parent share:
Share 82d3447f
Time first seen: Thu Jun 27 2013 14:59:17 GMT-0500 (Central Daylight Time) (1372363157.042115)
Payout address: 1GL7mM8ZA69WXQcSLu69WYTHGXgXajjSPT
the "non-DOA" child share:
Share b684ab9e (<--- as you can see, my log repeatedly "punished" this share, for being "block-stale")
Time first seen: Thu Jun 27 2013 14:59:24 GMT-0500 (Central Daylight Time) (1372363164.357247)
Payout address: 185Kip6odGYs4eSHD6DYsWVDJBg2DNLfiV
While trying to wrap my head around this I was going through your log and found this..... 2013-06-27 14:59:22.200435 Punishing share for 'Block-stale detected! 5eb5fbbee222c57983d44064121839f36a6b9ade5728c6bee6 < 994e796a55e58076e851ee356cc6cdae297b0ecebb41bb651d'! Jumping from 82d3447f to f619b3c1!2013-06-27 14:59:22.243440 New work for worker! Difficulty: 1.560562 Share difficulty: 1112.553271 Total block value: 25.003000 BTC including 3 transactions 2013-06-27 14:59:22.246420 New work for worker! Difficulty: 1.560562 Share difficulty: 1112.553271 Total block value: 25.003000 BTC including 3 transactions 2013-06-27 14:59:22.249283 New work for worker! Difficulty: 1.560562 Share difficulty: 1112.553271 Total block value: 25.003000 BTC including 3 transactions 2013-06-27 14:59:22.252093 New work for worker! Difficulty: 5.000000 Share difficulty: 1112.553271 Total block value: 25.003000 BTC including 3 transactions 2013-06-27 14:59:22.255850 New work for worker! Difficulty: 5.000000 Share difficulty: 5000.002049 Total block value: 25.003000 BTC including 3 transactions 2013-06-27 14:59:22.327728 New work for worker! Difficulty: 1.560562 Share difficulty: 1112.553271 Total block value: 25.003000 BTC including 3 transactions 2013-06-27 14:59:22.330796 New work for worker! Difficulty: 1.560562 Share difficulty: 1112.553271 Total block value: 25.003000 BTC including 3 transactions 2013-06-27 14:59:22.333631 New work for worker! Difficulty: 1.560562 Share difficulty: 1112.553271 Total block value: 25.003000 BTC including 3 transactions 2013-06-27 14:59:22.522117 New work for worker! Difficulty: 5.000000 Share difficulty: 1112.553271 Total block value: 25.003000 BTC including 3 transactions 2013-06-27 14:59:22.705084 New work for worker! Difficulty: 5.000000 Share difficulty: 5000.002049 Total block value: 25.003000 BTC including 3 transactions 2013-06-27 14:59:24.375464 Punishing share for 'Block-stale detected! 5eb5fbbee222c57983d44064121839f36a6b9ade5728c6bee6 < 994e796a55e58076e851ee356cc6cdae297b0ecebb41bb651d'! Jumping from b684ab9e to 82d3447f!I don't understand how 82d3447f can be the parent share if we jumped from 82d3447f to f619b3c1. How do we jump back to 82d3447f what happened to f619b3c1??? I am confused by this.... |
|
|
|
|
So is my assumption correct that when the block we just found is confirmed what we have in PPLNS will shift to Owed? I was mining at this pool before the change over to PPLNS awhile back. I like this pool.
Edit: Never mind I got my answer already with a quick payout THX... By the way where is FireDuck and why hasn’t he been around here lately?
|
|
|
|
Since newest bitcoind from git, I have errors on p2pool log: 2013-06-26 12:55:39.944779 p2pool (version 11.4-2-gf78a4e8)
2013-06-26 12:55:39.944959
2013-06-26 12:55:39.945105 Testing bitcoind RPC connection to 'http://127.0.0.1:8332/' with username 'bitcoinrpc'...
2013-06-26 12:55:40.068128 ...success!
2013-06-26 12:55:40.068220 Current block hash: d4710b27427c1d534bc78dac1c6863f3ebd04a55694b0ae4e8
2013-06-26 12:55:40.068277 Current block height: 243425
2013-06-26 12:55:40.068311
2013-06-26 12:55:40.068352 Testing bitcoind P2P connection to '127.0.0.1:8333'...
2013-06-26 12:55:40.100509 RECV version 71110100010000000000000039d6ca5100000000010000000000000000000000000000000000ffff000000000000010000000000000000000000000000000000ffff5869ab4b208dc9c543861df6eccf102f5361746f7368693a302e382e39392fe1b603...
2013-06-26 12:55:40.102466 > Error handling message: (see RECV line)
2013-06-26 12:55:40.102579 > Traceback (most recent call last):
2013-06-26 12:55:40.102732 > File "/usr/local/lib/python2.7/dist-packages/Twisted-13.0.0-py2.7-linux-x86_64.egg/twisted/internet/tcp.py", line 215, in doRead
2013-06-26 12:55:40.102819 > return self._dataReceived(data)
2013-06-26 12:55:40.102904 > File "/usr/local/lib/python2.7/dist-packages/Twisted-13.0.0-py2.7-linux-x86_64.egg/twisted/internet/tcp.py", line 221, in _dataReceived
2013-06-26 12:55:40.102984 > rval = self.protocol.dataReceived(data)
2013-06-26 12:55:40.103056 > File "/home/pioruns/p2pool/p2pool/util/p2protocol.py", line 26, in dataReceived
2013-06-26 12:55:40.103129 > self.dataReceived2(data)
2013-06-26 12:55:40.103220 > File "/home/pioruns/p2pool/p2pool/util/datachunker.py", line 40, in _DataChunker
2013-06-26 12:55:40.103292 > wants = receiver.send(buf.get(wants))
2013-06-26 12:55:40.103362 > --- <exception caught here> ---
2013-06-26 12:55:40.103448 > File "/home/pioruns/p2pool/p2pool/util/p2protocol.py", line 54, in dataReceiver
2013-06-26 12:55:40.103536 > self.packetReceived(command, type_.unpack(payload))
2013-06-26 12:55:40.103624 > File "/home/pioruns/p2pool/p2pool/util/pack.py", line 63, in unpack
2013-06-26 12:55:40.103718 > obj = self._unpack(data)
2013-06-26 12:55:40.103821 > File "/home/pioruns/p2pool/p2pool/util/pack.py", line 47, in _unpack
2013-06-26 12:55:40.103912 > raise LateEnd()
2013-06-26 12:55:40.104000 > p2pool.util.pack.LateEnd:
2013-06-26 12:55:40.104559 ...success!
2013-06-26 12:55:40.104644
2013-06-26 12:55:40.104760 Determining payout address...
2013-06-26 12:55:40.105005 ...success! Payout address: 1Lenny8KpVhqKvxwQFdYh7UZ6LFF4atY6z
2013-06-26 12:55:40.105087
2013-06-26 12:55:40.105247 Loading shares...
2013-06-26 12:55:42.221859 1000
2013-06-26 12:55:44.645612 2000
2013-06-26 12:55:47.023718 3000
2013-06-26 12:55:48.818631 4000
2013-06-26 12:55:50.557296 5000
2013-06-26 12:55:52.394567 6000
2013-06-26 12:55:54.305045 7000
2013-06-26 12:55:56.497315 8000
2013-06-26 12:55:58.507793 9000
2013-06-26 12:56:00.165688 10000
2013-06-26 12:56:02.333371 11000
2013-06-26 12:56:04.012640 12000
2013-06-26 12:56:05.586501 13000
2013-06-26 12:56:07.423243 14000
2013-06-26 12:56:09.057284 15000
2013-06-26 12:56:10.626802 16000
2013-06-26 12:56:12.608668 17000
2013-06-26 12:56:14.359926 18000
2013-06-26 12:56:16.323359 19000
2013-06-26 12:56:17.903745 20000
2013-06-26 12:56:19.619935 21000
2013-06-26 12:56:19.794666 ...done loading 21090 shares (12454 verified)!
2013-06-26 12:56:19.794790
2013-06-26 12:56:19.794824 Initializing work...
2013-06-26 12:56:23.137975 ...success!
2013-06-26 12:56:23.138095
2013-06-26 12:56:23.138131 Joining p2pool network using port 9333...
2013-06-26 12:56:23.235745 RECV version 71110100010000000000000064d6ca5100000000010000000000000000000000000000000000ffff000000000000010000000000000000000000000000000000ffff5869ab4b208db68c30145ddbb828102f5361746f7368693a302e382e39392fe1b603...
2013-06-26 12:56:23.236284 > Error handling message: (see RECV line)
2013-06-26 12:56:23.236346 > Traceback (most recent call last):
2013-06-26 12:56:23.236385 > File "/usr/local/lib/python2.7/dist-packages/Twisted-13.0.0-py2.7-linux-x86_64.egg/twisted/internet/tcp.py", line 215, in doRead
2013-06-26 12:56:23.236423 > return self._dataReceived(data)
2013-06-26 12:56:23.236459 > File "/usr/local/lib/python2.7/dist-packages/Twisted-13.0.0-py2.7-linux-x86_64.egg/twisted/internet/tcp.py", line 221, in _dataReceived
2013-06-26 12:56:23.236495 > rval = self.protocol.dataReceived(data)
2013-06-26 12:56:23.236530 > File "/home/pioruns/p2pool/p2pool/util/p2protocol.py", line 26, in dataReceived
2013-06-26 12:56:23.236566 > self.dataReceived2(data)
2013-06-26 12:56:23.236600 > File "/home/pioruns/p2pool/p2pool/util/datachunker.py", line 40, in _DataChunker
2013-06-26 12:56:23.236634 > wants = receiver.send(buf.get(wants))
2013-06-26 12:56:23.236667 > --- <exception caught here> ---
2013-06-26 12:56:23.236700 > File "/home/pioruns/p2pool/p2pool/util/p2protocol.py", line 54, in dataReceiver
2013-06-26 12:56:23.236736 > self.packetReceived(command, type_.unpack(payload))
2013-06-26 12:56:23.236769 > File "/home/pioruns/p2pool/p2pool/util/pack.py", line 63, in unpack
2013-06-26 12:56:23.236803 > obj = self._unpack(data)
2013-06-26 12:56:23.236836 > File "/home/pioruns/p2pool/p2pool/util/pack.py", line 47, in _unpack
2013-06-26 12:56:23.236870 > raise LateEnd()
2013-06-26 12:56:23.236904 > p2pool.util.pack.LateEnd:
2013-06-26 12:56:24.239385 RECV version 71110100010000000000000065d6ca5100000000010000000000000000000000000000000000ffff000000000000010000000000000000000000000000000000ffff5869ab4b208da170ba2446ed6ec1102f5361746f7368693a302e382e39392fe1b603...
2013-06-26 12:56:24.239831 > Error handling message: (see RECV line)
2013-06-26 12:56:24.239895 > Traceback (most recent call last):
2013-06-26 12:56:24.239951 > File "/usr/local/lib/python2.7/dist-packages/Twisted-13.0.0-py2.7-linux-x86_64.egg/twisted/internet/tcp.py", line 215, in doRead
2013-06-26 12:56:24.240026 > return self._dataReceived(data)
2013-06-26 12:56:24.240080 > File "/usr/local/lib/python2.7/dist-packages/Twisted-13.0.0-py2.7-linux-x86_64.egg/twisted/internet/tcp.py", line 221, in _dataReceived
2013-06-26 12:56:24.240138 > rval = self.protocol.dataReceived(data)
2013-06-26 12:56:24.240190 > File "/home/pioruns/p2pool/p2pool/util/p2protocol.py", line 26, in dataReceived
2013-06-26 12:56:24.240245 > self.dataReceived2(data)
2013-06-26 12:56:24.240297 > File "/home/pioruns/p2pool/p2pool/util/datachunker.py", line 40, in _DataChunker
2013-06-26 12:56:24.240351 > wants = receiver.send(buf.get(wants))
2013-06-26 12:56:24.240402 > --- <exception caught here> ---
2013-06-26 12:56:24.240452 > File "/home/pioruns/p2pool/p2pool/util/p2protocol.py", line 54, in dataReceiver
2013-06-26 12:56:24.240506 > self.packetReceived(command, type_.unpack(payload))
2013-06-26 12:56:24.240558 > File "/home/pioruns/p2pool/p2pool/util/pack.py", line 63, in unpack
2013-06-26 12:56:24.240611 > obj = self._unpack(data)
2013-06-26 12:56:24.240662 > File "/home/pioruns/p2pool/p2pool/util/pack.py", line 47, in _unpack
2013-06-26 12:56:24.240716 > raise LateEnd()
2013-06-26 12:56:24.240766 > p2pool.util.pack.LateEnd:
2013-06-26 12:56:25.448685 RECV version 71110100010000000000000066d6ca5100000000010000000000000000000000000000000000ffff000000000000010000000000000000000000000000000000ffff5869ab4b208dcd1f4482073bdb78102f5361746f7368693a302e382e39392fe1b603...
2013-06-26 12:56:25.449088 > Error handling message: (see RECV line)
2013-06-26 12:56:25.449150 > Traceback (most recent call last):
2013-06-26 12:56:25.449207 > File "/usr/local/lib/python2.7/dist-packages/Twisted-13.0.0-py2.7-linux-x86_64.egg/twisted/internet/tcp.py", line 215, in doRead
2013-06-26 12:56:25.449264 > return self._dataReceived(data)
2013-06-26 12:56:25.449318 > File "/usr/local/lib/python2.7/dist-packages/Twisted-13.0.0-py2.7-linux-x86_64.egg/twisted/internet/tcp.py", line 221, in _dataReceived
2013-06-26 12:56:25.449375 > rval = self.protocol.dataReceived(data)
2013-06-26 12:56:25.449428 > File "/home/pioruns/p2pool/p2pool/util/p2protocol.py", line 26, in dataReceived
2013-06-26 12:56:25.449491 > self.dataReceived2(data)
Linux 3.2.0-4-amd64 x86_64 GNU/Linux
Description: Debian GNU/Linux 7.1 (wheezy)
Python 2.7.3
Current p2pool version: 11.4-2-gf78a4e8 Current version: Bitcoin version v0.8.2-151-g4ad73c6-beta
commit 4ad73c6b080c46808b0c53b62ab6e4074e48dc75 i had to edit some of the p2pool code to get it to work, afaik anyone with 0.8.3 will get the same repeating error i may also try editing out the whole "punishing share" bit too later as some test, that's 3/3 orphans right now, occur within 5s of that I didn't get those errors and this is the version I am running Bitcoin-Qt version v0.8.3.0-g40809ae-betaI downloaded it from the link at top this page and complied from that src. Keep me posted about what you do to the punishing share code... |
|
|
|
Hi, sorry if this is the wrong place to ask. I'm new to p2pool.
I've got it setup and running (debian) and I just want to make sure things are looking OK. I have 330MH/s (AM USB eruptor). I've been running p2pool for 15 hrs, expected shares are ~5hrs, but I've only found 1 share. Is that something to be concerned about yet? Or is this amount of variance normal and I should sit tight? I don't have an issue letting it run longer waiting, but if it's already apparent that my setup is doing something wrong, that would be good to know if I need to roll my sleeves up. My getwork latency is ~1s. I apparently got 1 share so something is working...
Version: unknown 7032706f6f6c
Pool rate: 621GH/s (20% DOA+orphan) Share difficulty: 1190
Node uptime: 0.620 days Peers: 7 out, 0 in
Local rate: 308MH/s (9.3% DOA) Expected time to share: 4.60 hours
Shares: 1 total (0 orphaned, 0 dead) Efficiency: 124.7%
Payout if a block were found NOW: 0.00262778 BTC to xxx. Expected after mining for 24 hours: 0.0124 BTC per block.
Current block value: 25.28591 BTC Expected time to block: 37.2 hours
Also, I'm running the 11.4 release--is that recommended or do most people run the master branch from github?
Is peers in at 0 a problem? I can telnet to port 9333 from remote. Do I need more open ports?
1 share in 15 hrs is rough but plausible. The thing that stands out to me would be the local 9.3% DOA. If you haven’t adjusted the difficulty level that seems high. As far as 0 incoming, they should start trickling in but you need to open port 9332 and 9333. I will tell you to read the guide gyverlb has posted at https://bitcointalk.org/index.php?topic=153232.msg1626156#msg1626156edit: Yes 11.4 is the version you want yours just says unknown because you don't have it stored as a local git repository. edit2: I didn’t see the 1s latency until the poster below mentioned it. Start here https://bitcointalk.org/index.php?topic=18313.msg2256552#msg2256552 so you can get an idea of how to tune bitcoin (controversial subject). Also the guide I mentioned above covers this. |
|
|
|
Since newest bitcoind from git, I have errors on p2pool log: 2013-06-26 12:55:39.944779 p2pool (version 11.4-2-gf78a4e8)
2013-06-26 12:55:39.944959
2013-06-26 12:55:39.945105 Testing bitcoind RPC connection to 'http://127.0.0.1:8332/' with username 'bitcoinrpc'...
2013-06-26 12:55:40.068128 ...success!
2013-06-26 12:55:40.068220 Current block hash: d4710b27427c1d534bc78dac1c6863f3ebd04a55694b0ae4e8
2013-06-26 12:55:40.068277 Current block height: 243425
2013-06-26 12:55:40.068311
2013-06-26 12:55:40.068352 Testing bitcoind P2P connection to '127.0.0.1:8333'...
2013-06-26 12:55:40.100509 RECV version 71110100010000000000000039d6ca5100000000010000000000000000000000000000000000ffff000000000000010000000000000000000000000000000000ffff5869ab4b208dc9c543861df6eccf102f5361746f7368693a302e382e39392fe1b603...
2013-06-26 12:55:40.102466 > Error handling message: (see RECV line)
2013-06-26 12:55:40.102579 > Traceback (most recent call last):
2013-06-26 12:55:40.102732 > File "/usr/local/lib/python2.7/dist-packages/Twisted-13.0.0-py2.7-linux-x86_64.egg/twisted/internet/tcp.py", line 215, in doRead
2013-06-26 12:55:40.102819 > return self._dataReceived(data)
2013-06-26 12:55:40.102904 > File "/usr/local/lib/python2.7/dist-packages/Twisted-13.0.0-py2.7-linux-x86_64.egg/twisted/internet/tcp.py", line 221, in _dataReceived
2013-06-26 12:55:40.102984 > rval = self.protocol.dataReceived(data)
2013-06-26 12:55:40.103056 > File "/home/pioruns/p2pool/p2pool/util/p2protocol.py", line 26, in dataReceived
2013-06-26 12:55:40.103129 > self.dataReceived2(data)
2013-06-26 12:55:40.103220 > File "/home/pioruns/p2pool/p2pool/util/datachunker.py", line 40, in _DataChunker
2013-06-26 12:55:40.103292 > wants = receiver.send(buf.get(wants))
2013-06-26 12:55:40.103362 > --- <exception caught here> ---
2013-06-26 12:55:40.103448 > File "/home/pioruns/p2pool/p2pool/util/p2protocol.py", line 54, in dataReceiver
2013-06-26 12:55:40.103536 > self.packetReceived(command, type_.unpack(payload))
2013-06-26 12:55:40.103624 > File "/home/pioruns/p2pool/p2pool/util/pack.py", line 63, in unpack
2013-06-26 12:55:40.103718 > obj = self._unpack(data)
2013-06-26 12:55:40.103821 > File "/home/pioruns/p2pool/p2pool/util/pack.py", line 47, in _unpack
2013-06-26 12:55:40.103912 > raise LateEnd()
2013-06-26 12:55:40.104000 > p2pool.util.pack.LateEnd:
2013-06-26 12:55:40.104559 ...success!
2013-06-26 12:55:40.104644
2013-06-26 12:55:40.104760 Determining payout address...
2013-06-26 12:55:40.105005 ...success! Payout address: 1Lenny8KpVhqKvxwQFdYh7UZ6LFF4atY6z
2013-06-26 12:55:40.105087
2013-06-26 12:55:40.105247 Loading shares...
2013-06-26 12:55:42.221859 1000
2013-06-26 12:55:44.645612 2000
2013-06-26 12:55:47.023718 3000
2013-06-26 12:55:48.818631 4000
2013-06-26 12:55:50.557296 5000
2013-06-26 12:55:52.394567 6000
2013-06-26 12:55:54.305045 7000
2013-06-26 12:55:56.497315 8000
2013-06-26 12:55:58.507793 9000
2013-06-26 12:56:00.165688 10000
2013-06-26 12:56:02.333371 11000
2013-06-26 12:56:04.012640 12000
2013-06-26 12:56:05.586501 13000
2013-06-26 12:56:07.423243 14000
2013-06-26 12:56:09.057284 15000
2013-06-26 12:56:10.626802 16000
2013-06-26 12:56:12.608668 17000
2013-06-26 12:56:14.359926 18000
2013-06-26 12:56:16.323359 19000
2013-06-26 12:56:17.903745 20000
2013-06-26 12:56:19.619935 21000
2013-06-26 12:56:19.794666 ...done loading 21090 shares (12454 verified)!
2013-06-26 12:56:19.794790
2013-06-26 12:56:19.794824 Initializing work...
2013-06-26 12:56:23.137975 ...success!
2013-06-26 12:56:23.138095
2013-06-26 12:56:23.138131 Joining p2pool network using port 9333...
2013-06-26 12:56:23.235745 RECV version 71110100010000000000000064d6ca5100000000010000000000000000000000000000000000ffff000000000000010000000000000000000000000000000000ffff5869ab4b208db68c30145ddbb828102f5361746f7368693a302e382e39392fe1b603...
2013-06-26 12:56:23.236284 > Error handling message: (see RECV line)
2013-06-26 12:56:23.236346 > Traceback (most recent call last):
2013-06-26 12:56:23.236385 > File "/usr/local/lib/python2.7/dist-packages/Twisted-13.0.0-py2.7-linux-x86_64.egg/twisted/internet/tcp.py", line 215, in doRead
2013-06-26 12:56:23.236423 > return self._dataReceived(data)
2013-06-26 12:56:23.236459 > File "/usr/local/lib/python2.7/dist-packages/Twisted-13.0.0-py2.7-linux-x86_64.egg/twisted/internet/tcp.py", line 221, in _dataReceived
2013-06-26 12:56:23.236495 > rval = self.protocol.dataReceived(data)
2013-06-26 12:56:23.236530 > File "/home/pioruns/p2pool/p2pool/util/p2protocol.py", line 26, in dataReceived
2013-06-26 12:56:23.236566 > self.dataReceived2(data)
2013-06-26 12:56:23.236600 > File "/home/pioruns/p2pool/p2pool/util/datachunker.py", line 40, in _DataChunker
2013-06-26 12:56:23.236634 > wants = receiver.send(buf.get(wants))
2013-06-26 12:56:23.236667 > --- <exception caught here> ---
2013-06-26 12:56:23.236700 > File "/home/pioruns/p2pool/p2pool/util/p2protocol.py", line 54, in dataReceiver
2013-06-26 12:56:23.236736 > self.packetReceived(command, type_.unpack(payload))
2013-06-26 12:56:23.236769 > File "/home/pioruns/p2pool/p2pool/util/pack.py", line 63, in unpack
2013-06-26 12:56:23.236803 > obj = self._unpack(data)
2013-06-26 12:56:23.236836 > File "/home/pioruns/p2pool/p2pool/util/pack.py", line 47, in _unpack
2013-06-26 12:56:23.236870 > raise LateEnd()
2013-06-26 12:56:23.236904 > p2pool.util.pack.LateEnd:
2013-06-26 12:56:24.239385 RECV version 71110100010000000000000065d6ca5100000000010000000000000000000000000000000000ffff000000000000010000000000000000000000000000000000ffff5869ab4b208da170ba2446ed6ec1102f5361746f7368693a302e382e39392fe1b603...
2013-06-26 12:56:24.239831 > Error handling message: (see RECV line)
2013-06-26 12:56:24.239895 > Traceback (most recent call last):
2013-06-26 12:56:24.239951 > File "/usr/local/lib/python2.7/dist-packages/Twisted-13.0.0-py2.7-linux-x86_64.egg/twisted/internet/tcp.py", line 215, in doRead
2013-06-26 12:56:24.240026 > return self._dataReceived(data)
2013-06-26 12:56:24.240080 > File "/usr/local/lib/python2.7/dist-packages/Twisted-13.0.0-py2.7-linux-x86_64.egg/twisted/internet/tcp.py", line 221, in _dataReceived
2013-06-26 12:56:24.240138 > rval = self.protocol.dataReceived(data)
2013-06-26 12:56:24.240190 > File "/home/pioruns/p2pool/p2pool/util/p2protocol.py", line 26, in dataReceived
2013-06-26 12:56:24.240245 > self.dataReceived2(data)
2013-06-26 12:56:24.240297 > File "/home/pioruns/p2pool/p2pool/util/datachunker.py", line 40, in _DataChunker
2013-06-26 12:56:24.240351 > wants = receiver.send(buf.get(wants))
2013-06-26 12:56:24.240402 > --- <exception caught here> ---
2013-06-26 12:56:24.240452 > File "/home/pioruns/p2pool/p2pool/util/p2protocol.py", line 54, in dataReceiver
2013-06-26 12:56:24.240506 > self.packetReceived(command, type_.unpack(payload))
2013-06-26 12:56:24.240558 > File "/home/pioruns/p2pool/p2pool/util/pack.py", line 63, in unpack
2013-06-26 12:56:24.240611 > obj = self._unpack(data)
2013-06-26 12:56:24.240662 > File "/home/pioruns/p2pool/p2pool/util/pack.py", line 47, in _unpack
2013-06-26 12:56:24.240716 > raise LateEnd()
2013-06-26 12:56:24.240766 > p2pool.util.pack.LateEnd:
2013-06-26 12:56:25.448685 RECV version 71110100010000000000000066d6ca5100000000010000000000000000000000000000000000ffff000000000000010000000000000000000000000000000000ffff5869ab4b208dcd1f4482073bdb78102f5361746f7368693a302e382e39392fe1b603...
2013-06-26 12:56:25.449088 > Error handling message: (see RECV line)
2013-06-26 12:56:25.449150 > Traceback (most recent call last):
2013-06-26 12:56:25.449207 > File "/usr/local/lib/python2.7/dist-packages/Twisted-13.0.0-py2.7-linux-x86_64.egg/twisted/internet/tcp.py", line 215, in doRead
2013-06-26 12:56:25.449264 > return self._dataReceived(data)
2013-06-26 12:56:25.449318 > File "/usr/local/lib/python2.7/dist-packages/Twisted-13.0.0-py2.7-linux-x86_64.egg/twisted/internet/tcp.py", line 221, in _dataReceived
2013-06-26 12:56:25.449375 > rval = self.protocol.dataReceived(data)
2013-06-26 12:56:25.449428 > File "/home/pioruns/p2pool/p2pool/util/p2protocol.py", line 26, in dataReceived
2013-06-26 12:56:25.449491 > self.dataReceived2(data)
Linux 3.2.0-4-amd64 x86_64 GNU/Linux
Description: Debian GNU/Linux 7.1 (wheezy)
Python 2.7.3
Current p2pool version: 11.4-2-gf78a4e8 Current version: Bitcoin version v0.8.2-151-g4ad73c6-beta
commit 4ad73c6b080c46808b0c53b62ab6e4074e48dc75 here too I downloaded the .tar.gz from the direct link at the top of page (below login) and compiled from source. When I started bitcoin and p2pool I had an error in the p2pool log saying ports 9333 and 9332 are not open (not true) so I restarted ubuntu and that went away, all is working smoothly ( IT Crowd have you tried turning it off and back on again ). I see your version output says 0.8.2 the latest is now is 0.8.3. I also pulled the latest commits from p2pool as well. Other than my measly 200MH/s not finding shares fast enough all is good. |
|
|
|
ok, seriously:
(...)
is this a bug?
Looks like your bitcoind is behind. Your p2pool node know about new block but daemon still not got it. Thats why you "jumping from...to..." and probably thats why your shares are orphaned when you jumping. What would cause bitcoind to be behind p2pool? Could this be a result of limiting bitcoind connections? |
|
|
|
is this a bug?
Do you mean a bug in bitcoin 0.8.3? Are the problems still being caused by the same payout address as posted earlier? If so regardless of how long they’ve been mining someone should say something, if I remember correctly you said 50% of them were linked uuhh submitted (lack of a better word) to his slow node. |
|
|
|
OK, so I've been looking at my orphans for the last 10 days or so.... about 33% of them occur after a block solve.
i guess i should also mention that 50% of them are orphaned by 1CTgYxMTY5j6SLytKeMsBWAXuUc6yNKcAe and i know he isnt using an asic, so why so slow? How do you know it was that address, and is it wrong to assume that you have his ip address? If so ban him don't send any more work his way. Not that it matters but that address has a huge balance by the way... nah, he's a major contributor to p2pool. i think he's been mining it for years. i'm just whining and wish he had a faster setup. =p I can confirm that this address is mining since ages. The user behind may have changed his/her rigs since then but when the P2Pool mining started it was either GPU or FPGA based, seems the hashrate is fairly constant too: it always was around 50-60GH/s (computed from the payouts). If he is reading this thread, he should definitely upgrade his setup: he's probably able to shave quite a few more bitcoins by lowering his bitcoind latency (which is probably the reason why his setup is orphaning zvs shares on occasion instead of building on top of them). This should help us too: he may have mined orphan blocks (not sure of the probabilities though). I didn’t mean to sound so cold about it.... On another note I’m happy to hear that some are mining their jals on here. I am waiting on mine and want to stay here. I read that someone has raised the difficulty to 6000 on it. As salfter asked earlier won't this risk throwing out good work or is the point to just get the efficiency up regardless of what it throws out. Which brings up another question if jals are throwing out easier work and the efficiency is acceptable, isn't that good for lower hash rate miners? |
|
|
|
OK, so I've been looking at my orphans for the last 10 days or so.... about 33% of them occur after a block solve.
i guess i should also mention that 50% of them are orphaned by 1CTgYxMTY5j6SLytKeMsBWAXuUc6yNKcAe and i know he isnt using an asic, so why so slow? How do you know it was that address, and is it wrong to assume that you have his ip address? If so ban him don't send any more work his way. Not that it matters but that address has a huge balance by the way... |
|
|
|
|
Both of you guys have been extremely helpful to me so I'm reluctant to get in the middle here but isn't that what happens when you submit work for an old block.I found this in my log...
[2013-06-19 19:14:18] Stratum from pool 0 detected new block
edit: I realize I could have nothing useful to add here you two obviously are in a different league than me.
edit2: I'm sorry I do see your point now what did happen to '68f2aca3'?
|
|
|
|
|
Well I've got about 8 different ip addresses constantly submitting invalid hash, but I made the changes suggested above and their impact seems to be a lot smaller. Why are peers constantly submitting invalid hashes? Are they intentionally trying to spam the pool.. Am I being paranoid?
edit: After making the changes recommended above I unbanned all ip's that I had restricted and at first I was bombarded with a bunch of ip's submitting invalid hashes, but now that all of the hex data wasn't being sent (?) and their impact seems minimized. Now it's down to just 3 addresses doing it over and over. It may be premature but THX...
|
|
|
|
|
I started seeing this several times the last few days, same ip address each time.
2013-06-17 07:34:41.231070 invalid hash for 222.77.182.12 'remember_tx' 248861 872ef55d d295582b
2013-06-18 02:56:52.970716 > Peer referenced transaction twice, disconnecting
2013-06-18 02:56:52.976697 Lost peer 222.77.182.12:2288 -
2013-06-18 05:57:08.320456 > Peer referenced transaction twice, disconnecting
2013-06-18 05:57:08.321727 > Peer referenced transaction twice, disconnecting
2013-06-18 05:57:08.323347 > Peer referenced transaction twice, disconnecting
2013-06-18 05:57:08.324393 Lost peer 222.77.182.12:4187
Also this over and over and over.... I understand I will loose peers but this same one is doing this all day.
2013-06-18 17:25:41.304199 Incoming connection to peer 193.92.82.143:50029 established. p2pool version: 1100 '11.2'
2013-06-18 17:25:42.299477 Sending 1 shares to 193.92.82.143:50029
2013-06-18 17:25:42.301697 Lost peer 193.92.82.143:50029 - Connection to the other side was lost in a non-clean fashion.
I'm just going to ban both ip addresses for now. Is this something to concern myself with or is this normal?
edit: My latency smoothed out after banning them...
|
|
|
|
|
I'm still trying to wrap my head around why having all of the outgoing nodes helps. I made some changes zvs suggested dialled back a little with 30 outgoing vs. 60 like him because of bandwidth limitations but I don't get it. I'm not disagreeing because so far so good on my end (still too soon for any real conclusion) but I'm definitely confused.
|
|
|
|
yeah i got .045 btc with just 575MH mining for less than 24 hours, feel so good
default settings are the best, 130 efficiency 0 orphaned and only 1% doa
so you have 100 shares and 1 doa and 0 orphans? at 575mh in less than 24hrs? I think he's missing a zero in there... I was wondering if anyone has seen this? Today I finally received my units from Feb. 2 order. One unit was almost clean, while other one is moderate dusty. After checking all connections and desoldering F1 fuse, I started to configure units. First unit has been tuned to ozco.in and that is not surprise, cos same config was on my unit from batch one. Second unit has more interesting config: http://puu.sh/3hrak.pngAs you can see, first pool is eligius.st and most important is address: https://blockchain.info/address/1AYdAw8CcrQ2wx55LTbFHRn5bxgNZhaRLW?offset=0&filter=0716.40851602 BTC was mined from April 22 by various units. And only gods know, how much was mined on ozco.in. So, regardles what said Yifu, the answer is: YES, Team Avalon is mining with customer units.PS: I'm don't have any problems with fact, that Avalon is mining with my units, if this is burn test and not introducing shipment delays. |
|
|
|
We gotta get bfl to work
Agreed mine should be here soon and I really want to stay with p2pool. |
|
|
|
|
Show Posts
