* New graph implementation (works on Windows!) with per-miner graphs. Go to http://127.0.0.1:9332/static once installed to view.
Would it be possible to code in where miners can define a password for their graphs? 
Topic: [1500 TH] p2pool: Decentralized, DoS-resistant, Hop-Proof pool - page 739. (Read 2591916 times)
March 21, 2012, 09:04:00 PM
March 21, 2012, 07:28:42 PM
It's also the first release posted here that includes the new graphing implementation, which works on Windows.
Changes:
* New graph implementation (works on Windows!) with per-miner graphs. Go to http://127.0.0.1:9332/static once installed to view.
Changes:
* New graph implementation (works on Windows!) with per-miner graphs. Go to http://127.0.0.1:9332/static once installed to view.
Yay!
March 21, 2012, 07:26:44 PM
P2Pool release 0.10.3 signed tag: 0.10.3 UPGRADE REQUIRED before April 1st (BIP 16 date), March 27th for Litecoin
Windows binary: http://u.forre.st/u/jtjrvlxm/p2pool_win32_0.10.3.zip
Tarball: https://github.com/forrestv/p2pool/tarball/0.10.3
Zipball: https://github.com/forrestv/p2pool/zipball/0.10.3
This release purposely breaks compatibility in order to manage the changes BIP16 will bring, but also includes some other useful protocol changes. It's also the first release posted here that includes the new graphing implementation, which works on Windows (screenshot: http://u.forre.st/u/iastaoit/some-graphs.png).
Changes:
* Require users to be running a BIP16-compatible bitcoind (0.6.0rc4 or higher, or luke-jr's 0.5.4 backport). 0.6.0.rc4 is available at http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.6.0/test/ 0.5.4rc1 at https://bitcointalksearch.org/topic/please-help-test-bitcoin-054rc1-and-045rc1-72069
* New graph implementation (works on Windows!) with per-miner graphs. Go to http://127.0.0.1:9332/static/graphs.html once installed to view.
* The "script" bad output script bug will be fixed on the changeover on April 1st.
* Shares include a "version vote" that lets clients display a warning when an upgrade will soon be required.
* Shares contain the hash of their 100th parent share which could let a challenge/response protocol be implemented to verify that nodes are friendly and not just spamming you with shares.
* Shares contain a merkle branch so P2Pool's unique merged mining method could be used by other chains without any additional overhead on the Bitcoin blockchain.
Windows binary: http://u.forre.st/u/jtjrvlxm/p2pool_win32_0.10.3.zip
Tarball: https://github.com/forrestv/p2pool/tarball/0.10.3
Zipball: https://github.com/forrestv/p2pool/zipball/0.10.3
This release purposely breaks compatibility in order to manage the changes BIP16 will bring, but also includes some other useful protocol changes. It's also the first release posted here that includes the new graphing implementation, which works on Windows (screenshot: http://u.forre.st/u/iastaoit/some-graphs.png).
Changes:
* Require users to be running a BIP16-compatible bitcoind (0.6.0rc4 or higher, or luke-jr's 0.5.4 backport). 0.6.0.rc4 is available at http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.6.0/test/ 0.5.4rc1 at https://bitcointalksearch.org/topic/please-help-test-bitcoin-054rc1-and-045rc1-72069
* New graph implementation (works on Windows!) with per-miner graphs. Go to http://127.0.0.1:9332/static/graphs.html once installed to view.
* The "script" bad output script bug will be fixed on the changeover on April 1st.
* Shares include a "version vote" that lets clients display a warning when an upgrade will soon be required.
* Shares contain the hash of their 100th parent share which could let a challenge/response protocol be implemented to verify that nodes are friendly and not just spamming you with shares.
* Shares contain a merkle branch so P2Pool's unique merged mining method could be used by other chains without any additional overhead on the Bitcoin blockchain.
March 21, 2012, 07:14:57 PM
Hi everyone, I've been playing around with bitcoind/p2pool on my Fedora 16 box, and I decided to write an init script to manage starting and stopping things between updates. I think I might be one of the odd ones who's not using a Debian system, so I figured I'd add to your options 
. Feel free to take a look and copy/modify as you see fit. http://pastebin.com/qCDQerWP
. Feel free to take a look and copy/modify as you see fit. http://pastebin.com/qCDQerWP 
March 21, 2012, 06:06:58 PM
Yes, but you've been running for awhile. When you ran your p2pool node for the very first time how long did it take?
I'm pretty sure I had 10 in under a minute when I first setup, too. My backup node is much newer and it got connections just as fast as the server that has been up since January.I have a public IP, so theres no UPNP on my primary. I thought that might make a difference at first, but my secondary node has the port firewalled and no UPNP either. It should have a harder time getting connections, but it still gets them just as fast.
Maybe try adding " -n p2pool.stitthappens.com:8335" to your command? That should get you connected to me at the very least. Theres a list of public nodes on http://nodes.p2pmine.com/, but that lists the worker port instead of the p2p port.
March 21, 2012, 05:59:43 PM
Yes, but you've been running for awhile. When you ran your p2pool node for the very first time how long did it take?
March 21, 2012, 05:58:00 PM
Your node has to be running for a while without the IP changing. It took me 12 hours (over night) before I saw my first connection. It was a few weeks later when I saw higher numbers.
I see my first few connections pretty much instantly. And I get to 10 really fast. I just restarted my miner to update and am back at 13 peers in under a minute. March 21, 2012, 05:23:00 PM
Your node has to be running for a while without the IP changing. It took me 12 hours (over night) before I saw my first connection. It was a few weeks later when I saw higher numbers.
March 21, 2012, 03:15:18 PM
It will take a while. P2Pool nodes prefer to connect to nodes that have been up for a long time, so if your node is just recently added to the network, you won't get chosen very often.
Makes sense!
The IP will auto-reconnect every 24h, will that make that node "unreliable"? Or does it just have to run a long time without restart/reboot to be "reliable"? I.E. does every installation have an ID or something? Or does it change with running instance, or with IP?
Hmm, I guess only forrestv can answer this?
Ente
March 21, 2012, 03:11:41 PM
hmm, okay then..
I just rechecked, and could telnet into 9333 from outside. P2pool saw that connection (and timed out), so I just have to wait for connections to come in (still 10+0, after one hour)
Thanks for the info!
Ente
I just rechecked, and could telnet into 9333 from outside. P2pool saw that connection (and timed out), so I just have to wait for connections to come in (still 10+0, after one hour)
Thanks for the info!
Ente
It will take a while. P2Pool nodes prefer to connect to nodes that have been up for a long time, so if your node is just recently added to the network, you won't get chosen very often.
March 21, 2012, 02:50:14 PM
hmm, okay then..
I just rechecked, and could telnet into 9333 from outside. P2pool saw that connection (and timed out), so I just have to wait for connections to come in (still 10+0, after one hour)
Thanks for the info!
Ente
I just rechecked, and could telnet into 9333 from outside. P2pool saw that connection (and timed out), so I just have to wait for connections to come in (still 10+0, after one hour)
Thanks for the info!
Ente
March 21, 2012, 02:19:55 PM
Nope, nothing else you need to do.
I've done the same, forwarded port and waited. I've seen 30+ connections - 10 out and 20+ incoming to my node.
I've done the same, forwarded port and waited. I've seen 30+ connections - 10 out and 20+ incoming to my node.
March 21, 2012, 02:16:32 PM
The 10 is only on outbound connections. If you portforward you can have more than 10. 10 outbound + unlimited inbound.
Ah, nice!
I have tcp 9333 forwarded, closed p2pool and restarted. Anything else I forgot? I am still at 10+0..
Is (only) 9333 right?
I dont need to announce this or anything, do I?
Or is it just normal that it takes that long for nodes to connect?
Ente
March 21, 2012, 02:05:13 PM
Depends on how many? Some % of orphans is simply unavoidable but if your avg is similar to the network avg then your compensation is the same (i.e. you having 0% orphans and network having 0% orphans pays the same as you have 8% orphans and the network having 8% orphans).
If it is significantly more than the average then more connections may help. The 10 is only on outbound connections. If you portforward you can have more than 10. 10 outbound + unlimited inbound.
If it is significantly more than the average then more connections may help. The 10 is only on outbound connections. If you portforward you can have more than 10. 10 outbound + unlimited inbound.
March 21, 2012, 02:02:46 PM
I have more orphans than I like..
Orphans point to bad connection? I forwarded port 9333, but I still only have 10 peers, 0 incoming..
Other hints? Can I change the '10' limit?
The internet connection isnt that fast, I fear..
Ente
Orphans point to bad connection? I forwarded port 9333, but I still only have 10 peers, 0 incoming..
Other hints? Can I change the '10' limit?
The internet connection isnt that fast, I fear..
Ente
March 21, 2012, 11:26:06 AM
P2pool keeps growing. This is a new record I think:
Code:
2012-03-21 17:27:27.558000 Pool: 369GH/s Stale rate: 8.3% Expected time to block: 4.8 hours
2012-03-21 17:27:29.960000 New work for worker! Difficulty: 0.999985 Share difficulty: 900.936232 Total block value: 50.016434 BTC including 27 transactions
Oh, by the way, bitcoin-qt 0.6 rc4 doesn't crash under Windows. Hooray. 2012-03-21 17:27:29.960000 New work for worker! Difficulty: 0.999985 Share difficulty: 900.936232 Total block value: 50.016434 BTC including 27 transactions
March 21, 2012, 10:55:54 AM
I showed no -10 MH/s per card on a farm of 24 5970s. You sure you weren't just seeing variance. Still even if it is -10 MH/s if it saves you 20 watts you likely come out ahead. Using affinity still keep a core burning away at max clock rate and current.
You are aware the DRIVER is what affects the cpu bug. The SDK is what affects OpenCL performance. You can use any driver (including one with no CPU bug) with any SDK runtime (including the one you believe is +10MH/s better).
You are aware the DRIVER is what affects the cpu bug. The SDK is what affects OpenCL performance. You can use any driver (including one with no CPU bug) with any SDK runtime (including the one you believe is +10MH/s better).
I am fully aware that the DRIVER is what affects the CPU bug. I am also fully aware, that every combination of AMD-APP Runtime 2.5 variation I tried with newer drivers that fix the CPU bug, resulted in 10 Mh/s less per card on the three rigs I tried them on. This may not be the case on other OS's and card combinations.
I tested it on Windows 7 X64 with 6970's and 5870's (cgminer 2.3.1-2 and deleting .bin files every time a change was made [20 minute run time]).
Were you on 2.5.732.1 before you got rid of the CPU bug? If not you may not have noticed any drop in Mh/s.
March 21, 2012, 10:16:01 AM
Does anyone know if there are plans for a p2pool WITHOUT bip16 support come april 1st? Would p2pool be robust enough to work in a mixed client scenario?
It seems to me like there could be quite a few miners who like the idea and lower variance of p2pool but would also like some say in which changes get accepted into the bitcoin protocol.
The support is based on the client that each p2pool user is running, and whoever solves the block is the one that gets the "vote" That being said however, voting is pretty much over and P2SH is going ahead anyway, so if you don't support it you risk your blocks becoming orphan, and you not getting any payout at all. That would include all p2pool miners' payouts from a non supported bitcoind, since it is split. It seems to me like there could be quite a few miners who like the idea and lower variance of p2pool but would also like some say in which changes get accepted into the bitcoin protocol.
March 21, 2012, 09:55:14 AM
Also, the RRD graphs are deprecated. The new JavaScript-based ones have a lot more potential and flexibility. They don't have support for measuring individual miners yet, but that will come soon.
That's great news, thank you!
Ente
March 21, 2012, 09:34:02 AM
p2pool shows a global hashrate stat shown at "/rate" or on the p2pool command line. Anyone know over what time period that is calculated? Last hour? Last day? Last x shares? I got an idea for a promo / contest involving p2pool.
720 shares, which should normally be 720*10 seconds = 2 hours. This should be more self-documenting.. maybe return a JSON Object with an "averaging period" attribute.
---
Thanks for the recomendations about handling the donation amount. I will implement the warning-on-p2pool-start idea.
Also, the RRD graphs are deprecated. The new JavaScript-based ones have a lot more potential and flexibility. They don't have support for measuring individual miners yet, but that will come soon.
Does anyone know if there are plans for a p2pool WITHOUT bip16 support come april 1st? Would p2pool be robust enough to work in a mixed client scenario?
It seems to me like there could be quite a few miners who like the idea and lower variance of p2pool but would also like some say in which changes get accepted into the bitcoin protocol.
BIP16 is already final. It has >50% of he Bitcoin network's hash rate behind it. Any attempt at opposing it can only invalidate your own work. Note that during the last few months, P2Pool has passed through your bitcoind's "coinbaseflags" into mined blocks, which let you vote during the period where it mattered. It seems to me like there could be quite a few miners who like the idea and lower variance of p2pool but would also like some say in which changes get accepted into the bitcoin protocol.
Jump to: