Getting a dependency error on my fresh cent 6.4 install, any thoughts? I dont see a source for this lib for this version of Cent.
[rahlquist@corgi 64]$ ./primecoin-qt
./primecoin-qt: error while loading shared libraries: libminiupnpc.so.9: cannot open shared object file: No such file or directory
Looks like there's an issue with the Linux Qt binaries in the HP7 release. They use dynamic linking for all libraries instead of static linking where possible. I will update the Linux binaries soon. Updated Qt binaries are now up. |
|
|
|
Getting a dependency error on my fresh cent 6.4 install, any thoughts? I dont see a source for this lib for this version of Cent.
[rahlquist@corgi 64]$ ./primecoin-qt
./primecoin-qt: error while loading shared libraries: libminiupnpc.so.9: cannot open shared object file: No such file or directory
Looks like there's an issue with the Linux Qt binaries in the HP7 release. They use dynamic linking for all libraries instead of static linking where possible. I will update the Linux binaries soon. |
|
|
|
Nice initiative. However, I would prefer that people wouldn't post instructions that automatically clone the git repository.
Good catch. I've modified the script so that it only clones once and uses git pull to catch up. The initial pull will be ~15MB, but after that just a few KB. Much lighter and quicker than ~15MB each time. I would still prefer you didn't clone it at all. SourceForge has tons of mirrors which can handle load much more effectively. |
|
|
|
|
Nice initiative. However, I would prefer that people wouldn't post instructions that automatically clone the git repository. Those instructions already probably got my github repo disabled. It puts quite a lot of load on the repository hosting service too.
|
|
|
|
OK I was full of sh!t, I went back to version 5 and 1M SS as I had been using and I get relatively low PPS, so it must simply be the difficulty increase you mentioned. The highest PPS values I am seeing now with v5 is ~1760 but often it reports lower than that, usually ~1300-1400. This is what I was getting with v7. I'm surprised the difficulty has had such a impact so quickly, I'm sure just last night it was regularly over 2000 PPS. I just saw your OP edit: 2. Network difficulty has changed. Prime rate goes down when the integer part of the difficulty changes (i.e. going from 8.xx to 9.xx). It's a feature of the mining algorithm and nothing can be done about it. I had been assuming it was continuously varying between the integers.  FWIW I'm using a Core2Quad Q9550 @ stock speeds (2.83 GHz). I am glad though that the sievesize parameter issue has been cleared up though. Yup, I'm also glad it got sorted out. I updated the FAQ yet again about the command line parameters. |
|
|
|
hey mikaelh! try this: in the function FermatProbablePrimalityTestFast, you don't need this part: // Failed Fermat test, calculate fractional length
mpz_sub(mpzE, mpzN, mpzR);
mpz_mul_2exp(mpzR, mpzE, nFractionalBits);
mpz_tdiv_q(mpzE, mpzR, mpzN);
unsigned int nFractionalLength = mpz_get_ui(mpzE);
if (nFractionalLength >= (1 << nFractionalBits))
return error("FermatProbablePrimalityTest() : fractional assert");
nLength = (nLength & TARGET_LENGTH_MASK) | nFractionalLength;
If Fermat's test fails, just return false. The fractional part is irrelevant if your first number in the chain is not prime. Since most candidates fail Fermat's test, this code is executed many times, so it should give you some speed up. It did increase PPS 25% for me, but I didn't have the trial division optimization. btw, I don't know how effective is that, we are looking for Fermat's pseudo primes to the base 2, not for actual primes, so maybe your optimization is filtering numbers that would have passed the test. For those who'd like to share some love: ARQYnPjkeSgtmx41bypmnkbcHLvWPafGR5 I'd do a pull request, but there's no github anymore regards Well, that's a nice idea. The fractional part is definitely useless if the first number in the chain is not a prime. My profiling software shows that about 0.4% of cycles are spent calculating the fractional part. So it's not a huge optimization but it's something. You need to be careful with the return values though. You can easily start getting false positives if you get them wrong. And yes, github is still disabled. I probably need to send them another e-mail. In the meantime you use bitbucket or just send me some patches. |
|
|
|
My prime rate was 2400 with v5 then I extracted v7 and ran it, only gets 1200-1300 now. It only took me 1 minute to extract the new version and change the target I run, this is not comparing between days.
I was trying to get 4M sievesize with this shortcut command to start it:
C:\Windows\System32\cmd.exe /c start "runlow" /low C:\primecoin-0.1.1-hp7-winx64\primecoin-qt.exe -gen -setgenerate true -sievesize=4000000
But as I said it wasn't working: The problem was simply that -setgenerate true was supposed to be -setgenerate=true. Now the parameter after it (sievesize) works properly:
-setgenerate is not a valid command line parameter. It doesn't do anything. Also your syntax was incorrect as you already noticed (you must use the '=' sign, not a space). The incorrect syntax is probably the reason why the -sievesize parameter was not processed. Can you find out what your CPU model is? It may help me figure out why your performance has dropped. |
|
|
|
I just went from v5 to v7 and now my prime rate is halved. Anyone else having this? Is it because of the optomizations made (ie. more efficient/accurate)?
Also, I have set: -sievesize=4000000
but when I view stats with getmininginfo it always says its on 1M not 4M?
I believe that when you set sievesize from the command line, you need to leave a space between the switch and the value for it to parse correctly, i.e., "-sievesize 4000000". If you are setting it in your .conf file, then you need the '=' sign. Nope, you need to use the '=' sign without any spaces in between. That's how Primecoin (Bitcoin) command line parameters work. Some examples: primecoin-qt.exe -sievesize=2000000 primecoind.exe -sievesize=2000000 |
|
|
|
I just went from v5 to v7 and now my prime rate is halved. Anyone else having this? Is it because of the optomizations made (ie. more efficient/accurate)?
Also, I have set: -sievesize=4000000
but when I view stats with getmininginfo it always says its on 1M not 4M?
Well, there's a couple of things you can check (added these to the FAQ): 1. Make sure you're not using the 32-bit version which is slower. 2. Don't compare prime rate against a lower network difficulty. Difficulty went over 9 couple of days ago. Everyone's hash rate dropped by about 30%. In general prime rate should not go down between releases as long as they are being compared against the same network difficulty. If someone has experienced a drop that is not explained by the previous two points, then please post some information about your system. If -sievesize is not working, then you're putting it in the wrong place. EDIT: I also updated the FAQ concerning this. |
|
|
|
|
I forgot to mention that -hp7 should reduce the amount of random crashes since the crashes happen during block template creation. It's not a complete fix but it should help a bit.
|
|
|
|
|
-hp7 is out with Sunny King's bugfix!
This release contains Sunny King's important fix for mining large blocks. Last night we had an issue with one person sending out big transactions. The transactions were legit but the miner choked on them because it was creating block templates too frequently. Sunny King's patch fixes the issue so that new block templates are created only when needed. New transactions are only included at 10 second intervals. A new block being broadcasted on the network will still of course reset the miner.
I did also put in a small performance improvement for the sieve that was ready to go.
|
|
|
|
Looks good at first glance. It's getting late for me, so I'll port it to my tree in the morning. |
|
|
|
|
The block explorer is still probably a bit buggy in some places. If it's correct for this bit, then someone is sending transactions to transfer batches of 10k XPM.
|
|
|
|
|
Looks like the bad transactions are still coming in.
Couple of examples that look like the culprits:
4d19a79179e1c8a811241fb990023fa7754ad3856b8b41aef7bd9b5d4c9020f2
e245be126ff2f18496193bf90331de55a5c6645abaed793968a4bf65299e526f
|
|
|
|
|
Yeah, something is definitely very wrong with the network. Right now I'm thinking someone managed to broadcast some shitty transaction.
|
|
|
|
@mikaelh, it seems to be crashing a lot with HP6: primecoind: checkqueue.h:171: CCheckQueueControl<T>::CCheckQueueControl(CCheckQueue<T>*) [with T = CScriptCheck]: Assertion `pqueue->nTotal == pqueue->nIdle' failed. I get a crash on 70% of machines in 5 minutes gap (16cores). Though I did not use your Linux compliation, (used my own, since it worked better for me). Do I need to install it your way for HP6 to work? Or perhaps Reboot? No, that just means the bug isn't fixed. I'll look at it again tomorrow. |
|
|
|
difficulty 9 already, that's the reason
What's the reason it is only 9? I'm trying to get my head around the idea that Quarkcoin launched a few hours ago and is already 57 difficultly.* Is that an apples to oranges comparison? Surely Quarkcoin can't have 6 times the network strength of Primecoin. As Primecoin difficulty rises, the supply of coins really gets choked off - at difficultly of 32 . . . that's 999/(32*32)= .975 coins per block. *Oh, it's gone up to 63 since I wrote those two sentences. It is very much like comparing apples and oranges. For Primecoin, the integer part of difficulty determines the required probable prime chain length. E.g. if difficulty is 9.07233632, a probable prime chain of length 9 is required. The fractional part is used to determine how many length-9 chains are accepted. It scales logarithmically so that going from 9.8 to 9.9 is a lot harder than going from 9.1 to 9.2. The details for the fractional part are in Sunny King's paper. The current algorithm also does more work for longer target chain lengths. That's why PPS numbers are also dropping. |
|
|
|
|
-hp6 released!
Lots of changes in this release. Here's a list of notable changes:
* Added fast divisibility tests before doing the expensive Fermat's test
* Lots of other small optimizations
* Introduced a new experimental tuning parameter "sievepercentage". Default value is 10, minimum is 1, maximum is 100.
* Added new RPC command "getchainspermin"
* Added the following information to "getmininginfo": chainspermin, difficulty, sievepercentage, and sievesize
* Attempt to fix the random crash while mining
My PPS on mainnet went up 23% with this release with difficulty >= 9 on mainnet. This release attempts to fix the random crash while mining. I'm not sure if it's actually fixed because I have heard both positive and negative reports. The crash is more likely with high number of cores. 16 and 32 core machines are suffering the most.
The "sievepercentage" parameter is there for people to experiment with. It limits how many base primes are used to filter out candidate multipliers in the sieve. 8% seems optimal for testnet but I have no idea about mainnet.
|
|
|
|
HP5 - 6144000 - 7876 - 29 (4 at a time usually + 6 in 1 minute) - same result using "-1" or "6" threads.
Use multiples of 200k for sieve size with HP5. One of the internal loops goes over 200k elements. If there's a small bug there somewhere, it might crash when sieve size is not a multiple of 200k. |
|
|
|
This is killing me... i can't shut down primecoind, its always running, and has incorrect rpcuser and password. It doesn't let me edit or attempt to shut down using pkill, primecoind stop.
cd
echo '#!/bin/bash
killall --older-than 10s -q run-primecoind primecoind
function background_loop
while :; do
primecoind >/dev/null 2>&1
sleep 1
done
background_loop &' > run-primecoind
chmod +x run-primecoind
You need to kill the auto-restart script first (that's what my stop script does). |
|
|
|
|
Show Posts
