[ANN][BLC] Blakecoin Blake-256 for GPU/FPGA With Merged Mined Pools Stable Net

[rupy]

Cgminer will display the current clock speed per device, and the logfile will mark the clock speed changes. You should see the clock speed ramping up, roughly one 4MHz step every few minutes, until HW errors start increasing, at which point it will back off a step. Its this speed that you should then hardwire into the startup script (it may be slightly different for each device)

How can I see device info if I have to run with -T?

How can I independently configure device MHz?

[kramble]

How can I see device info if I have to run with -T?

The clock speed changes are in the log file (its quite safe to view this while cgminer is running, use notepad or similar, and reload often). Unfortunately the HW count and other stats are not available (though using --verbose will give some additional info, and --debug even more, though I wouldn't normally run with these). (edit) Actually, you may have to use --verbose to see the clock speed changes in the log file (I lied when I said I didn't normally run with this).

How can I independently configure device MHz?

See the README


--ztex-clock 180:192,184:196,180:204,192:212        set individual fpga device speeds


But I'd fix the clock by setting min and max the same

--ztex-clock 180:180,184:184,204:204,192:192


Its the same style of syntax as the icarus parameters in the original cgminer README (because I just copied the code), vis: colon for ranges, comma to separate devices. The example given is for a single 1.15y board, but it ought to work the same way with multiple 1.15x boards.

[bzyzny]

From my own tests on Blake with my GPU rigs show they draw less power from the wall than either scrypt or sha-256 for the same mining process, this also effects fan noise and heat output!

Doesn't this just mean that the GPU code has plenty of room for optimization? (If the code is already well optimized, you could at least run the GPU at a higher frequency.)

I agree on the statistical points, and I like the idea of an FPGA/ASIC friendly function vs. artificially complicated ones that end up wasting more power. However, I don't see how the efficiency can be meaningfully compared between different functions.

Good question and hopefully someone can give a better answer than I'm about to. My deduction is that Blake can use less power because it does not require as many sections of the GPU to do its calculations. A GPU can do a wide range of calculations, but blake only needs a few of them. The types of calculations have an impact on power draw. And scrypt maxes out memory usage (Blake does not) which contributes to power consumption. Of course its totally possible that the opencl code could be improved to get even higher hashrates at the cost of higher power consumption, but cgminer already reports my GPUs are kept at a steady 99% activity. Its definitely noticeable how much less power mining blakecoin needs, and my GPUs run way cooler and are stable at higher overclocks. This is a huge advantage! Hopefully my answer was helpful and more importantly, accurate

[teknohog]

Doesn't this just mean that the GPU code has plenty of room for optimization? (If the code is already well optimized, you could at least run the GPU at a higher frequency.)

Good question and hopefully someone can give a better answer than I'm about to. My deduction is that Blake can use less power because it does not require as many sections of the GPU to do its calculations. A GPU can do a wide range of calculations, but blake only needs a few of them. The types of calculations have an impact on power draw. And scrypt maxes out memory usage (Blake does not) which contributes to power consumption. Of course its totally possible that the opencl code could be improved to get even higher hashrates at the cost of higher power consumption, but cgminer already reports my GPUs are kept at a steady 99% activity. Its definitely noticeable how much less power mining blakecoin needs, and my GPUs run way cooler and are stable at higher overclocks. This is a huge advantage! Hopefully my answer was helpful and more importantly, accurate

Ah, of course -- it's like a CPU task that only does fixed point math, so there are unused FPU resources. (I guess I was thinking in an FPGA sense where you can allocate all of the silicon to any task.) The comparison to Scrypt is obvious, then. However, I'd expect Blake to use similar GPU resources as sha256 when fully optimized.

Also, the 99% figure doesn't mean anything -- you can max out a CPU with an idle loop, for example.

[BlueDragon747]

performance wise(resource usage) it is similar to sha-256 as blake-256 was intended to replace it  

it is also a semi parallel structure compared with both SHA-256 or Scrypt hence why it needs less rounds, it should also do well with vector math functions. http://www.youtube.com/watch?v=PgpJNRnx6eY

Blake uses quite simple primitives so it should never really stress a card like Scrypt and it does not need huge memory so uses less power there, I wanted a hash function that did not use all resources as I wanted to be able to play my MMO games with the mining in background  

You could optimize it further but its only about 3% off the usage on SHA-256 so I don't think there is as much to gain as you might think, best to just overclock the cards, I was able to maintain higher clocks running Blake during my tests but 24/7 I run them same as SHA-256, on Scrypt you cannot run the memory as low same would be true for any memory hard algo they are just wasteful for this type of task, good for maybe storing passwords in databases but not mining!  

atm Blake does not do well on Nvidia cards due to the fact you need the miner in CUDA not OpenCL to get performance from them, I have asked the CUDA miner dev's but got no reply  

with Blake it is a win-win as you get 2x-3x more hashes for a similar power budget compared with SHA-256, this is progress which is what I am more used to in technology, if someone tried to sell you a new processor for your PC that used more power and did less compute you would not be happy, this is the case with Scrypt no improvement over SHA-256

the common measurement for hash function is in hash/Watt, hash/Joule, Cycles per byte all of these Blake-256 wins over both SHA-256 or Scrypt  
*assumes same platform or manufacturing process  

[rupy]

Here we go, how I miss the early days of bitcoin mining!

Code:

[2014-01-20 22:53:25] ZTEX 04A346E2B9-1: Frequency change from 128.0 to 132.0 MHz
[2014-01-20 22:53:25] ZTEX 04A3468A8A-1: Frequency change from 128.0 to 132.0 MHz
[2014-01-20 22:53:25] ZTEX 04A32DC7CA-1: Frequency change from 128.0 to 132.0 MHz
[2014-01-20 22:53:25] ZTEX 04A346DF0A-1: Frequency change from 128.0 to 132.0 MHz
[2014-01-20 22:53:25] ZTEX 04A3468E2F-1: Frequency change from 128.0 to 132.0 MHz

[BlueDragon747]

Here we go, how I miss the early days of bitcoin mining!

Code:

[2014-01-20 22:53:25] ZTEX 04A346E2B9-1: Frequency change from 128.0 to 132.0 MHz
[2014-01-20 22:53:25] ZTEX 04A3468A8A-1: Frequency change from 128.0 to 132.0 MHz
[2014-01-20 22:53:25] ZTEX 04A32DC7CA-1: Frequency change from 128.0 to 132.0 MHz
[2014-01-20 22:53:25] ZTEX 04A346DF0A-1: Frequency change from 128.0 to 132.0 MHz
[2014-01-20 22:53:25] ZTEX 04A3468E2F-1: Frequency change from 128.0 to 132.0 MHz

Yay

[rupy]

Is this the only coin you can mine with FPGAs except BTC?

[teknohog]

Is this the only coin you can mine with FPGAs except BTC?

I'd say it's the only non-sha256 coin you can sensibly* mine with FPGAs.

Bitcoin uses sha256, but so do many other coins like Peercoin. Generally, you can use the same hardware for all coins that use the same hash algorithm. There are only a handful of different hash algos, compared to the bazillions of funnycoins and memecoins.

*(There are FPGA and ASIC miners being developed for Scrypt (e.g. Litecoin). For example kramble here has done some nice work with FPGAs However, it's not yet a huge threat to GPU mining -- the nature of Scrypt means that it needs a lot of fast RAM, which FPGAs don't have.)

[kramble]

As teknohog said. Scrypt perfomance on FPGA is pretty dire. I've got 60kHash/sec from a quad LX150 board (ztex 1.15y and Cairnsmore CM1). There is not currently a port for the 1.15x (I've been lazy), but it would only give around 15kHash/sec so its hardly worthwhile.

I am currently looking into keccak (SHA-3) as used in copperlark, but the example code is in VHDL which I'm not at all familiar with. That and my muse seems to have left me at the moment, so I'm finding it difficult to focus on the task.

There are several other hashing algorithms (the non-winning candidates for the NIST SHA-3 competition) that are suitable for FPGA (blake was one, also skein, grostl, JH) which Quark Coin uses, but in a way that makes a FPGA implementation difficult (it uses multiple hash algorithms and swaps between them on the fly). Then we have the likes of Primecoin which just won't fit at all (way too much RAM), and tweaks to the scrypt algorithm (YaCoin, Vertcoin) which may be possible in FPGA (Windmaster mined YAC on FPGA in its early days using a private bitstream, and I did a quick and dirty port of my litecoin miner for N=2048 to mine Vertcoin, but the hash rates are just not worth the bother).

PS, and looky here, they've just announced eCoin to use SHA-3 (like, this is why I've been looking at this in the first place, expecting new coins to use it), shame I've been so lazy recently and just not got it done 

[Calhil]

So youre getting around 1.6GH/s on ZTEX 1.15y? On Ztex site they are selling those boards for 500eur, but Ive found used ones for around 100eur. Given this price Im actually considering buying one to mine blakecoin (and possibly other coins in the future) ;]

[Prelude63]

I like blakecoin and I am interested to setup an exchange for blakecoin. Anyone else interested? We can pool our resources together to make this happen.

[teknohog]

So youre getting around 1.6GH/s on ZTEX 1.15y? On Ztex site they are selling those boards for 500eur, but Ive found used ones for around 100eur. Given this price Im actually considering buying one to mine blakecoin (and possibly other coins in the future) ;]

This is exactly what I did a few weeks ago, as I'm also interested in following other developments such as Scrypt on FPGAs. Paid 150€ for a bitstream-compatible clone, which I received last week. The speed is closer to 1.5 GH/s but I'm only using the default automatic adjustment, so there might be room for improvement.

[teknohog]

I like blakecoin and I am interested to setup an exchange

Read this first: https://bitcointalk.org/index.php?topic=414777.0

In other words, if you don't have the experience/expertise to handle other people's money, better just talk to established exchanges in order for them to adopt BLC.

[kramble]

The speed is closer to 1.5 GH/s but I'm only using the default automatic adjustment, so there might be room for improvement.

Lots of room for improvement in the bitstream. AFAIR (I'm not firing up the build machine just to check) its only around 50% utilization of the LE, and zero utilization of DSP or RAM. Plenty of scope for tuning the implementaton. I'd have done a bit more, but I got bogged down in the ISE "tweak the tables setting and build again" cycle for chasing best FMAX, and that's enough to sap all enthusiasm after a few dozen tries. Some expert attention would probably double the performance overall. Anyway, just sayin as I don't intend going back over it, at least for a while anyway.

[Prelude63]

I like blakecoin and I am interested to setup an exchange

Read this first: https://bitcointalk.org/index.php?topic=414777.0

In other words, if you don't have the experience/expertise to handle other people's money, better just talk to established exchanges in order for them to adopt BLC.

I have access to investors and coming out with a working prototype should get us some funding to secure it and see it to production.

[BlueDragon747]

I have access to investors and coming out with a working prototype should get us some funding to secure it and see it to production.

did you see what happened to OpenEx(open source exchange) hacked within 2 weeks wallets stolen and people lost money not good  

setting up an exchange is super high risk as it will get hacked at some point!

[BlueDragon747]

As teknohog said. Scrypt perfomance on FPGA is pretty dire. I've got 60kHash/sec from a quad LX150 board (ztex 1.15y and Cairnsmore CM1). There is not currently a port for the 1.15x (I've been lazy), but it would only give around 15kHash/sec so its hardly worthwhile.

I am currently looking into keccak (SHA-3) as used in copperlark, but the example code is in VHDL which I'm not at all familiar with. That and my muse seems to have left me at the moment, so I'm finding it difficult to focus on the task.

There are several other hashing algorithms (the non-winning candidates for the NIST SHA-3 competition) that are suitable for FPGA (blake was one, also skein, grostl, JH) which Quark Coin uses, but in a way that makes a FPGA implementation difficult (it uses multiple hash algorithms and swaps between them on the fly). Then we have the likes of Primecoin which just won't fit at all (way too much RAM), and tweaks to the scrypt algorithm (YaCoin, Vertcoin) which may be possible in FPGA (Windmaster mined YAC on FPGA in its early days using a private bitstream, and I did a quick and dirty port of my litecoin miner for N=2048 to mine Vertcoin, but the hash rates are just not worth the bother).

PS, and looky here, they've just announced eCoin to use SHA-3 (like, this is why I've been looking at this in the first place, expecting new coins to use it), shame I've been so lazy recently and just not got it done  

I tested most of those hashing algo's 100% sure they can't beat Blake-256 on size(fpga) or speed(hashrate) it does help that I reduced the rounds

keccak is slow and quite large area needed for fpga (they picked it for its sponge function as it was different to SHA-256 not its performance)
skein is slow and needs same sort of space as SHA-256
grostl still quite slow and was not that fast on fpga
JH is slow and again not that fast on fpga

these are quite good:
BMW-256 is good and quite fast it should be quite small on fpga but all in VHDL
Blake2 faster than Blake but to get good performance you need to remove the endianess from the wallet

[bzyzny]

Prelude, It would be great if you started another exchange, but as others are pointing out, make sure you are prepared. Make sure your developers and server admins REALLY know what they are doing. And you'll need some way to stand out, I would suggest by carefully picking which coins you trade based on technical merit, rather than just trading any/all new junk / hype coins

[BlueDragon747]

It would be great if you started another exchange, but as others are pointing out, make sure you are prepared. Make sure your developers and server admins REALLY know what they are doing. And you'll need some way to stand out, I would suggest. Y carefully picking which coins you trade based on technical merit, rather than just trading any/all new kunk / hype coins

even the best developers and server admins should not look at an exchange system and think they can secure it 100% its better to design such as system with the thought of its going to get hacked how do we limit the damage done

I agree picking some good well supported coins that have been about for at least one month and have active dev's, would be nice if an exchange picked coins on technical merit