Bitcoin Forum
December 03, 2016, 11:43:44 AM *
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 402465 times)
themike5000
Member
**
Offline Offline

Activity: 99


View Profile
July 02, 2011, 04:51:08 AM
 #341

I adapted the "program-fpga-board.bat" program to load "OrphanGland's" .sof file for the stratix 4 boards onto my fpga (my chip is the 230, his is the 530).  Then I changed the minc.tcl file to point towards my device.  I run the program and this is what spits out:



What am I supposed to see?
(I put in my slush credentials into the file as well)

Vertcoin: VdHjU3L2dcHCR3uQmqpM6mf4LCvp2678wh
1480765424
Hero Member
*
Offline Offline

Posts: 1480765424

View Profile Personal Message (Offline)

Ignore
1480765424
Reply with quote  #2

1480765424
Report to moderator
1480765424
Hero Member
*
Offline Offline

Posts: 1480765424

View Profile Personal Message (Offline)

Ignore
1480765424
Reply with quote  #2

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

Posts: 1480765424

View Profile Personal Message (Offline)

Ignore
1480765424
Reply with quote  #2

1480765424
Report to moderator
1480765424
Hero Member
*
Offline Offline

Posts: 1480765424

View Profile Personal Message (Offline)

Ignore
1480765424
Reply with quote  #2

1480765424
Report to moderator
TheSeven
Hero Member
*****
Offline Offline

Activity: 504


FPGA Mining LLC


View Profile WWW
July 02, 2011, 10:00:28 AM
 #342

Sounds like either the FPGA design has a bug that makes it calculate garbage, or the nonce offset value on the client side doesn't fit.

My tip jar: 13kwqR7B4WcSAJCYJH1eXQcxG5vVUwKAqY
comboy
Sr. Member
****
Offline Offline

Activity: 247



View Profile
July 02, 2011, 10:09:18 AM
 #343

To me, themike5000's output looks good, I have very similar one.

I was just wondering, how can I list devices name to know what to put into mine.tcl? I see "hardware_name" in Quartus so that's not a problem, but I don't know where can I check "device_name". The first part in the device name seems to be models that Quartus are asking me too choose between when plugging the device, but what is this 0x020F70DD? I thought maybe checksum but it doesn't seem to fit. Is there any way I can list all devices in a format that I'll be able to use in this param?

Variance is a bitch!
lame.duck
Legendary
*
Offline Offline

Activity: 1242


View Profile
July 02, 2011, 10:44:04 AM
 #344

If i remember correctly, pro programming script has some provisions to detect what  Jtag-adapter an which device on each adaper are connected. Eventually i added some output lines or just commented them out (don't remember exactly). But you can also use the scheme give in the mine.tcl script (even i failed to do so manually) when copying it did work.
Eventually we could  trying to find a canonical naming scheme for the bitstreams so the software could select from the jtag-id.
themike5000
Member
**
Offline Offline

Activity: 99


View Profile
July 02, 2011, 11:25:14 AM
 #345

To me, themike5000's output looks good, I have very similar one.

I was just wondering, how can I list devices name to know what to put into mine.tcl? I see "hardware_name" in Quartus so that's not a problem, but I don't know where can I check "device_name". The first part in the device name seems to be models that Quartus are asking me too choose between when plugging the device, but what is this 0x020F70DD? I thought maybe checksum but it doesn't seem to fit. Is there any way I can list all devices in a format that I'll be able to use in this param?

Run the programfpga.bat file. It will find any attached devices and list them in that format.

I'm going to try to run it for a bit longer and see if slush recognizes my output as work.

Vertcoin: VdHjU3L2dcHCR3uQmqpM6mf4LCvp2678wh
LazarusLong
Newbie
*
Offline Offline

Activity: 16


View Profile
July 02, 2011, 11:42:19 AM
 #346

"result: false" looks like the share was not accepted.
Accepted shares normally should have a result "true" in the JSON response
themike5000
Member
**
Offline Offline

Activity: 99


View Profile
July 02, 2011, 03:46:44 PM
 #347

"result: false" looks like the share was not accepted.
Accepted shares normally should have a result "true" in the JSON response

It seems like its working.  I have it working for bitcoins.lc because it tells me the hashrate of the workers (any other way to do this in the software?).  It leveled out a around 300Mhash/second.  That seems odd because its running on two cores and should be at 220 clock rate (see picture)



Any way to find a more accurate hashrate output than relying on bitcoins.lc to calculate for me?  Am I running at 150 or 220?  I'm confused...

Vertcoin: VdHjU3L2dcHCR3uQmqpM6mf4LCvp2678wh
lame.duck
Legendary
*
Offline Offline

Activity: 1242


View Profile
July 02, 2011, 04:20:45 PM
 #348

Any way to find a more accurate hashrate output than relying on bitcoins.lc to calculate for me?  Am I running at 150 or 220?  I'm confused...

You are running @220MHz and with a lully unrolled design you should have a hashrate of 220 MHash/s
themike5000
Member
**
Offline Offline

Activity: 99


View Profile
July 02, 2011, 04:27:51 PM
 #349

Any way to find a more accurate hashrate output than relying on bitcoins.lc to calculate for me?  Am I running at 150 or 220?  I'm confused...

You are running @220MHz and with a lully unrolled design you should have a hashrate of 220 MHash/s

220MHash/s on each core though, right?

Vertcoin: VdHjU3L2dcHCR3uQmqpM6mf4LCvp2678wh
lame.duck
Legendary
*
Offline Offline

Activity: 1242


View Profile
July 02, 2011, 04:42:28 PM
 #350

yes, on each core.

OrphanedGland
Member
**
Offline Offline

Activity: 71


View Profile
July 02, 2011, 04:53:01 PM
 #351

440MH/s is the raw underlying hash rate for your configuration, but you need to consider delays associated with presenting the golden nonce, getting new data from the pool etc.  You would never be able to achieve 440MH/s in practice.
comboy
Sr. Member
****
Offline Offline

Activity: 247



View Profile
July 02, 2011, 05:01:12 PM
 #352

To me, themike5000's output looks good, I have very similar one.

I was just wondering, how can I list devices name to know what to put into mine.tcl? I see "hardware_name" in Quartus so that's not a problem, but I don't know where can I check "device_name". The first part in the device name seems to be models that Quartus are asking me too choose between when plugging the device, but what is this 0x020F70DD? I thought maybe checksum but it doesn't seem to fit. Is there any way I can list all devices in a format that I'll be able to use in this param?

Run the programfpga.bat file. It will find any attached devices and list them in that format.

I'm on linux, but yes, I found what I needed there, thanks.

Variance is a bitch!
lame.duck
Legendary
*
Offline Offline

Activity: 1242


View Profile
July 02, 2011, 05:25:35 PM
 #353

440MH/s is the raw underlying hash rate for your configuration, but you need to consider delays associated with presenting the golden nonce, getting new data from the pool etc.  You would never be able to achieve 440MH/s in practice.

Well, there would be some sort of FIFO @ the input that holds the next workload. Since with high hashing speed the performance loss will rise there could be some demand for such a solution.
themike5000
Member
**
Offline Offline

Activity: 99


View Profile
July 02, 2011, 11:10:05 PM
 #354

My linear tech chips are running very hot, especially the one circled.  Two of them are too hot to touch for longer than a second or two.  Should I try to cool it off?

The hottest one is a Linear LTM4601V.


Vertcoin: VdHjU3L2dcHCR3uQmqpM6mf4LCvp2678wh
makomk
Hero Member
*****
Offline Offline

Activity: 686


View Profile
July 02, 2011, 11:33:28 PM
 #355

My linear tech chips are running very hot, especially the one circled.  Two of them are too hot to touch for longer than a second or two.  Should I try to cool it off?

The hottest one is a Linear LTM4601V.
Hmmmm. The data sheet for that chip suggests that maximum safe case temperature is 100 degrees centrigrade and that it should probably be able to operate without forced cooling or a heatsink across the full rated amperage range at typical room temperatures, so I don't know... check the temperature and see, or just point a fan across it?

Quad XC6SLX150 Board: 860 MHash/s or so.
SIGS ABOUT BUTTERFLY LABS ARE PAID ADS
TheSeven
Hero Member
*****
Offline Offline

Activity: 504


FPGA Mining LLC


View Profile WWW
July 02, 2011, 11:50:48 PM
 #356

440MH/s is the raw underlying hash rate for your configuration, but you need to consider delays associated with presenting the golden nonce, getting new data from the pool etc.  You would never be able to achieve 440MH/s in practice.
Actually making that run at 100% efficiency is fairly trivial, and my Xilinx design is already doing it. Just upload the next work when the old one is like 80% processed, and while you upload it, the FPGA will continue to old one, and still report shares if it found them during the upload.

440MH/s? What kind of badass FPGA is that?

My tip jar: 13kwqR7B4WcSAJCYJH1eXQcxG5vVUwKAqY
themike5000
Member
**
Offline Offline

Activity: 99


View Profile
July 03, 2011, 12:26:20 AM
 #357

440MH/s is the raw underlying hash rate for your configuration, but you need to consider delays associated with presenting the golden nonce, getting new data from the pool etc.  You would never be able to achieve 440MH/s in practice.
Actually making that run at 100% efficiency is fairly trivial, and my Xilinx design is already doing it. Just upload the next work when the old one is like 80% processed, and while you upload it, the FPGA will continue to old one, and still report shares if it found them during the upload.

440MH/s? What kind of badass FPGA is that?

Can that be implemented into "FPGA Miner"'s program?  I suck at coding and would screw it up.  (I'm learning bit by bit...)

Its a Stratix IV dev board -- the GX230KF40C2 chip.  Hoping for a Stratix V board within the year... Yeah -- its not cost effective (got the Stratix IV at discount for $2k), but it is pretty slick.  I'm going to try to push it to 260MHz and 2 cores.  But yeah, wasting most of my time talking to the server and asking for blocks is killing me more than anything else.

You know of a better way to track ACTUAL mhash/sec so we can see where we need to tweak?

Vertcoin: VdHjU3L2dcHCR3uQmqpM6mf4LCvp2678wh
TheSeven
Hero Member
*****
Offline Offline

Activity: 504


FPGA Mining LLC


View Profile WWW
July 03, 2011, 12:57:32 AM
 #358

440MH/s is the raw underlying hash rate for your configuration, but you need to consider delays associated with presenting the golden nonce, getting new data from the pool etc.  You would never be able to achieve 440MH/s in practice.
Actually making that run at 100% efficiency is fairly trivial, and my Xilinx design is already doing it. Just upload the next work when the old one is like 80% processed, and while you upload it, the FPGA will continue to old one, and still report shares if it found them during the upload.

440MH/s? What kind of badass FPGA is that?

Can that be implemented into "FPGA Miner"'s program?  I suck at coding and would screw it up.  (I'm learning bit by bit...)

I would guess yes, but I'm not at all familar with all this Tcl and Altera stuff.

Its a Stratix IV dev board -- the GX230KF40C2 chip.  Hoping for a Stratix V board within the year... Yeah -- its not cost effective (got the Stratix IV at discount for $2k), but it is pretty slick.  I'm going to try to push it to 260MHz and 2 cores.  But yeah, wasting most of my time talking to the server and asking for blocks is killing me more than anything else.

Way better than mine! It costs $2k as well but only runs 1 fully-unrolled miner at 120MHz (XC5VLX110T-1)

You know of a better way to track ACTUAL mhash/sec so we can see where we need to tweak?

By calculating it, like you already did: 220MHz * 2 fully unrolled miners = 440MH/s. That's the truth. Everything else is just estimates based on the number of shares submitted, which is subject to variance/luck.

Is the FPGA wrapping around on the keyspace while it's being fed new data? If yes, you'd need to take that into account as well, by measuring the time between the work uploads.

If you care to either rewrite your FPGA design to communicate via a serial port or to write a python interface module for your FPGA's JTAG, you could use my improved python mining code, which should be able to handle 440MH/s at 100% efficiency easily.

My tip jar: 13kwqR7B4WcSAJCYJH1eXQcxG5vVUwKAqY
themike5000
Member
**
Offline Offline

Activity: 99


View Profile
July 03, 2011, 01:06:24 AM
 #359


Is the FPGA wrapping around on the keyspace while it's being fed new data? If yes, you'd need to take that into account as well, by measuring the time between the work uploads.

If you care to either rewrite your FPGA design to communicate via a serial port or to write a python interface module for your FPGA's JTAG, you could use my improved python mining code, which should be able to handle 440MH/s at 100% efficiency easily.

I'm not really qualified to do that.  I'm barely able to hang on reading instructions and switching out one or two settings.  I'm at the whims of the rest of you here, until i get a little more experience under my belt.  :-p

Vertcoin: VdHjU3L2dcHCR3uQmqpM6mf4LCvp2678wh
TheSeven
Hero Member
*****
Offline Offline

Activity: 504


FPGA Mining LLC


View Profile WWW
July 03, 2011, 12:19:22 PM
 #360


Is the FPGA wrapping around on the keyspace while it's being fed new data? If yes, you'd need to take that into account as well, by measuring the time between the work uploads.

If you care to either rewrite your FPGA design to communicate via a serial port or to write a python interface module for your FPGA's JTAG, you could use my improved python mining code, which should be able to handle 440MH/s at 100% efficiency easily.

I'm not really qualified to do that.  I'm barely able to hang on reading instructions and switching out one or two settings.  I'm at the whims of the rest of you here, until i get a little more experience under my belt.  :-p

Which version of the FPGA design are you using?
Does your board have a serial port?
I might be able to whip up something...

My tip jar: 13kwqR7B4WcSAJCYJH1eXQcxG5vVUwKAqY
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!