Topic: [ANN][BLC] Blakecoin Blake-256 for GPU/FPGA With Merged Mined Pools Stable Net - page 143. (Read 409641 times)

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

Yay

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

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  

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.

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

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


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.

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

How can I independently configure device MHz?

Did anyone try to mine blakecoin with an nvidia gpu? Im wondering what hashrates can one get compared to a similarly priced amd cards.

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.

Overheating is the only thing that will damage them, so as long as they stay cool you should be OK. Blakecoin does not stress the FPGAs as much as bitcoin mining (which really means there is likely scope for considerable performance improvement given the attention of an expert coder rather than my amateur efforts). I wouldn't try 250MHz though as its way too fast for this bitstream (the CM1 bitstream will run this fast, but that's due to a different internal divider ratio, in both cases the internal core is only running at around 60Mhz or so). Oh BUM, I just realized this is scrypt I've been thinking of. Blakecoin runs faster (cgminer README). You'll probably be able to get it up to around 180Mhz or so (README). So try --ztex-clock 160:200 with the v03 bitstream and see how it copes.

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)

(edited rather a lot, hope it vaguely makes some sense now)

But can I damage the chips by setting it to 250Mhz f.ex?

I have extreme cooling, so heat is not a problem. My worry is breaking the chips...

How do I monitor where it settles?

Whatever gives you the best hash rate Its supposed to be managed automatically (at least in the bitcoin version), but doesn't work very well for blakecoin so I added the --ztex-clock parameter. I suggest you try setting it to say --ztex-clock 120:148 and monitor it to see where it settles, then use that value (or maybe dial it back slightly).

The reason I recommend setting min and max to the same value for production use, is that the automatic management will occasionally go haywire, so it seems better to fix it. The cgminer ztex driver is just buggy. Don't worry too much about HW errors at the device level as these are counted differently to other fpga/gpus.

@BlueDragon747 @kramble Works, I'm mining! The leds don't blink The leds do blink and the pool is reporting ~1GH/s... but the heatsinks are completely cold... this is my command:

cgminer.exe -T --ztex-clock 128:128 --disable-gpu -o stratum+tcp://eu1.blakecoin.com:3334 --userpass XXX:YYY 2>log.txt

What should the --ztex-clock be?

it does matter but it does not effect block time which is the limiter on coins produced per day/hour etc.

if Blake-256 gets as popular as Scrypt then it will make a huge difference to cost and power usage

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!

here in the UK electric is expensive ~15 pence per kWh, so energy efficiency of the algorithm is a very important factor and so is cycles per byte as efficiency of the hashing algorithm directly relates to operations per second, silicon space and power usage *This is a Fact! and a fundamental principle!, this is not the case with resistance or memory hard algorithm's which claim a lot but often fail to deliver e.g Litecoin/Scrypt *Which started the GPU/FPGA/ASIC resistant, slow algo myth

GPU Only Rig3+Rig4 Results(shared power meter at wall):

• Blakecoin = 1876W avg
• Bitcoin = 1932w avg
• Litecoin = 2139W avg

so if we ignore difficulty and reward, Blakecoin is ~14% more power efficient than Litecoin for the same rigs! and if we factor in that Blakecoin is merge mine capable then it would be orders of magnitude more power efficient each coin we could merge mine!

so my rough calculations for power usage over a year on these GPU rigs looks something like this:
Litecoin ~ £2802.95
Blakecoin ~ £2458.31

now multiply that by all the rigs using GPU and Mining Scrypt based coins you are talking a LOT of power/money wasted!

energy efficiency on the FPGA with Blake-256 is awesome, doing about 2x the hashing compared with SHA-256 for the same power usage, same would be true if Blake had an Asic (faster, cheaper, more power efficient to run)

higher hash rate means that a bruteforce guess has more chances of finding that needle in a hay stack if the diff goes high due to a pump/spike.

the larger the set (hashrate) the greater the probability of finding a random guess for any difficulty hence why Scrypt based coins get stuck so much in pumps as you still need to get to the retarget

Quote from wikipedia:
"In probability theory, the law of large numbers (LLN) is a theorem that describes the result of performing the same experiment a large number of times. According to the law, the average of the results obtained from a large number of trials should be close to the expected value, and will tend to become closer as more trials are performed. The LLN is important because it "guarantees" stable long-term results for the averages of random events."
en.wikipedia.org/wiki/Law_of_large_numbers

• block find is the random event in mining

this is the type of search mining is doing if you wanted to do the maths for exact numbers:
en.wikipedia.org/wiki/Stochastic_process
en.wikipedia.org/wiki/Convergence_of_random_variables

this is also useful:
en.wikipedia.org/wiki/Probability_distribution

the only reason a miner joins a pool is for better average payouts due to higher hash rate and better block find average's  

I think energy efficiency argument is bullshit. It doesnt matter if the whole network is hashing with 1KH/s or 100TH/s. Changing difficulty will ensure that blocks are found at the same rate in both cases.

I think you will find entry fees gifts are in BTC not BLC  

I will stick to my list of tasks above and not worry about exchanges atm, thanks for everyone's support  

any how to guides or other doc's are most welcome I get little time to do any documentation for Blakecoin so it would help  

Perhaps we could round up a few thousand blc to give to bigvern as a thank you for adding blc to cryptsy ;-). I could contribute 500blc. But I dont think we should hurry. I think its best we make sure there a few more pools, iron out any bugs, and generally prepare more since the added attention from getting on an exchange will test our infrastructure. I'm not a coder but am quite technically knowledgeable and am eager to help where I can. Perhaps by writing some documentation, any suggestions?

In a perfect world this would be the way to get coins listed on cryptsy but I think you will find there is more to it than that

To get coin on cryptsy people need to request Big Vern to add coin, requests can go to [email protected]. or can be added to forum discussion at https://cryptsy.freshdesk.com/support/discussions