Bitcoin Forum
November 23, 2017, 03:59:14 AM *
News: Latest stable version of Bitcoin Core: 0.15.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 ... 746 747 748 749 750 751 752 753 754 755 756 757 758 759 760 761 762 763 764 765 766 767 768 769 770 771 772 773 774 775 776 777 778 779 780 781 782 783 784 785 786 787 788 789 790 791 792 793 794 795 [796] 797 798 799 800 »
  Print  
Author Topic: [1500 TH] p2pool: Decentralized, DoS-resistant, Hop-Proof pool  (Read 2527779 times)
Comandante77
Newbie
*
Offline Offline

Activity: 12


View Profile
September 10, 2017, 04:57:53 PM
 #15901

Hi, everybody!

How can I configure p2pool with other coin? Just interesting fo CANN.
1511409554
Hero Member
*
Offline Offline

Posts: 1511409554

View Profile Personal Message (Offline)

Ignore
1511409554
Reply with quote  #2

1511409554
Report to moderator
1511409554
Hero Member
*
Offline Offline

Posts: 1511409554

View Profile Personal Message (Offline)

Ignore
1511409554
Reply with quote  #2

1511409554
Report to moderator
Join ICO Now A blockchain platform for effective freelancing
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1511409554
Hero Member
*
Offline Offline

Posts: 1511409554

View Profile Personal Message (Offline)

Ignore
1511409554
Reply with quote  #2

1511409554
Report to moderator
1511409554
Hero Member
*
Offline Offline

Posts: 1511409554

View Profile Personal Message (Offline)

Ignore
1511409554
Reply with quote  #2

1511409554
Report to moderator
1511409554
Hero Member
*
Offline Offline

Posts: 1511409554

View Profile Personal Message (Offline)

Ignore
1511409554
Reply with quote  #2

1511409554
Report to moderator
sawa
Legendary
*
Offline Offline

Activity: 1074



View Profile
September 10, 2017, 08:27:02 PM
 #15902

Hi, everybody!

How can I configure p2pool with other coin? Just interesting fo CANN.
https://github.com/ilsawa/p2pool-cann

Crosshair
Jr. Member
*
Offline Offline

Activity: 42


View Profile
September 11, 2017, 12:52:25 PM
 #15903

I just finished a beta version of a merge of veqtrus's SegWit code with my 1mb_hardforked+lowmem code. I've also added a couple of things that should improve the likelihood of it working with altcoins. I'm testing with Bitcoin right now. I'll try to have the testing done and the Bitcoin code ready for others to use within a couple of days, and then I'll work on the altcoin stuff and test it with Litecoin.
Comandante77
Newbie
*
Offline Offline

Activity: 12


View Profile
September 11, 2017, 01:05:46 PM
 #15904


Great! Thanks!
giuliano_ojeda
Newbie
*
Offline Offline

Activity: 2


View Profile
September 13, 2017, 08:36:38 PM
 #15905

Hello Everybody, first of all I would like to thank the developers of p2pool for such a wonderful job. We are Raptor Pool and we just launched a p2pool node in Paraguay(South America) raptorpool.com or es.raptorpool.com (In Spanish). We invite everyone in south america to join us. One more thing, We would like to ask whoever is in charge of the node scanner dev if it's possible to add a flag (Paraguayan Flag) for 190.52.135.28 and the location pin in the map? that will help everyone that's nearby to find out about us.

Thanks again and Best regards, 
Comandante77
Newbie
*
Offline Offline

Activity: 12


View Profile
September 14, 2017, 10:36:51 AM
 #15906

Hi, everybody!

How can I configure p2pool with other coin? Just interesting fo CANN.
https://github.com/ilsawa/p2pool-cann

 Hmm, trying to set pool for solo, but it still connect to other nodes.

 Changed in p2pool/networks.py

PERSIST = False
BOOTSTRAP_ADDRS = ''.split(' ')

  but it doesnt work.
jtoomim
Hero Member
*****
Offline Offline

Activity: 742


View Profile WWW
September 17, 2017, 04:28:32 AM
 #15907

I pushed some more code to https://github.com/jtoomim/p2pool/tree/1mb_segwit that adds more CPU and (maybe) RAM performance improvements for p2pool. I think it should improve CPU usage and latency by about 30% or more. These improvements should reduce DOA and orphan rates on the network a bit. It looks like running p2pool on CPython with medium-slow CPUs should now be viable without huge DOA/orphan costs, although I still recommend using pypy whenever possible. The new code makes fewer memory allocations when serializing objects for network transmission, which might reduce total memory consumption, or it might not. We'll see in a few days.

I also added a performance profiling/benchmark mode. If p2pool is too slow for you, I would find it helpful if you ran python run_p2pool.py --bench and then sent me a snippet of the output, especially if you can get the output near when a share is received over the network.

Hosting bitcoin miners for $65 to $80/kW/month on clean, cheap hydro power.
http://Toom.im
Xantus
Jr. Member
*
Offline Offline

Activity: 41


View Profile
September 18, 2017, 04:13:11 AM
 #15908

I pushed some more code to https://github.com/jtoomim/p2pool/tree/1mb_segwit that adds more CPU and (maybe) RAM performance improvements for p2pool. I think it should improve CPU usage and latency by about 30% or more. These improvements should reduce DOA and orphan rates on the network a bit. It looks like running p2pool on CPython with medium-slow CPUs should now be viable without huge DOA/orphan costs, although I still recommend using pypy whenever possible. The new code makes fewer memory allocations when serializing objects for network transmission, which might reduce total memory consumption, or it might not. We'll see in a few days.

I also added a performance profiling/benchmark mode. If p2pool is too slow for you, I would find it helpful if you ran python run_p2pool.py --bench and then sent me a snippet of the output, especially if you can get the output near when a share is received over the network.

okey, thanks. i will take a look these days. would by nice to get it run on Win10 with Pyton 2.7 (pypy does not run here ...)
Cryptonomist
Newbie
*
Offline Offline

Activity: 22


View Profile
September 18, 2017, 11:06:32 AM
 #15909

Hello,

I've got some questions related to P2Pool:

1) On the web interface of my node I find the following in relation to the shares: "Best share", "Verified heads", "Heads", "Verified tails", "Tails". I'm not sure I fully understand what they mean.
      *I suppose "best share" is the last share added to the sharechain (I'm I right about this???).
      *"Verified heads" contains several shares. I see that one of these shares is the one mentioned in "best share". So what are the other      shares mentioned? Other heads that are or will be orphaned or so?
      *What is the difference between "Verified heads" and "heads"?
      *What are the "Verified Tails" and "Tails"?

2) When I look to the "Best share" share, then I see stuff like "Time first seen", "Peer first received from", "Timestamp".
      *I suppose "Time first seen" gives the time that my node received a Inv (or the p2pool equivalent) from another node containing the hash of the share. Is this correct? Or is it the time when my node has completely downloaded the share?
      *"Peer first received from" gives then probably the node that has send my node the Inv containing the share.
      *"Timestamp" is the timestamp from the node that has found the share I guess. But this timestamp probably depends on the accuracy of that nodes clock, and can in theory deviate from reality?

3) Say for example that I want to know the time it takes my node to receive the latest share of the sharechain (so I want to know the time it takes my node to converge to the consensus sharechain). I probably can use the timestamp of the share gegenerated by the node that found the share, as it will be very close to the moment that it sends it to the rest of the network. So if I can also get the time that my node has downloaded the share, and restarts its mining work on top of the new share, I can in principal determine the time that it took the share to propagate from the node that has found the share to my node, and as such I can determine the "dwell time" of my node. Is this correct?

4) If my reasoning in point 3 is correct, I just need to find the time when my node is finished downloading the new share, and the share is added to the local sharechain. Is there a way to access the sharechain of my node directly through a log file or something? I know that p2pool creates logs in the directory /p2pool/data/bitcoin/, and occasionaly I find references to shares downloaded and stuff like that in the output. But is there another file for the sharechain, that contains time data of when a new share is downloaded and added to the share chain?

Thank you in advance
jtoomim
Hero Member
*****
Offline Offline

