forrestv
|
|
July 27, 2011, 06:42:11 AM |
|
New release! 1b128ebImportant changes: - Status display greatly improved
- Workarounds that get all miners tested at least mostly working - see first post - cgminer is the only known stock miner that is now completely compatible
Windows py2exe binary on the first post has been updated.
|
1J1zegkNSbwX4smvTdoHSanUfwvXFeuV23
|
|
|
Operations
Newbie
Offline
Activity: 22
Merit: 0
|
|
July 27, 2011, 04:16:42 PM |
|
If I'm using cgminer (version 1.5.1) then i see a lot of:
... [2011-07-27 18:13:25] LONGPOLL detected new block on network, waiting on fresh work [2011-07-27 18:13:25] New block detected on network before longpoll, waiting on fresh work [2011-07-27 18:13:38] LONGPOLL detected new block on network, waiting on fresh work [2011-07-27 18:13:38] LONGPOLL detected new block on network, waiting on fresh work [2011-07-27 18:13:38] New block detected on network before longpoll, waiting on fresh work [2011-07-27 18:13:41] LONGPOLL detected new block on network, waiting on fresh work [2011-07-27 18:13:41] LONGPOLL detected new block on network, waiting on fresh work [2011-07-27 18:13:41] New block detected on network before longpoll, waiting on fresh work [2011-07-27 18:13:47] LONGPOLL detected new block on network, waiting on fresh work [2011-07-27 18:13:47] LONGPOLL detected new block on network, waiting on fresh work [2011-07-27 18:13:47] New block detected on network before longpoll, waiting on fresh work [2011-07-27 18:14:05] LONGPOLL detected new block on network, waiting on fresh work [2011-07-27 18:14:05] LONGPOLL detected new block on network, waiting on fresh work [2011-07-27 18:14:05] LONGPOLL detected new block on network, waiting on fresh work [2011-07-27 18:14:20] LONGPOLL detected new block on network, waiting on fresh work [2011-07-27 18:14:20] LONGPOLL detected new block on network, waiting on fresh work [2011-07-27 18:14:20] New block detected on network before longpoll, waiting on fresh work [2011-07-27 18:14:22] LONGPOLL received after new block already detected [2011-07-27 18:14:22] New block detected on network before longpoll, waiting on fresh work [2011-07-27 18:14:22] LONGPOLL received after new block already detected [2011-07-27 18:14:22] New block detected on network before longpoll, waiting on fresh work [2011-07-27 18:14:22] New block detected on network before longpoll, waiting on fresh work [2011-07-27 18:14:49] LONGPOLL detected new block on network, waiting on fresh work [2011-07-27 18:14:49] LONGPOLL detected new block on network, waiting on fresh work [2011-07-27 18:14:49] New block detected on network before longpoll, waiting on fresh work [2011-07-27 18:14:53] LONGPOLL detected new block on network, waiting on fresh work [2011-07-27 18:14:53] LONGPOLL detected new block on network, waiting on fresh work [2011-07-27 18:14:53] New block detected on network before longpoll, waiting on fresh work [2011-07-27 18:14:58] Accepted 3d22e40b GPU 0 thread 0 [2011-07-27 18:14:58] LONGPOLL detected new block on network, waiting on fresh work [2011-07-27 18:14:58] LONGPOLL detected new block on network, waiting on fresh work [2011-07-27 18:14:58] New block detected on network before longpoll, waiting on fresh work [2011-07-27 18:15:34] Accepted 1f24ab65 GPU 0 thread 0 [2011-07-27 18:15:34] LONGPOLL detected new block on network, waiting on fresh work [2011-07-27 18:15:34] LONGPOLL detected new block on network, waiting on fresh work [2011-07-27 18:15:34] New block detected on network before longpoll, waiting on fresh work [2011-07-27 18:15:46] LONGPOLL detected new block on network, waiting on fresh work [2011-07-27 18:15:46] LONGPOLL detected new block on network, waiting on fresh work [2011-07-27 18:15:46] New block detected on network before longpoll, waiting on fresh work ...
|
|
|
|
hawks5999
|
|
July 27, 2011, 09:25:46 PM |
|
hmm... that looks like deepbit's solving speed lately...
|
■ ▄▄▄ ■ ███ ■ ■ ■ LEDGER WALLET ████ ■■■ ORDER NOW! ■■■ LEDGER WALLET Smartcard security for your BTCitcoins ■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■ Decentralized. Open. Secure.
|
|
|
forrestv
|
|
July 28, 2011, 01:51:34 AM Last edit: July 28, 2011, 04:39:16 AM by forrestv |
|
If I'm using cgminer (version 1.5.1) then i see a lot of:
... [2011-07-27 18:13:25] LONGPOLL detected new block on network, waiting on fresh work [2011-07-27 18:13:25] New block detected on network before longpoll, waiting on fresh work [2011-07-27 18:13:38] LONGPOLL detected new block on network, waiting on fresh work [2011-07-27 18:13:38] LONGPOLL detected new block on network, waiting on fresh work ...
That's completely normal. P2Pool blocks happen at a rate of one every five seconds on average, and that work is being pushed to the miners.
|
1J1zegkNSbwX4smvTdoHSanUfwvXFeuV23
|
|
|
forrestv
|
|
July 28, 2011, 05:20:34 AM Last edit: July 28, 2011, 05:30:52 AM by forrestv |
|
New release! a07e25c Changes: - Memory reduction - p2pool now takes 40% less memory!
- p2pool now adjusts to the specific miner daemon using its User-Agent header - less stales
- Share downloading is smarter - faster, more robust sharechain downloads
- p2pool doesn't distribute work until the sharechain is downloaded - elimination of those confusing stales you get when p2pool is starting
- Some minor interface changes: exception reporting, share notification lines
|
1J1zegkNSbwX4smvTdoHSanUfwvXFeuV23
|
|
|
burp
Member
Offline
Activity: 98
Merit: 10
|
|
July 28, 2011, 07:07:28 PM Last edit: July 28, 2011, 07:21:16 PM by burp |
|
Throwing away current work every 5 seconds doesn't seem very efficient to me. What about increasing the block rate? By using p2pool I'm basically wasting more than 30% of my hashing power. ( Reject ratio: 28.7 )
|
|
|
|
forrestv
|
|
July 28, 2011, 07:50:19 PM |
|
Throwing away current work every 5 seconds doesn't seem very efficient to me. What about increasing the block rate? By using p2pool I'm basically wasting more than 30% of my hashing power. ( Reject ratio: 28.7 )
What miner and p2pool version are you using? Did you look at the updated information about miners on the first post? By using that I've consistently been able to get <10% stales with all the different miners. I'm currently working on improving p2pool and the patches to the miners to decrease the reject ratio ... should have some new results in about an hour to further reduce it.
|
1J1zegkNSbwX4smvTdoHSanUfwvXFeuV23
|
|
|
burp
Member
Offline
Activity: 98
Merit: 10
|
|
July 28, 2011, 08:18:16 PM |
|
Throwing away current work every 5 seconds doesn't seem very efficient to me. What about increasing the block rate? By using p2pool I'm basically wasting more than 30% of my hashing power. ( Reject ratio: 28.7 )
What miner and p2pool version are you using? Did you look at the updated information about miners on the first post? By using that I've consistently been able to get <10% stales with all the different miners. I'm currently working on improving p2pool and the patches to the miners to decrease the reject ratio ... should have some new results in about an hour to further reduce it. Latest cgminer and p2pool. It's not about the stale number that p2pool displays, that is ok. But because of the frequent new blocks much work is wasted and the rejection percentage of cgminer is about ~30%. EDIT: OK, for everyone else that might think like me. Forrestv just made something clear to me in IRC: Work is not really "wasted", because these mini blocks serve as a method for calculating the payout. And submitted results that qualify as a real block solution give still payout to everyone using p2pool even if it's stale.
|
|
|
|
gigica viteazu`
Sr. Member
Offline
Activity: 458
Merit: 250
beast at work
|
|
July 28, 2011, 10:55:44 PM |
|
this is great, i intend to switch my 2.5Gmh/s to p2pool soon
|
|
|
|
forrestv
|
|
July 29, 2011, 09:02:20 AM Last edit: July 29, 2011, 09:24:24 AM by forrestv |
|
New important release! - please upgrade! 9037c07 - New best-share selection strategy - will reduce stales, but everyone needs to upgrade!
- Worker interface improvements that should also reduce stales (including added information about several additional miner daemons)
- Miscellaneous interface improvements and code cleanups
Please upgrade to keep the p2pool network healthy! The Windows EXE on the first post has been updated. EDIT: I'm getting ~5% stales on the miner using poclbm with the patch on the first post: ./poclbm.py http://9dfa:ada@127.0.0.1:9332 --verbose -d1 -f 100 -w 128 -v ... 127.0.0.1:9332 29/07/2011 05:23:49, [395.838 MH/s (~319 MH/s)] [Rej: 5/134 (3.73%)]
|
1J1zegkNSbwX4smvTdoHSanUfwvXFeuV23
|
|
|
gigica viteazu`
Sr. Member
Offline
Activity: 458
Merit: 250
beast at work
|
|
July 29, 2011, 03:15:16 PM |
|
last update gives me 50 rejects from 60 submited shares using cgminer
|
|
|
|
forrestv
|
|
July 29, 2011, 04:08:53 PM Last edit: July 29, 2011, 05:29:40 PM by forrestv |
|
last update gives me 50 rejects from 60 submited shares using cgminer
Hm ... there might have been a regression, though I'm testing cgminer right now, and while it does worse than poclbm (~15% stales), it's nowhere near what you report. Are you talking about the stales that cgminer tells you or the stales that p2pool reports? Can you paste a few lines from both cgminer and p2pool? And try running p2pool with '--debug' for a while and then upload the 'debug.log' file somewhere? Thanks, sorry! EDIT: Are you using multiple pools? burp_ reports that that can cause problems with cgminer and long polling. Also, cgminer doesn't check shares against the actual target, it just submits all difficulty-1 shares, so getting up to half rejected on the miner and lots of 'Invalid share' messages in p2pool is normal for it. You're not losing any work. Want to get on IRC? #p2pool on freenode if you're interested ...
|
1J1zegkNSbwX4smvTdoHSanUfwvXFeuV23
|
|
|
|
forrestv
|
|
August 03, 2011, 07:55:20 PM Last edit: August 09, 2011, 06:58:59 PM by forrestv |
|
New release! fbedaf9 Major changes: - Miners can connect with a Bitcoin address as the username to direct payouts to that address - set up a public node and invite people to mine on it!
- Drawing of share chain - use option --charts and go to http://127.0.0.1:9332/chain_img
- UPnP support - automatic port forwarding to help the P2P network
- IP transactions work
- Peer count displayed on status line
- Forward compatibility for merged mining
- Two new bootstrap nodes
- Better version detection
- Reduced CPU usage
Binaries are on the first post. EDIT: If you have multiple mining clients make sure they have unique usernames. p2pool internally tracks the state of miners by their usernames, and you will get a lot more stales if they are confused.
|
1J1zegkNSbwX4smvTdoHSanUfwvXFeuV23
|
|
|
LightRider
Legendary
Offline
Activity: 1500
Merit: 1022
I advocate the Zeitgeist Movement & Venus Project.
|
|
August 13, 2011, 05:42:25 AM |
|
This is a great idea and I hope it catches on. I think a p2p strategy in all aspects of BTC is a good one. Well done!
|
|
|
|
twmz
|
|
August 13, 2011, 04:43:36 PM |
|
EDIT: If you have multiple mining clients make sure they have unique usernames. p2pool internally tracks the state of miners by their usernames, and you will get a lot more stales if they are confused.
I assume you're accounting for the fact that some miners (cgminer, diablominer) use a single miner instance with many threads (2 per GPU, usually) that all use the same credentials. This is equivalent to multiple miners all sharing the same usernames. I don't think it is reasonable to forbid this behavior (or punish it with high stale rates).
|
Was I helpful? 1 TwmzX1wBxNF2qtAJRhdKmi2WyLZ5VHRs WoT, GPGBitrated user: ewal.
|
|
|
forrestv
|
|
August 16, 2011, 04:39:33 AM Last edit: August 16, 2011, 04:55:37 AM by forrestv |
|
New version! fbedaf9 Windows binary: http://u.forre.st/u/weclcaad/p2pool_win32_b324a68.zipSee first post and the wiki for instructions. Major changes: - Namecoin and Ixcoin support! Use --net=namecoin or --net=ixcoin
- Dropping of old shares - p2pool's memory usage no longer grows slowly over time
- Caching of shares and block headers on disk - after starting p2pool, it's ready to mine in less than a minute
- Display of median stale rate for users and individual efficiency - no more worrying about stales
- Improved communication with miners - less stales
- Removed resource leaks and huge bandwidth usage under some configurations due to UPnP
- Work isn't given to miners if bitcoind dies
- Miscellaneous memory and speed improvements
- Reopens debug.log on SIGUSR1 for log rotation
Join the #p2pool channel on Freenode for discussion!
|
1J1zegkNSbwX4smvTdoHSanUfwvXFeuV23
|
|
|
rdponticelli
Sr. Member
Offline
Activity: 325
Merit: 250
Our highest capital is the Confidence we build.
|
|
August 17, 2011, 05:06:18 PM |
|
Hi. I'm trying p2pool and I have some doubts. Last night I left it working on a server, with a couple of client miners, and this morning I found it was frozen. It seems that it got frozen after 12 hours of being running, or something like that...
Somebody else has experienced this kind of problem?
There was no logs useful for tracing the problem. It was just hanged somewhere on the normal loop, and I have had to SIGKILL the process and launch it again.
Another doubt is: what happens with all of yesterday's work? It's remembered by the network and will be payed if a block is found, or it's wasted?
And last. When the logs says: "Payout if block: x BTC"
That amount is what will be payed if my node finds the block or it's the payment without counting the subsidy?
Thank you.
|
|
|
|
forrestv
|
|
August 17, 2011, 06:48:40 PM |
|
Hi. I'm trying p2pool and I have some doubts. Last night I left it working on a server, with a couple of client miners, and this morning I found it was frozen. It seems that it got frozen after 12 hours of being running, or something like that...
Somebody else has experienced this kind of problem?
There was no logs useful for tracing the problem. It was just hanged somewhere on the normal loop, and I have had to SIGKILL the process and launch it again.
I'm guessing you're on Windows? I haven't been able to reproduce this problem. However, if you run p2pool with --debug, it will produce a lot more messages and log them all to debug.log, which might be useful. Another doubt is: what happens with all of yesterday's work? It's remembered by the network and will be payed if a block is found, or it's wasted?
It's forgotten. p2pool pays the last N shares (PPLNS payout method, used by several other pools too), which is provably fair and invulnerable to pool hopping. It does seem kind of unfair now, but once p2pool grows to get one block per day, all work will get a payout. And last. When the logs says: "Payout if block: x BTC"
That amount is what will be payed if my node finds the block or it's the payment without counting the subsidy?
That exact amount would be paid to you if the pool found a block at this moment.
|
1J1zegkNSbwX4smvTdoHSanUfwvXFeuV23
|
|
|
rdponticelli
Sr. Member
Offline
Activity: 325
Merit: 250
Our highest capital is the Confidence we build.
|
|
August 17, 2011, 07:08:37 PM |
|
Hi. I'm trying p2pool and I have some doubts. Last night I left it working on a server, with a couple of client miners, and this morning I found it was frozen. It seems that it got frozen after 12 hours of being running, or something like that...
Somebody else has experienced this kind of problem?
There was no logs useful for tracing the problem. It was just hanged somewhere on the normal loop, and I have had to SIGKILL the process and launch it again.
I'm guessing you're on Windows? I haven't been able to reproduce this problem. However, if you run p2pool with --debug, it will produce a lot more messages and log them all to debug.log, which might be useful. No. It's a Debian server. Anyway, I'll let you know if the problem shows up again. I'm now running the git from yesterday. Another doubt is: what happens with all of yesterday's work? It's remembered by the network and will be payed if a block is found, or it's wasted?
It's forgotten. p2pool pays the last N shares (PPLNS payout method, used by several other pools too), which is provably fair and invulnerable to pool hopping. It does seem kind of unfair now, but once p2pool grows to get one block per day, all work will get a payout. So everytime I stop the pool -let's say to launch the latest git version, or to change the payment address- I lose all work of every worker? I think that this has to be worked out. I understand PPLNS, and let's say that I agree with its fairness. Anyway, downtimes will always happens, and I think that that work shouldn't be wasted. And last. When the logs says: "Payout if block: x BTC"
That amount is what will be payed if my node finds the block or it's the payment without counting the subsidy?
That exact amount would be paid to you if the pool found a block at this moment. Thank you. Great work.
|
|
|
|
|