Getting 13.4ish with 160MHz / icarus-timing 1.0=20
HW errors around 1% -is this reasonable? EDIT - just saw Kramble's post error rate seems simlar.
HW errors around 1% -
yes I see about 1.2-1.4% HW error rate as well
Topic: [ANN][BLC] Blakecoin Blake-256 for GPU/FPGA With Merged Mined Pools Stable Net - page 112. (Read 409641 times)
April 09, 2014, 09:56:55 AM
yes I see about 1.2-1.4% HW error rate as well
April 09, 2014, 09:54:02 AM
Getting 13.4ish with 160MHz / icarus-timing 1.0=20
HW errors around 1% -is this reasonable? EDIT - just saw Kramble's post error rate seems simlar.
HW errors around 1% -
April 09, 2014, 09:49:01 AM
I have tried turning on the Lancelot and Icarus simultaneously and both take the same time before DONE lights up. Also setting 1 bit / 4 bit makes no difference to the programming time. I surmise that it is running in 1 bit mode regardless of the option chosen in impact.
Out of interest, FPGA1 running 3 core and FPGA2 running 2 core returns WU around 10 (clocked at 160MHz).
Out of interest, FPGA1 running 3 core and FPGA2 running 2 core returns WU around 10 (clocked at 160MHz).
Good stuff. You're probably correct about the 1 bit mode as the ug380 doc implies 4 bit needs to be enabled while compiling the bitstream (actually just the BitGen stage, so it does not need a full compilation to change the flag). Alternatively it could be the configrate (another BitGen parameter) which defaults to 3MHz (slowest rate). It doesn't really matter as a 10 second bootup time is not going to be a problem, so I don't think it's worth trying to speed this up.
Theoretically speaking the 2 core at 195MHz should give a WU of 10.9, and 3 core at 160MHz should give 13.4 (WU = 60 * hashrate / 2^32 where the hashrate is the total number of cores for both FPGAs times the clock frequency).
In practice for the 3 core at 160MHz on my lancelot I'm seeing around 13.1 (grep -c Accept log.txt / uptime in minutes) with around 1.3% HW error rate.
(Cross-posted with blue's comment)
April 09, 2014, 09:44:39 AM
For anyone needing the header connector for the Icarus, RS part no. 670 3695 fits perfectly. If you are in the UK I have a few spares as you have to order in bags of 10.
Kramble, today every .mcs I have loaded appears to work. I suspect the makeshift connector I had was possibly to blame as well as user error! The unit which had DONE1 but not DONE2 works after reprogramming.
I have tried turning on the Lancelot and Icarus simultaneously and both take the same time before DONE lights up. Also setting 1 bit / 4 bit makes no difference to the programming time. I surmise that it is running in 1 bit mode regardless of the option chosen in impact.
Out of interest, FPGA1 running 3 core and FPGA2 running 2 core returns WU around 10 (clocked at 160MHz).
Kramble, today every .mcs I have loaded appears to work. I suspect the makeshift connector I had was possibly to blame as well as user error! The unit which had DONE1 but not DONE2 works after reprogramming.
I have tried turning on the Lancelot and Icarus simultaneously and both take the same time before DONE lights up. Also setting 1 bit / 4 bit makes no difference to the programming time. I surmise that it is running in 1 bit mode regardless of the option chosen in impact.
Out of interest, FPGA1 running 3 core and FPGA2 running 2 core returns WU around 10 (clocked at 160MHz).
Lancelot 1 ~14WU:
cgminer-lancelot-52 --disable-gpu --icarus-timing 1.0=20 -S \\.\COM12 --url stratum+tcp://ny2.blakecoin.com:3334 --userpass User.worker:password --cainsmore-clock 165 -Q 4
Lancelot 2 ~13WU:
cgminer-lancelot-52 --disable-gpu --icarus-timing 1.0=20 -S \\.\COM7 --url stratum+tcp://ny2.blakecoin.com:3334 --userpass User.worker:password --cainsmore-clock 160 -Q 4
on 2 core I was getting about ~10WU
April 09, 2014, 09:18:13 AM
For anyone needing the header connector for the Icarus, RS part no. 670 3695 fits perfectly. If you are in the UK I have a few spares as you have to order in bags of 10.
Kramble, today every .mcs I have loaded appears to work. I suspect the makeshift connector I had was possibly to blame as well as user error! The unit which had DONE1 but not DONE2 works after reprogramming.
I have tried turning on the Lancelot and Icarus simultaneously and both take the same time before DONE lights up. Also setting 1 bit / 4 bit makes no difference to the programming time. I surmise that it is running in 1 bit mode regardless of the option chosen in impact.
Out of interest, FPGA1 running 3 core and FPGA2 running 2 core returns WU around 10 (clocked at 160MHz).
Kramble, today every .mcs I have loaded appears to work. I suspect the makeshift connector I had was possibly to blame as well as user error! The unit which had DONE1 but not DONE2 works after reprogramming.
I have tried turning on the Lancelot and Icarus simultaneously and both take the same time before DONE lights up. Also setting 1 bit / 4 bit makes no difference to the programming time. I surmise that it is running in 1 bit mode regardless of the option chosen in impact.
Out of interest, FPGA1 running 3 core and FPGA2 running 2 core returns WU around 10 (clocked at 160MHz).
April 08, 2014, 02:58:15 PM
By "it did not work", I meant it wouldn't mine. I am assuming the "done" lights mean "I am booted up and ready to go" or similar (they are orange on Icarus). Unfortunately I was not aware of them earlier so did not check them.
Thanks. The actual meaning of the DONE lights is that the FPGA has successfully loaded the bitstream (from ROM after power-up, or from JTAG if you have just programmed a bitfile). This is why I was asking since if they came on after power-up, then it was likely that the ROMs had successfully been programmed (though there is a chance that the erase/program cycle had simply done nothing at all, and the previous bitstream was still present).
There are a number of things that can break the mining (eg comms problems, of even the fact that the FPGAs are chained, so the second FPGA won't mine unless the first is working, while the first one can mine quite happily on its own).
The different timings are probably due to the /1 or /4 bit configurations (or just possibly due to a higher configrate for the original bitcoin bitstream). It would be useful to confirm this as to whether the /4 blake loads as fast as the original bitcoin.
That possibly faulty board with just one DONE illuminating? Was it like that when you got it (with bitcoin loaded) or only after programming? If it was already faulty for bitcoin and it's the second FPGA that's failing, it may still mine OK on the first FPGA (unfortunately the converse is not true).
Anyway, enough for today. Getting late.
PS Just saw your edit. Looks like we are pretty much agreement. The MCS programming is a lot longer using my parallel port programmer (45 minutes per FPGA) so I've only done it twice so far (for my 2 core and just yesterday for blue's 3 core, at which point I decided to rebuild my workbench, unfortunately and pulled it all apart).
April 08, 2014, 02:42:11 PM
By "it did not work", I meant it wouldn't mine. I am assuming the "done" lights mean "I am booted up and ready to go" or similar (they are orange on Icarus). Unfortunately I was not aware of them earlier so did not check them.
I have several boards as follows:
1. The board which mines blakecoin now. Done 1/2 illuminate after around 10 seconds.
2. The board which I started with and put to the side in case it was faulty. Done1 illuminates after around 10 seconds, done2 does not illuminate at all.
3. Another board which I have not attempted to program. Done1/2 illuminate almost immediately.
EDIT:
Here is my hypothesis:
1. Your 2 core MCS probably would have worked but I did not flash both FPGAs and reboot and test due to the error message.
2. My first attempt at building a .MCS was flawed and although I did flash both FPGAs and reboot and test it did not work (I seem to recall getting a different error at some point and this file did not load on Lancelot.)
3. My second attempt at building an MCS worked, I ignored the errors and rebooted and "it worked".
I will retry tomorrow using your 2 core mcs file and let you know how if it does indeed work in spite of errors. Unfortunately the long programming time makes checking all the options rather a slow process.
I have several boards as follows:
1. The board which mines blakecoin now. Done 1/2 illuminate after around 10 seconds.
2. The board which I started with and put to the side in case it was faulty. Done1 illuminates after around 10 seconds, done2 does not illuminate at all.
3. Another board which I have not attempted to program. Done1/2 illuminate almost immediately.
EDIT:
Here is my hypothesis:
1. Your 2 core MCS probably would have worked but I did not flash both FPGAs and reboot and test due to the error message.
2. My first attempt at building a .MCS was flawed and although I did flash both FPGAs and reboot and test it did not work (I seem to recall getting a different error at some point and this file did not load on Lancelot.)
3. My second attempt at building an MCS worked, I ignored the errors and rebooted and "it worked".
I will retry tomorrow using your 2 core mcs file and let you know how if it does indeed work in spite of errors. Unfortunately the long programming time makes checking all the options rather a slow process.
April 08, 2014, 02:20:34 PM
I rebuilt the .mcs file from scratch - tried it on Lancelot and it worked. Then tried it on Icarus (with 4 bit) still got the failed message as before but when I rebooted it worked!
I just want to tease out the exact meaning of "it worked" (and what you meant by "it did not work" earlier). Are you talking about the DONE (white) status LEDs, or whether the FPGA successfully mined blakecoin?
Did the DONE LEDs light after power cycling in the earlier tries (in which case, the ROMs had indeed programmed sucessfully), or
just this latest time? Very important to be sure here.
Quote
Thank you both for all your assistance.
You're welcome
April 08, 2014, 02:08:19 PM
Success!
I rebuilt the .mcs file from scratch - tried it on Lancelot and it worked. Then tried it on Icarus (with 4 bit) still got the failed message as before but when I rebooted it worked!
I will now try it with Bluedragon's .mcs to see if this works.
I have ordered a 2mm header and will report back if this fits.
Thank you both for all your assistance.
I rebuilt the .mcs file from scratch - tried it on Lancelot and it worked. Then tried it on Icarus (with 4 bit) still got the failed message as before but when I rebooted it worked!
I will now try it with Bluedragon's .mcs to see if this works.
I have ordered a 2mm header and will report back if this fits.
Thank you both for all your assistance.
April 08, 2014, 01:43:10 PM
CFI/PRM files for the two and three core bitstreams (no pastebin sorry so I've cat'd them together here)
You're on an older software version O.40d while mine is P.49d (ISE 14.4). I don't know if that matters though.
Code:
# PROMGEN: Xilinx Prom Generator P.49d
# Copyright (c) 1995-2012 Xilinx, Inc. All rights reserved.
SOFTWARE_VERSION P.49d
DATE 01/02/2014 - 14:05
SOURCE C:\blakecoin\USETHIS_blakefourbufce-2core-ucf146-fmax154.mcs
DEVICE 8192K
DATA_WIDTH 1
FILL_DATA 0xFF
SIGNATURE 0x43FC3925
START_ADDRESS 0x00000000 END_ADDRESS 0x00406533 DIRECTION_UP "C:/blakecoin/USETHIS_blakefourbufce-2core-ucf146-fmax154.bit" 6slx150fgg484
====== snip =========
PROMGEN: Xilinx Prom Generator P.49d
Copyright (c) 1995-2012 Xilinx, Inc. All rights reserved.
promgen -w -p mcs -c FF -o C:\blakecoin//USETHIS_blakefourbufce-2core-ucf146-fmax154.mcs -s 8192 -u 0000 C:/blakecoin/USETHIS_blakefourbufce-2core-ucf146-fmax154.bit -spi
PROM C:\blakecoin\USETHIS_blakefourbufce-2core-ucf146-fmax154.prm map: Thu Jan 02 14:05:44 2014
Calculating PROM checksum with fill value ff
Format Mcs86 (32-bit)
Size 8192K
PROM start 0000:0000
PROM end 007f:ffff
PROM checksum 43fc3925
Addr1 Addr2 Date File(s)
0000:0000 0040:6533 Oct 27 12:01:13 2013 C:/blakecoin/USETHIS_blakefourbufce-2core-ucf146-fmax154.bit
====== snip =========
# PROMGEN: Xilinx Prom Generator P.49d
# Copyright (c) 1995-2012 Xilinx, Inc. All rights reserved.
SOFTWARE_VERSION P.49d
DATE 04/07/2014 - 11:26
SOURCE C:\blakecoin\Untitled.mcs
DEVICE 8192K
DATA_WIDTH 1
FILL_DATA 0xFF
SIGNATURE 0x45C1113A
START_ADDRESS 0x00000000 END_ADDRESS 0x00406533 DIRECTION_UP "C:/blakecoin/blakeminer_FourGatexClk_3core_fmax-102.bit" 6slx150fgg484
====== snip =========
PROMGEN: Xilinx Prom Generator P.49d
Copyright (c) 1995-2012 Xilinx, Inc. All rights reserved.
promgen -w -p mcs -c FF -o C:\blakecoin//Untitled -s 8192 -u 0000 C:/blakecoin/blakeminer_FourGatexClk_3core_fmax-102.bit -spi
PROM C:\blakecoin\Untitled.prm map: Mon Apr 07 11:26:34 2014
Calculating PROM checksum with fill value ff
Format Mcs86 (32-bit)
Size 8192K
PROM start 0000:0000
PROM end 007f:ffff
PROM checksum 45c1113a
Addr1 Addr2 Date File(s)
0000:0000 0040:6533 Apr 04 13:12:08 2014 C:/blakecoin/blakeminer_FourGatexClk_3core_fmax-102.bit
# Copyright (c) 1995-2012 Xilinx, Inc. All rights reserved.
SOFTWARE_VERSION P.49d
DATE 01/02/2014 - 14:05
SOURCE C:\blakecoin\USETHIS_blakefourbufce-2core-ucf146-fmax154.mcs
DEVICE 8192K
DATA_WIDTH 1
FILL_DATA 0xFF
SIGNATURE 0x43FC3925
START_ADDRESS 0x00000000 END_ADDRESS 0x00406533 DIRECTION_UP "C:/blakecoin/USETHIS_blakefourbufce-2core-ucf146-fmax154.bit" 6slx150fgg484
====== snip =========
PROMGEN: Xilinx Prom Generator P.49d
Copyright (c) 1995-2012 Xilinx, Inc. All rights reserved.
promgen -w -p mcs -c FF -o C:\blakecoin//USETHIS_blakefourbufce-2core-ucf146-fmax154.mcs -s 8192 -u 0000 C:/blakecoin/USETHIS_blakefourbufce-2core-ucf146-fmax154.bit -spi
PROM C:\blakecoin\USETHIS_blakefourbufce-2core-ucf146-fmax154.prm map: Thu Jan 02 14:05:44 2014
Calculating PROM checksum with fill value ff
Format Mcs86 (32-bit)
Size 8192K
PROM start 0000:0000
PROM end 007f:ffff
PROM checksum 43fc3925
Addr1 Addr2 Date File(s)
0000:0000 0040:6533 Oct 27 12:01:13 2013 C:/blakecoin/USETHIS_blakefourbufce-2core-ucf146-fmax154.bit
====== snip =========
# PROMGEN: Xilinx Prom Generator P.49d
# Copyright (c) 1995-2012 Xilinx, Inc. All rights reserved.
SOFTWARE_VERSION P.49d
DATE 04/07/2014 - 11:26
SOURCE C:\blakecoin\Untitled.mcs
DEVICE 8192K
DATA_WIDTH 1
FILL_DATA 0xFF
SIGNATURE 0x45C1113A
START_ADDRESS 0x00000000 END_ADDRESS 0x00406533 DIRECTION_UP "C:/blakecoin/blakeminer_FourGatexClk_3core_fmax-102.bit" 6slx150fgg484
====== snip =========
PROMGEN: Xilinx Prom Generator P.49d
Copyright (c) 1995-2012 Xilinx, Inc. All rights reserved.
promgen -w -p mcs -c FF -o C:\blakecoin//Untitled -s 8192 -u 0000 C:/blakecoin/blakeminer_FourGatexClk_3core_fmax-102.bit -spi
PROM C:\blakecoin\Untitled.prm map: Mon Apr 07 11:26:34 2014
Calculating PROM checksum with fill value ff
Format Mcs86 (32-bit)
Size 8192K
PROM start 0000:0000
PROM end 007f:ffff
PROM checksum 45c1113a
Addr1 Addr2 Date File(s)
0000:0000 0040:6533 Apr 04 13:12:08 2014 C:/blakecoin/blakeminer_FourGatexClk_3core_fmax-102.bit
You're on an older software version O.40d while mine is P.49d (ISE 14.4). I don't know if that matters though.
April 08, 2014, 01:32:32 PM
Looks like the pullup resistor on the Icarus CSO_B pin is there, it's just shown separately on the Icarus schematic - look down from U4, below RN3 there are 3 pullup resistors - the bottom one R25 connects to FPGA2_CS which is also connected to U4 pin 1.
April 08, 2014, 01:29:34 PM
Just downloading ug380, will take a look.
xapp586-spi-flash.pdf is useful too (google it, I won't copy the google link here). It's for Artix/Kinetix 7 but is pretty much the same as Spartan-6.
Quote
Could either of you post the contents of your .cfi / .prm files so I can compare to the ones I am generating please?
Will take a little while as I moved stuff and the PC needs reassembling.
April 08, 2014, 01:20:07 PM
Just downloading ug380, will take a look.
Could either of you post the contents of your .cfi / .prm files so I can compare to the ones I am generating please?
Could either of you post the contents of your .cfi / .prm files so I can compare to the ones I am generating please?
April 08, 2014, 01:12:11 PM
Great, saves me uploading my mcs to dropbox (different PC, so involves a bit more effort).
I'm at a bit of a loss here as to what's going wrong. One thought was that the Icarus might need a slower configrate in the bitgen parameters, but that's just clutching at straws really. What do you make of the SPI configuration chapter in ug380?
Unfortunately I've just reorganised things in my "workshop" (aka bedroom), so my lancelot is now running standalone with the raspi and putting it back together for programming is going to be a bit of a pain. I'll have a look at it tomorrow (perhaps I'll try out the USB programmer instead of my parallel-port one).
PS
Quote
Tried power cycling after programming but it did not work.
Do you mean that the done LED's (white on lancelot, not sure what they are on icarus) failed to light?
April 08, 2014, 01:04:22 PM
Still failing on 1 bit - see pastebin for output.
http://pastebin.com/rQB8PYWm
I'm going to try using your instructions to convert the 3 core .bit file to a .mcs and see if this works.
http://pastebin.com/rQB8PYWm
I'm going to try using your instructions to convert the 3 core .bit file to a .mcs and see if this works.
Right click save as
http://blakecoin.org/blakeminer_FourGatexClk_3core_fmax-102.mcs
April 08, 2014, 12:38:11 PM
Built the new .mcs and it does not work with Icarus. Currently trying it on the Lancelot to compare the log outputs.
>>>> Lancelot failed with the 3 core .mcs file, so I must be doing something wrong in the build process. Now retrying Lancelot with the older .mcs file which did work. I have noticed that trying to program my .mcs file (created with 1 bit selection) choosing 4 bit for lancelot generates a warning. However, using your file there is no warning - possible something to do with the missing .cfi file?
Contents of .cfi file:
# PROMGEN: Xilinx Prom Generator O.40d
# Copyright (c) 1995-2011 Xilinx, Inc. All rights reserved.
SOFTWARE_VERSION O.40d
DATE 04/08/2014 - 18:14
SOURCE C:\blake\blakeminer_FourGatexClk_3core_fmax-102.mcs
DEVICE 8192K
DATA_WIDTH 1
FILL_DATA 0xFF
SIGNATURE 0x45C1113A
START_ADDRESS 0x00000000 END_ADDRESS 0x00406533 DIRECTION_UP "C:/blake/blakeminer_FourGatexClk_3core_fmax-102.bit" 6slx150fgg484
Tried power cycling after programming but it did not work.
It flagged the missing cfi file previously when I programmed Lancelot but it still worked.
>>>> Lancelot failed with the 3 core .mcs file, so I must be doing something wrong in the build process. Now retrying Lancelot with the older .mcs file which did work. I have noticed that trying to program my .mcs file (created with 1 bit selection) choosing 4 bit for lancelot generates a warning. However, using your file there is no warning - possible something to do with the missing .cfi file?
Contents of .cfi file:
# PROMGEN: Xilinx Prom Generator O.40d
# Copyright (c) 1995-2011 Xilinx, Inc. All rights reserved.
SOFTWARE_VERSION O.40d
DATE 04/08/2014 - 18:14
SOURCE C:\blake\blakeminer_FourGatexClk_3core_fmax-102.mcs
DEVICE 8192K
DATA_WIDTH 1
FILL_DATA 0xFF
SIGNATURE 0x45C1113A
START_ADDRESS 0x00000000 END_ADDRESS 0x00406533 DIRECTION_UP "C:/blake/blakeminer_FourGatexClk_3core_fmax-102.bit" 6slx150fgg484
Tried power cycling after programming but it did not work.
It flagged the missing cfi file previously when I programmed Lancelot but it still worked.
April 08, 2014, 12:24:17 PM
Still failing on 1 bit - see pastebin for output.
http://pastebin.com/rQB8PYWm
I'm going to try using your instructions to convert the 3 core .bit file to a .mcs and see if this works.
http://pastebin.com/rQB8PYWm
I'm going to try using your instructions to convert the 3 core .bit file to a .mcs and see if this works.
It's complaining about a missing .cfi file, doing the conversion yourself will fix that, and it's a faster bitstream anyway, so it's the one you'll want to have programmed into the ROMs.
I had a look at the xilinx spartan 6 configuration guide (ug380), fiendishly complicated. It seems to say that 1 bit is the default for SPI, and that the 4 bit option needs to be enabled by a bitgen parameter spi_buswidth:4 (which is done during the build process, and I certainly didn't set it). Except that you've got it to work on the lancelot anyway, so impact must be overriding that setting. Anyway the lancelot and icarus are using the same ROMs, so if it works on one, it ought to work on the other too.
EDIT: Actually there is a slight difference, a missing pullup resistor on the Icarus CSO_B pin, which might possibly affect it.
Did you try power cycling it after programming? The fact that the ROM verified OK seems to suggest it ought to work even though it failed to initialize after programming.
April 08, 2014, 12:19:06 PM
@coutts
What difficulty did you use in your calculations? Right now blakecoin difficulty can have really big spikes, so you should try to average it to get the right results.
At the current price level imo its better to mine other coins and just buy BLC.
What difficulty did you use in your calculations? Right now blakecoin difficulty can have really big spikes, so you should try to average it to get the right results.
At the current price level imo its better to mine other coins and just buy BLC.
April 08, 2014, 12:05:53 PM
Still failing on 1 bit - see pastebin for output.
http://pastebin.com/rQB8PYWm
I'm going to try using your instructions to convert the 3 core .bit file to a .mcs and see if this works.
http://pastebin.com/rQB8PYWm
I'm going to try using your instructions to convert the 3 core .bit file to a .mcs and see if this works.
April 08, 2014, 11:44:28 AM
I can't find a mining calculator, so here's a fun experiment. I am mining BLC with a small R9 270 rig (4 cards), ~6.6 GH/s. For the past 6 days I had consistent mining (no disconnects / extended periods of not mining). I've graphed my results here:
http://i.imgur.com/Uj9ggQD.png
Note: i just realized that's not an accurate BLC/day figure in the graph itself, I set the pool to pay out 50 BLC at a time and theres about 4 payouts per day so each mini bar is just a payout from the pool. I should update the label to not say blc/day (too lazy now that it's made).
Anyways, according to the Bitcoin mining calculator with current BLC figures, I'm supposed to mine 283.3909 BLC/day. If you factor in that BLC is 30% more efficient than bitcoin: 283.4 - (283.4 * 0.30) = 198.38 -- very close to my observed ~200 BLC/day.
Is there a mining calculator out there I just don't know about?
Also, is there any p2pool setup yet? The network seems very centralized on blakecoin.org servers at the moment.
EDIT
Okay, fixed the graph:
http://i.imgur.com/luJH8nh.png
http://i.imgur.com/Uj9ggQD.png
Note: i just realized that's not an accurate BLC/day figure in the graph itself, I set the pool to pay out 50 BLC at a time and theres about 4 payouts per day so each mini bar is just a payout from the pool. I should update the label to not say blc/day (too lazy now that it's made).
Anyways, according to the Bitcoin mining calculator with current BLC figures, I'm supposed to mine 283.3909 BLC/day. If you factor in that BLC is 30% more efficient than bitcoin: 283.4 - (283.4 * 0.30) = 198.38 -- very close to my observed ~200 BLC/day.
Is there a mining calculator out there I just don't know about?
Also, is there any p2pool setup yet? The network seems very centralized on blakecoin.org servers at the moment.
EDIT
Okay, fixed the graph:
http://i.imgur.com/luJH8nh.png
Jump to: