 Show Posts
|
|
Pages: « 1 2 3 [4] 5 6 »
|
ps: I only mine the testnet when I need to test stuff like this, yesterday I had 0 connections, but my node is always up.
I have two peers listed and have for a few days. One in Germany and one in MI USA. Not that it is important, but we might have more than one testnet running. Regards, -- bsunau7 |
|
|
|
possibly android clocks are the problem : cat /sys/device/cpu0/cpufreq/stats/time_in_state 126000 5835475 216000 46645 312000 3710 408000 502 600000 42483 696000 865 816000 2064668 1008000 1889 1200000 11922 1416000 3833 1512000 1261 1608000 4392 1704000 0 I'll try to find android clock switcher (any ideas??) and start again . ---edit--- tried cpu tuner, set 1410 MHz lower bound, tabled died soon  last message was : [2014-08-08 14:14:44] thread: 1 TOTAL (p0,p1,p2,p3,p4,p5,p6) = (75095,2108,65,2,0,0,0) [2014-08-08 14:14:44] thread: 1 setup:0.286795s sieve1:0.375605s sieve2:3.092670s fermat:8.899657s total:12.654727s Heat issue? When updating the ROMs in my old HTC I had to place the phone on an frozen gel pack to keep it functional. Not a viable solution long term however... Also wow! @1.4Ghz you are giving the a15 a run for its money (and will probably beat it). A larger sieve will probably get you 25% more. Making -m larger will move computation from fermat and into sieve2 (also most of the heat will be coming from sieve1 & sieve2). For reference mine is an a15 @ 1.4Ghz with -m 8750000: [2014-08-09 09:16:20] thread: 3 TOTAL (p0,p1,p2,p3,p4,p5,p6) = (10564478,302222,8741,251,7,0,0)
[2014-08-09 09:16:20] thread: 3 setup:0.457161s sieve1:0.136794s sieve2:4.365409s fermat:4.763878s total:9.723242s
[2014-08-09 09:16:20] thread 3: 16812648209 numbers, 1729090 knumbers/s
[2014-08-09 09:16:20] Total: 6882238 knumbers/s Regards, -- bsunau7 |
|
|
|
I was hoping to push out a new ARM binary, but have been running in circles looking for a problem which probably isn't mine. Testnet at a difficulty of 304 can only support a 39bit nonce which is making allowing me to make a mess of things.
I think I removed that restriction for testnet in v0.9.2 That rule is by design: otherwise there are some cases where 2 different headers with 2 different nonces could use the same sextuplet, which could lead to attacks. However that's not a problem for testnet so I decided to allow that in order to test the miners on testnet. Maybe the rule is still being enforced? Please confirm if you're using 0.9.2 regards and kudos for your work! Yep, 0.9.2. The bit maps for the bnTraget were not looking right which is why I looked at it being the cause, I couldn't get a 'clean' nonce without overflowing into the prime base. I shrank by 2 bits and started to get 25% of block accepted. Another fix (thanks gmp for 32bit ui) got 100% of blocks accepted. I'll set it to 48bits and see if the other fixes were the real solution or not. Also all my blocks in testnet need to mature, anyone else mining it? Regards, -- bsunau7 |
|
|
|
now I try the newer one (08-08):
minix rk3188:
[2014-08-08 10:26:28] Total: 4289580 knumbers/s
[2014-08-08 10:26:28] Expected average time to block: 12357322.189929
[2014-08-08 10:26:28] accepted: 0 in 1576 seconds
pipo p1-rk3288:
[2014-08-08 08:28:01] Total: 2885670 knumbers/s
[2014-08-08 08:28:01] Expected average time to block: 18369292.527667
[2014-08-08 08:28:01] accepted: 0 in 343 seconds
can it be slower ?
On the same hardware next to no way it should be slower. Nett effect of the changes are less instructions & memory access in sieve1 and less memory access in sieve2. Also there is 75% less network (getwork) traffic. It looks like a nice little speed bump on the minix. The RK3188 and RK3288 difference is a surprise. A9 cores verses A17 cores.. Both are "mid range", I hope that clocks & memory aren't the cause. Next possible cause would be arm/neon pipeline shenanigans. I'll do some reading and see what I can find. Thanks for running them! Regards, -- bsunau7 |
|
|
|
It's working! I just got it working with the stratum server already published some time ago.
I'll clean the code a little bit and upload to github tomorrow.
Also the miner is based on dga's b15, and just like dga's b15, I made it work on linux but not on windows. I'll try to debug that and if I can't find the problem I'll just make a stratum version of b14 (that should be easy now).
WooHoo! I can't wait to see how it hangs together! Regards, -- bsunau7 |
|
|
|
I was hoping to push out a new ARM binary, but have been running in circles looking for a problem which probably isn't mine. Testnet at a difficulty of 304 can only support a 39bit nonce which is making allowing me to make a mess of things.
A new version in which each thread searches 2^34 candidates. This also moves from a static pn19 to a pn23 sieve and is a little more efficient with memory access, these should bring ~10% overall gain (or more if your memory is slow). Unfortunately performance gains aren't keeping up with the decrease in value so I am no closer to being break even on power. Also, the pn23 can take a minute or two to generate (which is annoying to me). So on the first run it'll write the sieve into a file called 'pn23.bin'. Once the file has been created subsequent executions will use it. It is safe to delete if you want. Link is https://mega.co.nz/#F!6Y8ywRoZ!5ogMJEc2Teq5ckt9WClNpgRegards, -- bsunau7 |
|
|
|
I've got couple replies about rk3288 boxes, no firmware ready yet, and they are about 110 usd + -, have not order any yet. I can test on Pipo P1 with rk3288, but just android,no linux ready yet - this is my biggest challenge  any special requirements to run your miner in android ? Nothing special, just needs to have the neon FPU. I was hoping to push out a new ARM binary, but have been running in circles looking for a problem which probably isn't mine. Testnet at a difficulty of 304 can only support a 39bit nonce which is making allowing me to make a mess of things. Regards, -- bsunau7 |
|
|
|
...hmm... minix still running [2014-08-05 07:37:39] thread: 3 setup:0.103281s sieve1:0.050215s sieve2:1.185316s sieve3:0.000001s total:5.142445s [2014-08-05 07:37:39] thread 3: 4285951855 numbers, 833420 knumbers/s [2014-08-05 07:37:39] Total: 3401046 knumbers/s [2014-08-05 07:37:39] Expected average time to block: 16460402.054816 [2014-08-05 07:37:39] accepted: 0 in 38130 seconds Good to know my code wasn't at fault. You seem to be running at ~half the rate as the a15 core. I've a version which is ~7-10% quicker(removed a bunch of memory access in sieve2). I am in the process of moving from 32-bit to 34-bit nonce (4 times the search space) and from pn19 to pn23. Once I get that done I might compile an a9 version, but I don't hold much hope on GCC knowing much about the differences. I am looking at those RK3288 set top boxes for ~$79USD, curious how they fare... Also looks like a few people have put a floor under RIC on poloniex, seems to have held and pushed the price up some what. Regards, -- bsunau7 |
|
|
|
just fired up rminerd_armv7_210714 by bsunau on my latest fedora arm experiment with 4core rk3188 tv stick - leaving at
[2014-08-04 07:07:37] thread 0: 4292317050 numbers, 729502 knumbers/s
[2014-08-04 07:07:44] thread: 0 TOTAL (p0,p1,p2,p3,p4,p5,p6) = (8307,222,3,0,0,0,0)
[2014-08-04 07:07:44] thread: 0 setup:0.248963s sieve1:0.055215s sieve2:2.025427s sieve3:0.000002s total:6.726587s
[2014-08-04 07:07:44] thread 0: 4288084322 numbers, 637465 knumbers/s
[2014-08-04 07:07:45] thread: 3 TOTAL (p0,p1,p2,p3,p4,p5,p6) = (8446,226,3,0,0,0,0)
[2014-08-04 07:07:45] thread: 3 setup:0.227510s sieve1:0.056812s sieve2:7.640975s sieve3:0.000002s total:46.055727s
[2014-08-04 07:07:45] thread 3: 4286266223 numbers, 93067 knumbers/s
[2014-08-04 07:07:45] Total: 1565818 knumbers/s
[2014-08-04 07:07:45] Expected average time to block: 36355078.655511
[2014-08-04 07:07:45] accepted: 0 in 168 seconds
Thanks! A lot of variance in thread 3, were you thermally limited or doing something else on the stick? Everything I've read says that an a15 is significantly better than an a9 based processor for this workload. Your thread 0 is 50% of my performance with a 15-30% faster clock sort of proves this. I am getting a banana pi (dual a9 core) in a few days, I'll test out compile options on it before it gets used for motor control. And for anyone who cares, improving GMP performance isn't easy :-/ Regards, -- bsunau7 |
|
|
|
Yes, I noticed the the "time to block" decreased to a third when using -m 5M. In my miner (for intel hardware though) I use all primes up to 2^32, so I was used to some larger numbers :-) Note that the time to block displayed my be serverly off. You need to apply a correction depending primorial you use, which will increase the likelyhood of finding a sextuplet, but OTOH you do miss some sextuplets if your primorial is bigger than 210 (and of course it is).
The first choice I made was to use 32bit everywhere (64bit arithmetic is expensive). This means each thread only searches at most (nonce -> nonce+2^32) sieving with larger primes has low chance of pruning the candidate. It just becomes cheaper to stop sieving primes (diminishing returns) and start fermat testing. I don't use the pnXX+97 step, but test all 5005 candidates per pn19, so I don't believe I should miss any, so I am not sure why a correction factor would be required. Mertens 3rd theorem fits very well on this kind of sieves, it does give exactly the probability of not sieving a number if you sieve with all the primes up to n. You surely noticed the constant factor between p0/p1/p2... This factor can be calculated as the quotient from the 3rd mertens function with n as the sieve size and the prime density at the given difficulty, which is about 1/ln(2^(diff+256+8+1)). This factor raised to the sixt power (for p6) decreases significantly with the size of the primes used, so it might be worth using primes as big a possible, if your sieve is fast enough (but on an arm 2^32 is probably to big).
Yes I did, ~34-35 is the observed factor (@ current difficulty and sieving with the first 550k primes) and I use it outside of the miner to estimate time to block. In the miner I still use the original gatra code for the time estimate, it is ~10% of what it should be which isn't a big concern (ie low priority). I think the sieve code is pretty fast, but it is only fast because I stick to the ARM's word size. A sieve of a few hundred thousand primes will be a natural limit for a 32bit implementation, until the difficulty increases (when fermat testing gets significantly more expensive) I don't see any benefit in removing the 32bit design limit. The problem I found with the sieve after I eliminated all the modulo operations was that it is limited by memory bandwidth. To make more than one core do useful work on it, I needed to divide it into small chunks which fit into the caches.
Yes, memory bandwidth is a big issue in ARM as well. Not only does it use slower memory, hardware pre-fetch is not as advanced as x86, reading & writing to the same cache line has a penalty as does misalignment. My first few miners were all running at the same general speed no matter what I did, once I started minimizing memory access I was able to get some good gains. Regards, -- bsunau7 |
|
|
|
hmmmm ... I'll try over the weekend,
but 2 years - even improved by a factor 20 means more than a month for a block ... not very encouraging ...
My gut says his hardware should be about 4 time quicker with a better (smaller) sized sieve. So only 5 times better to go (and there are 3 or 4 things which should get me significantly closer if I can pull it off). Regards, -- bsunau7 |
|
|
|
With -m 100000000 on a nexus 4:
Thanks! With that -m option you are sieving the first 5.7million primes which is about 10 times larger than I would suggest. I suspect using a tenth will more than double overall performance (reducing it even more should improve it further). While your output was truncated the overall goal is to get the total time per thread to it's minimum. Right now you'd be spending ~2 years for a block (i.e not worth it, but playing with -m should improve that significantly). Some other notes, the sieve makes use of 128bit wide NEON instructions (most premium phones will have that). All sieves are impacted by memory performance (and phone memory is slow), the nexus 4 has a smaller cache than my system so memory access will play a bigger role in determining your performance (which is why making the sieve even smaller might help). Also I don't know enough about the Snapdragon processor, but most older ARM CPU's have very bad memory prefetch. Right now the sieve time should be pretty constant but the fermat tests will vary based on difficulty, I was thinking about a dynamic balancing the amount of sieving based on the relative performance of the fermat tests. As difficulty drops less sieving, as it rises more sieving. It should also help balance architectural differences in the CPUs in addition to difficulty levels. Thanks again, -- bsunau7 |
|
|
|
xpm aborts if the first number in the 6tuple is a composite (which is true most of the time), for the remaining 5 numbers the primes are counted. If I assume the search for a sixtuple in the arm miner is aborted when the first composite number is met (like in cpuminer-rminerd), you can multiply the 3ch and the 4ch numbers by about 10. This is because you have 10 choices to select 2 out of 5 (or 3 out of 5), 5!/(2!*3!) = 10.
Sorry didn't see your response. Yes a linear test of p6 chain, as soon as I fail I abort. For a solo miner it does not make sense to keep testing when you know a block can't be found, the ypool reward structure is different which is why different metrics are used. -- bsunau7 |
|
|
|
I am looking for people with linux running on ARM processors to try a solo miner...
Does not run on Android Linux. Unresolved library dependencies. Can you build a static executable or an executable linked to bionic? Edit: It's not only glibc, there are also a lot of undefined symbol from gmp. So a statically linked executable is needed, otherwise it will run only on your platform and nowhere else. Tried a quick -static build and well libcurl dependencies need to be resolved. I'll have some time in a few hours and will redouble my efforts! A static version has been uploaded. A minimal libcurl did the trick (was not looking forward to the Android NDK). Regards, -- bsunau7 |
|
|
|
I'll need to look at dga's code to come up with a method to map relative performance; question is does dga's miner look for any 4 out of 6 or does it look for any chain (contiguous) of 4?
The formula dga's miner uses is the 1st plus any three of the remaining 5. So all other things being equal the scaling factor should be 10 (please check my numbers, red wine and all...). You'll need to multiply the p4's I report by 10 and divide by the time taken. Regards, -- bsunau7 |
|
|
|
is this an open source miner ?
if yes i may try it out can you please point me to github or where the source is .. thanks
I might consider making n-1 type releases open, but it is not on my agenda right now. From a development viewpoint I doubt it'll do much (anything?) to improve/speed up development cycles. Regards, -- bsunau7 |
|
|
|
tried out of curiosity - no luck enable port in firewall ./riecoin-qt -server -rpcuser=userxxx -rpcpassword=passwordxxx -rpcport=28332 -rpcallowip=192.168.1.211 ./rminerd_armv7_210714 -o http://192.168.1.120:28332/ -O userxxx:passwordxxx -m 8250000 -t 4 [2011-01-02 00:01:17] 555151 primes generated. [2011-01-02 00:01:20] pn19 sieve generated, 5005 entries [2011-01-02 00:01:20] Binding thread 0 to cpu 0 [2011-01-02 00:01:20] Binding thread 2 to cpu 2 [2011-01-02 00:01:20] 4 miner threads started, using 'primesr' algorithm. [2011-01-02 00:01:20] Binding thread 3 to cpu 3 [2011-01-02 00:01:20] Binding thread 1 to cpu 1 [2011-01-02 00:01:20] HTTP request failed: couldn't connect to host [2011-01-02 00:01:20] json_rpc_call failed, retry after 30 seconds is there a way to comapre to DGA's miner I mentioned here ? (2ch,3ch.4ch ??) https://bitcointalk.org/index.php?topic=446703.msg6718714#msg6718714Do you have something like: rpcallowip=10.*
rpcallowip=172.* in your riecoin.conf file? I'll need to look at dga's code to come up with a method to map relative performance; question is does dga's miner look for any 4 out of 6 or does it look for any chain (contiguous) of 4? In a few hours I'll have some time. -- bsunau7 |
|
|
|
I am looking for people with linux running on ARM processors to try a solo miner...
Does not run on Android Linux. Unresolved library dependencies. Can you build a static executable or an executable linked to bionic? Edit: It's not only glibc, there are also a lot of undefined symbol from gmp. So a statically linked executable is needed, otherwise it will run only on your platform and nowhere else. Tried a quick -static build and well libcurl dependencies need to be resolved. I'll have some time in a few hours and will redouble my efforts! Thanks for trying it however. Regards, -- bsunau7 |
|
|
|
Hi All, I am looking for people with linux running on ARM processors to try a solo miner... Before you say yes, there is no warranty! It might work, it might not. The "block found" code is under tested so it might work, or it might not. It might run very very hot, it might just run hot (etc. etc. on the warnings)... What I am looking for is a gauge of interest as well as an indication of performance over different hardware. Link including a readme can be found: https://mega.co.nz/#F!6Y8ywRoZ!5ogMJEc2Teq5ckt9WClNpgWhat I would like is a summary of how you go items I would find interesting are: Hardware type used. OS version used. Performance seen. Wallet used to mine from. For performance let it run for a few hours (note it runs hot, hot enough that the stock cooling on my odroid couldn't stop thermal throttling and more than once it thermally shutdown on me) and grab the lines which look like: [2014-07-21 00:00:11] Total: 6506306 knumbers/s
[2014-07-21 00:00:11] Expected average time to block: 9310938.838931
[2014-07-21 00:00:11] accepted: 0 in 2858 seconds
[2014-07-21 00:00:11] thread: 1 TOTAL (p0,p1,p2,p3,p4,p5,p6) = (588022,16663,497,9,2,0,0)
[2014-07-21 00:00:11] thread: 1 setup:0.117046s sieve1:0.044911s sieve2:1.215523s sieve3:0.000003s total:2.564233s
Once again, just seeing how much interest/work I need to put in to make it portable and faster. Regards, -- bsunau7 |
|
|
|
|
