Topic: [ANN][RIC] Riecoin: constellations POW *CPU* HARD FORK successful, world record - page 140. (Read 685207 times)

edited the OP:
added the 's' in https://chainz.cryptoid.info/ric/
also added the brand new pool: http://ric.nonce-pool.com/


has the telnet forked? oh no! that would be sad

this is my info:

The explorer now supports SSL and can be reached at "https"

   https://chainz.cryptoid.info/drk/

In the next days, I'll have http queries redirect to https automatically.
The API will keep supporting both http & https.

@gatra could you updated link in first post?

We have a stratum pool up and running.  ric.nonce-pool.com

Hi gatra, do we have any stratum mining pool running? The following can not be connected for me:
http://ric.[Suspicious link removed]/ (stratum)
https://rie.crunchharder.net (stratum)

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

good news, thanks gatra

had to use 1.2 upper and lower freq  bound.
even with that tablet overheated (or something):
[2014-08-09 04:33:39] thread: 2 TOTAL (p0,p1,p2,p3,p4,p5,p6) = (7426517,201531,5541,164,3,0,0)
[2014-08-09 04:33:39] thread: 2 setup:0.331237s sieve1:0.151771s sieve2:3.585628s fermat:11.498838s total:15.567474s
[2014-08-09 04:33:39] thread 2: 16807105839 numbers, 1079623 knumbers/s
[2014-08-09 04:33:44] thread: 1 TOTAL (p0,p1,p2,p3,p4,p5,p6) = (7427210,201549,5541,164,3,0,0)
[2014-08-09 04:33:44] thread: 1 setup:0.331159s sieve1:0.151341s sieve2:3.524657s fermat:10.734700s total:14.741857s
[2014-08-09 04:33:44] thread 1: 16758935919 numbers, 1136820 knumbers/s
[2014-08-09 04:33:49] thread: 0 TOTAL (p0,p1,p2,p3,p4,p5,p6) = (7427968,201570,5541,164,3,0,0)
[2014-08-09 04:33:49] thread: 0 setup:0.331779s sieve1:0.152012s sieve2:3.660296s fermat:11.735564s total:15.879651s
[2014-08-09 04:33:49] thread 0: 16762322821 numbers, 1055579 knumbers/s
[2014-08-09 04:33:51] thread: 3 TOTAL (p0,p1,p2,p3,p4,p5,p6) = (7428641,201587,5541,164,3,0,0)
[2014-08-09 04:33:51] thread: 3 setup:0.333949s sieve1:0.153609s sieve2:3.488953s fermat:10.505618s total:14.482129s
[2014-08-09 04:33:51] thread 3: 16822808771 numbers, 1161619 knumbers/s
[2014-08-09 04:33:51] Total: 4433641 knumbers/s
[2014-08-09 04:33:51] Expected average time to block: 12839429.801994
[2014-08-09 04:33:51] accepted: 0 in 39102 seconds
and disconnected,but did not die.
I try it directly from tablet terminal

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:


Regards,

--
bsunau7

the miner for stratum is here: https://github.com/gatra/fastrie
works, but it still looks like a hack, pending tasks:

- some code cleanup, change "connected to server using xpt" line
- more robust connection error handling
- investigate why it sometimes gives 0ch/s in windows but works ok in linux

will ask dga to merge after my branch looks better

stratum server has been here for a while: https://github.com/gatra/stratum-mining



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.

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

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!

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
[2014-08-08 14:14:44] thread 1: 16806878461 numbers, 1328024 knumbers/s
[2014-08-08 14:14:45] thread: 0 TOTAL (p0,p1,p2,p3,p4,p5,p6) = (75792,2133,65,2,0,0,0)
[2014-08-08 14:14:45] thread: 0 setup:0.334116s sieve1:0.188270s sieve2:2.765245s fermat:8.097306s total:11.384937s
[2014-08-08 14:14:45] thread 0: 16739037019 numbers, 1470193 knumbers/s
[2014-08-08 14:14:46] thread: 3 TOTAL (p0,p1,p2,p3,p4,p5,p6) = (76584,2153,65,2,0,0,0)
[2014-08-08 14:14:46] thread: 3 setup:0.284316s sieve1:0.405908s sieve2:2.957543s fermat:9.159264s total:12.807031s
[2014-08-08 14:14:46] thread 3: 16694750029 numbers, 1303478 knumbers/s
[2014-08-08 14:14:46] Total: 5496150 knumbers/s
[2014-08-08 14:14:46] Expected average time to block: 10143268.019979
[2014-08-08 14:14:46] accepted: 0 in 314 seconds
[2014-08-08 14:14:46] thread: 2 TOTAL (p0,p1,p2,p3,p4,p5,p6) = (77370,2176,66,2,0,0,0)
[2014-08-08 14:14:46] thread: 2 setup:0.285636s sieve1:0.204412s sieve2:2.894155s fermat:9.073486s total:12.457689s
[2014-08-08 14:14:46] thread 2: 16699277077 numbers, 1340442 knumbers/s

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

Cool, looking forward to that:)

I am surprised old miner was still running :
[2014-08-08 09:54:04] thread: 0 TOTAL (p0,p1,p2,p3,p4,p5,p6) = (44704454,1211614,32907,844,26,0,0)
[2014-08-08 09:54:04] thread: 0 setup:0.104653s sieve1:0.050605s sieve2:1.256104s sieve3:0.000001s total:5.145437s
[2014-08-08 09:54:04] thread 0: 4287280212 numbers, 833204 knumbers/s
[2014-08-08 09:54:04] thread: 1 TOTAL (p0,p1,p2,p3,p4,p5,p6) = (44704666,1211619,32908,844,26,0,0)
[2014-08-08 09:54:04] thread: 1 setup:0.104250s sieve1:0.050860s sieve2:1.264051s sieve3:0.000001s total:5.446274s
[2014-08-08 09:54:04] thread 1: 4285468043 numbers, 786849 knumbers/s
[2014-08-08 09:54:06] thread: 2 TOTAL (p0,p1,p2,p3,p4,p5,p6) = (44704854,1211624,32908,844,26,0,0)
[2014-08-08 09:54:06] thread: 2 setup:0.103604s sieve1:0.050097s sieve2:1.200359s sieve3:0.000001s total:4.951137s
[2014-08-08 09:54:06] thread 2: 4294346790 numbers, 867329 knumbers/s
[2014-08-08 09:54:08] thread: 0 TOTAL (p0,p1,p2,p3,p4,p5,p6) = (44705021,1211630,32908,844,26,0,0)
[2014-08-08 09:54:08] thread: 0 setup:0.104176s sieve1:0.051124s sieve2:1.149726s sieve3:0.000001s total:4.513268s
[2014-08-08 09:54:08] thread 0: 4287856116 numbers, 950037 knumbers/s
[2014-08-08 09:54:08] thread: 3 TOTAL (p0,p1,p2,p3,p4,p5,p6) = (44705227,1211635,32908,844,26,0,0)
[2014-08-08 09:54:08] thread: 3 setup:0.103472s sieve1:0.049594s sieve2:1.266235s sieve3:0.000003s total:5.263346s
[2014-08-08 09:54:08] thread 3: 4287223931 numbers, 814527 knumbers/s
[2014-08-08 09:54:08] Total: 3418742 knumbers/s
[2014-08-08 09:54:08] Expected average time to block: 15505034.724386
[2014-08-08 09:54:08] accepted: 0 in 305519 seconds
------------
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 ?

WooHoo!  I can't wait to see how it hangs together!

Regards,

--
bsunau7

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!5ogMJEc2Teq5ckt9WClNpg

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).

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

hi gatra, any updates?