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

[BlueDragon747]

both my 5870s are showing about 2.5 Ghash/s each, while 7970s are a little slower than this, all in contrast to the commonly reported figures. These are with kR105's cgminer, SDK 2.9 and ati-drivers 13.12.

very strange, what core/mem clocks are you using for 5870 and 7970?

One 5870 is 900,300 and another is 925,925. The memory speeds don't seem to matter, similarly to sha256, but the other card does not allow very low values.

The 7970s were clocked to something like 1000,1500 but in fact they pretty well match the 2.2 GH/s from the main post - I probably confused them with the 7990 at first.

I am running 920, 600 but only getting 1.25GH/s each only difference I can see is driver version any changes to the cgminer.conf?

[1714023199]

1714023199

[1714023199]

1714023199

[1714023199]

1714023199

[1714023199]

1714023199

[1714023199]

1714023199

[1714023199]

1714023199

[teknohog]

One 5870 is 900,300 and another is 925,925. The memory speeds don't seem to matter, similarly to sha256, but the other card does not allow very low values.

I am running 920, 600 but only getting 1.25GH/s each only difference I can see is driver version any changes to the cgminer.conf?

My commandline only has

Code:

./cgminer --blake256 -o http://nanite:8772/ -u teknohog -p XXXXX -I 14

I have tried different worksizes like -w 128, and not seen much effect. This version of cgminer (kR105's 3.7.2 branch, latest from git) does not allow things like --thread-concurrency that I'm used to tweaking with other coins.

I guess I should try this on a pool that can report an effective hashrate, in case this cgminer shows it wrong. It's hard to get a good evaluation from a few day's solo mining.

[BlueDragon747]

One 5870 is 900,300 and another is 925,925. The memory speeds don't seem to matter, similarly to sha256, but the other card does not allow very low values.

I am running 920, 600 but only getting 1.25GH/s each only difference I can see is driver version any changes to the cgminer.conf?

My commandline only has

Code:

./cgminer --blake256 -o http://nanite:8772/ -u teknohog -p XXXXX -I 14

I have tried different worksizes like -w 128, and not seen much effect. This version of cgminer (kR105's 3.7.2 branch, latest from git) does not allow things like --thread-concurrency that I'm used to tweaking with other coins.

I guess I should try this on a pool that can report an effective hashrate, in case this cgminer shows it wrong. It's hard to get a good evaluation from a few day's solo mining.

cool I just tried this in my cgminer.conf

and the 5870 are getting 2.5GH/s each woot

Edit:
its also working on the 6 series cards proof that sometimes less is more

Edit2?
not showing on pool rate and the WU/m are the same for both so it looks like a display bug nice find though  

[gymnastico]

this is my .config for the Asus EAH6950

now i have 1.55GH/s   temp 58° C

//


{
"pools" : [
   {
      "url" : "pool",
      "user" : "user",
      "pass" : "pw"
   }
],

"intensity" : "13",
"expiry" : "10",
"failover-only" : true,
"log" : "5",
"no-restart" : true,
"queue" : "3",
"scan-time" : "1",
"worksize" : "256",
"temp-hysteresis" : "4",
"blake256" : true,
"vectors" : "1",
"temp-hysteresis" : "3",
"shares" : "0",
"shaders" : "1792",
"thread-concurrency" : "8192",
"gpu-thread" : "2",
"gpu-fan": "100",
"gpu-engine" : "990",
"sharethreads" : "32",
"lookup-gap" : "2",
"gpu-powertune" : "20",
"gpu-memclock" : "1375",
"no-submit-stale": true,
"kernel-path" : "/"
}


//

[BlueDragon747]

this is my .config for the Asus EAH6950

now i have 1.55GH/s   temp 58° C

I do about 1.45GH/s ~ 20 WU/s on the 6950 so will give it a try

thanks for sharing the conf its always worth tweaking 

[gymnastico]

this is my .config for the Asus EAH6950

now i have 1.55GH/s   temp 58° C

I do about 1.45GH/s ~ 20 WU/s on the 6950 so will give it a try

thanks for sharing the conf its always worth tweaking  

whit this setting ~ 23.2 WU/s   on your pool whit diff set to 1

[teknohog]

not showing on pool rate and the WU/m are the same for both so it looks like a display bug nice find though  

Yup, as confirmed by the EU pool, this cgminer is seeing double -- the actual rate is pretty much half of the displayed one for 5870s. OTOH, the display is fine for 7970s.

[hal7]

Improved Ztex 1.15x bitstream (168-180MHz) will be available soon (max tomorrow).

[kramble]

Improved Ztex 1.15x bitstream (168-180MHz) will be available soon (max tomorrow).

Via PM (thanks)

Fresh, new faster bitstream is available.

Results:
Ztex 1.15x clone - grade 2 chip: 168MHz stable with 0 HW, 7.6W power with 40mm fan
Ztex 1.15x         - grade 3 chip: 180MHz stable with 0 HW, 8.7W power with 40mm fan (360MH/s).

I'll do another attempt to hit 200MHz.

Bitstream is at https://www.dropbox.com/s/polv7bu899w4bmi/hal7_ztex_ufm1_15d4_2core_v03.bit

I'll update the github tomorrow.

[bzyzny]

My commandline only has

Code:

./cgminer --blake256 -o http://nanite:8772/ -u teknohog -p XXXXX -I 14

did you try a lower intensity? my card decreases gh/s when over 12

[teknohog]

did you try a lower intensity? my card decreases gh/s when over 12

I've tried these, and both 5870s and 7970s are slightly faster with 14. There are the occasional rejects, though, it's hard to say whether they are due to intensity or just the usual issues with pools and networks.

[bzyzny]

I've tried these, and both 5870s and 7970s are slightly faster with 14. There are the occasional rejects, though, it's hard to say whether they are due to intensity or just the usual issues with pools and networks.

the ideal intensity varies from card to card. rejects happen from time to time, from spikes in network latency and such. also make sure to have this line in your config file:

"no-submit-stale": true

[aliceross222]

does blakecoin favor asics?

[bzyzny]

does blakecoin favor asics?

yes but perhaps not how you may think. it is not compatible with bitcoin/sha-256 asics. however, the blake algorithm is very efficient and would be relatively simple and inexpensive to implement in silicon (relative to scrypt for example). there are no asics for blake yet, however i believe there is some documentation available about implementing blake in asic. there is also fpga support for blakecoin, and my understanding is that fpgas are used for prototyping asic designs. so this is good because if blakecoin gains enough momentum to warrant asic production, it will result in extremely high hashrates with very low power draw (much better than possible with sha256 asics). hope that helps

[BlueDragon747]

does blakecoin favor asics?

yes but perhaps not how you may think. it is not compatible with bitcoin/sha-256 asics. however, the blake algorithm is very efficient and would be relatively simple and inexpensive to implement in silicon (relative to scrypt for example). there are no asics for blake yet, however i believe there is some documentation available about implementing blake in asic. there is also fpga support for blakecoin, and my understanding is that fpgas are used for prototyping asic designs. so this is good because if blakecoin gains enough momentum to warrant asic production, it will result in extremely high hashrates with very low power draw (much better than possible with sha256 asics). hope that helps

that's about right but with fpga's you do get them in different categories not all are for asic development e.g the lx150 used on the ztex board are designed for industrial/automotive applications and the other lx150 used on the other fpga boards are considered "Low-Cost FPGAs" rather than for asic development which would be more of the mid/high end fpga range.

Quote Xilinx:
"Spartan®-6 FPGA delivers an optimal balance of low risk, low cost, and low power for cost-sensitive applications, now with 42% less power consumption and 12% increased performance over previous generation devices. Spartan-6 FPGAs offer advanced power management technology, up to 150K logic cells, integrated PCI Express® blocks, advanced memory support, 250MHz DSP slices, and 3.2Gbps low-power transceivers."

* Newer fpga's out now with better fmax and lower power due to 28nm-20nm designs, and higher end fpga's from Altera already at 14nm  
* Altera used to do a thing called hardcopy (fpga->asic) but they have stopped that http://www.altera.co.uk/devices/asic/asic-index.html  

so I like to think of fpga's as re-programmable hardware while asic is optimal for one task only e.g its fixed to one algorithm

some consumer, networking and broadcast equipment use fpga's is production devices same is true in automotive industry here is an example:
http://hackaday.com/2013/05/08/hdmi-color-processing-board-used-as-an-fpga-dev-board-to-mine-bitcoins/

the same fpga's used for mining Bitcoin can be reused for mining Blakecoin so you can see the flexibility that an fpga has over asic

I am quite keen on re purposing equipment for new tasks so might have a soft spot towards fpga's    

asic's will always get higher frequency and lower power usage as it is only designed for that one task, only thing left is to shrink the design like we have seen with CPU's over the years  

the volume of Blakecoin does not justify the huge cost of asic production/design yet, GPU and fpga mining should be possible for a few years at least

very good explanation bzyzny  

[teknohog]

I am quite keen on re purposing equipment for new tasks so might have a soft spot towards fpga's    

My thoughts exactly I try to buy only hardware I could learn to program myself, in a spirit of open source. There is also the arms race mentality about ASICs that I have a slight problem with; an early ASIC could soon be obsolete, but you could still develop something revolutionary on an old FPGA, GPU or CPU.

That said, I happen to have a BFL FPGA Single. I'm sure there are other people who have also stayed away from the ASIC refund, and it could be a nice engine for Blake. The sha256 performance is similar to a Ztex 1.15y. I recall reading it has two fairly high-end Altera chips, possibly of the Stratix family. (The heatsinks are glued on, so I haven't checked.)

If someone can port Blake on this thing, I am willing to donate mine for research. I have a feeling these FPGAs won't be accessible with the free Quartus, and there may be other software/electrical issues to reverse engineer.

[nadadenada]

Hello there,
Can anyone help me to compile cgminer 3.7 from kR105. Actually I am getting errors en cgminer.c :
Undefined reference to "opt_blake256"
Undefined reference to "blake256_reg"

Thanks in advance.

[teknohog]

Hello there,
Can anyone help me to compile cgminer 3.7 from kR105.

Please specify things like your OS, AMD APP SDK version, ./configure options and so on. I managed it on Linux with SDK 2.9 and --disable-icarus --disable-adl --enable-opencl.

[nadadenada]

Please specify things like your OS, AMD APP SDK version, ./configure options and so on. I managed it on Linux with SDK 2.9 and --disable-icarus --disable-adl --enable-opencl.

Thanks for replay,
Trying to compile it on windows 8.1 with MinGW. Using AMD SDK v2.8. I was trying to follow the windows-build.txt: https://github.com/kR105/cgminer/blob/3.7/windows-build.txt

I want to try cgminer 3.7.2 because cgminer 3.1.1 is using too much my cpu (about 90%), I am on AMD Sempron 140. Mining other coins with cgminer 3.7.2 it uses only 8%.

[kramble]

That said, I happen to have a BFL FPGA Single. I'm sure there are other people who have also stayed away from the ASIC refund, and it could be a nice engine for Blake. The sha256 performance is similar to a Ztex 1.15y. I recall reading it has two fairly high-end Altera chips, possibly of the Stratix family. (The heatsinks are glued on, so I haven't checked.)

We discussed this on another thread (it was a bit cluttered, so I'll just quote a couple of posts) ...

Let me say, I do not think they are scrap.  They do have a value, it is just pretty low.  They can be used as an FPGA dev platform.  That is why I say I would buy a few for $30 each.  But I will never get that $30 back mining BTC.  

Last I checked they were cryptographically locked to BFL's FPGA images and BFL won't provide the info needed to reprogram them. IIRC they also can't be reprogramed over the USB bus.

That's useful info. I was wondering if it might be worth porting my litecoin miner onto them, but I'll stick with the Lancelot and Ztex for now. Its just a hobby project anyway as the return on mining LTC would be minimal at the sort of hash rates I'm achieving (It was a challenge ... lots of people said FPGA couldn't do scrypt, well it can, just not very well ).

That can easily be fixed. The crypto keys can be removed with a JTAG.

yep ok ..... the  BFL bit-files will no longer work, but it's not as if you need them.

They have two, quite expensive, FPGA chips inside. They could be recovered and used elsewhere.

According to Ngzhang they are EP3SL150F780 https://bitcointalk.org/index.php?topic=79825.0
Some additional info https://bitcointalk.org/index.php?topic=123155.0

However the bitstream is protected (see http://www.altera.co.uk/literature/wp/wp-01010.pdf) and if BFL used the poly-fuse option rather than battery-backup, the devices may be unusable (I defer to rasorfishsl upthread, but AFAIK poly-fuses are one-time programmable and if the tamper flag is set the devices are junk without the master key).

So according to rasorfishsl it is possible, then according to kramble (me) its not (but I could be wrong). I guess the best way to proceed is to get the JTAG working first (it may need some hardware hacking), check the status of the protection and tamper FUSE, and proceed from there.