X6500 Custom FPGA Miner - page 37. | Bitcointalksearch.org

fizzisist

hero member

Activity: 720

Merit: 528

Quote from: freshzive on January 16, 2012, 07:42:41 PM

so stable, loving it Cheesy

325.47 MH/s | 0: 12498/58/68 0.5%/0.5% | 1: 12523/65/76 0.5%/0.6% | 3d21h2m | AH00WOWI

That is a beautiful status line!

Quote from: c_k on January 16, 2012, 03:21:19 PM

Looking at the picture of the X6500 without heatsinks on Cablesaurus.com, it appears there is no mounting holes for a heatsink/fan combo - can we only use adhesive tape to attach them?

For the stock heatsinks, we are using thermal tape. Mounting holes would have been nice, though. If you really want them, you might be able to build something that could use the existing mount holes. I'm not sure exactly how that would work out.

If you're really wanting the one with installed heatsinks, Cablesaurus will have them in stock again in a few days. Sorry, but we got a little backlogged!

99Percent

full member

Activity: 411

Merit: 101

🦜| Save Smart & Win 🦜

I am interested in trying out these boards but I noticed the ones with heat sinks are sold out.

Any suggestions on how to get these heatsinks separately?

It would be cool if these boards had the holes for mounting chipset cooling systems like the ones the LX-150 board has (https://bitcointalksearch.org/topic/minimalist-spartan6-lx150-board-45532). That way I might even try a water cooling system chaining the blocks of several X6500 boards to a pump.

freshzive

sr. member

Activity: 447

Merit: 250

so stable, loving it Cheesy

325.47 MH/s | 0: 12498/58/68 0.5%/0.5% | 1: 12523/65/76 0.5%/0.6% | 3d21h2m | AH00WOWI

c_k

donator

Activity: 242

Merit: 100

Looking at the picture of the X6500 without heatsinks on Cablesaurus.com, it appears there is no mounting holes for a heatsink/fan combo - can we only use adhesive tape to attach them?

thirdlight

sr. member

Activity: 445

Merit: 250

I've put one board on this version (running 12 hours now)- the rest (around 32 hours run) are on yesterday's git version.

Realy stable! I would have more on the latest version, but, apart from one to test, I only change them over when they stall, and they haven't!

Getting around 340 MH/s & less than 1% rejects.

I think you've cracked it! Thanks fizzisist & shad.

Grin

fizzisist

hero member

Activity: 720

Merit: 528

Quote from: O_Shovah on January 15, 2012, 05:43:57 PM

I dont have the time to look into the code for that error.
I hope it helps some more familiar with it.

Thanks for catching that, O_Shovah! It turns out that I forgot to test it without the 'verbose' option and screwed something up there. Should be fixed now!

O_Shovah

sr. member

Activity: 410

Merit: 252

Watercooling the world of mining

Hello I'm curently trying on the new code.

Code:

2012-01-15 23:33:54 | Device 0 opened (AH00WQ10)
2012-01-15 23:33:54 | Connected to 2 FPGAs
2012-01-15 23:33:54 | Connected to server
2012-01-15 23:33:54 | 0: Error getting work! Retrying...
Exception in thread Thread-1:
Traceback (most recent call last):
  File "C:\Python26\lib\threading.py", line 534, in __bootstrap_inner
    self.run()
  File "C:\Python26\lib\threading.py", line 486, in run
    self.__target(*self.__args, **self.__kwargs)
  File "C:\Users\O_Shovah\Desktop\FPGA_x6500\fizzisist_x6500_miner_0.2.8\rpcClie
nt.py", line 208, in getwork_loop
    self.getNewJob(fpga)
  File "C:\Users\O_Shovah\Desktop\FPGA_x6500\fizzisist_x6500_miner_0.2.8\rpcClie
nt.py", line 174, in getNewJob
    self.logger.log("%d: Error getting work! Retrying..." % fpga.id)
  File "C:\Users\O_Shovah\Desktop\FPGA_x6500\fizzisist_x6500_miner_0.2.8\Console
Logger.py", line 352, in log
    self.updateStatus(True)
  File "C:\Users\O_Shovah\Desktop\FPGA_x6500\fizzisist_x6500_miner_0.2.8\Console
Logger.py", line 283, in updateStatus
    acc = sum([fpga.accepted_count for fpga in fpga_list])
NameError: global name 'fpga_list' is not defined

Traceback (most recent call last):
  File "C:\Users\O_Shovah\Desktop\FPGA_x6500\fizzisist_x6500_miner_0.2.8\mine.py
", line 204, in 
    logger.updateStatus()
  File "C:\Users\O_Shovah\Desktop\FPGA_x6500\fizzisist_x6500_miner_0.2.8\Console
Logger.py", line 283, in updateStatus
    acc = sum([fpga.accepted_count for fpga in fpga_list])
NameError: global name 'fpga_list' is not defined

I dont have the time to look into the code for that error.
I hope it helps some more familiar with it.

fizzisist

hero member

Activity: 720

Merit: 528

Quote from: shad on January 15, 2012, 09:02:23 AM

Quote from: fizzisist on January 15, 2012, 07:58:24 AM

I think you're right. I probably threw out the baby with the bath water. To let you know, I just did a big reorganization that brings us a lot closer to multi-board support. It involved creating an FPGA class, which will moves of the FPGA communication out of mine.py and makes it much more modular, (instead of chain_list, we now have fpga_list, which can be iterated over and

yeah, i planed to make chain_list_per_board, as i want a thread per board, to get max usage of the weakest link which is the ft232, i was a little shocked about the much changes you made, i did my changes all in mine.py, so now my mine.py is a little incompatible, i wait until your next update
i think we agree with the way we want to go

Ok, then you are going to be even more shocked by the latest changes (pushed to Github minutes ago). Sorry to break your changes.

The changes are drastic, but I think necessary to keep everything organized as the code grows. This is an incremental step towards multi-board support, but it lays a lot of groundwork. Please check it out!

Quote from: shad on January 15, 2012, 09:02:23 AM

i made one, i now have to understand it, hoping there is something out there like TortoiseSVN

I typically just use the git command line tool in linux, but have used it on Windows as well. There's a git GUI, which should get it closer to TortoiseSVN, although I haven't used it. Check out the Windows help on Github which looks very helpful.

shad

full member

Activity: 148

Merit: 100

Quote from: fizzisist on January 15, 2012, 07:58:24 AM

I think you're right. I probably threw out the baby with the bath water. To let you know, I just did a big reorganization that brings us a lot closer to multi-board support. It involved creating an FPGA class, which will moves of the FPGA communication out of mine.py and makes it much more modular, (instead of chain_list, we now have fpga_list, which can be iterated over and

yeah, i planed to make chain_list_per_board, as i want a thread per board, to get max usage of the weakest link which is the ft232, i was a little shocked about the much changes you made, i did my changes all in mine.py, so now my mine.py is a little incompatible, i wait until your next update
i think we agree with the way we want to go

Quote from: fizzisist on January 15, 2012, 07:58:24 AM

Quote from: shad on January 14, 2012, 10:30:47 AM

maybe i should think about getting an github account so we could work together and not always working on the same idea in parallel

Please do!

i made one, i now have to understand it, hoping there is something out there like TortoiseSVN

fizzisist

hero member

Activity: 720

Merit: 528

Quote from: shad on January 15, 2012, 04:41:17 AM

i am looking at commit a312423 and i think there is a better solution
you have now a loop with: updateStatus()=>com with fpga0=>com with fpga1
the problem is that updatestatus blocks the comunication, an i guess we will put some more stuff into updateStatus if we make multi card support

i think the minethread was a good idea, but only 1 minethread per board with "com with fpga0=>com with fpga1"

I think you're right. I probably threw out the baby with the bath water. To let you know, I just did a big reorganization that brings us a lot closer to multi-board support. It involved creating an FPGA class, which will moves of the FPGA communication out of mine.py and makes it much more modular, (instead of chain_list, we now have fpga_list, which can be iterated over and

I'm going to let it run while I sleep now, and if it looks hasn't crashed when I wake up I push it to Github then.

Quote from: shad on January 14, 2012, 10:30:47 AM

maybe i should think about getting an github account so we could work together and not always working on the same idea in parallel

Please do!

thirdlight

sr. member

Activity: 445

Merit: 250

Quote from: fizzisist on January 14, 2012, 07:15:03 PM

Thirdlight, would you mind testing it then?

Always happy to test - if I could do more, I would!

1 board running on current git code, I'll swap more over later.

Thanks for your work on this.

shad

full member

Activity: 148

Merit: 100

i am looking at commit a312423 and i think there is a better solution
you have now a loop with: updateStatus()=>com with fpga0=>com with fpga1
the problem is that updatestatus blocks the comunication, an i guess we will put some more stuff into updateStatus if we make multi card support

i think the minethread was a good idea, but only 1 minethread per board with "com with fpga0=>com with fpga1"

Quote

   # impleent for card in number of cards
      # Start mining thread(s)
      minethread = Thread(target=mineloop, args=(chain_list,)) <== 2do chanlist per card? + ft232-interface
      minethread.daemon = True
      minethread.start()

      while True:
         time.sleep(1)
         logger.updateStatus()
         # TODO: implement a watchdog for the getwork thread
         if minethread is None or not minethread.isAlive():
            logger.log("Restarting minethread")
            minethread = Thread(target=mineloop, args=(chain_list,))
            minethread.daemon = True
            minethread.start()

fizzisist

hero member

Activity: 720

Merit: 528

I pushed some changes to Github, including the timeout on read_data() that shad suggested. Hopefully this helps with the lock-up problem, but I've never had that happen to me so I need you guys to test it. Thanks!

Quote from: freshzive on January 14, 2012, 08:33:14 PM

Thanks for the info..going to try getting the mining-proxy setup on my Mac. It doesn't look like this provides alerts for down miners though?

The proxy is nice, but I think the combination with munin is the real win. Here's a screenshot of the FPGA.contract worker graph:

It should be possible to implement an interface compatible with munin without mining-proxy, directly in x6500-miner. I'll think about how to do this in a simple way.

Also, munin has the capability to send notifications based on some kind of threshold. I haven't set that up myself, but it would probably be a good idea.

freshzive

sr. member

Activity: 447

Merit: 250

Quote from: fizzisist on January 14, 2012, 07:39:03 PM

Here's how I run a bunch of boards (12 at the moment). All of the mine.py instances are running within a gnu screen session. I'm using bitcoin-mining-proxy, and I have a munin plugin that queries the MySQL database for the proxy to make some nice graphs. This seems to work pretty well for me, but I would certainly like to cut down on the number of mine.py instances running.

Thanks for the info..going to try getting the mining-proxy setup on my Mac. It doesn't look like this provides alerts for down miners though?

2 more FPGAs in the mail today, now 4 running stably at 166mhz

fizzisist

hero member

Activity: 720

Merit: 528

Quote from: O_Shovah on January 13, 2012, 12:11:04 PM

Maybe just to remind it.

Please add a link to the executable of python 2.6.7 for the Windows users

http://www.activestate.com/activepython/downloads

Thanks

Thanks for the reminder, O_Shovah! Link added.

Quote from: freshzive on January 14, 2012, 12:04:33 PM

Are there plans to mine from multiple FPGAs using one mine.py script? Or is that not feasible? Setting up two more boards today and I feel like monitoring 4 terminal tabs is a little silly (and going to get more complex with larger farms).

Or maybe a simple script that could output speeds from multiple FPGAs at once (so they could all just be run in screens)? fizzisist how are you monitoring your farm?

Yes, that's exactly the idea. In theory, this is pretty simple. The reality, though, is that presenting all of the information for that many FPGAs is tricky. Also, it would be best if you could reprogram the FPGAs from within that program, so you don't have to restart the whole thing every time you add a board. I'll be working on this.

Here's how I run a bunch of boards (12 at the moment). All of the mine.py instances are running within a gnu screen session. I'm using bitcoin-mining-proxy, and I have a munin plugin that queries the MySQL database for the proxy to make some nice graphs. This seems to work pretty well for me, but I would certainly like to cut down on the number of mine.py instances running.

fizzisist

hero member

Activity: 720

Merit: 528

Quote from: shad on January 14, 2012, 03:19:10 PM

so you should switch to the version which is better running for you, but i think there isn't much a differenc in stability
is your Operation System on high CPU load when this happens?

we should try to fix it by adding the "# TODO: Add a timeout" to restart comunication

Quote

if starttime - time() > timeout then
"send an error and jump back to a point with save data"

but this doesn't change my POV that the seriell calling is better then the threads

Yep, I think this is exactly the right idea. The thread locks might not have been to blame, but it really makes things easier to do without them. I'll add in that timeout now, test it out briefly, and push it to github. Thirdlight, would you mind testing it then? I'll send you a PM when it's ready. Thanks!

thirdlight

sr. member

Activity: 445

Merit: 250

Thanks shad.

I think you're right & there is little difference in stability.

The machine is a 1.6GHz atom, but ticks along at about 20% cpu use. OS is XP home.

shad

full member

Activity: 148

Merit: 100

so you should switch to the version which is better running for you, but i think there isn't much a differenc in stability
is your Operation System on high CPU load when this happens?

we should try to fix it by adding the "# TODO: Add a timeout" to restart comunication

Quote

if starttime - time() > timeout then
"send an error and jump back to a point with save data"

but this doesn't change my POV that the seriell calling is better then the threads

thirdlight

sr. member

Activity: 445

Merit: 250

Stalled board running shad's mine.py:

Code:

2012-01-14 13:56:32 | (FPGA0) accepted 16602082L
2012-01-14 13:56:38 | (FPGA0) jobqueue loaded (1)
2012-01-14 13:56:38 | (FPGA0) Job data loaded
2012-01-14 13:56:38 | (FPGA1) jobqueue loaded (1)
2012-01-14 13:56:38 | (FPGA1) Job data loaded
2012-01-14 13:56:53 | (FPGA1) Golden nonce found
2012-01-14 13:56:53 | (FPGA1) accepted efdfb562L
2012-01-14 13:56:58 | (FPGA0) jobqueue loaded (1)
2012-01-14 13:56:58 | (FPGA0) Job data loaded
2012-01-14 13:56:58 | (FPGA1) jobqueue loaded (1)
2012-01-14 13:56:59 | (FPGA1) Job data loaded
2012-01-14 13:57:18 | (FPGA0) jobqueue loaded (1)
2012-01-14 13:57:19 | (FPGA1) jobqueue loaded (1)
2012-01-14 13:57:25 | Long-poll: new block 00000736dd68b0e6
2012-01-14 13:57:25 | (FPGA0) jobqueue loaded (1)
2012-01-14 13:57:25 | (FPGA1) jobqueue loaded (1)
2012-01-14 13:58:28 | Long-poll: new block 00000736dd68b0e6
2012-01-14 13:58:28 | (FPGA0) jobqueue loaded (1)
2012-01-14 18:19:01 | Exiting...
Run Summary:
E-xception in thread Thread-3:
Traceback (most recent call last):
  File "c:\python267\lib\threading.py", line 534, in __bootstrap_inner
    self.run()
  File "c:\python267\lib\threading.py", line 486, in run
    self.__target(*self.__args, **self.__kwargs)
  File "mine2.py", line 276, in mineloop
    nonce[chain] = fpgaReadNonce(jtag[chain])
  File "mine2.py", line 129, in fpgaReadNonce
    byte = fpgaReadByte(jtag)
  File "mine2.py", line 115, in fpgaReadByte
    byte = bits2int(jtag.read_dr(bits))
  File "C:\x6500\xx\jtag.py", line 159, in read_dr
    return self.shift_dr(bits, read=True)
  File "C:\x6500\xx\jtag.py", line 156, in shift_dr
    return self.read_tdo(len(bits)+self._tckcount)[:len(bits)-self.current_part]

  File "C:\x6500\xx\jtag.py", line 163, in read_tdo
    data = self.ft232r.read_data(num)
  File "C:\x6500\xx\ft232r.py", line 246, in read_data
    while self.handle.getQueueStatus() < wrote:
AttributeError: 'NoneType' object has no attribute 'getQueueStatus'

------------
Device: 1
Serial: AH00WIBS
JTAG chain: 2
Number of FPGAs: 2
Running time: 4h52m
Getwork interval: 20 secs
FPGA 0:
  Accepted: 70
  Rejected: 0 (0.00%)
  Invalid: 0 (0.00%)
  Hashrate (all nonces): 17.15 MH/s
  Hashrate (valid nonces): 17.15 MH/s
  Hashrate (accepted shares): 17.15 MH/s
FPGA 1:
  Accepted: 70
  Rejected: 0 (0.00%)
  Invalid: 0 (0.00%)
  Hashrate (all nonces): 17.15 MH/s
  Hashrate (valid nonces): 17.15 MH/s
  Hashrate (accepted shares): 17.15 MH/s
Total hashrate for device: 34.30 MH/s / 34.30 MH/s / 34.30 MH/s

Seconding appreciation to fizzisist & shad. Clever stuff!

freshzive

sr. member

Activity: 447

Merit: 250

Haven't touched mine and they're still running stably

Thanks for all the hard work fizzisist & shad, much appreciated.

320.75 MH/s | 0: 4922/19/28 0.4%/0.6% | 1: 5033/27/23 0.5%/0.5% | 1d13h17m | AH00WOWI
314.68 MH/s | 0: 4988/22/33 0.4%/0.7% | 1: 5048/29/22 0.6%/0.4% | 1d13h17m | AH00WOVL

Are there plans to mine from multiple FPGAs using one mine.py script? Or is that not feasible? Setting up two more boards today and I feel like monitoring 4 terminal tabs is a little silly (and going to get more complex with larger farms).

Or maybe a simple script that could output speeds from multiple FPGAs at once (so they could all just be run in screens)? fizzisist how are you monitoring your farm?

Topic: X6500 Custom FPGA Miner - page 37. (Read 220107 times)