sudo apt-get update sudo apt-get install pypy pypy-dev pypy-setuptools gcc build-essential git wget https://bootstrap.pypa.io/ez_setup.py -O - | sudo pypy sudo rm setuptools-*.zip wget https://pypi.python.org/packages/source/z/zope.interface/zope.interface-4.1.3.tar.gz#md5=9ae3d24c0c7415deb249dd1a132f0f79 tar zxf zope.interface-4.1.3.tar.gz cd zope.interface-4.1.3/ sudo pypy setup.py install cd .. sudo rm -r zope.interface-4.1.3* wget https://pypi.python.org/packages/source/T/Twisted/Twisted-15.4.0.tar.bz2 tar jxf Twisted-15.4.0.tar.bz2 cd Twisted-15.4.0 sudo pypy setup.py install cd .. sudo rm -r Twisted-15.4.0* git clone https://github.com/jtoomim/p2pool.git cd p2pool git checkout 1mb_segwitYou'll also need to install and run your bitcoind or altcoind of choice, and edit ~/.bitcoin/bitcoin.conf (or the corresponding file for litecoin or whatever other coin you intend to mine) with your bitcoind's RPC username and password. Launch your bitcoind or altcoind, and after it has finished downloading blocks and syncing, go to your p2pool directory and run
pypy run_p2pool.pyjtoomimnet vs mainnet
git clone https://github.com/jtoomim/p2pool.git cd p2pool git checkout 1mb_segwitabove with
git clone https://github.com/p2pool/p2pool.git cd p2poolNote: The BTC p2pools currently have low hashrate, which means that payouts will be infrequent, large, and unpredictable. As of Feb 2018, blocks are found on jtoomimnet on average once every 25 days, and blocks are found on mainnet on average once every 108 days. Do not mine on BTC p2pool unless you are very patient and can tolerate receiving no revenue for several months.
Yes, this is on all SHA256 nodes. But I always thought it was a hash problem on a particular ASIC.It looks like there was a bug of some sort on the BCH p2pool, causing effective hashrates to fall by a factor of about 100x. In my logs, I saw a lot of errors like this one:
2018-02-18 16:44:28.121106 Worker 139rsyPJwpqkmix2zTHyF4PDE9oNJmWifk submitted share with hash > target:
2018-02-18 16:44:28.121124 Hash: afdfa3abaa9c26715df8d7f432debf9011219b81065b0ad550359279
2018-02-18 16:44:28.121132 Target: a7c9ea61c71f78000000000000000000000000000000000000000000
After restarting my node, the problem went away. Has anyone else seen a similar issue?
The target block period is determined by Bitcoin and Bitcoin Cash. It's 10 minutes for Bitcoin (Cash) and 2.5 minutes for Litecoin. P2pool has no control over that.I'm wondering why, for the same values of BLOCK_PERIOD on BTC and BCH
BLOCK_PERIOD = 600 # s
You made different values of SHARE_PERIOD on BTC and BCH
SHARE_PERIOD = 30 # seconds
SHARE_PERIOD = 60 # seconds -- one minute
I don't think it's a good idea to spend development time on minor coins like Litecoin Cash while there are more serious issues outstanding, like the BCH bugs and the jtoomimnet/mainnet separation.Please make a p2pool for LitecoinCash
https://github.com/litecoincash/Litecoi ... r/litecash
Bad hardware.Out of curiosity, what was making your the nodes unstable?
The amount of hashrate on your node mostly doesn't matter. P2pool was designed so that even very small nodes (e.g. with one S9) can contribute effectively to the pool. While there are some fairness issues that crop up, they aren't significant until your node comprises > 20% of the pool, and they're much smaller on the BCH p2pool than on the BTC or LTC p2pools due to the slower share rate I chose for BCH.I'm not connecting to it at the moment as my hashrate is low and I wasn't sure how publicize it as a public node.
Memory usage is dependent on the Litecoin transaction throughput, and is not dependent on the node's hashrate or user count. I think the highest I've seen my LTC node get to with pypy is about 2 GB. That means that 4 GB would probably be enough until LTC either gets popular or gets spammed, at which time a 4 GB pypy node would likely crash. 8 GB is much safer. Of course, a 4 GB node running CPython would probably also crash (or slow to a crawl) during a spam event due to CPU usage, so if you only have 4 GB, pypy is almost certainly a better choice. If you're building a new node, choosing 8 GB or more is a good idea. If you're using a VPS and will be paying close attention, you can probably get away with starting with 4 GB and upgrading to 6 GB or 8 GB if a spam event on LTC ever happens.Jtoomim, what minimum memory requirement would you suggest for nodes running your fork with pypy? I thought I remember reading you say that PYPY uses a bit more memory, but uses less CPU. I've been recommending 8GB to most people that ask. But I think based off my system resource usage, 4GB might work?
Code: Select all
Unhandled Error
Traceback (most recent call last):
File "/usr/local/lib/pypy2.7/dist-packages/twisted/internet/defer.py", line 567, in _startRunCallbacks
self._runCallbacks()
File "/usr/local/lib/pypy2.7/dist-packages/twisted/internet/defer.py", line 653, in _runCallbacks
current.result = callback(current.result, *args, **kw)
File "/home/USER/jtoomim-p2pool/p2pool/p2pool/util/deferral.py", line 256, in gotResult
it(res2)
File "/home/USER/jtoomim-p2pool/p2pool/p2pool/util/deferral.py", line 233, in it
res = gen.send(cur) # external code is run here
--- <exception caught here> ---
File "/home/USER/jtoomim-p2pool/p2pool/p2pool/util/deferral.py", line 284, in _worker
self.func(*self.args, **self.kwargs)
File "/home/USER/jtoomim-p2pool/p2pool/p2pool/util/expiring_dict.py", line 109, in <lambda>
self._expire_loop = expire_loop = deferral.RobustLoopingCall(lambda: self_ref().expire())
exceptions.AttributeError: 'NoneType' object has no attribute 'expire'
Yes, I noticed.Sawa, when running your dgb-scrypt fork, it seems whatever node has the most hash, has the most efficiency share wise and other nodes miners struggle. Example being the dgb-scrypt node that has 90% of the hash, has 2% bad shares submit, while mine and yours are around 52%. Have you noticed this?
Total: 250 (Orphan: 111, Dead: 16) = 52% BAD on crypto.office | Total: 3997 (Orphan: 58, Dead: 39) = 2.4% bad on http://dgb.miningrooms.com:5025/static/ | Doing a test on mine last night, I was around 50-60% bad submits myself.
**edit** i did a git pull as well
There is a similar problem on the LCC p2pool - the hashrate disappears simultaneously on different nodes.It looks like there was a bug of some sort on the BCH p2pool, causing effective hashrates to fall by a factor of about 100x. In my logs, I saw a lot of errors like this one:
2018-02-18 16:44:28.121106 Worker 139rsyPJwpqkmix2zTHyF4PDE9oNJmWifk submitted share with hash > target:
2018-02-18 16:44:28.121124 Hash: afdfa3abaa9c26715df8d7f432debf9011219b81065b0ad550359279
2018-02-18 16:44:28.121132 Target: a7c9ea61c71f78000000000000000000000000000000000000000000
After restarting my node, the problem went away. Has anyone else seen a similar issue?
I noticed that a Litecoin p2pool node I had running on the same machine also manifested problems at the same time, but not as severe. The problems on the Litecoin node went away when I restarted my BCH node. This suggests that the BCH node was using enough resources (CPU or bandwidth) that it was preventing the Litecoin node from working properly. The rest of the Litecoin p2pool network appears to have continued to work fine, but the rest of the BCH p2pool seems to not be working fine.
I suspect this bug was an issue with the difficulty adjustment/assignment code which resulted in more shares being submitted to p2pool than p2pool could process, which in turn caused p2pool to not see all the hashrate it was getting, which then made p2pool lower its difficulty even further, etc. I will try to rewrite the pseudoshare difficulty setting code to suck less when I get a chance.
Code: Select all
bch@feather:~/ltcp2pool$ grep 137949cecc261593cc3e2423f84a31c71c10c7577e8c42023b45ccbd9fe22360 -C 5 ~/.litecoin/debug.log
2018-02-22 13:44:10 ERROR: ConnectBlock(): coinbase pays too much (actual=2511629881 vs limit=2511272981)
2018-02-22 13:44:10 InvalidChainFound: invalid block=137949cecc261593cc3e2423f84a31c71c10c7577e8c42023b45ccbd9fe22360 height=1373311 log2_work=70.057888 date=2018-02-22 13:43:58
2018-02-22 13:44:10 InvalidChainFound: current best=c30bc3be3604808e2456ee14dda6d2283b2954b0c2dc811f4395bb6a6a9cb1d8 height=1373310 log2_work=70.057863 date=2018-02-22 13:42:14
2018-02-22 13:44:10 ERROR: ConnectTip(): ConnectBlock 137949cecc261593cc3e2423f84a31c71c10c7577e8c42023b45ccbd9fe22360 failed
2018-02-22 13:44:10 InvalidChainFound: invalid block=137949cecc261593cc3e2423f84a31c71c10c7577e8c42023b45ccbd9fe22360 height=1373311 log2_work=70.057888 date=2018-02-22 13:43:58
2018-02-22 13:44:10 InvalidChainFound: current best=c30bc3be3604808e2456ee14dda6d2283b2954b0c2dc811f4395bb6a6a9cb1d8 height=1373310 log2_work=70.057863 date=2018-02-22 13:42:14
2018-02-22 13:44:11 ERROR: AcceptBlockHeader: block 137949cecc261593cc3e2423f84a31c71c10c7577e8c42023b45ccbd9fe22360 is marked invalid
2018-02-22 13:44:11 Peer 10 sent us invalid header via cmpctblock
2018-02-22 13:44:11 ERROR: AcceptBlockHeader: block 137949cecc261593cc3e2423f84a31c71c10c7577e8c42023b45ccbd9fe22360 is marked invalid
2018-02-22 13:44:11 Peer 14 sent us invalid header via cmpctblock
2018-02-22 13:44:14 ERROR: AcceptBlockHeader: block 137949cecc261593cc3e2423f84a31c71c10c7577e8c42023b45ccbd9fe22360 is marked invalid
2018-02-22 13:44:14 ERROR: ProcessNewBlock: AcceptBlock FAILED
2018-02-22 13:44:49 UpdateTip: new best=7f3817c6619ee41b4a6b329dd5f39eb758d4b881ad96115ff97d20a6e54f08df height=1373311 version=0x20000000 log2_work=70.057888 tx=21664794 date='2018-02-22 13:44:38' progress=1.000000 cache=45.6MiB(11831tx)
Users browsing this forum: No registered users and 21 guests