Will there be a hp8 release soon?
Probably yes. The current code is looking good now that the performance regression has been fixed.
Thanks for the update! I can't wait for the new hp8 release.
Topic: [XPM] [ANN] Primecoin High Performance | HP14 released! - page 68. (Read 397616 times)
Probably yes. The current code is looking good now that the performance regression has been fixed.
Thanks for the update! I can't wait for the new hp8 release.
Will there be a hp8 release soon?
Probably yes. The current code is looking good now that the performance regression has been fixed.
Will there be a hp8 release soon?
Is there anyway to find out which version of the HP* I have installed?
Currently there isn't. You can try comparing your binary file against different releases.
Also I found the reason for the performance regression. The latest code seems to get stuck on using too low round primorials.
I plan to.
Is there anyway to find out which version of the HP* I have installed?
Currently there isn't. You can try comparing your binary file against different releases.
Also I found the reason for the performance regression. The latest code seems to get stuck on using too low round primorials.
Is there anyway to find out which version of the HP* I have installed?
Currently there isn't. You can try comparing your binary file against different releases.
Also I found the reason for the performance regression. The latest code seems to get stuck on using too low round primorials.
Hi,
I'm also trying to see what are the optimal parameters and based on my testing I found that nTestsAtOnce = 500 in the MineProbablePrimeChain() functions doesn't gives me the optimal performance.
I tested it with 5chain performance and I introduced for myself also 6chain average and tested mainly against this value. For me the optimal value was around nTestsAtOnce = 1800. I also used sievesize 800000, and sievepercentage over 50 gave better results. PPS is not at all a performance indicator here.
Edit: I made some other modifications as well that I can't remember now so if anybody want to test these values may not get the same results.
Well, nTestsAtOnce should have only minimal impact on performance. It's there so that the call won't block the main loop for too long.
Sievesize and sievepercentage definitely do affect performance but you have to do your statistics properly with those. Preferably you should be measuring actual block rate.
Also if you happen to be testing on mainnet, make sure you grab my fix for the performance regression.
Also I found the reason for the performance regression. The latest code seems to get stuck on using too low round primorials.
The performance regression should be fixed by latest commit on bitbucket.
Is there anyway to find out which version of the HP* I have installed?
Currently there isn't. You can try comparing your binary file against different releases.
Also I found the reason for the performance regression. The latest code seems to get stuck on using too low round primorials.
Hi,
I'm also trying to see what are the optimal parameters and based on my testing I found that nTestsAtOnce = 500 in the MineProbablePrimeChain() functions doesn't gives me the optimal performance.
I tested it with 5chain performance and I introduced for myself also 6chain average and tested mainly against this value. For me the optimal value was around nTestsAtOnce = 1800. I also used sievesize 800000, and sievepercentage over 50 gave better results. PPS is not at all a performance indicator here.
Edit: I made some other modifications as well that I can't remember now so if anybody want to test these values may not get the same results.
I am currently testing the latest commits, it seems that the PPS indicator is very low compared to the value before, more than halved my numbers and chainspermin is 0 mostly all the time.
I will keep on testing, meanwhile, is anybody else testing the CURRENT version and seeing the same results out there ?
I will keep on testing, meanwhile, is anybody else testing the CURRENT version and seeing the same results out there ?
This happened for me too, on my Debian server with an i5-3570. I can't get even 1k PPS anymore, and chainspermin is around 1. HP7 was performing much better before. I don't have this performance problem with the newest version on an Ubuntu VirtualBox installation.
Here with Ubuntu 10.04 and i7-950 it's the same. PPS 300-700. Is use a self compilied GMP-lib.
Is there anyway to find out which version of the HP* I have installed?
Getinfo just shows which just shows the primecoin rev:
{
"version" : "v0.1.1.0-unk-beta",
"protocolversion" : 70001,
"walletversion" : 60000,
"balance" : 203.26000000,
"blocks" : 82636,
"moneysupply" : 1193468.71000000,
"timeoffset" : -1,
"connections" : 8,
"proxy" : "",
"testnet" : false,
"keypoololdest" : 1373284836,
"keypoolsize" : 106,
"paytxfee" : 0.00000000,
"errors" : ""
}
Getinfo just shows which just shows the primecoin rev:
{
"version" : "v0.1.1.0-unk-beta",
"protocolversion" : 70001,
"walletversion" : 60000,
"balance" : 203.26000000,
"blocks" : 82636,
"moneysupply" : 1193468.71000000,
"timeoffset" : -1,
"connections" : 8,
"proxy" : "",
"testnet" : false,
"keypoololdest" : 1373284836,
"keypoolsize" : 106,
"paytxfee" : 0.00000000,
"errors" : ""
}
Good idea... That would come in handy
Is there anyway to find out which version of the HP* I have installed?
You can also check the output of getmininginfo, and see if the latest commands are added chainspermin, sievepercentage and sievesize.
This will get you close to the hpX release you are using.
Is there anyway to find out which version of the HP* I have installed?
Currently there isn't. You can try comparing your binary file against different releases.
Also I found the reason for the performance regression. The latest code seems to get stuck on using too low round primorials.
Is there anyway to find out which version of the HP* I have installed?
Getinfo just shows which just shows the primecoin rev:
{
"version" : "v0.1.1.0-unk-beta",
"protocolversion" : 70001,
"walletversion" : 60000,
"balance" : 203.26000000,
"blocks" : 82636,
"moneysupply" : 1193468.71000000,
"timeoffset" : -1,
"connections" : 8,
"proxy" : "",
"testnet" : false,
"keypoololdest" : 1373284836,
"keypoolsize" : 106,
"paytxfee" : 0.00000000,
"errors" : ""
}
Getinfo just shows which just shows the primecoin rev:
{
"version" : "v0.1.1.0-unk-beta",
"protocolversion" : 70001,
"walletversion" : 60000,
"balance" : 203.26000000,
"blocks" : 82636,
"moneysupply" : 1193468.71000000,
"timeoffset" : -1,
"connections" : 8,
"proxy" : "",
"testnet" : false,
"keypoololdest" : 1373284836,
"keypoolsize" : 106,
"paytxfee" : 0.00000000,
"errors" : ""
}
I might have found a bug in hp7. I copied the hp7 code over to Reaper, and found some weird behavior. I noticed that many shares/blocks it found, had a difficulty with a fractional part of 0.
Function: FermatProbablePrimalityTestFast. It does a Fermat test, and if it fails, it calculates the fractional part. However, there's a fast division test before the Fermat test. If the fast division test is succesful, the function is returned from and the fractional part isn't calculated. If it just happened to be the last number in a chain, the fractional part isn't calculated and is left at 0. This means if the difficulty is for example 6.2, and the miner found a block of difficulty 6.3, it's possible that the fractional part was left uncalculated, and the miner thinks it's difficulty 6.0. The block doesn't get submitted and lots of profit has been lost.
The same applies to EulerLagrangeLifchitzPrimalityTestFast.
Right now I don't have git set up, I can't submit a patch.
Function: FermatProbablePrimalityTestFast. It does a Fermat test, and if it fails, it calculates the fractional part. However, there's a fast division test before the Fermat test. If the fast division test is succesful, the function is returned from and the fractional part isn't calculated. If it just happened to be the last number in a chain, the fractional part isn't calculated and is left at 0. This means if the difficulty is for example 6.2, and the miner found a block of difficulty 6.3, it's possible that the fractional part was left uncalculated, and the miner thinks it's difficulty 6.0. The block doesn't get submitted and lots of profit has been lost.
The same applies to EulerLagrangeLifchitzPrimalityTestFast.
Right now I don't have git set up, I can't submit a patch.
I updated to hp7 today on 13 i5 and i7s mining machines, only found 2 blocks in 14 hours, maybe I ran out of luck but I guess its the bug. I'm thinking about reverting to hp5 before going to sleep.
But then there is the issue of random crashes - I had no luck mining with hp5 or hp6 due to crashes every hour or so on my 3930k - did you experience this on hp5 with those machines at all?
I followed this guide to the end: http://ecoinomist.com/xpm-primecoin-mining-guide-on-linux
And there is a simple script + cronjob combo that takes care of the crash, if it happened to me I didn't notice. By using hp5 I found my first block in 4 hours.
When I was using hp5 and hp6 I didn't get anything for two days and when I installed hp7 yesterday I got a block within a half hour - It seems to come down to luck in the end - My first two days had nothing and then I got a block yesterday and today on hp7. I would really like to know how much of a difference it makes for you reverting back to hp5.
I feel a sleep last night, but this morning I re-installed hp5 on all my machines and found a block within 15 minutes. I'll report back tonight.
I am currently testing the latest commits, it seems that the PPS indicator is very low compared to the value before, more than halved my numbers and chainspermin is 0 mostly all the time.
I will keep on testing, meanwhile, is anybody else testing the CURRENT version and seeing the same results out there ?
I will keep on testing, meanwhile, is anybody else testing the CURRENT version and seeing the same results out there ?
This happened for me too, on my Debian server with an i5-3570. I can't get even 1k PPS anymore, and chainspermin is around 1. HP7 was performing much better before. I don't have this performance problem with the newest version on an Ubuntu VirtualBox installation.
There does indeed seem to be a regression with the latest code on mainnet. I'm trying to investigate it further now.
I am currently testing the latest commits, it seems that the PPS indicator is very low compared to the value before, more than halved my numbers and chainspermin is 0 mostly all the time.
I will keep on testing, meanwhile, is anybody else testing the CURRENT version and seeing the same results out there ?
I will keep on testing, meanwhile, is anybody else testing the CURRENT version and seeing the same results out there ?
This happened for me too, on my Debian server with an i5-3570. I can't get even 1k PPS anymore, and chainspermin is around 1. HP7 was performing much better before. I don't have this performance problem with the newest version on an Ubuntu VirtualBox installation.
@mikaelh: Why not merge your code with Sunny King's? He stated that it's due to licensing problems with libgmp (can't find the source), but I think that this is wrong. libgmp is LGPL, not GPL, and can therefore be used even in closed-source projects provided that you link to it only dynamically. Which primecoind does, so you would be fine even if primecoin would be closed-source.
Well, technically my Windows builds have been using static linking. It can be changed to dynamic linking. x86 will take a minor performance hit from that but x64 should be fine.
Even if the licensing concerns are solved through dynamic linking, it's still Sunny King's call whether he wants the code or not.
+1 for merging code, hope Sunny King will make clear where he stands on this one. It's not normal that wast majority of miners ignore the official version, not to mention the security issues. The problem few days ago had to wait for mikaelh to wake up for solution to be implemented network-wide, is that what Sunny King wants? It certainly doesn't add to confidence in XPM. Also it will give mikaelh recognition for his work on this coin, I hope Sunny King agrees with that.
ah - thanks for your answer . 20% seems about right to me from the blocks I solved with v7 vs v5. I had about half my instances on v5 and half on v7.
edit: NVM I understand the debug file and why it fluctuates. the stats are calculated based on last 60 seconds of mining, then multiplied by 60 to get per hour.
. 20% seems about right to me from the blocks I solved with v7 vs v5. I had about half my instances on v5 and half on v7.edit: NVM I understand the debug file and why it fluctuates. the stats are calculated based on last 60 seconds of mining, then multiplied by 60 to get per hour.
I really wish it was averaged over a longer period, now I have to monitor the average with a shell script.
Use the source, Luke!
(it's open source, you know...)
Changing the code to compute a sliding average over the last half hour or so should be a bit easier than implementing a faster prime finding algorithm :-)
Onkel Paul
I do not understand primecoin that well at the moment, the problem with v7 would that be reflected in primemeter stats in the debug file, does anyone know?
No, it won't show up in primes/sec or chains/min. I'm guessing it's reducing block rate by about 20%.
Is this only a problem in hp7? If it is, I assume that most folks would be better off by going back to hp6.
HP6 is also affected.
ah - thanks for your answer . 20% seems about right to me from the blocks I solved with v7 vs v5. I had about half my instances on v5 and half on v7.
edit: NVM I understand the debug file and why it fluctuates. the stats are calculated based on last 60 seconds of mining, then multiplied by 60 to get per hour.
. 20% seems about right to me from the blocks I solved with v7 vs v5. I had about half my instances on v5 and half on v7.edit: NVM I understand the debug file and why it fluctuates. the stats are calculated based on last 60 seconds of mining, then multiplied by 60 to get per hour.
I really wish it was averaged over a longer period, now I have to monitor the average with a shell script.
Jump to: