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

Here are the stats and calculations I get when hard coding the sieve size:

Diff: 9.96
Probability of finding a 10th chain link when you have a 9 chain and are sieving on 9-chains: 1 / ln(2^256) = 0.005635

Sieve Size 9:
9-chains per day: 0.54 (reported by miner)
10-chains per day: 0.54 * 0.005635 = 0.00304
block per day = 0.54*0.04 + 0.00304 = 0.025

Sieve Size 10
9-chains per day: 0.22 (reported by miner)
10-chains per day: 0.02 (reported by miner and inline with 0.22*0.095)
block per day: 0.22*0.04 + 0.02 = 0.029

Size 10 wins! But I welcome critique of these calcs..

That's definitely interesting if you are seeing increased block production when targeting length 10 instead of 9.

I'm aware that the distribution of the fractional remainder isn't really uniform. That's one major issue which may be screwing up my calculations. I'll need to check how big the impact is at some point. I'll also need to double check my earlier calculations too. I have already accounted for the fact that lots of 9-chains are found when targeting length 10. In fact, I assumed that ten times more 9-chains are found than 10-chains when targeting length 10.


I would argue that the difficulty increase to the 9.3 range was caused by the momentum left after the transition to 9.0. The block rate was about 1.5 blocks/minute on July 22 after the transition to 9.0. Cutting that rate by 1/3 brings it to the target rate of 1 block/min. The difficulty rising to about 9.3 does just that. The chart also shows that the block rate was about 3.0 blocks/minute before the transition. That means that going from 8.996 to 9.0 somehow seems to have cut the block rate in half.


I looked at the fractional remainder a while back. I remember seeing a large number of 0xFFFFFF (this is the 24-bit version of the fractional difficulty) values which should statistically be nearly impossible (if you wanted to assume that it would be uniformly distributed).

This one is an open question for me.. but I think it might be working against us. I see an abnormal number of 9.99999 chains and never see the corresponding 9.000001 chains. But the possible reasons behind that are over my head, other than it is non-linear.



Yup, as long as the network grows going from 10.0 to 10.4 (not even double the difficulty) will be a piece of cake and really quick, compared to going from say 9.80 to 9.95 (almost 4 times the difficulty).

I agree. My pool miner has already auto re-targeted to 10 (unless manually overridden), and I'm finding that the block rate is marginally better than if targeting the current network difficulty.. As I'm sure you're aware the difficulty calculation is not perfectly linear, so while the fractional part appears to indicate only 4% of 9ch's are valid now, it is actually less than 4% that is valid at the moment..

On the positive side, the step up to a target of 10.0 comes with a decent reduction in primes needed for sieving, as well each sieve returns fewer candidates for primality testing - so the raw number of candidates sieved/tested per second increases quite nicely.. This increased speed and the fact that *any* 10.0+ is currently a block solver makes it worth the switch IMO.. The way the pool miners work is that if a chain less than target but greater than submission difficulty is found the "share" is submitted.. In this instance, when solo mining with the pool miners the target can be set to 10, and while that sieves away a good percentage of the 9ch's.. it leaves enough for you to still encounter some block solving chains in the 9ch range..

Also, if you look at the difficulty charts from a historical perspective, once a target length is breeched the network difficulty quickly increases to the x.3-x.4 range - and I expect this to be the case with 10 as well..

I actually think 10.0 will be a bit 'easier' than 9.99. The reason is the stock miner will have finally switched to searching for 10-chains in the sieve and it will find a few more 10 chains than when it was searching for 9-chains. Once the diff passes .96 I think it is better to search for 1-higher chains. The biggest factor is just the nature of division though.. going from 9.0 to 9.5 cuts in half the number of 9-chain-blocks you will find (from 100% to 50%). But so does going from 9.98 to 9.99 (from 2% to 1%)

Yes, my original formula here actually wasn't accurate for high fractional difficulties. The issue boils down to the probability of the 10th number being prime. I thought that the probability would be negligible but actually it is about 3.5% according to my estimates (this number depends on the primorial used during mining). That means that about 3.5% of 9+-chains turn out to be 10-chains (9+-chains refers to chains at least of length 9). As the fractional difficulty increases, the number of accepted 9-chains diminishes while the 10-chains remain unaffected. Eventually there will be more 10-chains qualifying for blocks than 9-chains.

So my latest estimate for the amount of blocks found is:
blocks/day = chains/day * (1 - fracDiff + 0.035)

There will be a jump in the difficulty when difficulty goes to 10.0. That's because none of the 9-chains will qualify for blocks and we have to start looking for 10+-chains. I've actually been working on a paper related to this. Right now it looks like 10.0 will be more difficult than 9.996 will be which means we could get stuck between 9.996 and 10.0 for a while.

You can actually see that happening before in my charts:
http://xpm.muuttuja.org/charts/

If you look closely enough, the network block rate seems to have dropped when we went from 8.996 to 9.0. Of course we were using an older version of the mining algorithm back then which probably behaved slightly different.

How much CPU power do you use?

I think it is mistake, because  longer (>9) length chains are ignored when the block-found probability  is calculated. See http://www.peercointalk.org/index.php?topic=695.msg6311#msg6311
If the longer chains are included, there is no jump in block-found difficulty when the network difficulty goes over an integer limit.

Yes. the fractional difficulty is currently very high (.96 or more) This means only 4% or less of the chains suggested by the chainsperday value would be accepted by the network.

If my understanding is correct, when we hit 10.000 diff, then the chainsperday value will change to a much lower number since its related directly to the whole integer value of the difficulty.

If you only have one (or a small few) machines then you probably wont see a block each day anymore.

This has come up in previous pages. The answer is: its complicated, and difficult to achieve.

The calculations to estimate your XPM per day have been discussed quite a bit by mikaelh and in my own posts, suggest you look through our comment histories for examples.

http://anty.info/primecoin-calculator

Thanks guys...I'll give it a shot.

Yup, running a reindex should be one way to fix the issue. There's a bug in the Primecoin client which causes a crash if you start the miner when running -reindex. So make sure to specify -gen=0 to avoid that.

After ensuring your time problem(s) were resolved:

1) Append the following to your shortcut path field or batch file. If you run the .exe directly create a shortcut to it


Run it

It will attempt to reindex the blockchain, but probably crash immediately. Close the program, remove the -reindex parameter, and run as you normally would.

It should now reindex the blockchain (could take a long time depending on your machine specs).

That warning is given when no one on the network has a time within 5 minutes of your time. While it's possible you connected to bad peers, it's more likely that there is something wrong about your local date and time.


Can you also post the output of the commands 'getinfo' and 'getcheckpoint'?

New error:



{
"blocks" : 234498,
"chainspermin" : 0,
"chainsperday" : 0.00000000,
"currentblocksize" : 1000,
"currentblocktx" : 0,
"difficulty" : 9.94432247,
"errors" : "Warning: checkpoint on different blockchain fork, contact developers to resolve the issue",
"generate" : true,
"genproclimit" : -1,
"primespersec" : 0,
"pooledtx" : 7,
"sieveextensions" : 9,
"sievepercentage" : 10,
"sievesize" : 1000000,
"testnet" : false
}


Any clues?

Quick question...I get the following error when querying for mining info on HP11:

"Error: make sure the date is correct yaddayadda, otherwise primecoin might not work correctly"

The date and time is correct, it's an fx8320 running ubuntu 13.04 btw.

It's a modified beeeeer.org miner, which sends profits to that guy grom, like Trillium explained...and it's actually based on HP11 (the original xolominer for beeeeer.org)

This is not the trojan you are looking for...

It was not a 'trojan'. Some of the profits were siphoned off automatically to the creator as it mined.

The software was supposedly not meant for public release or use.

More or less everyone agrees: You should not use this software. Move along