Question to multi-BFL Single miners: temperature and throttling issues

[zefir]

Hi BFL miners,

received my Singles recently and wanted to hear if someone had similar issues with throttling.

I got 5 of them that I put mining right away (i.e. without opening the housing ). They seem to be all Rev.3 ones with no additional bottom fan with the only noticeable difference being one has a passive copper heat sink at the PCB-bottom, while the other 4 have blue heat sinks with fans.

BFL-Engineer already wrote that thermal design is a challenge and every board has individual characteristics. Though, I found it really strange that two of them are blowing 'cold' air out of their case, while the other three exhaust is almost hot air. Since all boards are operating under the same environmental, I'd expect all to get relatively equally hot.

That's the subjective side. The objective values running the setup for 48h with cgminer are:

No.	av. Temp °C	av. MH/s
1	63	810
2	54	810
3	56	810
4	60	757
5	61	809

Device 4 is throttling (LED is blinking every ~3 minutes), but it is not the device with the passive heat-sink (that's device 3). My interpretation of the values (as far as I can trust cgminer measures) is that devices 1 and 5 (those with the 'cold' exhaust) have sub-optimal temperature-conductivity to the heat-pipe. Device 4 is worse in that and hits the throttling threshold (~65°C) resulting in a varying temperature averaging down to 60°C. Does this sound reasonable?

Did you had similar issues with multiple boards varying similarly? Anyone already tried to dismantle the heat-pipe and re-apply thermal grease or pads to improve stability?

Generally, the setup is fine and delivers exactly 4GH/s. But while the relative loss through throttling is small, anyone would RMA his GPU delivering 50MH/s less its nominal rate. Also, improving temp-conductivity might not only increase hash rate but also help durability.


Any thoughts or hints? Thanks.

[1715446826]

1715446826

[Inspector 2211]

I think that all of your Singles are fine and the small temperature variations that you see are just that, random variations.
I also think that a brief blink every 3 minutes is not an indication of throttling, but rather an indication that the device has found a match or that it is being provided with a new work unit.

[zefir]

I think that all of your Singles are fine and the small temperature variations that you see are just that, random variations.
I also think that a brief blink every 3 minutes is not an indication of throttling, but rather an indication that the device has found a match or that it is being provided with a new work unit.

Yeah, I guess I'm ahead of time. Assumed people already started tweaking it to push it to the max (like done with GPUs), but I guess most are just happy with it as a plug-and-mine device.

As for the LED blinking, I'm pretty sure I read somewhere that a blinking front LED indicates throttling. Plus in my setup it is only the device with the lower hash rate that blinks, which I take as strong indication for throttling. What you maybe mean is the internal LED at the right side that goes off every ~5s for a short moment. I'd guess this is when the work is done and it stops for a moment to deliver shares and get fed with new work.

Also, with now running for 72h continuously I'd exclude variance as a cause for 4 devices being exactly at 810 and the fifth at 65 less. I'm pretty noob when it comes to HW, but I'm tempted to disassemble (and pretty sure brick) it to see what's wrong.

[BFL]

I think that all of your Singles are fine and the small temperature variations that you see are just that, random variations.
I also think that a brief blink every 3 minutes is not an indication of throttling, but rather an indication that the device has found a match or that it is being provided with a new work unit.

Yeah, I guess I'm ahead of time. Assumed people already started tweaking it to push it to the max (like done with GPUs), but I guess most are just happy with it as a plug-and-mine device.

As for the LED blinking, I'm pretty sure I read somewhere that a blinking front LED indicates throttling. Plus in my setup it is only the device with the lower hash rate that blinks, which I take as strong indication for throttling. What you maybe mean is the internal LED at the right side that goes off every ~5s for a short moment. I'd guess this is when the work is done and it stops for a moment to deliver shares and get fed with new work.

Also, with now running for 72h continuously I'd exclude variance as a cause for 4 devices being exactly at 810 and the fifth at 65 less. I'm pretty noob when it comes to HW, but I'm tempted to disassemble (and pretty sure brick) it to see what's wrong.

Hi zefir, please write office @ butterflylabs.com for assistance if needed.

Kind regards,
BFL

[zefir]

Hi zefir, please write office @ butterflylabs.com for assistance if needed.

Kind regards,
BFL

Hi BFL (Sonny?),

thanks for the advice.

I did not since there is no issue. The devices are just doing a great job, congrats. Even the throttling one is within performance specs (832-10%), plus it is comforting to see that the devices take care themselves to not go up in flames.

I was just hoping that someone did a better job than your engineers in cooling it down (no offense, many Bitcoiners do better jobs than GPU manufacturers ) and max it out. But again, they are just running fine as is.

Nevertheless, you could maybe clarify the LED states here or at the product page (if not already done elsewhere).


Thanks

[rjk]

There are 2 places where some lights blink: On the front panel is the power light, and also the one that indicates throttling. Inside on the right side, there is another pair that pulse whenever a nonce is sent to the host and other indications. The front panel one is the one to worry about, and it should be fine if your ambient is less than 72 degrees F or about 21 degrees C.

[Inspector 2211]

I think that all of your Singles are fine and the small temperature variations that you see are just that, random variations.
I also think that a brief blink every 3 minutes is not an indication of throttling, but rather an indication that the device has found a match or that it is being provided with a new work unit.

Yeah, I guess I'm ahead of time. Assumed people already started tweaking it to push it to the max (like done with GPUs), but I guess most are just happy with it as a plug-and-mine device.

As for the LED blinking, I'm pretty sure I read somewhere that a blinking front LED indicates throttling. Plus in my setup it is only the device with the lower hash rate that blinks, which I take as strong indication for throttling. What you maybe mean is the internal LED at the right side that goes off every ~5s for a short moment. I'd guess this is when the work is done and it stops for a moment to deliver shares and get fed with new work.

Also, with now running for 72h continuously I'd exclude variance as a cause for 4 devices being exactly at 810 and the fifth at 65 less. I'm pretty noob when it comes to HW, but I'm tempted to disassemble (and pretty sure brick) it to see what's wrong.

In think you are right, after all.

Upon closer examination, one of my Singles (the first Rev. 3 Single with an external fan attached) also seems to blink.
See, when BFL wrote "will blink" I was expecting it to blink continuously, but that's not what it does.
It blinks for a few seconds as it throttles down to some 530 MH/s, and then, as it gradually increases its frequency again (probably in a ZTEX-like fashion) until it reaches 820 MH/s again, it does not blink, until the throttling game begins again.

Placing a 133 cfm fan on top of the unit to aid the internal fan in sucking hot air out did not help at all. Neither did positioning the 133 cfm fan at one of the side vents of the throttling-afflicted Single.

However, placing the 133 cfm fan at the BOTTOM of the Single, aiding the Single's external bottom fan, seems to have done the trick for me and thus I can recommend swapping the bottom fan of the Single for a higher-cfm model.

Edit:    No, it still throttles. Took it quite some time; I was seeing 825 MH/s for a long time, but it's at 591 right now, already on the upslope again. 754 now. Upslope. Nevertheless, I have ordered a few fans from Silicon Valley Compucycle, all of them 65 cfm and above, and will probably open up this Single and swap out the fans. Admittedly, my mining environment is quite extreme as the central AC does not manage to replace enough hot air with cool air.

[Cablez]

I have found that elevating the unit about 1" so the bottom fan can work more efficiently gives me about 5 degrees cooler temps.  Maybe give that a try.

[rjk]

I have found that elevating the unit about 1" so the bottom fan can work more efficiently gives me about 5 degrees cooler temps.  Maybe give that a try.

Be men and add some REAL fans, pussies! http://vimeo.com/41028028

[Inspector 2211]

I have found that elevating the unit about 1" so the bottom fan can work more efficiently gives me about 5 degrees cooler temps.  Maybe give that a try.

Be men and add some REAL fans, pussies! http://vimeo.com/41028028

Yeah, in fact one of the fans I just ordered is a 103 cfm, 61 dBA Delta fan. 
It's 50mm thick, so maybe you're using that as well.
SVC.com has them on sale for a mere $10 - regular price is $65.

[Inspector 2211]

I have found that elevating the unit about 1" so the bottom fan can work more efficiently gives me about 5 degrees cooler temps.  Maybe give that a try.

Actually, I place all my singles on their pretty face, cables sticking out on top.
This should allow for maximum airflow.

[BFL]

I think that all of your Singles are fine and the small temperature variations that you see are just that, random variations.
I also think that a brief blink every 3 minutes is not an indication of throttling, but rather an indication that the device has found a match or that it is being provided with a new work unit.

Yeah, I guess I'm ahead of time. Assumed people already started tweaking it to push it to the max (like done with GPUs), but I guess most are just happy with it as a plug-and-mine device.

As for the LED blinking, I'm pretty sure I read somewhere that a blinking front LED indicates throttling. Plus in my setup it is only the device with the lower hash rate that blinks, which I take as strong indication for throttling. What you maybe mean is the internal LED at the right side that goes off every ~5s for a short moment. I'd guess this is when the work is done and it stops for a moment to deliver shares and get fed with new work.

Also, with now running for 72h continuously I'd exclude variance as a cause for 4 devices being exactly at 810 and the fifth at 65 less. I'm pretty noob when it comes to HW, but I'm tempted to disassemble (and pretty sure brick) it to see what's wrong.

In think you are right, after all.

Upon closer examination, one of my Singles (the first Rev. 3 Single with an external fan attached) also seems to blink.
See, when BFL wrote "will blink" I was expecting it to blink continuously, but that's not what it does.
It blinks for a few seconds as it throttles down to some 530 MH/s, and then, as it gradually increases its frequency again (probably in a ZTEX-like fashion) until it reaches 820 MH/s again, it does not blink, until the throttling game begins again.

Placing a 133 cfm fan on top of the unit to aid the internal fan in sucking hot air out did not help at all. Neither did positioning the 133 cfm fan at one of the side vents of the throttling-afflicted Single.

However, placing the 133 cfm fan at the BOTTOM of the Single, aiding the Single's external bottom fan, seems to have done the trick for me and thus I can recommend swapping the bottom fan of the Single for a higher-cfm model.

Edit:    No, it still throttles. Took it quite some time; I was seeing 825 MH/s for a long time, but it's at 591 right now, already on the upslope again. 754 now. Upslope. Nevertheless, I have ordered a few fans from Silicon Valley Compucycle, all of them 65 cfm and above, and will probably open up this Single and swap out the fans. Admittedly, my mining environment is quite extreme as the central AC does not manage to replace enough hot air with cool air.

Inspector, as I read your post I was preparing a response to ask you why you haven't contacted us about the issue...  until I realized you were running it in a hot ambient temperature.  Understood.

[Inspector 2211]

Inspector, as I read your post I was preparing a response to ask you why you haven't contacted us about the issue...  until I realized you were running it in a hot ambient temperature.  Understood.

I'm not a guy who cries wolf easily and only discovered that one of my Singles is throttling down frequently after zefir's post.
I am, however, in the process of phasing out all GPU rigs (in fact, just a few minutes ago I turned off my 2nd GPU rig for good, leaving only one rig running now).

Even with only one GPU rig running as we speak, this one "problem Single" is throttling down to about 500 MH/s quite frequently, right now, for instance, to 544 MH/s, and I may request a replacement unit at some point in time, after turning off the final GPU rig and after measuring the room temperature.

BTW, CGminer shows the "problem Single's" temperature at only 50 or 51 degrees Celsius, while the other good unit one foot away from it shows 64 degrees and mines along happily. So it seems to me that this "problem Single" may actually be throttling unnecessarily, or overly aggressively. By any chance, is there a trim pot inside by means of which an END USER could adjust the throttling threshold? Or is the throttling threshold error based like in the ZTEX design?

Just now I looked at the CGminer panel - the "problem Single" was at 823 MH/s and 53 degrees, whereupon it started throttling again. I don't deem 53 degrees a dangerous chip temperature and thus I'm really wondering what's going on here...

[BFL]

Inspector, as I read your post I was preparing a response to ask you why you haven't contacted us about the issue...  until I realized you were running it in a hot ambient temperature.  Understood.

I'm not a guy who cries wolf easily and only discovered that one of my Singles is throttling down frequently after zefir's post.
I am, however, in the process of phasing out all GPU rigs (in fact, just a few minutes ago I turned off my 2nd GPU rig for good, leaving only one rig running now).

Even with only one GPU rig running as we speak, this one "problem Single" is throttling down to about 500 MH/s quite frequently, right now, for instance, to 544 MH/s, and I may request a replacement unit at some point in time, after turning off the final GPU rig and after measuring the room temperature.

BTW, CGminer shows the "problem Single's" temperature at only 50 or 51 degrees Celsius, while the other good unit one foot away from it shows 64 degrees and mines along happily. So it seems to me that this "problem Single" may actually be throttling unnecessarily, or overly aggressively. By any chance, is there a trim pot inside by means of which an END USER could adjust the throttling threshold? Or is the throttling threshold error based like in the ZTEX design?

Just now I looked at the CGminer panel - the "problem Single" was at 823 MH/s and 53 degrees, whereupon it started throttling again. I don't deem 53 degrees a dangerous chip temperature and thus I'm really wondering what's going on here...

There are several factors involved, but the bottom line is that if it throttles in an ambient temperature of 72 degrees Fahrenheit than we'll gladly replace the unit.  If you're just curious as to the inner workings and want to know what factors are in play, please contact me in private and I'll do my best to answer your questions.

Regards,
BFL

[Inspector 2211]

Inspector, as I read your post I was preparing a response to ask you why you haven't contacted us about the issue...  until I realized you were running it in a hot ambient temperature.  Understood.

I'm not a guy who cries wolf easily and only discovered that one of my Singles is throttling down frequently after zefir's post.
I am, however, in the process of phasing out all GPU rigs (in fact, just a few minutes ago I turned off my 2nd GPU rig for good, leaving only one rig running now).

Even with only one GPU rig running as we speak, this one "problem Single" is throttling down to about 500 MH/s quite frequently, right now, for instance, to 544 MH/s, and I may request a replacement unit at some point in time, after turning off the final GPU rig and after measuring the room temperature.

BTW, CGminer shows the "problem Single's" temperature at only 50 or 51 degrees Celsius, while the other good unit one foot away from it shows 64 degrees and mines along happily. So it seems to me that this "problem Single" may actually be throttling unnecessarily, or overly aggressively. By any chance, is there a trim pot inside by means of which an END USER could adjust the throttling threshold? Or is the throttling threshold error based like in the ZTEX design?

Just now I looked at the CGminer panel - the "problem Single" was at 823 MH/s and 53 degrees, whereupon it started throttling again. I don't deem 53 degrees a dangerous chip temperature and thus I'm really wondering what's going on here...

There are several factors involved, but the bottom line is that if it throttles in an ambient temperature of 72 degrees Fahrenheit than we'll gladly replace the unit.  If you're just curious as to the inner workings and want to know what factors are in play, please contact me in private and I'll do my best to answer your questions.

Regards,
BFL

Here's what I will do:
1. I'll move the "problem Single", which currently is in the middle of the room together with one other Single, to the "nest" of 6 singles, which happens to be quite close to the office door.
2. I'll measure the hallway temperature, which is quite low, judging from what I feel
3. I'll move the "problem Single" to the hallway for, say, half an hour and watch whether it throttles
4. If the hallway temperature is 72 degrees or below, as I think it is, and the "problem Single" throttles, I'll RMA it.
5. Otherwise, I'll just suck it up. It still mines, just not at 820 MH/s...

[zefir]

BFL (through this post, BFL refers to the company, not to Sonny personally),

with due respect, while the Singles are lovely devices, your customer service sucks. Since the run for your products started, I contacted you 6 times with concrete technical inquiries and got zero responses (just ask BFL-Engineer, and FYI, that's why I did not order a (Mini) Rig). Therefore I preferred to get support from the community.

Plus it should be in BFL's best own interests when existing issues are discussed here openly and workarounds are made available publicly (or you add the related information at your product pages). Like Inspector said above, most of us would prefer fixing it by ourselves over waiting months for a RMA replacement.

That said, you need to clarify how you define ambient temperature. My setup is in a fairly large room in my basement with currently around 19°C room temperature. Naturally, as I approach the mining rig, local temperature gradually climbs and reaches ~23°C at half a meter distance. Given that the exhaust temperature right above the Singles is somewhere between 30 and 40°C, it's a physical imperative to have a local area with >22C° (or 72°F; any chance US is going to use SI-metrics soon? ).

I strongly believe that my operational environment is within specs, though the problematic device averaged down to 705MH/s after a continuous run for days. Again, I'm with Inspector arguing better to have it running at 500MH/s than waiting weeks for a replacement at 0MH/s. Therefore I'm going to first try the proposals the community posted, thanks to all.


While I am at it, I figured out a SW issue that could be quite relevant for all multi-Single setups driven by cgminer: while I removed the throttling device from the setup for further inspection, the average hashrate of the remaining 4 climbed up noticeably. To double check, I repeatedly run it long enough to exclude variation and this is what I get:
1) running all 5 devices the hashrate for all of them starts at 828 and after running a day the throttling settles at 705 all-time-average, while the properly working ones settle at 790
2) running the 4 proper ones alone, all start at 828 and after the day they are still at ~825

In other words, the throttling one is not just reducing its own hashing power but also those of the proper ones. In my 5-units setup the estimated loss is ~250MH/s.

This could be caused by the communication between PC and Single being frozen during the throttling. From the SW design view there should theoretically be no inter-dependencies, since every device is handled by its own threads. But in practice if the device throttles while communicating to the host and thereby stalls, the related thread will eat its scheduling quantum busy looping the serial port.

Luckily ckolivas is not only cgminer developer but also a Linux scheduler guru, so I'll sort this SW issue out in his thread. Meanwhile I will separate the throttling device from my setup and run it from a different host.

Tl;dr: if you have a multi-BFL Singles setup with one or more throttling units (front LED is blinking now and then) you should consider operating the throttling ones from a different host for a better overall hashrate.

[BFL]

BFL (through this post, BFL refers to the company, not to Sonny personally),

with due respect, while the Singles are lovely devices, your customer service sucks. Since the run for your products started, I contacted you 6 times with concrete technical inquiries and got zero responses (just ask BFL-Engineer, and FYI, that's why I did not order a (Mini) Rig). Therefore I preferred to get support from the community.

Plus it should be in BFL's best own interests when existing issues are discussed here openly and workarounds are made available publicly (or you add the related information at your product pages). Like Inspector said above, most of us would prefer fixing it by ourselves over waiting months for a RMA replacement.

That said, you need to clarify how you define ambient temperature. My setup is in a fairly large room in my basement with currently around 19°C room temperature. Naturally, as I approach the mining rig, local temperature gradually climbs and reaches ~23°C at half a meter distance. Given that the exhaust temperature right above the Singles is somewhere between 30 and 40°C, it's a physical imperative to have a local area with >22C° (or 72°F; any chance US is going to use SI-metrics soon? ).

I strongly believe that my operational environment is within specs, though the problematic device averaged down to 705MH/s after a continuous run for days. Again, I'm with Inspector arguing better to have it running at 500MH/s than waiting weeks for a replacement at 0MH/s. Therefore I'm going to first try the proposals the community posted, thanks to all.


While I am at it, I figured out a SW issue that could be quite relevant for all multi-Single setups driven by cgminer: while I removed the throttling device from the setup for further inspection, the average hashrate of the remaining 4 climbed up noticeably. To double check, I repeatedly run it long enough to exclude variation and this is what I get:
1) running all 5 devices the hashrate for all of them starts at 828 and after running a day the throttling settles at 705 all-time-average, while the properly working ones settle at 790
2) running the 4 proper ones alone, all start at 828 and after the day they are still at ~825

In other words, the throttling one is not just reducing its own hashing power but also those of the proper ones. In my 5-units setup the estimated loss is ~250MH/s.

This could be caused by the communication between PC and Single being frozen during the throttling. From the SW design view there should theoretically be no inter-dependencies, since every device is handled by its own threads. But in practice if the device throttles while communicating to the host and thereby stalls, the related thread will eat its scheduling quantum busy looping the serial port.

Luckily ckolivas is not only cgminer developer but also a Linux scheduler guru, so I'll sort this SW issue out in his thread. Meanwhile I will separate the throttling device from my setup and run it from a different host.

Tl;dr: if you have a multi-BFL Singles setup with one or more throttling units (front LED is blinking now and then) you should consider operating the throttling ones from a different host for a better overall hashrate.

I'm sorry you've had trouble getting a response.  We've added staff to handle customer service and your email thread may have been lost in the transition.  Try a new request to office@butterfly... (not sonny@butterfly...)   and you'll get prompt responses.  (again, sorry for the difficulty during the last month or so...  we've been stretched thin).

With regards to what we mean by ambient temperature...  Room temperature or building set thermostat temperature isn't a very good guide as you point out.  We recommend placing a thermometer next to the unit in question and you'll know for sure.  If there's throttling at 72f, then I would be very surprised.  Each unit is tested prior to shipment at higher temperatures than that while operating at 832 mh/s.

Also note that although the temp spec is with the hardware running at a speed of 832 mh/s.  Tuning it down to 816 or 808 mh/s will have a significant effect on it's tolerance and allow you to run in higher ambient temperatures.  The net result is a higher effective hash rate than 832 with throttling (depending on temperature stress).  Likewise, slower speed increments down to 768 will allow you to run in almost any environment without throttling.

Our Easy Miner software will allow you to test & tune.  It's in beta...  and still buggy but it will accomplish this task for you.  We can probably get a demo version prepped in the next week to let you play with speed tuning.

On the chips in general and their variances...  please understand that when chips are fabricated, not all are the same.  These variances are a normal part of the process.  Industry practice has the units sorted and sold per speed grade.  In our case, we've simply packaged the end product with the lowest common denominator performance which is 832 mh/s (+ - 10%) at 72f.  

Regards,
BFL

[zefir]

Thanks for the feedback, BFL.

I'm sorry you've had trouble getting a response.  We've added staff to handle customer service and your email thread may have been lost in the transition.  Try a new request to office@butterfly... (not sonny@butterfly...)   and you'll get prompt responses.  (again, sorry for the difficulty during the last month or so...  we've been stretched thin).

Glad to hear you expanded your customer service capacity - I'll maybe need it soon. As for the right email address, all mails I received from BFL where sent from sonny@bfl, including the shipment notification from last week. If that address is not valid any more, you still should assume that your customers just hit the reply button to contact you.

With regards to what we mean by ambient temperature...  Room temperature or building set thermostat temperature isn't a very good guide as you point out.  We recommend placing a thermometer next to the unit in question and you'll know for sure.  If there's throttling at 72f, then I would be very surprised.  Each unit is tested prior to shipment at higher temperatures than that while operating at 832 mh/s.

Also note that although the temp spec is with the hardware running at a speed of 832 mh/s.  Tuning it down to 816 or 808 mh/s will have a significant effect on it's tolerance and allow you to run in higher ambient temperatures.  The net result is a higher effective hash rate than 832 with throttling (depending on temperature stress).  Likewise, slower speed increments down to 768 will allow you to run in almost any environment without throttling.

Then you are essentially saying that one needs AC to reliably operate the Singles. As stated above, the devices are hot spots and heat their surrounding area to a point where you need to actively cool the ambiance or add external fans to increase convection. Reality check: I'm operating them in April in the Swiss Alps in an passively cooled (aka open window) cellar room that is at 18°C when mining rig is off. If that's not 'cold' enough, where in the world can they operate during summer without AC?

Fact is, you nowhere wrote that the claimed performance is limited by ambient temperature. Why is that? Why do you let your customers lurk the forums here to collect relevant information? I mean, you still claim the housing is 88*88mm^2 at the product page, while people holding the Singles in their hands can measure they are 110*105mm^2   You really do not disclose trade secrets if you add all those pieces of information collected in this forum to the product page. Remember, Bitcoin is based on openness...

Our Easy Miner software will allow you to test & tune.  It's in beta...  and still buggy but it will accomplish this task for you.  We can probably get a demo version prepped in the next week to let you play with speed tuning.

On the chips in general and their variances...  please understand that when chips are fabricated, not all are the same.  These variances are a normal part of the process.  Industry practice has the units sorted and sold per speed grade.  In our case, we've simply packaged the end product with the lowest common denominator performance which is 832 mh/s (+ - 10%) at 72f.  

Regards,
BFL

As for the EasyMiner, I guess it is Windows-only and therefore useless for me. But if you want to support the current matter, could you just check if adding a throttling unit to a set of non-throttling units reduces their average hashrate (as I described above)?

I fully understand the challenges with building such a device and repeat my above statement: your product is great, period. But your customers are part of an open society and you should have been prepared to provide an according information policy. I'm biased and surely not objective enough, but I hope it did not sound too harsh and you can take it as valuable input to improve further.


All the best, zefir

[BFL]

Thanks for the feedback, BFL.

I'm sorry you've had trouble getting a response.  We've added staff to handle customer service and your email thread may have been lost in the transition.  Try a new request to office@butterfly... (not sonny@butterfly...)   and you'll get prompt responses.  (again, sorry for the difficulty during the last month or so...  we've been stretched thin).

Glad to hear you expanded your customer service capacity - I'll maybe need it soon. As for the right email address, all mails I received from BFL where sent from sonny@bfl, including the shipment notification from last week. If that address is not valid any more, you still should assume that your customers just hit the reply button to contact you.

With regards to what we mean by ambient temperature...  Room temperature or building set thermostat temperature isn't a very good guide as you point out.  We recommend placing a thermometer next to the unit in question and you'll know for sure.  If there's throttling at 72f, then I would be very surprised.  Each unit is tested prior to shipment at higher temperatures than that while operating at 832 mh/s.

Also note that although the temp spec is with the hardware running at a speed of 832 mh/s.  Tuning it down to 816 or 808 mh/s will have a significant effect on it's tolerance and allow you to run in higher ambient temperatures.  The net result is a higher effective hash rate than 832 with throttling (depending on temperature stress).  Likewise, slower speed increments down to 768 will allow you to run in almost any environment without throttling.

Then you are essentially saying that one needs AC to reliably operate the Singles. As stated above, the devices are hot spots and heat their surrounding area to a point where you need to actively cool the ambiance or add external fans to increase convection. Reality check: I'm operating them in April in the Swiss Alps in an passively cooled (aka open window) cellar room that is at 18°C when mining rig is off. If that's not 'cold' enough, where in the world can they operate during summer without AC?

Fact is, you nowhere wrote that the claimed performance is limited by ambient temperature. Why is that? Why do you let your customers lurk the forums here to collect relevant information? I mean, you still claim the housing is 88*88mm^2 at the product page, while people holding the Singles in their hands can measure they are 110*105mm^2   You really do not disclose trade secrets if you add all those pieces of information collected in this forum to the product page. Remember, Bitcoin is based on openness...

Our Easy Miner software will allow you to test & tune.  It's in beta...  and still buggy but it will accomplish this task for you.  We can probably get a demo version prepped in the next week to let you play with speed tuning.

On the chips in general and their variances...  please understand that when chips are fabricated, not all are the same.  These variances are a normal part of the process.  Industry practice has the units sorted and sold per speed grade.  In our case, we've simply packaged the end product with the lowest common denominator performance which is 832 mh/s (+ - 10%) at 72f.  

Regards,
BFL

As for the EasyMiner, I guess it is Windows-only and therefore useless for me. But if you want to support the current matter, could you just check if adding a throttling unit to a set of non-throttling units reduces their average hashrate (as I described above)?

I fully understand the challenges with building such a device and repeat my above statement: your product is great, period. But your customers are part of an open society and you should have been prepared to provide an according information policy. I'm biased and surely not objective enough, but I hope it did not sound too harsh and you can take it as valuable input to improve further.


All the best, zefir

Zefir,

I'm glad you like the product.  We're doing our best to keep up with customer request as well as our own internal development for future products.  This industry is moving fast.  

The most popular software package in use for mining with BitForce hardware is currently CGminer.  It's only fault is that it doesn't auto detect the units as they're plugged into the chain.  Ufasoft is pretty good, but it's lacking in features as compared to CG.  I understand mpbcm is also an excellent choice for BitForce owners.  It both auto detects and provides a golden suite of data.

Having said all this, I'm really not qualified to comment on the inner workings of any of the software miners.  The hardware itself has no ability to influence the behavior of another device on the chain, so if you're experiencing that now, I would have to assume it's something to do with whatever software you're using.  We use Easy Miner here in the shop to do our testing.  It's diagnosis & testing function runs known problems with known results without any outside network issues able to affect the performance evaluation.  It handles multiple units without any influence from a throttling unit.  Perhaps that's helpful to you.

[zefir]

Zefir,

I'm glad you like the product.  We're doing our best to keep up with customer request as well as our own internal development for future products.  This industry is moving fast.  

The most popular software package in use for mining with BitForce hardware is currently CGminer.  It's only fault is that it doesn't auto detect the units as they're plugged into the chain.  Ufasoft is pretty good, but it's lacking in features as compared to CG.  I understand mpbcm is also an excellent choice for BitForce owners.  It both auto detects and provides a golden suite of data.

Having said all this, I'm really not qualified to comment on the inner workings of any of the software miners.  The hardware itself has no ability to influence the behavior of another device on the chain, so if you're experiencing that now, I would have to assume it's something to do with whatever software you're using.  We use Easy Miner here in the shop to do our testing.  It's diagnosis & testing function runs known problems with known results without any outside network issues able to affect the performance evaluation.  It handles multiple units without any influence from a throttling unit.  Perhaps that's helpful to you.

Thats at least some helpful information.

To understand the SW side it would have been more interesting to know what exactly happens during throttling, i.e. does it just stop hashing but remains accessible (e.g. for temperature readout), or is it completely gone during that phase. Never mind, it will take me some time but I'll find out myself.

As for EasyMiner, I'd like to try the demo version you mentioned above to have it as reference, if possible.

Thanks.

[twmz]

I also have a unit that is less tolerant of higher than supported ambient temperatures.  The room is 75 instead of 72 and one of my singles throttles regularly while the other never does. Until I can try EasyMiner's tuning, I have been trying to improve airflow in hopes that I can reduce throttling as much as possible. 

To that end, last night I removed the U-shaped cover piece to the unit that was throttling (the piece that wraps around the sides and the front) to expose the heatsinks and fans.   With that piece removed, the device stopped throttling in the 75 degree ambient temperature.  Note, I do have a room fan pointed at the table these are sitting on and so my assumption is that with the case removed, that room fan is providing enough additional circulation to offset the increased ambient temperature.

So it's something you might want to try.  Note, to remove this easily, you only want to remove the 4 small screws on the sides (2 per side).  The "back" is the side with the USB and power connections.  There are 4 small screws there you want to leave alone.

Side note: I hope EasyMiner's speed adjustments will be persisted in nvram or something?  So, if it is a windows-only app, I can make the adjustment and then move the Single back to my linux rig?  If not, please make the protocol for adjusting the speed public so that the cgminer developers can add this feature directly.

[zefir]

I also have a unit that is less tolerant of higher than supported ambient temperatures.  The room is 75 instead of 72 and one of my singles throttles regularly while the other never does. Until I can try EasyMiner's tuning, I have been trying to improve airflow in hopes that I can reduce throttling as much as possible. 

To that end, last night I removed the U-shaped cover piece to the unit that was throttling (the piece that wraps around the sides and the front) to expose the heatsinks and fans.   With that piece removed, the device stopped throttling in the 75 degree ambient temperature.  Note, I do have a room fan pointed at the table these are sitting on and so my assumption is that with the case removed, that room fan is providing enough additional circulation to offset the increased ambient temperature.

So it's something you might want to try.  Note, to remove this easily, you only want to remove the 4 small screws on the sides (2 per side).  The "back" is the side with the USB and power connections.  There are 4 small screws there you want to leave alone.

Side note: I hope EasyMiner's speed adjustments will be persisted in nvram or something?  So, if it is a windows-only app, I can make the adjustment and then move the Single back to my linux rig?  If not, please make the protocol for adjusting the speed public so that the cgminer developers can add this feature directly.

I already tried dismantling the case of the throttling one along with what was suggested by the other users. Nothing did really help, i.e. the time between the start of mining and first throttling varies with the attempts, but once it starts it does it with same frequency, resulting in a long-term hashrate of 710-730MH/s.

The best I got so far was a result of pure monkey testing: I turned the upper fan and put it back into the housing. Instead of blowing out the heat-pipe's hot air to the top, it now sucks the fresh air from there and pushes it through the heat-pipe and the VRMs to the side exhausts. It's just a trial-and-error result and people familiar with thermal design might argue this is stupid, but it works for me.

[Shadow383]

The best I got so far was a result of pure monkey testing: I turned the upper fan and put it back into the housing. Instead of blowing out the heat-pipe's hot air to the top, it now sucks the fresh air from there and pushes it through the heat-pipe and the VRMs to the side exhausts. It's just a trial-and-error result and people familiar with thermal design might argue this is stupid, but it works for me.

Makes sense, you'll generally improve thermal performance by having the fans "push" airflow rather than pull, as the flow is much more turbulent, increasing the amount of heat leeched away from the surface due to the increase in boundary-layer vorticity.

[kano]

Got mine today (from someone else on the forum) it's with the single fan/new heat sink (whatever version that means)

I plugged it in to my desktop (linux) and 830Mh/s for the 41 seconds I ran it.
Thought this is nice - performing as expected ... time to take it down to the (underground basement) garage where my rig is
FYI here in Sydney Aus today it's 20°C where I am - my garage is cooler (it's autumn, winter in 1 month)

Took a while to work out how to get xubuntu 10.04 to recognise the BFL at all.
(luke-jr came up with the answer - anyone wondering: "sudo modprobe ftdi_sio vendor=0x0403 product=0x6014")

After a few minutes running ... throttling.
This is odd - coz the temp (reported from cgminer) was below 50°C - always.
Throttling down to crappy hash rates 680MH/s ... for an extended time.
On exit with that:
 Runtime: 0 hrs : 34 mins : 1 secs
 BFL0  47.3C         | (5s):708.0 (avg):696.9 Mh/s | A:275 R:4 HW:0 U:8.1/m

Yeah that sux badly.

So I brought it back upstairs to run it in it's own cgminer and find its ... slightly better ...
But WTF?
It's reporting it's temperature always above 50°C now even though it's getting a slightly better average MH/s
Current stats:
 Runtime ~70 minutes
 BFL 0:  52.7C         | 733.6/743.0Mh/s | A:655 R:6 HW:0 U: 9.40/m

I'd guess this is going to be some 'return it' and get a replacement .......
As for their EasyMiner program - yeah I'm gonna expect some details of the extra protocol from them to see if I can fix this thing myself.

I bought this for a few reasons:
1) cgminer (obvious - I wrote some of it)
2) I only had to pay BTC to the person I got it from
3) I got it in LESS than a week after I discussed buying it from them

I guess it's time to try email ... unless someone else can supply the extra protocol commands
(or has a copy of EasyMiner to watch what it sends to the BFL)

Edit: oh and the front led supposed to flash? Never seen it do it (except at power on for a short while)

[Inspector 2211]

The front LED flashes only for a few moments when the Single reduces its [clock speed?] hash rate, but not while it slowly increases its speed again.
Btw., my throttling issue seems to have been resolved by lowering the room temperature. I lowered it by turning off a GPU mining rig.

[zefir]

My throttling device's front LED toggles for around two seconds every 3 minutes or so. Whether this is the down-clock phase or the time where it stops mining I don't know, but from the effective hashrate it is more the down-clock (2/180 idle cycle time won't make up for the 15% hashrate drop I have).

My attempts to circumvent throttling have been futile so far. Along with the suggestions made by other users in this thread I let it mine outside over night at < 14°C. No matter what, the 12h+ average comes down to ~715MH/s. I'm therefore pretty sure something went wrong when the heatpipe was mounted (the other 4 devices are always at ~815, no matter what). Look at the ztex thread: people are achieving significant speed improvements with different thermal grease / heatsinks combinations or the process how they are applied. Since no one tried that for BFL Singles so far, I'm not going to brick mine trying. I'll wait for EasyMiner and if that's not fixing it, mine goes back to BFL (it is at < 832MH/s - 10%).

[rjk]

Wait, so on one instance of cgminer it is slow and on another it is faster? Is it a host system limitation of some kind? Although I doubt that. Did you check to make sure that the heatsink was firmly attached? There have been reports of it dislodging during shipping.

[zefir]

Wait, so on one instance of cgminer it is slow and on another it is faster? Is it a host system limitation of some kind? Although I doubt that. Did you check to make sure that the heatsink was firmly attached? There have been reports of it dislodging during shipping.

If you mean my setup, no. It's one cgminer instance operating 5 BFL Singles (plus 3 GPUs) with 4 of them running full speed at ~815 with no throttling and the problematic one at ~715 on average, no matter how I try to add external cooling. I'd assume the conductivity from chips to heatsink is problematic, but I'm not going to dismantle it and void warranty unless someone experienced that you can recover a throttling one by e.g. re-applying thermal grease. The heatsink is tightly fixed, BTW.

[rjk]

Wait, so on one instance of cgminer it is slow and on another it is faster? Is it a host system limitation of some kind? Although I doubt that. Did you check to make sure that the heatsink was firmly attached? There have been reports of it dislodging during shipping.

If you mean my setup, no. It's one cgminer instance operating 5 BFL Singles (plus 3 GPUs) with 4 of them running full speed at ~815 with no throttling and the problematic one at ~715 on average, no matter how I try to add external cooling. I'd assume the conductivity from chips to heatsink is problematic, but I'm not going to dismantle it and void warranty unless someone experienced that you can recover a throttling one by e.g. re-applying thermal grease. The heatsink is tightly fixed, BTW.

Sorry I meant Kano.

[kano]

Wait, so on one instance of cgminer it is slow and on another it is faster? Is it a host system limitation of some kind? Although I doubt that. Did you check to make sure that the heatsink was firmly attached? There have been reports of it dislodging during shipping.

The two hosts are in 2 'different' environments.
One is here my desktop and the other is down in the underground basement garage that is clearly cooler.

However ...
... and my overnight run shows that it is indeed exactly ambient temperature related.

So although that does sound like a loose heatsink, I'm still wondering why the temp reported is always below 55°C
(I would say below 50°C but it has now got up to 50.x°C and hovering at 49.1°C - it's now 9:45am)

Last night the weather predicted temp was 9°C and BFL running in the basement got the expected average of 815MH/s
Up to an hour before the last time I restarted cgminer (3:30am) it was still throttling
(of course during an LP is expected, but it was also throttling not during an LP)
The fact that the 5s average was pretty much always at 826MH/s before 3:30am (except during LP) suggested to me that it had indeed dropped to whatever temperature it requires to not throttle

So my guess is one of:
1) the throttling process in the BFL is brain dead/faulty in my BFL (hmm I remember saying something about that in the BFL thread - suggesting it be possible to control the throttling - since hardware isn't always perfect - a LONG time ago)
2) the temperature that cgminer gets from the BFL is unrelated to the temperature used to determine throttling
3) the ambient temperature needed for a BFL is not far above a fridge (close to 10°C) and that should be made abundantly clear

Of course 3) could simply be a loose heat sink - but then 2) would also need to be true

Edit: of course I did email BFL about this 13 hours ago so I guess I'll see what they suggest also.

[kano]

BFL (Sonny) replied with the same suggestion about it being a loose heatsink
(and a BFL replacement if it wont work properly)

Fortunately for me it seems most likely to have been some sort of "burn in" issue
since once the temperature dropped that night after midnight and it stabilised, it hasn't had any more non-LP throttling since, during the almost 2 days and nights since!
(though maybe that is also due to the temperature here being quite cold for the last two days?)

The non-stop stats for almost 1 day 19 hours has been:
817.3Mh/s (A:29504 R:331 HW:0) U:11.45/m

Sonny also said that they will be releasing their miner soon Quote: "I hope to do so within the next week" (no idea what that really means)
but made no mention of the details of the commands to control the throttling that will be in the new miner
I guess we'll just have to wait until it's released and then get the commands out of the miner
(damn annoying decision that one is)

I still have no idea if the temperature reply from sending the "ZLX" command is related to the temperate used from throttling ...

[Inaba]

Easyminer will allow you to flash different firmware.  The thinking goes that if you reduce the max speed, it will throttle less (or not at all) giving you better overall hashrate.

[Tamerz]

Been running mine since yesterday. It is warm in this room and cgminer shows the single at 69 - 70 constantly. It hasn't done any type of throttling at all and stays right around 800Mh/s.

[BFL-Engineer]

During throttle, the device does respond to temperature read, status read, etc.
A new job, however, cannot be issued, as the unit will respond with 'BUSY'.


Good Luck,

[tarrant_01]

I had a throttling single.  I opened it up and the heat sink wasn't attached properly to the board.  One of the 2 spring pins wasn't pushed down.  After securing it, I've had no more issues.  Open it up and check it out or stick something through the vent and see if you can move the heat sink.  If it moves then it needs to be secured.

[kano]

During throttle, the device does respond to temperature read, status read, etc.
A new job, however, cannot be issued, as the unit will respond with 'BUSY'.


Good Luck,

What I mean is that: if I see a temp (ZLX) of 49C is that the same number tested by the throttling firmware that decides to throttle the BFL?
So whatever the first throttling temperate is inside a BFL (when it first drops below 832MH/s), I should see (ZLX) close to that "throttling temperature" just before it decides to throttle?

[BFL-Engineer]

During throttle, the device does respond to temperature read, status read, etc.
A new job, however, cannot be issued, as the unit will respond with 'BUSY'.


Good Luck,

What I mean is that: if I see a temp (ZLX) of 49C is that the same number tested by the throttling firmware that decides to throttle the BFL?
So whatever the first throttling temperate is inside a BFL (when it first drops below 832MH/s), I should see (ZLX) close to that "throttling temperature" just before it decides to throttle?

This is true. Should your unit for instance throttle at 67C, then that is usually the throttle threshold of your unit. Of course, the unit must be
in the same condition as it was the first time (enclosure closed/open, number of fans active, etc). Should one factor change, the throttle
temperature will change with it.


Good Luck,
BF Labs Inc.

[zefir]

Solved!

Tl;dr: dried-up thermal grease was causing thermal resistance between heat-pipe and FPGAs.

First off, thanks to all for your hints and suggestions. For me they didn't work, but they might be helpful for others with related problems.

Then, I need to apologize for calling BFL customer support crap. It is true that none of my emails I sent after ordering my Singles wasn't answered, but that were the times when probably every second miner overrun them with orders or questions. In contrast to that, my request for assistance in this case I sent yesterday got responded within hours with very helpful instructions. Sorry again.

Back to the problem. After none of the proposed approaches to improve cooling worked, I made sure that it is not an ambient temperature issue by running the device in a temperature chamber at 0°C. Same effect with throttling every several minutes and a total hashrate of less than 700MH/s - a strong indication that there was a problem with thermal conductivity between heat-pipe and FPGAs. Assumption turned out right as soon as I removed the heat-pipe: it was evident that the surfaces had only partial contact, since at one FPGA there was a larger blob of dried-up thermal grease that was holding the heat-pipe back from settling down. As a result, one FPGA had almost no contact to the heat-pipe, the other only partially.

I speculate that the heat-pipe was initially placed with one push-pin not fully locked and the grease started to dry-up at the loose side. Later during QA the push-pin was fixed, but the grease was already too viscose to be squeezed out evenly. Or something completely different...

I squeezed the blob manually and distributed it all over the FPGA with my finger to build a thin film, attached the heat-pipe back - et voilá, device is working at full speed with 815MH/s

Was too busy and didn't take any pictures, but it is quite obvious when you remove the heat-pipe.

[bitcoindaddy]

Solved! ....
I squeezed the blob manually and distributed it all over the FPGA with my finger to build a thin film, attached the heat-pipe back - et voilá, device is working at full speed with 815MH/s

BFL, does this void our warranty when we have to do such repairs? Are customers authorized to open the device in cases like this?

[tarrant_01]

When I mentioned replacing the thermal grease on my single that was throttling, they said I could try that and didn't mention the warranty at all.  There are no stickers in place that seal the enclosure. It's a good thing too for obvious reasons.  Quite a few of the singles have throttling issues it seems that require small repairs like the ones mentioned above.  Probably would be a good sticky for hardware or troubleshooting.  A guide on what to do with a throttling single.

[Inspector 2211]

Solved!

Tl;dr: dried-up thermal grease was causing thermal resistance between heat-pipe and FPGAs.

First off, thanks to all for your hints and suggestions. For me they didn't work, but they might be helpful for others with related problems.

Then, I need to apologize for calling BFL customer support crap. It is true that none of my emails I sent after ordering my Singles wasn't answered, but that were the times when probably every second miner overrun them with orders or questions. In contrast to that, my request for assistance in this case I sent yesterday got responded within hours with very helpful instructions. Sorry again.

Back to the problem. After none of the proposed approaches to improve cooling worked, I made sure that it is not an ambient temperature issue by running the device in a temperature chamber at 0°C. Same effect with throttling every several minutes and a total hashrate of less than 700MH/s - a strong indication that there was a problem with thermal conductivity between heat-pipe and FPGAs. Assumption turned out right as soon as I removed the heat-pipe: it was evident that the surfaces had only partial contact, since at one FPGA there was a larger blob of dried-up thermal grease that was holding the heat-pipe back from settling down. As a result, one FPGA had almost no contact to the heat-pipe, the other only partially.

I speculate that the heat-pipe was initially placed with one push-pin not fully locked and the grease started to dry-up at the loose side. Later during QA the push-pin was fixed, but the grease was already too viscose to be squeezed out evenly. Or something completely different...

I squeezed the blob manually and distributed it all over the FPGA with my finger to build a thin film, attached the heat-pipe back - et voilá, device is working at full speed with 815MH/s

Was too busy and didn't take any pictures, but it is quite obvious when you remove the heat-pipe.

Didn't you (or someone else) initially mention that the heat pipe is glued on?
When removing any kind of heat sink, especially a glued-on one, from a BGA package, I always worry about some (non-optimally soldered) balls to come loose from the PCB or the chip itself...
I.e. maybe the adhesion between heat sink and chip package is stronger than the adhesion between solder ball and PCB, or stronger than the adhesion between solder ball and chip.
I would guess that in 99 out of 100 situations my concern is unwarranted, but then again that doesn't help me much if I run into the one case out of 100 where it is not.

[dave3]

When I mentioned replacing the thermal grease on my single that was throttling, they said I could try that and didn't mention the warranty at all.  There are no stickers in place that seal the enclosure. It's a good thing too for obvious reasons.  Quite a few of the singles have throttling issues it seems that require small repairs like the ones mentioned above.  Probably would be a good sticky for hardware or troubleshooting.  A guide on what to do with a throttling single.

You'd think they'd be catching issues like this during the burn-in testing.  I guess not.

[zefir]

Didn't you (or someone else) initially mention that the heat pipe is glued on?
[...]

Yes, I guess that was me and that's your proof of what a noob I am when it comes to HW

When I tried the first time to remove the heat-pipe, I pulled it vertically upwards until I got scared to rip off the chips from the board. With the strong adhesion my wrong guess was that it is glued. Reading the forums and getting wiser (well, kind off), this time I tried it with torque. You still need to be very careful, but as soon as it starts to move you can gently lift it off.

My previously throttling Single works now rock-solid. I did the ultimate test and let it run in the temp-chamber at 28°C (the value I am expecting to have during summer in my basement) and it did not throttle within 4h With that 'fix' you could maybe power up your GPU miner again and keep the BFLs working.

[tarrant_01]

I re-greased one yesterday with only minor improvement.

[jothan]

Solved! ....
I squeezed the blob manually and distributed it all over the FPGA with my finger to build a thin film, attached the heat-pipe back - et voilá, device is working at full speed with 815MH/s

BFL, does this void our warranty when we have to do such repairs? Are customers authorized to open the device in cases like this?

I hope not. I had a pin on the fan plug that was not clipped properly, so I opened it up, clicked the pin and voila !

[Phraust]

I just tried getting rid of the "lumpy" thermal paste and smoothing out what was there, instant +10 mhps on a unit test of 100, and now it appears to be running better.  I'll update in the morning after it's worked all night.

If this is the case, I might as well take them all apart to clean and re-apply a better paste.

[SgtSpike]

I have all 10 of my singles (soon to be 4) lined up in a row, with a 6 inch fan blowing over the top of them.  Not much space between them, yet they still all stay below 60c.

They do NOT like to be stacked!  I tried that, all the ones on top got hot, up to 63c!

[zefir]

I just tried getting rid of the "lumpy" thermal paste and smoothing out what was there, instant +10 mhps on a unit test of 100, and now it appears to be running better.  I'll update in the morning after it's worked all night.

If this is the case, I might as well take them all apart to clean and re-apply a better paste.

I did this for all my BFLS and in fact there was a second unit with dried up thermal grease. After applying fresh one and re-assembling, I found it working more stable.

Meanwhile I found the perfect setup for my batch: three are doing fine with the 864MHz firmware, the other two work stable at 800MHz. It is obviously very important to find the right FW for the devices individually so that they never throttle, as doing so greatly impairs their overall hashing rate. A throttling 832 settles at 710MH/s over a week, while the slightly lower clocked 800M (non throttling) one ends up at 788MH/s. The 864 one averages out at 851MH/s (all results running cgminer for a week).

The 12MH/s you loose from the nominal hash rate at any clock speed seems to be the idle time between delivering shares and getting new work fed. From the numbers this should take ~80ms from each 5.37s cycle it takes to complete work at 800MHz. Pretty sure there will be some improved FW some day that provides pre-fetching of work and caching of shares to prevent the FPGAs from idling. BFL Engineer?

[BTCurious]

Some pictures and info that may be relevant to people here: https://bitcointalk.org/index.php?topic=60586.msg916922#msg916922

[ummas]

Hi i just have joined the "club"

I have got 3 of the singles. One of them slows down a lot.

Code:

 BFL 1:  34.4C         | 802.3/758.0Mh/s | A:8610 R:190 HW:  0 U: 10.28/m

Look at the average hashrate. After night it rised a lot. Before it was sommehink like 650.
I tested this with killo-wat, and i must say one think, it`s not working at all when fornt led is blinking.
Got 3 singles + ztex quad connected to kill-wat, and it shows 300W still, and 230 while throtling.
Look at the temp ! WTF ?
and 3 of them together

Code:

 [P]ool management [S]ettings [D]isplay options [Q]uit
 BFL 0:  43.7C         | 796.1/792.0Mh/s | A:9276 R:167 HW:  0 U: 11.03/m
 BFL 1:  36.8C         | 789.3/757.8Mh/s | A:8652 R:191 HW:  0 U: 10.28/m
 BFL 2:  53.5C         | 801.2/802.9Mh/s | A:9375 R:185 HW:  0 U: 11.14/m

After time spended on writing it, average speed slowled down....

[dave3]

When I first got my BFL Singles I had them running in an air conditioned room (though probably not 72°F).  With the 832 firmware, one of them would throttle.

It seems like the better of the two must have a more powerful fan, as I can feel stronger airflow coming from it, and it's temperature is a bit lower than the other one.

Anyway, I ended up settling on the 816 firmware and both of them run without throttling in an unairconditioned room (around 85°F) and consume about 150 watts together.

Code:

BFL 0:  58.9C         | 811.0/797.6Mh/s | A:2946 R:59 HW:0 U:11.20/m
BFL 1:  60.0C         | 811.0/798.7Mh/s | A:2911 R:68 HW:0 U:11.06/m

They are rev. 3 units, but they've also got external fans mounted on the bottom.  They're noisy, too.  I can hear them mining from the other side of the house.

[ummas]

Mine are rev 3 too, stock id say.
I can hear them over the sound of stock 6990, 5870 MATRIX and 5870 REV2 mining... sick!
I just discovered, that all is fine, except one tinny think, 6990 got exhausts in both ways, and "THE" sinle got hited by hot air...
Small invention, and now i`m waiting for results...

[dave3]

Mine are stock, also, and I haven't tried taking them apart.

I'm pretty happy with them, except for the noise issue.  But that's not a deal breaker.

When they get replaced by their ASIC counterparts, hopefully the noise issue will be solved.

[miaviator]

The Heat pipe is engineered to move heat from the first chip to the second chip and then dissipate that head though the radiator.  A very non-efficient design for cooling.

Since the whole heatsink is globbed on the chips with 10x to much thermal past and the in case design sucks heat away vs blowing cold air on cooling is highly inefficient. 

We saw a huge temperature drop and no throttling (except on newest 896 firmware) after some minor fixes.  I think to get the most out of the units (without spending $$$) and using the existing heat-sink this method has the largest net effect:

1: take the unit out of the case
2: use arctic silver thermal cleanser or rubbing alcohol and remove all of the existing thermal compound.  Replace it with an extremely thin film of arctic silver 5 or better.
3: flip the fans to blow cold air onto the heat-sink vs sucking hot air away
4: Ensure you have two 80MM fans one on top and one on bottom blowing air onto the heat-sinks
5: lay the units on their sides and schedule a layout so as to prevent cross heating
(Use a 19" data rack with a Pyle PFN41 19in fan at every shelf to keep fresh cool supplied to the units)