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

[gymnastico]

nice, excellent hash, tks for your info

[1714901012]

1714901012

[1714901012]

1714901012

[BlueDragon747]

yes please, share your .config or .bat setting

Sure thing - I use this same config (but scrypt instead of blake256 algorithm, and "xintensity 4" with kalroth's miner) to mine scrypt at 500 KH/s stable, very good config. I am not undervolted, so I suspect that is what allows me to push the clock over 1150 and still be stable (this is how I achieve the high hash rates).

"intensity" : "14",
"worksize" : "256",
"lookup-gap" : "2",
"gpu-threads" : "2",
"thread-concurrency" : "8193",
"gpu-engine" : "1165-1165",
"gpu-fan" : "0-100",
"gpu-memclock" : "1498",
"temp-cutoff" : "94",
"temp-overheat" : "88",
"temp-target" : "74",
"temp-hysteresis" : "3",
"api-mcast-port" : "4028",
"expiry" : "1",
"log" : "5",
"no-pool-disable" : true,
"queue" : "0",
"scan-time" : "1",
"blake256" : true,
"kernel-path" : "/usr/local/bin",
"api-allow" : "W:127.0.0.1"

settings look good couple of things to point out

"lookup-gap" : "2",
not used by blake-256 kernel

"thread-concurrency" : "8193",
not used by blake-256 kernel

"gpu-memclock" : "1498",
blake does not use much ram so get the ram clocks lower(300-600) for better power usage and maybe a higher core clock

"worksize" : "256",
with newer ati drivers and latest 7 series or better (R9,R8,R7) cards try a odd worksize "255" reports of better share rate on pools WU/m (does not work for older 5/6 series)

"scan-time" : "1",
could reduce this and get less polling "30" for pools works well for me

also note:

"vectors" : "1",
this is always 1 its due to the way kr105 has modded cgminer so just creates display bugs if you use anything but 1

[coutts]

yes please, share your .config or .bat setting

Sure thing - I use this same config (but scrypt instead of blake256 algorithm, and "xintensity 4" with kalroth's miner) to mine scrypt at 500 KH/s stable, very good config. I am not undervolted, so I suspect that is what allows me to push the clock over 1150 and still be stable (this is how I achieve the high hash rates).

"intensity" : "14",
"worksize" : "256",
"lookup-gap" : "2",
"gpu-threads" : "2",
"thread-concurrency" : "8193",
"gpu-engine" : "1165-1165",
"gpu-fan" : "0-100",
"gpu-memclock" : "1498",
"temp-cutoff" : "94",
"temp-overheat" : "88",
"temp-target" : "74",
"temp-hysteresis" : "3",
"api-mcast-port" : "4028",
"expiry" : "1",
"log" : "5",
"no-pool-disable" : true,
"queue" : "0",
"scan-time" : "1",
"blake256" : true,
"kernel-path" : "/usr/local/bin",
"api-allow" : "W:127.0.0.1"

settings look good couple of things to point out

"lookup-gap" : "2",
not used by blake-256 kernel

"thread-concurrency" : "8193",
not used by blake-256 kernel

"gpu-memclock" : "1498",
blake does not use much ram so get the ram clocks lower(300-600) for better power usage and maybe a higher core clock

"worksize" : "256",
with newer ati drivers and latest 7 series or better (R9,R8,R7) cards try a odd worksize 255 reports of better share rate on pools WU/m (does not work for older 5/6 series)

"scan-time" : "1",
could reduce this and get less polling 30 for pools works well for me

also note:

"vectors" : "1",
this is always 1 its due to the way kr105 has modded cgminer so just creates display bugs if you use anything but 1

Thank you for the input, I'll play with memclock and see if I can raise the core clock more.


By the way, I'm trying to get a discussion going on reddit, I think BLC needs a subreddit and some marketing initiative to get the ball rolling on people adopting / learning about it.
http://www.reddit.com/r/CryptoCurrency/comments/202169/discuss_blakecoin_blc_and_the_blake256_algorithm/

[BlueDragon747]

I am bit busy trying to get this merge mining working atm

I know quite a few people use reddit I have just not had time to look at it yet any help with raising awareness for Blakecoin is always welcome  

[Vorfeed]

yes please, share your .config or .bat setting

Sure thing - I use this same config (but scrypt instead of blake256 algorithm, and "xintensity 4" with kalroth's miner) to mine scrypt at 500 KH/s stable, very good config. I am not undervolted, so I suspect that is what allows me to push the clock over 1150 and still be stable (this is how I achieve the high hash rates).

"intensity" : "14",
"worksize" : "256",
"lookup-gap" : "2",
"gpu-threads" : "2",
"thread-concurrency" : "8193",
"gpu-engine" : "1165-1165",
"gpu-fan" : "0-100",
"gpu-memclock" : "1498",
"temp-cutoff" : "94",
"temp-overheat" : "88",
"temp-target" : "74",
"temp-hysteresis" : "3",
"api-mcast-port" : "4028",
"expiry" : "1",
"log" : "5",
"no-pool-disable" : true,
"queue" : "0",
"scan-time" : "1",
"blake256" : true,
"kernel-path" : "/usr/local/bin",
"api-allow" : "W:127.0.0.1"

If you are using 7970/280x cards you can go up to 1190 without much problems

[Lyddite]

I am bit busy trying to get this merge mining working atm

Would be nice to know more about this. I am not aware of any other coins using BLAKE-256. Is there something in the works you could tell us about?

The best block I have found so far came yesterday! :-) Keep mining.

Code:

Best share: 2.09M

-Lyddite

[D05GTO]

Anyone looking for efficient mining with the Summer coming; this is the Ticket.  Scrypt and scrypt-n clones will be killing GPU's left and right this summer.

[karky]

Not all 280x can go up to 1190. i worked with 4 of them, and 1 of them only does 1130. The other 3 is strong (1225,1180,1206).

[bzyzny]

Would be nice to know more about this. I am not aware of any other coins using BLAKE-256. Is there something in the works you could tell us about?

Photon is a blake256 coin and will probably be the first to support merged mining. I believe united federation coin is blake256 but the dev made changes that will make it unlikely to support merged mining. Bryce Weiner is also working on some blake256 coins that will be merged mineable

[rupy]

So what does merged mining mean? You get double the coins for your hashing? Will the blakecoin pools automatically switch to this, or do we need to do something?

[teknohog]

It must be common knowledge that the Ztex FPGA frequency adjustment is not perfect, but here's another anecdote. I recently got an original 1.15y board where two of the chips are impossible to run without forced clock limits. Basically, they start giving lots of HW errors at 188 or 192 MHz, and they end up SICK. After setting an upper limit of 184, they run fine, with zero HW errors. It's as if the HW vs. frequency is an extremely steep function for these chips.

The board runs SHA-2 code fine at nearly 220 MHz, though the two chips are the slowest of the bunch. I also have other 1.15y/x boards where Blake runs fine with the default adjustment on cgminer 3.1.1

To answer a question in the README,

I don't know if this will work for multiple boards

I got the freq limits working for two boards using

Code:

--ztex-clock 180:184,180:248,180:248,180:184,200:248,200:248,200:248,200:248

All in all, this is not a bug report or anything, but an interesting finding. I've tried both of the currently available bitstreams with similar results.

[kramble]

To answer a question in the README,

I don't know if this will work for multiple boards

I got the freq limits working for two boards using

Code:

--ztex-clock 180:184,180:248,180:248,180:184,200:248,200:248,200:248,200:248

All in all, this is not a bug report or anything, but an interesting finding. I've tried both of the currently available bitstreams with similar results.

Thanks. The --ztex-clock code is implemented in exactly the same way as the icarus options, so that makes sense. What I don't know is if the boards will always be detected in the same order, though I guess plugging them in one at a time should ensure this.

I think the ztex boards have a firmware ID string which could be used to identify them (I vaguely remember seeing some reference in the java SDK), if anyone wants to have a look at writing a better cgminer driver (unlikely I know )

[BlueDragon747]

So what does merged mining mean? You get double the coins for your hashing? Will the blakecoin pools automatically switch to this, or do we need to do something?

the miner will not need to make changes apart from having a wallet for each merged coin and you will only get paid for your shares on each block find this could be all coins merged or just one, all pools should get replaced once I have the code working and the shares/payouts/block find 100%

[bzyzny]

If you check out one of the mining pools that supports btc/nmc/etc merged mining you can get an idea of what it means. The hashes generated from cgminer can be used for both or several different blockchains since the mining protocols are compatible. The code for implementing merged mining is on the pool end, since the pool is what generates work input for your miners. The blockchains are still separate from each other in every way, except that their network hashing power is combined. That is why it will provide vastly superior security; imagine if all the miners for all the scrypt clones where sharing resources to secure all the blockchains simultaneously. It is perhaps uncertain how this will affect the prices of each individual coin involved. However, the combined hashing power will increase the difficulty, and thus decrease the payout of mined coins. On the other hand you will get multiple types of coins from mining so it should balance out. Also, the values of each separate type of coin would be independent, based on its own characteristics such as # of coins in circulation, reward structure, utility and popularity. Another great advantage is that since the Blake256 merged mining pools will each support several blockchains, it should provide a larger number of pools splitting the load for each blockchain, which reduces risk of 51% attack or other abuses.

[cinnamon_carter]

Photon

https://bitcointalk.org/index.php?topic=478136.0;all


https://cryptocointalk.com/forum/944-photon-pho/

I am bit busy trying to get this merge mining working atm

Would be nice to know more about this. I am not aware of any other coins using BLAKE-256. Is there something in the works you could tell us about?

The best block I have found so far came yesterday! :-) Keep mining.

Code:

Best share: 2.09M

-Lyddite

[Lyddite]

I'll put together the Altera version later (I did my original code on a DE0-Nano as Quartus is much nicer than the Xilinx toolchain).

Hi,

I have a couple DE0-Nano boards that aren't doing anything at the moment. Would you upload the code to github?

-Lyddite

[kramble]

I have a couple DE0-Nano boards that aren't doing anything at the moment. Would you upload the code to github?

OK, will do. I only used the DE0-Nano for my early tests, so the performance is not great. Also it uses the Altera TCL mining scripts (derived from the Open Source Bitcoin Miner), so it will only work solo or with a getwork pool, not Stratum.

I'll just need to tidy it up a little and check its still working, so give me a few hours and it will go up.

[Lyddite]

I have a couple DE0-Nano boards that aren't doing anything at the moment. Would you upload the code to github?

OK, will do. I only used the DE0-Nano for my early tests, so the performance is not great. Also it uses the Altera TCL mining scripts (derived from the Open Source Bitcoin Miner), so it will only work solo or with a getwork pool, not Stratum.

I'll just need to tidy it up a little and check its still working, so give me a few hours and it will go up.

Cool! I used the FPGA bitcoin miner last year!

-Lyddite

[kramble]

I think you're going to be rather disappointed with the performance.

I've just run a test and it's only reporting 2MHash/sec (though that may just be due to mis-calibration), but it took 5 minutes to find a share and the pool rejected it !!

I'm only clocking at 50MHz though, so it should go a bit faster, but the DE0-Nano voltage regulators are running quite warm even at this clock speed, so it will need some additional fan cooling. I'm a bit reluctant to put up a faster-clocked bitstream, though of course if you compile your own, you can clock it as fast as you dare.

HMM, got a second share rejected by the pool, so something is a bit off. I've not used the getwork pool (eu1.blakecoin.com:8337) before, so I'm may be doing something wrong.

PS This is weird (and a heads-up for BlueDragon). The pool seems to be sending an extra byte in the getwork data (129 bytes rather than 128), and expects the same in return. The python miner seems to cope with this, but the TCL one does not (they manipulate the hex strings slightly differently). I've hacked the TCL miner to fix it (I think, as my TCL coding skillz are even worse than my python). Except it's still not working and waiting up to half ah hour for a share makes debugging it rather slow. It looks like it won't go up today after all as I'm running out of time here.

[kramble]

I'm right out of time, but I've pushed the source up to github anyway
https://github.com/kramble/FPGA-Blakecoin-Miner/tree/master/experimental/DE0-Nano

Its possible that the problem is not with the TCL mining script but with the actual implementation of the algorithm (this was a very early version of the code). I'll get it debugged properly next week.

And as a little present to the BlakeCoin community (it's a crude hack, see the README).
https://github.com/kramble/FPGA-Blakecoin-Miner/tree/master/vanitygen