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

[atavacron]

Atavacron

An initial build of the FPGA code for X6500 is now up https://github.com/kramble/FPGA-Blakecoin-Miner/tree/master/experimental/X6500-Basic

The bitstream is at https://www.dropbox.com/s/ean7rbweij40oh1/X6500-Basic-v01-fmax-150MHz.bit

It will require a modified blake algorithm version of either of

https://github.com/TheSeven/Modular-Python-Bitcoin-Miner
https://github.com/fizzisist/x6500-miner

I'll have a go at this (probably the latter as it looks a lot simpler, even though it is depreciated) but my python skills are not awfully great. If anyone's got a blake hash module written in python, it would be very helpful, else I'll just hack in an os.system call to my external midstate and checkblake C code.

And in other news, I'm now getting 800Mash/sec (at around 20 Watts) from a Lancelot board 

Awesome Kramble!!!

I'll start experimenting with it right away.

[kramble]

Awesome Kramble!!!

I'll start experimenting with it right away.

Probably best just to see if it loads up and returns any hashes (they will be invalid as the current blakecoind sends the wrong midstate, hence the need to caclulate it in the driver). I'll take a look at the python miner code later, but I need to get myself some dinner first and wind-down a bit ('twas a bit of an intense hacking session).

Good Luck
Mark

[atavacron]

Awesome Kramble!!!

I'll start experimenting with it right away.

Probably best just to see if it loads up and returns any hashes (they will be invalid as the current blakecoind sends the wrong midstate, hence the need to caclulate it in the driver). I'll take a look at the python miner code later, but I need to get myself some dinner first and wind-down a bit ('twas a bit of an intense hacking session).

Good Luck
Mark

Gotcha.  Enjoy your dinner.

[atavacron]

Kramble,

The program.py from fizzisist seems to find the x6500 but gives me the following errors on the discovery:

Code:

./program.py -v X6500-Basic-v01-fmax-150MHz.bit 

2013-10-27 13:04:53 | Opening bitstream file: X6500-Basic-v01-fmax-150MHz.bit
2013-10-27 13:04:53 | Bitstream file opened:
2013-10-27 13:04:53 |  Design Name: blakeminer_top_routed.ncd;HW_TIMEOUT=FALSE;UserID=0x42240402
2013-10-27 13:04:53 |  Firmware: rev 4, build: 2
2013-10-27 13:04:53 |  Part Name: 6slx150fgg484
2013-10-27 13:04:53 |  Date: 2013/10/27
2013-10-27 13:04:53 |  Time: 15:22:10
2013-10-27 13:04:53 |  Bitstream Length: 4220492
2013-10-27 13:04:53 | Device 0 opened (A5VNUHQI)
2013-10-27 13:04:53 | Discovering FPGA 0 ...
Traceback (most recent call last):
  File "./program.py", line 93, in <module>
    fpga.detect()
  File "/home/spock/vcoins/x6500-miner/fpga.py", line 96, in detect
    self.jtag.detect()
  File "/home/spock/vcoins/x6500-miner/jtag.py", line 83, in detect
    self._readIdcodes()
  File "/home/spock/vcoins/x6500-miner/jtag.py", line 303, in _readIdcodes
    idcode = self.parseByte(data[0:8])
  File "/home/spock/vcoins/x6500-miner/jtag.py", line 259, in parseByte
    return (bits[7] << 7) | (bits[6] << 6) | (bits[5] << 5) | (bits[4] << 4) | (bits[3] << 3) | (bits[2] << 2) |  (bits[1] << 1) | bits[0]
IndexError: list index out of range

I'll give the Modular-Python-Bitcoin-Miner a try.

[kramble]

The program.py from fizzisist seems to find the x6500 but gives me the following errors on the discovery:

Try turning on the debug output (line 59 of jtag.py: self.debug = 1), I'm guessing the read_dr at line 298 is not returning valid data.

However it looks like its not even got to the point of sending the bitstream. You could try it with a known-good bitcoin bitstream first, or even use the BFGMiner to program it (like you did the last time).

[atavacron]

The program.py from fizzisist seems to find the x6500 but gives me the following errors on the discovery:

Try turning on the debug output (line 59 of jtag.py: self.debug = 1), I'm guessing the read_dr at line 298 is not returning valid data.

However it looks like its not even got to the point of sending the bitstream. You could try it with a known-good bitcoin bitstream first, or even use the BFGMiner to program it (like you did the last time).

OK.  I'll give that a try.

On another note, I did get the bitsteam to load using Modular-Python-Bitcoin-Miner.  I was even able to setup a work source pointed to my local Blakecoin client.  The WebGUI says that it is mining at 25MH/s on each core.

[kramble]

On another note, I did get the bitsteam to load using Modular-Python-Bitcoin-Miner.  I was even able to setup a work source pointed to my local Blakecoin client.  The WebGUI says that it is mining at 25MH/s on each core.

Good, at least its returning golden nonces. It should be twice that speed though (localparam BOOTUP_FREQUENCY = 50 so 50MH/s per core). Not sure how WebGUI is guessing the speed as the actual nonce counter does not get reported back to the miner.

Anyway looking at fizzisist's code, it looks fairly trivial to insert a subprocess.Popen call to midstate at line 347 of fpga.py and checkblake at line 81 of mine.py. I'll fork the github and give it a try (it would be worth you confirming the miner actually works OK for bitcoin first).

[kev7112001]

cgminer works great for BLC no stales like the reaper which i got 100% of now im running too 7970's at 5.5GH/s found 4 blocks 12hrs

[atavacron]

On another note, I did get the bitsteam to load using Modular-Python-Bitcoin-Miner.  I was even able to setup a work source pointed to my local Blakecoin client.  The WebGUI says that it is mining at 25MH/s on each core.

Good, at least its returning golden nonces. It should be twice that speed though (localparam BOOTUP_FREQUENCY = 50 so 50MH/s per core). Not sure how WebGUI is guessing the speed as the actual nonce counter does not get reported back to the miner.

Anyway looking at fizzisist's code, it looks fairly trivial to insert a subprocess.Popen call to midstate at line 347 of fpga.py and checkblake at line 81 of mine.py. I'll fork the github and give it a try (it would be worth you confirming the miner actually works OK for bitcoin first).

OK.  I'll verify that it is working for bitcoin.

[SpeedDemon13]

Wow, difficulty is flying; 6200 and counting!

It fluctuates, sometime it's in 3000's and all the way 6000's.

True, hour retargets lead it to fluctuate a fair amount while the coin is young, but network hashrate is certainly going up nicely .

Yup, it definitely is up...lol....Now, just need a stratum pool to lower the stale rates...

[BlueDragon747]

Wow, difficulty is flying; 6200 and counting!

It fluctuates, sometime it's in 3000's and all the way 6000's.

True, hour retargets lead it to fluctuate a fair amount while the coin is young, but network hashrate is certainly going up nicely .

Yup, it definitely is up...lol....Now, just need a stratum pool to lower the stale rates...

the invalid rate was over 50% on pool but fixed that bug and found another in block submit  

Atm mining the pool with 7GH/s-9GH/s shares so far 124723 and no blocks so be glad you are not testing the pool like me

[atavacron]

On another note, I did get the bitsteam to load using Modular-Python-Bitcoin-Miner.  I was even able to setup a work source pointed to my local Blakecoin client.  The WebGUI says that it is mining at 25MH/s on each core.

Good, at least its returning golden nonces. It should be twice that speed though (localparam BOOTUP_FREQUENCY = 50 so 50MH/s per core). Not sure how WebGUI is guessing the speed as the actual nonce counter does not get reported back to the miner.

Anyway looking at fizzisist's code, it looks fairly trivial to insert a subprocess.Popen call to midstate at line 347 of fpga.py and checkblake at line 81 of mine.py. I'll fork the github and give it a try (it would be worth you confirming the miner actually works OK for bitcoin first).

OK.  I'll verify that it is working for bitcoin.

Kramble,

Good news...

I had the same errors trying to mine when I tried to load the Bitcoin bitstream.  So I troubleshot and found that the "libftd2xx.so" symlink was pointed to "libftd2xx.so.1.1.12" instead of the modified "libftd2xx.so.1.0.4".  Now the Bitcoin bitstream loads and mines without a problem.  And your bitstream loads and connects to the server an is waiting to mine.

Code:

python program.py -v X6500-Basic-v01-fmax-150MHz.bit

2013-10-27 15:10:22 | Opening bitstream file: X6500-Basic-v01-fmax-150MHz.bit
2013-10-27 15:10:22 | Bitstream file opened:
2013-10-27 15:10:22 |  Design Name: blakeminer_top_routed.ncd;HW_TIMEOUT=FALSE;UserID=0x42240402
2013-10-27 15:10:22 |  Firmware: rev 4, build: 2
2013-10-27 15:10:22 |  Part Name: 6slx150fgg484
2013-10-27 15:10:22 |  Date: 2013/10/27
2013-10-27 15:10:22 |  Time: 15:22:10
2013-10-27 15:10:22 |  Bitstream Length: 4220492
2013-10-27 15:10:22 | Device 0 opened (A5VNV3JE)
2013-10-27 15:10:22 | Discovering FPGA 0 ...
2013-10-27 15:10:22 | 0: Waking up...
2013-10-27 15:10:22 | Found 1 device:
2013-10-27 15:10:22 |  FPGA0: Spartan 6 LX150
2013-10-27 15:10:22 | Discovering FPGA 1 ...
2013-10-27 15:10:22 | 1: Waking up...
2013-10-27 15:10:22 | Found 1 device:
2013-10-27 15:10:22 |  FPGA1: Spartan 6 LX150
2013-10-27 15:10:22 | Connected to 2 FPGAs
2013-10-27 15:10:22 | Pre-processing bitstream for chain = 2...
2013-10-27 15:12:26 | Pre-processed bitstream in 123.747140 seconds
2013-10-27 15:12:26 | Saving pre-processed bitstream...
2013-10-27 15:12:26 | Saved pre-processed bitstream in 0.067574 seconds
2013-10-27 15:12:26 | Beginning programming...
2013-10-27 15:12:26 | Programming both FPGAs...
2013-10-27 15:13:49 | Programmed both FPGAs in 82.786619 seconds

Code:

python mine.py -u 127.0.0.1:8772 -w <username:password>

2013-10-27 15:19:34 | Device 0 opened (A5VNV3JE)
2013-10-27 15:19:35 | Connected to 2 FPGAs
2013-10-27 15:19:35 | FPGA 0 is running at 26MHz
2013-10-27 15:19:35 | FPGA 1 is running at 26MHz
2013-10-27 15:19:35 | Connected to server
0 kH/s | 0/0/0 0.00%/0.00%

[SpeedDemon13]

Wow, difficulty is flying; 6200 and counting!

It fluctuates, sometime it's in 3000's and all the way 6000's.

True, hour retargets lead it to fluctuate a fair amount while the coin is young, but network hashrate is certainly going up nicely .

Yup, it definitely is up...lol....Now, just need a stratum pool to lower the stale rates...

the invalid rate was over 50% on pool but fixed that bug and found another in block submit  

Atm mining the pool with 7GH/s-9GH/s shares so far 124723 and no blocks so be glad you are not testing the pool like me

I am getting blocks every now and then while solo mining. Is CGminer suggest over Reaper for mining?

[atavacron]

Wow, difficulty is flying; 6200 and counting!

It fluctuates, sometime it's in 3000's and all the way 6000's.

True, hour retargets lead it to fluctuate a fair amount while the coin is young, but network hashrate is certainly going up nicely .

Yup, it definitely is up...lol....Now, just need a stratum pool to lower the stale rates...

the invalid rate was over 50% on pool but fixed that bug and found another in block submit  

Atm mining the pool with 7GH/s-9GH/s shares so far 124723 and no blocks so be glad you are not testing the pool like me

I am getting blocks every now and then while solo mining. Is CGminer suggest over Reaper for mining?

I'm getting more blocks with CGminer.

[kramble]

I had the same errors trying to mine when I tried to load the Bitcoin bitstream.  So I troubleshot and found that the "libftd2xx.so" symlink was pointed to "libftd2xx.so.1.1.12" instead of the modified "libftd2xx.so.1.0.4".  Now the Bitcoin bitstream loads and mines without a problem.  And your bitstream loads and connects to the server an is waiting to mine.

Code:

python mine.py -u 127.0.0.1:8772 -w <username:password>

2013-10-27 15:19:34 | Device 0 opened (A5VNV3JE)
2013-10-27 15:19:35 | Connected to 2 FPGAs
2013-10-27 15:19:35 | FPGA 0 is running at 26MHz
2013-10-27 15:19:35 | FPGA 1 is running at 26MHz
2013-10-27 15:19:35 | Connected to server
0 kH/s | 0/0/0 0.00%/0.00%

That does not look so good. Even without the correct midstate it should be returning nonces (around one a minute), but its just idle. I'll have to go back and look over the code again, I must have got something wrong.

Anyway I've forked the miner https://github.com/kramble/x6500-miner Just two files are changed (mine.py and fpga.py). Its not been tested live, but it does run (after a fashion). Let me know what it does against a real device. NB You will need to compile midstate.c and checkblake.c from https://github.com/kramble/FPGA-Blakecoin-Miner/tree/master/MiningSoftware/compile-midstate (since you're on unix its just a trivial "make midstate" and "make checkblake", no makefile needed but you do need the sph*.h headers).

[atavacron]

I had the same errors trying to mine when I tried to load the Bitcoin bitstream.  So I troubleshot and found that the "libftd2xx.so" symlink was pointed to "libftd2xx.so.1.1.12" instead of the modified "libftd2xx.so.1.0.4".  Now the Bitcoin bitstream loads and mines without a problem.  And your bitstream loads and connects to the server an is waiting to mine.

Code:

python mine.py -u 127.0.0.1:8772 -w <username:password>

2013-10-27 15:19:34 | Device 0 opened (A5VNV3JE)
2013-10-27 15:19:35 | Connected to 2 FPGAs
2013-10-27 15:19:35 | FPGA 0 is running at 26MHz
2013-10-27 15:19:35 | FPGA 1 is running at 26MHz
2013-10-27 15:19:35 | Connected to server
0 kH/s | 0/0/0 0.00%/0.00%

That does not look so good. Even without the correct midstate it should be returning nonces (around one a minute), but its just idle. I'll have to go back and look over the code again, I must have got something wrong.

Anyway I've forked the miner https://github.com/kramble/x6500-miner Just two files are changed (mine.py and fpga.py). Its not been tested live, but it does run (after a fashion). Let me know what it does against a real device. NB You will need to compile midstate.c and checkblake.c from https://github.com/kramble/FPGA-Blakecoin-Miner/tree/master/MiningSoftware/compile-midstate (since you're on unix its just a trivial "make midstate" and "make checkblake", no makefile needed but you do need the sph*.h headers).

I'll try the fork and get back to you asap.

[atavacron]

I had the same errors trying to mine when I tried to load the Bitcoin bitstream.  So I troubleshot and found that the "libftd2xx.so" symlink was pointed to "libftd2xx.so.1.1.12" instead of the modified "libftd2xx.so.1.0.4".  Now the Bitcoin bitstream loads and mines without a problem.  And your bitstream loads and connects to the server an is waiting to mine.

Code:

python mine.py -u 127.0.0.1:8772 -w <username:password>

2013-10-27 15:19:34 | Device 0 opened (A5VNV3JE)
2013-10-27 15:19:35 | Connected to 2 FPGAs
2013-10-27 15:19:35 | FPGA 0 is running at 26MHz
2013-10-27 15:19:35 | FPGA 1 is running at 26MHz
2013-10-27 15:19:35 | Connected to server
0 kH/s | 0/0/0 0.00%/0.00%

That does not look so good. Even without the correct midstate it should be returning nonces (around one a minute), but its just idle. I'll have to go back and look over the code again, I must have got something wrong.

Anyway I've forked the miner https://github.com/kramble/x6500-miner Just two files are changed (mine.py and fpga.py). Its not been tested live, but it does run (after a fashion). Let me know what it does against a real device. NB You will need to compile midstate.c and checkblake.c from https://github.com/kramble/FPGA-Blakecoin-Miner/tree/master/MiningSoftware/compile-midstate (since you're on unix its just a trivial "make midstate" and "make checkblake", no makefile needed but you do need the sph*.h headers).

I'll try the fork and get back to you asap.

The forked code loads fine but the miner sits idle as before.

Code:

python mine.py -u 127.0.0.1:8772 -w <username:password>

2013-10-27 16:18:37 | Device 0 opened (A5VNV3JE)
2013-10-27 16:18:38 | Connected to 2 FPGAs
2013-10-27 16:18:38 | FPGA 0 is running at 26MHz
2013-10-27 16:18:38 | FPGA 1 is running at 26MHz
2013-10-27 16:18:38 | Connected to server
2013-10-27 16:19:37 | Exiting...
Run Summary:              
-------------
Device: 0
Serial: A5VNV3JE
Number of FPGAs: 2
Running time: 59s
Getwork interval: 20 secs
FPGA 0:
  Accepted: 0
  Rejected: 0 (0.00%)
  Invalid: 0 (0.00%)
  Hashrate (all nonces): 0 kH/s
  Hashrate (valid nonces): 0 kH/s
  Hashrate (accepted shares): 0 kH/s
FPGA 1:
  Accepted: 0
  Rejected: 0 (0.00%)
  Invalid: 0 (0.00%)
  Hashrate (all nonces): 0 kH/s
  Hashrate (valid nonces): 0 kH/s
  Hashrate (accepted shares): 0 kH/s
Total hashrate for device: 0 kH/s / 0 kH/s / 0 kH/s

[kramble]

The forked code loads fine but the miner sits idle as before.

OK, thanks for testing. I'll need to go over the original x6500 code in some detail to understand what's happening (I did a very quick hack here and don't have a full grasp of the detail of the jtag_comm code, its not something that's easily testable in simulation). It'll probably take me a couple of days and I may need to put together a debug version (if you're happy to continue testing).

Hopefully its just a simple mistake and we can get this running fairly quickly. As a sweetener its quite likely the board will run at around 800MHash/sec (like the lancelot) and very low wattage once its working and a second core is instantiated.

[atavacron]

The forked code loads fine but the miner sits idle as before.

OK, thanks for testing. I'll need to go over the original x6500 code in some detail to understand what's happening (I did a very quick hack here and don't have a full grasp of the detail of the jtag_comm code, its not something that's easily testable in simulation). It'll probably take me a couple of days and I may need to put together a debug version (if you're happy to continue testing).

Hopefully its just a simple mistake and we can get this running fairly quickly. As a sweetener its quite likely the board will run at around 800MHash/sec (like the lancelot) and very low wattage once its working and a second core is instantiated.

Thanks.  I'll tinker around to see what I can break :-)

[bronan]

I see many people complain at reaper but its pretty damn stable, the only way it crashes is if you expect too much of your gpu's

On my system it has run many days without once crashing till i pushed the card a bit higher and poof there it went.

We all want the fastest speed but we sometimes forget that might be not what the card can cope with.

I found lots of issues to get cgminer/bfgminer to make a initial kernel file, as soon it has been made it simply allows anything.

Found this several times with scrypt coins i was mining at, as long as it does not create that  #.bin file you will see it crash

I reported that a long time ago but both developers did not react on this issue.

We might even try to make a few *.bin files and provide these for those having issues to make it easier


When using the cgminer which is posted make a batch file containing :

@echo off
cgminer -c blake256.conf


and start that for mining
on my 79xx cards going beyond intensity 13 is not working for me