There is still a memory leak. P2pool consuming 2.4 GB memory (RES) after running for 7 days.
Are you using most recent version 9.4-13-g5703b70?
Topic: [1500 TH] p2pool: Decentralized, DoS-resistant, Hop-Proof pool - page 607. (Read 2591920 times)
December 13, 2012, 09:11:35 AM
Are you using most recent version 9.4-13-g5703b70?
December 13, 2012, 09:00:24 AM
There is still a memory leak. P2pool consuming 2.4 GB memory (RES) after running for 7 days.
December 13, 2012, 06:13:08 AM
I've come to the conclusion that latency plays a huge factor in stale rate. I think bitcoind was hogging my bandwidth, I turned off port forwarding for it, stopped using -n to connect to multiple p2pool pools, and turned off port forwarding to my backup p2pool.
After 10h 8m 45s, I have 49 shares, 2 orphaned, or 4.08% stale. Been ages since I've been that low.
M
After 10h 8m 45s, I have 49 shares, 2 orphaned, or 4.08% stale. Been ages since I've been that low.
M
December 12, 2012, 03:58:26 PM
I have even better stats. On total 13187222 shares, 36281 stale shares = 0.275%.
Using Ztex's BTCMiner on BitMinter pool.
Unfortunately, my p2pool machine is too weak to get similar results on local p2pool with my FPGAs. Bitcoind latency is ~0.5s.
You can't compare stale rates of bitminter (or any non p2pool) with p2pool. They work differently.Using Ztex's BTCMiner on BitMinter pool.
Unfortunately, my p2pool machine is too weak to get similar results on local p2pool with my FPGAs. Bitcoind latency is ~0.5s.
My stratum miner is only .068% reject, but that number doesn't mean anything compared to p2pool.
December 12, 2012, 09:24:49 AM
I have even better stats. On total 13187222 shares, 36281 stale shares = 0.275%.
Using Ztex's BTCMiner on BitMinter pool.
Unfortunately, my p2pool machine is too weak to get similar results on local p2pool with my FPGAs. Bitcoind latency is ~0.5s.
Using Ztex's BTCMiner on BitMinter pool.
Unfortunately, my p2pool machine is too weak to get similar results on local p2pool with my FPGAs. Bitcoind latency is ~0.5s.
December 12, 2012, 08:09:57 AM
After 1d 15h 5m 39s, I have 211 shares, 22 orphaned, 3 dead - 11.85% stale rate. That's using the linux "do not use for mining" build in a VM, and p2pool v9.4. Decent in my mind, but not as good as it was pre fork.
Between my 3 miners, I have about 112k shares submitted, about 3k rejected, or 2.67% reject rate. That's pretty good for LP imho. Looking forward to stratum coming on.
M
Between my 3 miners, I have about 112k shares submitted, about 3k rejected, or 2.67% reject rate. That's pretty good for LP imho. Looking forward to stratum coming on.
M
That's an excellent long term stale right.. I think mine is closer to 5%.
December 12, 2012, 12:50:08 AM
What happens to the roof of the 400GH / s? It seems to be impossible to overcome when large mining brings lot of computing power other small miners disappear.
December 11, 2012, 09:19:25 PM
After 1d 15h 5m 39s, I have 211 shares, 22 orphaned, 3 dead - 11.85% stale rate. That's using the linux "do not use for mining" build in a VM, and p2pool v9.4. Decent in my mind, but not as good as it was pre fork.
Between my 3 miners, I have about 112k shares submitted, about 3k rejected, or 2.67% reject rate. That's pretty good for LP imho. Looking forward to stratum coming on.
M
Between my 3 miners, I have about 112k shares submitted, about 3k rejected, or 2.67% reject rate. That's pretty good for LP imho. Looking forward to stratum coming on.
M
December 11, 2012, 02:09:19 PM
Where in my linux p2pool directory can I look to find the human-readable version number, e.g., currently, 9.4?
run_p2pool.py --versionCode:
proofer@miner:~/src/p2pool$ run_p2pool.py --version
fatal: Not a git repository (or any parent up to mount parent )
Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).
unknown
proofer@miner:~/src/p2pool$:
The p2pool directory is renamed from the forrestv-p2pool-6880123 directory that was the expansion of the 9.4 linux tarball.fatal: Not a git repository (or any parent up to mount parent )
Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).
unknown
proofer@miner:~/src/p2pool$:
All problems gone forever. December 11, 2012, 11:53:54 AM
Where in my linux p2pool directory can I look to find the human-readable version number, e.g., currently, 9.4?
run_p2pool.py --versionCode:
proofer@miner:~/src/p2pool$ run_p2pool.py --version
fatal: Not a git repository (or any parent up to mount parent )
Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).
unknown
proofer@miner:~/src/p2pool$:
The p2pool directory is renamed from the forrestv-p2pool-6880123 directory that was the expansion of the 9.4 linux tarball. fatal: Not a git repository (or any parent up to mount parent )
Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).
unknown
proofer@miner:~/src/p2pool$:
December 11, 2012, 08:16:15 AM
Quote
when I set maxconnections=10 my p2pool is not started, just stay in
Code:
2012-12-09 21:05:51.285000 p2pool (version 9.4)
2012-12-09 21:05:51.300000
2012-12-09 21:05:51.300000 Testing bitcoind RPC connection to 'http://127.0.0.1:8332/' with username 'zzzzz'...
2012-12-09 21:05:51.378000 ...success!
2012-12-09 21:05:51.394000 Current block hash: 23vdgbfgbfhnfgn563hyjntjntgnbgfn6443h46h3nynn4tbtbrb
2012-12-09 21:05:51.394000 Current block height: 211544
2012-12-09 21:05:51.394000
2012-12-09 21:05:51.394000 Testing bitcoind P2P connection to '127.0.0.1:8333'...
2012-12-09 21:05:51.300000
2012-12-09 21:05:51.300000 Testing bitcoind RPC connection to 'http://127.0.0.1:8332/' with username 'zzzzz'...
2012-12-09 21:05:51.378000 ...success!
2012-12-09 21:05:51.394000 Current block hash: 23vdgbfgbfhnfgn563hyjntjntgnbgfn6443h46h3nynn4tbtbrb
2012-12-09 21:05:51.394000 Current block height: 211544
2012-12-09 21:05:51.394000
2012-12-09 21:05:51.394000 Testing bitcoind P2P connection to '127.0.0.1:8333'...
If it uses up all 10 before p2pool has a chance to connect then this happens. You can either start p2pool quickly after bitcoin or increase it to 20 or something.
December 11, 2012, 07:59:42 AM
Quote
when I set maxconnections=10 my p2pool is not started, just stay in
Code:
2012-12-09 21:05:51.285000 p2pool (version 9.4)
2012-12-09 21:05:51.300000
2012-12-09 21:05:51.300000 Testing bitcoind RPC connection to 'http://127.0.0.1:8332/' with username 'zzzzz'...
2012-12-09 21:05:51.378000 ...success!
2012-12-09 21:05:51.394000 Current block hash: 23vdgbfgbfhnfgn563hyjntjntgnbgfn6443h46h3nynn4tbtbrb
2012-12-09 21:05:51.394000 Current block height: 211544
2012-12-09 21:05:51.394000
2012-12-09 21:05:51.394000 Testing bitcoind P2P connection to '127.0.0.1:8333'...
2012-12-09 21:05:51.300000
2012-12-09 21:05:51.300000 Testing bitcoind RPC connection to 'http://127.0.0.1:8332/' with username 'zzzzz'...
2012-12-09 21:05:51.378000 ...success!
2012-12-09 21:05:51.394000 Current block hash: 23vdgbfgbfhnfgn563hyjntjntgnbgfn6443h46h3nynn4tbtbrb
2012-12-09 21:05:51.394000 Current block height: 211544
2012-12-09 21:05:51.394000
2012-12-09 21:05:51.394000 Testing bitcoind P2P connection to '127.0.0.1:8333'...
If it uses up all 10 before p2pool has a chance to connect then this happens. You can either start p2pool quickly after bitcoin or increase it to 20 or something.
December 10, 2012, 11:18:02 PM
unfortunately p2pool wasted work do not go below 15-20% as was before hardfork
Stale P2Pool shares are not "wasted" - they still can solve blocks and get us all a payout. They're just don't count for P2Pool credit, which affects everyone to some degree, so everything is optimal and fair as long as your efficiency is close to 100%.
Since people will keep talking about this "problem",
how about showing "Local status" on the static page based on efficiency?
Ex. "Good" for >110%, "Normal" for 100~110%, "Below Normal" for 90~100%, "Bad" for <90%.
December 10, 2012, 12:35:00 PM
Quote from: lenny_ link=topic=18313.msg1390522#msg1390522 date=1355160498
Some incompatibility with python 2.6.6? I tried it on python 2.7.3 (VM) and and no error.
[/quote
Some incompatibility with python 2.6.6? I tried it on python 2.7.3 (VM) and and no error.
[/quote
It's just a warning that is actually meaningless, since it was triggered by a bug in Python. It doesn't happen for new versions of Python because the erroneous warning was removed.
December 10, 2012, 12:28:18 PM
Code:
$ python run_p2pool.py --version
/home/pioruns/p2pool/p2pool/util/pack.py:203: DeprecationWarning: object.__new__() takes no parameters
return Type.__new__(cls, bits, endianness)
9.4-11-g8bc9cd4
/home/pioruns/p2pool/p2pool/util/pack.py:203: DeprecationWarning: object.__new__() takes no parameters
return Type.__new__(cls, bits, endianness)
9.4-11-g8bc9cd4
Code:
$ python --version
Python 2.6.6
Some incompatibility with python 2.6.6? I tried it on python 2.7.3 (VM) and and no error. Python 2.6.6
December 10, 2012, 12:17:57 PM
P2Pool release 9.4 tag: 9.4 hash: c95830cd6486b848c9201668720072485b2a8aed
Windows binary: http://u.forre.st/u/ahajjytb/p2pool_win32_9.4.zip
Source zipball: https://github.com/forrestv/p2pool/zipball/9.4
Source tarball: https://github.com/forrestv/p2pool/tarball/9.4
Changes:
* Fixed inefficient memory usage - Resident memory went from 736MB to 266MB for Diablo-D3
Windows binary: http://u.forre.st/u/ahajjytb/p2pool_win32_9.4.zip
Source zipball: https://github.com/forrestv/p2pool/zipball/9.4
Source tarball: https://github.com/forrestv/p2pool/tarball/9.4
Changes:
* Fixed inefficient memory usage - Resident memory went from 736MB to 266MB for Diablo-D3
unfortunately p2pool wasted work do not go below 15-20% as was before hardfork
Stale P2Pool shares are not "wasted" - they still can solve blocks and get us all a payout. They're just don't count for P2Pool credit, which affects everyone to some degree, so everything is optimal and fair as long as your efficiency is close to 100%.
December 10, 2012, 01:53:40 AM
Where in my linux p2pool directory can I look to find the human-readable version number, e.g., currently, 9.4?
run_p2pool.py --version December 10, 2012, 01:20:00 AM
P2Pool release 9.4 tag: 9.4 hash: c95830cd6486b848c9201668720072485b2a8aed
Windows binary: http://u.forre.st/u/ahajjytb/p2pool_win32_9.4.zip
Source zipball: https://github.com/forrestv/p2pool/zipball/9.4
Source tarball: https://github.com/forrestv/p2pool/tarball/9.4
Changes:
* Fixed inefficient memory usage - Resident memory went from 736MB to 266MB for Diablo-D3
Windows binary: http://u.forre.st/u/ahajjytb/p2pool_win32_9.4.zip
Source zipball: https://github.com/forrestv/p2pool/zipball/9.4
Source tarball: https://github.com/forrestv/p2pool/tarball/9.4
Changes:
* Fixed inefficient memory usage - Resident memory went from 736MB to 266MB for Diablo-D3
unfortunately p2pool wasted work do not go below 15-20% as was before hardfork
December 10, 2012, 01:12:34 AM
Try editing your bitcoin conf with the below settings. The reasoning behind them is with less connections and less transactions to process your bitcoind will respond faster. It did help a lot for me. Also I've noticed that anyone compiling their own bitcoin from git has a big advantage too since the new db system for the next bitcoin release is way faster. If you can't compile your own keep an eye out for a 0.8RC1 when it comes out.
maxconnections=10
#Maximum size, in bytes, of blocks you create:
blockmaxsize=50000
#How many bytes of the block should be dedicated to high-priority transactions,
#included regardless of the fees they pay
blockprioritysize=2000
#Minimum block size you want to create; block will be filled with free transactions
#until there are no more or the block reaches this size:
blockminsize=0
#Fee-per-kilobyte amount (in BTC) considered the same as "free"
#Be careful setting this: if you set it to zero then
#a transaction spammer can cheaply fill blocks using
#1-satoshi-fee transactions. It should be set above the real
#cost to you of processing a transaction.
mintxfee=0.0005
Code:
maxconnections=10
#Maximum size, in bytes, of blocks you create:
blockmaxsize=50000
#How many bytes of the block should be dedicated to high-priority transactions,
#included regardless of the fees they pay
blockprioritysize=2000
#Minimum block size you want to create; block will be filled with free transactions
#until there are no more or the block reaches this size:
blockminsize=0
#Fee-per-kilobyte amount (in BTC) considered the same as "free"
#Be careful setting this: if you set it to zero then
#a transaction spammer can cheaply fill blocks using
#1-satoshi-fee transactions. It should be set above the real
#cost to you of processing a transaction.
mintxfee=0.0005
when I set maxconnections=10 my p2pool is not started, just stay in
Code:
2012-12-09 21:05:51.285000 p2pool (version 9.4)
2012-12-09 21:05:51.300000
2012-12-09 21:05:51.300000 Testing bitcoind RPC connection to 'http://127.0.0.1:8332/' with username 'zzzzz'...
2012-12-09 21:05:51.378000 ...success!
2012-12-09 21:05:51.394000 Current block hash: 23vdgbfgbfhnfgn563hyjntjntgnbgfn6443h46h3nynn4tbtbrb
2012-12-09 21:05:51.394000 Current block height: 211544
2012-12-09 21:05:51.394000
2012-12-09 21:05:51.394000 Testing bitcoind P2P connection to '127.0.0.1:8333'...
2012-12-09 21:05:51.300000
2012-12-09 21:05:51.300000 Testing bitcoind RPC connection to 'http://127.0.0.1:8332/' with username 'zzzzz'...
2012-12-09 21:05:51.378000 ...success!
2012-12-09 21:05:51.394000 Current block hash: 23vdgbfgbfhnfgn563hyjntjntgnbgfn6443h46h3nynn4tbtbrb
2012-12-09 21:05:51.394000 Current block height: 211544
2012-12-09 21:05:51.394000
2012-12-09 21:05:51.394000 Testing bitcoind P2P connection to '127.0.0.1:8333'...
December 09, 2012, 11:34:29 PM
Granted, it could be coincidence.
A handfull of shares are far too few to identify statistically valid patterns.
My stats for the past couple days with the latest bitcoind...
Code:
Shares: 137 (8 orphan, 1 dead) Stale rate: ~6.6% (3-13%) Efficiency: ~110.8% (104-115%)
Jump to: