http://www.blakecoinmining.com/BlakecoinGUIMinerSource.zip <-- Source
Will put up more detailed information later.
Here's a screenshot:
Topic: [ANN][BLC] Blakecoin Blake-256 for GPU/FPGA With Merged Mined Pools Stable Net - page 179. (Read 409641 times)
October 27, 2013, 07:59:38 PM
http://www.blakecoinmining.com/BlakecoinGUIMiner.zip <--- Compiled Binary
http://www.blakecoinmining.com/BlakecoinGUIMinerSource.zip <-- Source
Will put up more detailed information later.
Here's a screenshot:
http://www.blakecoinmining.com/BlakecoinGUIMinerSource.zip <-- Source
Will put up more detailed information later.
Here's a screenshot:
October 27, 2013, 07:38:56 PM
My python fu isn't very good but since I like a challenge I'll see what I can do.
Cheers, it can't be worse than mine (just mind those spaces/tabs, whoever had the bright idea that whitespace should be syntax deserves, well, something not nice
). See if you can work out if the data is getting into/out of the fpga OK. Also run it with the verbose flag and turn on all the debug stuff so you can see what its actually doing.I'll put together a more robust build tomorrow that avoids all that messy clock-crossing and serial-shifting. Perhaps its just idle because I'm not handling the comm_new_work strobe properly. Shame there are no leds on that board we can flash to see what its getting up to
There are three LEDs on the board, one at the power input and two at the far sides of the FPGAs with the label "Done". At power on the two "Done" LEDs are off. However, there turn on just after loading the bitstream.
October 27, 2013, 05:39:30 PM
Just for information 7970 at 900 mhz core and memory at 300 mhz does give 2.2 Gh on blakecoin
Intensity 7, worksize 64
This card soon gets replaced by a R9 290X
Intensity 7, worksize 64
This card soon gets replaced by a R9 290X
October 27, 2013, 05:34:54 PM
My python fu isn't very good but since I like a challenge I'll see what I can do.
Cheers, it can't be worse than mine (just mind those spaces/tabs, whoever had the bright idea that whitespace should be syntax deserves, well, something not nice
). See if you can work out if the data is getting into/out of the fpga OK. Also run it with the verbose flag and turn on all the debug stuff so you can see what its actually doing.I'll put together a more robust build tomorrow that avoids all that messy clock-crossing and serial-shifting. Perhaps its just idle because I'm not handling the comm_new_work strobe properly. Shame there are no leds on that board we can flash to see what its getting up to
October 27, 2013, 05:15:42 PM
Thanks. I'll tinker around to see what I can break :-)
Try setting the overclock parameter (not too high, no more than say 150MHz), and see what value gets read back. I'm somewhat bemused that its reporting a clock speed of 26MHz while the initial value is hard coded at 50Mhz (almost but not quite double). In binary that's 11010 as opposed to 110010 so its not obvious how these can be conflated.
I think the best approach to debugging this is to get the comms working reliably first (so if your python is up to it you could try writing and reading back the registers, see jtag_comm.v for details), then possibly swap out my serial bus optimizations for the earlier wide-bus version as this does not then rely on a comm_new_work strobe to initiate the hasher).
I can do some testing on my Lancelot, once I've worked out how to drive the jtag bus outwith of Impact.
My python fu isn't very good but since I like a challenge I'll see what I can do.
October 27, 2013, 05:12:51 PM
which fpga are you using kramble ?
Xilinx Spartan6 LX150, pretty ubiquitous for the bitcoin FPGA miners (with the exception of BFL who went for a locked-down Altera chip). I've just got the one Lancelot board myself, but it should be fairly easy to port to the other boards: Ztex, Cainsmore, Modminer (notwithstanding the hiccup we're currently having with the X6500).
October 27, 2013, 05:04:06 PM
which fpga are you using kramble ?
October 27, 2013, 04:24:45 PM
Thanks. I'll tinker around to see what I can break :-)
Try setting the overclock parameter (not too high, no more than say 150MHz), and see what value gets read back. I'm somewhat bemused that its reporting a clock speed of 26MHz while the initial value is hard coded at 50Mhz (almost but not quite double). In binary that's 11010 as opposed to 110010 so its not obvious how these can be conflated.
I think the best approach to debugging this is to get the comms working reliably first (so if your python is up to it you could try writing and reading back the registers, see jtag_comm.v for details), then possibly swap out my serial bus optimizations for the earlier wide-bus version as this does not then rely on a comm_new_work strobe to initiate the hasher).
I can do some testing on my Lancelot, once I've worked out how to drive the jtag bus outwith of Impact.
October 27, 2013, 03:53:18 PM
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
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
October 27, 2013, 03:41:21 PM
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 :-)
October 27, 2013, 03:40:05 PM
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.
October 27, 2013, 03:21:18 PM
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
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
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
October 27, 2013, 03:07:01 PM
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
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.
October 27, 2013, 03:04:23 PM
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
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).
October 27, 2013, 02:43:49 PM
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.
October 27, 2013, 02:39:16 PM
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?
October 27, 2013, 02:25:20 PM
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
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%
October 27, 2013, 02:06:49 PM
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
October 27, 2013, 01:59:42 PM
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...
October 27, 2013, 01:13:50 PM
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.
Jump to: