Topic: [ANN][BLC] Blakecoin Blake-256 for GPU/FPGA With Merged Mined Pools Stable Net - page 114. (Read 409571 times)

i noticed theres a large concentration of miners on eu1 pool. it would be good if people could spread out some, eu2 sg1 and the ocminer pool are all pretty much empty.

i get stuck at step 4, it does not show the 2 fpgas after i run initialize chain, instead it gives this error:

ERROR:iMPACT - A problem may  exist in the hardware configuration. Check that the cable, scan chain, and power connections are intact, that the specified scan chain configuration matches the actual hardware, and that the power supply is adequate and delivering the correct voltage.

the led on the xilinx programmer turns green when i power up the fpga. impact appears to recognize the device is there, based on the log output, but im at a loss as to what is preventing the jtag chain from initializing. I even tried doing it on a different computer (with windows 7 32bit) and a different version of ise (14.2).  any steps i can take to narrow down the problem? thanks

14.7 works fine here, what cable you using and have you double checked the pinouts for jtag cable?

for Lancelot I do this

1. connect power to board (leave off)
2. plug jtag cable in (Xilinx usb jtag make sure its connected and installed status light should be red)
3. power on board (status light will turn green from red)
4. start impact and select create new then set configure device using boundary-scan (jtag) - Automatically connect (default)
5. should get a chain of 2 chips click the chip and assign the bitstream (mcs is not really needed at this stage only for long term e.g if asked to assign mcs for flash select no)
6. program both chips with the .bit should be quick
7. disconnect jtag cable (dont power off board!)
8. connect usb cable to the board and fire up cgminer (check device manager for port number)

example
cgminer-lancelot-52 --disable-gpu --icarus-timing 1.0=20 -S \\.\COM7 --url stratum+tcp://ny1.blakecoin.com:3334 --userpass User.worker:password  --cainsmore-clock 160 -Q 4

if all is ok it should be working and getting accepted shares

trying to get blakecoin .bit/.mcs on icarus fpga. ise impact isnt succeeding at initializing jtag chain. i think ive narrowed the problem down to either
1) Com port issue, either driver or mobo configuration
2) impact version, 14.7 doesnt seem to support the correct spartan6, do i need to use older version like 13.2? does 32bit/64bit make a difference?
3) perhaps icarus needs to be reset first, is it possible the previous bitcoin code is running and preventing jtag communication?

thanks for any help

cool 

no problemo im in #cryptopools on freenode irc if u need any help fast (theres a few other pool ops in there too).

Awesome this might help thanks 

any other help, tips, tricks most welcome

will add that auth module to eloipool 

Pool for Blakecoin still open for miners:

https://blake.suprnova.cc

It runs the latest MPOS with all its features including Idle Worker Notifs, two factor Auth etc.
I've got Stratum with Vardiff running on it, I've already found several Blocks while testing so everything should be fine, I just need some testing with higher loads.

You can use kr's latest cgminer and, of source, the FPGA miners too.

no other pool operators have offered to help with this so its up to me atm  

I think a plugin system is off due to time constraints and some of the merge is hard coded as it is for most merge mine pools, its still going to be tricky for other pool operators to setup, this I am quite sure as it has been that way for me so far  

no issues with max size of block but there is a limit to the size of the work header with this method of merging I would guess it might have issues >6 Aux coins without changing some stuff in miner/eloipool, there is another way to merge mine by just using the nonce and submitting it to the wallet to solve this is far more flexible for large merge but slightly more random/out of order finds and is a little more difficult to work out shares and payouts it is also heavy load for the wallets, atm the issue is mostly with the front end of the pool so not going to play with this until its needed e.g 6+ aux coins merged, MPOS is a PITA to mod and I may look into doing something more basic if I keep getting issues (which I do even on normal BLC pools)  


I have not finished the merge mining yet and still quite a few bugs to solve, I am testing some new code this weekend hope it works ok  

Effect of the Real World:
My time is split between working on any contract work (IT Consulting/Management) and the projects I am working on BLC/Games etc. the rest of the time is just spent eating, sleeping and other every day stuff, I don't have any big investors helping with any costs so all my projects are self funded atm

BlueDragon747, thanks for the status update, its reassuring to hear progress is being made behind the scenes. Nice trick there squeezing more megahashes out of the fpgas.

I was curious how you are implementing multiple coins in MPOS. Will it be a plugin system so pool operators can choose which blockchains to mine, and can miners choose which they participate in? I would imagine there might be a limit to how many blockchains can be concurrently merge mined, either from a limitation of MPOS, eliopool, or some technical parameter. If each aux chain has to insert a code into the Blakecoin blockchain, how many would it take to exceed the max file size of a block? Not sure if im asking the right questions but u get the idea

should be fine you are most welcome to add the link to your github  

Yeah using the Xilinx toolchain does take some of the fun out of it, I still put a build on once a week with slight tweaks and different seed values but its mostly disappointing or never finishes    

my boards here
Lancelot 1:  --cainsmore-clock 165 -Q 4 = ~14 WU
Lancelot 2:  --cainsmore-clock 160 -Q 4 = ~13 WU

Nice one. Getting 160MHz here with WU of around 12 to 13 so it's a definite improvement.

I'll pop the bitstream up on the github (I assume the link to blakecoin.org will be OK, else I can put up a copy on my dropbox account).

Yeah on the Xilinx toolchain. It's really frustrating when you just can't get it to route at all, so I basically gave up on it  

Still working on it been delayed a bit due to merge mining work

I had some meetings this week about FPS game release and progress is still on track should have some videos of the game play soon  

the RPG has at least a 6-8 week lag on the FPS atm so no eta

Merge Mining news:

some wallet code has been changed for the merge mining, testing this weekend hope to have a new update to the wallet by next weekend, MPOS for multicoin is still broken and the payout for aux coin is non functional atm still work in progress  

Other news:

got a better fmax on the 3 core Lancelot fpga build I had on the side still lower fmax than the 2 core but overall higher throughput ~960MH/s-1GH/s at 160MHz-165MHz which is about max blakecoin.org/blakeminer_FourGatexClk_3core_fmax-102.bit

no luck on getting Xilinx ISE 14.7 to build a 3 core version for the Ztex 1.15y or the CM1  

still waiting MMOFPS / MMORPG

You didn't say how fast you are clocking the devices  

However the theoretical hash rate is easy to work out. The lancelot has two FPGAs and the blake bitstream for the LX150 (all variants so this applies to CM1 and Ztex too), has two cores each of which produces one hash per clock cycle.

So at, for example, at 200MHz clock you should expect 2 * 2 * 200 = 800MHash/sec
I found the HW error rate a little too high at 200MHz, so I clock mine at 195MHz giving 780MHash/sec theoretical.

The lancelot uses a serial communication protocol which only reports found shares ("golden nonces"), so there is no way that the mining driver (cgminer or the python miner) can know the real hash rate, it can only average the share rate and back-calculate to the hash rate (this is pretty much what the pool will be doing too).

In fact it's worse than this, as cgminer calculates the hash rate from the icarus_timing parameter supplied on the command line, which bears no relationship to the actual clock speed. I recommend using --icarus_timing 1.0=20 which performs a getwork every 2 seconds as the default is too slow for blake and will cause duplication of work. The 1.0 figure is the one used by cgminer for the hash time (in nS) and 1.0 should report as 1000MH/s (which is not dissimilar to your 993MH/s).  The reported average hash rate should be more accurate, but it's not my code so I can't vouch for it.

As to the worker utilization, AFAIR this is shares submitted per second, so should be 2^32 / HashRate which I make to be 5.5 for 780MH/s which doesn't look much your 10.8. EDIT Sorry, that's nonsense, not enough coffee this morning. WU is shares/minute and the expected value is 60 * Hashrate / 2^32 which comes to 10.9 which is pretty much spot on, so I don't need to do this any more:

I suppose I ought to have a play with it myself to see what it's up to. I'll take a look later and run it interactively (I currently run cgminer in background, and while it does log, I don't get the final summary stats as cgminer gets sent a kill message on reboot, which happens a couple of times a day due to a bug in the raspi network stack).


Does anyone run this on a real Icarus? It would be useful to hear any reports.

AFAIK the Lancelot has a higher power PSU than the Icarus which allowed higher hashrates on bitcoin, but this should not affect blake as it's less power hungry (unless someone comes up with a better bitstream, there is scope for some improvement with expert attention, possibly even a third core).

Anyway, this was meant to be a quick reply and I've just rambled on, sorry. The bottom line is that 780MHash/sec as reported by the pool is perfectly acceptable for a Lancelot clocked at 195MHz.

1942/6= ~323 -> 160-164MHz per chip, which is very low.  I've played 4MHz to 8MHz more on spartan grade 2 clones with older v3 bitstream. With latest bitstream I am able to hit 200MHz without HW on grade 3 chip, with slightly R12/R13 mod.

You can also try manual frequency clocking for each ztex separately to find good settings.

BTW, there were two revisions of original 1.15x with different R12 value, so core voltage differs +/-0.02V.

Hi,

Got a lancelot running at 993Mh/s which seems fast, however comparing it to a GPU running at 2Gh/s, the lancelot shows WU of 10.8 compared to the GPU's 27.7

Comparing these gives an "effective" hashrate of around 780Mh/s for the Lancelot which seems about right. Is there any obvious explanation for the higher hashrate number? I have no experience of FPGA bitcoin mining so I may be missing something simple.

Also are there any significant differences between Lancelot and Icarus boards when mining blakecoin?

Thanks.

Turned off E-Mail, should be working now