[XPM] [ANN] Primecoin High Performance | HP14 released! - page 67.

AstroKev

newbie

Activity: 23

Merit: 0

Seeing nearly 2x improvement. Amazing, great work.

Code:

> ./primecoind getmininginfo
{
   "blocks" : 83381,
   "chainspermin" : 58,
   "currentblocksize" : 1000,
   "currentblocktx" : 0,
   "difficulty" : 9.26739043,
   "errors" : "",
   "generate" : true,
   "genproclimit" : -1,
   "roundsievepercentage" : 30,
   "primespersec" : 33445,
   "pooledtx" : 0,
   "sievepercentage" : 10,
   "sievesize" : 100000,
   "testnet" : false
}

Dsfyu

member

Activity: 75

Merit: 10

Thanks for the update - I'm seeing roughly a 40% increase in pps right now - averaging 6400 instead of about 4600 before. I'm still getting roughly 10-20 cpm with an average of about 15-17 (no change). Now lets see if this affects how often I find blocks...

Tuck Fheman

sr. member

Activity: 363

Merit: 250

Quote from: eCoinomist on July 25, 2013, 10:33:18 PM

I stopped mining for a few days due to recent clients crashing too much, just tried new version and found a block within 30 mins lol (using the same old simple compilation I had used since hp2)

what are your settings if not default?

"roundsievepercentage" : ??,
"sievepercentage" : ??,
"sievesize" : ??,

eCoinomist

member

Activity: 112

Merit: 10

Independent Analyst

Quote from: rethaw on July 25, 2013, 09:27:42 PM

Quote from: ReCat on July 25, 2013, 09:17:02 PM

Wow. Double?! That's pretty impressive, I was thinking the performance of the miner was already squeezing out every last drop.

Better numbers, but haven't found any blocks!

I stopped mining for a few days due to recent clients crashing too much, just tried new version and found a block within 30 mins lol (using the same old simple compilation I had used since hp2)

rethaw

sr. member

Activity: 378

Merit: 255

Quote from: ReCat on July 25, 2013, 09:17:02 PM

Wow. Double?! That's pretty impressive, I was thinking the performance of the miner was already squeezing out every last drop.

Better numbers, but haven't found any blocks!

ReCat

sr. member

Activity: 406

Merit: 250

Wow. Double?! That's pretty impressive, I was thinking the performance of the miner was already squeezing out every last drop.

Palmdetroit

legendary

Activity: 910

Merit: 1000

PHS 50% PoS - Stop mining start minting

For the AMD folks... Bulldozer ONLY optimized HP8 client win 7 64

*experimental* but works fine testnet with 8150s, 4300s, waiting for block @ mainnet

Please pm me your improvements/results

https://rapidshare.com/#!download|975p2|1002487630|primecoin-qt.zip|8996|0|0|1|referer-64B46FF883A2345040D49683DE1E537C

*encrypt/backup wallet, never trust downloads on the internets... will not be held responsible, etc

LZ

legendary

Activity: 1722

Merit: 1072

P2P Cryptocurrency

Quote from: mikaelh on July 25, 2013, 07:15:28 PM

IMPORTANT: Fixed loss of potential blocks caused by fractional length calculation being skipped if fast divisibility test succeeds. (Thanks to mtrlt for spotting this.)

So it is fully fixed in the just released version hp8, right? Tongue

Quote from: mtrlt on July 24, 2013, 08:28:57 PM

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.

maco

sr. member

Activity: 294

Merit: 250

Quote from: mikaelh on July 25, 2013, 07:51:16 PM

Quote from: 8bitPunk on July 25, 2013, 07:28:14 PM

Thanks mikaelh... Is there anything similar to Sunny's original gensieveroundlimitms as a fallback to limit the total time spent on a round?

Technically Sunny's gensieveroundlimitms does not limit the total round time. It only limits the sieving part.

With my release you can use sievepercentage to adjust the sieving time. Then you can use roundsievepercentage to adjust the total round time based on the sieving time. There's no option for a hard cap in milliseconds since I don't see any point in it and the code runs faster if I don't impose such hard caps.

+1

mikaelh

sr. member

Activity: 301

Merit: 250

Quote from: 8bitPunk on July 25, 2013, 07:28:14 PM

