Topic: X6500 Custom FPGA Miner - page 42. (Read 220107 times)
with the 166mhz i'm up at 19% reject rate and i'm on btcguild, I was sub 1% at 133mhz
same here
after 6hours of running ztexmerge_166mhz i have 12% stale, with fpgaminer_133mhz i had 2-3% i dont think this is a pool issue, i am at slushs pool
i will try the 150mhz bitstream
after 6hours of running ztexmerge_166mhz i have 12% stale, with fpgaminer_133mhz i had 2-3% i dont think this is a pool issue, i am at slushs pool
i will try the 150mhz bitstream
Just got done finally setting up my "mining rig".
This way they're both in front of the highest-airflow parts of the fan. Of course I'll have to take it apart again when my better heatsinks arrive, but until then it seems to be working
Edit: Spoke too soon. The reject rate is higher, but not 20% high. More like 6-12%.
This way they're both in front of the highest-airflow parts of the fan. Of course I'll have to take it apart again when my better heatsinks arrive, but until then it seems to be working
My reject rate skyrocketed back to 10-20% using the 150mhz and 166mhz bitstreams. This happened on both of the x6500s I tried, so I'm not understanding the 1-2% reject rate I saw on the earlier post. Maybe it's pool dependent?
Same. I'm on eligius, for what it's worth.Edit: Spoke too soon. The reject rate is higher, but not 20% high. More like 6-12%.
My reject rate skyrocketed back to 10-20% using the 150mhz and 166mhz bitstreams. This happened on both of the x6500s I tried, so I'm not understanding the 1-2% reject rate I saw on the earlier post. Maybe it's pool dependent?
today i tried to get this running on OpenWRT, but there are no ftdi D2xx drivers
any plans to get this running on an non x86 system?
any plans to get this running on an non x86 system?
I like the progress I'm seeing here. keep it up!
cheers
cheers
In preparation for this, I'd like to reiterate my request for instructions on removing the stock heatsinks. I have a feeling my current cooling situation might be insufficient for running the new logic on my boards (especially the slightly anemic one we've discussed before), so I'd like to be ready to switch to something a little higher-end if needs be.
It looks to me like removing the heatsinks when hot works really well. At least it did for me. Fortunately, there's a very nice little heater right under the heatsink.
I simply ran the board for a minute without a fan, then turned it off and unplugged it. Then, the slightest twisting motion broke the heatsink free from the chip. When I say twist, I mean parallel to the board. And when I say slight, I mean slight. If you're using a lot of force, you risk pulling the FPGA off the board.On another note, are there suggestions for something to mount these FPGAs on? I just ordered another and plan on picking up a few more once the speed improvements hit. I was thinking some sort of small case with some powerful fans in it would be sweet.
I've been thinking a lot about enclosures lately. I've drawn up a few sketches of different ideas for custom enclosures, but haven't decided on what I think would be the best.
I plan to do some experiments with one idea today, which would be simpler than a custom case if it works. I ordered a standard ATX mid-tower case and I'm going to install a mini-itx motherboard and PSU in there. Then, I'll try to remove the hard drive and optical drive mounts from the front of the case. I'll do my best to fill up that empty space with as many X6500s and fans as I can. The front of the case is mesh, so fresh air will be pulled in from there and exhausted out the back or top of the case.
Looks like there's a new 166 mhash/s bitstream: http://fpgamining.com/bitstreams/
I assume it's legit?
I assume it's legit?
Yes, it's legit.
In my testing, it seems to use about a watt more than the 133 MHz (17 instead of 16), which means cooling is even more important. Keep an eye on it. I'll be posting some higher hashrates soon, but those come along with even more of a warning.By the way, I did end up getting this run in Mac OS X Lion. The PyUSB-1.6 package you posted refused to build/install with most of the Python 2.6.x versions. The only one I could get to work with was the ActiveState Python 2.6.7, but then I'd get that error when running program.py ^^. However, this morning I installed ActiveState Python 2.7.2, rebuilt/installed the PyUSB-1.6 package and everything is working perfectly.
So yeah, if you're using a Mac, try the Python 2.7.2 package from the activestate site.
So yeah, if you're using a Mac, try the Python 2.7.2 package from the activestate site.
That's great! Glad to hear you got it working, and I'll update the guide to suggest that version of Python. I simply used the pre-installed version of Python, but I'm not even sure what version that was.
By the way, I did end up getting this run in Mac OS X Lion. The PyUSB-1.6 package you posted refused to build/install with most of the Python 2.6.x versions. The only one I could get to work with was the ActiveState Python 2.6.7, but then I'd get that error when running program.py ^^. However, this morning I installed ActiveState Python 2.7.2, rebuilt/installed the PyUSB-1.6 package and everything is working perfectly.
So yeah, if you're using a Mac, try the Python 2.7.2 package from the activestate site.
So yeah, if you're using a Mac, try the Python 2.7.2 package from the activestate site.
Is it getting a lot hotter with the 166mhz bitstream?
-------------
Device: 0
Serial: AH00WOWE
JTAG chain: 2
Number of FPGAs: 2
Running time: 59m39s
Getwork interval: 20 secs
Chain 0:
Accepted: 133
Rejected: 3 (2.21%)
Invalid: 0 (0.00%)
Accepted hashrate: 159.57 MH/s
Hashrate w/ rejects: 163.16 MH/s
Hashrate w/ invalids: 163.16 MH/s
Chain 1:
Accepted: 103
Rejected: 2 (1.90%)
Invalid: 2 (1.87%)
Accepted hashrate: 123.57 MH/s
Hashrate w/ rejects: 125.97 MH/s
Hashrate w/ invalids: 128.37 MH/s
Total hashrate for device: 283.14 MH/s / 289.14 MH/s / 291.54 MH/s
Thats using the 166MHz bitstream.
Device: 0
Serial: AH00WOWE
JTAG chain: 2
Number of FPGAs: 2
Running time: 59m39s
Getwork interval: 20 secs
Chain 0:
Accepted: 133
Rejected: 3 (2.21%)
Invalid: 0 (0.00%)
Accepted hashrate: 159.57 MH/s
Hashrate w/ rejects: 163.16 MH/s
Hashrate w/ invalids: 163.16 MH/s
Chain 1:
Accepted: 103
Rejected: 2 (1.90%)
Invalid: 2 (1.87%)
Accepted hashrate: 123.57 MH/s
Hashrate w/ rejects: 125.97 MH/s
Hashrate w/ invalids: 128.37 MH/s
Total hashrate for device: 283.14 MH/s / 289.14 MH/s / 291.54 MH/s
Thats using the 166MHz bitstream.
Looks like there's a new 166 mhash/s bitstream: http://fpgamining.com/bitstreams/
I assume it's legit?
I assume it's legit?
Running Python 2.6.7, using the D2XX 1.04 drivers and the PyUSB-0.6 from fpamining.com . I've tried messing around with different versions but nothing I do will get it to work in Lion. Works beautifully in Win7 though.
Any other suggestions? Thanks for the help.
Any other suggestions? Thanks for the help.
Sorry if this is a stupid question, but you used the Mac version of PyUSB, right? http://fpgamining.com/software/PyUSB-1.6-fizzisist-mac.tar.gz
Other than that, I'm really not sure what could be wrong. It might be helpful to go through and clear out all of the old D2XX stuff in case something is hanging around. First, do the reverse of the installation process you followed in the FTDI D2XX readme file. Then, remove PyUSB by removing the d2xx folder in /Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/. Maybe something is lingering around from one of the other versions and mucking things up.
Yes, I've been using the Mac version you posted. I was able to replicate the exact error I posted above on a 2nd Mac, so it isn't something weird with my Macbook. I'll try going through and manually removing all the old D2XX stuff tonight, didn't remove anything from the site-packages folder when reinstalled PyUSB last time (I'm assuming it needs to be reinstalled with each D2XX change?).
On another note, are there suggestions for something to mount these FPGAs on? I just ordered another and plan on picking up a few more once the speed improvements hit. I was thinking some sort of small case with some powerful fans in it would be sweet.
Thanks again for all of the help/advice!
I'll be posting some pre-built bitstreams very soon, but everyone should be even more careful to monitor their cooling using these higher clocks because the potential to burn out your FPGA is much higher. Also, in my limited tests I've seen that the error rates vary from FPGA to FPGA so you'll have to experiment with your setup to see what works well for you. I've seen some FPGAs tolerate 180 MHz no problem, but others report over 10% errors at that clock rate.
In preparation for this, I'd like to reiterate my request for instructions on removing the stock heatsinks. I have a feeling my current cooling situation might be insufficient for running the new logic on my boards (especially the slightly anemic one we've discussed before), so I'd like to be ready to switch to something a little higher-end if needs be.Thanks for the reminder and sorry for not testing this out already! I'll do some experiments tonight!
I'll be posting some pre-built bitstreams very soon, but everyone should be even more careful to monitor their cooling using these higher clocks because the potential to burn out your FPGA is much higher. Also, in my limited tests I've seen that the error rates vary from FPGA to FPGA so you'll have to experiment with your setup to see what works well for you. I've seen some FPGAs tolerate 180 MHz no problem, but others report over 10% errors at that clock rate.
In preparation for this, I'd like to reiterate my request for instructions on removing the stock heatsinks. I have a feeling my current cooling situation might be insufficient for running the new logic on my boards (especially the slightly anemic one we've discussed before), so I'd like to be ready to switch to something a little higher-end if needs be.
FPGAMiner pushed a new project to the Open Source FPGA Bitcoin Miner Github repository called X5000_ztexmerge. This is the new firmware capable of achieving much higher hashrates because he ported over ztex's very fast hashers to our platform. Thanks for open sourcing that, ztex!
I'll be posting some pre-built bitstreams very soon, but everyone should be even more careful to monitor their cooling using these higher clocks because the potential to burn out your FPGA is much higher. Also, in my limited tests I've seen that the error rates vary from FPGA to FPGA so you'll have to experiment with your setup to see what works well for you. I've seen some FPGAs tolerate 180 MHz no problem, but others report over 10% errors at that clock rate.
I'll be posting some pre-built bitstreams very soon, but everyone should be even more careful to monitor their cooling using these higher clocks because the potential to burn out your FPGA is much higher. Also, in my limited tests I've seen that the error rates vary from FPGA to FPGA so you'll have to experiment with your setup to see what works well for you. I've seen some FPGAs tolerate 180 MHz no problem, but others report over 10% errors at that clock rate.
Running Python 2.6.7, using the D2XX 1.04 drivers and the PyUSB-0.6 from fpamining.com . I've tried messing around with different versions but nothing I do will get it to work in Lion. Works beautifully in Win7 though.
Any other suggestions? Thanks for the help.
Any other suggestions? Thanks for the help.
Sorry if this is a stupid question, but you used the Mac version of PyUSB, right? http://fpgamining.com/software/PyUSB-1.6-fizzisist-mac.tar.gz
Other than that, I'm really not sure what could be wrong. It might be helpful to go through and clear out all of the old D2XX stuff in case something is hanging around. First, do the reverse of the installation process you followed in the FTDI D2XX readme file. Then, remove PyUSB by removing the d2xx folder in /Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/. Maybe something is lingering around from one of the other versions and mucking things up.
Another user had this problem on Linux, and it turned out it was because he used the new D2XX drivers that came out on 12/23. I haven't had a chance to hack PyUSB to work with that, so please try it with 1.0.4 (download here). Please let us know if that works for you!
Tried this, now I'm getting a different error:
Code:
Traceback (most recent call last):
File "program.py", line 23, in
from ft232r import FT232R, FT232R_PortList
File "/Users/christian/x6500/ft232r.py", line 22, in
import d2xx
File "/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/d2xx/__init__.py", line 24, in
from _d2xx import *
ImportError: dlopen(/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/d2xx/_d2xx.so, 2): Symbol not found: _FT_Close
Referenced from: /Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/d2xx/_d2xx.so
Expected in: dynamic lookup
imac:x6500 chris$ python2.6 --version
Python 2.6.7
Running Python 2.6.7, using the D2XX 1.04 drivers and the PyUSB-0.6 from fpamining.com . I've tried messing around with different versions but nothing I do will get it to work in Lion. Works beautifully in Win7 though.
Any other suggestions? Thanks for the help.
Pre-fix was getting 20% avg rejects. Now I'm down to under 3%.
I'm pulling a consistent 260 mh/s with and average of 0.9% reject
I'm seeing rejects between 1% and 4%, with hash rates of around 250 MH/s.
Jump to: