I started haveged on all my 50 vps just to see if I would notice any change in performance or find more blocks, I was extremely surprised with the result !
I had a great start of the day at noon with 10 blocks already found, after having started the haveged service I left for work and let everything run for 6 hours.
I was quite surprised to notice I wasn't receiving any emails notifying me of blocks found and for a good reason, for the first since I started mining with 50 vps I haven't found a single block in 6 hours...
I have just stopped the haveged service on all vps. Now this could be pure bad luck but 50 * 6 = 300 hours or 12.5 days, even my desktop computer solves a block in less time than that !
It seems haveged is responsible but how and why I have no clue. Could just be bad luck, well extremely bad luck...
Topic: [XPM] [ANN] Primecoin High Performance | HP14 released! - page 48. (Read 397657 times)
Yes, I am an idiot 
Nope, you are just lazy: functionally it's less of a problem than idiocy, but ethically it's worse
Just kidding, I think it's just hard to follow every thread (especially when your watchlist contains 50+ topics)
Yeah, it's really hard to follow a thread like this especially when dealing with outside issues like work/school/etc.
I feel like I'm going to be lazy asking this question since it probably has been answered somewhere in the thread, but I have two similar computers mining. Both have Phenom II processors and one is running windows 7 and the other is running ubuntu 13.04. Both computers are running hp9. The one running it in windows is getting 0.7 cpd and the Ubuntu one is getting 0.5 cpd despite the fact that they have phenom IIs with the same number of cores and the same clock speed. Could this be caused by the fact that one of these is a quad core chip (the 0.7 cpd cpu) and one is one of the 6 core ones with two cores locked (the 0.5 cpd chip)? I'm just trying to figure out what I should be doing to get the one with lower performance to match the other one.
Which chips are they? It could be their cache sizes.
Yes, I am an idiot
Nope, you are just lazy: functionally it's less of a problem than idiocy, but ethically it's worse
Just kidding, I think it's just hard to follow every thread (especially when your watchlist contains 50+ topics)
Yeah, it's really hard to follow a thread like this especially when dealing with outside issues like work/school/etc.
I feel like I'm going to be lazy asking this question since it probably has been answered somewhere in the thread, but I have two similar computers mining. Both have Phenom II processors and one is running windows 7 and the other is running ubuntu 13.04. Both computers are running hp9. The one running it in windows is getting 0.7 cpd and the Ubuntu one is getting 0.5 cpd despite the fact that they have phenom IIs with the same number of cores and the same clock speed. Could this be caused by the fact that one of these is a quad core chip (the 0.7 cpd cpu) and one is one of the 6 core ones with two cores locked (the 0.5 cpd chip)? I'm just trying to figure out what I should be doing to get the one with lower performance to match the other one.
Yes, I am an idiot
Nope, you are just lazy: functionally it's less of a problem than idiocy, but ethically it's worse
Just kidding, I think it's just hard to follow every thread (especially when your watchlist contains 50+ topics)
I have 50 vps running with chainsperday going from 1.18 to 0.9 and I find between 15 to 21 blocks per day.
They were not cloned so entropy is not a problem.
They were not cloned so entropy is not a problem.
50 VPS with how many cores? Digital Ocean?
If you have cloned instances running is there a way to fix the lack of entropy?
I've got 10 AWS instances running but not seen any blocks for 3 days and they were all launched from the same AMI.
Maybe you could read a few post above yours and get your answer ?
Yes, I am an idiot
Here's a useful oneliner if you want to see exactlya sorted list of when your blocks were found and if you are not comfortable with reading times and dates as
seconds since 1970... UTC.
Nice one liner seconds since 1970... UTC.
Code:
primecoind listtransactions | grep blocktime | sed -e "s/.* : //" -e "s/,//" | sort | xargs -n 1 -I '{}' date --date=@'{}'
Thanks. Maybe you could read a few post above yours and get your answer ?
Yes, it would answer most of the questions in this thread.People this lazy don't deserve answers.
IMO entropy is not the issue. I've never seen an instance even close to running out of entropy (without havaged / rng-tools installed). I was running hundreds of ec2 instances, all cloned from one, without issue.
I have 50 vps running with chainsperday going from 1.18 to 0.9 and I find between 15 to 21 blocks per day.
They were not cloned so entropy is not a problem.
They were not cloned so entropy is not a problem.
50 VPS with how many cores? Digital Ocean?
If you have cloned instances running is there a way to fix the lack of entropy?
I've got 10 AWS instances running but not seen any blocks for 3 days and they were all launched from the same AMI.
Maybe you could read a few post above yours and get your answer ?
I have 50 vps running with chainsperday going from 1.18 to 0.9 and I find between 15 to 21 blocks per day.
They were not cloned so entropy is not a problem.
They were not cloned so entropy is not a problem.
50 VPS with how many cores? Digital Ocean?
If you have cloned instances running is there a way to fix the lack of entropy?
I've got 10 AWS instances running but not seen any blocks for 3 days and they were all launched from the same AMI.
I have 50 vps running with chainsperday going from 1.18 to 0.9 and I find between 15 to 21 blocks per day.
They were not cloned so entropy is not a problem.
They were not cloned so entropy is not a problem.
50 VPS with how many cores? Digital Ocean?
I have 50 vps running with chainsperday ranging from 1.18 to 0.9 and I find between 15 to 21 blocks per day.
They were not cloned so entropy is not a problem.
They were not cloned so entropy is not a problem.
You guys are confusing finding chains for finding blocks. Having a chains/d of 1 does NOT imply you should find a block a day on average.
Right, as has been pointed out, chainsperday is a count of how many chains should meet the integer difficulty requirement, not considering the fractional difficulty requirement that must also be met.
Simple example:
If your chains per day was 1.0 and diff was 9.0100 then you will probably find 1 block per day on average.
If your chains per day was 1.0 and diff was 9.9985 then you probably won't find a block
Please correct me if my understanding is wrong...
However, like with any solo mining, you are still subject to variance ("luck"). You could find 4 blocks the first day you mine then find nothing for a week or more... etc
You guys are confusing finding chains for finding blocks. Having a chains/d of 1 does NOT imply you should find a block a day on average.
"blocks" : 106059,
"chainspermin" : 21,
"chainsperday" : 2.44443307,
"currentblocksize" : 1000,
"currentblocktx" : 0,
"difficulty" : 9.59809953,
cant say that i find 2 blocks per machine per day.. i am lucky to hit 4 blocks per all 6 mashines per day (All are identical)
"chainspermin" : 21,
"chainsperday" : 2.44443307,
"currentblocksize" : 1000,
"currentblocktx" : 0,
"difficulty" : 9.59809953,
cant say that i find 2 blocks per machine per day.. i am lucky to hit 4 blocks per all 6 mashines per day (All are identical)
If you set up one and cloned it, you may be dealing with conflicting / insufficient entropy.
Quick and easy fix:
Code:
apt-get install haveged -y
update-rc.d haveged defaults
service haveged start
update-rc.d haveged defaults
service haveged start
In case you are interested in the validity of the chains per day metric, with the following setup running on 9 identical machines I managed 8 chains over 24 hours.
8/9=0.8888 chains per day.
I would say, close enough for government work in this case.
8/9=0.8888 chains per day.
I would say, close enough for government work in this case.
Code:
"blocks" : 105938,
"chainspermin" : 3,
"chainsperday" : 0.92945471,
"currentblocksize" : 1000,
"currentblocktx" : 0,
"difficulty" : 9.59519291,
"errors" : "",
"generate" : true,
"genproclimit" : -1,
"roundsievepercentage" : 70,
"primespersec" : 1707,
"pooledtx" : 0,
"sievepercentage" : 10,
"sievesize" : 1100000,
"testnet" : false
"chainspermin" : 3,
"chainsperday" : 0.92945471,
"currentblocksize" : 1000,
"currentblocktx" : 0,
"difficulty" : 9.59519291,
"errors" : "",
"generate" : true,
"genproclimit" : -1,
"roundsievepercentage" : 70,
"primespersec" : 1707,
"pooledtx" : 0,
"sievepercentage" : 10,
"sievesize" : 1100000,
"testnet" : false
Lucky you then. I have 8 machines running at ~1.0 chains/day + a few spare machines on the side. I got 3 blocks in the last 24 hours.
"blocks" : 106059,
"chainspermin" : 21,
"chainsperday" : 2.44443307,
"currentblocksize" : 1000,
"currentblocktx" : 0,
"difficulty" : 9.59809953,
cant say that i find 2 blocks per machine per day.. i am lucky to hit 4 blocks per all 6 mashines per day (All are identical)
If you set up one and cloned it, you may be dealing with conflicting / insufficient entropy.
In case you are interested in the validity of the chains per day metric, with the following setup running on 9 identical machines I managed 8 chains over 24 hours.
8/9=0.8888 chains per day.
I would say, close enough for government work in this case.
8/9=0.8888 chains per day.
I would say, close enough for government work in this case.
Lucky you then. I have 8 machines running at ~1.0 chains/day + a few spare machines on the side. I got 3 blocks in the last 24 hours.
Hmmm...hopefully 13 blocks tomorrow...
Here's a useful oneliner if you want to see exactlya sorted list of when your blocks were found and if you are not comfortable with reading times and dates as
seconds since 1970... UTC.
Code:
primecoind listtransactions | grep blocktime | sed -e "s/.* : //" -e "s/,//" | sort | xargs -n 1 -I '{}' date --date=@'{}'
In case you are interested in the validity of the chains per day metric, with the following setup running on 9 identical machines I managed 8 chains over 24 hours.
8/9=0.8888 chains per day.
I would say, close enough for government work in this case.
8/9=0.8888 chains per day.
I would say, close enough for government work in this case.
Code:
"blocks" : 105938,
"chainspermin" : 3,
"chainsperday" : 0.92945471,
"currentblocksize" : 1000,
"currentblocktx" : 0,
"difficulty" : 9.59519291,
"errors" : "",
"generate" : true,
"genproclimit" : -1,
"roundsievepercentage" : 70,
"primespersec" : 1707,
"pooledtx" : 0,
"sievepercentage" : 10,
"sievesize" : 1100000,
"testnet" : false
"chainspermin" : 3,
"chainsperday" : 0.92945471,
"currentblocksize" : 1000,
"currentblocktx" : 0,
"difficulty" : 9.59519291,
"errors" : "",
"generate" : true,
"genproclimit" : -1,
"roundsievepercentage" : 70,
"primespersec" : 1707,
"pooledtx" : 0,
"sievepercentage" : 10,
"sievesize" : 1100000,
"testnet" : false
Lucky you then. I have 8 machines running at ~1.0 chains/day + a few spare machines on the side. I got 3 blocks in the last 24 hours.
"blocks" : 106059,
"chainspermin" : 21,
"chainsperday" : 2.44443307,
"currentblocksize" : 1000,
"currentblocktx" : 0,
"difficulty" : 9.59809953,
cant say that i find 2 blocks per machine per day.. i am lucky to hit 4 blocks per all 6 mashines per day (All are identical)
hp9 gives me the following compile error on centos6 (the previous version compiled ok):
"In function `CKey::Verify(uint256, std::vector > const&)':
/root/primecoin-0.1.2-hp9/src/key.cpp:376: undefined reference to `ECDSA_verify'
obj/key.o: In function `CKey::SetCompressedPubKey(bool)':
/root/primecoin-0.1.2-hp9/src/key.cpp:125: undefined reference to `EC_KEY_set_conv_form'"
"In function `CKey::Verify(uint256, std::vector
/root/primecoin-0.1.2-hp9/src/key.cpp:376: undefined reference to `ECDSA_verify'
obj/key.o: In function `CKey::SetCompressedPubKey(bool)':
/root/primecoin-0.1.2-hp9/src/key.cpp:125: undefined reference to `EC_KEY_set_conv_form'"
Is it a fresh install of CentOS?
If so, you'll need this step:
Quote
Step 2b. Compiling OpenSSL (for CentOS users)
This step is only required if you're using CentOS. Red Hat has removed support for elliptic curve cryptography from the OpenSSL it supplies.
Code:
cd
rm -rf openssl-1.0.1e.tar.gz openssl-1.0.1e
wget http://ftp://ftp.pca.dfn.de/pub/tools/net/openssl/source/openssl-1.0.1e.tar.gz
tar xzvf openssl-1.0.1e.tar.gz
cd openssl-1.0.1e
./config shared --prefix=/usr/local --libdir=lib
make
sudo make install
This step is only required if you're using CentOS. Red Hat has removed support for elliptic curve cryptography from the OpenSSL it supplies.
Code:
cd
rm -rf openssl-1.0.1e.tar.gz openssl-1.0.1e
wget http://ftp://ftp.pca.dfn.de/pub/tools/net/openssl/source/openssl-1.0.1e.tar.gz
tar xzvf openssl-1.0.1e.tar.gz
cd openssl-1.0.1e
./config shared --prefix=/usr/local --libdir=lib
make
sudo make install
https://bitcointalksearch.org/topic/xpm-primecoin-high-performance-linux-compilation-guide-259022
In case you are interested in the validity of the chains per day metric, with the following setup running on 9 identical machines I managed 8 chains over 24 hours.
8/9=0.8888 chains per day.
I would say, close enough for government work in this case.
8/9=0.8888 chains per day.
I would say, close enough for government work in this case.
Code:
"blocks" : 105938,
"chainspermin" : 3,
"chainsperday" : 0.92945471,
"currentblocksize" : 1000,
"currentblocktx" : 0,
"difficulty" : 9.59519291,
"errors" : "",
"generate" : true,
"genproclimit" : -1,
"roundsievepercentage" : 70,
"primespersec" : 1707,
"pooledtx" : 0,
"sievepercentage" : 10,
"sievesize" : 1100000,
"testnet" : false
"chainspermin" : 3,
"chainsperday" : 0.92945471,
"currentblocksize" : 1000,
"currentblocktx" : 0,
"difficulty" : 9.59519291,
"errors" : "",
"generate" : true,
"genproclimit" : -1,
"roundsievepercentage" : 70,
"primespersec" : 1707,
"pooledtx" : 0,
"sievepercentage" : 10,
"sievesize" : 1100000,
"testnet" : false
Lucky you then. I have 8 machines running at ~1.0 chains/day + a few spare machines on the side. I got 3 blocks in the last 24 hours.
hp9 gives me the following compile error on centos6 (the previous version compiled ok):
"In function `CKey::Verify(uint256, std::vector > const&)':
/root/primecoin-0.1.2-hp9/src/key.cpp:376: undefined reference to `ECDSA_verify'
obj/key.o: In function `CKey::SetCompressedPubKey(bool)':
/root/primecoin-0.1.2-hp9/src/key.cpp:125: undefined reference to `EC_KEY_set_conv_form'"
"In function `CKey::Verify(uint256, std::vector
/root/primecoin-0.1.2-hp9/src/key.cpp:376: undefined reference to `ECDSA_verify'
obj/key.o: In function `CKey::SetCompressedPubKey(bool)':
/root/primecoin-0.1.2-hp9/src/key.cpp:125: undefined reference to `EC_KEY_set_conv_form'"
Jump to: