X6500 Custom FPGA Miner

[allinvain]

Nah, 166 is perfectly safe. The Ztex board for example is running at 200MHz.  Just a matter f optimizing the board to help draw heat off the chip and top cooling.
The 3 ring core right now is being designed at 161MHz. But thats (161*3)*.5 = 241.5MHs   It is not a certain thing though and still has a ways to go in dev and testing.

Nice - 241 MHs per core would be really sweet. For me at least that means I can replace a 5870 (overclocked modestly to 900 MHz) with one of these boards

I'm fairly doubtful that code is going to get released— he was looking for investors, presumably to fund a private farm with that design. So unless you're planning on duplicating the work yourself (with substantial effort since he appeared to be carefully non-specific about the solutions to the problems he's encountered) don't be counting on running anything based on a three ring design anytime soon.

That may be the case, but there is always the hope that someone else will come up with the same design but who would be willing to share it . As they say, hope dies last.

 

[1714192790]

1714192790

[1714192790]

1714192790

[1714192790]

1714192790

[1714192790]

1714192790

[1714192790]

1714192790

[shad]

I grabbed the latest from github and tried to preprocess the new bitstreams, but I couldn't because I get a divide by zero error where it tries to calculate the speed somewhere.

had this one to, but at the second try with the same version it worked 

[thirdlight]

Same for me - first try failed, divide by zero. Re-run the command (no changes) & it worked.

~300MH/s, ~2% reject 

[tf101]

Hey guys, current stats using a 15sec getwork:

294.80 MH/s | 0: 3038/64/4 2.1% | 1: 2973/70/28 2.3% | 1d1h12m

[shad]

2012-01-10 09:00:14 | (FPGA1) accepted 9adb994fL
2012-01-10 09:00:18 | (FPGA0) Job data loaded
2012-01-10 09:00:22 | (FPGA1) Job data loaded
2012-01-10 09:00:22 | (FPGA1) Golden nonce found
2012-01-10 09:00:22 | (FPGA1) accepted e5d899c0L
2012-01-10 09:02:58 | Long-poll: new block 000008b08c3e99ff
0 kH/s | 0: 3178/72/0 2.2% | 1: 3139/72/0 2.2% | 1d10h24m

sad day today, 8,5 hours of doing nothing
i had no internet access at work today so i couldn't check it
is there anything you a working on to get this fixed?
this is the first time i have this problem since i installed v0.2
if not i will try this weekend to merge the program.py and mine.py to autoreprogram it if drops from >0 to 0, but i would like to use the standard client
am i the only one having this problem?

[fizzisist]

2012-01-10 09:00:14 | (FPGA1) accepted 9adb994fL
2012-01-10 09:00:18 | (FPGA0) Job data loaded
2012-01-10 09:00:22 | (FPGA1) Job data loaded
2012-01-10 09:00:22 | (FPGA1) Golden nonce found
2012-01-10 09:00:22 | (FPGA1) accepted e5d899c0L
2012-01-10 09:02:58 | Long-poll: new block 000008b08c3e99ff
0 kH/s | 0: 3178/72/0 2.2% | 1: 3139/72/0 2.2% | 1d10h24m

sad day today, 8,5 hours of doing nothing
i had no internet access at work today so i couldn't check it
is there anything you a working on to get this fixed?
this is the first time i have this problem since i installed v0.2
if not i will try this weekend to merge the program.py and mine.py to autoreprogram it if drops from >0 to 0, but i would like to use the standard client
am i the only one having this problem?

Oh no! I'm confused about what exactly happened, though... That long-poll came in, and then it just stopped? No exception or anything? Did you actually need to reprogram to bring it back to life or would restarting mine.py fix it?

The problem isn't popping out at me, but asking the software to keep an eye on the hashrate is definitely a good idea. Currently that average is based on the last 3 hours of work, so it would take 3 hours to restart. Maybe restart if the rate drops to half? I'll do some thinking about this. Other ideas are certainly welcome!

Thanks for reporting the bug, shad! Sorry it gave you such trouble!

[shad]

i reported that one first on: December 21, 2011, 08:06:26 AM
there was no LP support in the old version so i am not really sure if this has to do with LP
there is no exeption or enything else, i am a coder, i would have postet that and the script is running because it calculates the hashrate

i think we "talked" about this. maybe program-loss because of voltage drop or something, dont know the stats of the powersupply, but is from a NAS for 2 3.5" drive
also i noticed that i used 7Watt's more than usually while mining
i am not 100% sure if i have to reprogram it, because i use my amazing mine.bat which runs program & mine, i will check that if it happens again
anyone else having this problem?

[sirky]

I have had something like this happen as well. When it does the only way I can clear the screen is to unplug the USB cable to the miner. It just hangs indefinitely, even if I press ctrl+c, or even try to force quit cmd or python.

I suspect it might be a power fluctuation thing as well.

[freshzive]

I had that happen once as well, where the script was still running but it was just sitting there at 0mhash overnight. I was able to kill it with ctrl+c and simply restart mine.py to get it going again though. I feel like it may have something to do with power as well--my x6500s are running on barrel connectors.

It would be nice if you could add some code to the script so it automatically restarts if it drops below 100mhash.

[fizzisist]

Ok, I remember that post now, shad, but I thought it was fixed with the update shortly after that.

It seems like sirky's problem is a bit different. Maybe bad USB connectivity? Then again, if I completely pull the USB cable, I just get an IOError and it crashes the program. If I remove power to the FPGAs, the program keeps going but also keeps printing out "Job data loaded." It just doesn't know that those jobs are going nowhere because there's no acknowledgement from the FPGA that a new job was loaded. The only communication from the FPGA during mining is when it reports a nonce. If you lose power, it should just stop reporting nonces.

I have an idea for a simple watchdog, but not knowing the source of the problem it's hard to say if that watchdog would still be awake when the problem happens. In sirky's case it most definitely wouldn't. A watchdog feels like a hack-y workaround, anyway, so I'd really like to just understand what's going.

Would one of you guys be willing to run a version of the code with a lot of debug statements added? If so, I'll prepare something that might help us get to the bottom of these bugs. Thanks!

[shad]

i run what you want
this problem didn't come for 2 weeks now, so i thougt it was fixed by the new version do to cleanup of something

i thought of implementing massiv debug msg's my self, but the problem here is that if i don't recognize it for 8 hours i may not be able to scroll up so much, so we need a logfile, i have 15gigabyte space for them

also debug msg's from you would be better, you know the code and i have no experience with python

[sirky]

I have not had the problem for a long time either.

It was a few weeks ago for me as well. USB connectivity could also be the culprit.

I will let you know ASAP if it ever happens again.

[freshzive]

Hmmm. Ordered 2 more of these the other day and just noticed I got an e-mail that there's a delay in shipping them as Cablesaurus is out of stock. Currently the website says in stock: 20...so that must be incorrect?

Not a big deal, just thought maybe the site should be updated to show real stock levels.

Code:

Running time: 20h44m
Getwork interval: 15 secs
Chain 0:
  Accepted: 2475
  Rejected: 54 (2.14%)
  Invalid: 4 (0.16%)
  Accepted hashrate: 142.36 MH/s
  Hashrate w/ rejects: 145.47 MH/s
Chain 1:
  Accepted: 2582
  Rejected: 70 (2.64%)
  Invalid: 0 (0.00%)
  Accepted hashrate: 148.51 MH/s
  Hashrate w/ rejects: 152.54 MH/s
Total hashrate for device: 290.88 MH/s / 298.01 MH/s

166Mhz bitstreams are looking mighty stable   Bought a set of these and they seem powerful enough to keep my babies cool  (and almost totally silent):
http://www.amazon.com/Coolerguys-Dual-80mm-Cooling-Fans/dp/B002NVC1DS/ref=sr_1_3?s=electronics&ie=UTF8&qid=1326248829&sr=1-3

[thirdlight]

Would one of you guys be willing to run a version of the code with a lot of debug statements added? If so, I'll prepare something that might help us get to the bottom of these bugs. Thanks!

I'd be happy to. I seem to be getting this issue at least once a day (I have several boards!) so should be able to report back quickly.

[freshzive]

Anyone had any issues with slowdown using USB hubs? I purchased one of these: http://www.amazon.com/gp/product/B00483WRZ6/ref=oh_o01_s00_i01_details and after 12 hours of running, my hashrate on all of my FPGAs has dropped by about 20-30mhash. From the specs, I can't figure out why that would be.

Waste of $$

[allinvain]

Anyone had any issues with slowdown using USB hubs? I purchased one of these: http://www.amazon.com/gp/product/B00483WRZ6/ref=oh_o01_s00_i01_details and after 12 hours of running, my hashrate on all of my FPGAs has dropped by about 20-30mhash. From the specs, I can't figure out why that would be.

Waste of $$

I wonder if the same thing could happen with the 10 port usb hub cablesaurus sells. Anyone using those?

[coblee]

I use one of these: http://www.amazon.com/Macally-Mini-4-Port-Adapter-TriHub4/dp/B001DBF07I/ref=sr_1_2?s=electronics&ie=UTF8&qid=1326302935&sr=1-2
And my hashrate is between 260-270 for the 166MHz bitstream. So it may be the usb hub. I will try not using a hub.
But then again it could be because I'm on a Mac.

[shad]

Anyone had any issues with slowdown using USB hubs? I purchased one of these: http://www.amazon.com/gp/product/B00483WRZ6/ref=oh_o01_s00_i01_details and after 12 hours of running, my hashrate on all of my FPGAs has dropped by about 20-30mhash. From the specs, I can't figure out why that would be.

Waste of $$

how long does it take to load the FPGA?
2012-01-11 19:59:46 | (FPGA0) Job data loaded in 0.079 seconds
2012-01-11 19:59:48 | (FPGA1) Job data loaded in 0.110 seconds
2012-01-11 19:59:59 | (FPGA1) Job data loaded in 0.078 seconds
2012-01-11 20:00:01 | (FPGA0) Job data loaded in 0.063 seconds
2012-01-11 20:00:14 | (FPGA0) Job data loaded in 0.109 seconds
2012-01-11 20:00:15 | (FPGA1) Job data loaded in 0.110 seconds

i activated line 195, 204, 225 (https://github.com/fizzisist/x6500-miner/blob/master/mine.py)

nice debug code

[freshzive]

I use one of these: http://www.amazon.com/Macally-Mini-4-Port-Adapter-TriHub4/dp/B001DBF07I/ref=sr_1_2?s=electronics&ie=UTF8&qid=1326302935&sr=1-2
And my hashrate is between 260-270 for the 166MHz bitstream. So it may be the usb hub. I will try not using a hub.
But then again it could be because I'm on a Mac.

It might be the hub. I can get 290-300mhash on my iMac, but switching to the hub dropped it to 260-270.

how long does it take to load the FPGA?
2012-01-11 19:59:46 | (FPGA0) Job data loaded in 0.079 seconds
2012-01-11 19:59:48 | (FPGA1) Job data loaded in 0.110 seconds
2012-01-11 19:59:59 | (FPGA1) Job data loaded in 0.078 seconds
2012-01-11 20:00:01 | (FPGA0) Job data loaded in 0.063 seconds
2012-01-11 20:00:14 | (FPGA0) Job data loaded in 0.109 seconds
2012-01-11 20:00:15 | (FPGA1) Job data loaded in 0.110 seconds

i activated line 195, 204, 225 (https://github.com/fizzisist/x6500-miner/blob/master/mine.py)

nice debug code

Will try this using my hub when I get home.

[fizzisist]

It might be the hub. I can get 290-300mhash on my iMac, but switching to the hub dropped it to 260-270.

I think I found a reason for slowed down USB communication when running with many boards. I pushed an update to Github, and in my own testing it seems to have helped. Please let me know how it works for you.

Would one of you guys be willing to run a version of the code with a lot of debug statements added? If so, I'll prepare something that might help us get to the bottom of these bugs. Thanks!

I'd be happy to. I seem to be getting this issue at least once a day (I have several boards!) so should be able to report back quickly.

Wow, is it really that bad?! I'll get something ready for you and either PM it to you or create a branch on Github. I think we will need to log these extra messages to file, as shad suggested, so I'll be adding file logging in addition to the logging to the terminal (you don't want to pipe the regular output to a file because you'll have all that status update line in there many times, I think).

Hmmm. Ordered 2 more of these the other day and just noticed I got an e-mail that there's a delay in shipping them as Cablesaurus is out of stock. Currently the website says in stock: 20...so that must be incorrect?

Not a big deal, just thought maybe the site should be updated to show real stock levels.

Sorry about that freshzive. Our arrangement with Cablesaurus has been to keep him supplied with a steady stream of boards. Unfortunately (or fortunately, depending on your point of view), that stream wasn't enough to keep up with the demand in the past week! He should be receiving the latest shipment today and getting them out to you guys ASAP. Hopefully we keep up with demand from now on, but we're going to have to do another manufacturing run very soon. If the order pace keeps up, there will be a lag while we wait a couple weeks to get those.