ckolivas won't add features for this Well, who knows, who knows.
Topic: [ANNOUNCE] Tenebrix, a CPU-friendly, GPU-hostile cryptocurrency - page 42. (Read 127234 times)
September 26, 2011, 09:19:46 AM
ckolivas won't add features for this Well, who knows, who knows.
September 26, 2011, 09:15:15 AM
I wouldn't be worrying about GPU's or even FPGAs... the first person to get this running on Amazon EC2 will been a Tenebrix millionaire.
September 26, 2011, 09:13:05 AM
ckolivas won't add features for this Well, who knows, who knows.
As for the actual scrypt - lol r=1, p=1, N=1024 so you are joking right?
Since the scrypt part was done by ArtForz, I believe it would be most welcome if you provided a more elaborate criticism and kindly informed him of your opinion, so as to prevent possible distortion of you communication and expedite formation of improvements
And like I said, even if current PoW turns out to be insufficiently good at discouraging GPU mining, it can always be updated.
The real issue is that I'd doubt anyone would bother to write a GPU version since there is no gain from the effort and there are few who are experienced at working with OpenCL ...
We shall see...but the point isn't that OpenCL version is impossible (that indeed would be a nontrivial feat), the point is that it would be not verily likely to achieve even measly improvements over CPU in same approximate price range (I haven't yet decided as to criteria of performance increase "over CPU" in GPU implementations I could use as reference for bounty establishment, and am open to suggestions
)Should such a miner happen, the author will get a bounty, and whomever submits a patch that drops GPUs down again will get a bounty (so one can submit both the optimized GPU miner and Tenebrix fix to keep such optimizations at bay)
A: Efforts shall be taken not only keep up, but peek ahead of the curve and ensure that tenebrix remains CPU friendly and GPU hostile, no matter what kind of GPUs future science will throw at us. Being FPGA and ASIC hostile is harder, given their flexibility, though frankly, if someone, at some point in time, will be willing to throw that kind of money and engineering skillz at mining Tenebix, that already makes Tenebrix a success 
You do realize the guy who helped you write the code is an authority on FPGA mining, right?
Exactimundo.
That's why implementation by ArtForz > other similar endeavors (unless proven otherwise)
It would be trivially easy for him to implement it on his FPGAs.
Like I said, fighting something as flexible as FPGAs and ASICS seems fairly absurd, and is not main subject of Tenebrix endeavor.
The main goal is to keep GPUs (both "vanilla" and "pro") out of the pool for good.
If FPGA gets harder too - neat, but no biggie. If an optimized FPGA appears, no biggie, we're primarily hunting them GPUs here.
And the only scenario under which I could see ASICs being deployed on this chain is "USA abandons dollar, embraces Tenebrix as legal tender" (and at that point all COTS hardware gets out of the pool, lol
)
September 26, 2011, 09:10:45 AM
A: Efforts shall be taken not only keep up, but peek ahead of the curve and ensure that tenebrix remains CPU friendly and GPU hostile, no matter what kind of GPUs future science will throw at us. Being FPGA and ASIC hostile is harder, given their flexibility, though frankly, if someone, at some point in time, will be willing to throw that kind of money and engineering skillz at mining Tenebix, that already makes Tenebrix a success
You do realize the guy who helped you write the code is an authority on FPGA mining, right? It would be trivially easy for him to implement it on his FPGAs.
There is an old saying somewhere about fools and their clock cycles....
September 26, 2011, 08:57:50 AM
ckolivas won't add features for this Anyway, looked at the git - no autogen.sh, configure or Makefile in https://github.com/Lolcust/Tenebrix.git
So makes it pointless.
... and I was gonna add my name to a block for this too (like almost all of the other alt-chains) oh well ...
As for the actual scrypt - lol r=1, p=1, N=1024 so you are joking right?
The real issue is that I'd doubt anyone would bother to write a GPU version since there is no gain from the effort and there are few who are experienced at working with OpenCL ...
September 26, 2011, 08:34:13 AM
Any news on fixing the Linux version? (see previous page)
September 26, 2011, 08:31:06 AM
ckolivas adds features for bounties, if it was in BTC he'd probably do it.
+1 for cgminer being the best miner out there.
+1 for cgminer being the best miner out there.
September 26, 2011, 08:25:01 AM
Which you would rather I put a bounty on, splicing Tenebrix implementation of scrypt into cgminer or further tweaking of Jgarzik's code ?
Cgminer bounty.
September 26, 2011, 08:23:25 AM
so has anyone beaten the 2 khash/sec per core barrier yet?
BTW thank you lolcust! You're the most awesome alt chain developer yet!
Yup. Phenom II X6 @ 4GHz, amd64 linuxBTW thank you lolcust! You're the most awesome alt chain developer yet!
[2011-09-26 15:17:36] thread 3: 5242 hashes, 2.59 khash/sec
[2011-09-26 15:17:36] thread 1: 5242 hashes, 2.58 khash/sec
[2011-09-26 15:17:37] thread 4: 5242 hashes, 2.58 khash/sec
[2011-09-26 15:17:37] thread 0: 5242 hashes, 2.59 khash/sec
[2011-09-26 15:17:38] thread 2: 5071 hashes, 2.58 khash/sec
[2011-09-26 15:17:38] thread 5: 5242 hashes, 2.59 khash/sec
Sweet now what about?
http://aws.amazon.com/ec2/
September 26, 2011, 08:19:21 AM
so has anyone beaten the 2 khash/sec per core barrier yet?
BTW thank you lolcust! You're the most awesome alt chain developer yet!
Yup. Phenom II X6 @ 4GHz, amd64 linuxBTW thank you lolcust! You're the most awesome alt chain developer yet!
[2011-09-26 15:17:36] thread 3: 5242 hashes, 2.59 khash/sec
[2011-09-26 15:17:36] thread 1: 5242 hashes, 2.58 khash/sec
[2011-09-26 15:17:37] thread 4: 5242 hashes, 2.58 khash/sec
[2011-09-26 15:17:37] thread 0: 5242 hashes, 2.59 khash/sec
[2011-09-26 15:17:38] thread 2: 5071 hashes, 2.58 khash/sec
[2011-09-26 15:17:38] thread 5: 5242 hashes, 2.59 khash/sec
September 26, 2011, 08:15:08 AM
so has anyone beaten the 2 khash/sec per core barrier yet?
BTW thank you lolcust! You're the most awesome alt chain developer yet!
BTW thank you lolcust! You're the most awesome alt chain developer yet!
September 26, 2011, 07:49:12 AM
I see in the tenebrix.conf , under "
#IMPORTANT STUFF BELOW! DON'T CHANGE! (Unless you REALLY know what your are doing)" there's testnet=1 . Does this mean we'll only be mining test brix currently?
#IMPORTANT STUFF BELOW! DON'T CHANGE! (Unless you REALLY know what your are doing)" there's testnet=1 . Does this mean we'll only be mining test brix currently?
No, that's just leftover Multicoin legacy. BTW check it out, Multicoin is great and has very friendly community
That didn't work out for long.. gpu hashrates slowed down too much when enabling minerd on the same cpu core. Setting a low priority for minerd didn't help. 3 threads will do for now. Using process lasso to put the threads on desired cores.
Is it possible we can use CGminer-cpuonly with this algo?
Is it possible we can use CGminer-cpuonly with this algo?
Might be, if someone mods it
Also, I think that it might be possible to limit the Tenebtix miner so that amount of punishment it dishes out per core can be tweaked more effectively. I think I will put a decent-ish bounty on that slightly later.
EDIT:
Which you would rather I put a bounty on, splicing Tenebrix implementation of scrypt into cgminer or further tweaking of Jgarzik's code ?
September 26, 2011, 07:36:55 AM
I see in the tenebrix.conf , under "
#IMPORTANT STUFF BELOW! DON'T CHANGE! (Unless you REALLY know what your are doing)" there's testnet=1 . Does this mean we'll only be mining test brix currently?
#IMPORTANT STUFF BELOW! DON'T CHANGE! (Unless you REALLY know what your are doing)" there's testnet=1 . Does this mean we'll only be mining test brix currently?
September 26, 2011, 07:32:03 AM
That didn't work out for long.. gpu hashrates slowed down too much when enabling minerd on the same cpu core. Setting a low priority for minerd didn't help. 3 threads will do for now. Using process lasso to put the threads on desired cores.
Is it possible we can use CGminer-cpuonly with this algo?
Hashrates (average per core) (default settings)
C2D E6750: 1.25 khash/sec
i5 2500K: 1.67 khash/sec
Is it possible we can use CGminer-cpuonly with this algo?
Hashrates (average per core) (default settings)
C2D E6750: 1.25 khash/sec
i5 2500K: 1.67 khash/sec
September 26, 2011, 07:26:50 AM
when does the difficulty get readjusted?
September 26, 2011, 07:21:36 AM
Seems like an unstable buggy piece of crap. Ever heard of testing?
Actually, it has been tested and behaves quite well on windows so far.
Linux, alas, received less love, but hey, I'm a Windoze addict and just one oddball linux bug reported so far, we're going fine and will certainly get better.
But thanks for your opinion
thanks, switching -s to 5 fixes it.
I'm getting 1.2-3khashes on my [email protected] and 1.08khash on my sisters q8200.
I'm getting 1.2-3khashes on my [email protected] and 1.08khash on my sisters q8200.
I had --s 120
now I have --s 5 and I still get boooo's
Try different values, some peeps have other numbers working better. Also, what are your hashrates ?
Thank you Lolcust for the generous starting bounty!
Been mining during the night with 2 spare cores on my i5 2500k (Dedicated one core to 100% cpu bug for gpu mining and one core left free for system stability.) and my second rig is mining with C2D E6750. Found nearly 30 blocks so far.
Will unleash it on all of the i5 cores during the day to see how it affects overall system performance and gpu mining.
Been mining during the night with 2 spare cores on my i5 2500k (Dedicated one core to 100% cpu bug for gpu mining and one core left free for system stability.) and my second rig is mining with C2D E6750. Found nearly 30 blocks so far.
Will unleash it on all of the i5 cores during the day to see how it affects overall system performance and gpu mining.
Ya welcome, please report back
September 26, 2011, 07:18:58 AM
Seems like an unstable buggy piece of crap. Ever heard of testing?
September 26, 2011, 07:03:14 AM
Thank you Lolcust for the generous starting bounty!
Been mining during the night with 2 spare cores on my i5 2500k (Dedicated one core to 100% cpu bug for gpu mining and one core left free for system stability.) and my second rig is mining with C2D E6750. Found nearly 30 blocks so far.
Will unleash it on all of the i5 cores during the day to see how it affects overall system performance and gpu mining.
Been mining during the night with 2 spare cores on my i5 2500k (Dedicated one core to 100% cpu bug for gpu mining and one core left free for system stability.) and my second rig is mining with C2D E6750. Found nearly 30 blocks so far.
Will unleash it on all of the i5 cores during the day to see how it affects overall system performance and gpu mining.
September 26, 2011, 07:02:53 AM
thanks, switching -s to 5 fixes it.
I'm getting 1.2-3khashes on my [email protected] and 1.08khash on my sisters q8200.
I'm getting 1.2-3khashes on my [email protected] and 1.08khash on my sisters q8200.
I had --s 120
now I have --s 5 and I still get boooo's
September 26, 2011, 06:33:11 AM
cpu-miner.c:786: warning: passing argument 2 of ‘json_load_file’ makes integer from pointer without a cast
/usr/include/jansson.h:221: note: expected ‘size_t’ but argument is of type ‘struct json_error_t *’
cpu-miner.c:786: error: too few arguments to function ‘json_load_file’
/usr/include/jansson.h:221: note: expected ‘size_t’ but argument is of type ‘struct json_error_t *’
cpu-miner.c:786: error: too few arguments to function ‘json_load_file’
You'll need to tweak the call to json_loads. It changed the number of arguments it accepted between the 1.x and 2.x versions of libjansson.
I followed the README doc:
Code:
Basic *nix build instructions:
./autogen.sh # only needed if building from git repo
CFLAGS="-O3 -Wall -msse2" ./configure
make
autogen whines:
Code:
./autogen.sh
configure.ac:95: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body
../../lib/autoconf/lang.m4:194: AC_LANG_CONFTEST is expanded from...
../../lib/autoconf/general.m4:2662: _AC_LINK_IFELSE is expanded from...
../../lib/autoconf/general.m4:2679: AC_LINK_IFELSE is expanded from...
../../lib/m4sugar/m4sh.m4:606: AS_IF is expanded from...
../../lib/autoconf/general.m4:2032: AC_CACHE_VAL is expanded from...
../../lib/autoconf/general.m4:2053: AC_CACHE_CHECK is expanded from...
/usr/share/aclocal/libcurl.m4:38: LIBCURL_CHECK_CONFIG is expanded from...
configure.ac:95: the top level
configure.ac:95: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body
../../lib/autoconf/lang.m4:194: AC_LANG_CONFTEST is expanded from...
../../lib/autoconf/general.m4:2662: _AC_LINK_IFELSE is expanded from...
../../lib/autoconf/general.m4:2679: AC_LINK_IFELSE is expanded from...
../../lib/m4sugar/m4sh.m4:606: AS_IF is expanded from...
../../lib/autoconf/general.m4:2032: AC_CACHE_VAL is expanded from...
../../lib/autoconf/general.m4:2053: AC_CACHE_CHECK is expanded from...
aclocal.m4:59: LIBCURL_CHECK_CONFIG is expanded from...
configure.ac:95: the top level
configure.ac:95: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body
../../lib/autoconf/lang.m4:194: AC_LANG_CONFTEST is expanded from...
../../lib/autoconf/general.m4:2662: _AC_LINK_IFELSE is expanded from...
../../lib/autoconf/general.m4:2679: AC_LINK_IFELSE is expanded from...
../../lib/m4sugar/m4sh.m4:606: AS_IF is expanded from...
../../lib/autoconf/general.m4:2032: AC_CACHE_VAL is expanded from...
../../lib/autoconf/general.m4:2053: AC_CACHE_CHECK is expanded from...
aclocal.m4:59: LIBCURL_CHECK_CONFIG is expanded from...
configure.ac:95: the top level
configure.ac:95: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body
../../lib/autoconf/lang.m4:194: AC_LANG_CONFTEST is expanded from...
../../lib/autoconf/general.m4:2662: _AC_LINK_IFELSE is expanded from...
../../lib/autoconf/general.m4:2679: AC_LINK_IFELSE is expanded from...
../../lib/m4sugar/m4sh.m4:606: AS_IF is expanded from...
../../lib/autoconf/general.m4:2032: AC_CACHE_VAL is expanded from...
../../lib/autoconf/general.m4:2053: AC_CACHE_CHECK is expanded from...
aclocal.m4:59: LIBCURL_CHECK_CONFIG is expanded from...
configure.ac:95: the top level
BTW, client compiles fine but in Gentoo you probably need top add '-I/usr/include/db4.8/' to 'make' (if you get a can not find db_cxx.h error)
Can someone tweak the call to json_loads adn push it to git?
Jump to: