 Show Posts
|
|
Pages: [1] 2 3 »
|
For future development input I will try to contact j0nn9 once again to ask his position.
Without question, we need an updated software release, a fresh thread on bitcointalk.org (or the ability to at least edit the OP) and a couple of mining pools to affirm any new community interest and hashing power.
Aside from independent peer review, I don't envisage many immediate pitfalls in this regard and/or that cannot be solved with a good capable team.
In terms of Bitcoin Core I feel that we could aim for v0.12.1 (without SegWit etc.,) and then cherry-pick somewhat on the way up.
As previously stated the current v0.9.2 Gapcoin release is still doing OK for now.
It's probably advisable to set the following additions in the gapcoin.conf ;
upnp=0
dbcache=256
#dbcache=128 # on low-RAM instances
#paytxfee=0.00006500 # will certainly not break the bank with $1 to $100+ of value.
We know that scaling in the short-term is probably just fine.
...
Provisional date for original dev. response by end August 2018.
Agreed, a couple pools would be beneficial. Also getting the records updated more regularly, it's about three months old @j0nn9 http://gapcoin.org/primegaps-length.phpGives more impression this thing isn't dead. |
|
|
|
It's a bit frustrating when this happens:
[2018-07-21 17:09:33] Found Share: 27.1042661 => stale!
[2018-07-17 18:55:30] Found Share: 29.9036025 => stale!
Would be nice if you can have the stale gaps printed to screen so potential records could still be submitted. Especially if it happened to be a new world record ie: 40+ merit so it wouldn't be lost.
Indeed from a records perspective it would be ideal to retain or to at least present all data. However, this is perhaps a bit like the Butterfly Effect i.e. stale shares and prime gap records are only really 'lost' ... like tears in the rain! We know that commensurate with network difficulty increasing - new blocks will match and exceed existing records. "Your record prime gap has now been assimilated by the borg!"  Not necessarily, few are searching in the shift 400-600 range. Pretty easy feature request to put a -g option which prints to screen the starting prime and gap length along with the current merit. Plus gapcoin is missing out on marketing itself if its missing out on taking more length records. |
|
|
|
|
It's a bit frustrating when this happens:
[2018-07-21 17:09:33] Found Share: 27.1042661 => stale!
[2018-07-17 18:55:30] Found Share: 29.9036025 => stale!
Would be nice if you can have the stale gaps printed to screen so potential records could still be submitted. Especially if it happened to be a new world record ie: 40+ merit so it wouldn't be lost.
|
|
|
|
@BitcoinFX Here's some of my optimal 400-500 shift sieves. Check the pps on these guys don't think you'll be disappointed  I spent some time sieve searching/optimizing, think these are near the top end of CRT's throughput capability. The 512 sieve I've set a couple of records with already, got some ~28-30 merits. -------------- ./gapminer-cpu -o 127.0.0.1 -p 31397 -u gapcoin -x password -t 8 --shift 479 --crt crt/crt-22m-480s-dif22084c.txt --fermat-threads 6 --sieve-primes 13000 -q |== ChineseSet ==| n_primes: 70 size: 11058 n_candidates: 769 offset: 1476535438052344808249114914435996661778930746178207307948586337728699041748900 69973599252984037935841114047624491809544987485395054755413948 -------------- -------------- ./gapminer-cpu -o 127.0.0.1 -p 31397 -u gapcoin -x password -t 8 --shift 511 --crt crt/crt-22m-512s-dif21588k.txt --fermat-threads 6 --sieve-primes 13000 -q |== ChineseSet ==| n_primes: 74 size: 11319 n_candidates: 766 offset: 1336758545212663910491770481671492155581631117386004561640004944472923534481900 192446905129909515783553630929900340855652983761167499030099751977773980 -------------- |
|
|
|
Does anyone know who is actively updating the records list? http://gapcoin.org/primegaps-length.phpIt appears to be getting updated maybe once a month. I've been targeting records in the larger shift ranges, 400-600 and sometimes close to 1024. Would be nice to see it get updated more often. If anyone wants to go after the 1020-1024 range here is my best customized sieve file. Strange thing is gapcoin seems to not record about 15-20% of found blocks for these much higher shifts for some reason, not sure if it's a bug or something else. Anyways if you're more interested in setting a bunch of new records than getting more coins and have the cpus available then this should do you well. ./gapminer-cpu -o 127.0.0.1 -p 31397 -u gapcoin -x password -t 8 --shift 1021 --crt crt/crt-22m-1024s-dif21514b.txt --fermat-threads 6 --sieve-primes 23000 -q |== ChineseSet ==| n_primes: 130 size: 18863 n_candidates: 1039 offset: 4626081985258152152387146716381104236401743138963348264823465389447497680671113 1850105279036924603869257530367004081634142637510553687550996988149393864286408 0741632575037157518785072850028569785866506191383414969297175673797072420119844 8403639569393650350154418384633294148378069691014056008325991106608 |
|
|
|
|
I'm not sure the table for --ctr-bits is fixed.
Example:
If you want to generate a file for shift 384
ctr-primes = 58
ctr-bits = shift - log2(p1*p2*..*pn) - 256
...
ctr-bits = 384 - log2(58#) - 256
...
ctr-bits = 384 -64 - 256 = 64
Yet the table shows the ctr-bits set to 16 for primes=58.
|
|
|
|
|
This should be decent, took almost 2 days to generate:
|== ChineseSet ==|
n_primes: 62
size: 10242
n_candidates: 765
offset: 1146441612406461563657892639195504712824084356280432767521872923137076875201036 461817017569202830059679582232394065759000
|
|
|
|
CTR GapMiner UpdateNew Feature: Creating custom ctr filesThe ctr algorithm is divided into 2 parts. The first part, is a simple greedy algorithm which ties to find offsets for each involved prime, so that the desired number range has at least prime candidates as possible. The second part is an evolutionary algorithm, which tries to improve the results form the greedy algorithm. Therefor the greedy algorithm will be executed several times with slightly different parameters, to produce ctrs which differs in quality, which than can be used by the evolutionary algorithm. The output is a text file which can be used by gapminer as an input for ctr sieving. Parameter description: --calc-ctr Indicates that we want to calculate a ctr file.
--ctr-strength This is used to variate the computing time spend
within the greedy algorithm. Higher strength
can yield better results.
--ctr-primes The number of primes to use in the ctr file. The more
primes the better the ctr result, but the shift
also increases. Minimum shift can be calculated as
the binary logarithm of the product of all primes:
log2(p1 * p2 * ... *pn).
--ctr-evolution Whether to use the evolutionary algorithm or not.
--ctr-fixed This number indicates the number of starting primes
which wound get touched by the evolutionary algorithm
the offsets for the primes 2,3,5,7,11... are mostly
perfect computed by the greedy algorithm, and changing
them only declines the result.
--ctr-ivs The number of individuals used in the evolutionary algorithm.
More increases computing time but mostly also the
result quality.
--ctr-range Percent deviation from the number of primes.
Useful if you don't want to look for a specific number
of primes.
--ctr-bits The shift value you later use for sieving has to be greater
than log2(p1*p2*..*pn). With this flag you can fine tune a specific
shift by setting this to shift - log2(p1*p2*..*pn).
--ctr-merit The target merit (while testing the ctr it seamed that
sieving for target-merit - 1 yields the best results)
--ctr-file The target ctr output file. You can open this with a
text editor. Look for the n_candidates value, the smaller
it is the better the ctr file.
windows: https://github.com/gapcoin/GapMiner/releases/download/crt-rev5.1/windows.zipmd5: 50b506c6fdacbe36dd2d87e6f2c296d9 linux: https://github.com/gapcoin/GapMiner/releases/download/crt-rev5.1/linux.zipmd5: 88f0a3975df728566d3500b69475a78a source code: https://github.com/gapcoin/GapMiner/ I'm sorry to inform you, that I made mistake within the example commands. At the --ctr-bits flag you have to subtract 256 from the given value. The links above were updated. Any already generated ctr files can still be used, but they are targeting a 0.25 (130 primes) till 4.7 (14 primes) times greater merit. I was wondering why a shift 1024 was taking multiple days and counting though I had set the ivs to 10000 and the target shift to 20. |
|
|
|
It will be a new pool ?
nscythe, same one that has all the cpu power? If you're still mining on shift 25 you may mine faster on the higher shifts (400-600). It's still solo mining but the second release of the chinese remainder theorem, this latest release let's you build custom crt files. |
|
|
|
|
Trying the new miner and generating a new crt file. Can you post an example command to mine after the ctr file is generated? Do we still use --sieve-primes? Is ctr-evolution used in the ctr generation and the mining command?
|
|
|
|
|
@j0nn9 - Are you going to submit the next batch of new records?
There's a thread on mersenneforum where gapcoin is starting to get noticed by other gap hunters and number theorists. There's a lot of cpu resources with folks who follow that forum, getting involvement from that community would benefit gapcoin.
|
|
|
|
|
Counting 936 records Gapcoin has, closing in on 1000.
|
|
|
|
|
Folks who are transitioning to solo mining now that the pool is closed, don't forget to get the new Chinese remainder theorem miner (rev5).
If all the pool users transitioned to solo in the shift 500-600 range I'll bet we could find the overall merit world record fairly quickly. Seems easier to find bigger merits in the higher ranges.
|
|
|
|
|
Doing some more performance testing, here's another one that appears to yield good results if someone wants to try it out.
./gapminer-cpu -o 127.0.0.1 -p 31397 -u **** -x **** -t 8 --shift 508 --crt crt/crt-22m-512s.txt --fermat-threads 7 --sieve-primes 10000
It's a very low number of primes to sieve with but results in generating a LOT of candidate gaps in the gaplist. The gaplist grows by 50000 every 10 seconds. But the block percentage goes up very quickly. The reason I think it does is because of j0nn9's algo picking the best candidate gaps from a bigger applicant pool in the heap and thus yielding block solving gaps more quickly.
You'll want to monitor your memory usage for a couple rounds at first, the high watermark for the above arguments on my machine is about 2.6gig of RAM so you'll want to make sure you're not too close to maxing out your memory.
|
|
|
|
Looks like they've posted on trnicely.net Will see if we can get in the 25000 range next time Also looks like some records show up again as improvements on themselves (on gapcoin.org) due to digits truncated on trnicely.net EDIT: Fixed |
|
|
|
Looks like someone else has joined in searching for big shifts, we're setting new records fairly quickly now. Almost got into the 25000 range this morning, length 24822 ( merit 28.8 ). The overall merit record may be found more easily in these higher ranges. https://bchain.info/GAP/block/126548 |
|
|
|
Gapcoin's first record in the 20000-24998 range, shift 920 https://bchain.info/GAP/block/125746@j0nn9 - Is it possible to get 20000-24998 added to the gapcoin.org record range? EDIT: Nevermind, looks like it works! Also for anyone interested in hunting for larger overall length gaps, here are some settings that have worked for me (your mileage may vary). As time goes on I'm starting to think in some ways larger shifts can be tuned for larger performance (notice I set the fermat thread to total thread ratio very high on these). Shift 702 on an i7 (8 cores) ./gapminer-cpu -o 127.0.0.1 -p 31397 -u ***** -x ***** -t 7 --shift 702 --crt crt/crt-22m-704s.txt --fermat-threads 5 --sieve-primes 450000 Shift 920 on a 4 xeon server (16 cores) ./gapminer-cpu -o 127.0.0.1 -p 31397 -u ***** -x ***** -t 18 --shift 920 --crt crt/crt-22m-928s.txt --fermat-threads 15 --sieve-primes 300000 |
|
|
|
Gapcoin's first record in the 15000-19998 range with a shift 700 https://bchain.info/GAP/block/125025@j0nn9 - Looks like gapcoin.org thinks shift 700 is shift 594? Also, curious if there are any plans for a CRT on GPU? My machine with faster RAM seems to have gotten a better benefit to this new algo, would be interesting to see how a GPU would handle it. Edit: Looks like the shift 700 blew the doors off the bchain.info calculator, it concatenated some of the last digits on the start number. Calculating by hand the two ends are primes per factordb. |
|
|
|
@j0nn9 thanks for the new gapminer.
I second that, kudos to j0nn9. Here are my thoughts from initially testing out the new crt miner. What I think is my ideal performance setup is setting roughly half the total threads to Fermat threads. My sieve-primes # is what I then fine tune on a particular shift size(near the end of fine tuning only adjusting 1000 on sieve-primes at a time then re-running for a minute to observe). The ideal behavior is the gaplist size generally(most of the time) stays above 100. It'll creep up to a 2000-3000 then oscillate back down to 100 and then continues in this see-saw fashion. The Fermat test speeds seem to kick in faster when the list grows and tamps down the list. Those are my findings after only 24 hours. Two shift 512's so far. I parked my beefier server on shift 1024 for most of the day but gave up after the probability reached 170% with no solved block. |
|
|
|
|