Activity: 742


View Profile WWW
September 18, 2017, 09:41:08 PM
 #15910

okey, thanks. i will take a look these days. would by nice to get it run on Win10 with Pyton 2.7 (pypy does not run here ...)

I was able to get pypy running on Windows 10 by using the Linux Subsystem for Windows:

https://bitcointalk.org/index.php?topic=18313.msg21025074#msg21025074

However, the reason I made these CPU improvement changes was in the hope that it would allow people to run CPython on medium-speed CPUs without crazy orphan rates. I'm very much interested in hearing whether it works.

Hosting bitcoin miners for $65 to $80/kW/month on clean, cheap hydro power.
http://Toom.im
jtoomim
Hero Member
*****
Offline Offline

Activity: 742


View Profile WWW
September 18, 2017, 09:46:41 PM
 #15911

1) On the web interface of my node I find the following in relation to the shares: "Best share", "Verified heads", "Heads", "Verified tails", "Tails". I'm not sure I fully understand what they mean.
P2pool has a share chain that is very much like the Bitcoin blockchain, with a few differences. The tip of a chain (a block/share with no children) is known as a head. The root of a chain is known as the genesis block in Bitcoin (the block with no parent), but in p2pool it's known as a tail. P2pool's tails *do* have parents, unlike bitcoin, and consequently have a height greater than 1; however, they're called tails in p2pool because their parents have been pruned off from the node's copy of the share chain, so as far as your node is concerned, they have no living parents.

The best share is always a head. It's usually the head with the most work behind it, but not always. The rules for determining the head are a little complicated, and are different in different versions of p2pool.

Quote
     *I suppose "best share" is the last share added to the sharechain (I'm I right about this???).
Not necessarily, but usually. Just because a share is recent doesn't mean that it is placed at the tip of the chain.

Quote
     *"Verified heads"  -- Other heads that are or will be orphaned or so?
Yes, precisely.

Quote
     *What is the difference between "Verified heads" and "heads"?
      *What are the "Verified Tails" and "Tails"?
I'm not sure. I think unverified heads or tails are shares that have not yet been connected to the share chain, such as for a share that is was just downloaded during initial sync but whose ancestors have not yet been downloaded. However, I haven't verified that hypothesis, as I have not yet needed to work on that part of the code.

Quote
     *I suppose "Time first seen" gives the time that my node received a Inv ... Or is it the time when my node has completely downloaded the share?
Completely downloaded and mostly deserialized.

Quote
     *"Peer first received from" gives then probably the node that has send my node the Inv containing the share.
Yes, but it's a sendShares or share_reply message.

Quote
     *"Timestamp" is the timestamp from the node that has found the share I guess. But this timestamp probably depends on the accuracy of that nodes clock, and can in theory deviate from reality?
Correct. In the current p2pool master, the timestamp is required to be between 1 second after the previous share's timestamp and 59 seconds after the previous share's timestamp. Since the timestamps are used for minimum share difficulty adjustments, this can result in a situation where the share difficulty is very slow to adjust downwards after a rapid decrease in the network hashrate. In the jtoomimnet fork, I got rid of this timestamp clipping, and replaced it with a rule that rejects shares that are timestamped to come from the future in order to prevent share difficulty manipulation.

Keep in mind that the timestamp is the time at which the mining job was sent to the hardware, not the time at which the hardware returned the nonce value.

Quote
3) Say for example that I want to know the time it takes my node to receive the latest share of the sharechain (so I want to know the time it takes my node to converge to the consensus sharechain). I probably can use the timestamp of the share gegenerated by the node that found the share, as it will be very close to the moment that it sends it to the rest of the network.
Nope, it's not close. It will usually be off by around 5-50 seconds. But what you can do is use the "Peer first received from" line to browse to the info page for that share on the peer's address (you may have to guess the port number), and repeat, until eventually you get to a peer that says "Peer first received from: Null" for that share, and then you can use the "Time first seen" shown by that ndoe (or just the node that you got the share from, if you're lazy).

When I've done this measurement in the past, it's usually around 1 second per hop for nodes running CPython with 100 ms network latency, and around half that for nodes running pypy.

Quote
4) If my reasoning in point 3 is correct, I just need to find the time when my node is finished downloading the new share, and the share is added to the local sharechain. Is there a way to access the sharechain of my node directly through a log file or something? I know that p2pool creates logs in the directory /p2pool/data/bitcoin/, and occasionaly I find references to shares downloaded and stuff like that in the output. But is there another file for the sharechain, that contains time data of when a new share is downloaded and added to the share chain?
If you run my code (e.g. 1mb_segwit), you can install the rfoo package for python, then run run_p2pool.py with the --rconsole command line option, and then run the rconsole command in a separate terminal. This will give you a python interpreter that effectively runs inside the p2pool process, and allows you access to all of the variables and functions of p2pool while it's running. The share objects can be found in the gnode.tracker.verified object.
1mb_segwit also now has a --bench command-line option, which I think you would find interesting.

You could also maybe parse the log in data/bitcoin/log. That's just the stdout output of p2pool for (usually) the last few days.

Hosting bitcoin miners for $65 to $80/kW/month on clean, cheap hydro power.
http://Toom.im
Xantus
Jr. Member
*
Offline Offline

Activity: 41


View Profile
September 19, 2017, 05:30:23 AM
 #15912

However, the reason I made these CPU improvement changes was in the hope that it would allow people to run CPython on medium-speed CPUs without crazy orphan rates. I'm very much interested in hearing whether it works.

okey, first night run is done. Synchronising and getting down the share dificulty to test run with 4Th was take somethink about 4 hours. This morning i switched the
Miner Hash rate down to somethink about 1Th.
CPU last is now down to 10-15% avergade, put there are peaks to 30% :


my Miner dont runs 24Hr a day but p2pool node is alwas on an reachabel at:
http://212.43.81.114:9332

config is Windows 10 64Bit


here is the Log File (i dont Start the Debug mode ..):
www.c-xantus.de/log

i will take a look for a few more days. Efficenity is better now, but i could be better  Undecided
Cryptonomist
Newbie
*
Offline Offline

Activity: 22


View Profile
September 19, 2017, 10:45:11 AM
 #15913

1) On the web interface of my node I find the following in relation to the shares: "Best share", "Verified heads", "Heads", "Verified tails", "Tails". I'm not sure I fully understand what they mean.
P2pool has a share chain that is very much like the Bitcoin blockchain, with a few differences. The tip of a chain (a block/share with no children) is known as a head. The root of a chain is known as the genesis block in Bitcoin (the block with no parent), but in p2pool it's known as a tail. P2pool's tails *do* have parents, unlike bitcoin, and consequently have a height greater than 1; however, they're called tails in p2pool because their parents have been pruned off from the node's copy of the share chain, so as far as your node is concerned, they have no living parents.

The best share is always a head. It's usually the head with the most work behind it, but not always. The rules for determining the head are a little complicated, and are different in different versions of p2pool.

Quote
     *I suppose "best share" is the last share added to the sharechain (I'm I right about this???).
Not necessarily, but usually. Just because a share is recent doesn't mean that it is placed at the tip of the chain.

Quote
     *"Verified heads"  -- Other heads that are or will be orphaned or so?
Yes, precisely.

Quote
     *What is the difference between "Verified heads" and "heads"?
      *What are the "Verified Tails" and "Tails"?
I'm not sure. I think unverified heads or tails are shares that have not yet been connected to the share chain, such as for a share that is was just downloaded during initial sync but whose ancestors have not yet been downloaded. However, I haven't verified that hypothesis, as I have not yet needed to work on that part of the code.

Quote
     *I suppose "Time first seen" gives the time that my node received a Inv ... Or is it the time when my node has completely downloaded the share?
Completely downloaded and mostly deserialized.

Quote
     *"Peer first received from" gives then probably the node that has send my node the Inv containing the share.
Yes, but it's a sendShares or share_reply message.

Quote
     *"Timestamp" is the timestamp from the node that has found the share I guess. But this timestamp probably depends on the accuracy of that nodes clock, and can in theory deviate from reality?
Correct. In the current p2pool master, the timestamp is required to be between 1 second after the previous share's timestamp and 59 seconds after the previous share's timestamp. Since the timestamps are used for minimum share difficulty adjustments, this can result in a situation where the share difficulty is very slow to adjust downwards after a rapid decrease in the network hashrate. In the jtoomimnet fork, I got rid of this timestamp clipping, and replaced it with a rule that rejects shares that are timestamped to come from the future in order to prevent share difficulty manipulation.

Keep in mind that the timestamp is the time at which the mining job was sent to the hardware, not the time at which the hardware returned the nonce value.

Quote
3) Say for example that I want to know the time it takes my node to receive the latest share of the sharechain (so I want to know the time it takes my node to converge to the consensus sharechain). I probably can use the timestamp of the share gegenerated by the node that found the share, as it will be very close to the moment that it sends it to the rest of the network.
Nope, it's not close. It will usually be off by around 5-50 seconds. But what you can do is use the "Peer first received from" line to browse to the info page for that share on the peer's address (you may have to guess the port number), and repeat, until eventually you get to a peer that says "Peer first received from: Null" for that share, and then you can use the "Time first seen" shown by that ndoe (or just the node that you got the share from, if you're lazy).

When I've done this measurement in the past, it's usually around 1 second per hop for nodes running CPython with 100 ms network latency, and around half that for nodes running pypy.

Quote
4) If my reasoning in point 3 is correct, I just need to find the time when my node is finished downloading the new share, and the share is added to the local sharechain. Is there a way to access the sharechain of my node directly through a log file or something? I know that p2pool creates logs in the directory /p2pool/data/bitcoin/, and occasionaly I find references to shares downloaded and stuff like that in the output. But is there another file for the sharechain, that contains time data of when a new share is downloaded and added to the share chain?
If you run my code (e.g. 1mb_segwit), you can install the rfoo package for python, then run run_p2pool.py with the --rconsole command line option, and then run the rconsole command in a separate terminal. This will give you a python interpreter that effectively runs inside the p2pool process, and allows you access to all of the variables and functions of p2pool while it's running. The share objects can be found in the gnode.tracker.verified object.
1mb_segwit also now has a --bench command-line option, which I think you would find interesting.

You could also maybe parse the log in data/bitcoin/log. That's just the stdout output of p2pool for (usually) the last few days.

Ok great. Thank you for the clarifications. I'll try the methodology you suggest and see if I can get the information I need.
jtoomim
Hero Member
*****
Offline Offline

Activity: 742


View Profile WWW
September 19, 2017, 04:20:48 PM
 #15914

However, the reason I made these CPU improvement changes was in the hope that it would allow people to run CPython on medium-speed CPUs without crazy orphan rates.

config is Windows 10 64Bit

A 2.0 GHz A10 is not what i would call a medium-speed CPU, unfortunately. Sure, it might have 4 cores, but Python is effectively single-threaded, so that doesn't help at all. Pre-Ryzen AMD chips have poor single-threaded performance, so a 2 GHz A10 is equivalent in performance to a roughly 1.3 GHz Core i3 (if such a thing existed). I wish I could get p2pool to run nicely on such a CPU, but I'm afraid that's out of reach at the moment.

You've got plenty of RAM, so I think you can get it to work decently if you go through the steps I described to get Pypy running on Windows.

Also, if you could run p2pool with the --bench option, that would make the log file much more useful to me.

Hosting bitcoin miners for $65 to $80/kW/month on clean, cheap hydro power.
http://Toom.im
rav3n_pl
Legendary
*
Offline Offline

Activity: 1253


