idonothave
|
|
December 12, 2015, 12:47:02 PM |
|
Yes, on the standard p2pool web GUI every address can be seen. PS: BLOCK!! That's odd, as I'm passing through the mining addresses as can be seen by how little is being credited to me. P.S. 2nd share too. EDIT: You're right, something's amuck. Your miners are supposed to be forced to reconnect by the proxy but they're not. I'm looking into it right now. I may restart the node a few times while I implement code changes, bear with me (and always have a failover as you already know). no problem, I understand we are in testing mode. let as know
|
|
|
|
-ck
Legendary
Offline
Activity: 4242
Merit: 1644
Ruu \o/
|
|
December 12, 2015, 12:47:54 PM |
|
Yes, on the standard p2pool web GUI every address can be seen. PS: BLOCK!! That's odd, as I'm passing through the mining addresses as can be seen by how little is being credited to me. P.S. 2nd share too. EDIT: You're right, something's amuck. Your miners are supposed to be forced to reconnect by the proxy but they're not. I'm looking into it right now. I may restart the node a few times while I implement code changes, bear with me (and always have a failover as you already know). Taking them down for a bit, they're not doing what they're supposed to. Redirecting the port directly to the p2pool node for the time being.
|
Developer/maintainer for cgminer, ckpool/ckproxy, and the -ck kernel 2% Fee Solo mining at solo.ckpool.org -ck
|
|
|
p3yot33at3r
|
|
December 12, 2015, 01:21:17 PM |
|
No worries, I see my miner is still reporting the node as live so I'll just leave it as is.
|
|
|
|
windpath
Legendary
Offline
Activity: 1258
Merit: 1027
|
|
December 12, 2015, 01:34:34 PM |
|
Many thanks again -ck. With all the nastyness going on atm, it's great that a dev such as yourself is willing to step in & help out us p2poolers Incredibly the DE node has already found a share. Yeah, I saw that I'm not seeing my payout address in the graphs for some reason: 17RAoAa2ZJy5vh2YNwx2NMHijrRmAajGr2 you cannot see it because it is working with default address which is sense of the thing future payouts is another thing and he ck has there different solution then p2pool originaly has or? Does the p2pool intrinsic web page usually show miners logged into a public node as separate addresses? I currently have 2 active miners in the proxy logs: [2015-12-12 06:38:53.071] User 1PXJiWRQt3gNBAe4j6dbugEqhufJdgncCc:{"hashrate1m": "1.48T", "hashrate5m": "1.36T", "hashrate1hr": "658G", "hashrate1d": "36.5G", "hashrate7d": "5.27G", "lastupdate": 1449920333, "workers": 1, "shares": 741666, "bestshare": 2691098.6662059599} [2015-12-12 06:38:53.071] User 17RAoAa2ZJy5vh2YNwx2NMHijrRmAajGr2:{"hashrate1m": "381G", "hashrate5m": "380G", "hashrate1hr": "134G", "hashrate1d": "7.03G", "hashrate7d": "1.01G", "lastupdate": 1449920333, "workers": 1, "shares": 142968, "bestshare": 475613.94521986018}
If all is going correctly, 1PXJiWRQt3gNBAe4j6dbugEqhufJdgncCc got the share and as far as I can tell it was credited to him, and only 1% credited to my 1GYU9ouTVY6ECTqidLe96mWn485dP6WZaJ address. Very cool CK! If I remember correctly how the node fee works it is not 1% of each share but 1% of shares... So if a miner finds 100 shares on your node ~99 go to him and ~1 go to you...
|
|
|
|
-ck
Legendary
Offline
Activity: 4242
Merit: 1644
Ruu \o/
|
|
December 12, 2015, 03:00:51 PM |
|
No worries, I see my miner is still reporting the node as live so I'll just leave it as is.
Ok they're back up and I can see the extra miners listed now. Let's see what breaks next
|
Developer/maintainer for cgminer, ckpool/ckproxy, and the -ck kernel 2% Fee Solo mining at solo.ckpool.org -ck
|
|
|
p3yot33at3r
|
|
December 12, 2015, 03:04:34 PM |
|
Let's see what breaks next That'll be me..... I can see the addresses on the web UI now - good stuff -ck Edit: Ouch - that DOA rate........
|
|
|
|
-ck
Legendary
Offline
Activity: 4242
Merit: 1644
Ruu \o/
|
|
December 12, 2015, 03:46:41 PM |
|
Edit: Ouch - that DOA rate........
Almost 3 am, but... What's normal/good?
|
Developer/maintainer for cgminer, ckpool/ckproxy, and the -ck kernel 2% Fee Solo mining at solo.ckpool.org -ck
|
|
|
windpath
Legendary
Offline
Activity: 1258
Merit: 1027
|
|
December 12, 2015, 04:07:17 PM |
|
Edit: Ouch - that DOA rate........
Almost 3 am, but... What's normal/good? Ideally you want to be equal to or better than the global pool DOA...
|
|
|
|
p3yot33at3r
|
|
December 12, 2015, 04:22:48 PM |
|
Edit: Ouch - that DOA rate........
Almost 3 am, but... What's normal/good? Mine sits at about 3% - but it's a local private node.
|
|
|
|
Meuh6879
Legendary
Offline
Activity: 1512
Merit: 1012
|
|
December 12, 2015, 08:22:18 PM |
|
|
|
|
|
-ck
Legendary
Offline
Activity: 4242
Merit: 1644
Ruu \o/
|
|
December 12, 2015, 09:30:50 PM |
|
Edit: Ouch - that DOA rate........
Almost 3 am, but... What's normal/good? Mine sits at about 3% - but it's a local private node. Yeah, don't know what to make of it. The overnight run saw 9 shares come in total without any orphans or dead but of course you need about 100 shares to get a fair idea of the real efficiency. I can understand if you move your miner away and appreciate the testing you did initially to confirm it works though, thanks. It's been a while since I've played with p2pool though and something is really bugging me that I spot in the logs. I was wondering if anyone could answer me since my python knowledge is almost non-existent. On block changes, I'm NOT seeing p2pool immediately ask for a new block template when looking at my bitcoind logs which I have extra debugging on. Take for example this last block: The block came in here: 2015-12-12 21:11:05.242988 UpdateTip: new best
And p2pool asked for the first newblock template here: 2015-12-12 21:11:23.387677 CreateNewBlock Note the timestamps. There are 18 seconds between the block change and the first block template request. Now on my pool software I get a new template within milliseconds of the block update. So here's the question. Is p2pool by design not updating immediately on block changes and hashing on stale work? Am I missing something?
|
Developer/maintainer for cgminer, ckpool/ckproxy, and the -ck kernel 2% Fee Solo mining at solo.ckpool.org -ck
|
|
|
p3yot33at3r
|
|
December 12, 2015, 09:35:39 PM |
|
It's been a while since I've played with p2pool though and something is really bugging me that I spot in the logs. I was wondering if anyone could answer me since my python knowledge is almost non-existent. On block changes, I'm NOT seeing p2pool immediately ask for a new block template when looking at my bitcoind logs which I have extra debugging on. Take for example this last block: The block came in here: 2015-12-12 21:11:05.242988 UpdateTip: new best
And p2pool asked for the first newblock template here: 2015-12-12 21:11:23.387677 CreateNewBlock Note the timestamps. There are 18 seconds between the block change and the first block template request. Now on my pool software I get a new template within milliseconds of the block update. So here's the question. Is p2pool by design not updating immediately on block changes and hashing on stale work? Am I missing something? Above my paygrade I'm afraid - maybe forrestv can chime in here?
|
|
|
|
-ck
Legendary
Offline
Activity: 4242
Merit: 1644
Ruu \o/
|
|
December 12, 2015, 09:42:39 PM |
|
Well I've never really investigated the work model in p2pool and perhaps it's building on the work in its own chain somehow and not dependent on bitcoind? I see lots of blocktemplate calls to bitcoind the rest of the time though.
|
Developer/maintainer for cgminer, ckpool/ckproxy, and the -ck kernel 2% Fee Solo mining at solo.ckpool.org -ck
|
|
|
p3yot33at3r
|
|
December 12, 2015, 09:45:46 PM |
|
Well I've never really investigated the work model in p2pool and perhaps it's building on the work in its own chain somehow and not dependent on bitcoind?
That's pretty much how I understand it to work, but I'm sure there's a little more to it than that.
|
|
|
|
forrestv (OP)
|
|
December 12, 2015, 10:11:05 PM |
|
P2Pool should immediately call getblocktemplate after it knows that there is a new block. It is notified that there is a new block via its P2P connection to bitcoind, through which bitcoind sents an inv message when it has a new block. The code that does this is the work_poller in node.py. The reason that you saw a 18 second delay is something within that loop. Maybe bitcoind was lagging and took a long time to announce the block after it printed "new best"? Or maybe P2Pool was lagging and took a long time to respond. Is the delay always long or just for this one block?
That said, P2Pool will generate its own work if it knows that there is a new block (via its P2Pool peers) and bitcoind hasn't given it new work yet. These blocks will be empty, though. It's just a stopgap solution for bitcoind sometimes taking a long time to catch up.
In other news, a lot of users (or one big user) upgraded to v15 in the last day, and we'll probably be fine when BIP65 takes effect.
|
1J1zegkNSbwX4smvTdoHSanUfwvXFeuV23
|
|
|
-ck
Legendary
Offline
Activity: 4242
Merit: 1644
Ruu \o/
|
|
December 12, 2015, 10:15:45 PM Last edit: December 12, 2015, 10:32:26 PM by -ck |
|
P2Pool should immediately call getblocktemplate after it knows that there is a new block. It is notified that there is a new block via its P2P connection to bitcoind, through which bitcoind sents an inv message when it has a new block. The code that does this is the work_poller in node.py. The reason that you saw a 18 second delay is something within that loop. Maybe bitcoind was lagging and took a long time to announce the block after it printed "new best"? Or maybe P2Pool was lagging and took a long time to respond. Is the delay always long or just for this one block?
Thanks for that. No this bitcoind is very rapid with its responses. It's set up the same as I use for my own pool. This happened routinely, not just the one block though. Here are the 3 before it: 2015-12-12 21:51:12.963648 UpdateTip: 2015-12-12 21:51:32.679893 CreateNewBlock
2015-12-12 21:44:06.200074 UpdateTip: 2015-12-12 21:44:26.030397 CreateNewBlock
2015-12-12 21:42:07.479248 UpdateTip: 2015-12-12 21:42:26.094565 CreateNewBlock
I'm running current git master head. That said, P2Pool will generate its own work if it knows that there is a new block (via its P2Pool peers) and bitcoind hasn't given it new work yet. These blocks will be empty, though. It's just a stopgap solution for bitcoind sometimes taking a long time to catch up.
EDIT: Perhaps that actually explains these recent blocks then which are empty: https://www.blocktrail.com/BTC/block/00000000000000000842de6ff4793f59ab08139a253f7e5622926f9d470c1ae9https://www.blocktrail.com/BTC/block/000000000000000010e4a73a4abf8bd304809c021d636b1f39013ddf6e437d3c
|
Developer/maintainer for cgminer, ckpool/ckproxy, and the -ck kernel 2% Fee Solo mining at solo.ckpool.org -ck
|
|
|
forrestv (OP)
|
|
December 12, 2015, 10:42:07 PM |
|
Hmm, can you apply this[1] patch to P2Pool and post the relevant log sections of both bitcoind and P2Pool? 1: http://im.forre.st/pb/80707844.txt
|
1J1zegkNSbwX4smvTdoHSanUfwvXFeuV23
|
|
|
-ck
Legendary
Offline
Activity: 4242
Merit: 1644
Ruu \o/
|
|
December 13, 2015, 12:37:05 AM |
|
Running it now, will report back in a bit. Captured one Bitcoind: 2015-12-12 23:45:46.055397 UpdateTip: new best=0000000000000000057896223e152a585b48c27bfd0757f901116f4df1a026b2 2015-12-12 23:46:04.861979 CreateNewBlock()
p2pool: 2015-12-12 18:45:43.226373 work_poller sleeping 2015-12-12 18:45:44.580614 P2Pool: 17510 shares in chain (10184 verified/17514 total) Peers: 7 (0 incoming) 2015-12-12 18:45:44.580730 Local: 859GH/s in last 2.8 minutes Local dead on arrival: ~4.9% (3-7%) Expected time to share: 2.3 hours 2015-12-12 18:45:44.580780 Shares: 0 (0 orphan, 0 dead) Stale rate: ??? Efficiency: ??? Current payout: (0.0018)=0.0018 BTC 2015-12-12 18:45:44.580821 Pool: 613TH/s Stale rate: 20.5% Expected time to block: 6.4 days 2015-12-12 18:45:46.060562 work_poller triggered 0 2015-12-12 18:45:46.591346 Skipping from block c961a121526cc3eea1788faec200b43ab71db3853833a8e to block 57896223e152a585b48c27bfd0757f901116f4df1a026b2! 2015-12-12 18:45:46.604193 New work for worker! Difficulty: 1300.617269 Share difficulty: 9373917.033071 Total block value: 25.000000 BTC including 0 transactions 2015-12-12 18:45:46.862936 Punishing share for 'Block-stale detected! height(c961a121526cc3eea1788faec200b43ab71db3853833a8e) < height(57896223e152a585b48c27bfd0757f901116f4df1a026b2) or 180de64f != 180de64f'! Jumping from 18b25839 to 301798e2! 2015-12-12 18:45:49.709867 work_poller sleeping 2015-12-12 18:45:49.723776 P2Pool: 17509 shares in chain (10184 verified/17514 total) Peers: 7 (0 incoming) 2015-12-12 18:45:49.723931 Local: 863GH/s in last 2.9 minutes Local dead on arrival: ~4.9% (3-7%) Expected time to share: 2.3 hours 2015-12-12 18:45:49.723991 Shares: 0 (0 orphan, 0 dead) Stale rate: ??? Efficiency: ??? Current payout: (0.0017)=0.0017 BTC 2015-12-12 18:45:49.724073 Pool: 616TH/s Stale rate: 20.5% Expected time to block: 6.4 days 2015-12-12 18:45:51.569227 Punishing share for 'Block-stale detected! height(c961a121526cc3eea1788faec200b43ab71db3853833a8e) < height(57896223e152a585b48c27bfd0757f901116f4df1a026b2) or 180de64f != 180de64f'! Jumping from 18b25839 to 301798e2! 2015-12-12 18:45:51.578247 Punishing share for 'Block-stale detected! height(c961a121526cc3eea1788faec200b43ab71db3853833a8e) < height(57896223e152a585b48c27bfd0757f901116f4df1a026b2) or 180de64f != 180de64f'! Jumping from 18b25839 to 301798e2! 2015-12-12 18:45:52.095941 Peer sent entire transaction a2f01bd80b0b08eac507b98b7d4cfcebf291148f350e8d48f344b6d8dc295308 that was already received 2015-12-12 18:45:52.341543 Peer sent entire transaction c0dea60acb5a945e4dbfe490533555aa747b82cf358e5b81b311f97975061a76 that was already received 2015-12-12 18:45:52.734235 P2Pool: 17509 shares in chain (10184 verified/17514 total) Peers: 7 (0 incoming) 2015-12-12 18:45:52.734375 Local: 877GH/s in last 2.9 minutes Local dead on arrival: ~5.0% (3-7%) Expected time to share: 2.3 hours 2015-12-12 18:45:52.734432 Shares: 0 (0 orphan, 0 dead) Stale rate: ??? Efficiency: ??? Current payout: (0.0017)=0.0017 BTC 2015-12-12 18:45:52.734493 Pool: 616TH/s Stale rate: 20.5% Expected time to block: 6.4 days 2015-12-12 18:45:55.739050 P2Pool: 17509 shares in chain (10184 verified/17514 total) Peers: 7 (0 incoming) 2015-12-12 18:45:55.739190 Local: 893GH/s in last 3.0 minutes Local dead on arrival: ~5.1% (3-7%) Expected time to share: 2.2 hours 2015-12-12 18:45:55.739244 Shares: 0 (0 orphan, 0 dead) Stale rate: ??? Efficiency: ??? Current payout: (0.0017)=0.0017 BTC 2015-12-12 18:45:55.739283 Pool: 616TH/s Stale rate: 20.5% Expected time to block: 6.4 days 2015-12-12 18:45:56.595158 Punishing share for 'Block-stale detected! height(c961a121526cc3eea1788faec200b43ab71db3853833a8e) < height(57896223e152a585b48c27bfd0757f901116f4df1a026b2) or 180de64f != 180de64f'! Jumping from 18b25839 to 301798e2! 2015-12-12 18:45:56.606212 Punishing share for 'Block-stale detected! height(c961a121526cc3eea1788faec200b43ab71db3853833a8e) < height(57896223e152a585b48c27bfd0757f901116f4df1a026b2) or 180de64f != 180de64f'! Jumping from 18b25839 to 301798e2! 2015-12-12 18:45:57.728314 Peer sent entire transaction b162860a4358618d94e89809bea4f8471e3f581c0dc1f407faecda09676713a5 that was already received 2015-12-12 18:45:58.753944 P2Pool: 17509 shares in chain (10184 verified/17514 total) Peers: 7 (0 incoming) 2015-12-12 18:45:58.754053 Local: 940GH/s in last 3.0 minutes Local dead on arrival: ~5.2% (4-7%) Expected time to share: 2.1 hours 2015-12-12 18:45:58.754113 Shares: 0 (0 orphan, 0 dead) Stale rate: ??? Efficiency: ??? Current payout: (0.0017)=0.0017 BTC 2015-12-12 18:45:58.754161 Pool: 616TH/s Stale rate: 20.5% Expected time to block: 6.4 days 2015-12-12 18:46:01.631496 Punishing share for 'Block-stale detected! height(c961a121526cc3eea1788faec200b43ab71db3853833a8e) < height(57896223e152a585b48c27bfd0757f901116f4df1a026b2) or 180de64f != 180de64f'! Jumping from 18b25839 to 301798e2! 2015-12-12 18:46:01.643085 Punishing share for 'Block-stale detected! height(c961a121526cc3eea1788faec200b43ab71db3853833a8e) < height(57896223e152a585b48c27bfd0757f901116f4df1a026b2) or 180de64f != 180de64f'! Jumping from 18b25839 to 301798e2! 2015-12-12 18:46:01.779099 P2Pool: 17509 shares in chain (10184 verified/17514 total) Peers: 7 (0 incoming) 2015-12-12 18:46:01.779293 Local: 955GH/s in last 3.1 minutes Local dead on arrival: ~5.2% (4-7%) Expected time to share: 2.1 hours 2015-12-12 18:46:01.779401 Shares: 0 (0 orphan, 0 dead) Stale rate: ??? Efficiency: ??? Current payout: (0.0017)=0.0017 BTC 2015-12-12 18:46:01.779491 Pool: 616TH/s Stale rate: 20.5% Expected time to block: 6.4 days 2015-12-12 18:46:04.636870 New work for worker! Difficulty: 1413.903366 Share difficulty: 9448997.950860 Total block value: 25.114565 BTC including 2345 transactions 2015-12-12 18:46:04.823342 work_poller triggered 1 2015-12-12 18:46:04.835841 P2Pool: 17510 shares in chain (10185 verified/17515 total) Peers: 7 (0 incoming) 2015-12-12 18:46:04.835984 Local: 969GH/s in last 3.1 minutes Local dead on arrival: ~5.2% (4-7%) Expected time to share: 2.0 hours 2015-12-12 18:46:04.836040 Shares: 0 (0 orphan, 0 dead) Stale rate: ??? Efficiency: ??? Current payout: (0.0017)=0.0017 BTC 2015-12-12 18:46:04.836098 Pool: 608TH/s Stale rate: 20.5% Expected time to block: 6.5 days 2015-12-12 18:46:06.747933 work_poller sleeping
EDIT: looks ok to me. Maybe it's just bitcoind hiding the call debug message. I'll investigate further at my end with more debugging in bitcoind, thanks. Investigated further and added debugging to see when GBT was called since calls to CNB are cached and it is indeed calling GBT immediately after a blockchange, so this was all my fault for not noticing, sorry about the noise.
|
Developer/maintainer for cgminer, ckpool/ckproxy, and the -ck kernel 2% Fee Solo mining at solo.ckpool.org -ck
|
|
|
windpath
Legendary
Offline
Activity: 1258
Merit: 1027
|
|
December 13, 2015, 01:15:46 AM Last edit: December 14, 2015, 02:19:11 PM by windpath |
|
Edit: Ouch - that DOA rate........
Almost 3 am, but... What's normal/good? Mine sits at about 3% - but it's a local private node. Yeah, don't know what to make of it. The overnight run saw 9 shares come in total without any orphans or dead but of course you need about 100 shares to get a fair idea of the real efficiency. I can understand if you move your miner away and appreciate the testing you did initially to confirm it works though, thanks. It's been a while since I've played with p2pool though and something is really bugging me that I spot in the logs. I was wondering if anyone could answer me since my python knowledge is almost non-existent. On block changes, I'm NOT seeing p2pool immediately ask for a new block template when looking at my bitcoind logs which I have extra debugging on. Take for example this last block: The block came in here: 2015-12-12 21:11:05.242988 UpdateTip: new best
And p2pool asked for the first newblock template here: 2015-12-12 21:11:23.387677 CreateNewBlock Note the timestamps. There are 18 seconds between the block change and the first block template request. Now on my pool software I get a new template within milliseconds of the block update. So here's the question. Is p2pool by design not updating immediately on block changes and hashing on stale work? Am I missing something? edit: see Forrest's answer above... I *believe* (and may be incorrect) that p2pool will wait for a valid share (pool wide) before sending new work @ 30 seconds on average. I recall a couple years ago discussing this with someone. As P2Pool does not subscribe to bitcoind blocknotify it is not aware of the block change...
If I am right and this is the case, setting up a blocknotify flag in Bitcoin.conf and integrating it into the code should not be to hard, but I suspect there is a reason Forrest set it up this way? (Or maybe -blocknotify did not exist then?)
|
|
|
|
-ck
Legendary
Offline
Activity: 4242
Merit: 1644
Ruu \o/
|
|
December 13, 2015, 07:34:36 AM |
|
I *believe* (and may be incorect) that p2pool will wait for a valid share (pool wide) before sending new work @ 30 seconds on average. I recall a couple years ago discussing this with someone. As P2Pool does not subscribe to bitcoind blocknotify it is not aware of the block change...
If I am right and this is the case, setting up a blocknotify flag in Bitcoin.conf and integrating it into the code should not be to hard, but I suspect there is a reason Forrest set it up this way? (Or maybe -blocknotify did not exist then?)
Yeah sorry this was my mistake at misreading what debug output I had so it was a false positive. Investigated further and added debugging to see when GBT was called since calls to CNB are cached and it is indeed calling GBT immediately after a blockchange, so this was all my fault for not noticing, sorry about the noise.
|
Developer/maintainer for cgminer, ckpool/ckproxy, and the -ck kernel 2% Fee Solo mining at solo.ckpool.org -ck
|
|
|
|