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

Ifaistos

newbie

Activity: 18

Merit: 0

Quote from: Trillium on September 14, 2013, 04:02:55 AM

While I can't answer your question re cache optimization, I can tell you that those CPU's wont break even against electricity costs unless you have almost-free or free electricity. I have a pile of 10 rackmount servers behind me with those kinds of CPU (release dates roughly 2003 - 2007) and they're simply not worth mining on. An i7 4770k is about as fast of ten of those older single core xeons and only uses <120 watts even before you overclock it.

My work laptop (i5-560M) gets 0.8 chainsperday and uses 40 watts from the wall, it's faster than about 500 watts of my old rackmount servers (not to mention essentially silent and 1/100th the size).

You are right that it does not make sense without free electricity given current difficulty and price ~0.30$

I measured them with a Voltcratf energy logger at around 300W with both cpus and hyperthreading on, running H10
With the 'old' H10 they do around 0.3 cpd, with the version from github goes down to 0.22
So doing the math gives us

block/day = (1 - 0.86185294 ) * 0.22924828 = 0.031669976 which is around 1 block every 30 days
12 xpm * 0.30$ =3.6$/month

power consumption

330W = 7.92 Kw/h a day = 237.6 Kw/h per month

so to *break even* (no profit) you need an electricity price of less than 0.015 Kw/h (237.6/3.6) and without factoring in things like cooling,internet connection etc.

If on the other hand if you don't have to pay for any of the running costs with 10 machines and current prices you could get around 36$/month from some piece of junk equipment lol

Carra23

legendary

Activity: 980

Merit: 1000

Need a campaign manager? PM me

I have been continuously mining from day 1. I have never optimized anything, and just run the qt with setgenerate true. Is there anything I can do to improve?

peoplecoin

newbie

Activity: 24

Merit: 0

I heard that someone sell new block hashes?

Trillium

hero member

Activity: 546

Merit: 500

Quote from: Ifaistos on September 13, 2013, 05:34:09 PM

I've spend the day yesterday going over this thread (all 113 pages of it Roll Eyes

) trying to figure out optimal settings.
(People mention several times in the thread that the defaults are pretty much the best settings)
I have a number of old dual Xeon 3.4Ghz servers with 16k L1 and 1MB L2 and 2GB ram and i am not sure if the defaults are actually the best option for them, as newer cpu's have much bigger L1 and L2 caches.

As far as i understood without going over the code, sievesize is the pool of primes we look at, sievepercentage is the % of the numbers we look from the sieve for candidates for the chains.
I am not sure what the sieveextensions parameter means (there was a mention but can't locate it)
What is not clear to me and i would be great full if someone could explain, is how sievesize translates to actual memory footprint ?
Cause i believe that if that does not fit in the L2 cache things would slow down considerable (then again i might be wrong)

Thanks for your time

While I can't answer your question re cache optimization, I can tell you that those CPU's wont break even against electricity costs unless you have almost-free or free electricity. I have a pile of 10 rackmount servers behind me with those kinds of CPU (release dates roughly 2003 - 2007) and they're simply not worth mining on. An i7 4770k is about as fast of ten of those older single core xeons and only uses <120 watts even before you overclock it.

My work laptop (i5-560M) gets 0.8 chainsperday and uses 40 watts from the wall, it's faster than about 500 watts of my old rackmount servers (not to mention essentially silent and 1/100th the size).

Ifaistos

newbie

Activity: 18

Merit: 0

I've spend the day yesterday going over this thread (all 113 pages of it Roll Eyes

) trying to figure out optimal settings.
(People mention several times in the thread that the defaults are pretty much the best settings)
I have a number of old dual Xeon 3.4Ghz servers with 16k L1 and 1MB L2 and 2GB ram and i am not sure if the defaults are actually the best option for them, as newer cpu's have much bigger L1 and L2 caches.

As far as i understood without going over the code, sievesize is the pool of primes we look at, sievepercentage is the % of the numbers we look from the sieve for candidates for the chains.
I am not sure what the sieveextensions parameter means (there was a mention but can't locate it)
What is not clear to me and i would be great full if someone could explain, is how sievesize translates to actual memory footprint ?
Cause i believe that if that does not fit in the L2 cache things would slow down considerable (then again i might be wrong)

Thanks for your time

Ifaistos

newbie

Activity: 18

Merit: 0

pulled the code from github and build it
cpd wend from 0.30 to 0.19 no idea about block finds though, as i started yesterday with H10 on 5 similar machines (old dual xeon servers)

{
"blocks" : 163249,
"chainspermin" : 1,
"chainsperday" : 0.19348673,
"currentblocksize" : 1000,
"currentblocktx" : 0,
"difficulty" : 9.86140740,
"errors" : "",
"generate" : true,
"genproclimit" : -1,
"primespersec" : 380,
"pooledtx" : 0,
"sieveextensions" : 9,
"sievepercentage" : 10,
"sievesize" : 1000000,
"testnet" : false
}

mikaelh

sr. member

Activity: 301

Merit: 250

Well, I pushed the fix for the big bug to github. I'm also changing the default value of 'sieveextensions' to 9. That seems to be the new sweet spot now that the bug in the sieve is fixed. If all goes well, I will probably do a release some time tomorrow.

cabin

sr. member

Activity: 604

Merit: 250

Quote from: mikaelh on September 13, 2013, 01:26:18 PM

Quote from: cabin on September 13, 2013, 12:20:48 PM

Mikael: in the below code block should it be nLayerSeq < nBiTwinCC2Layers or nLayerSeq < nBiTwinCC1Layers? It looks like it should be a 1, and rdebourbon made this change in his miner, but it seems the chains/d drop when I do this.. so curious if you knew what was going on there. The double check in the first if statement seems redundant too.

Code:

                if (nLayerSeq < nBiTwinCC1Layers && nLayerSeq < nBiTwinCC2Layers)
                {
                    for (unsigned int nWord = nMinWord; nWord < nMaxWord; nWord++)
                    {
                        vfCompositeCunningham1[nWord] |= vfCompositeLayerCC1[nWord];
                        vfCompositeCunningham2[nWord] |= vfCompositeLayerCC2[nWord];
                        vfCompositeBiTwin[nWord] |= vfCompositeLayerCC1[nWord] | vfCompositeLayerCC2[nWord];
                    }
                }
                else if (nLayerSeq < nBiTwinCC2Layers)

Well, the second if-statement should say nLayerSeq < nBiTwinCC1Layers. I read rdebourbon's release notes and saw the bug in the code earlier already.

And yes, the first if-statement could be simplified to nLayerSeq < nBiTwinCC2Layers since that implies nLayerSeq < nBiTwinCC1Layers, if that's what you meant.

The bug causes the sieve to produce BiTwin candidates for 8-chains instead of 9-chains on mainnet. That means there will be more TWN candidates but they are a lot less likely to produce blocks. More candidates means that more primality tests are done which in turn falsely inflates the chains/day estimate. Basically this is the big bug in HP10 that I've been looking for. Once the bug is fixed, the miner will be producing more blocks and chains/day will be a lot closer to reality.

Thanks, that clears things up!

mikaelh

sr. member

Activity: 301

Merit: 250

Quote from: cabin on September 13, 2013, 12:20:48 PM

Mikael: in the below code block should it be nLayerSeq < nBiTwinCC2Layers or nLayerSeq < nBiTwinCC1Layers? It looks like it should be a 1, and rdebourbon made this change in his miner, but it seems the chains/d drop when I do this.. so curious if you knew what was going on there. The double check in the first if statement seems redundant too.

Code:

                if (nLayerSeq < nBiTwinCC1Layers && nLayerSeq < nBiTwinCC2Layers)
                {
                    for (unsigned int nWord = nMinWord; nWord < nMaxWord; nWord++)
                    {
                        vfCompositeCunningham1[nWord] |= vfCompositeLayerCC1[nWord];
                        vfCompositeCunningham2[nWord] |= vfCompositeLayerCC2[nWord];
                        vfCompositeBiTwin[nWord] |= vfCompositeLayerCC1[nWord] | vfCompositeLayerCC2[nWord];
                    }
                }
                else if (nLayerSeq < nBiTwinCC2Layers)

Well, the second if-statement should say nLayerSeq < nBiTwinCC1Layers. I read rdebourbon's release notes and saw the bug in the code earlier already.

And yes, the first if-statement could be simplified to nLayerSeq < nBiTwinCC2Layers since that implies nLayerSeq < nBiTwinCC1Layers, if that's what you meant.

The bug causes the sieve to produce BiTwin candidates for 8-chains instead of 9-chains on mainnet. That means there will be more TWN candidates but they are a lot less likely to produce blocks. More candidates means that more primality tests are done which in turn falsely inflates the chains/day estimate. Basically this is the big bug in HP10 that I've been looking for. Once the bug is fixed, the miner will be producing more blocks and chains/day will be a lot closer to reality.

ReCat

sr. member

Activity: 406

Merit: 250

Well, I mined for 4 days straight using yPool's Win64 miner on my rack server, and all that it rewarded me is 0.2 XPM. :I

I could have mined a block in this time!

Fuck!

cabin

sr. member

Activity: 604

Merit: 250

Mikael: in the below code block should it be nLayerSeq < nBiTwinCC2Layers or nLayerSeq < nBiTwinCC1Layers? It looks like it should be a 1, and rdebourbon made this change in his miner, but it seems the chains/d drop when I do this.. so curious if you knew what was going on there. The double check in the first if statement seems redundant too.

Code:

if (nLayerSeq < nBiTwinCC1Layers && nLayerSeq < nBiTwinCC2Layers)
{
for (unsigned int nWord = nMinWord; nWord < nMaxWord; nWord++)
{
vfCompositeCunningham1[nWord] |= vfCompositeLayerCC1[nWord];
vfCompositeCunningham2[nWord] |= vfCompositeLayerCC2[nWord];
vfCompositeBiTwin[nWord] |= vfCompositeLayerCC1[nWord] | vfCompositeLayerCC2[nWord];
}
}
else if (nLayerSeq < nBiTwinCC2Layers)

mhps

hero member

Activity: 516

Merit: 500

CAT.EX Exchange

Quote from: binaryFate on September 13, 2013, 11:35:52 AM

Quote from: masterOfDisaster on September 13, 2013, 11:29:13 AM

Quote from: acoiner1 on September 13, 2013, 11:16:34 AM

Sadly, the difficulty level dropped and XPM price keeps dropping. If trend continues, the XPM market will crash.

Yeah, I remember when I shut down my dual 5850 GPU Bitcoin miner in June 2011, because the combination of difficulty and price didn't seem to pay out. I'm not 100% sure about the details, but approximately 1 BTC/day was simply not enough at rates around 3 USD/BTC.
The thing is: you never know what will happen in such complex environments. I don't say that XPM will rise because BTC did. But you will not be able to predict a crash as well Wink

One thing that can strongly support Primecoin is the fact that its proof-of-work might be useful.

But the mecanism that relates in primecoin the number of coins released per block to difficulty is absent in bitcoin.
Here we have a potentially reinforcing cycle: decrease of diff -> more coins created -> more coins to sell on market -> price drop -> less miners keep mining -> decrease of diff.

That potentially leads to sharp adjustments.

The cycle is perhaps less strong as you think. Because of improvement in miners, one of my computer is finding 6-chains as fast as all miners in the world did on the release day of XPM. The network difficulty will perhaps never go under 8 again because only about 200 today's miners are needed to sustain it. At diff=8 a block only has 50% XPMs than today. I estimate 2000 machines are needed to sustain diff=9. There won't be significantly more coins created per day because there is a floor to the difficulty. So I think for a long term analysis the improvement of miners (and Moore's law, as Sunny King points out) will be the driving factor.

binaryFate

legendary

Activity: 1484

Merit: 1003

Still wild and free

Quote from: masterOfDisaster on September 13, 2013, 11:29:13 AM

Quote from: acoiner1 on September 13, 2013, 11:16:34 AM

Sadly, the difficulty level dropped and XPM price keeps dropping. If trend continues, the XPM market will crash.

Yeah, I remember when I shut down my dual 5850 GPU Bitcoin miner in June 2011, because the combination of difficulty and price didn't seem to pay out. I'm not 100% sure about the details, but approximately 1 BTC/day was simply not enough at rates around 3 USD/BTC.
The thing is: you never know what will happen in such complex environments. I don't say that XPM will rise because BTC did. But you will not be able to predict a crash as well Wink

One thing that can strongly support Primecoin is the fact that its proof-of-work might be useful.

But the mecanism that relates in primecoin the number of coins released per block to difficulty is absent in bitcoin.
Here we have a potentially reinforcing cycle: decrease of diff -> more coins created -> more coins to sell on market -> price drop -> less miners keep mining -> decrease of diff.

That potentially leads to sharp adjustments.

Carra23

legendary

Activity: 980

Merit: 1000

Need a campaign manager? PM me

It may seem strange, but I am happy that price is dropping. I am still solomining so this should help.

masterOfDisaster

sr. member

Activity: 321

Merit: 250

Quote from: acoiner1 on September 13, 2013, 11:16:34 AM

Sadly, the difficulty level dropped and XPM price keeps dropping. If trend continues, the XPM market will crash.

Yeah, I remember when I shut down my dual 5850 GPU Bitcoin miner in June 2011, because the combination of difficulty and price didn't seem to pay out. I'm not 100% sure about the details, but approximately 1 BTC/day was simply not enough at rates around 3 USD/BTC.
The thing is: you never know what will happen in such complex environments. I don't say that XPM will rise because BTC did. But you will not be able to predict a crash as well Wink

One thing that can strongly support Primecoin is the fact that its proof-of-work might be useful.

acoiner1

newbie

Activity: 10

Merit: 0

Sadly, the difficulty level dropped and XPM price keeps dropping. If trend continues, the XPM market will crash.

redphlegm

sr. member

Activity: 246

Merit: 250

My spoon is too big!

I think something wonky is going on. I've got my rig running at 8.x chains per day but haven't found a block in 3 days now. Is this indicative of something amiss or is it likely just really shitty luck? I was pulling in 1-3 a day before and now it's just crickets. Sad

Default settings, by the way.

Trillium

hero member

Activity: 546

Merit: 500

Quote from: magnificat_mafia on September 10, 2013, 09:50:05 AM

It is a dual processor Xeon X5650. I think it should be performing better than this.

author=magnificat_mafia link=topic=255782.msg3114986#msg3114986 date=1378745514]
What are the best settings for Xeon processors? I'm running 2x 2.66 GHz Xeon's and getting pretty low chains per day:
{
   "blocks" : 157519,
   "chainspermin" : 10,
   "chainsperday" : 1.18470870,
   "currentblocksize" : 1000,
   "currentblocktx" : 0,
   "difficulty" : 9.86931497,
   "errors" : "",
   "generate" : true,
   "genproclimit" : -1,
   "primespersec" : 1754,
   "pooledtx" : 0,
   "sieveextensions" : 6,
   "sievepercentage" : 10,
   "sievesize" : 1000000,
   "testnet" : false

Yes something is wrong, those CPU's each get about ~7500+ on the passmark scores ( http://www.cpubenchmark.net/cpu_list.php )

I have a single Core 2 Quad Q9550 which gets up to 1.5 CPD yet it is only ~4000 in the passmark scores.

This might be a silly question, but are you sure that you are using the 64-bit version of HP10 and you have it running on all cores on both CPU?

crendore

sr. member

Activity: 363

Merit: 250

I'm looking forward to those Broadwell chips coming out at the end of this year:
http://www.intel.com/content/dam/www/public/us/en/documents/white-papers/ia-large-integer-arithmetic-paper.pdf

shoggot

member

Activity: 62

Merit: 10

{
"blocks" : 158941,
"chainspermin" : 33,
"chainsperday" : 4.23677822,
"currentblocksize" : 1521,
"currentblocktx" : 1,
"difficulty" : 9.86579484,
"errors" : "",
"generate" : true,
"genproclimit" : -1,
"primespersec" : 4397,
"pooledtx" : 1,
"sieveextensions" : 6,
"sievepercentage" : 10,
"sievesize" : 1000000,
"testnet" : false
}

2x e5645 with hp10

{
"blocks" : 158941,
"chainspermin" : 61,
"chainsperday" : 5.25560817,
"currentblocksize" : 1521,
"currentblocktx" : 1,
"difficulty" : 9.86579484,
"errors" : "",
"generate" : true,
"genproclimit" : -1,
"primespersec" : 5457,
"pooledtx" : 1,
"sieveextensions" : 6,
"sievepercentage" : 10,
"sievesize" : 1000000,
"testnet" : false
}

2x e5-2630 with hp10

{
"blocks" : 158943,
"chainspermin" : 16,
"chainsperday" : 1.47739306,
"currentblocksize" : 1000,
"currentblocktx" : 0,
"difficulty" : 9.86568880,
"errors" : "",
"generate" : true,
"genproclimit" : -1,
"primespersec" : 1538,
"pooledtx" : 0,
"sieveextensions" : 6,
"sievepercentage" : 10,
"sievesize" : 1000000,
"testnet" : false
}

1x e5620

there you have some xeon figures.

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