 Show Posts
|
|
Pages: « 1 2 [3] 4 5 6 »
|
Hi All, I've had very little time recently and it looks like the next 3-4 months will afford me even less time. As such I've released the code for my ARMv7 miner to the public. The link is: https://bitbucket.org/bsunau7/riecoin-armv7There are lots of ideas I would like to try out, some of which are: - Seeing if the '0' heavy primes I generate can be used to speed up modular exponentiation (initial tests got within 5% of GMP performance without using montgomery)
- fast_recip might be faster than the fastmod code, making more use of fast_recip might get performance gains.
- It might be quicker to calculate the reciprocals inline as opposed to fetching from memory.
- Interleaving primes/reciprocals/offsets should be more efficient from a memory access viewpoint, worth investigating.
- I've only optimized fast_recip for memory access, should be some wins in the fastmod code.
Hope this is of interest! Regards, -- bsunau7 |
|
|
|
What are the chances that everyone that jumps on for the super block day would be there just for exactly the time needed to find the superblock, even if superblocks have thier own diff curve (which u can safely assume they would) if its a one day a month thing u can expect that the extra mining power will start sometime before the superblock and linger some time after, in which case it will effect the network till next retarget.
Low, when ypool's riecoin wallet was being re-built there were still 4k clients "mining" nothing. There are a lot of miners (either knowingly or un-knowingly) mining while their machines are on. If they can't stop mining when there is no reward I don't think they will change their behaviour if they are mining the superblock or not. -- bsunau7 |
|
|
|
Why settle for 52 world records per year when u could have more  Say at least 3 super blocks per week? I don't think 3 hours a week would be a big impact on the riecoin network. I originally thought even everyday would be fine and would make mining more interesting for the average miner hopefully attracting more miners and having the flow on effect of making records easier to achieve. Though i can see the reasoning behind wanting to cause the least disruption while still breaking records. Perhaps you could also have POS blocks for the duration of the superblock this way tx can still be processed and you can have as many superblocks as deemed practical. I think once a week is more than enough, once a month would be my personal preference. Or 13 a year and make it a "full moon" thing  Breaking records is a one trick pony, you don't want to flog that pony any more than you need to. We'll get a nice up tick on the first record and the second but over time breaking the same record will have less and less value; it'll become the norm not the exception. Going on a slower path extends the marketing benefits while keeping the record difficulty somewhat in check. Also knowing how superblocks will be sized would be nice. While you've touched on some of them there are significant risks if the superblock is a guaranteed record (i.e superblock difficulty only ever increases). Also you need to consider that once the "record euphoria" passes we'll see a reduction in overall network performance potentially making the next record block a huge liability. Just some thoughts... -- bsunau7 |
|
|
|
|
In ten hours the difficulty has stuck @ 1410 and no blocks found...
I'd have assumed that the difficulty would have plummeted by now... Not having looked at the protocol to much, do we need confirmations for the difficulty to drop?
Guess I was hoping for easy coins while 95%+ of the network was "dead"
Regards,
--
bsunau7
|
|
|
|
This kinds of discussions makes the value of Riecoin, it's lot more interesting than mixing and mashing hash algorithms!
Yes, this coin got me looking into ARM and SMID which I never had before. I am pretty sure I've got some very clever tricks in my sieve which no one else has considered (well, aside from riecoin there isn't much use for a fast p6 sieve). I've said it before but this coin is a side project, making profit would be a bonus. The value of the coin eventually matter in that if it were high enough, it would incentivize some dedicated prime computing silicon, which eventually could have other uses. I guess NSA & similar have such silicon, but it's definitely beyond the budget of us mere mortals.
There are some quite well known Montgomery multiplication design patterns for FPGA's and have been for years, same for binary exponentiation. I have been wondering if those old crypto accelerator cards could be leveraged into riecoin (that is my pipe dream). Also the main FPGA makers are supporting OpenCL. Yes; write OpenCL and compile it into hardware. I am surely moving the goalposts here, but would it be possible to amortize the verification over many blocks? Sort of a distributed partial Rabin-Miller (is that practical and can it be made provable?) ... It all hinges on the provability of a partial Rabin-Miller test, which may be a pipe dream This looks like a job for a pool where state across multiple miners can be maintained. Maintaining validation and reward allocation across a distributed network would be PhD material. Regards, -- bsunau7 |
|
|
|
edit2: fixed & updated zip, now with 122000 primes.
Quick turn around & thanks! Regards, -- bsunau7 |
|
|
|
I'm afraid that doesn't work. Imagine that you did find p-2 and p+18 prime. So you have a septuplet. But, you started from a sextuple so p+12 is also prime. This means that your septuple is also an octuple: it has 8 primes in the range p-2 to p+18. A difference of 20. But Athony Forbes tells us that the minimum distance possible for 8-tuples is 26, so the 8-tuple with distance 20 cannot exist. But we said it did... this absurd comes from assuming you could find p-2 and p+18 both prime.
So the test is needs to include a "p4 or p12 not prime" test as well. Sorry for any false hope! Regards, -- bsunau7 |
|
|
|
There is an anomaly at block hight 61000-62000 where the limb size doubles, I suspect it might be the source file/gmp parsing but I've not investigated.
fairglu, can you check the file? The problem primes are twice as long as they should: pukcab% head -60010 Riecoin_Primes.txt| tail -10 | wc
10 10 10060
pukcab% head -70010 Riecoin_Primes.txt| tail -10 | wc
10 10 4820
pukcab% head -50010 Riecoin_Primes.txt| tail -10 | wc
10 10 5180
pukcab%
The difficulty and the size of the prime for block 60010 don't match ( https://chainz.cryptoid.info/ric/block.dws?60010.htm). Also the p0 for block height 60010 does not match what the block chain says: $ riecoind getprimes c128a2f6a3ebb5afa55cd3896959697059b8bd36a16b1e50e56b5fb1349230f7
{
"p0" : "6583993995561192360346046251200206127224654587084325937668318951846051159452993920231623250817659319742419550076619488702317466896549240871168724940491399822598666002168585392207972987955918925506288180520886691254442379378219899029781268734901605154351243323483934758451516491217058653000969212415484447222824114991142710278105797334598372470805981538498172580073950216353959647551925237059810296823999141391673270944333694570238718103456560515918954735187487480245413428471638426754875981718775052397", Regards, -- bsunau7 |
|
|
|
No problem, I'll run the update and generate a complete zip (had not bothered since diff went down). edit: updated the zip with the first 120k primes (p0), get it from https://chainz.cryptoid.info/ric/Quick and dirty test didn't find any p0-2 primes, tested code by running the same test with p0-0 (i.e. p0) which 'found' most of them aside from some in the 60k block range... There is an anomaly at block hight 61000-62000 where the limb size doubles, I suspect it might be the source file/gmp parsing but I've not investigated. Code used (so people and extend/validate): //bsunau7
#include <stdio.h>
#include <stdlib.h>
#include "gmp.h"
int count,m2 = 0;
mpz_t tmp,p0;
int test_minus2(mpz_t p) {
mpz_sub_ui(tmp,p,2);
if(mpz_millerrabin(tmp, 12)) {
m2++;
gmp_printf("p0 %#Zd\n",p);
}
}
int main(int argc, char *argv[]) {
FILE *f;
mpz_init(p0); mpz_init(tmp);
f = fopen("Riecoin_Primes.txt","r");
//while(EOF != gmp_fscanf(f,"%Zd\n",p0)) {
while(mpz_inp_str(p0,f,10)) {
test_minus2(p0);
count++;
if(count%1000 == 0) {
printf("count = %u minus-2's = %u limbs = %u\n",count,m2,p0->_mp_size);
}
}
fclose(f);
printf("count = %u minus-2's = %u\n",count,m2);
} To compile & run: pukcab% gcc -L /usr/local/lib -I /usr/local/include -O3 -o p7 p7.c -lgmp
pukcab% ./p7 No error checking (but a progress counter!!!!) just make sure that the file "Riecoin_Primes.txt" is in the same directory as you run it from. Regards, -- bsunau7 |
|
|
|
This is much nicer think to do - than the hard fork. I had that idea before when checking Riecoin, here are the k-tuples http://en.wikipedia.org/wiki/Prime_k-tuplebut did not have the time ... if anybody has tips, how to parse ric blockchain for 6tuplets, it's ease to do. Anybody ? Quickest way is https://chainz.cryptoid.info/ric/ has the first 60k blocks p0 in a zip file. fairglu might be willing to run this script to get a complete set... Other wise it looks like and extract the transaction id (looks like custom code to process the block chain) and run "riecoind getprimes <txid>". A perl DBM based script should also be able to do it, but I've not the time :-/ And yes, no hard fork would be nicer. Regards, -- bsunau7 |
|
|
|
Am I crazy, or should we not expect to have a few tens of septuplets already? Perhaps I'm mis-thinking the math -- 1/ln(2^1700) ~= 1/1200 chance of a sextuplet being a septuplet?
You're right, but looking at the admissible patterns for sextuplets vs septuplets: 0 4 6 10 12 16 vs 0 2 6 8 12 18 20 0 2 8 12 14 18 20 it doesn't fit...looks like we're screwed... we won't have septuplets with minimal distance (p ... p+20) I didn't verify this, but the source is Anthony Forbes same thing with octuplets: 0 2 6 8 12 18 20 26 0 2 6 12 14 20 24 26 0 6 8 14 18 20 24 26 I spotted that as well, but it might not be as bad as you think (but not as easy as testing one extra prime). If you take the first p7 variant and subtract 2 you get the pattern: Aside from "12" is a very good match for the 6-tuplet pattern (for the second p7 variant you ignore the "4"). In both cases you just need to test p-2 and p+18 for a valid p7 chain. In effect a valid 6-tuplet means you know you have 5 out of 7 valid primes for the 7-tuplet. A quick look at the others shows similar tricks to "re-use" valid 6-tuplets probably also exist. Once again check my assumptions.... EDIT: For the 7-tuplet, you can also subtract 4 and get another pretty good subset to use as the basis of a test. Should also increase chance of finding a valid chain. Regards, -- bsunau7 |
|
|
|
The Primecoin lot have broken quite a few world records, it would be nice if we could get some too.
The difficulty on the primecoin network has been stuck at 10.95-10.98 (give or take) for months. It only seems to be increasing in response to miner efficiency. I doubt they will be seeing any new records for a while. Regards, -- bsunau7 |
|
|
|
Hi, Another 5% from making sieve2 code ~30% smaller and starting to optimize memory access (pre-fetching). Once again to see this improvement you'll need to increase the sieve size (-m). I am running it at 15million which means I am sieving against the first 970k primes. Link is, as always; https://mega.co.nz/#F!6Y8ywRoZ!5ogMJEc2Teq5ckt9WClNpgNote: This runs the chip hot, very hot. The CPU is sitting on 94-104c (thermal throttles at 104c) even with a heat sink and a 12v noctua fan. Stock systems will probably clock right down to save themselves (and thus give bad performance). I do like the idea of a monthly super block, so much so I am considering putting a bounty of the first super block not mined by a pool. Regards, -- bsunau7 |
|
|
|
It compiled many of the source code files but in the end I got the error message: /usr/bin/ld: cannot find -lcrypto /usr/bin/ld: cannot find -lssl collect2: error: ld returned 1 exit status make: *** [xptminer] Error 1 maybe I am missing some other libraries? or are these missing source code files of the xptminer? as I said I'm a newbie to Linux Thank you very much for your help. Michael ana: curefrankosflue Try installing libssl-dev if ubuntu 13 does not have it. As root: # apt-get install libssl-dev Next try setting LD_LIBRARY_PATH before you run xptminer. It sets the path which the executable will look for it's libraries. Doing it on the make line sets it for that execution of "make" and not the executable created. Something like # export LD_LIBRARY_PATH=/usr/local/lib
# xptminer Should work. The export makes it active for the life of the shell. There are a few ways to make this "sticky" my preference is to add it into dynamic linker, there are are lots of hits on google for this, search for something like "adding /usr/local/lib to library path" should give you a pretty good start! Regards, -- bsunau7 |
|
|
|
Another version of the little ARM miner project. A 5-11% improvements depending on sieve size (the bigger the sieve bigger improvement) by re-factoring part of the code in assembly. To get the 11% I had to increase my sieve by about 30% (I am now sieving using the first 770k primes), so you'll need to increase '-m' accordingly. Link is https://mega.co.nz/#F!6Y8ywRoZ!5ogMJEc2Teq5ckt9WClNpg. Regards, PS The last time I had to do assembler was for m88k, which should give you an idea of how long ago that was. -- bsunau7 |
|
|
|
I've put a new one up, ~5% faster, mostly in the setup phase. Also GCC has put "sub-optimal" code in some of the loops, gcc4.9 might do a better job as would some hand crafted ASM code, neither of which fill me with joy.
Another version, this one netted 2 blocks in ~8 days of run time (just the luck of the draw). Biggest change is the use of a 30 second target to process each block (dynamically increases/decreases search space). For me it's a little quicker as the setup phase overhead is proportionately smaller the larger the search space. Aside from that the other changes would be to small to notice. https://mega.co.nz/#F!6Y8ywRoZ!5ogMJEc2Teq5ckt9WClNpgRegards, -- bsunau7 |
|
|
|
no hard feelings nice work, thanks for effort. Just started another arm miner / old dga's - to see the difference and help the network a bit ... difficulty now 1388 let's go grab some easy money I would be interested in the 4ch/s numbers you get with the same hardware. Hate to gloat, but I got another block; a month of miner power bills paid for (on paper at least). Regards, -- bsunau7 |
|
|
|
... and there goes "5 times faster to go" I only needed 2.5 times faster for break even when I wrote that (now its over 4 times with price drop). I've only had time in the past few weeks to spend time on incremental improvements and not the bigger (higher risk) changes I want to implement. While a doubling of mining performance was possible a quadrupling is probably out of reach with my current code base. A 4 times gain with my hardware is what is needed at the current price. As I mentioned previously, people are mining at a loss (botnet/work computers) or have a private super miner (and a super miner is possible). Competing against a (close to) zero cost miner is impossible. I intend to keep working on the miner, but it is (and always will be) a side project. Regards, -- bsunau7 |
|
|
|
diff = 1400, but still not easy to mine on arm - no luck yet with bsunau7's miner.
running happily for a week or so, keep mining on !
I've put a new one up, ~5% faster, mostly in the setup phase. Also GCC has put "sub-optimal" code in some of the loops, gcc4.9 might do a better job as would some hand crafted ASM code, neither of which fill me with joy. Regards, -- bsunau7 |
|
|
|
|
