Butterfly Labs - Bitforce Single and Mini Rig Box

[Askit2]

Could someone let me know if my single is a goof. Both fans blow air out. From memory fans move more air past heatsinks on the pressure side not the vacuum side. I would assume that blowing in should cool the power stage better and the processor. As it shipped I have a 2 fan Revision 3 with Heatpipes. I get less then 820 megahash per CGminer 2.4.1. The highest temperature I have seen listed was 62 and the unit was not flashing its LED to let me know it was throttling. My average on CGminer is 777 Mhash. I have checked the clips on the heatsink and they are both through the board fully. The highest I have seen was 790. I suppose I could ask in the cgminer thread about that.
Thanks all!

[1714946800]

1714946800

[1714946800]

1714946800

[1714946800]

1714946800

[1714946800]

1714946800

[BFL]

Could someone let me know if my single is a goof. Both fans blow air out. From memory fans move more air past heatsinks on the pressure side not the vacuum side. I would assume that blowing in should cool the power stage better and the processor. As it shipped I have a 2 fan Revision 3 with Heatpipes. I get less then 820 megahash per CGminer 2.4.1. The highest temperature I have seen listed was 62 and the unit was not flashing its LED to let me know it was throttling. My average on CGminer is 777 Mhash. I have checked the clips on the heatsink and they are both through the board fully. The highest I have seen was 790. I suppose I could ask in the cgminer thread about that.
Thanks all!

Hi Askit,

The outward blowing fans achieve greater cooling effectiveness than an inward blowing orientation.  Your unit is configured properly.  With regards to throttling.  The front LED will only pulse during the throttle, and not after.  If your performance is showing 777 mh/s then your unit definitely throttling.  If you sit and watch it, you will eventually see the front LED pulse...  indicating the throttle.

The only way the unit will throttle is in reaction to heat build up.  Be sure the top heatsink's push pins are properly secured and haven't worked loose in shipping.  Probe through the bottom grill opening and ensure that the bottom heatsink is well adhered to the bottom of the PCB. 

Finally, check that the ambient temperature is 72f at the point of air intake into the unit.  In many cases, room temperature may be cool, but exhaust from other devices may be heating up the air around your single...  causing it to throttle.  If the ambient temperature is as best as you are able to control, then you can tune the speed of the unit slightly to accommodate any ambient temperature you like.  The software tool to do this will be released this week.  Failing all this, you can send your unit in for a replacement.  We'll test it in 72f and if it fails to run at proper speed, we'll send an immediate replacement.

[Askit2]

My unit normally shows 52-62C. The absolute highest I have seen myself was 62C. I am not sure it is throttling. The LED never blinks. The grating on the side shows 69.4F. The only thing that makes me think something is wrong is a 24 hour average under speed. I have stared at the LED for more then an hour at a time. Would the throttling be short enough that if I blink I would miss it? It flashes the 2 internal LED's every about 10 seconds. The single rearward LED stay lit. The front only blinks on start up. I will move the unit to a location that I can check the lower heatsink tomorrow. I have already pushed both pins down to check their seating but both are fully down. Unless I missed some clips it is properly held down.

Thank You for the suggestions. I will post more when I know more.

[BFL-Engineer]

My unit normally shows 52-62C. The absolute highest I have seen myself was 62C. I am not sure it is throttling. The LED never blinks. The grating on the side shows 69.4F. The only thing that makes me think something is wrong is a 24 hour average under speed. I have stared at the LED for more then an hour at a time. Would the throttling be short enough that if I blink I would miss it? It flashes the 2 internal LED's every about 10 seconds. The single rearward LED stay lit. The front only blinks on start up. I will move the unit to a location that I can check the lower heatsink tomorrow. I have already pushed both pins down to check their seating but both are fully down. Unless I missed some clips it is properly held down.

Thank You for the suggestions. I will post more when I know more.

Dear Askit,

The internal LEDs blink every time a new job is about to be processed. This should happen exactly ever 5 seconds (5100 ms). Should the interval
be higher than 5 seconds, then it indicates that the unit is not receiving job fast enough from the host. Of course at this point I think it does
blink every 5 seconds, and the 10 seconds you mentioned was an estimation.

The front LED is what counts. If it blink anytime after startup, it indicates a throttle. Usually the throttle lasts about 15 seconds.



Good Luck,
BF Labs Inc.

[kano]

Hmm, I presume what really happens is different?
If the unit is throttled, then it takes longer than 5.162s to do a full 2^32 nonce range.
Thus when throttled the internal LED should be flashing less than every 5.1s ...
(e.g. 800MH/s = 5.3687s)
Not easily visually different, but certainly different.

Of course the software could be silly and abort the work every 5.162s when it is throttled ...
But that would just mean it wasn't programmed very well.
Edit: actually, it's not an Icarus - so I should add - that would be insane to abort the work at 5.162s since you would be throwing away ALL your shares when it is throttled.
So yeah when it's throttled, it will always be flashing slower than every 5.162s

[Askit2]

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.

[BFL-Engineer]

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.

Your hash rate has not dopped down to 500MH/s. The number you see is based on statistical calculation done in cgminer. It takes the number of
nonces found and based on the time it took, it gives you the hash-rate. During LP, the unit stops receiving job from cgminer. As a result, the unit stays
idle for some time. This causes the number reported by cgminer to drop, since the clock on cgminer is ticking but it's not providing any job to the unit
(hence no nonces are found).

Regards,
BF Labs Inc.

[Askit2]

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?

[BFL-Engineer]

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?

If possible, please download Easyminer from our website, and run a light-diagnosis on your unit.
The number given to you is very close to the hash-speed of the unit( there is some 80ms device
turnaround latency, which would translate some 10MH/s less than the units hash rate, but it will
give you the speed of the unit nonetheless).

Please report the number you get back to us, and we'll see if something is wrong.



Regards,
BF Labs Inc.

[Askit2]

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.

Edit:
After downloading firmware A Plenty I am testing the 864Mhash version. I hope it doesn't throttle. But I can always try something slower if it does.

[BFL-Engineer]

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.

Is it possible for your to upload a new firmware? We have them available on the site. Start with 864, then 832, etc.


Regards,
BF Labs Inc.

[Askit2]

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.

[bitlane]

......shipped with 3 fans total and a declocked bitstream....

The above statement along with a 6 month warranty make me happy that BFL took 2 days to answer my email in regards to a near $10,000 USD order that I was informed may be available in 6-8 weeks.

I will keep a candle burning for you all and pray that your 6 month warrantied miners don't end up being 7 month old paperweights.

[BFL-Engineer]

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.

The 810 you see does not have the latency of 100ms included. 810 means 822MH/s total.
Could you please send me detailed information of how fast each firmware has operated?
To be sure, after each firmware upload, power-cycle the unit and run diagnostics.

Please send the results to nasser@butterflylabs.com.


Regards,
BF Labs Inc.

[Askit2]

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.

Edit:
Running 52.2C so cooler then the last firmware I had on it. CGMiner reports 857.7 over 50 minutes. I will have more accurate numbers later but so far this works about how I would expect given the firmware I know I flashed on it.

Edit 2:
After running 12 hours or a little more I have an average speed of 807Mhash, and the top speed I see is still 858. Rejects are a lower % as well.

Edit 3:
Tried medium test twice.
First result was disconnected at least 100 processed 0 errors, 0 throttles.
Second result was gave up. Unit reliable, processed 115 0 errors, 0 throttles.

[BFL-Engineer]

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.

Happy to know. It is best to run medium or heavy diagnostics to make sure unit will behave the same
way in the long run.


Regards,
BF Labs Inc.

[n0ne]

......shipped with 3 fans total and a declocked bitstream....

The above statement along with a 6 month warranty make me happy that BFL took 2 days to answer my email in regards to a near $10,000 USD order that I was informed may be available in 6-8 weeks.

I will keep a candle burning for you all and pray that your 6 month warrantied miners don't end up being 7 month old paperweights.

[Askit2]

Is Gave up a bad hing?
is run was 259 processed, 0 erors, 1 throttle. 1 seems high. I will keep an eye on it.

[-ck]

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?

You ARE out of work after a longpoll. The cached work is absolutely useless belonging to a now dead previous block height so you do NOT work on it no matter how much work is "cached". The only thing that is "cached" with submit-stale is SHARES, if they have been found at approximately the same point in time as the longpoll, not extra work. You cannot work again at maximum rate until you have received enough work from either the longpoll itself (since it provides one work unit), rolls work from that longpoll (if the pool supports rolltime), and/or you get enough new work units. The fact that the BFL device twiddles its thumbs for up to 5 seconds on the wrong block work after longpoll means up to 5 seconds of work is wasted. You can submit those shares, but most pools will just say "too late" and they'll be rejected.

[Askit2]

Then I guess I am curious why it starts twiddling its tumbs more then 40 seconds after the LP from the pool. I see staged drop slightly after LP then about 40-45 seconds later I finally get a significant drop in speed. I had assumed it was working staged shares or it wouldn't keep busy immediately after but if it keeps up for the first at least 30 seconds I wonder why it slows down after that. I guess I get some shares early enough. that it coasts that long or something. At any rate the pools I have between the three should I had assumed keep up with one single. I have eclipseMC, bitclockers (I know people hate them), and bitpenny(kinda high fees but local work). Pool does not seem to change LP issues. Issue does not start at LP but after just far nearer LP then the next LP.
At any rate the more instant speed of the single stayed at 810-811 and now it stays above 850. It did not change because of any software changes. I put a new bitstream on it. My average went from 790 to 810ish now. I have had to adjust my queue up a bit hopefully the average will come up more.

Some LP times it does drop off instantly or close to it and stays down but most of the time it is later.