atavacron
Full Member
Offline
Activity: 224
Merit: 100
The definition of insanity is doing the same thing
|
|
October 27, 2013, 04:23:08 PM |
|
Awesome Kramble!!! I'll start experimenting with it right away.
|
|
|
|
kramble
|
|
October 27, 2013, 04:31:28 PM |
|
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
Full Member
Offline
Activity: 224
Merit: 100
The definition of insanity is doing the same thing
|
|
October 27, 2013, 04:40:35 PM |
|
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
Full Member
Offline
Activity: 224
Merit: 100
The definition of insanity is doing the same thing
|
|
October 27, 2013, 05:21:50 PM |
|
Kramble, The program.py from fizzisist seems to find the x6500 but gives me the following errors on the discovery: ./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
|
|
October 27, 2013, 05:49:31 PM |
|
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
Full Member
Offline
Activity: 224
Merit: 100
The definition of insanity is doing the same thing
|
|
October 27, 2013, 05:52:23 PM |
|
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
|
|
October 27, 2013, 06:07:14 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).
|
|
|
|
kev7112001
|
|
October 27, 2013, 06:07:34 PM |
|
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
|
MCXNOW MODERATOR
|
|
|
atavacron
Full Member
Offline
Activity: 224
Merit: 100
The definition of insanity is doing the same thing
|
|
October 27, 2013, 06: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.
|
|
|
|
SpeedDemon13
|
|
October 27, 2013, 06: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...
|
CRYPTSY exchange: https://www.cryptsy.com/users/register?refid=9017 BURST= BURST-TE3W-CFGH-7343-6VM6R BTC=1CNsqGUR9YJNrhydQZnUPbaDv6h4uaYCHv ETH=0x144bc9fe471d3c71d8e09d58060d78661b1d4f32 SHF=0x13a0a2cb0d55eca975cf2d97015f7d580ce52d85 EXP=0xd71921dca837e415a58ca0d6dd2223cc84e0ea2f SC=6bdf9d12a983fed6723abad91a39be4f95d227f9bdb0490de3b8e5d45357f63d564638b1bd71 CLAMS=xGVTdM9EJpNBCYAjHFVxuZGcqvoL22nP6f SOIL=0x8b5c989bc931c0769a50ecaf9ffe490c67cb5911
|
|
|
BlueDragon747 (OP)
Legendary
Offline
Activity: 1509
Merit: 1030
Solutions Architect
|
|
October 27, 2013, 07: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
|
Info: Github - Blakecoin.org - BCT Blakecoin thread - Twitter - BCS - BlakeZone Trade Blakecoin: Xeggex.com Merged Mining Pools: EU3 - NY2/AT1 - LA1Donation Addresses: BLC: Bd3jJftFbwxWSKNSNz35vkDd57kG6jHAjt PHO: BZXPMc8eF9YZcJStskkP2bVia38fv9VmuT BBTC: 2h8c4NbzXJXk6QQ89r7YYMGhe13gQUC2ajD ELT: e7cm6cAgpfhvk3Myh2Jkmi1nqaHtDHnxXb UMO: uQH9H17t7kz3eVQ3vKDzMsWCK4hn5nh2gC LIT: 8p8Z4h5fkZ8SCoyEtihKcjzZLA7gFjTdmL BTC: 1Q6kgcNqhKh8u67m6Gj73T2LMgGseETwR6
|
|
|
atavacron
Full Member
Offline
Activity: 224
Merit: 100
The definition of insanity is doing the same thing
|
|
October 27, 2013, 07: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. 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
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
|
|
October 27, 2013, 07: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?
|
CRYPTSY exchange: https://www.cryptsy.com/users/register?refid=9017 BURST= BURST-TE3W-CFGH-7343-6VM6R BTC=1CNsqGUR9YJNrhydQZnUPbaDv6h4uaYCHv ETH=0x144bc9fe471d3c71d8e09d58060d78661b1d4f32 SHF=0x13a0a2cb0d55eca975cf2d97015f7d580ce52d85 EXP=0xd71921dca837e415a58ca0d6dd2223cc84e0ea2f SC=6bdf9d12a983fed6723abad91a39be4f95d227f9bdb0490de3b8e5d45357f63d564638b1bd71 CLAMS=xGVTdM9EJpNBCYAjHFVxuZGcqvoL22nP6f SOIL=0x8b5c989bc931c0769a50ecaf9ffe490c67cb5911
|
|
|
atavacron
Full Member
Offline
Activity: 224
Merit: 100
The definition of insanity is doing the same thing
|
|
October 27, 2013, 07: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.
|
|
|
|
kramble
|
|
October 27, 2013, 08: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. 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
Full Member
Offline
Activity: 224
Merit: 100
The definition of insanity is doing the same thing
|
|
October 27, 2013, 08: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. 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
Full Member
Offline
Activity: 224
Merit: 100
The definition of insanity is doing the same thing
|
|
October 27, 2013, 08: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. 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. 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
|
|
October 27, 2013, 08: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.
|
|
|
|
atavacron
Full Member
Offline
Activity: 224
Merit: 100
The definition of insanity is doing the same thing
|
|
October 27, 2013, 08: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 :-)
|
|
|
|
bronan
|
|
October 27, 2013, 08:53:18 PM Last edit: October 27, 2013, 10:01:18 PM by 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
|
|
|
|
|