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

Dsfyu

member

Activity: 75

Merit: 10

Quote from: Pt0x on July 24, 2013, 10:24:52 PM

Quote from: Dsfyu on July 24, 2013, 10:12:05 PM

Quote from: Pt0x on July 24, 2013, 09:46:54 PM

Quote from: mtrlt on July 24, 2013, 07: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.

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.

Pt0x

sr. member

Activity: 266

Merit: 250

Quote from: Dsfyu on July 24, 2013, 10:12:05 PM

Quote from: Pt0x on July 24, 2013, 09:46:54 PM

Quote from: mtrlt on July 24, 2013, 07: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.

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.

Dsfyu

member

Activity: 75

Merit: 10

Quote from: Pt0x on July 24, 2013, 09:46:54 PM

Quote from: mtrlt on July 24, 2013, 07: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.

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?

maco

sr. member

Activity: 294

Merit: 250

Quote from: blackboy on July 24, 2013, 07:19:26 PM

It does up to 100 blocks. There was a detailed post at the beginning of this thread regarding that very subject.

you talking about this: https://bitcointalksearch.org/topic/m.2725864 ??

Pt0x

sr. member

Activity: 266

Merit: 250

According to the first post:

Changes in -hp6:
* Added fast divisibility tests before doing the expensive Fermat's test

I guess by just reverting to hp5 we can get around the bug while hp8 appears online.

Quote from: maco on July 24, 2013, 09:45:42 PM

So do we have to wait for the next update to get this problem solved?

Quote from: 8bitPunk on July 24, 2013, 08:07:36 PM

Quote from: mtrlt on July 24, 2013, 07: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.

Thanks mtrlt... the code you copied is all the commits up to the tag 'v0.1.1xpm-hp7' or including more recent commits in the last 16 hours?

Mikaelh has been changing this section of the code to avoid calculating the fractional part when the chain length was insufficient to pass the difficulty. e.g. commit 64528eb & 27c3cdf

Pt0x

sr. member

Activity: 266

Merit: 250

Quote from: mtrlt on July 24, 2013, 07: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.

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.

maco

sr. member

Activity: 294

Merit: 250

So do we have to wait for the next update to get this problem solved?

Quote from: 8bitPunk on July 24, 2013, 08:07:36 PM

Quote from: mtrlt on July 24, 2013, 07: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.

Thanks mtrlt... the code you copied is all the commits up to the tag 'v0.1.1xpm-hp7' or including more recent commits in the last 16 hours?

Mikaelh has been changing this section of the code to avoid calculating the fractional part when the chain length was insufficient to pass the difficulty. e.g. commit 64528eb & 27c3cdf

nmersulypnem

full member

Activity: 238

Merit: 100

Any chance we can get some x64 windows binaries with the latest changes (those after hp7)? I haven't been able to build on windows (something with my MingW build is not binding the static libraries).

mtrlt

member

Activity: 104

Merit: 10

Only up to the tag. But it seems the recent commits haven't had the bug fixed.

8bitPunk

member

Activity: 70

Merit: 10

Quote from: mtrlt on July 24, 2013, 07: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.

Thanks mtrlt... the code you copied is all the commits up to the tag 'v0.1.1xpm-hp7' or including more recent commits in the last 16 hours?

Mikaelh has been changing this section of the code to avoid calculating the fractional part when the chain length was insufficient to pass the difficulty. e.g. commit 64528eb & 27c3cdf

mtrlt

member

Activity: 104

Merit: 10

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.

blackboy

member

Activity: 109

Merit: 16

It does up to 100 blocks. There was a detailed post at the beginning of this thread regarding that very subject.

maco

sr. member

Activity: 294

Merit: 250

Has anyone tried using the same wallet across all mining servers? does it work?

Stinky_Pete

hero member

Activity: 560

Merit: 500

Quote from: Dsfyu on July 24, 2013, 02:07:17 PM

Quote from: Stinky_Pete on July 24, 2013, 11:56:51 AM

Still getting new blocks mined on my i7-970 Gulftown at 3.2GHz (2 today, 2 yesterday). Maturing seem to take at least 48 hours, so I'm guessing a lot of machines have dropped out of the network.

What settings are you using and how many primes per second are you getting? I'm mining on my 3930k and get anything from 4k to 5700 primes per sec and have only gotten one block in three days of mining.

{
"blocks" : 81752,
"chainspermin" : 0,
"currentblocksize" : 1000,
"currentblocktx" : 0,
"difficulty" : 9.27018213,
"errors" : "",
"generate" : true,
"genproclimit" : -1,
"primespersec" : 0,
"pooledtx" : 0,
"sievepercentage" : 10,
"sievesize" : 1000000,
"testnet" : false
}

mhps

hero member

Activity: 516

Merit: 500

CAT.EX Exchange

Quote from: gigawatt on July 24, 2013, 02:41:09 PM

With hash based coins, the question is simply "if I throw dice with X sides, what's the odds I'll get a number lower than [difficulty]".
With primecoin, the question is "what's the odds that I'll find a chain of primes [difficulty] numbers long, with the next number not being prime and having a remainder greater than [difficulty]".

I won't be surprised if with all the chains that have been found, patterns have already been found and the patterns have been used to take advantage in mining.

wibtc

newbie

Activity: 32

Merit: 0

Four desktops found nothing for 3 days.
Does the Primecoin client support pool mining now? thx

Tuck Fheman

sr. member

Activity: 363

Merit: 250

For comparison, these are my current stats w/HP7 on i7 860 @ 3.22 Win7/64

{
"blocks" : 81643,
"chainspermin" : 15,
"currentblocksize" : 1000,
"currentblocktx" : 0,
"difficulty" : 9.26953751,
"errors" : "",
"generate" : true,
"genproclimit" : 4,
"primespersec" : 2026,
"pooledtx" : 0,
"sievepercentage" : 8,
"sievesize" : 2000000,
"testnet" : false
}

{
"blocks" : 81626,
"chainspermin" : 7,
"currentblocksize" : 1000,
"currentblocktx" : 0,
"difficulty" : 9.26957542,
"errors" : "",
"generate" : true,
"genproclimit" : 4,
"primespersec" : 2437,
"pooledtx" : 0,
"sievepercentage" : 8,
"sievesize" : 2000000,
"testnet" : false
}

{
"blocks" : 81707,
"chainspermin" : 8,
"currentblocksize" : 1000,
"currentblocktx" : 0,
"difficulty" : 9.27111542,
"errors" : "",
"generate" : true,
"genproclimit" : 6,
"primespersec" : 2307,
"pooledtx" : 0,
"sievepercentage" : 8,
"sievesize" : 2000000,
"testnet" : false
}

I don't really see much improvement using all threads, in fact I'd have to say I see less CPM when doing so. It appears I see higher CPM when using 4.

My experience since 7/17 has been ... mining primecoin with one cpu is like being in a really unlucky PPLNS pool.

8bitPunk

member

Activity: 70

Merit: 10

Quote from: fredeq on July 24, 2013, 05:02:52 PM

No block for 2 days on Xeon e5 3,7 Ghz, decided to go ypool...

Btw while hp7 shows around 3800 primes/s, the ypool miner shows 8000 primes/s. Maybe I should not compare, dunno.

YPool is interesting in that they are finding 5% of the blocks which appears consistent with their stats page ~3/hour

If we could estimate the total number of miner nodes in the primecoin network then we could establish whether the 3000 workers are more or less 5% of the total network.

I suspect that the ypool miner performance is worse, but the aggregated effect of the pool is helping to avoid orphan blocks.

rahlquist

newbie

Activity: 46

Merit: 0

Quote from: mikaelh on July 24, 2013, 08:30:30 AM

Oh yeah, there are still the glibc and libstdc++ dependencies. Those are quite hard to get rid of. For now your best option is probably to compile it yourself. You can try taking a few pointers from my guide here:
https://bitcointalksearch.org/topic/xpm-primecoin-high-performance-linux-compilation-guide-259022

That only shows how to compile the daemon though. You'll need to install the Qt development packages in addition to compile the Qt client.

Thanks for the help. The incompatibility here and with another key app caused me to dump Cent and go with Fedora 19. Getting 2608pps on my new server rig ( amd FX-6300 based) now with your client.

Not bad for a sub $450 server.

8bitPunk

member

Activity: 70

Merit: 10

Quote from: Dsfyu on July 24, 2013, 04:22:36 PM

Quote from: 8bitPunk on July 24, 2013, 04:05:47 PM

mikaelh has been hard at work optimizing the code (10 new commits on bitbucket)

After an hour running this on mainnet I'm seeing consistently higher pps and chainspermin than with hp7 on an identical box

I think it's time for another round of donations to keep mikaelh going

How much higher are you seeing? I would donate in primecoin now but I only mined my first block yesterday and it still is immature - it's going to be at least another day before I am able to use the coins.

Current mining info from the box compiled from the latest code:

Code:

{
    "blocks" : 81661,
    "chainspermin" : 10,
    "currentblocksize" : 10284,
    "currentblocktx" : 1,
    "difficulty" : 9.26995111,
    "errors" : "",
    "generate" : true,
    "genproclimit" : -1,
    "primespersec" : 2995,
    "pooledtx" : 1,
    "sievepercentage" : 11,
    "sievesize" : 4400000,
    "testnet" : false
}

and mining info from the box running hp7:

Code:

{
    "blocks" : 81663,
    "chainspermin" : 7,
    "currentblocksize" : 1000,
    "currentblocktx" : 0,
    "difficulty" : 9.26969045,
    "errors" : "",
    "generate" : true,
    "genproclimit" : -1,
    "primespersec" : 2010,
    "pooledtx" : 0,
    "sievepercentage" : 11,
    "sievesize" : 4400000,
    "testnet" : false
}

PPS and CPM fluctuate on both boxes, but the newest code is performing ~30% better based on the stats. It's hard to tell what improvement this would translate to in finding blocks.

I'm wary of comparisons between testnet and mainnet - due to the difference in difficulty, some optimizations might never get used on testnet while they are in constant use in mainnet because of the higher difficulty.

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