Some senior moment at my side, I guess. This thread became too long but I remember a discussion with xiangfu that due to the way how an Icarus is detected (you have to feed some work and check the resulting share for success) there are corner-cases where it becomes unreliable (like looking for a BFL first can kill its state-machine). That was when the initial Icarus support was planned, and since it works for you it was obviously solved meanwhile.

You're always friendly and respectful, just my reference on how people should behave on this forum to make a better community.

As for the Singles in your bedroom: water-cooled ones ahead in the pipeline. Time for you to silently raffle away your old loud ones for 150% resale value

Topic: true, there is no hot-plug support for FPGAs implemented. I understood that it's not safe since auto-detecting routines between different board types collide, i.e. if you scan on serial port X for a single and have actually an Icarus attached, you'd hang in a loop (or vice-versa, not sure).

What I noticed as problematic (but this might be a Linux specific thing) is, I added cgminer to the autostart service and it usually worked fine with the GPU setup and assured that system is automatically restarted when a card hangs. With the 5 BFLs attached I see every now and then that only two or three of them are detected immediately after reboot. Re-starting cgminer activates them all again. Kind of bad if you plan to leave your miner unattended for two weeks


Edit: sorry you talked about hot-removal, not hot-plugging. With Linux you do not stop cgminer completely. You just stop the threads dedicated to that BFL. If it was the last/only one, then cgminer stops, but otherwise it just continues with one unit less (though statistics are displayed further, no indication that device is gone). Plugging the unit back will not make it operating again automatically.

Ist wahr? Ok, wir sind hier nicht sehr früh in den Bergen Jetzt habe ich doch beim Lachanfall Wein in meine Tastatur gekippt...

Nacht.

Du hast jetzt nicht absichtlich 'Fred' gesagt, sondern dich verschrieben, oder? Sonst wäre das echt der Brüller den ich mal bei mir im Klub bringen müsste 

Oder ist es das neueste Neusprech, was noch nicht bis in die Schweiz durchgesickert ist?

Tschuldigung, ich lach mich grad schlapp... Du hast meinen Tag gerettet, danke!

Thanks Epoch for taking your time!

Yes, I'm running my setup from a Linux machine and did most of the measurements with cgminer-2.3.5. Plus, the same process is driving 3 GPUs worth 1.7GH/s that did not suffer while dealing with the throttling Single. I'm building an OpenWRT router to control the proper working units and leave the throttling one attached to the GPU rig.

Lucky you, you had to force your BFL to throttle

Thanks again. Sent you a coin to at least compensate you for the loss of hashing power during measurement.

Thanks for the feedback, BFL.

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.

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...


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

Con, Luke,

this is from another thread to sort out issues with a throttling BFL Single I have in my 5-unit setup:

In short, what I am observing is: the one throttling device reproducibly reduces the all-time-average hashrate of the non-throttling devices reported by cgminer (Linux, 2.3.5). I am not sure whether this is just a measurement error or if my assumption with the stalling communication thread causing lags sounds reasonable.

Con, you're da Linux scheduler guru. Any ideas? Since you have no Singles at hand (and even more no reliably throttling ones), I'd try to implement and test potential fixes myself if you had some ideas. Or do you have a throttling one, Luke?


Thanks, 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.

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

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 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.

Got my 5 Singles today. Shipment to Switzerland took 5 days.

I paid 300CHF (~330US$) for customs (8% + 70CHF handling fee).

A rock solid analysis as always, DaT.

I admit that I missed to protocol occurrences of farts or similar potential influences on the results, so your claims are valid.

Alas, let's put Poisson aside for a short while (advanced stochastic is no friend of mine  ). At a lower understanding level, if I repeat 12 measures (6 times with and 6 times without stimulus (CPU stress here)) over 120 minutes - how probable is it to have 6 times 1% higher average hashrates with the stressed CPU than compared to the control measures only through variance? Isn't that 1/32, corresponding to ~97% confidence (if we treat the results as binary)?

Thanks for the insight into validity of those mid-term hash-rate estimations. Though, in this case I guess P4man is on the right track:
Bingo! I set CPU clock to fixed 800MHz with 'CPU Frequency Scaling Monitor' when I installed the rig and did not notice (headless system) that it is adjusted to 2.8GHz when on full load. You're fully right, if I disable Cool n Quiet in the BIOS and the CPU runs at full speed, I get same numbers without stressing it.

Mystery solved. Thanks!

I'm with you folks: can't believe what I'm saying, but the measures still hold.

RFT here stands for 'request for test', so if you're in the mood just repeat the test (it's really trivial) and report your measures.

Other speculations on why this can't be are useless, since we all agree that this theoretically should not work.

Thanks, zefir

In my setup I buy the additional 18 MH/s for 10W, which is slightly worse than my average efficiency of ~2.3MH/J. This might turn to the positive side if you had a 3*5970/6990 setup.

As for the 10W delta, that is what I measure. I also expected a more significant jump, but it seems that running cgminer the CPU never enters those low power states where it is said to use only 9W. I'd guess the delta is between 28 and 39W.

BTW, since my miner is pointing to your pool, if you had long-term stats we could even check if there is a difference in effective hashrate.

True for one shot measures.

But as said, I based the results on my long term hash rate from running the miner continuously for more than a week. Plus running the mid-term measures (2h+) repeatedly gives perfect correlation.

As for the 1%, given that the GPU mining SW potential is nearly maxed out (OpenCL guys are fighting for the last 0.x% gains), 1% is huge.

Seriously, I won't buy this if I heard from someone else. But it is easy to test - just give it a try and report your results.

Edit: Mystery solved.
P4man had the right idea: as long as CPU frequency management is enabled, stressing the CPU will force it to run at max speed that is also beneficial to miner SW. Additionally, DeathAndTaxes clarified the reliability of mid-term hash-rate measures that need to be considered to estimate the potential improvement.



Hello miners,

I observed something I fail to fully understand and post here for you to confirm and maybe take advantage of.

Recently I had to generate some personalized addresses with vanitygen. I first ran it on my laptop but soon found it not acceptable, since it will take days and generate heat and noise in my office. The only thing keeping me back to offload that task to the miner in my basement were doubts that it might negatively influence the mining performance.

Tl;dr: it did not, stressing the CPU increased my GPU hashing power by ~1%

Details:
Mining with Ubuntu and latest cgminer, my long term average hash-rate is about 1732MH/s (2*7970+1*6950). The CPU (Sempron 145) is mostly idling, system draws 750W at wall (not optimized: uses HD for cgminer development, not down-clocked CPU and GPU-mem, etc.).

After about an hour running vanitigen (100% CPU load: 97 for vanitigen, 2 for cgminer), the short term average increases by 1% to 1750MH/s. The power draw is then at 760W.

To eliminate some mid-term fluctuations caused by pool issues or local temperature extremes, I repeated the tests several times, either

• start and run it without vanitygen for ~2h, start vanitygen and see the average GH/s settling to a +1% average
• start and run with vanitygen runnng for ~2h, stop vanitygen and see the hashing power decreasing by 1%

I suspect this could be an effect of the CPU power saving features effective when CPU is idling and being disabled when CPU is fully loaded. Also, it might be that the Linux scheduler is more reactive when not entering the idle-task. Or some cgminer related thing that is specific to my setup.

Whatever, YMMV, but if you can reproduce, please share your results. With my low-scale setup the increased power cost roughly matches the performance gain, in higher scaled setups (e.g. 3*5970/6990) the gain might outperform the cost. Plus you can stress the CPU with mining instead of running vanitygen for some extra coins


Good Luck!

tracking # received:

Ordered: 01/30/2012
Confirmed: 02/02/2012
Shipped: 04/20/2012
Qty: 5

Here's what confuses me: from what you write it sounds like you plan to stuff the card into the BFL Single, which most probably won't work . I assume you plan to set up another computer to control your Single(s) that has a free slot for your 5830 - and that should work. When your BFL device arrives (somewhere in June, good luck),  I'd first try the cgminer integrated control (they really are very effective and reliable) before bumbling around with external tools.

Hi runlinux,

As agreed via PM

• 140 BTC sent to 1M6NRvtEWGv45jhozVpcayNjp8PF3z53HQ [1]
• 161 BTC to be paid back to 1CYHqXpMmQzNnu75iAuXGwbCMajUn1WMaZ on Monday, April 30th.

Please confirm.

[1] http://www.blockchain.info/tx-index/3681459/fe45871f6893e2ee16842bde0a0fc6cd3d14d493e88dbb573a78ef0062ca1372