|
7 hours of 120+ pps at 100k sieve and not a single block :/
|
|
|
|
|
Do people want a pool for this? I think I could give it a shot if people are interested in actually having pools before we have gpu miners. I'm not sure about a pay per share design due to the nonuniform and decreasing distribution of primes, but proportionally seems straight forward.
|
|
|
|
|
I've found all the blocks I've mined after compiling it myself. So who knows mang. Prime distribution is the 9th wonder of the world.
|
|
|
|
|
How would a pool even do shares with a PoW like this?
|
|
|
|
Maybe the improvement should be tested with shorter chains on the testnet first. Or it takes days or probably weeks to show its effects...
Do you know a way to become your own chain? Timing how long it takes to create a blockchain x blocks long would be an interesting test of your miner's performance. |
|
|
|
could you please post the codelines you've changed?
cheers!
My lines are gonna be off since I also removed the printf statements that were inside the loops. The debug file isn't important to me anymore so eh. But here ya go, no changes to the algorithm itself yet, my knowledge of math isn't in this area. ... If you're changing the max sieve size, I think you can also change the vector sizes on lines 102-104. ....but what's the point? You're obviously just proportionately reducing the chance of finding something... I believe people are having trouble running this on multi-core machines because of cache issues, reducing the amount of memory that goes into each thread might improve the issue? I don't have a 32 core machine to test on though. I just linked those vectors to my nMaxSieveSize, we'll see if it offers any improvement. |
|
|
|
could you please post the codelines you've changed?
cheers!
My lines are gonna be off since I also removed the printf statements that were inside the loops. The debug file isn't important to me anymore so eh. But here ya go, no changes to the algorithm itself yet, my knowledge of math isn't in this area. main.cpp
4610: uint256 phash = pblock->GetHeaderHash();
4611 - 4614: while ((phash < hashBlockHeaderLimit || CBigNum(phash) % bnHashFactor != 0) && pblock->nNonce < 0xffff0000){
pblock->nNonce++;
phash = pblock->GetHeaderHash();
}
4644: CBigNum bnMultiplierMin = bnPrimeMin * bnHashFactor / CBigNum(phash) + 1;
4655: if (MineProbablePrimeChain(*pblock, bnFixedMultiplier, fNewBlock, nTriedMultiplier, nProbableChainLength, nTests, nPrimesHit,phash))
prime.h
10: static const unsigned int nMaxSieveSize = 500000u;
60: bool MineProbablePrimeChain(CBlock& block, CBigNum& bnFixedMultiplier, bool& fNewBlock, unsigned int& nTriedMultiplier, unsigned int& nProbableChainLength, unsigned int& nTests, unsigned int& nPrimesHit,uint256& headerhash);
prime.cpp
342: bool MineProbablePrimeChain(CBlock& block, CBigNum& bnFixedMultiplier, bool& fNewBlock, unsigned int& nTriedMultiplier, unsigned int& nProbableChainLength, unsigned int& nTests, unsigned int& nPrimesHit,uint256& headerhash)
360: psieve.reset(new CSieveOfEratosthenes(nMaxSieveSize, block.nBits, headerhash, bnFixedMultiplier));
380: bnChainOrigin = CBigNum(headerhash) * bnFixedMultiplier * nTriedMultiplier;
|
|
|
|
nMaxSieveSize = 1000000u ~130 - 230 pps nMaxSieveSize = 100000u ~230 - 400 pps nMaxSieveSize = 10000u ~ 350 - 800 pps Running the second one now, no idea if this will make me mine more blocks or none. Also not sure about the other thing you mentioned, goes above my head.  I'm not sure that reducing the sieve size is the best optimization, since by reducing it you also reduce the amount of potential numbers you are testing for the PoW... Who knows what that actually does to the potential of finding a correct PoW though. Running different Sieve values per thread rather than the current all threads same Sieve, could spread out that risk, even if it's just 1 out of 4 running at 10k and the other 3 at 1M There's an idea. Then run that setup for a day and figure out proportionally which sieve size resulted in the most correct PoWs. |
|
|
|
nMaxSieveSize = 1000000u ~130 - 230 pps nMaxSieveSize = 100000u ~230 - 400 pps nMaxSieveSize = 10000u ~ 350 - 800 pps Running the second one now, no idea if this will make me mine more blocks or none. Also not sure about the other thing you mentioned, goes above my head. I'm not sure that reducing the sieve size is the best optimization, since by reducing it you also reduce the amount of potential numbers you are testing for the PoW... Who knows what that actually does to the potential of finding a correct PoW though. |
|
|
|
Left my somewhat optimized version running over night and came back to 3 additional blocks mined.
Getting roughly ~60 pps with 500K sieve size and basic optimization flags. Running on a single thread of a stock i3 2120.
Dude. Post it. Keeping optimized miners secret is a bad move for your rep and the coin. Don't make me get my own optimized one to post. Other than the sieve size change. I also opted to pass the blockheader hash through the functions, instead of making calls to block->GetHeaderHash() every time. I'm not sure what kind of improvements that actually made since I also changed the sieve size when I first did it. But it stops me from running double SHA256 like 3 times more than I used to. |
|
|
|
|
Left my somewhat optimized version running over night and came back to 3 additional blocks mined.
Getting roughly ~60 pps with 500K sieve size and basic optimization flags. Running on a single thread of a stock i3 2120.
|
|
|
|
The longest known Cunningham Chain has k=17.
So far the highest found by primecoin are 9 long in blocks 116, 1592, and 2044.
The distribution is skewed towards chains of 7 primes as the difficulty started at 7. I'm expecting difficulty >8 within 4 days and >9 by the end of the month. In time we will start to see some significantly long chains, but I can't see this project delivering chains longer than 12 that match the hash of the prime blockchain for another year at least. Before we can get longer chain the network pps will have to go up. And do we know how to measure the effective pps rate of the network? |
|
|
|
|
Has anybody else tried messing with the nMaxSieveSize variable?
By chopping a zero off of it, I seemed to be able to get almost a 5x increase in pps. I know that reducing the sieve size would effectively reduce the amount of numbers checked for each run of the sieve and then reduce the likelyhood of finding a block, but is pps more important than search size?
|
|
|
|
|
Just write a blockchain parser.
|
|
|
|
I seem to be over 1000pps pretty consistently after some optimization.  What kinda CPU you running on? |
|
|
|
|
After compiling with optimization flags, a setgenerate true 1 on my stock i3 2120 is getting 80+ pps.
|
|
|
|
when does gpu mining come out?
Is this something GPUs are good at? It's fundamentally different from hashcracking It really depends on how well the programmer writes it. |
|
|
|
|
So in like 8 hours the first coins will be mature. And then the real fun begins.
|
|
|
|
|
Finally mined 19.47XPM on my i3 2120 with only 1 core.
|
|
|
|
|
I've probably averaged 10 primes per sec since the coin started and not a single block.
|
|
|
|
|
Show Posts
