bitpop
Legendary
Offline
Activity: 2912
Merit: 1060
|
|
July 14, 2013, 07:56:22 PM |
|
Pretty selfish
|
|
|
|
BTCMiners.net
|
|
July 14, 2013, 08:02:36 PM |
|
I have 6 GH/s pointed to P2Pool. Can I get a %% update it currently is at?
|
|
|
|
notme
Legendary
Offline
Activity: 1904
Merit: 1002
|
|
July 14, 2013, 08:03:29 PM |
|
Pretty selfish
But it could hurt revenue by 5% for a whole day! He certainly can't afford that.... unless he has a fast connection and fast hard drives. Then his 110%+ efficiency would make up for it .
|
|
|
|
notme
Legendary
Offline
Activity: 1904
Merit: 1002
|
|
July 14, 2013, 08:03:49 PM |
|
I have 6 GH/s pointed to P2Pool. Can I get a %% update it currently is at?
Switchover imminent. Upgraded: 66.962% Threshold: 95.000%
|
|
|
|
BTCMiners.net
|
|
July 14, 2013, 08:07:22 PM |
|
I have 6 GH/s pointed to P2Pool. Can I get a %% update it currently is at?
Switchover imminent. Upgraded: 66.962% Threshold: 95.000% *sigh* Was hoping it would be higher by now. Thanks for the update though.
|
|
|
|
gyverlb
|
|
July 14, 2013, 08:17:15 PM |
|
I have 6 GH/s pointed to P2Pool. Can I get a %% update it currently is at?
Switchover imminent. Upgraded: 66.962% Threshold: 95.000% ? I'm seeing an average of 91% over last 24h in the graphs and a big chunk of hashrate switched over less than 24 hours ago. The switch should happen in the next 48h. Hashrate has been rising too: it's at ~1.4TH/s. Exciting times for p2pool, we may regain a spot in the top 5 pools if enough people join and lower variance:currently only people understanding variance and able to afford it are on p2pool, with lower variance more people will join.
|
|
|
|
notme
Legendary
Offline
Activity: 1904
Merit: 1002
|
|
July 14, 2013, 08:25:36 PM |
|
I have 6 GH/s pointed to P2Pool. Can I get a %% update it currently is at?
Switchover imminent. Upgraded: 66.962% Threshold: 95.000% ? I'm seeing an average of 91% over last 24h in the graphs and a big chunk of hashrate switched over less than 24 hours ago. The switch should happen in the next 48h. Hashrate has been rising too: it's at ~1.4TH/s. Exciting times for p2pool, we may regain a spot in the top 5 pools if enough people join and lower variance:currently only people understanding variance and able to afford it are on p2pool, with lower variance more people will join. There is 12 hour lag. the changes will take effect 12 hours after 95% of the mining power has been upgraded, as usual.
I guess it will be a little while yet. Still, I would agree with your 48 hour estimate.
|
|
|
|
CartmanSPC
Legendary
Offline
Activity: 1270
Merit: 1000
|
|
July 14, 2013, 08:38:50 PM |
|
Could someone explain the changes in SHARE_PERIOD and SPREAD? I understand it's to support ASICs in some way but can we get a more detailed explanation as to what these setting do? Bitcoin: SHARE_PERIOD=10, # seconds NEW_SHARE_PERIOD=30, # seconds
SPREAD=3, # blocks NEW_SPREAD=3, # blocks
Litecoin: SHARE_PERIOD=10, # seconds NEW_SHARE_PERIOD=15, # seconds
SPREAD=12, # blocks NEW_SPREAD=3, # blocks Thanks!
|
|
|
|
notme
Legendary
Offline
Activity: 1904
Merit: 1002
|
|
July 14, 2013, 08:52:37 PM |
|
Could someone explain the changes in SHARE_PERIOD and SPREAD? I understand it's to support ASICs in some way but can we get a more detailed explanation as to what these setting do? Bitcoin: SHARE_PERIOD=10, # seconds NEW_SHARE_PERIOD=30, # seconds
SPREAD=3, # blocks NEW_SPREAD=3, # blocks
Litecoin: SHARE_PERIOD=10, # seconds NEW_SHARE_PERIOD=15, # seconds
SPREAD=12, # blocks NEW_SPREAD=3, # blocks Thanks! I'm not sure about SPREAD, but SHARE_PERIOD is the target time between shares. Essentially, the sharechain is blockchain of valid bitcoin blocks, but it has a target block time of SHARE_PERIOD. The payouts for valid blocks have to pay out to the last CHAIN_LENGTH shares.
|
|
|
|
maqifrnswa
|
|
July 14, 2013, 09:19:34 PM |
|
Could someone explain the changes in SHARE_PERIOD and SPREAD? I understand it's to support ASICs in some way but can we get a more detailed explanation as to what these setting do? Bitcoin: SHARE_PERIOD=10, # seconds NEW_SHARE_PERIOD=30, # seconds
SPREAD=3, # blocks NEW_SPREAD=3, # blocks
Litecoin: SHARE_PERIOD=10, # seconds NEW_SHARE_PERIOD=15, # seconds
SPREAD=12, # blocks NEW_SPREAD=3, # blocks Thanks! I'm not sure about SPREAD, but SHARE_PERIOD is the target time between shares. Essentially, the sharechain is blockchain of valid bitcoin blocks, but it has a target block time of SHARE_PERIOD. The payouts for valid blocks have to pay out to the last CHAIN_LENGTH shares. SPREAD is basically how long will p2pool remember shares in units of expected time to share. If it should take 10 hours for a share, a spread of 3 means shares are remembered for 30 hours (although there is a cap of 24 hours, this is more important to LTC as of now).
|
|
|
|
notme
Legendary
Offline
Activity: 1904
Merit: 1002
|
|
July 14, 2013, 10:56:51 PM Last edit: July 14, 2013, 11:25:38 PM by notme |
|
Did we just fork? My "Expected time to share" just tripled. I'm also not seeing the "Switchover imminent" messages anymore. Edit: It appears so... this was the last switchover message in my log (time is EST). 2013-07-14 18:36:51.640422 Switchover imminent. Upgraded: 92.061% Threshold: 95.000%
After which I see several of these: 2013-07-14 18:38:52.620338 Lost peer <ip:port removed> - 2013-07-14 18:38:52.620455 Connection was aborted locally, using 2013-07-14 18:38:52.620595 L{twisted.internet.interfaces.ITCPTransport.abortConnection}. 2013-07-14 18:38:52.620723 2013-07-14 18:38:52.620843 @since: 11.1
I'm looking forward to ASIC reports. I can recommend this guide for setting up and tuning p2pool (just mind that it might not yet be updated for the ASIC friendly changes this fork brings, so don't be discouraged by the warnings): https://bitcointalk.org/index.php?topic=153232.0I would like to see my tiny 20GH/s get knocked out of the top 10
|
|
|
|
lenny_
Legendary
Offline
Activity: 1036
Merit: 1000
DARKNETMARKETS.COM
|
|
July 15, 2013, 12:37:59 AM |
|
Errors in new version: Linux 3.2.0-4-amd64 x86_64 GNU/Linux Description: Debian GNU/Linux 7.1 (wheezy) Python 2.7.3 Current p2pool version: 13.1 2013-07-15 01:23:20.739541 P2Pool: 17343 shares in chain (17347 verified/17347 total) Peers: 7 (1 incoming) 2013-07-15 01:23:20.739646 Local: 0H/s in last 10.0 minutes Local dead on arrival: ??? Expected time to share: ??? 2013-07-15 01:23:20.739683 Shares: 0 (0 orphan, 0 dead) Stale rate: ??? Efficiency: ??? Current payout: 0.0000 BTC 2013-07-15 01:23:20.739726 Pool: 1280GH/s Stale rate: 15.5% Expected time to block: 1.0 days 2013-07-15 01:23:24.094661 > Error in DeferredResource handler: 2013-07-15 01:23:24.094747 > Traceback (most recent call last): 2013-07-15 01:23:24.094779 > File "/home/pioruns/p2pool/p2pool/util/deferred_resource.py", line 24, in render 2013-07-15 01:23:24.094810 > defer.maybeDeferred(resource.Resource.render, self, request).addCallbacks(finish, finish_error) 2013-07-15 01:23:24.094843 > File "/usr/local/lib/python2.7/dist-packages/Twisted-13.0.0-py2.7-linux-x86_64.egg/twisted/internet/defer.py", line 137, in maybeDeferred 2013-07-15 01:23:24.094875 > result = f(*args, **kw) 2013-07-15 01:23:24.094904 > File "/usr/local/lib/python2.7/dist-packages/Twisted-13.0.0-py2.7-linux-x86_64.egg/twisted/web/resource.py", line 250, in render 2013-07-15 01:23:24.094935 > return m(request) 2013-07-15 01:23:24.094964 > File "/usr/local/lib/python2.7/dist-packages/Twisted-13.0.0-py2.7-linux-x86_64.egg/twisted/internet/defer.py", line 1213, in unwindGenerator 2013-07-15 01:23:24.094995 > return _inlineCallbacks(None, gen, Deferred()) 2013-07-15 01:23:24.095023 > --- <exception caught here> --- 2013-07-15 01:23:24.095051 > File "/usr/local/lib/python2.7/dist-packages/Twisted-13.0.0-py2.7-linux-x86_64.egg/twisted/internet/defer.py", line 1070, in _inlineCallbacks 2013-07-15 01:23:24.095081 > result = g.send(result) 2013-07-15 01:23:24.095109 > File "/home/pioruns/p2pool/p2pool/web.py", line 186, in render_GET 2013-07-15 01:23:24.095137 > res = yield self.func(*self.args) 2013-07-15 01:23:24.095165 > File "/home/pioruns/p2pool/p2pool/web.py", line 446, in <lambda> 2013-07-15 01:23:24.095195 > new_root.putChild('graph_data', WebInterface(lambda source, view: hd.datastreams[source].dataviews[view].get_data(time.time()))) 2013-07-15 01:23:24.095225 > exceptions.KeyError: 'last_' 2013-07-15 01:23:35.771283 P2Pool: 17343 shares in chain (17347 verified/17347 total) Peers: 7 (1 incoming) 2013-07-15 01:23:35.771436 Local: 0H/s in last 10.0 minutes Local dead on arrival: ??? Expected time to share: ??? 2013-07-15 01:23:35.771502 Shares: 0 (0 orphan, 0 dead) Stale rate: ??? Efficiency: ??? Current payout: 0.0000 BTC 2013-07-15 01:23:35.771572 Pool: 1280GH/s Stale rate: 15.5% Expected time to block: 1.0 days 2013-07-15 01:28:24.560067 > Traceback (most recent call last): 2013-07-15 01:28:24.560102 > File "/home/pioruns/p2pool/p2pool/util/deferred_resource.py", line 24, in render 2013-07-15 01:28:24.560137 > defer.maybeDeferred(resource.Resource.render, self, request).addCallbacks(finish, finish_error) 2013-07-15 01:28:24.560177 > File "/usr/local/lib/python2.7/dist-packages/Twisted-13.0.0-py2.7-linux-x86_64.egg/twisted/internet/defer.py", line 137, in maybeDeferred 2013-07-15 01:28:24.560214 > result = f(*args, **kw) 2013-07-15 01:28:24.560248 > File "/usr/local/lib/python2.7/dist-packages/Twisted-13.0.0-py2.7-linux-x86_64.egg/twisted/web/resource.py", line 250, in render 2013-07-15 01:28:24.560288 > return m(request) 2013-07-15 01:28:24.560320 > File "/usr/local/lib/python2.7/dist-packages/Twisted-13.0.0-py2.7-linux-x86_64.egg/twisted/internet/defer.py", line 1213, in unwindGenerator 2013-07-15 01:28:24.560355 > return _inlineCallbacks(None, gen, Deferred()) 2013-07-15 01:28:24.560385 > --- <exception caught here> --- 2013-07-15 01:28:24.560416 > File "/usr/local/lib/python2.7/dist-packages/Twisted-13.0.0-py2.7-linux-x86_64.egg/twisted/internet/defer.py", line 1070, in _inlineCallbacks 2013-07-15 01:28:24.560449 > result = g.send(result) 2013-07-15 01:28:24.560479 > File "/home/pioruns/p2pool/p2pool/web.py", line 186, in render_GET 2013-07-15 01:28:24.560510 > res = yield self.func(*self.args) 2013-07-15 01:28:24.560543 > File "/home/pioruns/p2pool/p2pool/web.py", line 446, in <lambda> 2013-07-15 01:28:24.560576 > new_root.putChild('graph_data', WebInterface(lambda source, view: hd.datastreams[source].dataviews[view].get_data(time.time()))) 2013-07-15 01:28:24.560622 > exceptions.KeyError: 'last_'
|
|
|
|
daemondazz
|
|
July 15, 2013, 01:02:11 AM |
|
Did we just fork? My "Expected time to share" just tripled. I'm also not seeing the "Switchover imminent" messages anymore.
I hope so, my expected time to share went from about 35 minutes to 3 hours.
|
Computers, Amateur Radio, Electronics, Aviation - 1dazzrAbMqNu6cUwh2dtYckNygG7jKs8S
|
|
|
wtogami
|
|
July 15, 2013, 01:16:10 AM |
|
forrestv said 13.2 is coming soon which will be necessary for Avalon mining now that p2pool BTC is past the fork. Keep an eye on #p2pool for news.
|
If you appreciate my work please consider making a small donation. BTC: 1LkYiL3RaouKXTUhGcE84XLece31JjnLc3 LTC: LYtrtYZsVSn5ymhPepcJMo4HnBeeXXVKW9 GPG: AEC1884398647C47413C1C3FB1179EB7347DC10D
|
|
|
Krellan
Member
Offline
Activity: 106
Merit: 10
|
|
July 15, 2013, 07:51:34 AM |
|
As others have already pointed out, I went back through my scrollback and saw when the fork happened. It was at about 15:33 (in my US/Pacific timezone, so that's 22:33 UTC) on 14 July. Nice!
I also noticed a disruption in network traffic. My node lost 3 connections, and then they were almost immediately replaced by new connections elsewhere. I am guessing this is P2Pool rejecting the obsolete nodes (below the fork's version cutoff) and kicking them out of the pool?
To see something interesting, look at your P2Pool graphs (on your localhost).
* In the "Desired version" graph, the little amount of red at the bottom has faded away, it's all blue now. I'm guessing red was obsolete nodes (lower version)?
* In the "Pool rate" graph, there are less DOA/Orphan shares now, which is a good thing. The pool is more green. Still not perfect, but a big improvement.
* In the "Traffic rate" graph, there's a huge change. There was a sudden spike near when the changeover happened, but that was a one-time thing. Network traffic has nicely gone down a large amount. It's about 1/3 what it was before, to reflect the new, slower, pace of share generation/synchronization.
Interestingly, the expected time for my node to find a single share, is now longer than the expected time for P2Pool to find a Bitcoin block! Previously, it was the other way around. Guess that means that my node will fall out of blocks entirely (0 shares/block) but that's the price to be paid for finding blocks more often, so in the long term it should even out.
I'm glad the changeover went smoothly! If it were me, I would have been really nervous when it happened, crossing my fingers, especially since such a dramatic change to a distributed network is a tough thing to fully test in advance...!
Josh
|
1JUZr4TZ5zuB4WdEv4mrhZMaM7yttpJvLG
|
|
|
rav3n_pl
Legendary
Offline
Activity: 1361
Merit: 1003
Don`t panic! Organize!
|
|
July 15, 2013, 09:46:52 AM |
|
Share difficulty 9120 !!! I hope it will get lower in next 48hrs as palnned. 9k is "bit" insane.
|
|
|
|
elebit
|
|
July 15, 2013, 12:24:28 PM |
|
Interestingly, the expected time for my node to find a single share, is now longer than the expected time for P2Pool to find a Bitcoin block! Previously, it was the other way around. Guess that means that my node will fall out of blocks entirely (0 shares/block) but that's the price to be paid for finding blocks more often, so in the long term it should even out.
How does that work? If your node doesn't report any shares during a block, how does the other p2pool nodes know that you're mining? Will it really even out?
|
|
|
|
maqifrnswa
|
|
July 15, 2013, 12:59:09 PM |
|
BFL jallepeno, flashed with a custom version 1.2.5 firmware. Used to have ~85% efficiency and 20% DOA. Now down to 6.5% DOA and~96.5% (63-111%) efficiency). 2013-07-15 03:52:31.495832 Local: 7135MH/s in last 10.0 minutes Local dead on arrival: ~6.5% (4-9%) Expected time to share: 1.2 hours 2013-07-15 03:52:31.496095 Shares: 12 (1 orphan, 1 dead) Stale rate: ~16.7% (4-45%) Efficiency: ~96.5% (63-111%) Current payout: 0.1248 BTC 2013-07-15 03:52:31.496307 Pool: 1418GH/s Stale rate: 13.7% Expected time to block: 22.0 hours Interestingly, the expected time for my node to find a single share, is now longer than the expected time for P2Pool to find a Bitcoin block! Previously, it was the other way around. Guess that means that my node will fall out of blocks entirely (0 shares/block) but that's the price to be paid for finding blocks more often, so in the long term it should even out.
How does that work? If your node doesn't report any shares during a block, how does the other p2pool nodes know that you're mining? Will it really even out? How it works: you will only get credit in the blocks that you get shares in. If your node doesn't report any shares during a block, you won't get credit and other nodes won't know your are mining. Yes it will even out. It will even out because when you do get a block, you will get exactly the compensation for the blocks you missed. Example (made up numbers for demonstration) before you would get .1 BTC per share, and find a share every 12 hours. now you will get .3 BTC per share, and find a share every 36 hours. BTC/hour is the same in both cases.
|
|
|
|
elebit
|
|
July 15, 2013, 02:01:38 PM |
|
Yes it will even out. It will even out because when you do get a block, you will get exactly the compensation for the blocks you missed.
Ah, of course. If the shares are three times as hard to find, they will also be worth three times as much. P2Pool doesn't need to keep track of individual miners contributions at all. Thanks.
|
|
|
|
gyverlb
|
|
July 15, 2013, 03:06:36 PM Last edit: July 15, 2013, 06:46:25 PM by gyverlb |
|
Nice side-effect of hard-forking the P2Pool chain with a larger share interval: I noticed that the amount of network traffic as been significantly reduced at the time of the fork, more specifically the p2p-in amount (the p2p-out seems to be stable for me).
Note that may be relative to my observations: I use 8 incoming and 4 outgoing connections, my bitcoind configuration includes more transactions than average (aggressive settings as recommended in the guide in my signature) which may explain why I have a higher and more constant p2p-out across the fork (my node needs to forward these transactions to neighbors).
My efficiency as been reduced (edit: seems ~104% instead of the previous ~108% average) but this was the expected outcome of the fork (everybody should converge near 100% efficiency).
|
|
|
|
|