That's bad, I wonder what went wrong as they test them before shipping. Have you tried swapping power supply / USB cable ?

There business model is to intentionally lie about order guarantee dates. They are clearly aware, that no orders are being filled in 4-6 weeks. Even if you email them after there guaranteed time has past, they just give another bogus deadline. After that deadline is up, email them again. They give you another unrealistic delivery date. Seems like they have politicians setting up the business model down there.. No one is expecting miracles, a little honesty would be nice though.

Out of curiosity what is the absolute highest hashrate you've gotten out of these units?

Now if someone was to build a waterblock for the babies we could push them to the edge

I can't find my units using easyminer :/ tried several cables and ports while connecting to a desktop (win7) or a laptop (xp)

I installed EasyMiner.  It shows my units just fine, but only allows me to select the 3rd option on the menu (the diagnostics/testing/statistics option, forgot what it was called).  The other two options are grayed out.  So, I can see the units, but I can't mine with them using EasyMiner.  Any suggestions?

Passwords are security through obscurity.  Just sayin.

Is this something to worry about ?



https://wyobiz.wy.gov/Business/ViewCertificate.aspx

Just saw BFLs next offering:



666 Terahashs/s

ALL the kilowatts

If bitcoins completely disappeared would these machines have any resale value? I don't understand why everyone argues that they will not pay off even if it takes 2 years to break even, you still have the machine, say it is worth $5k after two years thats a 16% return. I may not completely understand the risks but sounds solid to me.

FPGAs is a "new thing" in Bitcoin mining, so it is expected to get cheaper. But it will not if everyone sits around and waits for that. What I would suggest is that we buy FPGA boards, to stimulate the market, BUT lets not bet high on them.

Another thing to note, is the warranty period. I believe every mining device should be under warranty for the whole period until the device's break even. If an FPGA board dies well before break even, it's a lose-lose-lose-lose situation. In this field, FPGAs ar far behind IMO compared to GPUs

Last but not least, the reselling price should be taken under consideration. An FPGA board, is specific to Bitcoin mining. If anything happens in that field (e.g. new and better board comes out, bitcoin fails, etc), no one would want to buy it. On the contrary, GPUs can be sold quite easily and are independent on bitcoin.

has anyone else encountered a firmware integrity failure ... after attempting to upgrade the firmware ... the following message is listed in the device information ... "Firmware integrity test failed.  Reflash required."

@BFL_Engineer: regarding the different firmware binaries available for download:

For the 864 (experimental), 792 and 768 (hot environment) firmware, are there any functional differences between these and the 832/816/808/800 versions other than hashrate? Throttling point, for example?

I'm just wondering why you have labels ('experimental' or 'hot environment') on some but not the others.

Actually it would be nice if BFL would publish the hashes for the files they are posting.

I filled out their form and it took me to bit-pay and I have a receipt from bit-pay.

Thanks for the links I will check them out.

858 on the 862 firmware. 0 throttles and 0 errors light test. running on cgminer now to let it run all night. Will unplug and retry tests tomorrow.

Yes I am I edited in that I was testing faster before I checked for new posts. I gave results then downloaded the new firmwares.

Test shows average speed 810Mhash, 0 throttles, 0 errors and reliable. The 810 makes me a little upset. Had I known that it was shipped with 3 fans total and a declocked bitstream I would have expected the results I have gotten. Not the results that where stated plainly on the page when I paid for it.

Well that would be truely accurate except I submit stale as 2 of my 3 pools accept all of the shares. It does not go idle or does not seem to slow down until the staged work runs out. I guess my quandry is why between LP is the unit never able to clear 811.1 with an average of 796 over this test has only been 10 hours. I understand that the lag after LP (if I dumped the queue) would delay a couple of work units. Even EclipseMC where RollNtime is working. I am able to run some work multiple times per request. Even if the first request was lagging the next 4 for sure submissions should be on time as the work is now local. While the next how ever many it completes are being run through CGminer queues more work. Up to 2 is the highest I have seen. But even with a queue of 2 and staged work of 5 I am seeing less then 800 listed periodically. The loss of hashrate comes about 1 minute into the new work after the LP.

On CGMiner how long is the per device speed averaged over. I am going to try changing the log information to see when the upper matches since I know of no faster way to find out(this was a bad plan as now the value I want to test and the value I am to test it against both change at the same time). I know the average seems to be the whole running time. I know the upper data I can set and it defaults to 5 seconds. I ask because I am having trouble figuring out if cgminer is failing to deliver work fast enough, if cgminer isn't checking close enough to when its done sometimes, if a minute after a LP I am unable to get shares in a timely fashion (I have queued work so that seems unlikely), or if my single is not for some reason  signaling it is done when it should(I am not saying this is the problem).

As a side note per the engineers information I have no way to actually diagnose this. There appears to be no status indication for a unit done with its processing but not yet working. Maybe I have misunderstood but the internal LED's only blink when new work is set so they  are nearly useless for me to tell if the device is finsihing early. This has my testing stuck with a blame the other guy answer. All that needs said is BFL its cgminer or your pools, cgminer its your pools or your single, your pools its your single or cgminer. HOW DO I KNOW?

I don't think 811 sounds right at all personally. My average of not even 800 seems horribly low. I understand that LP can cause some network delays after it happens. I guess to me it seems a bit glib to say that my unit is throttling when out fo the two of us I am pretty sure I am the only one capable of seeing the LED's, and that despite my being able to look into the running unit you know much better then I do what rate the internal LED's blink at. Possibly you have broken into my house and examined the unit without my knowledge or consent but far more likely you are guessing. I am looking at the unit in question. I am in proximity to the problem and so far I have gotten nothing from the BFL-Engineer to actually help figure this out. By all means pat yourself on the back for being so knowledgable that you just know everything is fine. Maybe just for a moment pretend that when I said I stared at it for an hour I ment 60 Minutes. When I said I timed the LED flashes I actually timed them, and when I said I counted that I am not so stupid as to actually look away during it.

I understand how long polls work. New block is found everyone has to get new work. The pools get hammered with requests for work. How is it possible when I am working on previously cached work and requesting new and showing cached work that I am out of work? Even set to 2 seconds for my logging I show 1 unit que and 3-12 staged. How is that out of work?

To be fair earlier I used a watch rather then counting the time between the internal LED flashes. 5 in a row looked to be either right on or very close to 5 seconds the last one I timed was 7 seconds. The lowest hashrate reported by cgminer is 224Mhash. Mostly it shows 800+ but occasional dips to below 300Mhash on a 5 second average and below 500Mhash on a 10 second average. The per unit rate seems nearly constant at 811 but drops at LP to 750ish. I am unsure as to why I would have nearly the same results regardless of the que length. I have used a queue of 1-5 and am now trying 10. My staged shares never seem to go above 4 but have gone to 0.  I have a GF of 5 and an RF of 13 in 2 hours 15 minutes. My total queued never get above 3 either. Assuming it is a latency issue then increasing the queue should move the problem to LP rather then somewhere inbetween. Assuming I am right that is. Even set at a queue of 5 I should have 25.5 seconds or so of work giving my computer ample lead to get more work I would think.

Changing pool options in cgminer left me with a better result. Load balance did not always keep up. Rotate every N minutes works much better for me with a larger queue.  I now have only issues at LP and a short while after. BFL shows 811Mhash until LP then lower until I get a ST of at least 4. I have no idea why but it looks like network isn't keeping up.

edit:
I am still curious why Cgminer is showing 810-811 Mhash for the single. Is there a way to improve this number more then I have. I moved the BFL to a USB port with 0 other devices (changed the rate 0Mhash). I have tried local work, and remote work from 2 pools one supporting rollNtime (results seemed to be the same). I am running CGminer 2.4.1. The average is still below 800 on average but the slower LP has moved it up to nearly 800. Just after a LP I get down to 500Mhash on the BFL 0 line.

Anyone have any luck with the 'Blink Unit(s)' function? I'm running EasyMiner_V_1.0_Beta and the 'Blink Unit(s)' feature on the right-click menu doesn't do anything for me. i.e. I click on it, but no LED on my unit blinks. It would be a handy feature if it worked.