|
If I could get them sooner without the enclosure and the Raspberry Pi, I'd rather have my 18 boards as-is. OK, heat sinks would be nice.
Speaking of:
I have this theory that at least some of the cooling problems of [few] "problem Singles" originate from a lack of co-planarity between the two FPGAs, leading to a void between heat sink and FPGA at one or even both of the FPGAs. OK, not literally a void, but an area where the thermal paste is very thick, and that's not good.
|
|
|
|
The question is: For what?
Yes, because I don't see a second one that I would assume would exist when used in a daisy chain fashion. Maybe it's just some simple SPI or [point-to-point] I2C digital I/O that will plug into [an I/O board of] the Raspberry Pi. |
|
|
|
That SATA port looks interesting. I was about to post the same thing, but it's labeled "X-LINK" and since a SATA port doesn't make sense (the bandwidth is not that high and the mini rig will have a Raspberry Pi as a controller, not a a PC motherboard with 18 SATA ports), I assume that they just re-purposed the SATA connector and SATA cables for something else. The question is: For what? |
|
|
|
I think he's hinting at us getting him one these  <<picture of flashy car>> Subscribed. Not really my style... though my 10-year-old Kia could use a new taillight. Deal. You send me the bitstream, and I'll get you a new taillight for the Kia. |
|
|
|
Any word on whether or not the 200 chip will be among the first ones available? I'm hoping the availability of that one will prevent people from using the smaller Artices, sort of like how nobody uses Spartan6-LX75's. The Artix-100 is really funny-shaped. Somebody beat that chip with the ugly stick.
No word on that. I agree that Artix-200 will be the FPGA of choice for mining, and the $64,000 question is whether anyone (hint, hint) can fit all 125 stages of a miner into the Artix-200's 156 columns, from left to right (or from right to left), without the dreaded U-turn. Or, to be more precise, whether anyone (hint, hint) can get all 2 x 125 stages of TWO miners into it. The two "parks" (Central Park and Golden Gate Park) for the ADC and the PCIe controller in the left half of Artix-200 certainly don't help with such an endeavor... My experience has been that sequencing doesn't matter if you program via JTAG -- just don't start the JTAG sequence until all supplies are stable. Is there reason to believe Artix-7 will be any different?
Yes, there is! There was a talk just on designing power supplies for -7 chips (Artix, Kintex, Virtex) and this point was stressed. However, most DC-DC controllers have an enable pin, thus enforcing a well-defined power-up sequence is actually quite easy. Not so easy for power-down, but while the power-down sequence is NOMINALLY the reverse power-up sequence, it isn't critical in practice (because the "wrong" condition will only last for a short period of time, not long enough to cause damage). There is a datasheet note that states: "On power-down, voltage w may only be higher than voltage x by y volts for z milliseconds, otherwise the long-term reliability of the chip will be affected", but the lecturer said, this is almost implicitly guaranteed in most designs and should not be of concern to most people. They're probably having to adjust the prices upwards due to the 28nm yield trainwreck at TSMC.
I sure hope not! But I agree with you: While Intel is now shipping 22 nm CPUs in volume, TSMC still hasn't solved the problems with the 28 nm process. Sigh. |
|
|
|
Along with the beta release of our maintenance and diagnostics tool (EasyMiner), we're making an experimental firmware available for running your Singles at a faster than stock 864 mh/s.
BFL
I think you mean faster than stock 832 Mh/s No, the BFL spokesperson said it correctly, if a little bit confusingly - I'm adding parentheses for clarity: we're making an experimental firmware available for running your Singles at a (faster than stock) 864 mh/s |
|
|
|
I just looked at their site and downloaded their new EasyMiner. I'm on my playbook atm, so that's not going to do me much good.  Has anyone started using it yet? I'd like to see some screenshots! Interesting.  I forgot to shut off cgminer first, so it seems to have hung here. Not sure whether to abort or not. I hit the "run a test" button, and the small box popped up saying it was going to do a firmware update. EDIT: I hit "abort" and it changed the display to "aborting..." but still didn't close. I then closed cgminer and nothing changed. I started cgminer again, and it started mining as usual. I don't mind if these windows want to take their time closing, but they are modal on top of everything so they are annoying. EDIT EDIT: I hit "quit' in the main window, and it quit instantly. The $64,000 question is: Did they include new firmware that performs better than the typical 826 MH/s? |
|
|
|
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. |
|
|
|
|
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.
|
|
|
|
I think your queue position is determined by the payment date, and not by the confirmation date.
Confirmation Date = Payment Received Date ?!? I think it's determined by the order date. Payment received date occurs later depending on the method (paypal probably takes longest) then they "confirm" as soon as they see that they have payment. No. It took me about a week to get deposited checks cleared prior to the Mini Rig wire transfer, and the wire transfer confirmation by BFL then referred to the wire transfer date as the queue position, not the order date. |
|
|
|
I'll have to snip the leads to the bottom fan
For simplicity in testing, I'd recommend just taping down the fan blade to keep it from spinning, or another low-tech method of restriction (a piece of chewed gum?). If you get some thermal throttling, it's easy to make it spin again. I would advise against that - a stuck motor can draw a multiple of the wattage that it normally draws, and thus overheat, even burn out. |
|
|
|
Ordered: Feb. 25 2012
Confirmed: March 7th 2012
Shipped: May 2 2012
Quantity: 2
So they are down to about 8 weeks from order confirmation to shipping? I hope this trend keeps up. about 9 weeks  Big difference for the waiting man... I think your queue position is determined by the payment date, and not by the confirmation date. |
|
|
|
I just got 2 singles, one came with the heatsink not fastened down. The plastic part holding it down was broken. I don't think it could have happened during shipping, it was packaged pretty well. The other single averages 710 m/hash with cgminer, and runs about 7 degrees hotter. The one with the broken heatsink performances at advertised speeds atleast, around 820 m/hash. Anyone else seeing speeds down at 710 m/hash?
If you have one of these ordered, don't expect a email letting you know when they mail it.
I see 710 MH/s AVERAGE for the one Single which is throttling, or I should rather say "saw", as turning off a GPU rig seems to have reduced the room temperature enough for this "problem" Single not to throttle anymore, and for me to keep my shirt on when I work there. |
|
|
|
ummm... Nice board but I think 1 hole in the center might be a problem for me. I had plans to water cool this baby. Oh well, I guess I have to suck it up lol. Thanks for the img btw.
The holes on the corners of each FPGA are setup to take standard northbridge heatsinks. Which means any northbridge standard waterblock should work just fine using through-hole mount available on this board. Yeah but you can't mount 4 heatsinks or blocks with only 1 hole in the middle. I would be more interested in one large heatsink which covers all four fpga. What if the four FPGAs are not precisely co-planar? Are you OK with one or two of them running hot because the heat sink does not completely touch it/them? |
|
|
|
I'm thinking about replacing the fans on my singles with something that has a bit more oomph. Are there any published specs on this to anyone's knowledge?
+1 |
|
|
|
|
Order date: 2-23-12 (qty. 4)
Ship date: 4-30-12
Arrival date: 5-2-12
Seems like the shipping delay is coming down further, towards 2 1/3 months or even 2 1/4 months.
|
|
|
|
Thanks for the tips on the PSU's guys, but I already was pretty sure that was the route that I wanted to go eventually. But considering that only 7 out of 8 of my singles have power now, it's just forcing my hand a bit sooner than I was expecting. I will probably end up getting a 80+ gold PSU and some stuff from Cablez, if just to reduce the rat's nest of wires that is my room right now. I cut off the +12V cables from BFL's made-in-China supplies, put crimp terminals on them and wired six singles to a 600W single 12V output Vicor Power "Flatpack" supply, which I already had. The two other singles are still powered by the original supply and will probably stay that way for the near future. When the remaining four Singles arrive (any day now), I'll wire one of them into the above-mentioned 600W supply and the three others into a 300W Vicor power Flatpack. These Vicor Power Flatpack supplies are awesome, if expensive. But I already had them from a former [unsuccessful] business venture. |
|
|
|
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... |
|
|
|
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... |
|
|
|
|
Order date: Jan. 31st, 2012 (qty. 2)
Order data: Feb. 10th, 2012 (qty. 2)
Received: April 27th, 2012 (qty. 4)
Looks like they are coming down from the 3 month delay towards a 2 1/2 month delay.
|
|
|
|
|
Show Posts
