[ANN][RIC] Riecoin: constellations POW *CPU* HARD FORK successful, world record

[gatra]

Gatra, what are you waiting for with the wallet fixes ?!

Posted on 23. Apr :

Worst client ever! Takes 2 minutes to start on an i7. 5 minutes when using -rescan arg.  Fresh install/syncing the blockchain takes longer than bitcoin...
Dev, fix the client. this is ridiculous..

EDIT : Forgot to mention, keep the wallet running for a couple of days, interface says connected. Try to send coins - unable/offline.
EDIT2 : Try to rebroadcast an offline transaction using -rescan, nothing happanes after 30 min! Now i have to export/import priv keys !! Shittiest out of all ALT wallets!

I did noticed it was slower than bitcoin wallet. Could it be due to the data size needed to store the long prime digits? Progressively, it will require alot more disk space?

Hey, I'm not waiting, it's just that it's a lot of work.

The extra data is minimal, the overhead is in the verification - which will be optmized a lot in next version. Also, since v0.9.1 block headers are downloaded before the rest of the blocks, this allows for block downloading in parallel, which will further speed up the sync process.

EDIT: not only the extra data is minimal, it will remain constant regardless of prime size increasing because only a 256bit offset for the first prime in the tuple is stored.

[1715019487]

1715019487

[1715019487]

1715019487

[1715019487]

1715019487

[northranger79510]

Gatra, what are you waiting for with the wallet fixes ?!

Posted on 23. Apr :

Worst client ever! Takes 2 minutes to start on an i7. 5 minutes when using -rescan arg.  Fresh install/syncing the blockchain takes longer than bitcoin...
Dev, fix the client. this is ridiculous..

EDIT : Forgot to mention, keep the wallet running for a couple of days, interface says connected. Try to send coins - unable/offline.
EDIT2 : Try to rebroadcast an offline transaction using -rescan, nothing happanes after 30 min! Now i have to export/import priv keys !! Shittiest out of all ALT wallets!

I did noticed it was slower than bitcoin wallet. Could it be due to the data size needed to store the long prime digits? Progressively, it will require alot more disk space?

Hey, I'm not waiting, it's just that it's a lot of work.

The extra data is minimal, the overhead is in the verification - which will be optmized a lot in next version. Also, since v0.9.1 block headers are downloaded before the rest of the blocks, this allows for block downloading in parallel, which will further speed up the sync process.

EDIT: not only the extra data is minimal, it will remain constant regardless of prime size increasing because only a 256bit offset for the first prime in the tuple is stored.

+1. I am sure you guys want everything to be quick but I'd rather the dev. take time, do it right and release it. I hang around with very talented developers and every projects takes them weeks/months/years to complete depending on the difficulties. Wanting to complete it in less than 2 weeks takes 24h dedication which normal working people can't afford.

[aamarket]

I was very disappointed with __MY__ vmware virtual machine setup and latest xptminer.
It runs quite well on linux / quad core intel - [00:25:04] 2ch/s: 27.1115 3ch/s: 1.6259 4ch/s: 0.0626 Shares total: 23 / 22 (around ?3GB? RAM USED)
but it gives less than 1/5 on virtual machine. Strange. Needs an investigation, or help please ...

[Bigtruck45]

https://bitcointalk.org/index.php?topic=596232.new#new

[Spiff637]

Has anyone had any luck getting the B15 build compiled on windows 7 64? I did see a build a few pages back, but it dies after about 15 shares..     Also I am curious of which version of the miner people with Xeon Chipsets such as the E5-2650 CPU.    One one of my workstations I'm getting around 65 3 ch/s  3.9  4 ch/s but the other is 75 3ch/s and 5.5 ch/s etc..   any thoughts?

Thank you!

[northranger79510]

Bump

[primer10]

Has anyone had any luck getting the B15 build compiled on windows 7 64? I did see a build a few pages back, but it dies after about 15 shares..     Also I am curious of which version of the miner people with Xeon Chipsets such as the E5-2650 CPU.    One one of my workstations I'm getting around 65 3 ch/s  3.9  4 ch/s but the other is 75 3ch/s and 5.5 ch/s etc..   any thoughts?

Thank you!

no one bothered to compile using Cygwin (64bits edition)? It should work ..

[Gaoweida]

New paper wallet design on riecoinfoundation.org/PaperWallet. Check it out! Credits go to our wonderful foundation member, Antoine who made the design! Cheesy Thank you

[Spiff637]

Has anyone had any luck getting the B15 build compiled on windows 7 64? I did see a build a few pages back, but it dies after about 15 shares..     Also I am curious of which version of the miner people with Xeon Chipsets such as the E5-2650 CPU.    One one of my workstations I'm getting around 65 3 ch/s  3.9  4 ch/s but the other is 75 3ch/s and 5.5 ch/s etc..   any thoughts?

Thank you!

no one bothered to compile using Cygwin (64bits edition)? It should work ..

Good point..  I will try to do it right now.. wish me luck, because I will need it. 

[coinfusion]

Has anyone had any luck getting the B15 build compiled on windows 7 64? I did see a build a few pages back, but it dies after about 15 shares..     Also I am curious of which version of the miner people with Xeon Chipsets such as the E5-2650 CPU.    One one of my workstations I'm getting around 65 3 ch/s  3.9  4 ch/s but the other is 75 3ch/s and 5.5 ch/s etc..   any thoughts?

Thank you!

I got B15 compiled with mingw64 gcc 4.8.2, but it crashes if the -s command-line parameter is set above 400million.  Worked fine for 48 hours with it set to 400million though (8-core non-AVX machine with 8gb).  Performance is about the same as B14.  Going to attempt to rebuild my environment with gcc4.9 this weekend, will post again if results change!

[aamarket]

I tried cygwin compilation, no success ... see https://bitcointalk.org/index.php?topic=446703.msg6425707#msg6425707

I tried with ARM 4core - too slow, like 1/100 of Intel, and strange error - any ideas ?


[00:02:38] Share found! (Blockheight: 50855)
Invalid share
Reason: CheckProofOfWork() : not valid pow
1755[00:02:40] 2ch/s: 0.1792 3ch/s: 0.0512 4ch/s: 0.0256 Shares total: 1 / 0
1755[00:02:48] 2ch/s: 0.1950 3ch/s: 0.0488 4ch/s: 0.0244 Shares total: 1 / 0
1755[00:02:56] 2ch/s: 0.2095 3ch/s: 0.0465 4ch/s: 0.0233 Shares total: 1 / 0
1755[00:03:04] 2ch/s: 0.2003 3ch/s: 0.0445 4ch/s: 0.0223 Shares total: 1 / 0

ideas welcome

[dga]

I tried cygwin compilation, no success ... see https://bitcointalk.org/index.php?topic=446703.msg6425707#msg6425707

I tried with ARM 4core - too slow, like 1/100 of Intel, and strange error - any ideas ?


[00:02:38] Share found! (Blockheight: 50855)
Invalid share
Reason: CheckProofOfWork() : not valid pow
1755[00:02:40] 2ch/s: 0.1792 3ch/s: 0.0512 4ch/s: 0.0256 Shares total: 1 / 0
1755[00:02:48] 2ch/s: 0.1950 3ch/s: 0.0488 4ch/s: 0.0244 Shares total: 1 / 0
1755[00:02:56] 2ch/s: 0.2095 3ch/s: 0.0465 4ch/s: 0.0233 Shares total: 1 / 0
1755[00:03:04] 2ch/s: 0.2003 3ch/s: 0.0445 4ch/s: 0.0223 Shares total: 1 / 0

ideas welcome

32 bit is unlikely to work.  There are spots in the code that require that gmp is 64 bit, I'm pretty sure.  Let me get an ARM port on the longer-term to look at list, though.  That'd be fun.

[aamarket]

I am not a day to day programmer - but I would like to challenge that
I believe GMP is just a bignum library and it is present and working well on arm.
As well as 64 bit values can be (and probably are) emulated by the compiler with 32 bit instructions.
Let me grab a cup of coffee and give me 2 hours

[Supercomputing]

I am not a day to day programmer - but I would like to challenge that
I believe GMP is just a bignum library and it is present and working well on arm.
As well as 64 bit values can be (and probably are) emulated by the compiler with 32 bit instructions.
Let me grab a cup of coffee and give me 2 hours

Check and verify the size of your data types. Make sure that the size of your 64-bit (long) data type is really 8 bytes and not 4 bytes. Sometimes you have to use (long long) for 64-bit data type.

[aamarket]

I know, should be fine, but will double check later ... giving up right now,
but problems found : around 50 "Conditional jump or move depends on uninitialised value(s)" when running valgrind,
leaving to run and crash to collect all errors

[dga]

I am not a day to day programmer - but I would like to challenge that
I believe GMP is just a bignum library and it is present and working well on arm.
As well as 64 bit values can be (and probably are) emulated by the compiler with 32 bit instructions.
Let me grab a cup of coffee and give me 2 hours

Perhaps I didn't state it clearly.  The code *in the miner* makes some assumptions about the internal GMP data structures.  Some of it is code inherited from the initial xptMiner that I haven't looked at very deeply because it was just working, such as parts of the code relating to share submission:

(this is in an ifdef win64, but it gives you a taste of what's there:

 *(uint64*)(nOffset+d* = z_temp2->_mp_d[d];

)

I haven't tested any of that outside of x86 and have no idea how robust it is.

I also wasn't as careful as I should have been about making sure I didn't have any weird size assumptions in my parts of the code.  The one Supercomputing noted is a quite possible bug - while I tried to use (u)int64_t in any place I touched, there's still room for cleanup.

And, finally, there's that windows bug that I haven't tracked down that's *probably* just a generic buffer overwrite somewhere that isn't killing linux due to differences in memory allocation.  That might be biting you on arm.

More time to work on Riecoin again starting next week.

[aamarket]

I agree, dga, and I know, but ... just few lines below ifdef ... else ... *(uint32*)(nOffset+d*4) = z_temp2->_mp_d[d];
and it was in the code since the beginning. But to be sure, I'll double check.
I know (u)intXX_t is the right way, I already burned myself doing data exchange x64<->mips32 long time ago
I think I replaced some in some previous miner version, doing cleanup as well, but your version is far more superior, so I ditched old changes.
regarding win - that was exactly what I was thinking
but no results yet apart from "uninitialized values" seem to be in the libraries and/or old kernel (so no apparent problem in the code),
killed in valgrind soon because with sieve=9e8 its close to my memory limit,
and that I checked couple returned triplets, they seem to be primes (like p - 4,  p - 6,  p - 16 ; p - 4,  p - 12,  p - 16 ; p - 4,  p - 10,  p - 16 ; ....)
Which points us to your original point

I'll post some results soon, but the speed is horrible and it does not make sense to run on this ARM architecture

[dga]

I agree, dga, and I know, but ... just few lines below ifdef ... else ... *(uint32*)(nOffset+d*4) = z_temp2->_mp_d[d];
and it was in the code since the beginning. But to be sure, I'll double check.
I know (u)intXX_t is the right way, I already burned myself doing data exchange x64<->mips32 long time ago
I think I replaced some in some previous miner version, doing cleanup as well, but your version is far more superior, so I ditched old changes.
regarding win - that was exactly what I was thinking
but no results yet apart from "uninitialized values" seem to be in the libraries and/or old kernel (so no apparent problem in the code),
killed in valgrind soon because with sieve=9e8 its close to my memory limit,
and that I checked couple returned triplets, they seem to be primes (like p - 4,  p - 6,  p - 16 ; p - 4,  p - 12,  p - 16 ; p - 4,  p - 10,  p - 16 ; ....)
Which points us to your original point

I'll post some results soon, but the speed is horrible and it does not make sense to run on this ARM architecture

Is your GMP using NEON?  I suspect that in general, GMP is far less tuned on ARM than on x86, but it's worth being sure it's at least trying to use the vectors.

[cphr]

Hello, dga. In b15 code, update_remainders function, there is line (riecoinMiner.cpp, line 310 on github)

Code:

remainders[i] = remainder;

It seems like remainders array is not used in code anymore and not needed malloc for it too. Or maybe i'm wrong.

[ipadbroken]

 paper wallet design on riecoinfoundation.org/PaperWallet. Check it out! Credits go to our wonderful foundation member, Antoine who made the design! Cheesy Thank you Antoine!