Of course it may be coincidence
Off to install on my other machines
*** 4 hours later ***
3 more newly mined blocks - mikaelh is a mining god!
Topic: [XPM] [ANN] Primecoin High Performance | HP14 released! - page 74. (Read 397645 times)
Installed hp7 last night and today got my first block for a week
Of course it may be coincidence
Off to install on my other machines
*** 4 hours later ***
3 more newly mined blocks - mikaelh is a mining god!
Of course it may be coincidence
Off to install on my other machines
*** 4 hours later ***
3 more newly mined blocks - mikaelh is a mining god!
Ok, Im running i5 2410M @2.30mhz hp7
Have 3mb cache I believe
Seems I get the best pps with sieve size 1M and Sieve percentage 1
Im getting around 2600pps and only 3-5 chains per min.
Ive adjusted the sieve size to 2M pps goes down slightly CPM stays the same
Ive tried playing with sieve percentage and as I go up pps goes down and CPM jumps around but basically stays between 3-5
When I increase sieve size to 4M my pps goes way down to around 600-900pps and 1-2CPM
Cant seem to find a sweet spot yet havent found a block in 3 days. Anyone have any info on settings for my cpu or just performance with different parameters?
From my experience you really don't want sievepercentage lower than 8. 1 is very bad and way too low. Use the 5-chains value from debug.log as a performance guide too. A lower sievepercentage will increase PPS but that's a bad indicator to use. The sievepercentage is 10 by default for a reason and that is because for many people this will be the optimal number. The same is true for sievesize. You do have to play around to get a good combination but do NOT use PPS as a performance guide. Have 3mb cache I believe
Seems I get the best pps with sieve size 1M and Sieve percentage 1
Im getting around 2600pps and only 3-5 chains per min.
Ive adjusted the sieve size to 2M pps goes down slightly CPM stays the same
Ive tried playing with sieve percentage and as I go up pps goes down and CPM jumps around but basically stays between 3-5
When I increase sieve size to 4M my pps goes way down to around 600-900pps and 1-2CPM
Cant seem to find a sweet spot yet havent found a block in 3 days. Anyone have any info on settings for my cpu or just performance with different parameters?
Seems my 5-chains value is between 60-360 with SP=8 and SS=1M (running closer to default settings)
Whats would be a decent 5-chains value range for my system?
Looking back on the log I have had up to 500 5-chains, but I will have to go back again and see what settings produced what. How useful is CPM?
Is it already too difficult to get some results?
I'm mining with an i7 and get ~800-1000 pps. But didn't find anything in the last 20h
I'm mining with an i7 and get ~800-1000 pps. But didn't find anything in the last 20h
Ok, Im running i5 2410M @2.30mhz hp7
Have 3mb cache I believe
Seems I get the best pps with sieve size 1M and Sieve percentage 1
Im getting around 2600pps and only 3-5 chains per min.
Ive adjusted the sieve size to 2M pps goes down slightly CPM stays the same
Ive tried playing with sieve percentage and as I go up pps goes down and CPM jumps around but basically stays between 3-5
When I increase sieve size to 4M my pps goes way down to around 600-900pps and 1-2CPM
Cant seem to find a sweet spot yet havent found a block in 3 days. Anyone have any info on settings for my cpu or just performance with different parameters?
From my experience you really don't want sievepercentage lower than 8. 1 is very bad and way too low. Use the 5-chains value from debug.log as a performance guide too. A lower sievepercentage will increase PPS but that's a bad indicator to use. The sievepercentage is 10 by default for a reason and that is because for many people this will be the optimal number. The same is true for sievesize. You do have to play around to get a good combination but do NOT use PPS as a performance guide. Have 3mb cache I believe
Seems I get the best pps with sieve size 1M and Sieve percentage 1
Im getting around 2600pps and only 3-5 chains per min.
Ive adjusted the sieve size to 2M pps goes down slightly CPM stays the same
Ive tried playing with sieve percentage and as I go up pps goes down and CPM jumps around but basically stays between 3-5
When I increase sieve size to 4M my pps goes way down to around 600-900pps and 1-2CPM
Cant seem to find a sweet spot yet havent found a block in 3 days. Anyone have any info on settings for my cpu or just performance with different parameters?
Ok, Im running i5 2410M @2.30mhz hp7
Have 3mb cache I believe
Seems I get the best pps with sieve size 1M and Sieve percentage 1
Im getting around 2600pps and only 3-5 chains per min.
Ive adjusted the sieve size to 2M pps goes down slightly CPM stays the same
Ive tried playing with sieve percentage and as I go up pps goes down and CPM jumps around but basically stays between 3-5
When I increase sieve size to 4M my pps goes way down to around 600-900pps and 1-2CPM
Cant seem to find a sweet spot yet havent found a block in 3 days. Anyone have any info on settings for my cpu or just performance with different parameters?
Have 3mb cache I believe
Seems I get the best pps with sieve size 1M and Sieve percentage 1
Im getting around 2600pps and only 3-5 chains per min.
Ive adjusted the sieve size to 2M pps goes down slightly CPM stays the same
Ive tried playing with sieve percentage and as I go up pps goes down and CPM jumps around but basically stays between 3-5
When I increase sieve size to 4M my pps goes way down to around 600-900pps and 1-2CPM
Cant seem to find a sweet spot yet havent found a block in 3 days. Anyone have any info on settings for my cpu or just performance with different parameters?
Can some kind soul give a good non mathematical explanation of sievesize, and what is a good setting, when to change it etc.. ?
cheers
cheers
OK I was full of sh!t, I went back to version 5 and 1M SS as I had been using and I get relatively low PPS, so it must simply be the difficulty increase you mentioned. The highest PPS values I am seeing now with v5 is ~1760 but often it reports lower than that, usually ~1300-1400. This is what I was getting with v7. I'm surprised the difficulty has had such a impact so quickly, I'm sure just last night it was regularly over 2000 PPS. I just saw your OP edit:
I had been assuming it was continuously varying between the integers.
FWIW I'm using a Core2Quad Q9550 @ stock speeds (2.83 GHz).
I am glad though that the sievesize parameter issue has been cleared up though.
Quote
2. Network difficulty has changed. Prime rate goes down when the integer part of the difficulty changes (i.e. going from 8.xx to 9.xx). It's a feature of the mining algorithm and nothing can be done about it.
I had been assuming it was continuously varying between the integers.
FWIW I'm using a Core2Quad Q9550 @ stock speeds (2.83 GHz).
I am glad though that the sievesize parameter issue has been cleared up though.
Yup, I'm also glad it got sorted out. I updated the FAQ yet again about the command line parameters.
hey mikaelh!
try this: in the function FermatProbablePrimalityTestFast, you don't need this part:
If Fermat's test fails, just return false. The fractional part is irrelevant if your first number in the chain is not prime. Since most candidates fail Fermat's test, this code is executed many times, so it should give you some speed up. It did increase PPS 25% for me, but I didn't have the trial division optimization.
btw, I don't know how effective is that, we are looking for Fermat's pseudo primes to the base 2, not for actual primes, so maybe your optimization is filtering numbers that would have passed the test.
For those who'd like to share some love: ARQYnPjkeSgtmx41bypmnkbcHLvWPafGR5
I'd do a pull request, but there's no github anymore
regards
try this: in the function FermatProbablePrimalityTestFast, you don't need this part:
Code:
// Failed Fermat test, calculate fractional length
mpz_sub(mpzE, mpzN, mpzR);
mpz_mul_2exp(mpzR, mpzE, nFractionalBits);
mpz_tdiv_q(mpzE, mpzR, mpzN);
unsigned int nFractionalLength = mpz_get_ui(mpzE);
if (nFractionalLength >= (1 << nFractionalBits))
return error("FermatProbablePrimalityTest() : fractional assert");
nLength = (nLength & TARGET_LENGTH_MASK) | nFractionalLength;
mpz_sub(mpzE, mpzN, mpzR);
mpz_mul_2exp(mpzR, mpzE, nFractionalBits);
mpz_tdiv_q(mpzE, mpzR, mpzN);
unsigned int nFractionalLength = mpz_get_ui(mpzE);
if (nFractionalLength >= (1 << nFractionalBits))
return error("FermatProbablePrimalityTest() : fractional assert");
nLength = (nLength & TARGET_LENGTH_MASK) | nFractionalLength;
If Fermat's test fails, just return false. The fractional part is irrelevant if your first number in the chain is not prime. Since most candidates fail Fermat's test, this code is executed many times, so it should give you some speed up. It did increase PPS 25% for me, but I didn't have the trial division optimization.
btw, I don't know how effective is that, we are looking for Fermat's pseudo primes to the base 2, not for actual primes, so maybe your optimization is filtering numbers that would have passed the test.
For those who'd like to share some love: ARQYnPjkeSgtmx41bypmnkbcHLvWPafGR5
I'd do a pull request, but there's no github anymore
regards
Well, that's a nice idea. The fractional part is definitely useless if the first number in the chain is not a prime. My profiling software shows that about 0.4% of cycles are spent calculating the fractional part. So it's not a huge optimization but it's something.
You need to be careful with the return values though. You can easily start getting false positives if you get them wrong.
And yes, github is still disabled. I probably need to send them another e-mail. In the meantime you use bitbucket or just send me some patches.
OK I was full of sh!t, I went back to version 5 and 1M SS as I had been using and I get relatively low PPS, so it must simply be the difficulty increase you mentioned. The highest PPS values I am seeing now with v5 is ~1760 but often it reports lower than that, usually ~1300-1400. This is what I was getting with v7. I'm surprised the difficulty has had such a impact so quickly, I'm sure just last night it was regularly over 2000 PPS. I just saw your OP edit:
I had been assuming it was continuously varying between the integers.
FWIW I'm using a Core2Quad Q9550 @ stock speeds (2.83 GHz).
I am glad though that the sievesize parameter issue has been cleared up though.
Quote
2. Network difficulty has changed. Prime rate goes down when the integer part of the difficulty changes (i.e. going from 8.xx to 9.xx). It's a feature of the mining algorithm and nothing can be done about it.
I had been assuming it was continuously varying between the integers.
FWIW I'm using a Core2Quad Q9550 @ stock speeds (2.83 GHz).
I am glad though that the sievesize parameter issue has been cleared up though.
I just went from v5 to v7 and now my prime rate is halved. Anyone else having this? Is it because of the optomizations made (ie. more efficient/accurate)?
Also, I have set: -sievesize=4000000
but when I view stats with getmininginfo it always says its on 1M not 4M?
Also, I have set: -sievesize=4000000
but when I view stats with getmininginfo it always says its on 1M not 4M?
I believe that when you set sievesize from the command line, you need to leave a space between the switch and the value for it to parse correctly, i.e., "-sievesize 4000000". If you are setting it in your .conf file, then you need the '=' sign.
Nope, you need to use the '=' sign without any spaces in between. That's how Primecoin (Bitcoin) command line parameters work.
Some examples:
primecoin-qt.exe -sievesize=2000000
primecoind.exe -sievesize=2000000
Sorry, I stand corrected.
My prime rate was 2400 with v5 then I extracted v7 and ran it, only gets 1200-1300 now. It only took me 1 minute to extract the new version and change the target I run, this is not comparing between days.
I was trying to get 4M sievesize with this shortcut command to start it:
C:\Windows\System32\cmd.exe /c start "runlow" /low C:\primecoin-0.1.1-hp7-winx64\primecoin-qt.exe -gen -setgenerate true -sievesize=4000000
But as I said it wasn't working: The problem was simply that -setgenerate true was supposed to be -setgenerate=true. Now the parameter after it (sievesize) works properly:
I was trying to get 4M sievesize with this shortcut command to start it:
C:\Windows\System32\cmd.exe /c start "runlow" /low C:\primecoin-0.1.1-hp7-winx64\primecoin-qt.exe -gen -setgenerate true -sievesize=4000000
But as I said it wasn't working: The problem was simply that -setgenerate true was supposed to be -setgenerate=true. Now the parameter after it (sievesize) works properly:
-setgenerate is not a valid command line parameter. It doesn't do anything. Also your syntax was incorrect as you already noticed (you must use the '=' sign, not a space). The incorrect syntax is probably the reason why the -sievesize parameter was not processed.
Can you find out what your CPU model is? It may help me figure out why your performance has dropped.
hey mikaelh!
try this: in the function FermatProbablePrimalityTestFast, you don't need this part:
If Fermat's test fails, just return false. The fractional part is irrelevant if your first number in the chain is not prime. Since most candidates fail Fermat's test, this code is executed many times, so it should give you some speed up. It did increase PPS 25% for me, but I didn't have the trial division optimization.
btw, I don't know how effective is that, we are looking for Fermat's pseudo primes to the base 2, not for actual primes, so maybe your optimization is filtering numbers that would have passed the test.
For those who'd like to share some love: ARQYnPjkeSgtmx41bypmnkbcHLvWPafGR5
I'd do a pull request, but there's no github anymore
regards
try this: in the function FermatProbablePrimalityTestFast, you don't need this part:
Code:
// Failed Fermat test, calculate fractional length
mpz_sub(mpzE, mpzN, mpzR);
mpz_mul_2exp(mpzR, mpzE, nFractionalBits);
mpz_tdiv_q(mpzE, mpzR, mpzN);
unsigned int nFractionalLength = mpz_get_ui(mpzE);
if (nFractionalLength >= (1 << nFractionalBits))
return error("FermatProbablePrimalityTest() : fractional assert");
nLength = (nLength & TARGET_LENGTH_MASK) | nFractionalLength;
If Fermat's test fails, just return false. The fractional part is irrelevant if your first number in the chain is not prime. Since most candidates fail Fermat's test, this code is executed many times, so it should give you some speed up. It did increase PPS 25% for me, but I didn't have the trial division optimization.
btw, I don't know how effective is that, we are looking for Fermat's pseudo primes to the base 2, not for actual primes, so maybe your optimization is filtering numbers that would have passed the test.
For those who'd like to share some love: ARQYnPjkeSgtmx41bypmnkbcHLvWPafGR5
I'd do a pull request, but there's no github anymore
regards
I just went from v5 to v7 and now my prime rate is halved. Anyone else having this? Is it because of the optomizations made (ie. more efficient/accurate)?
Also, I have set: -sievesize=4000000
but when I view stats with getmininginfo it always says its on 1M not 4M?
Also, I have set: -sievesize=4000000
but when I view stats with getmininginfo it always says its on 1M not 4M?
I believe that when you set sievesize from the command line, you need to leave a space between the switch and the value for it to parse correctly, i.e., "-sievesize 4000000". If you are setting it in your .conf file, then you need the '=' sign.
Nope, you need to use the '=' sign without any spaces in between. That's how Primecoin (Bitcoin) command line parameters work.
Some examples:
primecoin-qt.exe -sievesize=2000000
primecoind.exe -sievesize=2000000
I just went from v5 to v7 and now my prime rate is halved. Anyone else having this? Is it because of the optomizations made (ie. more efficient/accurate)?
Also, I have set: -sievesize=4000000
but when I view stats with getmininginfo it always says its on 1M not 4M?
Also, I have set: -sievesize=4000000
but when I view stats with getmininginfo it always says its on 1M not 4M?
Well, there's a couple of things you can check (added these to the FAQ):
1. Make sure you're not using the 32-bit version which is slower.
2. Don't compare prime rate against a lower network difficulty. Difficulty went over 9 couple of days ago. Everyone's hash rate dropped by about 30%.
In general prime rate should not go down between releases as long as they are being compared against the same network difficulty. If someone has experienced a drop that is not explained by the previous two points, then please post some information about your system.
If -sievesize is not working, then you're putting it in the wrong place. EDIT: I also updated the FAQ concerning this.
I am definitely using the 64 bit version as I had previously.
My prime rate was 2400 with v5 then I extracted v7 and ran it, only gets 1200-1300 now. It only took me 1 minute to extract the new version and change the target I run, this is not comparing between days.
I was trying to get 4M sievesize with this shortcut command to start it:
C:\Windows\System32\cmd.exe /c start "runlow" /low C:\primecoin-0.1.1-hp7-winx64\primecoin-qt.exe -gen -setgenerate true -sievesize=4000000
But as I said it wasn't working: The problem was simply that -setgenerate true was supposed to be -setgenerate=true. Now the parameter after it (sievesize) works properly:
except... it crashes on 4M. So I have it running on 2M right now:
C:\Windows\System32\cmd.exe /c start "runlow" /low C:\primecoin-0.1.1-hp7-winx64\primecoin-qt.exe -gen -setgenerate=true -sievesize=2000000
I just went from v5 to v7 and now my prime rate is halved. Anyone else having this? Is it because of the optomizations made (ie. more efficient/accurate)?
Also, I have set: -sievesize=4000000
but when I view stats with getmininginfo it always says its on 1M not 4M?
Also, I have set: -sievesize=4000000
but when I view stats with getmininginfo it always says its on 1M not 4M?
I believe that when you set sievesize from the command line, you need to leave a space between the switch and the value for it to parse correctly, i.e., "-sievesize 4000000". If you are setting it in your .conf file, then you need the '=' sign.
As I found, it seems that when using parameters in a shortcut's target field, you must use = sign instead of the space.
https://i.imgur.com/d7qiw8W.jpg
I just went from v5 to v7 and now my prime rate is halved. Anyone else having this? Is it because of the optomizations made (ie. more efficient/accurate)?
Also, I have set: -sievesize=4000000
but when I view stats with getmininginfo it always says its on 1M not 4M?
Also, I have set: -sievesize=4000000
but when I view stats with getmininginfo it always says its on 1M not 4M?
I believe that when you set sievesize from the command line, you need to leave a space between the switch and the value for it to parse correctly, i.e., "-sievesize 4000000". If you are setting it in your .conf file, then you need the '=' sign.
I just went from v5 to v7 and now my prime rate is halved. Anyone else having this? Is it because of the optomizations made (ie. more efficient/accurate)?
Also, I have set: -sievesize=4000000
but when I view stats with getmininginfo it always says its on 1M not 4M?
Also, I have set: -sievesize=4000000
but when I view stats with getmininginfo it always says its on 1M not 4M?
Doublecheck that you don't have sievesize set in your primecoin.conf file?
I just went from v5 to v7 and now my prime rate is halved. Anyone else having this? Is it because of the optomizations made (ie. more efficient/accurate)?
Also, I have set: -sievesize=4000000
but when I view stats with getmininginfo it always says its on 1M not 4M?
Also, I have set: -sievesize=4000000
but when I view stats with getmininginfo it always says its on 1M not 4M?
Well, there's a couple of things you can check (added these to the FAQ):
1. Make sure you're not using the 32-bit version which is slower.
2. Don't compare prime rate against a lower network difficulty. Difficulty went over 9 couple of days ago. Everyone's hash rate dropped by about 30%.
In general prime rate should not go down between releases as long as they are being compared against the same network difficulty. If someone has experienced a drop that is not explained by the previous two points, then please post some information about your system.
If -sievesize is not working, then you're putting it in the wrong place. EDIT: I also updated the FAQ concerning this.
I just went from v5 to v7 and now my prime rate is halved. Anyone else having this? Is it because of the optomizations made (ie. more efficient/accurate)?
Also, I have set: -sievesize=4000000
but when I view stats with getmininginfo it always says its on 1M not 4M?
Also, I have set: -sievesize=4000000
but when I view stats with getmininginfo it always says its on 1M not 4M?
I'm getting internal compiler error when compiling hp7 on Ubuntu 12.04 & 13.04
anyone having same problem
anyone having same problem
Obviously that correction mattered. Yes you complained, you made huge mistakes there.
Stop spying on me, QRK earned me more than you and half of the people mining XPM will.
Get real servers and then you won't go into an loss.
Stop spying on me, QRK earned me more than you and half of the people mining XPM will.
Get real servers and then you won't go into an loss.
Can I get you something to drink? Water? Go relax under the sun a bit... It sounds like you are just passing through.
* maco weaves Good-bye!
That sure was an executed IRC command and now used in the forum using /me
Jump to: