Bitcoin Forum
December 09, 2016, 11:17:05 PM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 [32] 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 »
  Print  
Author Topic: Official Open Source FPGA Bitcoin Miner (Last Update: April 14th, 2013)  (Read 403020 times)
Khertan
Full Member
***
Offline Offline

Activity: 193


View Profile WWW
February 24, 2013, 03:45:07 PM
 #621

A (probably) final update on my experiences with the DE0-Nano, in case anyone out there is interested.

Using Makomk's code (from his github rather than the fpgaminer code), plus some modifications of my own to pack 22 of the sha256_digester's onto the EP4CE22, I've got a single core generating a full bitcoin hash every 6 clock cycles. I've been running this at 140MHz for a couple of days now which I reckon is 23.3MH/s (it averages 20 shares per hour which I reckon is about right, though if anyone wants to correct me on this then please feel free to do so). Its drawing 1.35 amps from an external 3.3V PSU, and the onboard regulators get pretty hot (I'm fan cooling the board). Not that I'd recommend this to anyone as its really pushing the envelope on the DE0-Nano board and may well fry it eventually.

This is probably as far as I'm going to go with this as to clock it any faster will need modifications to the power supply (as Makmok has documented on his web site) since the onboard regulators are only rated at 1.5A (and that's pretty optimistic as they need some serious additional cooling to get anywhere near that).

I'm running a pair of these boards on btcguild which claims to be earning me 0.00659245 BTC per day, not a lot I know, and probably barely covering my power costs (two times 4.5 Watts, plus another say 2 Watts for the raspberry pi host, plus whatever the mains PSU's are dissipating in heat), but I may as well have the boards do something vaguely useful while I think of something else to use them for, and its "free" bitcoins anyway (even if I am just converting joules into coins). I wonder what I can spend them on?

Many thanks to all who have contributed to this project, as its kept me well entertained for the last few months (I saw a quote somewhere saying you can lose 3 months of your life to FPGA's, so it seems like an appropriate point to bow out).

Regards
Mark

I'm interested, indeed. Did you share somewhere your modifications ?
I'm currently trying to optimizing things (virtually, didn't have device yet).

Yes i know useless, that s most for fun as i bought a de0-nano for testing something else but once tested, i ll playing to try to run a miner on it ...

Total Logic Elements : 22,320 / 22,320 ( 100 % ) :p

Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1481325425
Hero Member
*
Offline Offline

Posts: 1481325425

View Profile Personal Message (Offline)

Ignore
1481325425
Reply with quote  #2

1481325425
Report to moderator
1481325425
Hero Member
*
Offline Offline

Posts: 1481325425

View Profile Personal Message (Offline)

Ignore
1481325425
Reply with quote  #2

1481325425
Report to moderator
1481325425
Hero Member
*
Offline Offline

Posts: 1481325425

View Profile Personal Message (Offline)

Ignore
1481325425
Reply with quote  #2

1481325425
Report to moderator
kramble
Sr. Member
****
Offline Offline

Activity: 384



View Profile WWW
February 25, 2013, 01:48:18 PM
 #622

I'm interested, indeed. Did you share somewhere your modifications ?
I'm currently trying to optimizing things (virtually, didn't have device yet).

I've just now created a github account https://github.com/kramble/DE0-Nano-BitCoin-Miner and put up my 22 hasher mod of Makomk's code, plus the code for my raspberry pi mining host (warning, its pretty crude). Github's new to me, so I hope I've got it right (I based it on a bunch of stuff I mailed to another bitcointalk user, so the README is a bit out of date). Its probably worth noting the parameter SPEED_MHZ which sets the PLL osc speed, though confusingly in units of 10MHz (sorry), eg SPEED_MHZ=4 runs at 40MHz (I've kept it slow in the published code for safety's sake).

I've moved on from this now (it was fun, but not really worth spending any more time on), though I will note that I was able to reliably clock it up to a maximum of 170MHz (28.3MH/s), using an external 1.2V core supply as documented by Makomk at http://www.makomk.com/2011/10/06/de0-nano-power-efficiency-mod (though my version was somewhat of a kludge as I ran the external supply in parallel with the onboard regulators, and overvolted the supply slightly to 1.3V to ensure the onboard reg was overdriven ... not pretty, but it seemed happy about it).

Best of luck, and take care with the regulator temperatures (and USB supply current) if you crank the clock rate up.
Mark


Github https://github.com/kramble BLC BkRaMaRkw3NeyzsZ2zUgXsNLogVVkQ1iPV
Khertan
Full Member
***
Offline Offline

Activity: 193


View Profile WWW
March 12, 2013, 09:30:34 PM
 #623

Oh ... didn't notice your answer, thx a lot.

I'll not put clock too high, as i ll not put an other regulated power, this is more an exercice for trying to optimize things for fun Smiley
For the moment i ll just play with the simulator until the device will be delivered (bought but not yet received) Smiley

EDIT :

While trying to simulate i got an error :

# ** Error: (vsim-3033) fpgaminer_6_1200mv_85c_slow.vo(759): Instantiation of 'dffeas' failed. The design unit was not found.
#         Region: /test_fpgaminer_top/uut

Maybe you can point me what i miss ...
Thx

EDIT: was not in cycloneive_ver lib but altera Smiley

Khertan
Full Member
***
Offline Offline

Activity: 193


View Profile WWW
March 13, 2013, 06:20:40 AM
 #624

Look like i need to understand a bit more the complex modelsim ide Smiley

I got some error that should not happen ...
This or another usage of 'uut.data_buf' inconsistent with 'net' object.
#         Region: /test_fpgaminer_top


I probably miss something, any advices ?

kramble
Sr. Member
****
Offline Offline

Activity: 384



View Profile WWW
March 13, 2013, 11:09:45 AM
 #625

Hi Khertan

Unfortunately I'm not much of an expert in modelsim, so I'm probably not going to be of much help here.

The Modelsim version I used was the one than came on the CDROM with the DE0-Nano vis Modelsim ALTERA starter edition version 6.6c and Quartus II version 10.1 web edition.

I didn't really do much in the way of simulation as the original fpgaminer code worked fine, and my mod's were mostly just hacking around at the top level (though I did use it to debug my 22 hasher mod).

The only thing I can think of is the need to define the macro SIM (I just set it = 1) in the compile properties of fpgaminer_top.v so as to disable the virtual_wire probes (I'm assuming you're simulating the JTAG version, though I also did this for the serial version). This would certainly affect uut.data_buf, but I just tried deleting the macro and I got the error "Instantiation of 'virtual_wire' failed. The design unit was not found." rather than your "inconsistent with 'net' object".

But I didn't include virtual_wire.v in the modelsim project (its not needed for the simulation, and does not work anyway ... I just added it in, it compiles but simulating gives "Instantiation of 'altsource_probe' failed. The design unit was not found.").
Ah, memory is just coming back, I now recall that at this point I realised that I needed to define the SIM macro, and removed the virtual_wire.v module from the simulation.

Anyway, I'm probably not helping much here. It may be worth you going back to the original fpgaminer code (from the github link on the first page of this thread) and get that working first in the simulator, then see what differences my code introduces.

Regards
Mark

Github https://github.com/kramble BLC BkRaMaRkw3NeyzsZ2zUgXsNLogVVkQ1iPV
kramble
Sr. Member
****
Offline Offline

Activity: 384



View Profile WWW
March 13, 2013, 12:03:34 PM
 #626

Just to make sure we're on the same page, I just did the following ...

BTW I'm using windows 8 (its an upgrade from windows vista, quartus/modelsim were actually installed on vista prior to the upgrade and survived the process, albeit with a rather strange but minor windowing display bug that just affects quartus).

Modelsim ALTERA starter edition version 6.6c / Quartus II version 10.1 web edition (installed from DE0-Nano CDROM).

Downloaded the Zip version from https://github.com/kramble/DE0-Nano-BitCoin-Miner
Unzipped it using 7-zip to C:\Users\Boss\Downloads\DE0-Nano-BitCoin-Miner-master\DE0-Nano-BitCoin-Miner-master
(sorry about the double nesting, 7zip just does that by default)
Started modelsim
Pressed Jumpstart on the Welcome screen, then "Create a Project"
Called it hashers22 and for the project location I browsed to
C:/Users/Boss/Downloads/DE0-Nano-BitCoin-Miner-master/DE0-Nano-BitCoin-Miner-master/Hashers22
At the add items dialog, press "Add existing file", then press browse (it opens the above folder)
Select (ctrl-click) ONLY fpgaminer_top.v, sha256_transform.v, sha-256-functions.v, test_fpgaminer_top.v
Close the dialogs.
In the project screen, right click on fpgaminer_top.v, compile, compile properties, in the dialog press Macro...
then enter SIM value 1 and close the dialogs
Press the "Compile All" button in the toolbar ... all 4 should compile successfully
Press the "Simulate"  button in the toolbar, expand the work folder and select test_fpgaminer_top
Assuming it loads OK, click on uut to expand the objects pane
Click on Simulate menu, Runtime options, Radix and select hexadecimal
Change the run length from 100ps to 100ns
Step the simulation 17 times (to 1700ns) and golden_nonce should change to 1afda099

That just worked for me, so possibly you're using a newer version of Modelsim and it just does not like the code? Then again its possible that I may just have fiddled with the modelsim configuration at some point when I was originally trying to get it working.

Perhaps one the the real experts could chip in to help out?

Regards
Mark

Github https://github.com/kramble BLC BkRaMaRkw3NeyzsZ2zUgXsNLogVVkQ1iPV
Khertan
Full Member
***
Offline Offline

Activity: 193


View Profile WWW
March 13, 2013, 01:37:39 PM
 #627

Oh ... if i start modelsim from quartus i got the error i posted in previous post, if i create the project manually like you explain it, that s works... Smiley)

Thanks a lot ! I ll now be able to play a bit more with the code Smiley

senseless
Sr. Member
****
Offline Offline

Activity: 388



View Profile
March 14, 2013, 12:28:47 PM
 #628


Finally got around to fiddling with my FPGA and getting it working. I'm running a stratix iv 230.

Was able to get a single fully unrolled core of the makomk-mod running. Started at 50mhz then went up to 100mhz then to 200mhz. I haven't really load tested it (just long enough to submit a couple shares then I kill the TCL miner). Now that I have it working, I'm concerned that I might burn up my chip. I was wondering what the implications of using a 50mhz clock source with a clock multiplier of 4 to obtain 200mhz were? In my timequest timing analsys it says my fmax is 233mhz for the pll driving the mining core. Is it safe to try to push 233mhz on a 50mhz clock source?  I don't quite understand how the clock source works in relation to the multiplier, divider, etc if anyone would be kind enough to share. My chip should be fully capable of those speeds; but my only other clock sources i'm not quite sure how to access as of yet. They're clock sources that are supposed to be used for driving 10gigabit ethernet among other on-board things (100,125,150,156mhz clock sources).




kramble
Sr. Member
****
Offline Offline

Activity: 384



View Profile WWW
March 14, 2013, 04:21:23 PM
 #629


Finally got around to fiddling with my FPGA and getting it working. I'm running a stratix iv 230.

Was able to get a single fully unrolled core of the makomk-mod running. Started at 50mhz then went up to 100mhz then to 200mhz. I haven't really load tested it (just long enough to submit a couple shares then I kill the TCL miner). Now that I have it working, I'm concerned that I might burn up my chip. I was wondering what the implications of using a 50mhz clock source with a clock multiplier of 4 to obtain 200mhz were? In my timequest timing analsys it says my fmax is 233mhz for the pll driving the mining core. Is it safe to try to push 233mhz on a 50mhz clock source?  I don't quite understand how the clock source works in relation to the multiplier, divider, etc if anyone would be kind enough to share. My chip should be fully capable of those speeds; but my only other clock sources i'm not quite sure how to access as of yet. They're clock sources that are supposed to be used for driving 10gigabit ethernet among other on-board things (100,125,150,156mhz clock sources).


I'm certainly not an expert on these things, but as this thread is something of a backwater, I'll make a few comments while we wait for the real experts to show up.

The PLL multiplier/divider is not a significant issue here as you should be able to achieve 200MHz quite satisfactorily and I guess 233MHz is just multilpy 14 divide 3 (refer to the altpll documentation).

The main issue is power dissipation as a fully unrolled core is going to run quite hot at these clock speeds, and yes, you could destroy the device. Given the expense of these devices (I just looked up the cost of the dev kits ... $3000 or $5000!!), you're taking quite a risk here.

You may want to take it slowly and step up the clock speed in increments. Looking at the DK-SI-4SGX230N data sheet there seems to be an option to display the junction temperature on LCD, but I guess this is going to need to be compiled into the design first.

Anyway as I said, I'm not the expert here, but I just wanted to raise a caution.

Mark

Github https://github.com/kramble BLC BkRaMaRkw3NeyzsZ2zUgXsNLogVVkQ1iPV
senseless
Sr. Member
****
Offline Offline

Activity: 388



View Profile
March 14, 2013, 04:40:36 PM
 #630


Anyway as I said, I'm not the expert here, but I just wanted to raise a caution.


That makes 2 of us. I got the board off ebay. But that's not to say that it was cheap. Was still more expensive than other commonly available boards/fpga miners. If I got this thing running months ago when I bought it would've paid for itself by now. But at an electric cost of 35$ per year I should still be able to make it pay for itself over the next 2 years.

My main concern is that I would somehow damage my clock source by running the multiplier to high (if that is even possible). But it sounds like there shouldn't be any issues as long as I keep my temps under control. Unfortunately I don't have the LCD Sad



kramble
Sr. Member
****
Offline Offline

Activity: 384



View Profile WWW
March 14, 2013, 05:14:31 PM
 #631


My main concern is that I would somehow damage my clock source by running the multiplier to high (if that is even possible). But it sounds like there shouldn't be any issues as long as I keep my temps under control. Unfortunately I don't have the LCD Sad

Ah, obviously not the board I found via google http://www.buyaltera.com/scripts/partsearch.dll?Detail&name=544-2592-ND
so I'm talking out of my a** here. Shame as it looks to have a nice heatsink and fan to help with the cooling.

You won't damage the clock source, but as I said you may burn the chip! Quartus does have some options to estimate power dissipation, but you'll need to plug in the correct cooling parameters for the board, and anyway I'm getting out of my depth here as I've only played with a smallish cyclone device, and not the monster you've got your hands on Cheesy
Even so, I can hazard a guess ... given that my one-sixth core on cyclone iv at 170MHz was dissipating around 2 watts, so for a full core you'd be looking at around 15 watts at 200MHz (possibly a bit less if the stratix is using a more advanced silicon process), which is going to need some serious cooling. Does the board have any temperature monitoring at all? Or can you attach a temperature probe to the heatsink? (I'm using one of those internal/external thermometers, though you have to be careful to insulate the metal probe so it won't short out anything) You'll need to keep the heatsink below around 60C to ensure a safe junction temperature, though for the exact calculation you need to know the actual power dissipation and junction-to-case thermal resistance of the package.

Anyway, as I said, I'm out of my depth here, sorry.
Mark


Github https://github.com/kramble BLC BkRaMaRkw3NeyzsZ2zUgXsNLogVVkQ1iPV
senseless
Sr. Member
****
Offline Offline

Activity: 388



View Profile
March 14, 2013, 11:46:18 PM
 #632

The board I have is the DK-DEV-4SGX230N. It's got a place for the LCD I just don't have one.

Thanks for your assistance. I think i'm just going to find some 3rd party temperature monitoring do-hickey. The FPGA currently has a heat sink but no fan. I'll need to get around to adding a fan (and probably replacing the heat sink) at some point today.

Was able to get orphanedgland going stable @ 100mhz w/ 3 cores. (300mh/s). The FPGA's heatsink doesn't even go above room temperature (though I did now add a fan). The fMax of the orphaned gland code is 107mhz. Not sure if I should go about trying to get 3-4x makomk-mod's hashers running together or try to improve the fmax of the orphanedgland code.





kingcoin
Sr. Member
****
Offline Offline

Activity: 262


View Profile
March 15, 2013, 03:25:35 AM
 #633

I just gave this miner I try and run into a couple questions:

1) What is the _rejected_ message and 100% rejection related to?

Quote
[03/15/2013 04:17:29] 99.99 MH/s (~102.07 MH/s) [Rej: 409/409 (100.00%)]
[03/15/2013 04:17:31] 100.05 MH/s (~102.06 MH/s) [Rej: 409/409 (100.00%)]
[03/15/2013 04:17:31] 1b687ede _rejected_
[03/15/2013 04:17:33] 23a953e9 _rejected_
[03/15/2013 04:17:35] 100.00 MH/s (~102.53 MH/s) [Rej: 411/411 (100.00%)]
[03/15/2013 04:17:35] 334dcacd _rejected_
[03/15/2013 04:17:37] 100.04 MH/s (~102.77 MH/s) [Rej: 412/412 (100.00%)]
[03/15/2013 04:17:39] 100.00 MH/s (~102.76 MH/s) [Rej: 412/412 (100.00%)]
[03/15/2013 04:17:41] 100.02 MH/s (~102.75 MH/s) [Rej: 412/412 (100.00%)]

2) Will the TCL script handle multiple instances of the miner within a single FPGA?

3) Will the TCL script handle multiple FPGA's connected through the same JTAG chain

4) Will the TCL script handle multiple FPGA's connected through multiple JTAG chains, i.e. multiple USB blasters
senseless
Sr. Member
****
Offline Offline

Activity: 388



View Profile
March 15, 2013, 04:05:43 AM
 #634

I just gave this miner I try and run into a couple questions:

1) What is the _rejected_ message and 100% rejection related to?

Quote
[03/15/2013 04:17:29] 99.99 MH/s (~102.07 MH/s) [Rej: 409/409 (100.00%)]
[03/15/2013 04:17:31] 100.05 MH/s (~102.06 MH/s) [Rej: 409/409 (100.00%)]
[03/15/2013 04:17:31] 1b687ede _rejected_
[03/15/2013 04:17:33] 23a953e9 _rejected_
[03/15/2013 04:17:35] 100.00 MH/s (~102.53 MH/s) [Rej: 411/411 (100.00%)]
[03/15/2013 04:17:35] 334dcacd _rejected_
[03/15/2013 04:17:37] 100.04 MH/s (~102.77 MH/s) [Rej: 412/412 (100.00%)]
[03/15/2013 04:17:39] 100.00 MH/s (~102.76 MH/s) [Rej: 412/412 (100.00%)]
[03/15/2013 04:17:41] 100.02 MH/s (~102.75 MH/s) [Rej: 412/412 (100.00%)]

2) Will the TCL script handle multiple instances of the miner within a single FPGA?

3) Will the TCL script handle multiple FPGA's connected through the same JTAG chain

4) Will the TCL script handle multiple FPGA's connected through multiple JTAG chains, i.e. multiple USB blasters

Check to make sure your I/O is setup correctly. I had a wide variety of problems until i used the 50mhz GPIO clock on my board with 2.5v I/O.

I'm not sure if the miner will handle multiple cards or fpga on the same chain. I had to disable my CPLD to get it to function correctly. I was thinking of trying to put a driver hack together to handle the opensource fpga miner firmware on jtag for cgminer. But it'll likely take me forever. I'd be willing to put some coins toward a bounty for getting a jtag driver in cgminer for this firmware.

kingcoin
Sr. Member
****
Offline Offline

Activity: 262


View Profile
March 15, 2013, 07:30:58 AM
 #635

Check to make sure your I/O is setup correctly. I had a wide variety of problems until i used the 50mhz GPIO clock on my board with 2.5v I/O.

The pin location and io specification for the clock pin should be correct. I have a signaltap instance and some other logic in there which I observe is operating correctly off the same clock. I will try to disable the signaltap part in case it causes problems for the jtag hub...

But what does the 100% reject ratio actually mean? Is it described somewhere? If not I'll have to peek more into the logic and scripts....
kingcoin
Sr. Member
****
Offline Offline

Activity: 262


View Profile
March 15, 2013, 08:24:18 AM
 #636

But what does the 100% reject ratio actually mean? Is it described somewhere? If not I'll have to peek more into the logic and scripts....

Or does it simply mean that it did not find a solution before somebody else, which is the most natural case. The output shown initially in this thread is winning, but this could be due to that it's located on some test net. Is that the case?

kingcoin
Sr. Member
****
Offline Offline

Activity: 262


View Profile
March 15, 2013, 08:43:43 AM
 #637

I'm not sure if the miner will handle multiple cards or fpga on the same chain.

There's a note in the mine.tcl:

Quote
TODO: Handle multiple FPGAs at once

So I guess the answer to multiple FPGA's is no...
kramble
Sr. Member
****
Offline Offline

Activity: 384



View Profile WWW
March 15, 2013, 10:30:18 AM
 #638

1) What is the _rejected_ message and 100% rejection related to?

Quote
[03/15/2013 04:17:29] 99.99 MH/s (~102.07 MH/s) [Rej: 409/409 (100.00%)]
[03/15/2013 04:17:31] 100.05 MH/s (~102.06 MH/s) [Rej: 409/409 (100.00%)]
[03/15/2013 04:17:31] 1b687ede _rejected_
[03/15/2013 04:17:33] 23a953e9 _rejected_
[03/15/2013 04:17:35] 100.00 MH/s (~102.53 MH/s) [Rej: 411/411 (100.00%)]
[03/15/2013 04:17:35] 334dcacd _rejected_
[03/15/2013 04:17:37] 100.04 MH/s (~102.77 MH/s) [Rej: 412/412 (100.00%)]
[03/15/2013 04:17:39] 100.00 MH/s (~102.76 MH/s) [Rej: 412/412 (100.00%)]
[03/15/2013 04:17:41] 100.02 MH/s (~102.75 MH/s) [Rej: 412/412 (100.00%)]

Looks to me that the pool is rejecting ALL of your shares! So either the fpga is producing garbage, or your submission to the pool is not working.

However the actual hash rate (102.75MH/s) matches the expected rate of 100MH/s pretty closely, so the device would seem to be hashing properly. Assuming you're using the official fpgaminer code (linked on the first page of this thread), I can offer the comment that its not entirely bug free. It has several variants and some are better than others. From the hash rate it looks like you're running the fully unrolled version which I can't (I've only got a 22kLE part), but I did come across a very similar problem caused by GOLDEN_NONCE_OFFSET being off by one for the particular LOG_LOOP2 value I was using  (so the submitted nonce was consistently wrong, even though the hash had been correctly calculated). The mine.tcl script does not check the result before submitting it to the pool. So one thing to try is to add some logging to the script and then manually check the hash values to see if they are correct. Or maybe just try a different pool (the default btcguild configuration works fine for me, albeit with my own account details).

Mark

Github https://github.com/kramble BLC BkRaMaRkw3NeyzsZ2zUgXsNLogVVkQ1iPV
kingcoin
Sr. Member
****
Offline Offline

Activity: 262


View Profile
March 15, 2013, 12:25:06 PM
 #639

Looks to me that the pool is rejecting ALL of your shares! So either the fpga is producing garbage, or your submission to the pool is not working.

The FPGA seem to be running. The problem appears to be related to upstream json communication. I'm a bitcoin newbie so it's a little hard to tell if the transactions are correct. I've included some puts statements and here is what I observe:

Code:
[03/15/2013 13:03:35] 99.99 MH/s (~52.70 MH/s) [Rej: 2/2 (100.00%)]
Submitting work ... 0000000236fdabecb3eff6caa95027cf247643cade23325ab5d677040000
0304000000006f21ab6f094d06f1df5ff632aeeedb3634639ab1762bcbda5a511f0c8167ea675143
0e081a0375fae44d3b1a000000800000000000000000000000000000000000000000000000000000
000000000000000000000000000080020000
do_rpc_request: url: http://localhost:8332 request: {"method": "getwork", "params": [ "0000000236fdabecb3eff6caa95027cf247643cade23325ab5d6770400000304000000006f21ab6f094d06f1df5ff632aeeedb3634639ab1762bcbda5a511f0c8167ea6751430e081a0375fae44d3b1a000000800000000000000000000000000000000000000000000000000000000000000000000000000000000080020000" ], "id":1}
do_rpc_request: will return result false error null id 1
json_dict: result false error null id 1
[03/15/2013 13:03:36] 1a3b4de4 _rejected_
do_rpc_request: url: http://localhost:8332 request: {"method": "getwork", "params": [], "id":0}
do_rpc_request: will return result {midstate 662f73807a8ad39f1d7fef2e480fefb19a9c8c9be9dc3bba07efd37c4c4a0859 data 0000000236fdabecb3eff6caa95027cf247643cade23325ab5d677040000030400000000ad9da8b1b157514d40ca3ddd23ee4dfef10f09f5a84d9717bcc5d7190a0d404151430e171a0375fa00000000000000800000000000000000000000000000000000000000000000000000000000000000000000000000000080020000 hash1 00000000000000000000000000000000000000000000000000000000000000000000008000000000000000000000000000000000000000000000000000010000 target 0000000000000000000000000000000000000000000000fa7503000000000000} error null id 0
[03/15/2013 13:03:38] 100.01 MH/s (~77.62 MH/s) [Rej: 3/3 (100.00%)]


The problem might also be related to the configuration of my bitcoind on localhost.
kramble
Sr. Member
****
Offline Offline

Activity: 384



View Profile WWW
March 15, 2013, 12:52:53 PM
 #640

The problem might also be related to the configuration of my bitcoind on localhost.

Yes, I think that is likely. Just to eliminate this, why not just set up an account on btcguild (it only takes a moment) and try it on there?

I know almost nothing about the getwork protocol, but comparing your sample, the target value 0000000000000000000000000000000000000000000000fa7503000000000000 looks suspicious. I'm pretty sure the fpgaminer is hard coded to search for difficulty 1 shares. For instance my script logs target values of ffffffffffffffffffffffffffffffffffffffffffffffffffffffff00000000 from btcguild getwork requests.

I'll have a poke around in my stuff and see if I can confirm the sample hash you've given. Be right back.

Regards
Mark

Github https://github.com/kramble BLC BkRaMaRkw3NeyzsZ2zUgXsNLogVVkQ1iPV
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 [32] 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!