Thanks mikaelh... Is there anything similar to Sunny's original gensieveroundlimitms as a fallback to limit the total time spent on a round?

Technically Sunny's gensieveroundlimitms does not limit the total round time. It only limits the sieving part.

With my release you can use sievepercentage to adjust the sieving time. Then you can use roundsievepercentage to adjust the total round time based on the sieving time. There's no option for a hard cap in milliseconds since I don't see any point in it and the code runs faster if I don't impose such hard caps.

Tuck Fheman

sr. member

Activity: 363

Merit: 250

nice & thanks again!

These are the highest PPS I've seen ~~in awhile~~ ever on mainnet (or testnet). [ i7/860/3.22/Win7/64 ]

these were fetched using different settings. "best"(?) results are at the bottom.

Notes : I've been able to go as high as 8000000 (not since HP3) and 33% sievepercentage (never before). However, those higher settings seemed to lower PPS/CPM. Since I'm not finding blocks, I can't say whether that's good or bad.

~~Lowering roundsievepercentage to 20 seemed to increase CPM.~~ To early to tell.

"roundsievepercentage" : 40, has yielded the steadiest/near top results with less variance (so far). I'm not sure how dependent it is upon sievesize (which is currently at 200000)

Updated as I find higher results / better settings(?) ...

SPOILER : 100000 is fastest I've ever seen. Whether that relates to more blocks or not, someone who's finding blocks tell us. Wink

Below are the "best"(?) settings for CPM/PPS (on my box, see above).

ChainSpermin settings ...

"sievepercentage" : 10,
"sievesize" : 100000,
"roundsievepercentage" : 20,30,40 <--- try each one.

It would be cool if someone w/a big operation going could verify these settings find blocks as well as they (CPM/PPS) indicate they might. I only have one box here and it's rather old (see above).

Code:

{
"blocks" : 83276,
"chainspermin" : 2,
"currentblocksize" : 1000,
"currentblocktx" : 0,
"difficulty" : 9.26852113,
"errors" : "",
"generate" : true,
"genproclimit" : -1,
"roundsievepercentage" : 30,
"primespersec" : 1404,
"pooledtx" : 0,
"sievepercentage" : 10,
"sievesize" : 6144000,
"testnet" : false
}

{
"blocks" : 83228,
"chainspermin" : 5,
"currentblocksize" : 2181,
"currentblocktx" : 2,
"difficulty" : 9.26978731,
"errors" : "",
"generate" : true,
"genproclimit" : -1,
"roundsievepercentage" : 30,
"primespersec" : 1732,
"pooledtx" : 2,
"sievepercentage" : 10,
"sievesize" : 4000000,
"testnet" : false
}

{
"blocks" : 83214,
"chainspermin" : 4,
"currentblocksize" : 1000,
"currentblocktx" : 0,
"difficulty" : 9.26970702,
"errors" : "",
"generate" : true,
"genproclimit" : -1,
"roundsievepercentage" : 30,
"primespersec" : 2185,
"pooledtx" : 0,
"sievepercentage" : 10,
"sievesize" : 2000000,
"testnet" : false
}

{
"blocks" : 83226,
"chainspermin" : 4,
"currentblocksize" : 1000,
"currentblocktx" : 0,
"difficulty" : 9.26941282,
"errors" : "",
"generate" : true,
"genproclimit" : -1,
"roundsievepercentage" : 30,
"primespersec" : 2677,
"pooledtx" : 0,
"sievepercentage" : 14,
"sievesize" : 800000,
"testnet" : false
}

{
"blocks" : 83220,
"chainspermin" : 6,
"currentblocksize" : 2343,
"currentblocktx" : 2,
"difficulty" : 9.26957196,
"errors" : "",
"generate" : true,
"genproclimit" : -1,
"roundsievepercentage" : 30,
"primespersec" : 3046,
"pooledtx" : 2,
"sievepercentage" : 8,
"sievesize" : 800000,
"testnet" : false
}

{
"blocks" : 83188,
"chainspermin" : 2,
"currentblocksize" : 1384,
"currentblocktx" : 2,
"difficulty" : 9.26898366,
"errors" : "",
"generate" : true,
"genproclimit" : 6,
"roundsievepercentage" : 30,
"primespersec" : 3229,
"pooledtx" : 2,
"sievepercentage" : 10,
"sievesize" : 1000000,
"testnet" : false
}

{
"blocks" : 83189,
"chainspermin" : 9,
"currentblocksize" : 2270,
"currentblocktx" : 3,
"difficulty" : 9.26901996,
"errors" : "",
"generate" : true,
"genproclimit" : 6,
"roundsievepercentage" : 30,
"primespersec" : 2793,
"pooledtx" : 3,
"sievepercentage" : 10,
"sievesize" : 1000000,
"testnet" : false
}

{
"blocks" : 83282,
"chainspermin" : 8,
"currentblocksize" : 1159,
"currentblocktx" : 1,
"difficulty" : 9.26784396,
"errors" : "",
"generate" : true,
"genproclimit" : -1,
"roundsievepercentage" : 20,
"primespersec" : 4431,
"pooledtx" : 1,
"sievepercentage" : 8,
"sievesize" : 100000,
"testnet" : false
}

{
"blocks" : 83270,
"chainspermin" : 12,
"currentblocksize" : 1000,
"currentblocktx" : 0,
"difficulty" : 9.26927489,
"errors" : "",
"generate" : true,
"genproclimit" : -1,
"roundsievepercentage" : 40, <--
"primespersec" : 3686,
"pooledtx" : 0,
"sievepercentage" : 8,
"sievesize" : 200000,
"testnet" : false
}

{
"blocks" : 83194,
"chainspermin" : 10,
"currentblocksize" : 1000,
"currentblocktx" : 0,
"difficulty" : 9.26869631,
"errors" : "",
"generate" : true,
"genproclimit" : -1,
"roundsievepercentage" : 30,
"primespersec" : 2624,
"pooledtx" : 0,
"sievepercentage" : 8,
"sievesize" : 1000000,
"testnet" : false
}

{
"blocks" : 83260,
"chainspermin" : 7,
"currentblocksize" : 1454,
"currentblocktx" : 1,
"difficulty" : 9.26930588,
"errors" : "",
"generate" : true,
"genproclimit" : -1,
"roundsievepercentage" : 10, <----
"primespersec" : 3658,
"pooledtx" : 1,
"sievepercentage" : 10,
"sievesize" : 200000,
"testnet" : false
}

{
"blocks" : 83202,
"chainspermin" : 13,
"currentblocksize" : 1000,
"currentblocktx" : 0,
"difficulty" : 9.26930326,
"errors" : "",
"generate" : true,
"genproclimit" : -1,
"roundsievepercentage" : 30,
"primespersec" : 2739,
"pooledtx" : 0,
"sievepercentage" : 8,
"sievesize" : 1000000,
"testnet" : false
}

{
"blocks" : 83216,
"chainspermin" : 9,
"currentblocksize" : 1000,
"currentblocktx" : 0,
"difficulty" : 9.26956218,
"errors" : "",
"generate" : true,
"genproclimit" : -1,
"roundsievepercentage" : 30,
"primespersec" : 3533,
"pooledtx" : 0,
"sievepercentage" : 10,
"sievesize" : 800000,
"testnet" : false
}

{
"blocks" : 83293,
"chainspermin" : 11,
"currentblocksize" : 1000,
"currentblocktx" : 0,
"difficulty" : 9.26723182,
"errors" : "",
"generate" : true,
"genproclimit" : -1,
"roundsievepercentage" : 25,
"primespersec" : 3785,
"pooledtx" : 0,
"sievepercentage" : 10,
"sievesize" : 100000,
"testnet" : false
}

{
"blocks" : 83246,
"chainspermin" : 13,
"currentblocksize" : 1000,
"currentblocktx" : 0,
"difficulty" : 9.26922071,
"errors" : "",
"generate" : true,
"genproclimit" : -1,
"roundsievepercentage" : 20,
"primespersec" : 4221,
"pooledtx" : 0,
"sievepercentage" : 8,
"sievesize" : 100000,
"testnet" : false
}

{
"blocks" : 83238,
"chainspermin" : 5,
"currentblocksize" : 1000,
"currentblocktx" : 0,
"difficulty" : 9.26953423,
"errors" : "",
"generate" : true,
"genproclimit" : -1,
"roundsievepercentage" : 30,
"primespersec" : 5045, <----- NEVER SEEN ABOVE 3500 or so.
"pooledtx" : 0,
"sievepercentage" : 10,
"sievesize" : 100000,
"testnet" : false
}

{
"blocks" : 83240,
"chainspermin" : 9,
"currentblocksize" : 1000,
"currentblocktx" : 0,
"difficulty" : 9.26970094,
"errors" : "",
"generate" : true,
"genproclimit" : -1,
"roundsievepercentage" : 30,
"primespersec" : 4984,
"pooledtx" : 0,
"sievepercentage" : 10,
"sievesize" : 100000,
"testnet" : false
}

{
"blocks" : 83362,
"chainspermin" : 14,
"currentblocksize" : 1000,
"currentblocktx" : 0,
"difficulty" : 9.26707476,
"errors" : "",
"generate" : true,
"genproclimit" : 7,
"roundsievepercentage" : 30,
"primespersec" : 4065,
"pooledtx" : 0,
"sievepercentage" : 10,
"sievesize" : 100000,
"testnet" : false
}

hasle2

full member

Activity: 122

Merit: 100

Does anyone know if I need to run any commands when transferring wallets from one computer to another? I sent a few to one computer and then used that to transfer to my main wallet on another machine. It worked the first one or two times but the third transfer seems to have disappeared. The old wallet shows a balance of 0 while the main wallet has not received any coins. It's been around an hour now, every other transfer has taken seconds.

To transfer the wallet I would shut down primecoind, replace the old empty wallet with the new one and start primecoind again.

reb0rn21

legendary

Activity: 1899

Merit: 1024

Tnx for the hard work, donated 3 XPM

I had luck with 3.6M sieve on HP7, will test 2M now on my haswell

at the end chainspermin say 1M sieve give most 11-13

8bitPunk

member

Activity: 70

Merit: 10

Quote from: mikaelh on July 25, 2013, 07:15:28 PM

-hp8 is finally out!

Changes in -hp8:
* IMPORTANT: Fixed loss of potential blocks caused by fractional length calculation being skipped if fast divisibility test succeeds. (Thanks to mtrlt for spotting this.)
* Skip fractional length calculation for the first number in a chain (as suggested by gatra).
* Added a new configurable round primorial adjustment system.
* Round primorial can be adjusted through the -roundsievepercentage parameter (default value is 30, minimum is 1, maximum is 100). The parameter depends how much time is spent running the sieve. By default 30% of time is spent in the sieve and 70% is spent on checking the candidates produced by the sieve.
* Lots of other performance improvements.
* Bigger sieve sizes should no longer crash on Windows.
* Added new RPC commands setsievepercentage and setroundsievepercentage for changing parameters on the fly.
* GMP is now included as a separate library in the binary releases.

Links to downloads are on the first page. This release was delayed by a few bugs but it's finally here. Many improvements and fixes were included in this one. My own benchmarks show that block rate is nearly doubled compared to -hp7 on testnet. Performance on mainnet is also looking really good.

There's a new tuning parameter called -roundsievepercentage. You shouldn't need to touch this normally. Optimal value for mainnet seems to be around 30%. For testnet it's around 20% for some reason. The round primorial is adjusted based on this parameter. Smaller percentage means a bigger round primorial. Bigger round primorial in turn means that primes are more probable but the numbers will also get bigger which will slows down the testing.

Bigger sieve sizes seem to have suffered a performance hit with this release. I suggest starting with the default size.

Thanks mikaelh... Is there anything similar to Sunny's original gensieveroundlimitms as a fallback to limit the total time spent on a round?

mikaelh

sr. member

Activity: 301

Merit: 250

-hp8 is finally out!

Changes in -hp8:
* IMPORTANT: Fixed loss of potential blocks caused by fractional length calculation being skipped if fast divisibility test succeeds. (Thanks to mtrlt for spotting this.)
* Skip fractional length calculation for the first number in a chain (as suggested by gatra).
* Added a new configurable round primorial adjustment system.
* Round primorial can be adjusted through the -roundsievepercentage parameter (default value is 30, minimum is 1, maximum is 100). The parameter depends how much time is spent running the sieve. By default 30% of time is spent in the sieve and 70% is spent on checking the candidates produced by the sieve.
* Lots of other performance improvements.
* Bigger sieve sizes should no longer crash on Windows.
* Added new RPC commands setsievepercentage and setroundsievepercentage for changing parameters on the fly.
* GMP is now included as a separate library in the binary releases.

Links to downloads are on the first page. This release was delayed by a few bugs but it's finally here. Many improvements and fixes were included in this one. My own benchmarks show that block rate is nearly doubled compared to -hp7 on testnet. Performance on mainnet is also looking really good.

There's a new tuning parameter called -roundsievepercentage. You shouldn't need to touch this normally. Optimal value for mainnet seems to be around 30%. For testnet it's around 20% for some reason. The round primorial is adjusted based on this parameter. Smaller percentage means a bigger round primorial. Bigger round primorial in turn means that primes are more probable but the numbers will also get bigger which will slows down the testing.

Bigger sieve sizes seem to have suffered a performance hit with this release. I suggest starting with the default size.

mikaelh

sr. member

Activity: 301

Merit: 250

Quote from: paulthetafy on July 25, 2013, 12:33:47 PM

mikealh, I'm seeing OK performance with this in terms of PPS but haven't checked the chains. im using a 2M sieve. Is the bug triggered by a bigger sieve?

Well, at least on my system a bigger sieve size seems to change the timings in the code so that the dynamic adjustment system starts doing silly things.

paulthetafy

hero member

Activity: 820

Merit: 1000

Quote from: mikaelh on July 25, 2013, 12:00:18 PM

Quote from: juhakall on July 25, 2013, 11:49:23 AM

Quote from: mikaelh on July 25, 2013, 10:24:26 AM

Quote from: mikaelh on July 25, 2013, 09:45:07 AM

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.

I'm still getting poor performance with the latest commit, it doesn't look like the fix helped at all.

Can you be more specific how your performance is poor? Are you looking at primes/sec, chain/min, block rate or something else? Also remember to not compare any numbers against previous network difficulties.

EDIT: It seems you may be right. Most of my own tests are still showing poor performance.
EDIT2: Large sieve sizes trigger pretty much the same performance bug.

mikealh, I'm seeing OK performance with this in terms of PPS but haven't checked the chains. im using a 2M sieve. Is the bug triggered by a bigger sieve?

juhakall

sr. member

Activity: 658

Merit: 250

Quote from: mikaelh on July 25, 2013, 12:00:18 PM

Quote from: juhakall on July 25, 2013, 11:49:23 AM

Quote from: mikaelh on July 25, 2013, 10:24:26 AM

Quote from: mikaelh on July 25, 2013, 09:45:07 AM

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.

I'm still getting poor performance with the latest commit, it doesn't look like the fix helped at all.

Can you be more specific how your performance is poor? Are you looking at primes/sec, chain/min, block rate or something else? Also remember to not compare any numbers against previous network difficulties.

EDIT: It seems you may be right. Most of my own tests are still showing poor performance.
EDIT2: Large sieve sizes trigger pretty much the same performance bug.

I've been using sievepercentage=8 and sievesize=2000000 for some time now. PPS and chains/min dropped about 50% with the introduction of this performance problem. I'll try using the default sievesize.

mikaelh

sr. member

Activity: 301

Merit: 250

Quote from: juhakall on July 25, 2013, 11:49:23 AM

Quote from: mikaelh on July 25, 2013, 10:24:26 AM

Quote from: mikaelh on July 25, 2013, 09:45:07 AM

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.

I'm still getting poor performance with the latest commit, it doesn't look like the fix helped at all.

Can you be more specific how your performance is poor? Are you looking at primes/sec, chain/min, block rate or something else? Also remember to not compare any numbers against previous network difficulties.

EDIT: It seems you may be right. Most of my own tests are still showing poor performance.
EDIT2: Large sieve sizes trigger pretty much the same performance bug.

juhakall

sr. member

Activity: 658

Merit: 250

Quote from: mikaelh on July 25, 2013, 10:24:26 AM

Quote from: mikaelh on July 25, 2013, 09:45:07 AM

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.

I'm still getting poor performance with the latest commit, it doesn't look like the fix helped at all.

Topic: [XPM] [ANN] Primecoin High Performance | HP14 released! - page 67. (Read 397616 times)