Topic: Nexus - Pure SHA3 + CPU/GPU + nPoS + 15 Active Innovations + More to Come - page 330. (Read 785514 times)
October 01, 2014, 03:57:29 PM
@Viz, whats your marketing plan? We need to build a strong community if you want this project succedeed
October 01, 2014, 08:47:58 AM
Hi Paul,
I am curious with your 1000 cores, how many blocks you mined per hours. I mine nothing.
Best Rgrds,
https://www.dropbox.com/s/qszqn79q48828f4/CoinShieldV1.1.zip?dl=0
Added stats for accepted and rejected blocks.
Removed mutexes for a more reliable bock submission process.
I have some optimization ideas to improve the mining performance approximately 4x; they will be added to this miner after the GPU channel launch.
In 15 minutes, 1 cpu, 3 blocks, 3 rejects. So still having all rejects... had like 20 with previous miner.
There is something weird going on here. you had 3 blocks in 15 mins?
I've done another 1000 cores for an hour with the new miner, and I didn't find a single block. no errors, no rejects. I am using gmp 6.0.0
Hey I only ran 1000 cores as a test for a few hours and after having difficulties getting it to work I gave up. So now I'm using 20 cores and have mined 6 blocks in 12 hours I am curious with your 1000 cores, how many blocks you mined per hours. I mine nothing.
Best Rgrds,
https://www.dropbox.com/s/qszqn79q48828f4/CoinShieldV1.1.zip?dl=0
Added stats for accepted and rejected blocks.
Removed mutexes for a more reliable bock submission process.
I have some optimization ideas to improve the mining performance approximately 4x; they will be added to this miner after the GPU channel launch.
In 15 minutes, 1 cpu, 3 blocks, 3 rejects. So still having all rejects... had like 20 with previous miner.
There is something weird going on here. you had 3 blocks in 15 mins?
I've done another 1000 cores for an hour with the new miner, and I didn't find a single block. no errors, no rejects. I am using gmp 6.0.0
October 01, 2014, 06:31:26 AM
Here is the x64 build: https://mega.co.nz/#!bBV0jRYJ!u1j1KczgIvURkGy_mtg5rZNBGj0FO_RweqKhH8pKDmo
I've compiled also with AVX and CORE2 flags to have better performance on specific CPUs.
Sorry but currently I don't have x86 build environment. If I'll have some free time I'll try to build one.
thanks! So which .exe should I use for i5? coinshield_prime-avx.exe?I've compiled also with AVX and CORE2 flags to have better performance on specific CPUs.
Sorry but currently I don't have x86 build environment. If I'll have some free time I'll try to build one.
I searched on the net and looks like i5 supports AVX instruction set so you can use coinshield_prime-avx.exe.
You can also use this tool to check your CPU features: http://www.cpuid.com/softwares/cpu-z.html
October 01, 2014, 06:18:12 AM
Here is the x64 build: https://mega.co.nz/#!bBV0jRYJ!u1j1KczgIvURkGy_mtg5rZNBGj0FO_RweqKhH8pKDmo
I've compiled also with AVX and CORE2 flags to have better performance on specific CPUs.
Sorry but currently I don't have x86 build environment. If I'll have some free time I'll try to build one.
thanks! So which .exe should I use for i5? coinshield_prime-avx.exe? I've compiled also with AVX and CORE2 flags to have better performance on specific CPUs.
Sorry but currently I don't have x86 build environment. If I'll have some free time I'll try to build one.
October 01, 2014, 06:08:02 AM
i would like to know what 1k cores means that could be anything to me ive seen alot where people talk about cores on these forums a core could be anything of any architecture eg: arm pentium etc etc
October 01, 2014, 03:25:13 AM
Hi Paul,
I am curious with your 1000 cores, how many blocks you mined per hours. I mine nothing.
Best Rgrds,
https://www.dropbox.com/s/qszqn79q48828f4/CoinShieldV1.1.zip?dl=0
Added stats for accepted and rejected blocks.
Removed mutexes for a more reliable bock submission process.
I have some optimization ideas to improve the mining performance approximately 4x; they will be added to this miner after the GPU channel launch.
In 15 minutes, 1 cpu, 3 blocks, 3 rejects. So still having all rejects... had like 20 with previous miner.
There is something weird going on here. you had 3 blocks in 15 mins?
I've done another 1000 cores for an hour with the new miner, and I didn't find a single block. no errors, no rejects. I am using gmp 6.0.0
I am curious with your 1000 cores, how many blocks you mined per hours. I mine nothing.
Best Rgrds,
https://www.dropbox.com/s/qszqn79q48828f4/CoinShieldV1.1.zip?dl=0
Added stats for accepted and rejected blocks.
Removed mutexes for a more reliable bock submission process.
I have some optimization ideas to improve the mining performance approximately 4x; they will be added to this miner after the GPU channel launch.
In 15 minutes, 1 cpu, 3 blocks, 3 rejects. So still having all rejects... had like 20 with previous miner.
There is something weird going on here. you had 3 blocks in 15 mins?
I've done another 1000 cores for an hour with the new miner, and I didn't find a single block. no errors, no rejects. I am using gmp 6.0.0
October 01, 2014, 01:25:53 AM
could someone please make a x64 and x86 windows build? https://www.dropbox.com/s/qszqn79q48828f4/CoinShieldV1.1.zip?dl=0
Here is the x64 build: https://mega.co.nz/#!bBV0jRYJ!u1j1KczgIvURkGy_mtg5rZNBGj0FO_RweqKhH8pKDmo
I've compiled also with AVX and CORE2 flags to have better performance on specific CPUs.
Sorry but currently I don't have x86 build environment. If I'll have some free time I'll try to build one.
October 01, 2014, 01:02:26 AM
could someone please make a x64 and x86 windows build? https://www.dropbox.com/s/qszqn79q48828f4/CoinShieldV1.1.zip?dl=0
October 01, 2014, 12:54:53 AM
block 6843 taking a long time over 15min from when i wrote this
Yes, almost half an hour
October 01, 2014, 12:37:28 AM
block 6843 taking a long time over 15min from when i wrote this
September 30, 2014, 11:58:08 PM
Hello vedran82,
I am curious with your 1000 cores, how many block you can find in 1 hours now?
Best Rgrds,
I am curious with your 1000 cores, how many block you can find in 1 hours now?
Best Rgrds,
It seems that somehow I mixed up wallet versions. No more rejects, every block gets accepted. Thanks a lot!
You've mixed me up with someone else, I'd love to have 1000 cores
I'm mining with FX8350 and FX8320. It happened I've had 3 blocks in 15 minutes, now I didn't have block for hours...
September 30, 2014, 11:01:21 PM
Hello vedran82,
I am curious with your 1000 cores, how many block you can find in 1 hours now?
Best Rgrds,
I am curious with your 1000 cores, how many block you can find in 1 hours now?
Best Rgrds,
It seems that somehow I mixed up wallet versions. No more rejects, every block gets accepted. Thanks a lot!
September 30, 2014, 10:13:12 PM
Hey all......is the coin worth mining yet without a pool for someone with an 8 core processor?
September 30, 2014, 09:43:58 PM
It seems that somehow I mixed up wallet versions. No more rejects, every block gets accepted. Thanks a lot!
September 30, 2014, 08:21:07 PM
Supercomputing,
Thank you for your diligence in developing a stable optimized miner, a lot more people other than myself I'm sure appreciate it.
edit: to add, checking the prime bits twice isn't the same as checks > 1. Each check runs a different set of parameters for divisors, fermat, and miller-rabin
Viz.
Thank you for your diligence in developing a stable optimized miner, a lot more people other than myself I'm sure appreciate it.
edit: to add, checking the prime bits twice isn't the same as checks > 1. Each check runs a different set of parameters for divisors, fermat, and miller-rabin
Viz.
September 30, 2014, 08:18:32 PM
@Videlicet
Thanks for the information on the process priority, that info will be helpful to others as well.
Version 1.1 resolved the submission bug (at least for me) after commenting out the mutex code. I mined over 200 blocks on testnet with no issues.
Your "GetPrimeBits" function is called twice before the actual block is submitted since version 1.0. The only difference is that I call it with 1 check instead of 4. The probability of a false check is less than 1/sqrt(N), N being a 992-1024-bit number, but will be increased to 4 checks in the next release.
Thanks for the information on the process priority, that info will be helpful to others as well.
Version 1.1 resolved the submission bug (at least for me) after commenting out the mutex code. I mined over 200 blocks on testnet with no issues.
Your "GetPrimeBits" function is called twice before the actual block is submitted since version 1.0. The only difference is that I call it with 1 check instead of 4. The probability of a false check is less than 1/sqrt(N), N being a 992-1024-bit number, but will be increased to 4 checks in the next release.
September 30, 2014, 07:07:12 PM
Supercomputing,
I'm checking into the submission errors. Do you get a timeout during submission, or no submission at all?
I've found especially running a lot of threads with a wallet on the same computer, you need to lower the process priority to "very low" to prevent it from stealing computing resources from the wallet.
edit:Also the difficulty has to be > nBits, not >= nBits. This was my mistake..
My apologies, the true check is:
if(pblock->nBits > GetPrimeBits(pblock->GetPrime()))
return error("Coinshield Miner : prime difficulty below target");
Coinshield Core also does 4 checks on the prime difficulty in CheckWork [From your miner], and 2 checks in VerifyWork [From the Network], which does catch false primes, this might help as well.
Thank You,
Viz.
I'm checking into the submission errors. Do you get a timeout during submission, or no submission at all?
I've found especially running a lot of threads with a wallet on the same computer, you need to lower the process priority to "very low" to prevent it from stealing computing resources from the wallet.
edit:
My apologies, the true check is:
if(pblock->nBits > GetPrimeBits(pblock->GetPrime()))
return error("Coinshield Miner : prime difficulty below target");
Coinshield Core also does 4 checks on the prime difficulty in CheckWork [From your miner], and 2 checks in VerifyWork [From the Network], which does catch false primes, this might help as well.
Thank You,
Viz.
September 30, 2014, 06:57:27 PM
Hello gatra, I will never abandon RIC - XPM and RIC are still my favorite coins. This summer has been extremely busy with too much to do and very little play time.
Yes, I do have some ideas to improve the overall efficiency. Also keep in mind that the sieve's output of at least four primes are passed to the checking function which may find other forms.
Yes, I do have some ideas to improve the overall efficiency. Also keep in mind that the sieve's output of at least four primes are passed to the checking function which may find other forms.
September 30, 2014, 06:34:58 PM
gatra,
Yes, you are entirely correct. I allow the maximum prime gap to be +12 due to the fact that they can get this large when finding shares of difficulty 17.x. This will allow any sized k-tuples to be accepted, but there are many many different combinations than just k-tuples for each given difficulty level.
Thank You,
Viz.
Yes, you are entirely correct. I allow the maximum prime gap to be +12 due to the fact that they can get this large when finding shares of difficulty 17.x. This will allow any sized k-tuples to be accepted, but there are many many different combinations than just k-tuples for each given difficulty level.
Thank You,
Viz.
September 30, 2014, 06:28:51 PM
C] Total Number of 4-Chains Found = 214: When difficulty is 5.x 4 CH won't be accepted. The only logical reason I can see that chains are getting accepted above 5.x is somebody expanded supercomputing's code for 5.x and kept it private, or that the 4 ch that are found by his miner at random times are 5x too, which would account for so many rejects.
Correction, the wheel factorization procedure implemented in the code can efficiently sieve for prime twins, triplets, quadruplets, quintuplets, and sextuplets without any modifications to the code. But only prime constellations which meet the minimum difficulty requirements are submitted. The sieve is only for admissible k-tuples.
Please see:
http://math.mit.edu/~primegaps/
http://ocw.mit.edu/courses/mathematics/18-785-analytic-number-theory-spring-2007/lecture-notes/k_tuples.pdf
hi!
Looking at the original miner, it looks like it accepts gaps of up to 12 between primes, and tuplets are not required to have minimal diameter.
So, we know that 6-tuples of minimal diameter have only one admissible form:
p+0 4 6 10 12 16
however since they are not enforcing the diameter to be minimal (16 in this case), then the following could be a valid block even though it's diameter is 24:
p+0 4 6 10 12 24
or lots of other combinations, with diameter up to 12*6 = 72
So, a sieve that allows only admissible 6-tuples of diameter 16 may not be the most efficient way to mine this... or it may be, idk, I just wanted to leave the question beause but I can't help thinking that the sieve may be filtering too much.
btw, have you abandoned RIC? me miss you
Jump to: