|
Well, if multicoin-qt builds on osx so should tbx, so "only" a matter of finding someone willing, able and trustworthy to build a binary...
|
|
|
|
|
0.015625 currently, looks like next diff will be 0.0625.
|
|
|
|
|
Doesn't sound too far-fetched, wouldn't be terribly surprised if the biggest single-GPU card ends up around 3.2-3.5Mh/J or so and a downclocked dual-GPU variant at least close to 4Mh/J.
|
|
|
|
How much harder is mining Tenebrix versus mining Bitcoin? By my calculation, I should get about 1000 as many TBX than I'm getting right now given my hashrate and the current difficulty. ArtForz, can you comment?
Very roughly a factor of 1000. PhenomII hexcore here gets ~20Mh/s for BTC, ~20kh/s TBX. Ok, but is the same factor applied to the expected time to find a block? Let say the difficulty is 0.015625 and you are mining at 1 kh/s, how long does it take to find a block on average? In other words, how many hashes do you need to find a block on average? Nope, difficulty works as in bitcoin, so at 20kH/s and difficulty 0.015625 you'd expect to find a block every 2^32 * 0.015625 / 20000 seconds on average (= ~56 minutes). |
|
|
|
How much harder is mining Tenebrix versus mining Bitcoin? By my calculation, I should get about 1000 as many TBX than I'm getting right now given my hashrate and the current difficulty. ArtForz, can you comment?
Very roughly a factor of 1000. PhenomII hexcore here gets ~20Mh/s for BTC, ~20kh/s TBX. |
|
|
|
The algorithm was written by an fpga expert and it runs very well on fpgas (shockingly) and not so well on gpus.
Hey, that's news to me, so far my math and synthesis attempts say it'll suck on FPGAs, too. (wow, a algorithm designed to be expensive on specialized hardware ends up expensive on specialized hardware). so... [citation needed] or stop spreading FUD. Hmm and here I thought you had the necessary skills to efficiently program fpgas to solve blocks using an algorithm you wrote. My apologies. There are a handful of people on this board with the knowledge and equipment to try and implement this on FPGAs. I am not one of them and therefore must concede the point. The rest of what I wrote is true. Wait, what? an algorithm *I* designed? Rule #1 of cryptography: do not design your own algorithms. What I did was modify multicoin to make replacing the block PoW hashing function easier, then plugged in scrypt ( http://www.tarsnap.com/scrypt.html) with parameters of N=1024, p=1, r=1, feeding in the block header as password and salt, output size of 32 bytes. While those parameters would be way too low for a good password hashing/key derivation function (you want lots of margin for the future there), my initial educated guess and further experiments suggest they're still enough to "pessimize" current GPUs and FPGAs to a point where CPUs will easily be competitive... GPUs growing several MB of fast random access on-chip memory in the future might change that. And yes, choosing such "unusual" parameters is skirting the rule, but in this case imo acceptable risk. Worst case... someone manages to make a "efficient enough" GPU/FPGA/... implementation or a new gen of GPUs comes out, scheduled chain fork switching to higher N and p. Up to N=4096,p=8,r=1 or so time to verify the PoW hash on a CPU shouldn't be an issue, beyond that you'd have to add some measures to prevent "junk block spam" DoS. |
|
|
|
Yep, and price/perf is where FPGAs fall flat on their face. Why? Well, even at-cost a LX150 box still ends up at > $1/Mhps. And expected resale value is damn near 0. With GPUs not only is the initial cost lower, but when the next generation comes around you can resell them for somewhere around 50-70% of the initial cost, keep the rest of the system and replace them with their successors. If those end up about 40% better price/perf and perf/power (not totally unreasonable), you'd end up with the same hashrate as before but now using only 60% of the power. Repeat as often as necessary. Another benfit of that, with the short product cycles of GPUs, they'll be pretty much in warranty forever. So... why even bother with FPGAs then, other than being low power? Well... density (32 LX150s in a 2U = trivial, 48 = still no big problem) and reliability/low maintenance (server grade PSU, 80mm fans with > 60kh expected lifetime, ...) And of course having your own FPGA cluster to play with  |
|
|
|
The algorithm was written by an fpga expert and it runs very well on fpgas (shockingly) and not so well on gpus.
Hey, that's news to me, so far my math and synthesis attempts say it'll suck on FPGAs, too. (wow, a algorithm designed to be expensive on specialized hardware ends up expensive on specialized hardware). so... [citation needed] or stop spreading FUD. |
|
|
|
|
Huh? Heavily undervolted GPUs coming even *close* to FPGAs? Seriously?
So far the best I've seen from GPUs even with extreme undervolting is ~ 3Mh/J at the wall.
My first 32*LX150 box with a power-hungry mobo, WAY overkill fans and running at 1250mV Vccint? 6.27Gh at 382W at the wall, thats a bit > 16Mh/J.
A more optimized design, no overvolting, > 20Mh/J at the wall.
And S6s are real power hogs compared to higher-end chips, smallish V6 and Stratix IVs get >30Mh/J easily (at atrocious price/perf, but hey...).
For the math impaired, 20Mh/J at current difficulty -> 1BTC ~= 2kWh, that's $0.60/BTC at "european" $0.30/kWh and around $0.20/BTC at $0.10/kWh... yeah.
|
|
|
|
But my comment about that table is that either the first line is wrong or misread.
A HD6970 will do 100x a typical CPU and certainly at LEAST 10x any CPU the same price as it.
That table says double-sha256 1:120
So unless it is totally crap, that can only mean CPU:GPU
Then the next line says scrypt(1024,1,1) 1:5.2
Which would mean GPU is 5.2 times faster.
Now, I have no idea where he pulled those number out of ... but reading that table says GPU will be 5.2 time CPU on N=1024,p=1,r=1
I'm not saying the table is based on real info, just that it doesn't match what's written and just switching the numbers would simply mean they are not reliable at all.
No, thats *one 3GHz K10 CPU core* vs. a HD6970 A 3GHz K10 core is roughly 3Mh/s doing double-sha256 aka bitcoinhash. A stock HD6970 is about 360-400Mh/s for bitcoinhash. Hey look, 3:360 == 1:120, a miracle! So yes, the factor of 1:5.2 is for ONE CPU CORE vs. a 6970. For the math or comprehension impaired, thats "A hex(=6)core PhenomII at 3GHz is a few % faster than a HD6970" And this is from actual measurements of real code running on real devices, not some "well, in theory it *should* be possible" numbers that overlook massive problems on real hardware. So... where is any written performance info for GPUs doing scrypt variants? The original paper only deals with VLSI, any citations? So I went for the "well, to get some numbers I'll actually have to try to write a optimized implementation" approach. So... maybe your GPU is 100 times faster than a CPU executing pure ALU code, but to do that you actually need to... like... store the per-thread state somewhere? So, where to put 128KiB (or 32 KiB using a factor 4 time/space tradeoff) of memory for V *per thread*? Registers? Way too small. LDS - works, but you only got 64KiB/CU so you end up with a max of 2 threads/CU even with a factor 4 time/space tradeoff GDS? way too small again. L2 read cache? You got 512k of that, so with a /4 reduction you can keep 16 threads worth of V arrays there, but that's not really helping a whole lot due to reasons I'll explain shortly. External GDDR5? Completely horrible for randomly reading 128 byte items all over the place. Now, ATI GPUs are funny beasts, they use something best described as "hyperthreading" similar to a niagara CPU to hide their 4-clock instruction latency. Which means you need to be executing 64 threads in parallel to make full use of a CU (16 VLIW4 cores * 4 deep pipeline). Best option so far is "use LDS, live with only being able to run 2 threads/CU (due to LDS size)... welll... thanks to what I explained above, that means you're effectively getting ALU throughput of half of one VLIW4 core per CU per clock. So a whole 6970 ends up effectively performing as if you only had 12 fully utilized VLIW4 cores. Well, turns using this approach in the real world, at 880MHz core clock and with overhead it actually manages roughly 5.2 times the performance of a single 3GHz K10 core. So, if you have any constructive suggestions on what other approaches to try to wrangle better performance out of a AMD GPU for this variant of scrypt, I'm listening. Inb4 obvious, first thing I tried was the KISS "just allocate a huge buffer for V arrays in global memory, run 64-256 threads and have the mem and L2 controllers figure it out." approach. also with time/space tradeoff factors of 2 to 16. Ends up slower than going with LDS. |
|
|
|
|
Yep, it's still very unoptimized.
Just compiling scrypt.c in cpuminer with -O3 on amd64 linux ends up at 3.28kH/s/core on a AthlonII @ 3.6GHz.
|
|
|
|
|
Option #2, giving up most of the memory-hardness to get a primitive useful for a iterated hashing PoW.
Parameters used are N=1024,p=1,r=1 -> 128KiB of V.
Not exactly much, but enough to give current gen GPUs a major headache.
Basically, instead of aiming for "enough memory use to hit external memory on any device", aiming for "small enough to fit in L2 cache on CPUs, big enough to require too much on-chip memory/cache for running enough parallel instances to make GPU/FPGA/VLSI worth it."
If a future generation of GPUs has several MB of fast on-chip cache (which would make em competitive), a forced update with increased memory usage and parallelism is on the wall (e.g. N=4096, p=4 or 8 ).
And it'd still be "fast enough" to not cause too much of an issue with speed of verifying PoW, with N=4096,p=8 still only ~20ms per hash on a current decent CPU core.
Notice that N=4096 p=8 r=1 is one of the parameter sets used in the scrypt paper for relative cost on specialized hardware.
using the same cost/area figures for VLSI as the paper, rough relative estimates:
md5=1
double-sha256=6
scrypt(1024,1,1)=1000000
scrypt(4096,8,1)=40000000
Or let's put it another way, best relative performance achieved real-world for sha256(sha256()), scrypt(1024,1,1), scrypt(4096,2,1) and scrypt(4096,8,1) for a 3GHz K10 core vs. a HD6970
double-sha256 1:120
scrypt(1024,1,1) 1:5.2
scrypt(4096,2,1) 1:3.7
scrypt(4096,8,1) 1:4.4
That's without using vector instructions on the CPU, using a time-memory tradeoff for scrypt on the HD6970 that only stores 1/4 or 1/8 of V values and recreates the missing ones on the fly, straightforward GPU version was slower by a factor of 3-5.
|
|
|
|
|
It's 2016 blocks with *4 /4 limits like bitcoin, just with 5 min nominal/block.
Min difficulty is 1/4096 to account for scrypt(N=1024,p=1,r=1) being well over a factor 1000 slower than sha256(sha256()).
There's no cmdline daemon yet, porting the multicoin-qt->tenebrix changes to multicoin should be pretty trivial.
|
|
|
|
I must be missing something here.
Is there a some type of help doc or what ever on how to run this miner in linux?
I managed to get it going but it must have been a flook. I'm running kubuntu. $ ./minerd --debug --user 1 --pass 1
[2011-09-26 17:57:35] Binding thread 0 to cpu 0
[2011-09-26 17:57:35] HTTP request failed: couldn't connect to host
[2011-09-26 17:57:35] json_rpc_call failed, retry after 30 seconds
[2011-09-26 17:57:36] Binding thread 1 to cpu 1
[2011-09-26 17:57:37] 2 miner threads started, using SHA256 'scrypt' algorithm.
[2011-09-26 17:58:05] HTTP request failed: couldn't connect to host
[2011-09-26 17:58:05] json_rpc_call failed, retry after 30 seconds
...
[2011-09-26 18:02:35] workio thread dead, exiting.
forgot --url http://127.0.0.1:8697/ ? |
|
|
|
bobnova@bobnova-P67A-UD4-B3:~/Tenebrix-miner$ CFLAGS="-O3 -Wall -msse2" ./configure
checking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-unknown-linux-gnu
checking target system type... x86_64-unknown-linux-gnu
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... no
checking for mawk... mawk
checking whether make sets $(MAKE)... yes
checking whether to enable maintainer-specific portions of Makefiles... no
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking for style of include used by make... GNU
checking dependency style of gcc... gcc3
checking how to run the C preprocessor... gcc -E
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking whether gcc needs -traditional... no
checking whether gcc and cc understand -c and -o together... yes
checking for ranlib... ranlib
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking syslog.h usability... yes
checking syslog.h presence... yes
checking for syslog.h... yes
checking for working alloca.h... yes
checking for alloca... yes
checking for json_loads in -ljansson... yes
checking for pthread_create in -lpthread... yes
checking for yasm... /usr/bin/yasm
checking if yasm version is greater than 1.0.1... yes
checking for pkg-config... /usr/bin/pkg-config
checking pkg-config is at least version 0.9.0... yes
./configure: line 4977: syntax error near unexpected token `,'
./configure: line 4977: `LIBCURL_CHECK_CONFIG(, 7.10.1, ,'
bobnova@bobnova-P67A-UD4-B3:~/Tenebrix-miner$
Thoughts? Got the client working. Hard to mine without a miner though. on debian/ubuntu, install one of the libcurl4-dev packages |
|
|
|
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 linux [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 |
|
|
|
|
the database format itself is compatible, the transaction logs are not. remove /database/log.* while bitcoind is stopped and you can happily switch from bdb5.1 back to 4.6 and similar stunts.
|
|
|
|
|
Show Posts
