Bitcoin Forum
July 21, 2018, 07:57:53 PM *
News: Latest stable version of Bitcoin Core: 0.16.1  [Torrent]. (New!)
 
   Home   Help Search Donate Login Register  
Pages: « 1 ... 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 [66] 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 ... 133 »
  Print  
Author Topic: [XPM] [ANN] Primecoin High Performance | HP14 released!  (Read 395958 times)
mikaelh
Sr. Member
****
Offline Offline

Activity: 301
Merit: 250


View Profile
July 25, 2013, 04:00:18 PM
 #1301

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.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1532203073
Hero Member
*
Offline Offline

Posts: 1532203073

View Profile Personal Message (Offline)

Ignore
1532203073
Reply with quote  #2

1532203073
Report to moderator
juhakall
Sr. Member
****
Offline Offline

Activity: 577
Merit: 250



View Profile WWW
July 25, 2013, 04:26:55 PM
 #1302

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.

Elitehash PPS Pools: Bitcore, Gincoin, Raven
paulthetafy
Hero Member
*****
Offline Offline

Activity: 815
Merit: 1000


View Profile
July 25, 2013, 04:33:47 PM
 #1303

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?

mikaelh
Sr. Member
****
Offline Offline

Activity: 301
Merit: 250


View Profile
July 25, 2013, 05:34:57 PM
 #1304

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.
mikaelh
Sr. Member
****
Offline Offline

Activity: 301
Merit: 250


View Profile
July 25, 2013, 11:15:28 PM
 #1305

-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.
8bitPunk
Member
**
Offline Offline

Activity: 70
Merit: 10



View Profile
July 25, 2013, 11:28:14 PM
 #1306

-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?

BTC 18bPunkuginRBm1Xz9mcgj8mWJnHDAW5Th | Ł LTCgXEdyBdoQ9WdF6JHi7Pa2EWtzbDjG76 | Ψ ATEBiTLkLpAYeW5hQknUfSvnb7Abbgegku
reb0rn21
Legendary
*
Online Online

Activity: 1442
Merit: 1000


View Profile
July 25, 2013, 11:32:31 PM
 #1307

Tnx for the hard work, donated 3 XPM Smiley

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

... PLAY SHARE EARN...
.LBRY...
                            __¦¦¦__
                        __¦¦¦¦¦¯¦¦¦¦¦__
                    __¦¦¦¦¦¯¯     ¯¯¦¦¦¦¦__
                __¦¦¦¦¦¯¯             ¯¯¦¦¦¦¦__
            __¦¦¦¦¦¯¯                     ¯¯¦¦¦¦¦__
        __¦¦¦¦¦¯¯                             ¯¯¦¦¦¦¦__
    __¦¦¦¦¦¯¯                                     ¯¯¦¦¦
__¦¦¦¦¦¯¯                                         __¦¦¦
¦¦¦¯¯                                         __¦¦¦¦¦¯¯
¦¦¦     ¦__                               __¦¦¦¦¦¯¯
¦¦¦     ¦¦¦¦¦__                       __¦¦¦¦¦¯¯  ________
¦¦¦       ¯¯¦¦¦¦¦__               __¦¦¦¦¦¯¯       ¦¦¦¦¦¦
¦¦¦¦¦__       ¯¯¦¦¦¦¦__       __¦¦¦¦¦¯¯       __¦¦¦¦¦¦¦
  ¯¯¦¦¦¦¦__       ¯¯¦¦¦¦¦___¦¦¦¦¦¯¯       __¦¦¦¦¦¯¯ ¦¦
      ¯¯¦¦¦¦¦__       ¯¯¦¦¦¦¦¯¯       __¦¦¦¦¦¯¯
          ¯¯¦¦¦¦¦__       ¯       __¦¦¦¦¦¯¯
              ¯¯¦¦¦¦¦__       __¦¦¦¦¦¯¯
                  ¯¯¦¦¦¦¦___¦¦¦¦¦¯¯
                      ¯¯¦¦¦¦¦¯¯
                          ¯
hasle2
Full Member
***
Offline Offline

Activity: 123
Merit: 100


View Profile
July 25, 2013, 11:37:38 PM
 #1308

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.
Tuck Fheman
Sr. Member
****
Offline Offline

Activity: 363
Merit: 250


View Profile WWW
July 25, 2013, 11:48:47 PM
 #1309

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
}






mikaelh
Sr. Member
****
Offline Offline

Activity: 301
Merit: 250


View Profile
July 25, 2013, 11:51:16 PM
 #1310

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.
maco
Sr. Member
****
Offline Offline

Activity: 294
Merit: 250



View Profile
July 26, 2013, 12:47:46 AM
 #1311

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
LZ
Legendary
*
Offline Offline

Activity: 1736
Merit: 1018


P2P Cryptocurrency


View Profile
July 26, 2013, 01:02:05 AM
 #1312

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

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.

Palmdetroit
Legendary
*
Offline Offline

Activity: 910
Merit: 1000


PHS 50% PoS - Stop mining start minting


View Profile
July 26, 2013, 01:10:08 AM
 #1313

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

ReCat
Sr. Member
****
Offline Offline

Activity: 406
Merit: 250



View Profile WWW
July 26, 2013, 01:17:02 AM
 #1314

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

BTC: 1recatirpHBjR9sxgabB3RDtM6TgntYUW
Hold onto what you love with all your might, Because you can never know when - Oh. What you love is now gone.
rethaw
Sr. Member
****
Offline Offline

Activity: 378
Merit: 250



View Profile
July 26, 2013, 01:27:42 AM
 #1315

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!

eCoinomist
Member
**
Offline Offline

Activity: 112
Merit: 10


Independent Analyst


View Profile WWW
July 26, 2013, 02:33:18 AM
 #1316

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)

Tuck Fheman
Sr. Member
****
Offline Offline

Activity: 363
Merit: 250


View Profile WWW
July 26, 2013, 02:47:52 AM
 #1317

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" : ??,


Dsfyu
Member
**
Offline Offline

Activity: 75
Merit: 10



View Profile
July 26, 2013, 02:54:49 AM
 #1318

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...

Don't just trade, get paid to Atomic⚛Trade !!!
Disclaimer: I am a noob. Assume I know nothing until proven otherwise.
AstroKev
Newbie
*
Offline Offline

Activity: 23
Merit: 0


View Profile
July 26, 2013, 03:01:07 AM
 #1319

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
}

martingale gambler bot: http://goo.gl/b4XsJ
Krusher33
Jr. Member
*
Offline Offline

Activity: 37
Merit: 0


View Profile
July 26, 2013, 03:07:04 AM
 #1320

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

How does this compare to hp8 in Linux.
Pages: « 1 ... 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 [66] 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 ... 133 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!