- Initial support for Bitcoin Cash. Use --net bitcoincash at the command line. Please let me know if you plan on running a BCH node with high uptime so I can add you to the DNS seeds list.
- Compatible with bitcoind pruning. Set "prune=10000" in your bitcoin.conf to limit it to 10 GB of disk space used for block storage (plus around 5 GB for the UTXO database)
- Improved block size and weight checking to avoid invalid blocks caused by the coinbase transaction putting the block over 4 million weight. Shares that exceed the block size or weight limits will be punished (i.e. orphaned).
- Minor CPU usage improvements by caching deserialized and unhexlified transactions when performing getblocktemplate calls
Topic: [1500 TH] p2pool: Decentralized, DoS-resistant, Hop-Proof pool - page 15. (Read 2591630 times)
December 11, 2017, 10:50:01 PM
I have pushed some new code into 1mb_segwit. Changes:
December 11, 2017, 05:52:44 PM
and thanks to all that contribute with different p2pool forks as well. Its all good work.
December 11, 2017, 05:44:57 PM
Kiefff, it looks like you have a lot of different mining addresses on the same node. Most of the work that p2pool needs to do is per worker address, not per worker. If you have 1000 miners all sharing the same worker address, that's less work for p2pool than 10 miners each with a different address. If you can change the miners to all use the same worker address, you should be able to handle the load just fine. That might not be an option, though.
I also notice that you seem to have enabled incoming p2p connections (e.g. by forwarding a port on your router) a few days ago, and you're now getting about 2x as many connections. Each connection increases the CPU load on your node, so if you have a slow CPU, you may be better off limiting your node to e.g. 5 connections total.
Pypy will probably also help as long as you have enough RAM. It looks like you're currently using about 1.8 GB of RAM on CPython, so that might increase to 4 GB if you switch to Pypy.
My p2pool modifications would probably help too, but I haven't tried running them on Litecoin yet, so I don't know if they would work.
I also notice that you seem to have enabled incoming p2p connections (e.g. by forwarding a port on your router) a few days ago, and you're now getting about 2x as many connections. Each connection increases the CPU load on your node, so if you have a slow CPU, you may be better off limiting your node to e.g. 5 connections total.
Pypy will probably also help as long as you have enough RAM. It looks like you're currently using about 1.8 GB of RAM on CPython, so that might increase to 4 GB if you switch to Pypy.
My p2pool modifications would probably help too, but I haven't tried running them on Litecoin yet, so I don't know if they would work.
Jtoomim,
I will try to limit total connections as you suggested. I will give pypy a go as well. The rig itself has 16Gb of memory and I will always increase it to meet the needs. I will do some messing around with your fork as well on my spare rig. Thank you again for the reply and honestly, what you do for p2pool in general. I see EST block time is down on your Jtoomimnet. I tell anyone that asks to hop on if they want to mine some BTC.
December 11, 2017, 04:05:48 PM
Kiefff, it looks like you have a lot of different mining addresses on the same node. Most of the work that p2pool needs to do is per worker address, not per worker. If you have 1000 miners all sharing the same worker address, that's less work for p2pool than 10 miners each with a different address. If you can change the miners to all use the same worker address, you should be able to handle the load just fine. That might not be an option, though.
I also notice that you seem to have enabled incoming p2p connections (e.g. by forwarding a port on your router) a few days ago, and you're now getting about 2x as many connections. Each connection increases the CPU load on your node, so if you have a slow CPU, you may be better off limiting your node to e.g. 5 connections total.
Pypy will probably also help as long as you have enough RAM. It looks like you're currently using about 1.8 GB of RAM on CPython, so that might increase to 4 GB if you switch to Pypy.
My p2pool modifications would probably help too, but I haven't tried running them on Litecoin yet, so I don't know if they would work.
I also notice that you seem to have enabled incoming p2p connections (e.g. by forwarding a port on your router) a few days ago, and you're now getting about 2x as many connections. Each connection increases the CPU load on your node, so if you have a slow CPU, you may be better off limiting your node to e.g. 5 connections total.
Pypy will probably also help as long as you have enough RAM. It looks like you're currently using about 1.8 GB of RAM on CPython, so that might increase to 4 GB if you switch to Pypy.
My p2pool modifications would probably help too, but I haven't tried running them on Litecoin yet, so I don't know if they would work.
December 11, 2017, 03:32:57 PM
December 11, 2017, 01:42:20 PM
Hey all, been running a p2pool LTC node and its been going great until I get 10GH + of miners on my node.
Kiefff, can you describe in more detail what the issue is when it hits 10 GH/s? What goes wrong? Does your CPU get pegged at 100% on one core? Does the web UI become less responsive? Does it spit out error messages? Does your efficiency drop and your orphan rate increase? Does your machine halt and catch fire? It would be useful to have some more information on what the problem actually is.Hi, thanks for the response and sorry for lack of detail when asking for troubleshooting help. I know it can be super annoying. It seems everyone on the node, now that it is past 10GH local, now has high rejection rates(even my locally connected miners) and I also notice a increase in local stale shares. So it seems when A CPU core spikes to 100%, local dead on arrival spikes to around 15-16% and then goes back down after things seem to calm down on the CPU core. Local stale share % then starts to drop until the process starts all over again. Web UI seems to be just as responsive during these times, from what I can tell. No fire yet =] Thanks again for the reply.
it seems when this comes up, the CPU core spikes and my problem above happens
Code:
2017-12-11 12:23:58.579394 Peer sent entire transaction ffe7dff1b877c24f5dab32947698137d7e35fec51ab8accc0cbc59c947d5d230 that was already received
2017-12-11 12:23:58.591211 Peer sent entire transaction 8560094e76b112e54302624cbfe9aa0f666edd19d8526fa7da46fd7c2c460749 that was already received
2017-12-11 12:23:58.596509 Peer sent entire transaction ffe7dff1b877c24f5dab32947698137d7e35fec51ab8accc0cbc59c947d5d230 that was already received
2017-12-11 12:23:58.601995 Peer sent entire transaction ffe7dff1b877c24f5dab32947698137d7e35fec51ab8accc0cbc59c947d5d230 that was already received
2017-12-11 12:23:58.820905 Peer sent entire transaction 8560094e76b112e54302624cbfe9aa0f666edd19d8526fa7da46fd7c2c460749 that was already received
2017-12-11 12:23:58.844515 Peer sent entire transaction 8560094e76b112e54302624cbfe9aa0f666edd19d8526fa7da46fd7c2c460749 that was already received
2017-12-11 12:23:59.009682 Peer sent entire transaction 8560094e76b112e54302624cbfe9aa0f666edd19d8526fa7da46fd7c2c460749 that was already received
2017-12-11 12:23:59.031231 Peer sent entire transaction 8560094e76b112e54302624cbfe9aa0f666edd19d8526fa7da46fd7c2c460749 that was already received
December 11, 2017, 12:51:36 PM
Hey all, been running a p2pool LTC node and its been going great until I get 10GH + of miners on my node.
Kiefff, can you describe in more detail what the issue is when it hits 10 GH/s? What goes wrong? Does your CPU get pegged at 100% on one core? Does the web UI become less responsive? Does it spit out error messages? Does your efficiency drop and your orphan rate increase? Does your machine halt and catch fire? It would be useful to have some more information on what the problem actually is. December 11, 2017, 12:41:58 PM
Cryptonomist, your node is handing out a difficulty of around 300k to your miners. The expected number of hashes needed to find a 300k diff pseudoshare is 300000*2**48/0xffff = 1.28 PH. With a hashrate of 80 GH/s, it's expected that would take about 4.47 hours per pseudoshare. Since p2pool needs to switch jobs every 30 seconds or so, that means that 99.82% of the time, p2pool would switch jobs before your miner found a (pseudo)share.
I suggest you manually set a lower pseudoshare difficulty (e.g. 256, for about 14 sec per) by putting address+256 as your stratum username. This will only affect your stats, not your revenue. You can also put address+256/32768 to set your share difficulty target to either 32768 or the network's minimum share difficulty (whichever is higher) if you want to have a better chance of mining an actual share.
Ideally, I would tweak my p2pool code so that it would adjust pseudoshare difficulty more quickly and intelligently to miners with different hashrates. However, that's pretty low on my priority list right now, since it does not affect revenue or resource requirements at all.
I suggest you manually set a lower pseudoshare difficulty (e.g. 256, for about 14 sec per) by putting address+256 as your stratum username. This will only affect your stats, not your revenue. You can also put address+256/32768 to set your share difficulty target to either 32768 or the network's minimum share difficulty (whichever is higher) if you want to have a better chance of mining an actual share.
Ideally, I would tweak my p2pool code so that it would adjust pseudoshare difficulty more quickly and intelligently to miners with different hashrates. However, that's pretty low on my priority list right now, since it does not affect revenue or resource requirements at all.
December 11, 2017, 12:23:07 PM
Hey all, been running a p2pool LTC node and its been going great until I get 10GH + of miners on my node. Ive ran it on my 12 core xeon(only 2.6gh clock). Then after reading that p2pool does better on single core high clock I ran the node on my i5 OC'd. Still the same issue. Now I'm trying my i7 3770 with the same issues. My pipeline is a biz connection, 100/20 to my home. Would running it with pypy work? I seen Jtoom mention it, but not sure if its just for his 1mb_segwit fork? Sorry, been trying to read ALL the pages in here before I come and ask. I'm all about p2pool, great work.
December 11, 2017, 09:20:47 AM
Cryptonomist, your CPU is faster than bitlock1's, and is probably fast enough to run jtoomimnet p2pool with pypy and with an acceptable (but not excellent) DOA+orphan rate, though of course faster would be better.
Edit: based on PMs, it looks like Cryptonomist's setup is working okay. jtoomimnet will often choose higher pseudoshare difficulty, especially on startup, and Cryptonomist is using USB miners with a very low hashrate (~80 GH/s), so he's only finding one stratum share (p2pool pseudoshare) every 15 minutes or so. But it's working.
Edit: based on PMs, it looks like Cryptonomist's setup is working okay. jtoomimnet will often choose higher pseudoshare difficulty, especially on startup, and Cryptonomist is using USB miners with a very low hashrate (~80 GH/s), so he's only finding one stratum share (p2pool pseudoshare) every 15 minutes or so. But it's working.
Hello,
So i'm no mining again on my own p2pool node using jtoomim's fork. However, there are still some things that aren't very clear to me. I've been running my miners and node now for a couple of hours, however, the p2pool output is still the following:
Code:
2017-12-11 13:57:56.476565 Peer sent entire transaction c714882643dfb355152cffe5ec79754a64c73610fb9c41edaccc8e4ca641c6b7 that was already received
2017-12-11 13:57:58.721058 Peer sent entire transaction c714882643dfb355152cffe5ec79754a64c73610fb9c41edaccc8e4ca641c6b7 that was already received
2017-12-11 13:57:59.927420 Peer sent entire transaction c714882643dfb355152cffe5ec79754a64c73610fb9c41edaccc8e4ca641c6b7 that was already received
2017-12-11 13:58:04.081785 Peer sent entire transaction 5fc8f4ccf5ccd68c4a0ca57a30fbca580061a75873b0bed4cbc9e8a441e5e64a that was already received
2017-12-11 13:58:05.791001 Peer sent entire transaction 5fc8f4ccf5ccd68c4a0ca57a30fbca580061a75873b0bed4cbc9e8a441e5e64a that was already received
2017-12-11 13:58:06.049836 Peer sent entire transaction 5fc8f4ccf5ccd68c4a0ca57a30fbca580061a75873b0bed4cbc9e8a441e5e64a that was already received
2017-12-11 13:58:06.285570 Peer sent entire transaction 5fc8f4ccf5ccd68c4a0ca57a30fbca580061a75873b0bed4cbc9e8a441e5e64a that was already received
2017-12-11 13:58:06.726747 Peer sent entire transaction 5fc8f4ccf5ccd68c4a0ca57a30fbca580061a75873b0bed4cbc9e8a441e5e64a that was already received
2017-12-11 13:58:12.124851 Peer sent entire transaction 5fc8f4ccf5ccd68c4a0ca57a30fbca580061a75873b0bed4cbc9e8a441e5e64a that was already received
2017-12-11 13:58:14.679518 Peer sent entire transaction 5fc8f4ccf5ccd68c4a0ca57a30fbca580061a75873b0bed4cbc9e8a441e5e64a that was already received
2017-12-11 13:58:14.902474 P2Pool: 17628 shares in chain (16240 verified/17632 total) Peers: 10 (4 incoming)
2017-12-11 13:58:14.902849 Local: 0H/s in last 0.0 seconds Local dead on arrival: ??? Expected time to share: ???
2017-12-11 13:58:14.903110 Shares: 0 (0 orphan, 0 dead) Stale rate: ??? Efficiency: ??? Current payout: (0.0000)=0.0000 BTC
2017-12-11 13:58:14.903413 Pool: 7173TH/s Stale rate: 3.2% Expected time to block: 11.0 days
2017-12-11 13:58:15.408087 Peer sent entire transaction 5fc8f4ccf5ccd68c4a0ca57a30fbca580061a75873b0bed4cbc9e8a441e5e64a that was already received
2017-12-11 13:58:18.516933 Peer sent entire transaction bea3223c82a3c08b75c9d51b7ce7a3bb1931d3dec355903a0d214ad50e569393 that was already received
2017-12-11 13:58:19.591504 Peer sent entire transaction 521b0e85fece2a4af6b84f9cd7a9a57b310a9a1b3a0349f74308f07ed33bf196 that was already received
2017-12-11 13:58:21.115704 Peer sent entire transaction 7f7e0343783c01bd435e6c2291d2c3ff662e7f2f011c20e63cda9753b5ef5e91 that was already received
2017-12-11 13:58:21.277624 Peer sent entire transaction 7f7e0343783c01bd435e6c2291d2c3ff662e7f2f011c20e63cda9753b5ef5e91 that was already received
2017-12-11 13:58:21.414326 Peer sent entire transaction 7f7e0343783c01bd435e6c2291d2c3ff662e7f2f011c20e63cda9753b5ef5e91 that was already received
2017-12-11 13:58:22.602042 Peer sent entire transaction 7f7e0343783c01bd435e6c2291d2c3ff662e7f2f011c20e63cda9753b5ef5e91 that was already received
2017-12-11 13:58:29.465659 Peer sent entire transaction eefc6be2c096c3f0a4b5a2f40b3db71dee318b094db1c4669560495b1f60a742 that was already received
2017-12-11 13:58:30.497847 Peer sent entire transaction 7f7e0343783c01bd435e6c2291d2c3ff662e7f2f011c20e63cda9753b5ef5e91 that was already received
2017-12-11 13:58:30.743429 Peer sent entire transaction eefc6be2c096c3f0a4b5a2f40b3db71dee318b094db1c4669560495b1f60a742 that was already received
2017-12-11 13:58:35.010332 Peer sent entire transaction eefc6be2c096c3f0a4b5a2f40b3db71dee318b094db1c4669560495b1f60a742 that was already received
2017-12-11 13:58:36.765627 Peer sent entire transaction eefc6be2c096c3f0a4b5a2f40b3db71dee318b094db1c4669560495b1f60a742 that was already received
2017-12-11 13:58:36.815290 Peer sent entire transaction eefc6be2c096c3f0a4b5a2f40b3db71dee318b094db1c4669560495b1f60a742 that was already received
2017-12-11 13:58:38.326642 Peer sent entire transaction eefc6be2c096c3f0a4b5a2f40b3db71dee318b094db1c4669560495b1f60a742 that was already received
2017-12-11 13:58:39.066717 Peer sent entire transaction eefc6be2c096c3f0a4b5a2f40b3db71dee318b094db1c4669560495b1f60a742 that was already received
2017-12-11 13:58:43.359680 Generating a share with 1009297 bytes (289609 new) and 572 transactions (281 new)
2017-12-11 13:58:43.454053 Warning: Previous share's timestamp is 205 seconds old.
2017-12-11 13:58:43.454353 Make sure your system clock is accurate, and ensure that you're connected to decent peers.
2017-12-11 13:58:43.454537 If your clock is more than 300 seconds behind, it can result in orphaned shares.
2017-12-11 13:58:43.454685 (It's also possible that this share is just taking a long time to mine.)
2017-12-11 13:58:43.510764 New work for xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx Diff: 346418.14 Share diff: 49058729.28 Block value: 13.78 BTC (572 tx, 1009 kB)
2017-12-11 13:58:43.999881 Generating a share with 1009297 bytes (289609 new) and 572 transactions (281 new)
2017-12-11 13:58:44.095464 Warning: Previous share's timestamp is 206 seconds old.
2017-12-11 13:58:44.095825 Make sure your system clock is accurate, and ensure that you're connected to decent peers.
2017-12-11 13:58:44.095977 If your clock is more than 300 seconds behind, it can result in orphaned shares.
2017-12-11 13:58:44.096125 (It's also possible that this share is just taking a long time to mine.)
2017-12-11 13:58:44.226306 Peer sent entire transaction c1200722f49b5865e71c72509ba7378a720b04597208b3ea84dcc2d2736ed1d0 that was already received
2017-12-11 13:58:44.325999 Peer sent entire transaction 896452b94905c8bab594c088a3ae17f99a286f3e0d4514c31ab8ae52e84cfe23 that was already received
2017-12-11 13:58:44.494081 Peer sent entire transaction 688583e03e9043bbd6566c9ef5da8f0550d8a8b960f0b9239a94e4fc99887c5e that was already received
2017-12-11 13:58:44.671330 Peer sent entire transaction 896452b94905c8bab594c088a3ae17f99a286f3e0d4514c31ab8ae52e84cfe23 that was already received
2017-12-11 13:58:44.911456 Peer sent entire transaction 688583e03e9043bbd6566c9ef5da8f0550d8a8b960f0b9239a94e4fc99887c5e that was already received
2017-12-11 13:58:45.033646 P2Pool: 17628 shares in chain (16240 verified/17632 total) Peers: 10 (4 incoming)
2017-12-11 13:58:45.033913 Local: 0H/s in last 0.0 seconds Local dead on arrival: ??? Expected time to share: ???
2017-12-11 13:58:45.034058 Shares: 0 (0 orphan, 0 dead) Stale rate: ??? Efficiency: ??? Current payout: (0.0000)=0.0000 BTC
2017-12-11 13:58:45.034204 Pool: 7173TH/s Stale rate: 3.2% Expected time to block: 11.0 days
2017-12-11 13:58:45.092149 Peer sent entire transaction 688583e03e9043bbd6566c9ef5da8f0550d8a8b960f0b9239a94e4fc99887c5e that was already received
2017-12-11 13:58:53.621809 Peer sent entire transaction 688583e03e9043bbd6566c9ef5da8f0550d8a8b960f0b9239a94e4fc99887c5e that was already received
2017-12-11 13:58:53.957365 Peer sent entire transaction 688583e03e9043bbd6566c9ef5da8f0550d8a8b960f0b9239a94e4fc99887c5e that was already received
2017-12-11 13:58:57.317096 Peer sent entire transaction a94cf7b5a6d446b901783e8168141bd5699b18b099d6315621441251b7c4659b that was already received
2017-12-11 13:58:57.330907 Peer sent entire transaction 97d75c8a745d8b8593d328e3f4150a243f75cf3531c7f4c67fef447841500d87 that was already received
2017-12-11 13:58:57.527107 Peer sent entire transaction 97d75c8a745d8b8593d328e3f4150a243f75cf3531c7f4c67fef447841500d87 that was already received
2017-12-11 13:58:57.970848 Peer sent entire transaction 97d75c8a745d8b8593d328e3f4150a243f75cf3531c7f4c67fef447841500d87 that was already received
2017-12-11 13:58:58.373802 Peer sent entire transaction 97d75c8a745d8b8593d328e3f4150a243f75cf3531c7f4c67fef447841500d87 that was already received
2017-12-11 13:58:58.617500 Peer sent entire transaction 97d75c8a745d8b8593d328e3f4150a243f75cf3531c7f4c67fef447841500d87 that was already received
So as you can see, although my miners are pointed to my node at 127.0.0.1:9332, the local rate is still 0H/s. My miners are very slow, but still I think that their hash rate should be visible. Or am I missing something?
Also, it is strange that my cgminer now again gives 0 accepted and 5815374 rejected. This is something I find strange.
The output of cgminer is:
Code:
cgminer version 4.10.0 - Started: [2017-12-11 11:12:05.150]
--------------------------------------------------------------------------------
(5s):105.8G (1m):96.54G (5m):93.58G (15m):90.14G (avg):95.91Gh/s
A:0 R:5815374 HW:263 WU:1334.1/m
Connected to 127.0.0.1 diff 329K with stratum as user xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Block: 8ee4d35a... Diff:1.59T Started: [14:10:53.954] Best share: 226K
--------------------------------------------------------------------------------
[U]SB management [P]ool management [S]ettings [D]isplay options [Q]uit
0: BSC 10000197: COMPAC-1 150.00MHz HW:0 | 7.307G / 8.277Gh/s WU:115.7/m
1: BSD 10013137: COMPAC-2 200.00MHz HW:262 | 21.02G / 21.96Gh/s WU:301.0/m
2: BSD 10013099: COMPAC-2 200.00MHz HW:1 | 34.09G / 21.93Gh/s WU:306.4/m
3: BSD 10013031: COMPAC-2 200.00MHz HW:0 | 28.43G / 21.79Gh/s WU:304.4/m
4: BSD 10013138: COMPAC-2 200.00MHz HW:0 | 21.81G / 21.95Gh/s WU:306.7/m
Code:
[2017-12-11 13:52:13.774] Stratum from pool 0 requested work restart
[2017-12-11 13:52:27.996] Stratum from pool 0 requested work restart
[2017-12-11 13:52:40.520] Pool 0 difficulty changed to 342703.6
[2017-12-11 13:52:40.521] Stratum from pool 0 requested work restart
[2017-12-11 13:53:40.111] Pool 0 difficulty changed to 338314.9
[2017-12-11 13:53:40.111] Stratum from pool 0 requested work restart
[2017-12-11 13:53:42.105] Stratum from pool 0 requested work restart
[2017-12-11 13:54:00.967] Pool 0 difficulty changed to 337301.9
[2017-12-11 13:54:00.967] Stratum from pool 0 requested work restart
[2017-12-11 13:54:22.709] Pool 0 difficulty changed to 335591.2
[2017-12-11 13:54:22.710] Stratum from pool 0 requested work restart
[2017-12-11 13:54:23.999] Stratum from pool 0 requested work restart
[2017-12-11 13:54:53.832] Pool 0 difficulty changed to 333706.6
[2017-12-11 13:54:53.832] Stratum from pool 0 requested work restart
[2017-12-11 13:55:18.669] Pool 0 difficulty changed to 332825.1
[2017-12-11 13:55:18.669] Stratum from pool 0 requested work restart
[2017-12-11 13:55:41.308] Pool 0 difficulty changed to 329907.0
[2017-12-11 13:55:41.308] Stratum from pool 0 requested work restart
[2017-12-11 13:57:11.395] Stratum connection to pool 0 interrupted
[2017-12-11 13:57:12.424] Pool 0 difficulty changed to 322413.0
[2017-12-11 13:57:12.428] Stratum from pool 0 requested work restart
[2017-12-11 13:57:13.008] Pool 0 difficulty changed to 329907.0
[2017-12-11 13:57:13.008] Stratum from pool 0 requested work restart
[2017-12-11 13:57:13.008] Rejected untracked stratum share from pool 0
[2017-12-11 13:58:43.051] Stratum connection to pool 0 interrupted
[2017-12-11 13:58:44.164] Pool 0 difficulty changed to 346418.1
[2017-12-11 13:58:44.169] Stratum from pool 0 detected new block at height 498741
[2017-12-11 13:58:44.256] Stratum from pool 0 requested work restart
[2017-12-11 13:58:44.262] Rejected untracked stratum share from pool 0
[2017-12-11 13:59:04.957] Pool 0 difficulty changed to 345313.8
[2017-12-11 13:59:04.957] Stratum from pool 0 requested work restart
[2017-12-11 13:59:49.833] Pool 0 difficulty changed to 349850.7
[2017-12-11 13:59:49.833] Stratum from pool 0 detected new block at height 498742
[2017-12-11 14:00:26.001] Pool 0 difficulty changed to 344780.4
[2017-12-11 14:00:26.002] Stratum from pool 0 requested work restart
[2017-12-11 14:00:27.293] Stratum from pool 0 requested work restart
[2017-12-11 14:00:44.426] Pool 0 difficulty changed to 342663.0
[2017-12-11 14:00:44.427] Stratum from pool 0 requested work restart
[2017-12-11 14:00:53.575] Pool 0 difficulty changed to 341213.7
[2017-12-11 14:00:53.575] Stratum from pool 0 requested work restart
[2017-12-11 14:00:55.052] Stratum from pool 0 requested work restart
[2017-12-11 14:02:04.548] Pool 0 difficulty changed to 333298.2
[2017-12-11 14:02:04.548] Stratum from pool 0 requested work restart
[2017-12-11 14:02:26.943] Pool 0 difficulty changed to 330923.5
[2017-12-11 14:02:26.943] Stratum from pool 0 requested work restart
So it detects the new blocks. But the work is always restarted, and the difficulty adjusted. Under normal operation I should see a lot of accepted, which is here not the case. I understand that the difficulty is higher on the jtoomim fork, but even then I should have seen some accepted in the last couple of hours.
We know (jtoomim confirmed this) that my miners work, so it must be that something is wrong with my p2pool node or with the connection between my miners and my p2pool node. However, the output of p2pool doesn't seem abnormal. It looks like a normal operating p2pool node, except for the timestamp error (this error was only temporary). Also, cgminer doesn't give any error messages. It's just that I don't know what is going wrong, since that I use exactly the same setup like the one i was using for mining on the main p2pool. So does anyone have a suggestion of what I can try next? Or is this purely because my miners are to slow?
Thank you in advance.
December 10, 2017, 11:27:34 PM
I have a test node up mining Bitcoin Cash
code plz December 10, 2017, 02:54:30 PM
https://en.bitcoin.it/wiki/P2Pool#Stales
Could anybody be so kind to explain in more details, what does this mean?
What's PPLNS got to do with it?
Could anybody be so kind to explain in more details, what does this mean?
Quote
On P2Pool stales refer to shares which can't make it into the sharechain. Because the sharechain is 20 times faster than the Bitcoin chain many stales are common and expected. However, because the payout is PPLNS only your stale rate relative to other nodes is relevant; the absolute rate is not.
What's PPLNS got to do with it?
Hello Rabinovitch,
The reason is in my opinion the following.
PPLNS is pay per last n shares. So lets assume that the last 200 shares result in a payment to the nodes that mined the shares. Lets assume that A, B, C and D mine and lets also assume they have the same hash rate. Further we assume that their stale rate is 0 (so each miner has a stale rate of 0). In this case each miner has 50 shares (this is not necessarily true in reality because mining is a random process) in the share chain. Lets also assume for simplicity that every share leads to an equal payment. In that case each miner gets a payment when a block is found that is equal to 1/4th of the block reward.
Now lets assume that A, B, C and D mine, but they all have a stale rate of 10%. This means that 10% of the shares of the network are lost. This means that to generate a chain of 200 shares, the network takes 10% more time than in the previous situation. Since they all have a 10% stale rate, they all wast an equal amount of work, so in the end the share chain of 200 shares will again contain 50 shares of each node. This means also that they have right on 1/4th of the block reward.
Now lets assume again that A, B, C and D mine, and they again all have the same hash power. But now A, B, C have a stale rate of 0, and D has a 50% stale rate. Now there is a difference in the amount of shares each node will have in the share chain of 200 shares length. A, B, and C will have 57.14 shares in the share chain, and D will only have 28.57 shares in the share chain. This means that D will get much less reward than A, B and C if a block is found. The share for D decreases, but the share of A, B and C increases.
So the relevance of PPLNS is that it pays a reward to a miner according to the number of shares it has in the share chain. The relative stale rate has an impact on the distribution of the reward, because it determines how many shares each miner will have in the share chain.
Of course the examples here are simplifications of the real algorithm. PPLNS comes in many different forms. You can find a more detailed explanation of PPLNS at https://bitcointalksearch.org/topic/pplns-39832.
I hope this is an answer to your question.
December 10, 2017, 10:59:05 AM
Upgrade instructions to pass in Python v3.4 (in French) : https://bitcointalksearch.org/topic/m.26086837
Initial Tutorial (in French) for the initial Python v2.7 : https://bitcointalksearch.org/topic/comment-miner-des-bitcoins-soi-meme-avec-un-serveur-p2pool-1114415
Take time to understand the pip & wheel install & upgrade ... science (i'm not a linux user).
Initial Tutorial (in French) for the initial Python v2.7 : https://bitcointalksearch.org/topic/comment-miner-des-bitcoins-soi-meme-avec-un-serveur-p2pool-1114415
Take time to understand the pip & wheel install & upgrade ... science (i'm not a linux user).
December 10, 2017, 07:56:31 AM
The closest node from me shows a very high latency, so I would like to set up a private noed for my 9 Antminer L3+s. I read here that the requirement is not that huge for Litecoin. Problem is that my internet speed is pretty low and I cannot improve it from 5mbit/1mbit(upload), is that a problem?
I got a Intel NUC NUC6CAYS Intel Celeron J3455 1.5 GHz, 2GB RAM, Windows 10. Can this run a node?
I got a Intel NUC NUC6CAYS Intel Celeron J3455 1.5 GHz, 2GB RAM, Windows 10. Can this run a node?
December 10, 2017, 06:56:12 AM
I have a test node up mining Bitcoin Cash (using Bitcoin ABC) at http://woff.toom.im:9338/. I don't know if it can successfully mine blocks yet though.
Give me the source code, please, I will connect 2-3 nodes.I have many miners who require a BCH node
December 09, 2017, 11:55:48 PM
I have a test node up mining Bitcoin Cash (using Bitcoin ABC) at http://woff.toom.im:9338/. I don't know if it can successfully mine blocks yet though.
December 09, 2017, 06:54:20 PM
Are you still suggesting to run your 1mb_segwit branch?
Yes. http://github.com/jtoomim/p2pool master is currently just an old snapshot of http://github.com/p2pool/p2pool master. All of my new code is in 1mb_segwit. It looks like that's what you're running now, otherwise you wouldn't be getting the --bench output.bitlock1, it looks like your node is sorta working now, but not very well. Your mining efficiency is only 73%. This is probably because of the slow CPU. When you're running p2pool with a slow CPU, it can take several seconds for your machine to download a new share from a peer, deserialize it, build a new share template, and send that share template to miners. In your case, it took 4.2 seconds to do the deserialization step, and up to 1.3 seconds to build a new share template. This means that your miners are hashing on an old share for at least 5.5 seconds out of every 30 seconds on average. That alone will reduce your expected revenue by about 18.3%. (There are also a few processing steps that aren't accounted for in my --bench output, which may be why you're seeing 27% in practice rather than 18.3%.)
However I experience some problems. Well actually I haven't been able to mine at all with jtoomim's fork. Somehow my miners don't mine.
Can you try mining on a different node on jtoomimnet to test to see if the problem is with your node or with your miners? You can use ml.toom.im:9332. If your node has publicly open ports, it might also be helpful if you PM me your IP address so I can take a look.Cryptonomist, your CPU is faster than bitlock1's, and is probably fast enough to run jtoomimnet p2pool with pypy and with an acceptable (but not excellent) DOA+orphan rate, though of course faster would be better.
Edit: based on PMs, it looks like Cryptonomist's setup is working okay. jtoomimnet will often choose higher pseudoshare difficulty, especially on startup, and Cryptonomist is using USB miners with a very low hashrate (~80 GH/s), so he's only finding one stratum share (p2pool pseudoshare) every 15 minutes or so. But it's working.
December 09, 2017, 09:11:57 AM
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.html
The 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
thanks jtoomim
Moderator note: frodocooper edited this post to include code tags.
http://97.77.64.18:9332/static/index.html
The 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
Code:
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.
December 09, 2017, 08:07:09 AM
Hello,
I've recently switched from the main p2pool to jtoomim's fork, due to issues with cpu load. P2Pool works, and I can mine, but over time my node start creating huge amounts of orphans. An analysis of the problem showed that the issue was the cpu load. It's nearly always at 100%. I also saw the same messages that other people on this forum had, namely that the connection with bitcoind was lost. It is indeed so that this starts to happen when the cpu utilization is at 100% for a very long time. I must say that this became only quite recently an issue for me. I've been using p2pool for over a year now, but it is only the last couple of weeks that the cpu utilization became an issue. At first I used just python to run p2pool, and this was sufficient. Recently I switched to pypy as an attempt to alleviated the problem with the cpu load. This diminished the cpu load slightly, however not sufficiently, and my node still gets a lot of orphan shares (the stale rate is enormous: between 30 and 50%). So at that point I decided to switch to jtoomim's fork because of the optimalizations.
However I experience some problems. Well actually I haven't been able to mine at all with jtoomim's fork. Somehow my miners don't mine. I know the miners work and so does the setup because I can mine 'perfectly' on the main P2pool. But when using jtoomim's fork all the work of my miners get rejected. I also see the lights flashing on the usb miners, so they are active.
Cgminer gives me the following:
That is all I get. Also accepted = 0 and rejected = a lot.
If I analyze the output of p2pool, I see the following:
It keeps on doing that. I see that new work is send to the miners. Also the rest of the output makes me believe that the P2Pool node is running as it should.
The cgminer command I use to run cgminer and connect to p2pool is the following:
screen -d -m -S cgminer ~/git/vthoang/cgminer/cgminer -o stratum+tcp://127.0.0.1:9332 -u xxxxxxxxxxxxxxxxxxxxxxxxxxxx -p xxxxxxxxxxxxx --suggest-diff 32 --gekko-compac-freq 150 --gekko-2pac-freq 200
Can someone explain to me what i'm doing wrong?
Thank you
Extra info:
My setup is the following:
* Processor: i3 M350 @2.77Ghz (so it is not a powerful processor)
* RAM: 8GB
* OS: ubuntu server 16.04 LTS
* mining software: cgminer 4.10
* miners: a couple of gekkoscience compac and gekkoscience 2Pac
I've recently switched from the main p2pool to jtoomim's fork, due to issues with cpu load. P2Pool works, and I can mine, but over time my node start creating huge amounts of orphans. An analysis of the problem showed that the issue was the cpu load. It's nearly always at 100%. I also saw the same messages that other people on this forum had, namely that the connection with bitcoind was lost. It is indeed so that this starts to happen when the cpu utilization is at 100% for a very long time. I must say that this became only quite recently an issue for me. I've been using p2pool for over a year now, but it is only the last couple of weeks that the cpu utilization became an issue. At first I used just python to run p2pool, and this was sufficient. Recently I switched to pypy as an attempt to alleviated the problem with the cpu load. This diminished the cpu load slightly, however not sufficiently, and my node still gets a lot of orphan shares (the stale rate is enormous: between 30 and 50%). So at that point I decided to switch to jtoomim's fork because of the optimalizations.
However I experience some problems. Well actually I haven't been able to mine at all with jtoomim's fork. Somehow my miners don't mine. I know the miners work and so does the setup because I can mine 'perfectly' on the main P2pool. But when using jtoomim's fork all the work of my miners get rejected. I also see the lights flashing on the usb miners, so they are active.
Cgminer gives me the following:
Code:
[2017-12-09 12:37:24.975] Pool 0 difficulty changed to 318767.1
[2017-12-09 12:37:24.976] Stratum from pool 0 requested work restart
[2017-12-09 12:38:00.753] Pool 0 difficulty changed to 316516.4
[2017-12-09 12:38:00.753] Stratum from pool 0 requested work restart
[2017-12-09 12:38:53.471] Pool 0 difficulty changed to 311201.8
[2017-12-09 12:38:53.471] Stratum from pool 0 requested work restart
[2017-12-09 12:39:21.296] Pool 0 difficulty changed to 308553.9
[2017-12-09 12:39:21.297] Stratum from pool 0 requested work restart
[2017-12-09 12:39:44.927] Pool 0 difficulty changed to 305991.7
[2017-12-09 12:39:44.927] Stratum from pool 0 requested work restart
[2017-12-09 12:39:46.181] Stratum from pool 0 requested work restart
[2017-12-09 12:40:08.425] Pool 0 difficulty changed to 304497.7
[2017-12-09 12:40:08.426] Stratum from pool 0 requested work restart
[2017-12-09 12:40:08.426] Stratum from pool 0 requested work restart
[2017-12-09 12:40:10.956] Stratum from pool 0 requested work restart
[2017-12-09 12:40:13.911] Stratum from pool 0 requested work restart
[2017-12-09 12:40:28.796] Pool 0 difficulty changed to 303616.9
[2017-12-09 12:40:28.796] Stratum from pool 0 detected new block at height 498385
[2017-12-09 12:40:41.587] Pool 0 difficulty changed to 301658.7
[2017-12-09 12:40:41.587] Stratum from pool 0 requested work restart
[2017-12-09 12:40:49.738] Pool 0 difficulty changed to 301019.8
[2017-12-09 12:40:49.738] Stratum from pool 0 requested work restart
[2017-12-09 12:40:52.193] Pool 0 difficulty changed to 331502.0
[2017-12-09 12:40:52.193] Stratum from pool 0 requested work restart
[2017-12-09 12:41:01.276] Stratum from pool 0 requested work restart
[2017-12-09 12:41:05.722] Stratum from pool 0 detected new block at height 498386
[2017-12-09 12:41:07.698] Pool 0 difficulty changed to 344825.9
[2017-12-09 12:41:07.698] Stratum from pool 0 requested work restart
[2017-12-09 12:41:39.337] Pool 0 difficulty changed to 343068.6
[2017-12-09 12:41:39.337] Stratum from pool 0 requested work restart
[2017-12-09 12:42:02.765] Pool 0 difficulty changed to 338019.6
[2017-12-09 12:42:02.765] Stratum from pool 0 requested work restart
[2017-12-09 12:42:02.765] Stratum from pool 0 requested work restart
[2017-12-09 12:42:20.844] Pool 0 difficulty changed to 336936.5
[2017-12-09 12:42:20.845] Stratum from pool 0 requested work restart
[2017-12-09 12:42:53.143] Pool 0 difficulty changed to 335038.0
[2017-12-09 12:42:53.144] Stratum from pool 0 requested work restart
[2017-12-09 12:43:07.531] Pool 0 difficulty changed to 334145.2
[2017-12-09 12:43:07.531] Stratum from pool 0 requested work restart
[2017-12-09 12:43:11.495] Stratum from pool 0 requested work restart
[2017-12-09 12:43:27.773] Pool 0 difficulty changed to 331792.9
[2017-12-09 12:43:27.773] Stratum from pool 0 requested work restart
[2017-12-09 12:43:46.130] Pool 0 difficulty changed to 330480.7
[2017-12-09 12:43:46.130] Stratum from pool 0 requested work restart
[2017-12-09 12:44:45.373] Pool 0 difficulty changed to 322995.3
[2017-12-09 12:44:45.373] Stratum from pool 0 requested work restart
[2017-12-09 12:44:48.620] Stratum from pool 0 detected new block at height 498387
That is all I get. Also accepted = 0 and rejected = a lot.
If I analyze the output of p2pool, I see the following:
Code:
2017-12-09 12:46:42.790786 Pool: 5909TH/s Stale rate: 4.8% Expected time to block: 13.4 days
2017-12-09 12:46:44.605121 Peer sent entire transaction 7f7e027bf783f74f0004f84945fa0ad4e811dea0f77653ed26646facef7ab012 that was already received
2017-12-09 12:46:50.004147 Peer sent entire transaction b1dbf883f527584830abcd8cc2ed37db0bfc7f0e9cd0a6ea73558577a1641214 that was already received
2017-12-09 12:46:51.680249 Peer sent entire transaction b1dbf883f527584830abcd8cc2ed37db0bfc7f0e9cd0a6ea73558577a1641214 that was already received
2017-12-09 12:46:54.528876 Peer sent entire transaction e21cbec550ca962e08a9e630d9192e1ff3813ab158b5d9882ed8c0a406128614 that was already received
2017-12-09 12:46:55.393046 Peer sent entire transaction b1dbf883f527584830abcd8cc2ed37db0bfc7f0e9cd0a6ea73558577a1641214 that was already received
2017-12-09 12:47:00.150376 Peer sent entire transaction b1dbf883f527584830abcd8cc2ed37db0bfc7f0e9cd0a6ea73558577a1641214 that was already received
2017-12-09 12:47:00.306119 Peer sent entire transaction 24c5c38682bfe425d1317d6b56d83ef1e3b04f732450f8b7f8131ad90842fa39 that was already received
2017-12-09 12:47:04.560185 Peer sent entire transaction ad2f5f371325641b5f8e5db13c2d62826104414beaef2f26e987c0f9baa36149 that was already received
2017-12-09 12:47:04.951282 Peer sent entire transaction 24c5c38682bfe425d1317d6b56d83ef1e3b04f732450f8b7f8131ad90842fa39 that was already received
2017-12-09 12:47:08.196591 Peer sent entire transaction 24c5c38682bfe425d1317d6b56d83ef1e3b04f732450f8b7f8131ad90842fa39 that was already received
2017-12-09 12:47:10.547186 Peer sent entire transaction 24c5c38682bfe425d1317d6b56d83ef1e3b04f732450f8b7f8131ad90842fa39 that was already received
2017-12-09 12:47:10.624559 Peer sent entire transaction 24c5c38682bfe425d1317d6b56d83ef1e3b04f732450f8b7f8131ad90842fa39 that was already received
2017-12-09 12:47:12.794002 P2Pool: 18894 shares in chain (10338 verified/18895 total) Peers: 7 (1 incoming)
2017-12-09 12:47:12.794440 Local: 0H/s in last 0.0 seconds Local dead on arrival: ??? Expected time to share: ???
2017-12-09 12:47:12.794901 Shares: 0 (0 orphan, 0 dead) Stale rate: ??? Efficiency: ??? Current payout: (0.0000)=0.0000 BTC
2017-12-09 12:47:12.795191 Pool: 5909TH/s Stale rate: 4.8% Expected time to block: 13.4 days
2017-12-09 12:47:14.620279 Peer sent entire transaction 55b649247f4f1c3401dff5ab149f1363821c6c26b39e0e9344b9e6c04b968277 that was already received
2017-12-09 12:47:16.179862 Peer sent entire transaction 55b649247f4f1c3401dff5ab149f1363821c6c26b39e0e9344b9e6c04b968277 that was already received
2017-12-09 12:47:20.354942 Peer sent entire transaction 55b649247f4f1c3401dff5ab149f1363821c6c26b39e0e9344b9e6c04b968277 that was already received
2017-12-09 12:47:21.211953 Peer sent entire transaction 28bd8ec0eeef7fcfc6ef95bbb13d5249eb2d6bcdef964815dd1f13534e36c152 that was already received
2017-12-09 12:47:24.414647 Peer sent entire transaction 55b649247f4f1c3401dff5ab149f1363821c6c26b39e0e9344b9e6c04b968277 that was already received
2017-12-09 12:47:25.638982 Peer sent entire transaction 55b649247f4f1c3401dff5ab149f1363821c6c26b39e0e9344b9e6c04b968277 that was already received
2017-12-09 12:47:25.852640 Peer sent entire transaction 55b649247f4f1c3401dff5ab149f1363821c6c26b39e0e9344b9e6c04b968277 that was already received
2017-12-09 12:47:31.968817 Peer sent entire transaction 91418671d582f9ca897299ecbada2a1b89048e84850fb8b449e36fb0cb64e0f3 that was already received
2017-12-09 12:47:32.112685 Peer sent entire transaction 91418671d582f9ca897299ecbada2a1b89048e84850fb8b449e36fb0cb64e0f3 that was already received
2017-12-09 12:47:35.474336 Peer sent entire transaction 91418671d582f9ca897299ecbada2a1b89048e84850fb8b449e36fb0cb64e0f3 that was already received
2017-12-09 12:47:36.768029 Peer sent entire transaction 4390d4b9df73c20f53e187f88f1d1a90bef6e58a9c4abf9fb0528b2287f56f88 that was already received
2017-12-09 12:47:40.935720 Peer sent entire transaction 958abe7a189bcc7669e8de0eec0895b11bcc21a4a74ad25380d55e7237baec5e that was already received
2017-12-09 12:47:41.006484 Peer sent entire transaction 958abe7a189bcc7669e8de0eec0895b11bcc21a4a74ad25380d55e7237baec5e that was already received
2017-12-09 12:47:41.180621 Peer sent entire transaction 958abe7a189bcc7669e8de0eec0895b11bcc21a4a74ad25380d55e7237baec5e that was already received
2017-12-09 12:47:42.799063 P2Pool: 18894 shares in chain (10338 verified/18895 total) Peers: 7 (1 incoming)
2017-12-09 12:47:42.799495 Local: 0H/s in last 0.0 seconds Local dead on arrival: ??? Expected time to share: ???
2017-12-09 12:47:42.799797 Shares: 0 (0 orphan, 0 dead) Stale rate: ??? Efficiency: ??? Current payout: (0.0000)=0.0000 BTC
2017-12-09 12:47:42.800125 Pool: 5909TH/s Stale rate: 4.8% Expected time to block: 13.4 days
2017-12-09 12:47:46.797353 Peer sent entire transaction 958abe7a189bcc7669e8de0eec0895b11bcc21a4a74ad25380d55e7237baec5e that was already received
2017-12-09 12:47:47.811957 Peer sent entire transaction 8ae74c9c3367fbbcf954e1f3dc085fa4dcca70dc075b016585fbf4d092327271 that was already received
2017-12-09 12:47:50.377209 Peer sent entire transaction 8ae74c9c3367fbbcf954e1f3dc085fa4dcca70dc075b016585fbf4d092327271 that was already received
2017-12-09 12:47:52.139107 Peer sent entire transaction 7906c45bfb1ac2d8cc68c1a112ec00f419f6c6f97d0dbdb9c472b680295f9916 that was already received
2017-12-09 12:47:55.676708 Generating a share with 1030867 bytes (796675 new) and 1749 transactions (1203 new)
2017-12-09 12:47:55.868625 New work for xxxxxxxxxxxxxxxxxxxxxxxxxx Diff: 331431.13 Share diff: 47521705.54 Block value: 14.40 BTC (1749 tx, 1031 kB)
2017-12-09 12:47:56.641314 Peer sent entire transaction ddc0747ebc82a8648afc7e25c820bd5a66cd624bf4dbf37a66ba9f2a1fce7444 that was already received
2017-12-09 12:47:56.650497 Peer sent entire transaction ddc0747ebc82a8648afc7e25c820bd5a66cd624bf4dbf37a66ba9f2a1fce7444 that was already received
2017-12-09 12:47:57.388120 Peer sent entire transaction 8ae74c9c3367fbbcf954e1f3dc085fa4dcca70dc075b016585fbf4d092327271 that was already received
2017-12-09 12:48:03.519249 Peer sent entire transaction 6ef6ca8a2e71117f951852a8054aaade92253bd3bf3edcd5c9540866aeb76875 that was already received
2017-12-09 12:48:03.780748 Peer sent entire transaction 3c23a8842d731c695162989c8aaeaaca8168a7829121c0136a405368d38e9c5b that was already received
2017-12-09 12:48:05.673745 Peer sent entire transaction 3c23a8842d731c695162989c8aaeaaca8168a7829121c0136a405368d38e9c5b that was already received
2017-12-09 12:48:11.758827 Peer sent entire transaction 3c23a8842d731c695162989c8aaeaaca8168a7829121c0136a405368d38e9c5b that was already received
2017-12-09 12:48:11.833870 Peer sent entire transaction 3c23a8842d731c695162989c8aaeaaca8168a7829121c0136a405368d38e9c5b that was already received
2017-12-09 12:48:12.804277 P2Pool: 18895 shares in chain (10339 verified/18896 total) Peers: 7 (1 incoming)
2017-12-09 12:48:12.804664 Local: 0H/s in last 0.0 seconds Local dead on arrival: ??? Expected time to share: ???
2017-12-09 12:48:12.804912 Shares: 0 (0 orphan, 0 dead) Stale rate: ??? Efficiency: ??? Current payout: (0.0000)=0.0000 BTC
2017-12-09 12:48:12.805183 Pool: 6173TH/s Stale rate: 4.8% Expected time to block: 12.8 days
2017-12-09 12:48:13.162434 Peer sent entire transaction 3c23a8842d731c695162989c8aaeaaca8168a7829121c0136a405368d38e9c5b that was already received
2017-12-09 12:48:19.125554 Peer sent entire transaction e396580068983ef8e3ce328047b8beaa0c9b69a51a86c6df687e3b5519b8bafc that was already received
2017-12-09 12:48:19.265750 Peer sent entire transaction e396580068983ef8e3ce328047b8beaa0c9b69a51a86c6df687e3b5519b8bafc that was already received
2017-12-09 12:48:20.927594 Peer sent entire transaction e396580068983ef8e3ce328047b8beaa0c9b69a51a86c6df687e3b5519b8bafc that was already received
It keeps on doing that. I see that new work is send to the miners. Also the rest of the output makes me believe that the P2Pool node is running as it should.
The cgminer command I use to run cgminer and connect to p2pool is the following:
screen -d -m -S cgminer ~/git/vthoang/cgminer/cgminer -o stratum+tcp://127.0.0.1:9332 -u xxxxxxxxxxxxxxxxxxxxxxxxxxxx -p xxxxxxxxxxxxx --suggest-diff 32 --gekko-compac-freq 150 --gekko-2pac-freq 200
Can someone explain to me what i'm doing wrong?
Thank you
Extra info:
My setup is the following:
* Processor: i3 M350 @2.77Ghz (so it is not a powerful processor)
* RAM: 8GB
* OS: ubuntu server 16.04 LTS
* mining software: cgminer 4.10
* miners: a couple of gekkoscience compac and gekkoscience 2Pac
December 09, 2017, 12:25:18 AM
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
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
Jump to: