Wallet stop on "blocks" : 12112
Restart does not help
ok it's works now
Topic: [ANN][BLC] Blakecoin Blake-256 for GPU/FPGA With Merged Mined Pools Stable Net - page 176. (Read 409641 times)
October 31, 2013, 01:02:59 AM
October 31, 2013, 12:45:23 AM
October 31, 2013, 12:42:40 AM
Google docs exchange: https://bitcointalk.org/index.php?topic=321823.new#new
Looking for trusted members to help sustain the exchange when I am asleep (in ~8 to 9 hours from now)
Looking for trusted members to help sustain the exchange when I am asleep (in ~8 to 9 hours from now)
October 31, 2013, 12:19:16 AM
Anyone getting consecutive orphans?
I haven't got a single orphan until about 12 hours ago. Now all newly mined blocks are orphans. I realize that the diff is high but this seems odd. The diff was much higher, near 10k, a while ago and I had no orphans. Strange.
I haven't got a single orphan until about 12 hours ago. Now all newly mined blocks are orphans. I realize that the diff is high but this seems odd. The diff was much higher, near 10k, a while ago and I had no orphans. Strange.
restart wallet, sometimes happens, i don't understand why
October 30, 2013, 11:55:15 PM
Anyone getting consecutive orphans?
I haven't got a single orphan until about 12 hours ago. Now all newly mined blocks are orphans. I realize that the diff is high but this seems odd. The diff was much higher, near 10k, a while ago and I had no orphans. Strange.
I haven't got a single orphan until about 12 hours ago. Now all newly mined blocks are orphans. I realize that the diff is high but this seems odd. The diff was much higher, near 10k, a while ago and I had no orphans. Strange.
yeah I got about 6 in past 12 hrs and was not getting them before, gone back to reaper to see it that helps as it does not seem to stress the wallet as much but it is strange
I think I'll do the same. Of course, it is Halloween. The Reaper should shred right through the BLC \\\ O~O ///
October 30, 2013, 11:42:49 PM
Anyone getting consecutive orphans?
I haven't got a single orphan until about 12 hours ago. Now all newly mined blocks are orphans. I realize that the diff is high but this seems odd. The diff was much higher, near 10k, a while ago and I had no orphans. Strange.
I haven't got a single orphan until about 12 hours ago. Now all newly mined blocks are orphans. I realize that the diff is high but this seems odd. The diff was much higher, near 10k, a while ago and I had no orphans. Strange.
yeah I got about 6 in past 12 hrs and was not getting them before, gone back to reaper to see it that helps as it does not seem to stress the wallet as much but it is strange
October 30, 2013, 11:37:53 PM
Anyone getting consecutive orphans?
I haven't got a single orphan until about 12 hours ago. Now all newly mined blocks are orphans. I realize that the diff is high but this seems odd. The diff was much higher, near 10k, a while ago and I had no orphans. Strange.
I haven't got a single orphan until about 12 hours ago. Now all newly mined blocks are orphans. I realize that the diff is high but this seems odd. The diff was much higher, near 10k, a while ago and I had no orphans. Strange.
October 30, 2013, 08:49:04 PM
Atavacron
Sorry, I managed to delete this previous post while quoting from it (probably pressed edit rather than quote), hope you read it first (I was just commenting that the hash rate is correct since we've got two cores per fpga).
I've been running a 100MHz build for about 3 hours now, still not fully routed (899 to go), so I'll leave it run overnight (UK time). Not a bad sign, the earlier builds seemed far too quick, I've put some more timing constraints in place so perhaps this will give a better result. (As an aside, open source code is great, but does not always match the actual code/build parameters used to create the released bitstreams. We developers sometimes like to hold something back. So its not really surprising that the bitcoin x6500 code is not quite as easy to replicate you'd expect
)
Sorry, I managed to delete this previous post while quoting from it (probably pressed edit rather than quote), hope you read it first (I was just commenting that the hash rate is correct since we've got two cores per fpga).
Quote
I suppose I could do a couple of fixed frequency builds (it really should be working at >100MHz) which will eliminate the initial DCM programming as the source of the problem. Yup, I'll fire up the build machine and get those done now.
I've been running a 100MHz build for about 3 hours now, still not fully routed (899 to go), so I'll leave it run overnight (UK time). Not a bad sign, the earlier builds seemed far too quick, I've put some more timing constraints in place so perhaps this will give a better result. (As an aside, open source code is great, but does not always match the actual code/build parameters used to create the released bitstreams. We developers sometimes like to hold something back. So its not really surprising that the bitcoin x6500 code is not quite as easy to replicate you'd expect
)No problem.
I got the x6500-miner to load and run the new code. No rejects, which might be a problem, or blocks so far. I'll un-comment the debug output and try get an idea if it is working.
I also managed to get MPBM to load the bitstream, point the source to the BLC client (reported correct info such as current diff), and report the blockchain info. Unfortunately, after what seems like the start of mining, it crashes with a proxy error (I'll rerun it and post the error).
October 30, 2013, 06:45:59 PM
I have no clue if its correct but if i would calc what i should get this would be : 4400 * 1000000 * 25 * 60 * 60 * 24 / 4294967296 / 8843
The resulting value = 250,234359073434 coins
But i actually was getting 0,00 coins a day
The resulting value = 250,234359073434 coins
But i actually was getting 0,00 coins a day
October 30, 2013, 06:17:39 PM
Quick earnings calculator, edit those numbers to match your hashrate and current difficulty and paste it to Calc
Coins/day @ 500 MH/s, 8843 difficulty
500 * 1000000 * 25 * 60 * 60 * 24 / 4294967296 / 8843
Coins/day @ 500 MH/s, 8843 difficulty
500 * 1000000 * 25 * 60 * 60 * 24 / 4294967296 / 8843
October 30, 2013, 06:07:28 PM
Well i used both programs provided cgminer and reaper and at first i was getting some coins
However the last week that i mined nothing was being accepted as valid
So if you people can get coins and i don't that does not mean my setup is wrong but others get the coins instead of me
However the last week that i mined nothing was being accepted as valid
So if you people can get coins and i don't that does not mean my setup is wrong but others get the coins instead of me
That's the negative side-effect of solo mining. Someone can mine the same block and solve it faster and/or submit it first. A pool would make it more balanced.
October 30, 2013, 06:02:08 PM
Well i used both programs provided cgminer and reaper and at first i was getting some coins
However the last week that i mined nothing was being accepted as valid
So if you people can get coins and i don't that does not mean my setup is wrong but others get the coins instead of me
However the last week that i mined nothing was being accepted as valid
So if you people can get coins and i don't that does not mean my setup is wrong but others get the coins instead of me
October 30, 2013, 05:50:50 PM
Atavacron
Sorry, I managed to delete this previous post while quoting from it (probably pressed edit rather than quote), hope you read it first (I was just commenting that the hash rate is correct since we've got two cores per fpga).
I've been running a 100MHz build for about 3 hours now, still not fully routed (899 to go), so I'll leave it run overnight (UK time). Not a bad sign, the earlier builds seemed far too quick, I've put some more timing constraints in place so perhaps this will give a better result. (As an aside, open source code is great, but does not always match the actual code/build parameters used to create the released bitstreams. We developers sometimes like to hold something back. So its not really surprising that the bitcoin x6500 code is not quite as easy to replicate you'd expect )
Sorry, I managed to delete this previous post while quoting from it (probably pressed edit rather than quote), hope you read it first (I was just commenting that the hash rate is correct since we've got two cores per fpga).
Quote
I suppose I could do a couple of fixed frequency builds (it really should be working at >100MHz) which will eliminate the initial DCM programming as the source of the problem. Yup, I'll fire up the build machine and get those done now.
I've been running a 100MHz build for about 3 hours now, still not fully routed (899 to go), so I'll leave it run overnight (UK time). Not a bad sign, the earlier builds seemed far too quick, I've put some more timing constraints in place so perhaps this will give a better result. (As an aside, open source code is great, but does not always match the actual code/build parameters used to create the released bitstreams. We developers sometimes like to hold something back. So its not really surprising that the bitcoin x6500 code is not quite as easy to replicate you'd expect
) October 30, 2013, 04:46:14 PM
Great! Do you have any back of envelope estimations for amount of LUTs needed?
I've downloaded the reference HDL (unfortunately its VHDL rather than Verilog so I'm on a steep learning curve there). However looking at the comparisons, all of the SHA3 final round candidates were roughly the same in terms of area implementation (see the image at http://www.iis.ee.ethz.ch/~sha3/), blake and keccak being to the smaller end of the range. In terms of LUTs, the reference implemetations were for a mimimum size, rather than maximizing the throughput. I would expect keccak to work out fairly similar to blake since it actually won the competition (a total guess that!). The simplest blake easily fits on a DE0-Nano (10k LE used for the midstate variant), while my current builds run to about 40k LUT per core on the LX150 (though only two cores currently fit due to routing problems)
). Probably there are some new tricks to learn in VHDL code, thank you for idea! October 30, 2013, 04:17:34 PM
I've got a project on the back burner to implement Quark hashing on FPGA, which will require pretty much all of those, or at the very least keccak in case someone comes up with a SHA3 coin, wanna be ready to hash from the get-go 
Great! Do you have any back of envelope estimations for amount of LUTs needed?BTW, Copperlark (heavily premined but still alive) is keccak based.
Sorry, at the moment the project is just at a very early stage (I only thought of it a couple of weeks ago when blake got going). I've downloaded the reference HDL (unfortunately its VHDL rather than Verilog so I'm on a steep learning curve there). However looking at the comparisons, all of the SHA3 final round candidates were roughly the same in terms of area implementation (see the image at http://www.iis.ee.ethz.ch/~sha3/), blake and keccak being to the smaller end of the range. In terms of LUTs, the reference implemetations were for a mimimum size, rather than maximizing the throughput. I would expect keccak to work out fairly similar to blake since it actually won the competition (a total guess that!). The simplest blake easily fits on a DE0-Nano (10k LE used for the midstate variant), while my current builds run to about 40k LUT per core on the LX150 (though only two cores currently fit due to routing problems)
Sorry I can't help further, I'll have a better idea once I actually start on the project proper (perhaps in the next few weeks, depending on how the blake work goes).
Thanks for the Copperlark info, I'll take a look at that.
October 30, 2013, 03:55:24 PM
I've got a project on the back burner to implement Quark hashing on FPGA, which will require pretty much all of those, or at the very least keccak in case someone comes up with a SHA3 coin, wanna be ready to hash from the get-go
Great! Do you have any back of envelope estimations for amount of LUTs needed?BTW, Copperlark (heavily premined but still alive) is keccak based.
October 30, 2013, 12:39:46 PM
It is fortunate we have someone like Kramble that is kind enough to explain to FPGA newbs, like myself, the ins and outs of FPGAs as it is applied to crypto coins. I've been fascinated by FPGAs for some time now and testing the Blakecoin FPGA miner has given me the needed push to dive deeper. Plus it doesn't hurt to make some coins in the process. Thanks Kramble.
I'm looking forward to your next bitstream. As for the last bitstream, I ran "X6500-Robust-v04-2core-fmax-100MHz.bit" for 21 hours with the below results. Interestingly, the overclock was set to 63MHz but the Run Summary reports a Hash Rate @ ~120MHz.
python mine.py -d 0 -u 127.0.0.1:8772 -w --verbose --overclock 63
I'm looking forward to your next bitstream. As for the last bitstream, I ran "X6500-Robust-v04-2core-fmax-100MHz.bit" for 21 hours with the below results. Interestingly, the overclock was set to 63MHz but the Run Summary reports a Hash Rate @ ~120MHz.
python mine.py -d 0 -u 127.0.0.1:8772 -w
Code:
...
0 kH/s | 0: 0/2177/0 100.0%/0.0% | 1: 0/2203/0 100.0%/0.0% | 21h47m | xxxxxxxx
midstatehex= aed57a86736a9369d4254d680c1199970a1437c1f834d6c88f9c336901ead826
2013-10-30 11:54:49 | 0: Job data loaded in 0.034 seconds
2013-10-30 11:54:49 | 1: Loading new job...
2013-10-30 11:54:49 | 1: Checking for nonce*...
2013-10-30 11:54:49 | 1: Writing job...
0 kH/s | 0: 0/2177/0 100.0%/0.0% | 1: 0/2203/0 100.0%/0.0% | 21h47m | xxxxxxxx
midstatehex= 445f08592f53292635592347ffc80f481674dd22851ff9b491216ac76a4cd402
2013-10-30 11:54:49 | 1: Job data loaded in 0.034 seconds
2013-10-30 11:55:00 | Exiting...
Run Summary:
-------------
Device: 0
Serial: xxxxxxxx
Number of FPGAs: 2
Running time: 21h47m
Getwork interval: 20 secs
FPGA 0:
Accepted: 0
Rejected: 2177 (100.00%)
Invalid: 0 (0.00%)
Hashrate (all nonces): 119.14 MH/s
Hashrate (valid nonces): 0 kH/s
Hashrate (accepted shares): 0 kH/s
FPGA 1:
Accepted: 0
Rejected: 2203 (100.00%)
Invalid: 0 (0.00%)
Hashrate (all nonces): 120.57 MH/s
Hashrate (valid nonces): 0 kH/s
Hashrate (accepted shares): 0 kH/s
Total hashrate for device: 239.71 MH/s / 0 kH/s / 0 kH/s
0 kH/s | 0: 0/2177/0 100.0%/0.0% | 1: 0/2203/0 100.0%/0.0% | 21h47m | xxxxxxxx
midstatehex= aed57a86736a9369d4254d680c1199970a1437c1f834d6c88f9c336901ead826
2013-10-30 11:54:49 | 0: Job data loaded in 0.034 seconds
2013-10-30 11:54:49 | 1: Loading new job...
2013-10-30 11:54:49 | 1: Checking for nonce*...
2013-10-30 11:54:49 | 1: Writing job...
0 kH/s | 0: 0/2177/0 100.0%/0.0% | 1: 0/2203/0 100.0%/0.0% | 21h47m | xxxxxxxx
midstatehex= 445f08592f53292635592347ffc80f481674dd22851ff9b491216ac76a4cd402
2013-10-30 11:54:49 | 1: Job data loaded in 0.034 seconds
2013-10-30 11:55:00 | Exiting...
Run Summary:
-------------
Device: 0
Serial: xxxxxxxx
Number of FPGAs: 2
Running time: 21h47m
Getwork interval: 20 secs
FPGA 0:
Accepted: 0
Rejected: 2177 (100.00%)
Invalid: 0 (0.00%)
Hashrate (all nonces): 119.14 MH/s
Hashrate (valid nonces): 0 kH/s
Hashrate (accepted shares): 0 kH/s
FPGA 1:
Accepted: 0
Rejected: 2203 (100.00%)
Invalid: 0 (0.00%)
Hashrate (all nonces): 120.57 MH/s
Hashrate (valid nonces): 0 kH/s
Hashrate (accepted shares): 0 kH/s
Total hashrate for device: 239.71 MH/s / 0 kH/s / 0 kH/s
October 30, 2013, 11:19:41 AM
Kramble, Sounds like you are having a lot of fun with this. Thanks. (even if I don't have a FPGA 
)
)Yep, having a ball. Got to keep those little grey cells busy now I've retired from the world of wage slavery. It wouldn't be nearly so much fun if I was getting paid to do it (though all experience is useful, and there is no knowing where this will go)
October 30, 2013, 11:09:46 AM
Kramble, Sounds like you are having a lot of fun with this. Thanks. (even if I don't have a FPGA )
) October 30, 2013, 10:38:38 AM
Kramble,
I recall you mentioning that you use modelsim for the fpga testing. In my search for blake code examples, I found the below site. Note the folder labeled "modelsim" and the multiple SHA-3 candidates at top. There is a modelsim folder for each.
http://www.iis.ee.ethz.ch/~sha3/blake/
I recall you mentioning that you use modelsim for the fpga testing. In my search for blake code examples, I found the below site. Note the folder labeled "modelsim" and the multiple SHA-3 candidates at top. There is a modelsim folder for each.
http://www.iis.ee.ethz.ch/~sha3/blake/
Yep, its a useful site (shame they have converted all their source code into html, just makes more work to copy it). I've got a project on the back burner to implement Quark hashing on FPGA, which will require pretty much all of those, or at the very least keccak in case someone comes up with a SHA3 coin, wanna be ready to hash from the get-go
Anyway thats OT, so back to modelsim. Those are just build scripts, so are not of much use. Modelsim itself is a commercial product http://www.mentor.com/products/fv/modelsim/ and I'm using the free version bundled with Quartus II for the DE0-Nano fpga dev board. You can download it from http://www.altera.com/products/software/quartus-ii/web-edition/qts-we-index.html Its not really meant for use with xilinx fpgas, but I was familiar with it so just stayed with it rather than learning the xilinx webpack simulator http://www.xilinx.com/products/design_tools/logic_design/verification/ise_simulator_faq.htm
I should have an updated version of the x6500 python miner later today (just finshing off my blakeminer.py mods first). Then I'll have a look the TheSeven's Modular Python Bitcoin Miner (should be trivial to add blake support now I've found some python code). And then I'll make a start on the x6500 debugging.
Jump to: