[XPM] [ANN] Primecoin High Performance | HP14 released!

[Kalshnikov]

what about 40 or 50?

[1713405535]

1713405535

[1713405535]

1713405535

[mikaelh]

what about 40 or 50?

Well, 50 would be some sort of a trade-off between the old setting and the new setting. You will probably get more primes/sec and your chains/day won't plummet. Ultimately choosing the settings is up to you.

[Tamis]

Thanks a lot once again for your excellent work mikaelh !

Could you please update your post (https://bitcointalk.org/index.php?topic=259022.0) with the sources for hp9 ?

I confirm that hp9 reduces pps about 50% down compared to hp8 but as mikaelh explained several time pps is not a reliable mining value.

[mikaelh]

Thanks a lot once again for your excellent work mikaelh !

Could you please update your post (https://bitcointalk.org/index.php?topic=259022.0) with the sources for hp9 ?

Done.

[Tamis]

Thanks a lot once again for your excellent work mikaelh !

Could you please update your post (https://bitcointalk.org/index.php?topic=259022.0) with the sources for hp9 ?

Done.

Thanks, have a dozen vps running and will give later on an update on blocks mined per day with hp9 vs hp8 (default settings for both) !


EDIT :

As a side question mikaelh , do you think there is any interest on installing haveged for mining purpose ?

[mikaelh]

As a side question mikaelh , do you think there is any interest on installing haveged for mining purpose ?

Probably not.

[Tamis]

First block solved with hp9 !

all my miners have been upgraded.

Thanks for confirming what I thought about haveged mikaelh.

[Dsfyu]

Thanks for the update! I have the miner set up and am currently getting the following with hp9 on my 3930k:


09:06:41

{
"blocks" : 95165,
"chainspermin" : 12,
"chainsperday" : 1.41151548,
"currentblocksize" : 1000,
"currentblocktx" : 0,
"difficulty" : 9.21685755,
"errors" : "",
"generate" : true,
"genproclimit" : -1,
"roundsievepercentage" : 70,
"primespersec" : 2875,
"pooledtx" : 0,
"sievepercentage" : 10,
"sievesize" : 1000000,
"testnet" : false
}

Does this look normal? I honestly don't know what kind of rates to expect after updates.

[Tamis]

This looks normal for hp9 Dsfyu.

This is what I get on my 3770k @ 4400 :

{
"blocks" : 95203,
"chainspermin" : 15,
"chainsperday" : 1.35325702,
"currentblocksize" : 1672,
"currentblocktx" : 1,
"difficulty" : 9.21680802,
"errors" : "",
"generate" : true,
"genproclimit" : -1,
"roundsievepercentage" : 70,
"primespersec" : 2625,
"pooledtx" : 1,
"sievepercentage" : 10,
"sievesize" : 1000000,
"testnet" : false
}

2nd hp9 block solved

[redphlegm]

I'm still having a hard time figuring out the best way to optimize / balance sievesize, sievepercentage, and roundsievepercentage. Any pointers / recommendations from anyone?

[ivanlabrie]

I'm still having a hard time figuring out the best way to optimize / balance sievesize, sievepercentage, and roundsievepercentage. Any pointers / recommendations from anyone?

Big +1...I've been doing it based on others results since I don't know practical ways to test it myself.

[bitx64]

Version 0.1.2-hp9 is finally out! (Download links are on the first page as usual.)

Here's the list of notable changes:
 * Sunny's mining optimizations from 0.1.2.
...

any need to uninstall the official 1.1 client and install the official 1.2 client prior to using hp9?

[Tamis]

Version 0.1.2-hp9 is finally out! (Download links are on the first page as usual.)

Here's the list of notable changes:
 * Sunny's mining optimizations from 0.1.2.
...

any need to uninstall the official 1.1 client and install the official 1.2 client prior to using hp9?

No, you don't need the official client to run hp*

[mikaelh]

I'm still having a hard time figuring out the best way to optimize / balance sievesize, sievepercentage, and roundsievepercentage. Any pointers / recommendations from anyone?

Well, I think we are getting to the point where the optimal settings for mainnet will be different from testnet. That means that most of us won't be able to accurately measure the actual block rate and we will have to rely on whatever performance metrics we have. That's where the chains/day estimate comes in. Instead of counting shorter chains found during the search, it's trying to estimate the chances of finding a full-length chain that may lead to a block. Assuming that the model works, it should be the best performance metric available.

The default settings are my best guesses of what the optimal settings would be for most people. With the latest release I was mainly looking at chains/day and then checking 5-chains/h after that to make sure there's some sense in the new setting.

[pocesar]

I'm getting those numbers

2013-08-03 22:46:44 primemeter  19911666 prime/h 353606585 test/h 1440 5-chains/h 2.923962 chain/d

getmininginfo shows

{
"blocks" : 95925,
"chainspermin" : 27,
"chainsperday" : 2.91638892,
"currentblocksize" : 1000,
"currentblocktx" : 0,
"difficulty" : 9.24577916,
"errors" : "",
"generate" : true,
"genproclimit" : -1,
"roundsievepercentage" : 70,
"primespersec" : 5541,
"pooledtx" : 0,
"sievepercentage" : 10,
"sievesize" : 1000000,
"testnet" : false
}

something is off. I'm using a 32 core instance and 60GB of RAM. How does it look like when a block was found?

[relm9]

PPS went down big time with hp9, was getting 6000-7000 pps previously. This is on 2xE5-2620, so 12 cores total.

-bash-4.1$ ./primecoind getmininginfo
{
    "blocks" : 95960,
    "chainspermin" : 13,
    "chainsperday" : 1.35648856,
    "currentblocksize" : 2197,
    "currentblocktx" : 4,
    "difficulty" : 9.24782068,
    "errors" : "",
    "generate" : true,
    "genproclimit" : -1,
    "roundsievepercentage" : 70,
    "primespersec" : 2865,
    "pooledtx" : 4,
    "sievepercentage" : 10,
    "sievesize" : 1000000,
    "testnet" : false
}

Normal?

[TheSpiral]

PPS went down big time with hp9, was getting 6000-7000 pps previously. This is on 2xE5-2620, so 12 cores total.

-bash-4.1$ ./primecoind getmininginfo
{
    "blocks" : 95960,
    "chainspermin" : 13,
    "chainsperday" : 1.35648856,
    "currentblocksize" : 2197,
    "currentblocktx" : 4,
    "difficulty" : 9.24782068,
    "errors" : "",
    "generate" : true,
    "genproclimit" : -1,
    "roundsievepercentage" : 70,
    "primespersec" : 2865,
    "pooledtx" : 4,
    "sievepercentage" : 10,
    "sievesize" : 1000000,
    "testnet" : false
}

Normal?

Apparently. I'm at about 2000, was at about 6000 previously.

[monsterer]

No one seems to be clear on exactly what metric we're supposed to optimise for?

Can someone from the dev team provide some clarity here? Is it chains per minute, primes per second etc etc?

[itod]

Can someone from the dev team provide some clarity here? Is it chains per minute, primes per second etc etc?

You have most competent explanation exactly four posts above yours, from the developer himself.

[redphlegm]

I'm still having a hard time figuring out the best way to optimize / balance sievesize, sievepercentage, and roundsievepercentage. Any pointers / recommendations from anyone?

Well, I think we are getting to the point where the optimal settings for mainnet will be different from testnet. That means that most of us won't be able to accurately measure the actual block rate and we will have to rely on whatever performance metrics we have. That's where the chains/day estimate comes in. Instead of counting shorter chains found during the search, it's trying to estimate the chances of finding a full-length chain that may lead to a block. Assuming that the model works, it should be the best performance metric available.

The default settings are my best guesses of what the optimal settings would be for most people. With the latest release I was mainly looking at chains/day and then checking 5-chains/h after that to make sure there's some sense in the new setting.

I understand that but it would be helpful, at least for me, to understand how to go about optimizing. So we start with default parameters but where do we go from there? I understand that we should try optimizing chains per day but in what manner? Should we be finding the sweet spot for cpd by adjusting sievesize first (to find the highest value), then doing the same for sievepercentage, then roundsievepercentage? If we tweak the first one in and then change another, will it move the potential optimal point for the first variable optimized?

What I'm ideally looking for is some sort of workflow for optimizing the three variables. Like:

Code:

1) Start with default settings, give it 1 hour to get a history of cpd, then increment seivesize up 200k (or 1M or whatever you choose). Obtain 30 min - 1hr of new data and compare the log file to see what the difference was. When you find the optimal setting for sievesize then move on to sievepercentage.
2) Increment sievepercentage by your chosen amount and compare log performance to find the optimal setting. (This is where, if a different sievepercentage effects the ideal sievesize it would be prudent to go back to step 1).
3) Adjust roundsievepercentage to obtain optimal results.

But maybe roundsievepercentage and / or sievepercentage are more dependent on cores, cpu speed, or something else. I just don't understand it enough to come up with a good process to try to optimize. Something like this would be very helpful. Once we figure out a good way to optimize, it seems like it would be relatively easy to create some type of optimization script that will run through this process, collect variables & performance from the log, and after a day or two of running through the script, spit out "based on the script, these are your optimal settings for this machine". Even if it takes a day to settle into these figures, over the long term it would be worth it.