EDIT: Regarding Linux distribution, we always use the latest. Never had problems. Are you using a normal computer or some RaspPi or Beaglebone for the Linux Setup?
Tried it on both a regular laptop and a RPi. I suspect the RPi is out of date with the drivers, but the laptop I had fully updated with ubuntu and all of the bfgminer dependencies, so I am not really sure what's up with it. Dear Morblias, I just asked people in the lab to create a fresh install of Ubuntu 12.04 LTS and clone the latest Bfgminer, just to be sure everything is work. The test passed successfully. For your information, the computer in test was 64bit. Thanks, Nasser |
|
|
|
The images you show are actually hashing at 680GH not 620GH (For some reason, the Job-Rate is shown less than Nonce-Rate in Bfgminer, you might want to confirm this with your pool). Yeah you are correct, the pool is showing 680gh/s. Works great on my Windows 7 machine. Just curious, which distribution of linux are you using? I was trying it on Ubuntu 14.04.1 when I was having those issues. Could it possibly be a driver issue causing it not to work on mine? I suspect it should be a driver issue, because the firmware and the card is the same, and bfg is bfg, but windows has some problems and linux doesn't have any. It must be OS related. I don't think we'll use FTDI For our next generation products. EDIT: Regarding Linux distribution, we always use the latest. Never had problems. Are you using a normal computer or some RaspPi or Beaglebone for the Linux Setup? Thanks, Nasser |
|
|
|
We have never faced this in the many boards we tested in lab. I would suspect a weak solder joint somewhere, or some issue with this board which went undetected.
@Morblias: You could send this board for replacement. Please let me know if you do so and when so I can accelerate the process and also see what's wrong with this board.
However, if you have the possibility of testing this card on another computer, it would be very helpful, as the issue may come from the actual computer / driver that you're using.
Thanks,
Nasser
I tried it on my RPi (with minepeon) and ubuntu 14. Both came up with those same errors. Then I tried it on a windows 7 64 bit machine, and this happens, except it continues to hash after the errors. On the linux ones it would just stop hashing completely, but the windows one continues around 620gh/s. I found another USB cable and tried that also with no luck. Still happens on all of the computers. 620gh/s isn't too bad though, so I might just leave it on the windows machine.  The images you show are actually hashing at 680GH not 620GH (For some reason, the Job-Rate is shown less than Nonce-Rate in Bfgminer, you might want to confirm this with your pool). Also when a unit mines and then stops, it still has job-results in it's internal buffer. Upon restart, bfgminer will see those results but won't recognize them (as it doesn't know source of those jobs), hence you get a "Was not able to find work for result". It's basically information, and should not be considered a failure. I have already talked to Luke, and we have discussed a recovery mechanism that can be implemented on the Host-side if a USB packet gets corrupted (for Windows). On our own, we don't see these issues in our lab, especially on Linux (On windows you do get an error every once in a while, but never affects speed or cause failure). EDIT: I will be shortly publishing a special built of Bfgminer (version 4.2) which was custom-built and doesn't have slowdown/failure issues on windows. Please let me know if you had any questions. Thanks, Nasser |
|
|
|
|
We have never faced this in the many boards we tested in lab. I would suspect a weak solder joint somewhere, or some issue with this board which went undetected.
@Morblias: You could send this board for replacement. Please let me know if you do so and when so I can accelerate the process and also see what's wrong with this board.
However, if you have the possibility of testing this card on another computer, it would be very helpful, as the issue may come from the actual computer / driver that you're using.
Thanks,
Nasser
|
|
|
|
|
Dear Morblias,
Do you have the possibility of running a bfgminer on Linux to check if the same issue persists?
Also, is it normal that you are getting 228GH instead of 700GH for Nonce-Rate? or it has happened in this instance only?
Regards,
Nasser
|
|
|
|
OK so i ordered a Jall base model on the 23rd of june 2013 and i ordered the upgrade a week later.
just checked the BFL Blog and....
Jalapenos 4.5 and 5 gh/s: Feb 12-14, 2013 no Jallys shipped today
have they halted production on the upgraded units?
Dear Techkojj, To address your concern, production of jalapenos have not been halted, and we have been producing them at very high-speed since the beginning (as it's easier to assemble). Thanks, Nasser |
|
|
|
Please note that the two reported temperatures from the single-sc are not everything. This values are coming from two sensors, which are somewhere between a 8-ASIC cluster and the +1V regulation for this cluster. They are not in the ASICs or inside the 8-ASIC cluster circuit nor inside the +1V regulation circuit.
Even if you may see only a small temperature increase by changing the fans or even see a decrease by changing the whole setup by e.g. opening the box or something like this, it doesn't mean that the ASIC's or any other important parts are not getting much more hot than they should. Also watch the hardware error rate carefully!
Soon I'm ready to report my results from looking for fan alternatives....
In effect, what you are saying is...the chips are actually hotter than reported. Correct? Is that a good thing? Not necessarily. The DC/DC supply generates a significant amount of heat as well, and doesn't have the benefit of the nice heatpiped cooler attached to it. It's possible that the temperature reported from the sensors close to the output inductor could be higher than the die temperature. Is the next generation (Monarch) going to have a true (die level) temp sensor? The current BFL chip has an on die temperature sensor, they just aren't using it. If I had to guess it's a cost issue; it's cheaper to toss a couple 20 cent temperature sensors on the board that it is to properly mux and read 16 temperature diodes. It turned out that the MOSFET zone usually gets to be the hottest region on the PCB. As a result we use our temperature sensors on board for sensing temperature, otherwise the on-die temperature diode is fairly easy to read (Just check the voltage drop across the diode and you have the temperature). Regards, Nasser |
|
|
|
Just today I've got my 3 BGL 60Gh\s miners and they are not working.
I've got - BitFORCE SHA 256 SC new device in control panel(windows 7 64bit) and this device is with exclamatory sign.
I've tryed BFG miner but it's doesn't detect any ACIS hardware- only see my videocard.
WHat exactly happens? can anybody answer me?
Please try re-installing the VCP drivers are mentioned in earlier posts. If you still have difficulty with it, you can reach me at nasser@butterflylabs.com. Regards, Nasser |
|
|
|
On the bflfraud site, you can see the guy's partner saying he called up BFL and paid extra money to take earlier delivery of minirigs from people who simply bought them online via their website. ie : paying to skip in line
(edit : I didn't read the whole thread so maybe this was already mentionned. Sorry it that is the case)
We don't do that... it's immoral and dishonest. Regards, Nasser |
|
|
|
I must add two small notes:
1) The true number of employees involved in the process are at least several thousand. You must include all the employees that are involved in FedEx for example (or any other carrier we use to ship different components around), to employees in all the companies in the supply chain, PCB and assembly divisions, Wafer Foundry, etc ... The list goes on and on.
2) The sensitivity in our situation comes from the fact that initial delays were incurred. Long story short, at best we could have added 2 months error margin to the initial timeline given to us (which we did). In order to know what the exact delay is going to be (in any project), you need to know the future. We would've purchased a crystal-ball to let us know in advance.. but the company that makes crystal-balls just went out of business...
Regards,
Nasser
I am sorry to have to correct you, but at best you could have added a 10 month error margin. Then you would be shipping on time, instead of very very late. Other companies manage to use FedEx without being 10 months late. They also manage to make PCBs without being 10 months late. Indeed the list goes on and on. Even at this late juncture, you are still pushing your own failures off onto other companies. If you can't manage to ship things via FedEx, you probably shouldn't be selling things over the internet. We could have added 10 years of error margin as well. But to know the exact number, you need to know the future. Regards, Nasser P.S. The FedEx example was used to demonstrate how little logistic elements can affect an active production line, it was not related to the initial delay in any way. |
|
|
|
|
I must add two small notes:
1) The true number of employees involved in the process are at least several thousand. You must include all the employees that are involved in FedEx for example (or any other carrier we use to ship different components around), to employees in all the companies in the supply chain, PCB and assembly divisions, Wafer Foundry, etc ... The list goes on and on.
2) The sensitivity in our situation comes from the fact that initial delays were incurred. Long story short, at best we could have added 2 months error margin to the initial timeline given to us (which we did). In order to know what the exact delay is going to be (in any project), you need to know the future. We would've purchased a crystal-ball to let us know in advance.. but the company that makes crystal-balls just went out of business...
Regards,
Nasser
|
|
|
|
Also Posted in Pre-Sales at BFL Forum
MiniRig Line:Concerned
Via Jody's blog, we can conclude the minirig line made ZERO progress from roughly August 15th until today. It seems ONE 500 GH/s unit has been completed since then (as seen on Jody's Update yesterday). If only one 500 GH/s unit has been completed since the 15th, which is 8 days...How, at ONE 500 GH/s unit EVERY 8 DAYS, will BFL ever complete the backlog?
If BFL is purposely slowing the Minirig line, to force big-money investors to switch their investment to the Monarch line, this would be very troubling.
I welcome BFL to clarify why this line, which so much money has been dumped into by customers, is moving so slowly...Neglect, lack of coordination, or fraud?
Also, since I have 1.5 TH/s to my order...Can I assume, at one 500GH/s rig every 8 days, my order will take 24 DAYS to build and fulfill?
Thanks for your time
PS: I'm not an angry troll, I've invested in the Minirig line and I'm extremely concerned at the lack of progress. And seemingly no effort to correct it..
Are no other MiniRig purchasers as concerned as I am?
Hello EvilLizardApparel, Just wanted to let you know that MiniRig line was not slowed down in any way, we were just waiting for new boards to arrive to the facility. Regards, Nasser Unacceptable Nasser. BFL has had plenty of time to foresee this and if any part should be slower, its the chips and that is it. BFL has dropped the ball in a time when your customer has few options being that your orders are all pre-orders. If you want to do real customer service, them your big customers how your are going to compensate them for your internal delay because of a lack of foresight. Having a 100% error-free production line, means around several thousand employees in several different companies must function as precise as atomic clocks do, with absolutely no human-error. Even robots cannot achieve that, let alone humans. We will do our best to make sure a huge number of products get shipped everyday. Regards, Nasser |
|
|
|
Also Posted in Pre-Sales at BFL Forum
MiniRig Line:Concerned
Via Jody's blog, we can conclude the minirig line made ZERO progress from roughly August 15th until today. It seems ONE 500 GH/s unit has been completed since then (as seen on Jody's Update yesterday). If only one 500 GH/s unit has been completed since the 15th, which is 8 days...How, at ONE 500 GH/s unit EVERY 8 DAYS, will BFL ever complete the backlog?
If BFL is purposely slowing the Minirig line, to force big-money investors to switch their investment to the Monarch line, this would be very troubling.
I welcome BFL to clarify why this line, which so much money has been dumped into by customers, is moving so slowly...Neglect, lack of coordination, or fraud?
Also, since I have 1.5 TH/s to my order...Can I assume, at one 500GH/s rig every 8 days, my order will take 24 DAYS to build and fulfill?
Thanks for your time
PS: I'm not an angry troll, I've invested in the Minirig line and I'm extremely concerned at the lack of progress. And seemingly no effort to correct it..
Are no other MiniRig purchasers as concerned as I am?
Hello EvilLizardApparel, Just wanted to let you know that MiniRig line was not slowed down in any way, we were just waiting for new boards to arrive to the facility. Regards, Nasser |
|
|
|
|
To clarify one thing, when the __PRODUCT_JALAPENO or __PRODUCT_LITTLE_SINGLE is selected, the crystal used for the MCU should be 16MHz. However for SINGLE or MINIRIG models, then the crystal
used should be 12MHz, otherwise the Frequency of the ASICs is going to be incorrectly calculated (that is where you get 320MHz speed report, etc).
Regards,
Nasser
|
|
|
|
This is hilarious... I actually have some BFL hardware and even I think this means they are finished.. They are obviously trying to move payments to a medium that cant be refunded (bitcoin or wire xfer). They are using a design which alot of us *know* cannot dissipate that much heat, and they are moving at a snail's pace with current orders.
Guys... Ive never said this before, but i believe they are on the virge of folding and taking anyone who preorders money with them..
Regarding power consumption, Radeon 6990 both consume more power than our card does, the very reason we took this design approach. Regards, Nasser EDIT: Corrected '5970' and '5870' to 6990 Simple mistake for a Persian engineer to make late at night in France on a Saturday. It's 3:00 AM Paris time, and I do enjoy reading threads usually. Nasser |
|
|
|
From the BFL website:  Plus Due to double node jump, the max power should be 0.77W/GH (3.1W/GH divided by 4). Based on everything we know from any chip industry (FPGA, CPU, GPU, etc), that should be the ceiling in power-consumption.
Regards,
Nasser
Picture says 600 GH/s @ 350W. BFL "engineer" (who's area of expertise is Visual Basic and .NET) says 0.77W per GH/s Unfortunately, multiplication says 600 GH/s * 0.77W per GH/s = 462W Based on everything we know about multiplication (FPGA, CPU, GPU. etc) that should mean you are just as good at guessing TDP in August of 2013 as you were in August of 2012. If you read carefully, it's noted that 0.77W/GH would be ceiling due to node jump, not taking any optimization or correction into consideration. The actual numbers are lower, and the ~0.6W/GH was number we decided that was closest to reality + error margin. Regards, Nasser |
|
|
|
I think around 1W/Gh is a more reasonable estimate, that would be the number I will be running with for making future energy consumption estimates. 0.58 (BFL site) or 0.77 (Nasser) just seems too optimistic given history of both BFL and other companies.
Will
Every opinion is respectful. I'm happy we were able to resolve even the most challenging issues we encountered in the past. We will always look forward into making better products for our customers. Regards, Nasser |
|
|
|
This is hilarious... I actually have some BFL hardware and even I think this means they are finished.. They are obviously trying to move payments to a medium that cant be refunded (bitcoin or wire xfer). They are using a design which alot of us *know* cannot dissipate that much heat, and they are moving at a snail's pace with current orders.
Guys... Ive never said this before, but i believe they are on the virge of folding and taking anyone who preorders money with them..
Regarding power consumption, Radeon 5970 and 5870 both consume more power than our card does, the very reason we took this design approach. TDP of 5970 is 294W and 5870 is 224W. The card is reported to be 350W which is significantly higher not lower. Still this is AMD and even with three decades of experience the 7990 (375W TDP) was delayed by six months due to power/thermal issues that they found challenging to resolve. While 350W is possible in that form factor one would have to be willing to bet that a) BFL hasn't been overly optimistic in power simulations (unlikely every other product in the past). 350W is cutting it close, 400W would be nearly impossible b) BFL doesn't run into any cooling or power problems due to the high energy density. Something that has plagued even veteran companies like AMD and NVidia. As for 350W being realistic. Well it is 0.6 w/GH. BFL current chips are 3.1 w/GH. A die shrink generally cuts power consumption by 40% (you stated upthread up to 60% but that would be rather optimistic don't you think). 28nm is two die shrinks from current chip. So 3.1 w/GH * 0.6 * 0.6 = 1.1 w/GH. Ouch. 1.1 * 600 = 660W. Now you did indicate you opimtized the chip but that is a rather significant optimization wouldn't you say. Nearly an 86% performance per watt. Intel is happy for a 5% to 10% improvement in performance per watt (outside of die shrinks). Given the aggressive improvement in performance per watt necessary, combined with the lack of any headroom (if it misses by even 20% then it can't be cooled in that form factor at that speed), it would need to be a nearly flawless design and execution from start to finish. It certainly "can" be done but given BFL past promises on power and cooling well one would be betting that "this one will be different". Regarding 5970 and 5870, it was my mistake looking at some charts (I'm not good with GPUs generally), what I meant was 6990. The actual design was modified, stray capacitance and flip-flop instability was resolved (which were causing the majority of consumption). The numbers we have are lower, and were reported here with margin. The migration between Stratix 3 and Arria 2 GX (Original single vs. MiniRig FPGA cards), proved a 50% reduction in power. As both were doing SHA256, taking 50% for this case would be a reasonable number. Including the corrections made to stray capacitance and flip flop instability, the final figures arrive at an even lower number. The number announced by us is the worst case scenario based on what we have in our hands; however, as stated, these are estimations. Regards, Nasser |
|
|
|
Regarding power consumption, Radeon 5970 and 5870 both consume more power than our card does, the very reason we took this design approach.
Yeah, but what about when the power doubles from your pre-fab estimates, like every other chip you've built? Due to double node jump, the max power should be 0.77W/GH (3.1W/GH divided by 4). Based on everything we know from any chip industry (FPGA, CPU, GPU, etc), that should be the ceiling in power-consumption. Regards, Nasser |
|
|
|
|
Show Posts
