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

[kramble]

edit:
Kramble, i think you have done an awesome job, everywhere i went to try and figure this out, your name came up :-p, could you by any chance point me in a direction of learning about programming fpgas? books or websites?

Aww, shucks I'm just an amateur, I learned on Bitcoin https://bitcointalk.org/index.php?topic=9047.0

That said, from my bookmarks

http://www.fpga4fun.com/
http://svenand.blogdrive.com/
http://www.asic-world.com/verilog/veritut.html
http://excamera.com/sphinx/fpga-vhdl-verilog.html#main
http://www.joelw.id.au/FPGA/CheapFPGADevelopmentBoards
http://opencores.org/or1k/Main_Page
http://www.rcis.aist.go.jp/special/SASEBO/SHA3-en.html (the inspiration for the blakecoin miner)
http://cryptography.gmu.edu/athena/index.php?id=source_codes (other crypto algos)

and I'll add some more once I've gone through them properly (apologies Blue if this is off topic).

[CHAOSiTEC]

yeah got all that and patched up cgminer, i think its running now though with the following command line (im running linux) :-) yuhu got 3 shares, over the last 6 minutes :-p

sudo ./cgminer --icarus-timing long -S /dev/ttyUSB0 -S /dev/ttyUSB1 -S /dev/ttyUSB2 -S /dev/ttyUSB3 --url stratum+tcp://eu3.blakecoin.com:3334 --userpass FireWalkerX.1:x --cainsmore-clock 200,200,190,180

Yep, that looks good. As long as all four devices are giving accepted hashes at the right sort of rate (WU around 13 I think off the top of my head, I run my lancelot in background I don't see the interactive display, I'll need to check back through the thread to see what others are getting with the CM1). If you run it with the --verbose switch you'll see the difficulty=1 shares being reported in the log (the pool accepts at diff=32 so most of them will be above-targets, but it will show that it's working).

Use "--icarus-timing 1.0=20" instead of long as this gives better control of the work (20 is one work refresh every 2 seconds). You don't want the nonce wrapping and the devices going idle (yellow led).

ive changed the timing, but since blue is setting up umo on the pool, its a bit hard to test, im just letting it run, at some point it will connect again :-p

edit:
Kramble, i think you have done an awesome job, everywhere i went to try and figure this out, your name came up :-p, could you by any chance point me in a direction of learning about programming fpgas? books or websites?

Aww, shucks I'm just an amateur, I learned on Bitcoin https://bitcointalk.org/index.php?topic=9047.0

That said, from my bookmarks

http://www.fpga4fun.com/
http://svenand.blogdrive.com/
http://www.asic-world.com/verilog/veritut.html
http://excamera.com/sphinx/fpga-vhdl-verilog.html#main
http://www.joelw.id.au/FPGA/CheapFPGADevelopmentBoards
http://opencores.org/or1k/Main_Page
http://www.rcis.aist.go.jp/special/SASEBO/SHA3-en.html (the inspiration for the blakecoin miner)
http://cryptography.gmu.edu/athena/index.php?id=source_codes (other crypto algos)

and I'll add some more once I've gone through them properly (apologies Blue if this is off topic).

awesome, ill safe this page so i can see if you update it with more good stuff :-)

[kramble]

ive changed the timing, but since blue is setting up umo on the pool, its a bit hard to test, im just letting it run, at some point it will connect again :-p

It's useful to set up a failover pool (just add --failover-only and the second pool login credentials). I actually failover to solo mining so that I pick up the occasional pristine block.

awesome, ill safe this page so i can see if you update it with more good stuff :-)

Umm, I think that was just about it. I'm not actually doing very much with FPGA at the moment (especially the LX150 which is a right PITA to work with). Just waiting to come up with some cool idea to get stuck into (crypto-mining is pretty much dead on FPGA now, blake is just about the only algo that's worth mining with).

I updated the WU in my previous post to 5.6 per device (60 * 2 * clock * 1000000) / 2^32 ) so you should be seeing around 20 or so for the CM1 board. The pool will tell you the actual rate (should be around 1600MHash/s at 200MHz).

[CHAOSiTEC]

I updated the WU in my previous post to 5.6 per device (60 * 2 * clock * 1000000) / 2^32 ) so you should be seeing around 20 or so for the CM1 board. The pool will tell you the actual rate (should be around 1600MHash/s at 200MHz).

well board had more HW than accepted, so now im running at 175 MHz and no more HW and more shares being submitted, still have a wu of aprox 20 :-p

[kramble]

well board had more HW than accepted, so now im running at 175 MHz and no more HW and more shares being submitted, still have a wu of aprox 20 :-p

The HW errors are reported on the raw diff=1 shares, but since the pool (currently) accepts at diff=32, it's not quite as bad as it looks. You should be aiming for a HW error rate of a few percent of the diff=1 share rate, so anything less than the accept rate at diff=32 is probably OK (as usual, it's the hash rate reported by the pool that really matters). So you may be able to bump up the clock a little from 175MHz. I was easily achieving 200MHz, though since you've got an early board, it may perform a little worse than the later ones. Good luck

[CHAOSiTEC]

well board had more HW than accepted, so now im running at 175 MHz and no more HW and more shares being submitted, still have a wu of aprox 20 :-p

The HW errors are reported on the raw diff=1 shares, but since the pool (currently) accepts at diff=32, it's not quite as bad as it looks. You should be aiming for a HW error rate of a few percent of the diff=1 share rate, so anything less than the accept rate at diff=32 is probably OK (as usual, it's the hash rate reported by the pool that really matters). So you may be able to bump up the clock a little from 175MHz. I was easily achieving 200MHz, though since you've got an early board, it may perform a little worse than the later ones. Good luck

ok, im running the board now with 190,190,180,175 im just going to test and see where i get the best results, since its also incredible hot here right now, i dont want to push it further :-)

Thanks for all the help :-)

[BlueDragon747]

UMO now added to all merge mine pools 

[nicred]

Awesome news Blue! Welcome to the party UMO!

[MinermanNC]

Anyone else not getting a payout ,,, from Electron or Photon? rounds end but nothing happens no coin is moved into the unconfirmed column.... both coins no payout since 6:38 pm last night??? eastern time.... and they appear to be hashing with estimates and new block will start and it as if the last block never happened. on ny2 pool

[BlueDragon747]

ELT network has issues and is being looked into by dev and myself

PHO on NY2 is due to a stuck cron forcing it now should be back to normal soon

[MinermanNC]

ELT network has issues and is being looked into by dev and myself

PHO on NY2 is due to a stuck cron forcing it now should be back to normal soon

Fixed 
Ty

[SquidsIn]

since im quite new to fpga's can someone point me in the right direction on a step by step of what i need to do to set my cairnsmore 1 up for blakecoin mining?

There is not much I can add to what has been said by BlueDragon and sidgrip. Just be sure to load the hashvoodo firmware via spiprog (or impact) before flashing the blake bitstream. I'll add those notes to the CM1 github README as it's a bit terse at the moment. EDIT: OK, that's done. Let me know if I can improve it or if there are any errors.

I didn't find the CM1 to be very reliable (at least the one I was testing on, borrowed from BlueDragon) as it kept dropping off the USB every few hours, needing a complete power cycle (including disconnecting and reconnecting the USB cable) to reset it. While the CM1 appears to be of really good build quality, there were some design issues with the USB, the clock distribution and the broken serial chaining of the FPGA devices. Later devices were apparently slightly better (serial number 0051 onwards, see here), but I don't know if Enterpoint ever got it properly up to production quality (and I'm not reading all the way through that thread to find out). There is also some useful background information on the Hashvoodo thread.

I  have an old (actual age unkown) CM1 acquired from ebay a few weeks ago and I had that same reliability issue mentioned (USB dropping off requiring disconnect, power cycle etc etc).  I was running the CM1 and a ZTEZ 1.15y in the same instance of cgminer and the CM1 would fail every few hours for no apparent reason.

One of two things seemed to fix it and its now been running rock a solid 1.5Gh for a couple of weeks.  Firstly I compiled and now run separate instances of cgminer 3.1.1 for the CM1 and the 1.15y with only Icarus and ZTEX enabled respectively.  Secondly, I moved the CM1 onto a USB3.0 port on the back of the rig instead of the USB2.0 port it was using. I think it was the USB3,0 port that fixed it but I'm loathe to upset the apple cart by trying to prove/disprove that.

[BlueDragon747]

since im quite new to fpga's can someone point me in the right direction on a step by step of what i need to do to set my cairnsmore 1 up for blakecoin mining?

There is not much I can add to what has been said by BlueDragon and sidgrip. Just be sure to load the hashvoodo firmware via spiprog (or impact) before flashing the blake bitstream. I'll add those notes to the CM1 github README as it's a bit terse at the moment. EDIT: OK, that's done. Let me know if I can improve it or if there are any errors.

I didn't find the CM1 to be very reliable (at least the one I was testing on, borrowed from BlueDragon) as it kept dropping off the USB every few hours, needing a complete power cycle (including disconnecting and reconnecting the USB cable) to reset it. While the CM1 appears to be of really good build quality, there were some design issues with the USB, the clock distribution and the broken serial chaining of the FPGA devices. Later devices were apparently slightly better (serial number 0051 onwards, see here), but I don't know if Enterpoint ever got it properly up to production quality (and I'm not reading all the way through that thread to find out). There is also some useful background information on the Hashvoodo thread.

I  have an old (actual age unkown) CM1 acquired from ebay a few weeks ago and I had that same reliability issue mentioned (USB dropping off requiring disconnect, power cycle etc etc).  I was running the CM1 and a ZTEZ 1.15y in the same instance of cgminer and the CM1 would fail every few hours for no apparent reason.

One of two things seemed to fix it and its now been running rock a solid 1.5Gh for a couple of weeks.  Firstly I compiled and now run separate instances of cgminer 3.1.1 for the CM1 and the 1.15y with only Icarus and ZTEX enabled respectively.  Secondly, I moved the CM1 onto a USB3.0 port on the back of the rig instead of the USB2.0 port it was using. I think it was the USB3,0 port that fixed it but I'm loathe to upset the apple cart by trying to prove/disprove that.

yeah I also found a short USB lead was good and not all cables created stability some made it more unstable 

not tried USB 3.0 port but have some will give it a go 

[kingscrown]

BLC has really good dev it will get right price in future. Good investment for now!

[BlueDragon747]

Issue on EU3 with MMP I am fixing it now

[griffitsj]

I don't know if this has been covered before but I have found that for Tahiti based cards (280x 7850) the worksize should be set to 64 for best performance.   This gave me a nice 10% performance increase as previously I had been using 128 without realizing.  Older cards should probably leave it at the default 128.

Anyone have any other experiences to share?

[BlueDragon747]

I don't know if this has been covered before but I have found that for Tahiti based cards (280x 7850) the worksize should be set to 64 for best performance.   This gave me a nice 10% performance increase as previously I had been using 128 without realizing.  Older cards should probably leave it at the default 128.

Anyone have any other experiences to share?

some people also report that odd worksize with newer drivers works quite well e.g 255

thanks for sharing your results

[xen0s]

anyone use geforce with blake256?

im interested in hashrates, so comments will be very appreciated

[BlueDragon747]

anyone use geforce with blake256?

im interested in hashrates, so comments will be very appreciated

Nvidia performance is not great cudaminer is not well tweaked for Blake-256 and OpenCL is not as fast on Nvidia card

That said it does run with the cgminer and there are miners using Nvidia cards to mine with best thing is to just give it a try

[xen0s]

anyone use geforce with blake256?

im interested in hashrates, so comments will be very appreciated

Nvidia performance is not great cudaminer is not well tweaked for Blake-256 and OpenCL is not as fast on Nvidia card

That said it does run with the cgminer and there are miners using Nvidia cards to mine with best thing is to just give it a try

optimisation is the key
look how was x11 optimised on amd
so...maybe someone will take close look at cudaminer too..