Don`t panic! Organize!


View Profile WWW
September 20, 2017, 07:09:02 AM
 #15915

okey, thanks. i will take a look these days. would by nice to get it run on Win10 with Pyton 2.7 (pypy does not run here ...)

I was able to get pypy running on Windows 10 by using the Linux Subsystem for Windows:

https://bitcointalk.org/index.php?topic=18313.msg21025074#msg21025074

However, the reason I made these CPU improvement changes was in the hope that it would allow people to run CPython on medium-speed CPUs without crazy orphan rates. I'm very much interested in hearing whether it works.
This "linux subsystem" is like 5-10x slower than you make a Vitrualbox VM and run Ubuntu in it.
Tested on cross-compiling coin daemons.
It would be way better choice to install Ubuntu desktop in VM, run it in seamless mode and use for whatever you want.

1Rav3nkMayCijuhzcYemMiPYsvcaiwHni  Bitcoin stuff on my OneDrive
My RPC CoinControl for any coin https://bitcointalk.org/index.php?topic=929954
Some stuff on https://github.com/Rav3nPL/
jtoomim
Hero Member
*****
Offline Offline

Activity: 742


View Profile WWW
September 20, 2017, 04:41:51 PM
 #15916

This "linux subsystem" is like 5-10x slower than you make a Vitrualbox VM and run Ubuntu in it.
That assertion is inconsistent with most of the benchmarks I have seen, in which WSL is often faster than native Linux and rarely more than 5% slower.
https://www.phoronix.com/scan.php?page=article&item=windows-10-lxcore&num=2

However, for some reason, code compilation appears to be the exception to that rule. For some strange reason, compiling code on WSL is extremely slow:
https://www.phoronix.com/scan.php?page=article&item=windows-10-lxcore&num=4

Since running p2pool is not code compilation, performance on WSL should be quite good. P2pool is mostly just a CPU-bound task with very little disk IO and a small amount of network IO, so the poor results from code compiling should not manifest here.

Hosting bitcoin miners for $65 to $80/kW/month on clean, cheap hydro power.
http://Toom.im
jtoomim
Hero Member
*****
Offline Offline

Activity: 742


View Profile WWW
September 20, 2017, 07:13:11 PM
 #15917

jtoomimnet found another block two days ago.

https://blockchain.info/block/00000000000000000096cef4bfd159307030923b0111acd39bfb6561b277a375

1014 kB, 3998 kWU, 13.858 BTC.

We also added a few hundred TH/s yesterday, and are now up to 2.2 PH/s.

Hosting bitcoin miners for $65 to $80/kW/month on clean, cheap hydro power.
http://Toom.im
Xantus
Jr. Member
*
Offline Offline

Activity: 41


View Profile
September 20, 2017, 08:45:33 PM
 #15918


A 2.0 GHz A10 is not what i would call a medium-speed CPU, unfortunately. Sure, it might have 4 cores, but Python is effectively single-threaded, so that doesn't help at all. Pre-Ryzen AMD chips have poor single-threaded performance, so a 2 GHz A10 is equivalent in performance to a roughly 1.3 GHz Core i3 (if such a thing existed). I wish I could get p2pool to run nicely on such a CPU, but I'm afraid that's out of reach at the moment.

You've got plenty of RAM, so I think you can get it to work decently if you go through the steps I described to get Pypy running on Windows.

Also, if you could run p2pool with the --bench option, that would make the log file much more useful to me.

hey there,
here is the log file from p2pool on phyton2.7 on windows 10 with --bench option:
www.c-xantus.de/log2
by the way, there is a bug on the p2pool mining difficult. it dont will be set down if smaler miner are working, or it takes days !

i also tried to install these Linux box and followed the intall steps in the ubuntu bash box to test it.
installation runs fine without anny errors. i copied the bitcoin.conf file to /home/user/.bitcoin/bitcoin.conf
and was able to start P2Pool with --bench option on pypy. But seams that twisted dont work ? - i get no connetion to other nodes.
alwas show the twistet errors :
Code:
2017-09-20 22:26:57.168361 Peer 5.9.143.40:9335 says protocol version is 3301, client version 16.0-139-g49e1a94
2017-09-20 22:26:57.168361 Outgoing connection to peer 5.9.143.40:9335 established. p2pool version: 3301 '16.0-139-g49e1a94'
2017-09-20 22:27:18.544607 P2Pool: 0 shares in chain (0 verified/0 total) Peers: 1 (0 incoming)
2017-09-20 22:27:18.544607  Local: 0H/s in last 0.0 seconds Local dead on arrival: ??? Expected time to share: ???
2017-09-20 22:27:18.544607    0.000 ms for update_remote_view_of_my_known_txs
in handle_share_hashes:
Traceback (most recent call last):
Failure: twisted.internet.defer.TimeoutError: in GenericDeferrer

2017-09-20 22:27:18.560231 Lost peer 5.9.143.40:9335 - Connection was aborted locally, using.
2017-09-20 22:27:41.083009    0.000 ms for update_remote_view_of_my_known_txs
2017-09-20 22:28:02.193542 P2Pool: 0 shares in chain (0 verified/0 total) Peers: 0 (0 incoming)
2017-09-20 22:28:02.193542  Local: 0H/s in last 0.0 seconds Local dead on arrival: ??? Expected time to share: ???
2017-09-20 22:28:02.193542    0.000 ms for update_remote_view_of_my_known_txs
Error getting work from bitcoind:
Traceback (most recent call last):
Failure: twisted.internet.defer.TimeoutError: Getting http://127.0.0.1:8332/ took longer than 30 seconds.
jtoomim
Hero Member
*****
Offline Offline

Activity: 742


View Profile WWW
September 20, 2017, 09:19:10 PM
 #15919

Interesting, it seems that time.time() on Windows only has 15 or 16 ms resolution, so all of the short function calls are reported as taking either 0 ms, 15 ms, or 16 ms, even though they're actually probably taking about 4 ms each.

I also see a few lines like this one:
Code:
2017-09-20 07:00:17.936000  453.000 ms for 0 txs in p2p.py:handle_remember_tx (453.000 ms/tx)
453 ms for handle_remember_tx when no transactions are being added seems strange and significant. I'll have to reread the code and see if I can figure out what could be taking so long.

There's also this:
Code:
2017-09-20 07:00:37.877000  750.000 ms for work.py:get_work()
2017-09-20 07:00:37.877000 1734.000 ms for 1 shares in handle_shares (1734.000 ms/share)
That makes about 1.7 seconds of latency just in those two functions for your node switching work. (IIRC, handle_shares() calls get_work, so the 750 ms is already included in the 1734 ms.) There may be a few other functions that I didn't add the benchmarking code to that also play a role, but that latency alone should be responsible for about 5.8% of your DOA+orphan rates.

Code:
2017-09-20 07:02:24.241000 Decoding transactions took 31 ms, Unpacking 1188 ms, hashing 16 ms
The 1188 ms (unpacking) is something I think I know how to fix via a CPU/RAM tradeoff. That will probably be my next task. However, that will only reduce the CPU usage in processing new getblocktemplate responses, which I think is not in the critical code path for share propagation, so I don't expect it to help with DOA+orphan rates much. It's a pretty easy and obvious optimization, though. The node I do my testing on (4.4 GHz Core i7, pypy) only shows about 40 ms for unpacking instead of 1188 ms, so I wasn't sure it would be worthwhile. But if it's stalling your CPU for over a second, that sounds like it could be interfering with things.

Not sure what's the issue with pypy on your machine. Does your CPU show activity when you run it? How much?

Hosting bitcoin miners for $65 to $80/kW/month on clean, cheap hydro power.
http://Toom.im
Xantus
Jr. Member
*
Offline Offline

Activity: 41


View Profile
September 21, 2017, 04:11:41 AM
 #15920

Not sure what's the issue with pypy on your machine. Does your CPU show activity when you run it? How much?
pypy cpu usage is lower than 5%, but it seams as anything is verry slow. it look like p2pool on pypy lags. and also get now connection.
but i did now "sudo apt-get update and "upgrade" and gave pypy another changse this day. loocks better for this moment.
But i have to go to work now and look this evening again does pypy work or not. - i will edit this post ....

thanks agein so far jtoomin
Pages: « 1 ... 746 747 748 749 750 751 752 753 754 755 756 757 758 759 760 761 762 763 764 765 766 767 768 769 770 771 772 773 774 775 776 777 778 779 780 781 782 783 784 785 786 787 788 789 790 791 792 793 794 795 [796] 797 798 799 800 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!