Sorry i am new to all this ...
But there is one thing i dont get.
I tryed to run it with a primecoin.conf file and changed parameters like rpcuser ... rpcpassword ... gen=0 gen=1 and also with rpcport=9910 rpcallowip=127.0.0.1 with server=1 and daemon=1.
I did not receive any block in earlier stages ... difficulty was past 8 to this stage ...
as i deleted the conf file and run the wallet without it i received two blocks in two hours ...
How can that be ... Luck ? I was using hp3 ...
So my question is is the conf file needed or not ??
Thx
That is indeed called pure luck. |
|
|
|
aws cc2.8xlarge,
primecoin-0.1.1-hp5 two changes:
1) prime.cpp
const unsigned int nPrimes = (uint64)nTotalPrimes * 8 / 100; // down from 10
2) main.cpp
static const unsigned int nPrimorialHashFactor = 9; // up from 7
You seem to be testing two changes at the same time. The first change will definitely affect performance while the second change shouldn't as people have already pointed out. It's likely you're only seeing the effects of the first change you did. mikael, knowing your work I'll take your word for it, do you agree that 1) is a change for the better and will not negatively effect block finding? The first parameter he changed definitely has a huge impact on performance, that's for sure. The parameter is based on sieve round limit implemented by Sunny King. As you probably know, that resulted in a pretty big performance boost. I'm using a static percentage value in my code instead of counting microseconds. Changing that percentage may indeed improve performance on some system. It depends on the efficiency difference between the sieve and the primality tester. I may change the percentage into a configuration parameter in the future. |
|
|
|
aws cc2.8xlarge,
primecoin-0.1.1-hp5 two changes:
1) prime.cpp
const unsigned int nPrimes = (uint64)nTotalPrimes * 8 / 100; // down from 10
2) main.cpp
static const unsigned int nPrimorialHashFactor = 9; // up from 7
You seem to be testing two changes at the same time. The first change will definitely affect performance while the second change shouldn't as people have already pointed out. It's likely you're only seeing the effects of the first change you did. |
|
|
|
Just wanted to say great miner! I feel like this is probably the most optimized miner on the market right now. Looking over the source code of the original miner and yours I think I see a way to make the miner (potentially much) faster from a mathematical standpoint rather than a code-optimization standpoint. My optimization centers around the Primorial and the loop that occurs in main.cpp on line 4622. Before getting into the code, it is important to realize why a primorial is helpful (if you already understand this, skip this paragraph). With numbers on the order of 2 256 there is about a 1 in 177 chance that a random number is prime. If you select 8 random numbers, then, the odds of all of them being prime is about 1 in 1 quintillion--impractically low. If you limit your search to only odd numbers, though, the odds shoot up tremendously. Further limiting your search to numbers not divisible by 3, 5, 7, and so on can cause the odds of finding a prime number to become much, much better. If the hash value is divisible by lots of these small numbers then multiples of that hash ± 1 will not be divisible by any of those numbers. Thus, it is convenient to use a hash that is already a multiple of 2 * 3 * 5 * 7 * ... as it will produce far more primes than another hash. As I understand the aforementioned loop, the program is searching for a hash that is divisible by a primorial. Each iteration of this loop requires a hash to be generated as it increments the nonce value. In the present form the primorail is of degree 7 (line 4579: static const unsigned int nPrimorialHashFactor = 7). I suspect that this value is carefully chosen and it's probably ideal with the way that it is written. However, I think there's an additional step that can be added to make the process much faster. Increasing the degree of the primorial is incredibly expensive as it gets larger, since adding the 8th prime requires 19 times as many hashes to be checked; the 9th prime requires 23 times as many, and so on. There is another way, though. Prime origins are required to be in the form O = H * N where O is the origin, H is the hash, and N is any integer; H is selected to be divisible by p#7 (the primorial shown above). If we extend this to O = H * N * P 2 where P 2 is 19 * 23 * 29 * ... * 51--a product of primes starting after the last prime used in the existing search--then the checked origin is still valid (an integer times an integer is still an integer). This grants the benefits of searching with a higher degree primorial while not requiring a longer search for a working hash. Nothing is free, though, as this method inflates the size of the primes to be checked. If the fast modular exponentiation is implemented through the same method as is used on the Fermat Primality Test Wikipedia page then the algorithmic efficiency is O(log 2(n) * log(log(n)) * log(log(log(n))) ). There should be some sweet spot of how large of a primorial to use where the increased frequency of primes more than offsets the extra time required for the fast modular exponentiation. It's possible that the sweet spot is 0 extra primes, but I think it's worth looking into. Definitely a great. I haven't had the time to study the code from a mathematical perspective, so this is helping me understand the code better.  Unfortunately it seems that Sunny King was ahead of you here. The code is already doing what you proposed. It uses something called a round primorial which is dynamically adjusted. You can see these round primorials in debug.log if you enable the debugging options -debug -printmining. A fixed multiplier is calculated through division by the first primorial used to choose the hash value. This fixed multiplier corresponds to your P 2. I think some improvements could be made to the dynamic adjustment system. It seems to be picking lots of different values. |
|
|
|
Good stuff Can you see if you can fix this also.. primecoind: checkqueue.h:167: CCheckQueueControl<T>::CCheckQueueControl(CCheckQueue<T>*) [with T = CScriptCheck]: Assertion `pqueue->nTotal == pqueue->nIdle' failed. CCheckQueueControl(CCheckQueue<T> *pqueueIn) : pqueue(pqueueIn), fDone(false) {
// passed queue is supposed to be unused, or NULL
if (pqueue != NULL) {
assert(pqueue->nTotal == pqueue->nIdle);
assert(pqueue->nTodo == 0);
assert(pqueue->fAllOk == true);
}
} It crashes my daemons.. Should be freed or released ? My plan is to try out my remaining optimization ideas first. Then I'll start looking at the crashes. I haven't looked at this specific crash in detail. I have seen it happening on my boxes too and I do have a core dump of the crash. I just need some time to look at that core dump. |
|
|
|
-hp5 released!This version adds a fast 32-bit routine for inverting numbers. I did some other small performance improvements to the sieve as well. Nothing really big though. Only a 2% improvement in my benchmark. Official backup repository is now on bitbucket: https://bitbucket.org/mikaelh/primecoin-hpBut please download the source code from SourceForge if you can.
|
|
|
|
|
I guess you failed to notice that CUMP only supports addition, subtraction and multiplication. You need division and other special functions for Primecoin mining.
|
|
|
|
I'm getting loads of weird compile errors when compiling makefile.unix on centos6:
"alert.cpp:223: error: âitemâ was not declared in this scope
alert.cpp:223: error: âBOOST_FOREACHâ was not declared in this scope
alert.cpp:224: error: expected â;â before â{â token
alert.cpp:268: error: expected â}â at end of input
alert.cpp:268: error: expected â}â at end of input"
Looks like there are weird characters in the source?
You probably need a newer version of boost. |
|
|
|
Mickael, why not include a command to remplace getprimespersec?
I think 5chain are more reliable.
For information, i found 2 block on machine A and 1 on B. But it's too low to have a significance.
I don't like how much variance there is currently in the 5-chains/h numbers. An rpc command would probably need to include some averaging. When the numbers are dumped to debug.log, people can do the averaging manually. Some nice numbers there still. |
|
|
|
@mikhaelh, any comment on what to do if test/h and 5-chains/h don't agree in debug.log for hp4 ? For example when sievesize=2M, I have 50M test/h and 350 5-chains/h, when sievesize=4M, I have 36M test/h and 780 5-chains/h.
I would trust the 5-chains/h number. The test/h number doesn't really have any useful meaning as far as mining is concerned. It's just the number of candidate multipliers produced by the sieve algorithm. The primes/h number tells how many of the multipliers produced a probable prime chain of length 1 or greater. The 5-chains/h number tells how many probable prime chains were at least of length 5. It's supposed to be the most reliable performance number as far as mining is concerned. A 5-chain is essentially a lot closer to an 8-chain than a 1-chain. |
|
|
|
deleted blockchain client now not connecting?
can addnode help and which one?
Here's another list of peers available at this moment: "addr" : "192.241.200.197:9911",
"addr" : "192.81.217.158:9911",
"addr" : "78.31.105.26:9911",
"addr" : "192.157.59.116:9911",
"addr" : "198.199.65.39:9911",
"addr" : "173.45.227.231:9911",
"addr" : "54.242.28.200:9911", Pick one IP address from the list (to spread the load) and write it your config file like this: Alternatively you can use the command line switch -addnode=X.X.X.X. |
|
|
|
My client also not connecting after i deleted block chain, any addnode to help?
Here's a list of outgoing connections from my primecoind: "addr" : "192.241.143.207:9911",
"addr" : "198.211.105.211:9911",
"addr" : "50.112.196.19:9911",
"addr" : "88.190.56.58:9911",
"addr" : "46.249.52.141:9911",
"addr" : "54.232.230.20:9911",
"addr" : "54.215.168.106:9911",
"addr" : "198.199.108.176:9911", |
|
|
|
What is the logic behind Sievesize/Performance?
Is it like Thread-concurency were the more, the better. Until your card can't handle it.
Or it's more complex, and some more powerful CPU can benefit from a lower value?
The code uses candidate multipliers to obtain the origin of a probable prime chain. Sieve size influences how many candidate multipliers are produced at once with a specific set of parameters. I don't personally fully understand the mechanics between the sieve size and the probable prime chains. The method was devised by Sunny King. All I know is that higher sieve sizes produces more blocks on the testnet. Please note that I haven't been able to confirm that on mainnet. |
|
|
|
The client seems to crash for me after few minutes of mining running hp3-win64 on Win 7 x64 I7 930  any ideas? This is what I got, and only once, only after hours of mining, and never again since restart. EDIT This was with hp3, I7 2660 Any news on this? I seem to get this error every few hours on my i7 3930k (Win 7 x64) but not on any of my other machines with various Intel processors. A simple restart and it goes away, but if I'm not at my computer then I lose mining time until I can get back. If I had to make a wild guess, it's asserting that the thread pool has nothing but idle threads, but I've not waded through the source to find what the problem is. I saw this same crash on one of my Linux boxes. Backtrace shows the crash happens when the mining threads are creating new blocks for mining. I think it's a bug in the original code that gets triggered more often because my code is running faster. |
|
|
|
It seems that the git repo is down ? I noticed when trying to pull the latest (hp4) changes .
I have sent them an e-mail about that. Now we just have to wait. |
|
|
|
|
New version is out!
-hp4 mainly adds L1 and L2 cache optimizations. It removes the performance bottleneck with bigger sieve sizes. Thus it's possible to increase sieve size even further.
I also added a new alternative performance measurement. The client now calculates the number of probable prime chains of length 5 and prints them to debug.log. The printing frequency is also increased.
|
|
|
|
I understand that. It kills my GPU mining when I use all cores. But I think you missed something in my post. I'm getting 5k PPS on 7 cores in the windows client but only 1k PPS in the Linux one.
Look up the "nice" command. Any CPU mining, whether built in to a coin or using minerd aka cpuminer or whatever, use "nice coind" or "nice minerd", it runs at lower priority so does not seem to impact GPU mining nor FPGA mining nor ASIC mining yet still gets to use most of the cores most of the time. -MarkM- For debug purpose, I've shut down my GPU mining and tried all cores. I still only get about 1200PPS in linux vm but I'm getting 6000 in Windows. I was chitchatting with someone else and he said his Linux PPS got halved when he switched to this client too. Which Linux distribution are you using? I suspect some distributions might not be supplying a properly optimized version of GMP. I may eventually start releasing my own Linux binaries. Ubuntu 12.04 Looks like Ubuntu 12.04 comes with GMP version 5.0.2. That's from Aug 2011. It may fail to recognize newer CPUs. In that case, it won't choose the optimal code path. |
|
|
|
I understand that. It kills my GPU mining when I use all cores. But I think you missed something in my post. I'm getting 5k PPS on 7 cores in the windows client but only 1k PPS in the Linux one.
Look up the "nice" command. Any CPU mining, whether built in to a coin or using minerd aka cpuminer or whatever, use "nice coind" or "nice minerd", it runs at lower priority so does not seem to impact GPU mining nor FPGA mining nor ASIC mining yet still gets to use most of the cores most of the time. -MarkM- For debug purpose, I've shut down my GPU mining and tried all cores. I still only get about 1200PPS in linux vm but I'm getting 6000 in Windows. I was chitchatting with someone else and he said his Linux PPS got halved when he switched to this client too. Which Linux distribution are you using? I suspect some distributions might not be supplying a properly optimized version of GMP. I may eventually start releasing my own Linux binaries. |
|
|
|
There is something strange with this coin/daemon
It is locking sometimes mining nothing and using whole cpu power
To repair it kill daemon do -rescan and start again
You can easily spot this if you have immature coins locked at specific number of confirmations, but daemon block number is increasing
I wasted many cpu power because of that
I ma using hp2 build, ubuntu
Sounds a bit like your client got stuck on the wrong fork. Sunny King's original client also suffers from that issue. |
|
|
|
|
Block rate seems to have dropped dramatically on mainnet. It's taking a couple of minutes until a new block is found.
|
|
|
|
|
Show Posts
