sEpuLchEr
Sr. Member
Offline
Activity: 248
Merit: 250
Are we there yet?
|
|
January 17, 2015, 08:34:20 PM |
|
oooiii... what happen to the hashrate??
Are you guys all stuck trying to get pypy to work or merge mining? LOL.
|
|
|
|
|
mdude77
Legendary
Offline
Activity: 1540
Merit: 1001
|
|
January 17, 2015, 09:14:21 PM |
|
oooiii... what happen to the hashrate??
Are you guys all stuck trying to get pypy to work or merge mining? LOL.
Don't forget the hashrate isn't really the hashrate. It's a calculated value based on how many shares have been submitted in the last X minutes. Could easily be bad luck across the board. M
|
I mine at Kano's Pool because it pays the best and is completely transparent! Come join me!
|
|
|
windpath
Legendary
Offline
Activity: 1258
Merit: 1027
|
|
January 17, 2015, 09:15:02 PM |
|
|
|
|
|
mahrens917
|
|
January 17, 2015, 10:46:08 PM |
|
What is Your Bitcoind GetBlockTemplate Latency? Has You p2pool node external IP to see stats? Thanks for the reply! Well my stats looks like this: P2Pool Status Local rate 155.77 GH/s (DOA 3.67 GH/s / 2.35%) Shares Total: 2 (Orphan: 0, Dead: 1, Unknown: 1) Global pool rate 1.93 PH/s (DOA 321.61 TH/s / 16.67%) Share difficulty 6,707,631.61 Current block value Expected time to share 2d 3h 22m 33 s Total node payout if block found NOW Expected time to block 1d 3h 11m 10 s Node peers [in] 2 / 30 [out] Node uptime 2d 6h 35m 22 s Node p2pool version 13.5-73-g12ca9d8-dirty Protocol version 1300 Node efficiency 60.00% Node getwork latency 305 ms Node fee 0% Node donation 0%
Bitcoin Status Network rate 303.41 PH/s Blocks 339,372 Current block 998,775 bytes / 1,600 txs Block difficulty 43,971,662,056.08958 Hashes to win 9.22 EH Block probability per GH 5.295015761671106e-12% Total Bitcoins Expected time to block 0h 0m 30 s Exchange rate Block interval 0h 10m 30 s Connections [in] 12 / 523 [out] Node uptime 2d 6h 37m 53 s Node bitcoind version 99900 Protocol version 70002 Relay fee Peer latency 675 ms I assume my Bitcoind GetBlockTemplate Latency is 675ms, right? From what I've read, the latencies are OK and they are stable when the "payload too long" error is not occurring. Only when the error comes up in the console of p2pool then those latencies are indeed skyrocketing. As I understand from the logs and statistics this payload error does not look like a cause from latencies, but latencies are the symptoms of the payload error. So where all the sudden arises this payload error from? Is it the "maxblocksize" of Bitcoind Core which is 1MB? Because the payload error is always in combination when the blocktime between blocks were +10mins (and +2000 transactions). Get the idea the problem comes from that direction. Any thoughts? Yes. 1) Switch to latest p2pool version. git clone https://github.com/forrestv/p2pool2) to limit outgoing/incomming connections of p2pool use this settings: --max-conns 6 \ --outgoing-conns 6 \ 3) use 0.9.4.0 bitcoin core version with bitcoin.conf like this (nothing more is necessary): server=1 rpcuser=your_rpc_user rpcpassword=your_rpc_password Thanks for the tips. I have the latest p2pool and bitcoind code and have limited my incoming and outgoing p2pool connections. However, my bitcoin.conf file does set blockmaxsize, minrelaytxfee, maxconnections, blockminsize, blockprioritysize, and mintxfee. Do you believe that one of those settings could cause this issue within p2pool?
|
|
|
|
IYFTech
|
|
January 17, 2015, 10:56:57 PM |
|
I leave my conf file with the bear minimum needed, and I don't adjust my p2pool settings either - everything works perfectly using the standard settings for me apart from maxconnections to reduce the bandwidth usage - my ADSL line is shite
|
|
|
|
mahrens917
|
|
January 17, 2015, 11:03:30 PM |
|
So doing some digging, the "payload too long" error comes about when a packet's length is greater than max_payload_length. This can be seen in p2pool/util/p2protocol.py. This is called from p2pool/bitcoin/p2p.py and p2pool/p2p.py where it sets max_payload_length to 1,000,000. I am going to change the code to print out the packet size, as well as, change the max_payload_length to twice the size. I will let the code run for awhile and see what happens and report back.
|
|
|
|
Gumara
|
|
January 17, 2015, 11:52:55 PM |
|
I have one question. Is it recommended to give the address with the -a flag and save this address is always the same? Does it make a difference?
|
|
|
|
idonothave
|
|
January 18, 2015, 12:14:56 AM |
|
What is Your Bitcoind GetBlockTemplate Latency? Has You p2pool node external IP to see stats? Thanks for the reply! Well my stats looks like this: P2Pool Status Local rate 155.77 GH/s (DOA 3.67 GH/s / 2.35%) Shares Total: 2 (Orphan: 0, Dead: 1, Unknown: 1) Global pool rate 1.93 PH/s (DOA 321.61 TH/s / 16.67%) Share difficulty 6,707,631.61 Current block value Expected time to share 2d 3h 22m 33 s Total node payout if block found NOW Expected time to block 1d 3h 11m 10 s Node peers [in] 2 / 30 [out] Node uptime 2d 6h 35m 22 s Node p2pool version 13.5-73-g12ca9d8-dirty Protocol version 1300 Node efficiency 60.00% Node getwork latency 305 ms Node fee 0% Node donation 0%
Bitcoin Status Network rate 303.41 PH/s Blocks 339,372 Current block 998,775 bytes / 1,600 txs Block difficulty 43,971,662,056.08958 Hashes to win 9.22 EH Block probability per GH 5.295015761671106e-12% Total Bitcoins Expected time to block 0h 0m 30 s Exchange rate Block interval 0h 10m 30 s Connections [in] 12 / 523 [out] Node uptime 2d 6h 37m 53 s Node bitcoind version 99900 Protocol version 70002 Relay fee Peer latency 675 ms I assume my Bitcoind GetBlockTemplate Latency is 675ms, right? From what I've read, the latencies are OK and they are stable when the "payload too long" error is not occurring. Only when the error comes up in the console of p2pool then those latencies are indeed skyrocketing. As I understand from the logs and statistics this payload error does not look like a cause from latencies, but latencies are the symptoms of the payload error. So where all the sudden arises this payload error from? Is it the "maxblocksize" of Bitcoind Core which is 1MB? Because the payload error is always in combination when the blocktime between blocks were +10mins (and +2000 transactions). Get the idea the problem comes from that direction. Any thoughts? Yes. 1) Switch to latest p2pool version. git clone https://github.com/forrestv/p2pool2) to limit outgoing/incomming connections of p2pool use this settings: --max-conns 6 \ --outgoing-conns 6 \ 3) use 0.9.4.0 bitcoin core version with bitcoin.conf like this (nothing more is necessary): server=1 rpcuser=your_rpc_user rpcpassword=your_rpc_password Thanks for the tips. I have the latest p2pool and bitcoind code and have limited my incoming and outgoing p2pool connections. However, my bitcoin.conf file does set blockmaxsize, minrelaytxfee, maxconnections, blockminsize, blockprioritysize, and mintxfee. Do you believe that one of those settings could cause this issue within p2pool? Do You know the reason for each one parameter in Your bitcoin.conf file? If no, or they are not really necessary from very good reason, remove them. Give it a chance to work.
|
|
|
|
corrow
Member
Offline
Activity: 97
Merit: 10
|
|
January 18, 2015, 02:02:53 PM |
|
So doing some digging, the "payload too long" error comes about when a packet's length is greater than max_payload_length. This can be seen in p2pool/util/p2protocol.py. This is called from p2pool/bitcoin/p2p.py and p2pool/p2p.py where it sets max_payload_length to 1,000,000. I am going to change the code to print out the packet size, as well as, change the max_payload_length to twice the size. I will let the code run for awhile and see what happens and report back. If I'm correct the 'maxblocksize' is hardcoded to 1MB into the Bitcoin protocol. So I guess changing the payload length does do the trick within P2Pool code (until the blocksize will be increased). Well it is still unclear to me what part of the code you have changed. Logically it had to do with Bitcoin Core which is responsible for "packaging" the block and verify the hash of it. It would be awesome if you still could update us with news. I've also updated my Bitcoin Core and I'm waiting for a long blocktime with lots of transactions to debug my new setup. So, I'll keep you guys posted! Thanks!
|
|
|
|
idonothave
|
|
January 18, 2015, 04:15:44 PM |
|
I have one question. Is it recommended to give the address with the -a flag and save this address is always the same? Does it make a difference?
Depends on what You preffer. If to mine to local wallet (where bitcoin daemon is running) or to exteral wallet. I preffer to mine to external wallet with -a option. Easier and more comfortable for me.
|
|
|
|
mahrens917
|
|
January 18, 2015, 05:09:38 PM |
|
So doing some digging, the "payload too long" error comes about when a packet's length is greater than max_payload_length. This can be seen in p2pool/util/p2protocol.py. This is called from p2pool/bitcoin/p2p.py and p2pool/p2p.py where it sets max_payload_length to 1,000,000. I am going to change the code to print out the packet size, as well as, change the max_payload_length to twice the size. I will let the code run for awhile and see what happens and report back. If I'm correct the 'maxblocksize' is hardcoded to 1MB into the Bitcoin protocol. So I guess changing the payload length does do the trick within P2Pool code (until the blocksize will be increased). Well it is still unclear to me what part of the code you have changed. Logically it had to do with Bitcoin Core which is responsible for "packaging" the block and verify the hash of it. It would be awesome if you still could update us with news. I've also updated my Bitcoin Core and I'm waiting for a long blocktime with lots of transactions to debug my new setup. So, I'll keep you guys posted! Thanks! Yes, the block should not be coming into p2pool over 1,000,000 or perhaps it is sometimes coming in with a size of 1,024,000 (another meaning of MB). Or perhaps p2pool or bitcoind is somehow corrupting it at certain times which is causing this issue. We'll see and my logging should let us know a little better what is happening.
|
|
|
|
corrow
Member
Offline
Activity: 97
Merit: 10
|
|
January 19, 2015, 06:03:49 AM Last edit: January 19, 2015, 06:53:13 AM by corrow |
|
I see you're using an Rc version: v99900 - Maybe that's what's causing your errors. I only use the stable release versions for mining.......
OMG, Why I didn't saw that myself? I'm gonna deploy a stable release of Bitcoin Core to factor this out! Thanks! I've been monitoring my P2Pool Node very closely since the update to the last Bitcoin Core version. I found out with Block #339.597 (which took about 50mins and had more than 2000tx did not grow beyond the the maxblocksize of 1.000.000! This is great news now the P2Pool did not gave any "playload too long" error at console. The update to a later Bitcoin Core did the trick. I would advise everyone to update their Bitcoin Core concerning this issue! Thanks for the good help and your efforts everyone!!!
|
|
|
|
K1773R
Legendary
Offline
Activity: 1792
Merit: 1008
/dev/null
|
|
January 19, 2015, 04:44:32 PM |
|
I see you're using an Rc version: v99900 - Maybe that's what's causing your errors. I only use the stable release versions for mining.......
OMG, Why I didn't saw that myself? I'm gonna deploy a stable release of Bitcoin Core to factor this out! Thanks! I've been monitoring my P2Pool Node very closely since the update to the last Bitcoin Core version. I found out with Block #339.597 (which took about 50mins and had more than 2000tx did not grow beyond the the maxblocksize of 1.000.000! This is great news now the P2Pool did not gave any "playload too long" error at console. The update to a later Bitcoin Core did the trick. I would advise everyone to update their Bitcoin Core concerning this issue! Thanks for the good help and your efforts everyone!!! be aware that the maxsize for a tx is 50kB. unfortunately hardcoded...
|
[GPG Public Key]BTC/DVC/TRC/FRC: 1 K1773RbXRZVRQSSXe9N6N2MUFERvrdu6y ANC/XPM A K1773RTmRKtvbKBCrUu95UQg5iegrqyeA NMC: N K1773Rzv8b4ugmCgX789PbjewA9fL9Dy1 LTC: L Ki773RBuPepQH8E6Zb1ponoCvgbU7hHmd EMC: E K1773RxUes1HX1YAGMZ1xVYBBRUCqfDoF BQC: b K1773R1APJz4yTgRkmdKQhjhiMyQpJgfN
|
|
|
jonnybravo0311
Legendary
Offline
Activity: 1344
Merit: 1024
Mine at Jonny's Pool
|
|
January 19, 2015, 06:34:44 PM |
|
Holy back to back blocks Batman!
|
Jonny's Pool - Mine with us and help us grow! Support a pool that supports Bitcoin, not a hardware manufacturer's pockets! No SPV cheats. No empty blocks.
|
|
|
windpath
Legendary
Offline
Activity: 1258
Merit: 1027
|
|
January 19, 2015, 06:55:05 PM |
|
Holy back to back blocks Batman!
No kidding! 3rd time is a charm.... Edit: Double checked to see if it was a record, that's our 2nd luckiest block since I've been tracking at %70,579 First place is still block 329431 at %180,136 (just 30 seconds after our previous block) http://minefast.coincadence.com/p2pool-stats.php?blockoffset=100
|
|
|
|
Prelude
Legendary
Offline
Activity: 1596
Merit: 1000
|
|
January 19, 2015, 07:28:14 PM |
|
|
|
|
|
yslyung
Legendary
Offline
Activity: 1500
Merit: 1002
Mine Mine Mine
|
|
January 19, 2015, 07:55:41 PM |
|
Holy back to back blocks Batman!
No kidding! 3rd time is a charm.... Edit: Double checked to see if it was a record, that's our 2nd luckiest block since I've been tracking at %70,579 First place is still block 329431 at %180,136 (just 30 seconds after our previous block) http://minefast.coincadence.com/p2pool-stats.php?blockoffset=100more the merrier ! let's rock it btw, what was the max or record for hitting the most # of blocks in 24hrs for p2p ?
|
|
|
|
windpath
Legendary
Offline
Activity: 1258
Merit: 1027
|
|
January 19, 2015, 08:36:43 PM |
|
btw, what was the max or record for hitting the most # of blocks in 24hrs for p2p ?
On February 16, 2013 16 blocks were found by P2Pool.
|
|
|
|
|
|