Right, just switched over to the newest git from Rav3n's skydrive - thanks for the heads up Rav3n. Lets see how this baby goes......
Topic: [1500 TH] p2pool: Decentralized, DoS-resistant, Hop-Proof pool - page 614. (Read 2591920 times)
November 29, 2012, 05:35:27 AM
OK, after 18 hours uptime I can't see any significant change - still at 25%+ orphan/dead rate with large memory usage. I have also noticed a lot of the "tx" comments in the logs, as well as the "punishing share for stale" thing - whats with that? Even with the high stale rate I notice we're still getting payouts on blocks (albeit lower since halving) so it's not all bad, although I find myself wondering what the payouts would be with a normal reject/orphaned/dead rate......
Right, just switched over to the newest git from Rav3n's skydrive - thanks for the heads up Rav3n. Lets see how this baby goes......
Right, just switched over to the newest git from Rav3n's skydrive - thanks for the heads up Rav3n. Lets see how this baby goes......
November 29, 2012, 04:01:46 AM
Latest git 9.1-9-gb246991 works much better for me.
Memory usage on linux finally drop to around 500MB, no doas.
Windows binary (32 bit) on my skydrive.
Memory usage on linux finally drop to around 500MB, no doas.
Windows binary (32 bit) on my skydrive.
November 29, 2012, 01:00:33 AM
After a git pull I'm seeing this line repeated very often in the log.
2012-11-29 00:00:01.675185 Punishing share for 'not all txs present'! Jumping from fdbd8fa8 to b29d41a0!
2012-11-29 00:00:01.835841 Punishing share for 'not all txs present'! Jumping from fdbd8fa8 to b29d41a0!
2012-11-29 00:00:01.887518 Punishing share for 'not all txs present'! Jumping from fdbd8fa8 to b29d41a0!
2012-11-29 00:00:01.940477 Punishing share for 'not all txs present'! Jumping from fdbd8fa8 to b29d41a0!
2012-11-29 00:00:01.675185 Punishing share for 'not all txs present'! Jumping from fdbd8fa8 to b29d41a0!
2012-11-29 00:00:01.835841 Punishing share for 'not all txs present'! Jumping from fdbd8fa8 to b29d41a0!
2012-11-29 00:00:01.887518 Punishing share for 'not all txs present'! Jumping from fdbd8fa8 to b29d41a0!
2012-11-29 00:00:01.940477 Punishing share for 'not all txs present'! Jumping from fdbd8fa8 to b29d41a0!
November 28, 2012, 09:09:37 PM
Well.. after about 24 hours, the new version isn't helping me any. I still get 5-10% rejects from cgminer, and 25% stale/dead from p2pool. Maybe stratum will help.
M
M
November 28, 2012, 08:11:00 PM
so we hit the halving. and p2pool thinks the next block is worth 38.55495555 BTC
there's not a chance in hell there's 13.5btc in transaction fees.
there's not a chance in hell there's 13.5btc in transaction fees.
Actually there is
Look: https://blockchain.info/block-height/210000Transaction Fees 13.56295554 BTC
It was planned action (by Twitters), for 210000 block to be remembered in history
November 28, 2012, 12:38:26 PM
That's looking better, even though it is early doors. How did you manage to get connected to so many peers (30 &24 in)? I've never managed to get above 11 & 0 in.....
That's 6 outgoing (which is the recently revised default) and those always fill up quickly. The incoming ones always take a few hours to re-arrive after I restart p2pool. The only way another node will connect to me is if it is restarted, itself (and therefore needs to re-establish it's 6 outgoing connections) or if it loses one of its 6 outgoing connections. Also, nodes prefer to connect to "old" peers that have been around for a long time, and my node has been running consistently for about a year, so I don't usually have to wait more than a day to be full on incoming connections again.
i changed the code to create 30 outgoing connections, its fairly easy!
There is a reason it has a low default and is limited to 10: Outgoing connections are a limited resource, since few nodes are set up to accept incoming connections. See the discussion of the "Hub" patch to Bitcoin.
Besides that, you don't need that many connections. Bandwidth usage scales linearly with number of connections, but the benefit of increased connections on your orphan rate is small.
gonna try 100 later just for fun ^^ November 28, 2012, 12:33:07 PM
That's looking better, even though it is early doors. How did you manage to get connected to so many peers (30 &24 in)? I've never managed to get above 11 & 0 in.....
That's 6 outgoing (which is the recently revised default) and those always fill up quickly. The incoming ones always take a few hours to re-arrive after I restart p2pool. The only way another node will connect to me is if it is restarted, itself (and therefore needs to re-establish it's 6 outgoing connections) or if it loses one of its 6 outgoing connections. Also, nodes prefer to connect to "old" peers that have been around for a long time, and my node has been running consistently for about a year, so I don't usually have to wait more than a day to be full on incoming connections again.
i changed the code to create 30 outgoing connections, its fairly easy!
There is a reason it has a low default and is limited to 10: Outgoing connections are a limited resource, since few nodes are set up to accept incoming connections. See the discussion of the "Hub" patch to Bitcoin.
Besides that, you don't need that many connections. Bandwidth usage scales linearly with number of connections, but the benefit of increased connections on your orphan rate is small.
November 28, 2012, 12:15:09 PM
That's looking better, even though it is early doors. How did you manage to get connected to so many peers (30 &24 in)? I've never managed to get above 11 & 0 in.....
That's 6 outgoing (which is the recently revised default) and those always fill up quickly. The incoming ones always take a few hours to re-arrive after I restart p2pool. The only way another node will connect to me is if it is restarted, itself (and therefore needs to re-establish it's 6 outgoing connections) or if it loses one of its 6 outgoing connections. Also, nodes prefer to connect to "old" peers that have been around for a long time, and my node has been running consistently for about a year, so I don't usually have to wait more than a day to be full on incoming connections again.
i changed the code to create 30 outgoing connections, its fairly easy!
November 28, 2012, 11:37:47 AM
That's looking better, even though it is early doors. How did you manage to get connected to so many peers (30 &24 in)? I've never managed to get above 11 & 0 in.....
That's 6 outgoing (which is the recently revised default) and those always fill up quickly. The incoming ones always take a few hours to re-arrive after I restart p2pool. The only way another node will connect to me is if it is restarted, itself (and therefore needs to re-establish it's 6 outgoing connections) or if it loses one of its 6 outgoing connections. Also, nodes prefer to connect to "old" peers that have been around for a long time, and my node has been running consistently for about a year, so I don't usually have to wait more than a day to be full on incoming connections again.
November 28, 2012, 10:27:36 AM
so we hit the halving. and p2pool thinks the next block is worth 38.55495555 BTC
there's not a chance in hell there's 13.5btc in transaction fees.
there's not a chance in hell there's 13.5btc in transaction fees.
There is. Looks like some people are celebrating by paying big txfees for the first 25 BTC block.
yep guess so,
http://blockchain.info/block-index/322335/000000000000048b95347e83192f69cf0366076336c639f9b7228e9ba171342e
lol
November 28, 2012, 10:25:05 AM
so we hit the halving. and p2pool thinks the next block is worth 38.55495555 BTC
there's not a chance in hell there's 13.5btc in transaction fees.
there's not a chance in hell there's 13.5btc in transaction fees.
There is. Looks like some people are celebrating by paying big txfees for the first 25 BTC block.
November 28, 2012, 10:22:54 AM
so we hit the halving. and p2pool thinks the next block is worth 38.55495555 BTC
there's not a chance in hell there's 13.5btc in transaction fees.
there's not a chance in hell there's 13.5btc in transaction fees.
November 28, 2012, 10:22:18 AM
Right, thanks rav3n, but 9333 is already open. Is there a reason why the defaults are 40 & 6? And would there be any benefit in changing them?
Still a noob, still learning......
The more nodes you connect to the faster your shares reach the entire network and the fewer stales you will have. But if you are on a home internet connection you don't want to saturate your upload bandwidth because that will just mess everything up and Bitcoin needs to take a chunk of bandwidth too. So try to strike a balance that suits your connection.
Right, thanks rav3n, but 9333 is already open. Is there a reason why the defaults are 40 & 6? And would there be any benefit in changing them?
Still a noob, still learning......
The more nodes you connect to the faster your shares reach the entire network and the fewer stales you will have. But if you are on a home internet connection you don't want to saturate your upload bandwidth because that will just mess everything up and Bitcoin needs to take a chunk of bandwidth too. So try to strike a balance that suits your connection.
Thanks cabin,
Seeing as my internet is snails pace anyway I'll leave those settings at default then.....
November 28, 2012, 10:00:27 AM
Right, thanks rav3n, but 9333 is already open. Is there a reason why the defaults are 40 & 6? And would there be any benefit in changing them?
Still a noob, still learning......
The more nodes you connect to the faster your shares reach the entire network and the fewer stales you will have. But if you are on a home internet connection you don't want to saturate your upload bandwidth because that will just mess everything up and Bitcoin needs to take a chunk of bandwidth too. So try to strike a balance that suits your connection.
November 28, 2012, 08:49:54 AM
ng better, even though it is early doors. How did you manage to get connected to so many peers (30 &24 in)? I've never managed to get above 11 & 0 in.....
Code:
usage: run_p2pool.exe [-h] [--version] [--net {bitcoin,litecoin}] [--testnet]
[--debug] [-a ADDRESS] [--datadir DATADIR]
[--logfile LOGFILE] [--merged MERGED_URLS]
[--give-author DONATION_PERCENTAGE] [--iocp]
[--irc-announce] [--no-bugreport] [--p2pool-port PORT]
[-n ADDR[:PORT]] [--disable-upnp] [--max-conns CONNS]
[--outgoing-conns CONNS] [-w PORT or ADDR:PORT]
[-f FEE_PERCENTAGE]
[--bitcoind-address BITCOIND_ADDRESS]
[--bitcoind-rpc-port BITCOIND_RPC_PORT]
[--bitcoind-rpc-ssl]
[--bitcoind-p2p-port BITCOIND_P2P_PORT]
[BITCOIND_RPCUSERPASS [BITCOIND_RPCUSERPASS ...]]
(...)
--max-conns CONNS maximum incoming connections (default: 40)
--outgoing-conns CONNS
outgoing connections (default: 6)
You need also open port 9333 to accept incoming.[--debug] [-a ADDRESS] [--datadir DATADIR]
[--logfile LOGFILE] [--merged MERGED_URLS]
[--give-author DONATION_PERCENTAGE] [--iocp]
[--irc-announce] [--no-bugreport] [--p2pool-port PORT]
[-n ADDR[:PORT]] [--disable-upnp] [--max-conns CONNS]
[--outgoing-conns CONNS] [-w PORT or ADDR:PORT]
[-f FEE_PERCENTAGE]
[--bitcoind-address BITCOIND_ADDRESS]
[--bitcoind-rpc-port BITCOIND_RPC_PORT]
[--bitcoind-rpc-ssl]
[--bitcoind-p2p-port BITCOIND_P2P_PORT]
[BITCOIND_RPCUSERPASS [BITCOIND_RPCUSERPASS ...]]
(...)
--max-conns CONNS maximum incoming connections (default: 40)
--outgoing-conns CONNS
outgoing connections (default: 6)
Right, thanks rav3n, but 9333 is already open. Is there a reason why the defaults are 40 & 6? And would there be any benefit in changing them?
Still a noob, still learning......
November 28, 2012, 08:18:11 AM
ng better, even though it is early doors. How did you manage to get connected to so many peers (30 &24 in)? I've never managed to get above 11 & 0 in.....
Code:
usage: run_p2pool.exe [-h] [--version] [--net {bitcoin,litecoin}] [--testnet]
[--debug] [-a ADDRESS] [--datadir DATADIR]
[--logfile LOGFILE] [--merged MERGED_URLS]
[--give-author DONATION_PERCENTAGE] [--iocp]
[--irc-announce] [--no-bugreport] [--p2pool-port PORT]
[-n ADDR[:PORT]] [--disable-upnp] [--max-conns CONNS]
[--outgoing-conns CONNS] [-w PORT or ADDR:PORT]
[-f FEE_PERCENTAGE]
[--bitcoind-address BITCOIND_ADDRESS]
[--bitcoind-rpc-port BITCOIND_RPC_PORT]
[--bitcoind-rpc-ssl]
[--bitcoind-p2p-port BITCOIND_P2P_PORT]
[BITCOIND_RPCUSERPASS [BITCOIND_RPCUSERPASS ...]]
(...)
--max-conns CONNS maximum incoming connections (default: 40)
--outgoing-conns CONNS
outgoing connections (default: 6)
You need also open port 9333 to accept incoming.[--debug] [-a ADDRESS] [--datadir DATADIR]
[--logfile LOGFILE] [--merged MERGED_URLS]
[--give-author DONATION_PERCENTAGE] [--iocp]
[--irc-announce] [--no-bugreport] [--p2pool-port PORT]
[-n ADDR[:PORT]] [--disable-upnp] [--max-conns CONNS]
[--outgoing-conns CONNS] [-w PORT or ADDR:PORT]
[-f FEE_PERCENTAGE]
[--bitcoind-address BITCOIND_ADDRESS]
[--bitcoind-rpc-port BITCOIND_RPC_PORT]
[--bitcoind-rpc-ssl]
[--bitcoind-p2p-port BITCOIND_P2P_PORT]
[BITCOIND_RPCUSERPASS [BITCOIND_RPCUSERPASS ...]]
(...)
--max-conns CONNS maximum incoming connections (default: 40)
--outgoing-conns CONNS
outgoing connections (default: 6)
November 28, 2012, 07:52:00 AM
This release is a test to see whether it mitigates the high stale proportion the pool is seeing. Please use it and report if things improve for you!
It's probably not been long enough for this to be statistically valid, but things look better for me (prior to this version I was closer to 20% stale rate):
Code:
P2Pool: 17355 shares in chain (17359 verified/17359 total) Peers: 30 (24 incoming)
Local: 1610MH/s in last 10.0 minutes Local dead on arrival: ~1.8% (0-5%) Expected time to share: 28.7 minutes
Shares: 18 (0 orphan, 1 dead) Stale rate: ~5.6% (0-26%) Efficiency: ~117.8% (92-124%) Current payout: 0.2555 BTC
Pool: 365GH/s Stale rate: 19.8% Expected time to block: 11.2 hours
Local: 1610MH/s in last 10.0 minutes Local dead on arrival: ~1.8% (0-5%) Expected time to share: 28.7 minutes
Shares: 18 (0 orphan, 1 dead) Stale rate: ~5.6% (0-26%) Efficiency: ~117.8% (92-124%) Current payout: 0.2555 BTC
Pool: 365GH/s Stale rate: 19.8% Expected time to block: 11.2 hours
We'll see how things look after another 24-48 hours.
That's looking better, even though it is early doors. How did you manage to get connected to so many peers (30 &24 in)? I've never managed to get above 11 & 0 in.....
November 28, 2012, 07:44:33 AM
This release is a test to see whether it mitigates the high stale proportion the pool is seeing. Please use it and report if things improve for you!
It's probably not been long enough for this to be statistically valid, but things look better for me (prior to this version I was closer to 20% stale rate):
Code:
P2Pool: 17355 shares in chain (17359 verified/17359 total) Peers: 30 (24 incoming)
Local: 1610MH/s in last 10.0 minutes Local dead on arrival: ~1.8% (0-5%) Expected time to share: 28.7 minutes
Shares: 18 (0 orphan, 1 dead) Stale rate: ~5.6% (0-26%) Efficiency: ~117.8% (92-124%) Current payout: 0.2555 BTC
Pool: 365GH/s Stale rate: 19.8% Expected time to block: 11.2 hours
Local: 1610MH/s in last 10.0 minutes Local dead on arrival: ~1.8% (0-5%) Expected time to share: 28.7 minutes
Shares: 18 (0 orphan, 1 dead) Stale rate: ~5.6% (0-26%) Efficiency: ~117.8% (92-124%) Current payout: 0.2555 BTC
Pool: 365GH/s Stale rate: 19.8% Expected time to block: 11.2 hours
We'll see how things look after another 24-48 hours.
November 28, 2012, 07:32:02 AM
P2Pool release 9.1 tag: 9.1 hash: 9742ead60733e26f94ee10a16c43ee7cb403e88c
Windows binary: http://u.forre.st/u/fngdrqsq/p2pool_win32_9.1.zip
Source zipball: https://github.com/forrestv/p2pool/zipball/9.1
Source tarball: https://github.com/forrestv/p2pool/tarball/9.1
Changes:
* Don't connect to older nodes and ignore old shares
This release is a test to see whether it mitigates the high stale proportion the pool is seeing. Please use it and report if things improve for you!
Windows binary: http://u.forre.st/u/fngdrqsq/p2pool_win32_9.1.zip
Source zipball: https://github.com/forrestv/p2pool/zipball/9.1
Source tarball: https://github.com/forrestv/p2pool/tarball/9.1
Changes:
* Don't connect to older nodes and ignore old shares
This release is a test to see whether it mitigates the high stale proportion the pool is seeing. Please use it and report if things improve for you!
Thanks Forrestv - checking it out now, stay tooned.
November 28, 2012, 05:04:06 AM
P2Pool release 9.1 tag: 9.1 hash: 9742ead60733e26f94ee10a16c43ee7cb403e88c
Windows binary: http://u.forre.st/u/fngdrqsq/p2pool_win32_9.1.zip
Source zipball: https://github.com/forrestv/p2pool/zipball/9.1
Source tarball: https://github.com/forrestv/p2pool/tarball/9.1
Changes:
* Don't connect to older nodes and ignore old shares
This release is a test to see whether it mitigates the high stale proportion the pool is seeing. Please use it and report if things improve for you!
Windows binary: http://u.forre.st/u/fngdrqsq/p2pool_win32_9.1.zip
Source zipball: https://github.com/forrestv/p2pool/zipball/9.1
Source tarball: https://github.com/forrestv/p2pool/tarball/9.1
Changes:
* Don't connect to older nodes and ignore old shares
This release is a test to see whether it mitigates the high stale proportion the pool is seeing. Please use it and report if things improve for you!
After about 7 hours @ ~4.8GH/s:
46 shares, 9 orphaned, 3 dead, 26% stale rate. Not any better. But I was asleep, I can't tell if I had my normal connection problems over night. Might not be p2pool's fault.
In other news, pool hash is < 300GH/s, making my slice of the pie bigger. Now if we can just get a block or two before the great halving occurs.
M
Jump to: