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

[BlueDragon747]

this is due to not enough cpu for wallet and mining on the same machine and it results in losing connections, this happens more with cgminer than reaper or kramble's python miner

my advice is to just mine on the weak cpu machine and host the wallet on another machine and just mine to it over your local network and blakecoind is better for using less resources than blakecoin-qt so you could just try using blakecoind and see if that get same results if it is not possible to host the wallet on another machine

i do not cpu mine, only qt and cgminer on a fpga is running, the cpu (Celeron dualcore 1.2GHz) is idle at 5-7%

any cgminer e.g fpga or opencl seems to stress the wallet if it is running on same machine

have you tried to use blakecoind and does that get same result?

Sorry i am a n00b by mining without Pool, Who do i setup this?
i have a server there i can install the QT client in a VM maschine.. maybe this works better....  :/
config -> listening on= 0.0.0.0 or 255.255.255.255 ?

EDIT: right now the diff goes over 2K  

do you have the wallet on more than 1 machine?

if you have a stable wallet on other machine then just edit blakecoin.conf and add something like this: rpcallowip=192.168.0.*  (this allows connections from your lan) replace ip with your lan ip range, you can also just add a single ip like this: rpcallowip=192.168.0.3

then you mining rig does not need to run the wallet  

just change the mining command line to point to the ip of the machine with the wallet running e.g cgminer --disable-gpu --url 192.168.0.4:8772 --userpass yourusername:yourpassword

or try using the blakecoind via the command line

here is the list of commands that work with Blakecoin and Bitcoin via the command line
https://en.bitcoin.it/wiki/Original_Bitcoin_client/API_calls_list

on windows in a command window with the directory of the wallet: c:\blakecoin>   I can run: blakecoind getinfo
on linux in a bash window with the directory of the wallet: /media/blakecoin> I can run: sudo ./blakecoind getinfo

both blakecoin-qt and blakecoind use same blakecoin.conf and data but you can only run one at a time

like I said the QT client is slower than blakecoind and all the server nodes just use blakecoind on ubuntu 12.04 x64 and they run for weeks without restart  

edit:
also if you wanted to allow more than 10 connections add this to your blakecoin.conf: maxconnections=50

edit2:
example conf for lan mining

listen=1
maxconnections=50
gen=0
rpcallowip=127.0.0.1
rpcallowip=192.168.0.*
rpcuser=yourusername
rpcpassword=yourpassword
rpcport=8772
server=1
daemon=1
addnode=162.243.133.80
addnode=162.243.14.130
addnode=146.185.135.24
addnode=184.171.247.23

[1714042607]

1714042607

[1714042607]

1714042607

[1714042607]

1714042607

[1714042607]

1714042607

[kramble]

I have updated the blake fpga cgminer https://github.com/kramble/FPGA-Blakecoin-Miner/tree/master/cgminer/cgminer-3.1.1

This removes some of the debug output which has caused such confusion (overflow and checknonce messages) and added a new command line option to set the ZTEX clock speed manually. Its probably best to let it run in automatic (default) mode at first to get a feel for which settings may be required should you decide to use it.

The new windows binary is at https://www.dropbox.com/s/6ydm22w7rclzhj2/cgminer.exe (to upgrade just copy it over the old version in cgminer-3.1.1-blakefpga).

When running on linux you will probably need to run as sudo, and don't forget to update bitstreams/ztex_ufm1_15y1.bit with the blake version from https://www.dropbox.com/s/vk3k5sb64b8641o/ztex_ufm1_15y1-v06ad-2core-ucf-140MHz-fmax-147-fixed.bit or you'll only get a bunch of HW errors instead of shares (yep, I made that mistake too   )

The updated README is as follows ...

Blakeminer patches for https://github.com/ckolivas/cgminer version 3.1.1

I don't think its appropriate to fork the repository in this case so I will
just supply patches to specific release versions.

Compilation
Open the official repository (link above) in your browser, click the "branches"
dropdown menu in the middle left of the page, select the "tags" tab and scroll down
to the version required (3.1.1) and select it. Download the zip (right side of page)
and unzip the archive.

Copy my patch files (from this github folder) into the official cgminer 3.1.1 folder,
replacing existing files as necessary. Build as normal, see the README or windows-build.txt

Prebuit windows binary at https://www.dropbox.com/s/6ydm22w7rclzhj2/cgminer.exe
Dependancies (DLL) at https://www.dropbox.com/s/xa01f9hhakpsexv/cgminer-3.1.1-blakefpga.zip

To use the windows version, unzip the dependancies then move cgminer.exe into the folder.
Copy the bitstream folder from the official cgminer-3.1.1 distribution.
Replace ztex_ufm1_15y1.bit with the BlakeCoin bitstream.
Edit the RUNBLAKE.BAT script and set the username/password to be the same as the rpcuser
and rpcpassword set in your blakecoin.conf. Change localhost if running blakecoind on a
separate machine. You will need to install the WinUSB driver using zadig which is available
at http://sourceforge.net/projects/libwdi/files/zadig/

For linux users, run as follows (this is the same as RUNBLAKE.BAT)
sudo ./cgminer --disable-gpu --url localhost:8772 --userpass username:password 2>log.txt
You can probably change the UDEV rules to avoid the need for sudo.

Notes:
Should you have problems, redirect the stderr output to log.txt (this is done
automatically in RUNBLAKE.BAT) and examine this for messages.
Do not use this for GPU mining as it will not work.
Do not enable the --debug switch as it crashes, --verbose works OK though.
Cainsmore CM1 will be detected as icarus, you may need the -T switch if it crashes.
Use the -S option eg.  -S \\.\COM20 -S \\.\COM21 -S \\.\COM22 -S \\.\COM23
It will not work for my current lancelot bitstream, use the python miner instead.
Only the ztex 1.15y board is supported. Frequency management is automatic using the
same algorithm as bitcoin. It can be overriden by the --ztex-clock option as follows
--ztex-clock 180:200   sets initial clock of 180MHz, max of 200Mhz
--ztex-clock 204:204   fixed clock speed of 204MHz
--ztex-clock 180:192,184:196,180:204,192:212   set individual fpga device speeds
I don't know if this will work for multiple boards, but its done the same way as
the icarus options so with luck it will be OK.
The clock resolution is 4MHz (rounds down) and the valid range is 100MHz to 250MHz.
If --ztex-clock is not used the default range is 172MHz to 220MHz.

[trepex]

The clock resolution is 4MHz (rounds down) and the valid range is 100MHz to 250MHz.

No! without knowing anything about MHz, Ztex Boards, Mining... that's pure math!  

[kramble]

The clock resolution is 4MHz (rounds down) and the valid range is 100MHz to 250MHz.

No! without knowing anything about MHz, Ztex Boards, Mining... that's pure math!  

Yup, you caught me out good and proper. Though it still is the valid range for input; the 250 just gets rounded down to 248MHz when setting the clock speed (notwithstanding a -1 that also gets applied, so the speeds may actually be off by 4MHz across the board, but that's by the by).

Have you tried it out? Do you like it?  

[mogrith]

Well now that I've been mineing for several days. It's settled down to ~350MH/s per core on the CM 1. I' 'm pretty happy with that.:-D

[kramble]

Well now that I've been mineing for several days. It's settled down to ~350MH/s per core on the CM 1. I' 'm pretty happy with that.:-D

I'll try to slot some CM1's into the build queue so as to get you a slightly faster hash rate. I've been concentrating on the ztex recently as there has been rather more interest (squeaky wheel gets the grease).

To whit: https://www.dropbox.com/s/1ffqdaj1dowkd0j/ztex_ufm1_15y1-v06ad-t6-ucf-150MHz-fmax-157.bit is marginally faster by about 4MHz to 8MHz (not the 10MHz or more suggested by the fmax increase).

Its going to get progressively more difficult to improve on this, unless I can get that third core to route which has been a dismal failure to date, so I think I'm going to take a timeout and do a litecoin build for the ztex as interest is hotting up over at the litecoin forum in the commercial offerings, and I'd like to get my ztex alternative out there (only perhaps 66kHash/s or thereabouts, so not great, though I can't be sure until I've built it).

[knorrly]

I have been working on a block chain explorer. It is a fork of Bitcoin Abe. Only minor adaptations were required for Blakecoin.

The source is available here: https://github.com/knorrly/blakecoin-abe

I am running a demo site: http://blakexplorer.dyndns.org:2750/chain/Blakecoin

The demo site will only be temporary and is not able to handle a big workload. Would someone be willing to host it officially? blakecoin.org would be a good candidate .

[BlueDragon747]

I have been working on a block chain explorer. It is a fork of Bitcoin Abe. Only minor adaptations were required for Blakecoin.

The source is available here: https://github.com/knorrly/blakecoin-abe

I am running a demo site: http://blakexplorer.dyndns.org:2750/chain/Blakecoin

The demo site will only be temporary and is not able to handle a big workload. Would someone be willing to host it officially? blakecoin.org would be a good candidate .

I will put it up on a server no problem thanks for working on it

[jlsminingcorp]

Hi All, has anybody had any luck compiling the cgminer for Blakecoin in linux from the source linked in the OP? I'm getting the following error:

Edit: Just to clarify, I'm talking about the gpu-mining version of cgminer, not kramble's FPGA version (which works fine).

Code:

cgminer-cgminer.o: In function `rebuild_hash':
/home/hdt/Downloads/cgminer-blake256-src/cgminer.c:3391: undefined reference to `blake256_regenhash'
collect2: ld returned 1 exit status
make[2]: *** [cgminer] Error 1
make[2]: Leaving directory `/home/hdt/Downloads/cgminer-blake256-src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/hdt/Downloads/cgminer-blake256-src'
make: *** [all] Error 2

I'm running ubuntu 12.04 LTS 64 bit and have all of the dependencies to compile the regular cgminer. With the Blakecoin version I had to copy the contents of compat/jansson/.deps/ from a "normal" version of cgminer to the Blakecoin version to get rid of the windows-specific file locations in these files (I'm afraid that I was too lazy to edit all of them by hand). Is this the likely source of the problem? I realise that I'm probably missing something completely obvious, but would certainly appreciate a hand.

[knorrly]

I have been working on a block chain explorer. It is a fork of Bitcoin Abe. Only minor adaptations were required for Blakecoin.

The source is available here: https://github.com/knorrly/blakecoin-abe

I am running a demo site: http://blakexplorer.dyndns.org:2750/chain/Blakecoin

The demo site will only be temporary and is not able to handle a big workload. Would someone be willing to host it officially? blakecoin.org would be a good candidate .

I will put it up on a server no problem thanks for working on it

Great, thanks! Let me know if I can support you with the setup.

[jlsminingcorp]

I have updated the blake fpga cgminer https://github.com/kramble/FPGA-Blakecoin-Miner/tree/master/cgminer/cgminer-3.1.1

This removes some of the debug output which has caused such confusion (overflow and checknonce messages) and added a new command line option to set the ZTEX clock speed manually. Its probably best to let it run in automatic (default) mode at first to get a feel for which settings may be required should you decide to use it.

The new windows binary is at https://www.dropbox.com/s/6ydm22w7rclzhj2/cgminer.exe (to upgrade just copy it over the old version in cgminer-3.1.1-blakefpga).

When running on linux you will probably need to run as sudo, and don't forget to update bitstreams/ztex_ufm1_15y1.bit with the blake version from https://www.dropbox.com/s/vk3k5sb64b8641o/ztex_ufm1_15y1-v06ad-2core-ucf-140MHz-fmax-147-fixed.bit or you'll only get a bunch of HW errors instead of shares (yep, I made that mistake too   )

The updated README is as follows ...

Kramble, you're a hero for getting this working. One overvolted Ztex 1.15y hashing away happily at 204 MHz now (could probably push it further) - no sign of magic smoke yet . Do you have a blakecoin tipjar?

What kind of hardware error rate do you feel would be reasonable for this coin? I've got around 300 HW errors on most of the chips so far (although one has substantially fewer than the others for some reason) after 9 hours of mining. The HW errors seem to come in groups rather than in a regular pattern. None of the heatsinks feel particularly hot (they actually seem to be a little cooler than when bitcoin mining).

[boymok]

Any progress on pool?

[kramble]

Kramble, you're a hero for getting this working. One overvolted Ztex 1.15y hashing away happily at 204 MHz now (could probably push it further) - no sign of magic smoke yet . Do you have a blakecoin tipjar?

What kind of hardware error rate do you feel would be reasonable for this coin? I've got around 300 HW errors on most of the chips so far (although one has substantially fewer than the others for some reason) after 9 hours of mining. The HW errors seem to come in groups rather than in a regular pattern. None of the heatsinks feel particularly hot (they actually seem to be a little cooler than when bitcoin mining).

Thanks for the compliment. Tips gratefully accepted at BYEE2FvGv4L3yt5aEr8BQ73oWzXMu59Fwz (no need for an upfront tip, just mine blakecoin and decide what you'd like to contribute from proceeds).

The HW errors reported per-device for the Ztex are perhaps a little misleading as these are calculated as the devices are polled four times per second. So an error rate of just 1% (one in a 100) will give 4 * 3600 / 100 = 144 HW errors per hour! So I wouldn't worry too much about these, the automatic frequency management is likely to dial back the frequency to reduce the rate anyway (this may be what you're seeing with the grouping as the frequency steps up and down). I may just add a feature to completely disable this if its annoying, but it does seem to be working reasonably well and gives some protection against overheating (as evidenced by comments in the original code). Not that overheating should be an issue as the FPGA is only about 50% utilized (compare 80% for the bitcoin code), so it does run cooler. Now if I could only get that third core to route we'd really be cooking

Well now that I've been mineing for several days. It's settled down to ~350MH/s per core on the CM 1. I' 'm pretty happy with that.:-D

I'll try to slot some CM1's into the build queue so as to get you a slightly faster hash rate. I've been concentrating on the ztex recently as there has been rather more interest (squeaky wheel gets the grease).

I've been running builds all weekend, but haven't come up with anything faster yet. I have added a --cainsmore-clock command line parameter to cgminer to allow you to set the clock speed. Mine seems OK up to around 200MHz but you need to be very careful of HW errors as (unlike the ztex above) these are counted per share, so you want to keep these very low (a few are unavoidable due to timing issues as new work is sent). Just note the frequency where the errors start to climb rapidly, and dial it back slightly, you may want to set this on a per-device basis. See https://github.com/kramble/FPGA-Blakecoin-Miner/blob/master/cgminer/cgminer-3.1.1/README.txt for notes and a link to the new windows binary.

PS It you do set the clock speed too high, you may find the devices are not detected the next time you run cgminer. Don't panic! Just run it again with a lower clock speed, perhaps twice, and the devices should be detected OK. If you have not yet already done so, you may want to flash the bitstream into ROM so it survives a power cycle as this is the ultimate reset.

[mogrith]

I've been running builds all weekend, but haven't come up with anything faster yet. I have added a --cainsmore-clock command line parameter to cgminer to allow you to set the clock speed. Mine seems OK up to around 200MHz but you need to be very careful of HW errors as (unlike the ztex above) these are counted per share, so you want to keep these very low (a few are unavoidable due to timing issues as new work is sent). Just note the frequency where the errors start to climb rapidly, and dial it back slightly, you may want to set this on a per-device basis. See https://github.com/kramble/FPGA-Blakecoin-Miner/blob/master/cgminer/cgminer-3.1.1/README.txt for notes and a link to the new windows binary.

PS It you do set the clock speed too high, you may find the devices are not detected the next time you run cgminer. Don't panic! Just run it again with a lower clock speed, perhaps twice, and the devices should be detected OK. If you have not yet already done so, you may want to flash the bitstream into ROM so it survives a power cycle as this is the ultimate reset.

I'll be looking at this.

I did send you some BLC for all the TLC you've given to FPGAs.

[kramble]

I did send you some BLC for all the TLC you've given to FPGAs.

Many thanks, that's very generous of you. I'm taking a timeout to port my Litecoin miner to the CM1 (I only expect around 60kHash/sec so don't get too excited), but I'll keep plugging away at the blake builds as its just a matter of tweaking the build parameters and firing it off, checking back a few hours later to see if it has any chance of completing, then typically aborting it any trying again as the full build can take 12 hours or more.

[bzyzny]

Good news everyone! (imagine Prof. Farnsworth voice )

I have managed to compile a version of cgminer for gpu mining blakecoin on Linux. So far I have only mined two blocks with it, blocks #29622 and #29634, they are still awaiting maturity. However they've already been confirmed several times so I am going to assume its valid. You can look at them here:
http://blakexplorer.dyndns.org:2750/b/CDFYi4Y7J
http://blakexplorer.dyndns.org:2750/b/C4EV2G1q4
Thanks for the block explorer

I have uploaded a binary and sources to mediafire. So far I have only compiled a 64bit version, but when I have time I will compile 32bit as well.

http://www.mediafire.com/download/ahaf69z3sdzeqou/blakecoin-cgminer-3.3.1-linux.tar.bz2

[ZeWaren]

Is there any exchange/places where I could buy some?

[wax7]

Is there any exchange/places where I could buy some?

i sell 250blc -4- 0,1btc

[faye]

hey Bluedragon,
where can I find the white paper of Blakecoin?  Thanks

[ArcticWolfie]

Hi I'm trying to get reaper working for solo mining
but somehow my stale is always 100%...

GPU 58.67MH/s, shares: 50|0|50, stale 100%, GPU errors: 0%, ~62481.3 kH/s, 3437s
GPU 58.68MH/s, shares: 50|0|50, stale 100%, GPU errors: 0%, ~62426.9 kH/s, 3440s
GPU 58.67MH/s, shares: 50|0|50, stale 100%, GPU errors: 0%, ~62408.7 kH/s, 3441s
GPU 58.67MH/s, shares: 50|0|50, stale 100%, GPU errors: 0%, ~62390.6 kH/s, 3442s
GPU 58.67MH/s, shares: 50|0|50, stale 100%, GPU errors: 0%, ~62372.5 kH/s, 3443s‏

my configs look like:
in appdata blakecoin.conf:

listen=1
gen=0
rpcuser=username
rpcpassword=password
rpcallowip=127.0.0.1
rpcport=8772
daemon=1
server=1

blakecoin.conf in reaper.exe directory

host 127.0.0.1
port 8772
user username
pass password

protocol blakecoin

worksize 64
aggression 18
threads_per_gpu 1
cpu_mining_threads 0
vectors 1

reaper conf:

kernel reaper.cl
save_binaries yes
enable_graceful_shutdown yes
long_polling no

mine blakecoin

device 0

Reaper can only use my Intel IGP (somehow it fails at my GTX765M...)
any ideas what I'm doing wrong? I tried reaper on Litecoin and it works fine...