 Show Posts
|
|
Pages: [1]
|
|
Disregard the vps.forre.st it is a known issue, probably resolved when jtoomin gets the main code updated with forrest permission.... right now there are two versions on p2pool running main and jtoomin
regards
|
|
|
|
|
@jtoomim
Replaced the AMD 6128 processor with a AMD 6204 bursting at 3.3ghz which helped a bit.
BTC P2Pool running at ~82% Eff - i have several old S3 pointing at this node so probably holding it down, the Dash and LTC P2Pools on this same server are running 100%+ so
thanks for processor and pypy improvements - will probably upgrade at some point when the machine becomes unstable.
Any news on P2Pool merge?
thanks
|
|
|
|
Post number 1 will get you started, and the docs on p2pool github...... then there are over 800 pages of development...  P2Pool does take a little research to get up and running.... but I like the distributed network without throwing my hash power to Antpool. regards, |
|
|
|
After mining for about 8 hours pypy is doing much better, was watching the cpu utilization and it never hit 100% like it did with python so I will watch this for awhile and it looks like the miners are generating shares http://97.77.64.18:9332/static/index.htmlThe graphs page show a great decrease in latency  The stats do show we create/solved a few solutions. I still need to make sure I am using the correct branch. I am seeing some of the same results as Cryptonomist....but assume my miners were too slow and the transaction was already complete. logs with --bench 2017-12-09 06:58:49.092191 Peer sent entire transaction 899cbf82a1e839e565dc1bb6d6f7346760a17bfa0eb62ac52f426283a4c5c933 that was already received
2017-12-09 06:58:49.107110 15.113 ms for 0 txs in p2p.py:handle_remember_tx (15.113 ms/tx)
2017-12-09 06:58:49.739611 5.692 ms for work.py:got_response()
2017-12-09 06:58:49.757925 0.074 ms for 21 txs in handle_losing_tx (0.004 ms/tx)
2017-12-09 06:58:49.788240 7.113 ms for work.py:got_response()
2017-12-09 06:58:50.059477 5.123 ms for work.py:got_response()
2017-12-09 06:58:51.941826 9.247 ms for 35 txs in p2p.py:handle_remember_tx (0.264 ms/tx)
2017-12-09 06:58:52.559175 4.877 ms for work.py:got_response()
2017-12-09 06:58:52.710049 6.561 ms for work.py:got_response()
2017-12-09 06:58:54.069984 4.063 ms for work.py:got_response()
2017-12-09 06:58:54.758305 0.085 ms for 21 txs in handle_losing_tx (0.004 ms/tx)
2017-12-09 06:58:54.968584 4.851 ms for work.py:got_response()
2017-12-09 06:58:55.720537 6.651 ms for work.py:got_response()
2017-12-09 06:58:56.291616 0.084 ms for 20 txs in handle_losing_tx (0.004 ms/tx)
2017-12-09 06:58:56.377485 5.816 ms for work.py:got_response()
2017-12-09 06:58:56.494658 5.494 ms for work.py:got_response()
2017-12-09 06:58:57.356390 0.067 ms for 20 txs in handle_losing_tx (0.003 ms/tx)
2017-12-09 06:58:58.029431 0.084 ms for 34 txs in handle_losing_tx (0.002 ms/tx)
2017-12-09 06:58:58.076610 4.853 ms for work.py:got_response()
2017-12-09 06:58:58.155988 33.165 ms for update_remote_view_of_my_known_txs
2017-12-09 06:58:58.184428 27.724 ms for update_remote_view_of_my_known_txs
2017-12-09 06:58:58.211773 26.689 ms for update_remote_view_of_my_known_txs
2017-12-09 06:58:58.236410 24.039 ms for update_remote_view_of_my_known_txs
2017-12-09 06:58:58.258269 21.322 ms for update_remote_view_of_my_known_txs
2017-12-09 06:58:58.280302 21.479 ms for update_remote_view_of_my_known_txs
2017-12-09 06:58:58.302797 21.907 ms for update_remote_view_of_my_known_txs
2017-12-09 06:58:58.324515 21.185 ms for update_remote_view_of_my_known_txs
2017-12-09 06:58:58.342164 17.110 ms for update_remote_view_of_my_known_txs
2017-12-09 06:58:58.506453 2.884 ms for work.py:got_response()
2017-12-09 06:58:58.703789 3.334 ms for work.py:got_response()
2017-12-09 06:58:59.243816 Peer sent entire transaction 899cbf82a1e839e565dc1bb6d6f7346760a17bfa0eb62ac52f426283a4c5c933 that was already received
2017-12-09 06:58:59.275476 32.095 ms for 0 txs in p2p.py:handle_remember_tx (32.095 ms/tx)
2017-12-09 06:59:01.035604 4.068 ms for work.py:got_response()
2017-12-09 06:59:01.296439 Peer sent entire transaction 53e8f5decead09879430377a846cc5fa0248b8f20d997e3d7b021440577d6198 that was already received
2017-12-09 06:59:01.307575 11.334 ms for 0 txs in p2p.py:handle_remember_tx (11.334 ms/tx)
================
2017-12-09 07:15:59.335277 1.115 ms for 1 shares in sendShares (1.115 ms/share)
2017-12-09 07:15:59.336851 1.305 ms for 1 shares in sendShares (1.305 ms/share)
2017-12-09 07:15:59.338391 1.273 ms for 1 shares in sendShares (1.273 ms/share)
2017-12-09 07:15:59.513629 Generating a share with 1049203 bytes (4922 new) and 1682 transactions (14 new)
2017-12-09 07:15:59.742585 New work for 1P9NC51Xxxxxxxxxxxxxxxxxxxxxxx! Diff: 854.52 Share diff: 1597970.59 Block value: 17.53 BTC (1682 tx, 1049 kB)
2017-12-09 07:15:59.743501 404.192 ms for work.py:get_work()
2017-12-09 07:15:59.935287 Generating a share with 1049203 bytes (4922 new) and 1682 transactions (14 new)
2017-12-09 07:16:00.115778 370.224 ms for work.py:get_work()
2017-12-09 07:16:00.290388 Generating a share with 1049203 bytes (4922 new) and 1682 transactions (14 new)
2017-12-09 07:16:00.773628 655.698 ms for work.py:get_work()
2017-12-09 07:16:01.727765 Generating a share with 1049203 bytes (4922 new) and 1682 transactions (14 new)
2017-12-09 07:16:02.126340 1343.181 ms for work.py:get_work()
2017-12-09 07:16:02.414538 Generating a share with 1049203 bytes (4922 new) and 1682 transactions (14 new)
2017-12-09 07:16:02.663207 535.062 ms for work.py:get_work()
2017-12-09 07:16:02.966352 Generating a share with 1049203 bytes (4922 new) and 1682 transactions (14 new)
2017-12-09 07:16:03.127259 462.104 ms for work.py:get_work()
2017-12-09 07:16:03.128754 4236.527 ms for 1 shares in handle_shares (4236.527 ms/share)
2017-12-09 07:16:03.704863 0.060 ms for 0 txs in p2p.py:handle_remember_tx (0.060 ms/tx)
2017-12-09 07:16:04.041200 0.959 ms for 0 shares in sendShares (0.959 ms/share)
thanks jtoomim Moderator note: frodocooper edited this post to include code tags. |
|
|
|
|
jtoomim,
I setup pypy and it is running about the same - so will try this for a few days and see if my latency drops.
It looks like I was running the forest master branch after researching git somewhat.
Are you still suggesting to run your 1mb_segwit branch?
thanks
|
|
|
|
AMD Opteron 6128 - python is running near 100% so pypy may have to be my route as this processor may be a little weak even with 8 cores 32GB Memory Hard Drive may be a 5400rpm - this was an old server that I revived and i just grabbed a 1TB HD I had, could have probably used a SSD I didn't realize this was going to be so intensive ... I may have to rebuild, but will give pypy a try 1st Bitcoind GetBlockTemplate Latency is bad - mean of 9.07 seconds Memory Usage is about 1.9GB However this server is also server a Dash Node and a Litecoin node and running as expected. Latency is around .0201s on the Dash node with memory of 235MB, and about .0668s on the Litecoin node with memory of 1.26gb I am also not sure what version of your code I am using, terrible with git, what would be the command to change from jtoomim/p2pool to https://github.com/jtoomim/p2pool/tree/1mb_segwit.gitif that is the current version I should use. --bench has been added, will supply debug.log shortly. thanks |
|
|
|
I have switched over to https://github.com/jtoomim/p2pool code and things seem better, but still occasionally see bitcoind not responding errors. I review the bitcoind logs receive version message: /P2Pool:17.0-4-g68f653f-dirty/: version 70002, blocks=0, us=127.0.0.1:8333, peer=41
2017-12-08 16:01:59 Misbehaving: 127.0.0.1:52702 peer=41 (0 -> 100) BAN THRESHOLD EXCEEDED
2017-12-08 16:01:59 Warning: not banning local peer 127.0.0.1:52702!
i can increase the banscore index to 150 ? not sure if this is a good move. Any Suggestions? current bitcoin.conf file rpcuser=bitcoinusernamegoeshere
rpcpassword=bigolpasswordgoeshere
#----
#rpcallowip=127.0.0.1
#----
listen=1
server=1
daemon=1
maxconnections=20
#blockmaxsize=1000000 #default is 500000 (deprecated)
blockmaxweight=3950000
mintxfee=0.00001
minrelaytxfee=0.00001
dbcache=500
maxmempool=500
rpcthreads=50
addnode=v4.us-west.fibre.bitcoinrelaynetwork.org
#--------------------
|
|
|
|
|
Thanks for the blockmaxweight tip - I was using the old suggestions.
>>>>>
Please ignore the bits that suggest setting and tuning a blockmaxsize value. The blockmaxsize parameter has been deprecated in favor of the blockmaxweight parameter, which you should set to a suggested maximum of 3950000.
If you have a system with a reasonably fast CPU (one with a base clock of at least 2.4 GHz) and at least 4 GB of RAM, you may want to try out jtoomim's 1mb_segwit fork, if you aren't already, which promises better overall performance and reward fairness. Using PyPy to run 1mb_segwit is highly recommended for maximum performance.
<<<<<
|
|
|
|
|
Thanks,
I have plenty of ram on this system, before I try a new fork would this be a bitcoind ram issue or p2pool ram issue and what setting would I set to give the program a little more breathing room.
thanks,
|
|
|
|
|
Is there a way to minimize or increase performance on either bitcoin or p2pool
Warning: LOST CONTACT WITH BITCOIND for 1.8 minutes! Check that it isn't frozen or dead
The stats on my p2pool for bitcoin are really slow
bitcoind and p2pool are running on the same machine
thx
|
|
|
|
|
