Bitcoin Forum
October 22, 2017, 01:31:05 AM *
News: Latest stable version of Bitcoin Core: 0.15.0.1  [Torrent]. (New!)
 
   Home   Help Search Donate Login Register  
Pages: « 1 2 [3] 4 »  All
  Print  
Author Topic: BFL ASIC Firmware & Hardware, Understanding & Optimization  (Read 15248 times)
BTC-engineer
Sr. Member
****
Offline Offline

Activity: 346



View Profile
September 02, 2013, 11:45:52 AM
 #41

Firmware version 1.2.8 is released. I will test it soon.
It looks like there is a way to use ENGINE_ZERO if the ASIC has revision B, but BFL seems to worry about heat-problems.
I can only repeat myself by saying that one of the most important things is to have a good airflow through the box.
With my improved fan plates, the box is not only quieter, you have also way for hashrate improvements.

---------------------------------------------------------------------------
/*************** Firmware Version ******************/
#define __FIRMWARE_VERSION      "1.2.8"   

// **** Change log Vs 1.2.7
// - An option introduced that disables Engines 0 and 1 on all chips. This is to throttle the speed so the unit won't overheat
//   ( in std_defs.h named as DISABLE_ENGINE_ZERO_AND_ONE_ON_ALL_CHIPS)

// **** Change log Vs 1.2.6
// - Engine 0 operation supported
// - Auto detect if chip is Revision B or A (Revision B has engine 0 functional)
// - Blink issue resolved. Now it blinks for 30seconds instead of 300ms
----------------------------------------------------------------------------
1508635865
Hero Member
*
Offline Offline

Posts: 1508635865

View Profile Personal Message (Offline)

Ignore
1508635865
Reply with quote  #2

1508635865
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1508635865
Hero Member
*
Offline Offline

Posts: 1508635865

View Profile Personal Message (Offline)

Ignore
1508635865
Reply with quote  #2

1508635865
Report to moderator
BTC-engineer
Sr. Member
****
Offline Offline

Activity: 346



View Profile
September 02, 2013, 06:44:30 PM
 #42

I've just tested firmware 1.2.8 on one of my singles.
It looks like this single, which is my latest one received ~2 weeks ago, has not yet Revision B chips inside.
Anyhow, I could not reach the overall hashing performance, which I reached with 1.2.6. So I switched back to 1.2.6. To be fair, I didn't spend a lot of time with the new firmware. I will test it again, when new singles arrive.
Cablez
Legendary
*
Offline Offline

Activity: 1400


I owe my soul to the Bitcoin code...


View Profile
September 02, 2013, 06:58:56 PM
 #43

So what your saying is with older versions of the hardware, newer firmware doesn't really bump performance any and doesn't seem to be worth the flash?

Tired of substandard power distribution in your ASIC setup???   Chris' Custom Cablez will get you sorted out right!  No job too hard so PM me for a quote
Check my products or ask a question here: https://bitcointalk.org/index.php?topic=74397.0
BTC-engineer
Sr. Member
****
Offline Offline

Activity: 346



View Profile
September 02, 2013, 07:28:15 PM
 #44

So what your saying is with older versions of the hardware, newer firmware doesn't really bump performance any and doesn't seem to be worth the flash?

Well, that's not exactly what I said or would like to say. I would not say it so much in general like your consumption.
I used a SINGLE-SC in the 5xx serialnumber range, which I received ~2weeks ago. Flashing the standard 1.2.8 firmware into this single gave me a significant lower hashing rate than me already tuned 1.2.6 firmware. This was not soo much surprising for me. But after tuning the 1.2.8 firmware in nearly the same way I did it with the 1.2. 6 firmware, I still could not reach the hashing rate of my tuned 1.2.6 firmware. Maybe there are other ways to tune the 1.2.8 firmware to get better results. However, with the standard 1.2.8 firmware I could not see any improvement in hashing-rate over the standard 1.2.6 firmware with my single, which seems to have revision A chips.
vitruvio
Sr. Member
****
Offline Offline

Activity: 467



View Profile
September 02, 2013, 07:50:52 PM
 #45

I'm now wondering what these two defines in the firmware do... Anyone experimented with them?
//#define __CHIP_BY_CHIP_DIAGNOSTICS      
//#define __ENGINE_BY_ENGINE_DIAGNOSTICS

I'm imagining more in-depth self-diagnostics on bootup, but if there is a chance the chip-by-chip diagnostics would allow individual chips on boards to reclock to higher maximum speeds it would definitely be interesting to play with...

Also, I've been working on a windows program to make it easier to grab statistics from BFL Bitforce SC gear. Far from complete yet and it only supports FTDI drivers, but its available from http://randomcontent.wolfnexus.net/RandomSite/files/2313/7776/5140/RW2-BFL-Commport-Scanner.zip

Yes it is an executable, but I can promise it does nothing malicious. Below is a summary of how it works.

Startup - unpack required wrapper DLL from within using reflection
Check for running cgminer or bfgminer instances. Display warning if found, lock interface and skip subsequent scans
Scan for FTDI devices using WinUSB driver, if found display warning
Scan for FTDI devices using unknown driver, if found display warning
Scan for FTDI devices using FTDI driver, identify which of these are Bitforce SC units and add them to the listbox

On selection from listbox, enable scan device button. If nothing selected in listbox, ensure button is disabled

On scan, open port based on device serial number. Issue ZCX, ZTX and ZLX commands and populate relevant fields on the user interface.

Thats about all there is to it, besides some other bits of logic to keep the UI clean.
If anyone finds any bugs, please let me know. I've done four or five iterations so far to fix major bugs.

Again, this is a Windows only program, and has been tested on XP and Windows 7 so far. It is written in .Net (because I am lazy) and isn't really open source, although I'm happy to discuss the code if anyone is interested.

Sorry but my antivirus is unhappy with your software

bcp19
Hero Member
*****
Offline Offline

Activity: 532



View Profile
September 02, 2013, 07:57:36 PM
 #46

I'm now wondering what these two defines in the firmware do... Anyone experimented with them?
//#define __CHIP_BY_CHIP_DIAGNOSTICS      
//#define __ENGINE_BY_ENGINE_DIAGNOSTICS

I'm imagining more in-depth self-diagnostics on bootup, but if there is a chance the chip-by-chip diagnostics would allow individual chips on boards to reclock to higher maximum speeds it would definitely be interesting to play with...

Also, I've been working on a windows program to make it easier to grab statistics from BFL Bitforce SC gear. Far from complete yet and it only supports FTDI drivers, but its available from http://randomcontent.wolfnexus.net/RandomSite/files/2313/7776/5140/RW2-BFL-Commport-Scanner.zip

Yes it is an executable, but I can promise it does nothing malicious. Below is a summary of how it works.

Startup - unpack required wrapper DLL from within using reflection
Check for running cgminer or bfgminer instances. Display warning if found, lock interface and skip subsequent scans
Scan for FTDI devices using WinUSB driver, if found display warning
Scan for FTDI devices using unknown driver, if found display warning
Scan for FTDI devices using FTDI driver, identify which of these are Bitforce SC units and add them to the listbox

On selection from listbox, enable scan device button. If nothing selected in listbox, ensure button is disabled

On scan, open port based on device serial number. Issue ZCX, ZTX and ZLX commands and populate relevant fields on the user interface.

Thats about all there is to it, besides some other bits of logic to keep the UI clean.
If anyone finds any bugs, please let me know. I've done four or five iterations so far to fix major bugs.

Again, this is a Windows only program, and has been tested on XP and Windows 7 so far. It is written in .Net (because I am lazy) and isn't really open source, although I'm happy to discuss the code if anyone is interested.

Sorry but my antivirus is unhappy with your software


Neither Symantec nor McAffee alert for this.  The likely reason yours does is that it is seeing the port-scan portion of the software which would indicate a potential unsafe program if you did not already know what it is doing.  If you want to be absolutely sure, send it to the AV company and ask them to verify it is not a false positive.

I do not suffer fools gladly... "Captain!  We're surrounded!"
I embrace my inner Kool-Aid.
Cablez
Legendary
*
Offline Offline

Activity: 1400


I owe my soul to the Bitcoin code...


View Profile
September 02, 2013, 08:56:57 PM
 #47

So what your saying is with older versions of the hardware, newer firmware doesn't really bump performance any and doesn't seem to be worth the flash?

Well, that's not exactly what I said or would like to say. I would not say it so much in general like your consumption.
I used a SINGLE-SC in the 5xx serialnumber range, which I received ~2weeks ago. Flashing the standard 1.2.8 firmware into this single gave me a significant lower hashing rate than me already tuned 1.2.6 firmware. This was not soo much surprising for me. But after tuning the 1.2.8 firmware in nearly the same way I did it with the 1.2. 6 firmware, I still could not reach the hashing rate of my tuned 1.2.6 firmware. Maybe there are other ways to tune the 1.2.8 firmware to get better results. However, with the standard 1.2.8 firmware I could not see any improvement in hashing-rate over the standard 1.2.6 firmware with my single, which seems to have revision A chips.

Understood, Thanks.  I have an April version board but have not looked into flashing yet as there seems to be no benefit for me after potentially dropping money on an AVR dragon. There would need to be a gain for me to start messing around...for now.

Tired of substandard power distribution in your ASIC setup???   Chris' Custom Cablez will get you sorted out right!  No job too hard so PM me for a quote
Check my products or ask a question here: https://bitcointalk.org/index.php?topic=74397.0
vitruvio
Sr. Member
****
Offline Offline

Activity: 467



View Profile
September 02, 2013, 10:04:43 PM
 #48

Hi BTC-engineer,  good work you are doing with this stuff, I've got a Litle Single that Red_Wolf_2's software throw this data:

Code:
DEVICE: BitFORCE SC
FIRMWARE: 1.2.1
IAR Executed: NO
CHIP PARALLELIZATION: YES @ 8
QUEUE DEPTH:40
PROCESSOR 0: 15 engines @ 362 MHz -- MAP: FFFE
PROCESSOR 1: 15 engines @ 348 MHz -- MAP: FFFE
PROCESSOR 2: 14 engines @ 389 MHz -- MAP: FFEE
PROCESSOR 3: 15 engines @ 362 MHz -- MAP: FFFE
PROCESSOR 4: 15 engines @ 385 MHz -- MAP: FFFE
PROCESSOR 5: 14 engines @ 399 MHz -- MAP: FBFE
PROCESSOR 6: 14 engines @ 350 MHz -- MAP: FFEE
PROCESSOR 7: 15 engines @ 419 MHz -- MAP: FFFE
THEORETICAL MAX: 44072 MH/s
ENGINES: 117
FREQUENCY: 274 MHz
XLINK MODE: MASTER
CRITICAL TEMPERATURE: 0
XLINK PRESENT: NO
OK

After few reboots I get 116-118 engines, that gives me 31.5-32  GH/s, any improve if I update my firmware? seems to be quite old.

Regards
kano
Legendary
*
Online Online

Activity: 2240


Linux since 1997 RedHat 4


View Profile
September 03, 2013, 01:12:02 AM
 #49

Just an FYI - the cgminer API has always reported that in the stats command.

Pool: https://kano.is Here on Bitcointalk: Forum BTC: 1KanoPb8cKYqNrswjaA8cRDk4FAS9eDMLU
FreeNode IRC: irc.freenode.net channel #kano.is Majority developer of the ckpool code
Help keep Bitcoin secure by mining on pools with full block verification on all blocks - and NO empty blocks!
Red_Wolf_2
Sr. Member
****
Offline Offline

Activity: 252


View Profile
September 03, 2013, 04:02:19 AM
 #50

I'm now wondering what these two defines in the firmware do... Anyone experimented with them?
//#define __CHIP_BY_CHIP_DIAGNOSTICS      
//#define __ENGINE_BY_ENGINE_DIAGNOSTICS

I'm imagining more in-depth self-diagnostics on bootup, but if there is a chance the chip-by-chip diagnostics would allow individual chips on boards to reclock to higher maximum speeds it would definitely be interesting to play with...

Also, I've been working on a windows program to make it easier to grab statistics from BFL Bitforce SC gear. Far from complete yet and it only supports FTDI drivers, but its available from http://randomcontent.wolfnexus.net/RandomSite/files/2313/7776/5140/RW2-BFL-Commport-Scanner.zip

Yes it is an executable, but I can promise it does nothing malicious. Below is a summary of how it works.

Startup - unpack required wrapper DLL from within using reflection
Check for running cgminer or bfgminer instances. Display warning if found, lock interface and skip subsequent scans
Scan for FTDI devices using WinUSB driver, if found display warning
Scan for FTDI devices using unknown driver, if found display warning
Scan for FTDI devices using FTDI driver, identify which of these are Bitforce SC units and add them to the listbox

On selection from listbox, enable scan device button. If nothing selected in listbox, ensure button is disabled

On scan, open port based on device serial number. Issue ZCX, ZTX and ZLX commands and populate relevant fields on the user interface.

Thats about all there is to it, besides some other bits of logic to keep the UI clean.
If anyone finds any bugs, please let me know. I've done four or five iterations so far to fix major bugs.

Again, this is a Windows only program, and has been tested on XP and Windows 7 so far. It is written in .Net (because I am lazy) and isn't really open source, although I'm happy to discuss the code if anyone is interested.

Sorry but my antivirus is unhappy with your software


Neither Symantec nor McAffee alert for this.  The likely reason yours does is that it is seeing the port-scan portion of the software which would indicate a potential unsafe program if you did not already know what it is doing.  If you want to be absolutely sure, send it to the AV company and ask them to verify it is not a false positive.

Well, as the author of the software I can guarantee there is no dropper in it. It may be detecting the reflection I used and the embedded wrapper DLL file for the FTDI drivers, but that shouldn't trigger a detection as a dropper... Send it through to the AV company, I'll privmsg you an email address to contact me with if you want too.

Probably should put something here.... Maybe an LTC address?
LeNdJidEvsyogSu2KbC1u3bfJSdcjACFsF
vitruvio
Sr. Member
****
Offline Offline

Activity: 467



View Profile
September 03, 2013, 06:17:26 PM
 #51



Well, as the author of the software I can guarantee there is no dropper in it. It may be detecting the reflection I used and the embedded wrapper DLL file for the FTDI drivers, but that shouldn't trigger a detection as a dropper... Send it through to the AV company, I'll privmsg you an email address to contact me with if you want too.

Indeed false positive

https://analysis.avira.com/en/status?uniqueid=gbsQSnjX5hY3ISq4jnUXLNW56pYPInVK&incidentid=1502551

Regards
Red_Wolf_2
Sr. Member
****
Offline Offline

Activity: 252


View Profile
September 05, 2013, 12:25:23 PM
 #52

New version is online, I've added some new checks to ensure the FTDI drivers are actually there before starting up (if they aren't, a warning is displayed then the program closes.)
Also added a slightly longer delay in the loop checking for new serial data, which might make it collect data a fraction slower, but should resolve the issue with no diagnostic information being displayed on slower machines.

Link below:
http://randomcontent.wolfnexus.net/RandomSite/files/9613/7838/3202/RW2-BFL-Commport-Scanner.zip

Probably should put something here.... Maybe an LTC address?
LeNdJidEvsyogSu2KbC1u3bfJSdcjACFsF
Mobius
Hero Member
*****
Offline Offline

Activity: 965



View Profile
September 06, 2013, 04:50:19 PM
 #53

Latest shipped SC60 Ser#13xx  has
DEVICE: BitFORCE SC0x0aFIRMWARE: 1.2.90x0aIAR

loaded, any source available?
gurki
Member
**
Offline Offline

Activity: 102


View Profile
September 06, 2013, 10:57:54 PM
 #54

Yesterday I've received the improved version of my single fan plates from production.


Here are some pictures of my singles with the new plates. Air is now flowing much easier.







It's easy to see the difference, when you directly compare it with the standard version.


A friend of mine has made them on his professional CNC-machine based on my design.
I've ask him if he would produce and ship them in very low volume too. And he agreed.

He would even produce them for order volume ONE.
He is thinking about a kit including:
2 x Improved fan plates
2 x fan grills
8 x screws

The plate is made fully compatible to the existing one (same backside profile).

Update: He is selling the sets now on www.bitmit.net
His account name is wowo and I can confirm that he is the official manufacture of my fan plate design.
Look on bitmit for 'FAN PLATE Set for BFL SINGLE'S'. I'm sure you will find it there.


It'd be nice to have a video that actually shows how much this improves the noise level and temp.
johnyj
Legendary
*
Offline Offline

Activity: 1834


Beyond Imagination


View Profile
September 07, 2013, 04:20:32 AM
 #55

Gentle typhoon 1850 rpm 120mm fan should be able to reduce the noise dramatically while keep almost the same static pressure and air flow

Bicknellski
Hero Member
*****
Offline Offline

Activity: 924



View Profile
September 07, 2013, 04:34:53 AM
 #56

Yesterday I've received the improved version of my single fan plates from production.


Here are some pictures of my singles with the new plates. Air is now flowing much easier.







It's easy to see the difference, when you directly compare it with the standard version.


A friend of mine has made them on his professional CNC-machine based on my design.
I've ask him if he would produce and ship them in very low volume too. And he agreed.

He would even produce them for order volume ONE.
He is thinking about a kit including:
2 x Improved fan plates
2 x fan grills
8 x screws

The plate is made fully compatible to the existing one (same backside profile).

Update: He is selling the sets now on www.bitmit.net
His account name is wowo and I can confirm that he is the official manufacture of my fan plate design.
Look on bitmit for 'FAN PLATE Set for BFL SINGLE'S'. I'm sure you will find it there.


It'd be nice to have a video that actually shows how much this improves the noise level and temp.

Need an air filter... that is going suck in the dust for sure.  https://www.bitcoinstore.com/accessories/air-filters.html

Dogie trust abuse, spam, bullying, conspiracy posts & insults to forum members. Ask the mods or admins to move Dogie's spam or off topic stalking posts to the link above.
BFL-Engineer
Full Member
***
Offline Offline

Activity: 227



View Profile WWW
September 07, 2013, 10:29:39 AM
 #57

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

BF Labs Inc.  www.butterflylabs.com   -  Bitcoin Mining Hardware
kano
Legendary
*
Online Online

Activity: 2240


Linux since 1997 RedHat 4


View Profile
September 07, 2013, 12:15:13 PM
 #58

...
It'd be nice to have a video that actually shows how much this improves the noise level and temp.
Just taking the whole cover off on my 2 reduced the temp by 5C each
It initially dropped 7C on one but levelled out at 5C for both.

Pool: https://kano.is Here on Bitcointalk: Forum BTC: 1KanoPb8cKYqNrswjaA8cRDk4FAS9eDMLU
FreeNode IRC: irc.freenode.net channel #kano.is Majority developer of the ckpool code
Help keep Bitcoin secure by mining on pools with full block verification on all blocks - and NO empty blocks!
nfowest
Jr. Member
*
Offline Offline

Activity: 31


View Profile
September 12, 2013, 07:50:10 PM
 #59

watching

eestimees
Hero Member
*****
Offline Offline

Activity: 583



View Profile
September 13, 2013, 05:44:00 AM
 #60

...
It'd be nice to have a video that actually shows how much this improves the noise level and temp.
Just taking the whole cover off on my 2 reduced the temp by 5C each
It initially dropped 7C on one but levelled out at 5C for both.


temp dropped at the place where this sensor is, but what is the temp near the chip where big fan sucks air out? what is the temp underside of pcb ?

Pages: « 1 2 [3] 4 »  All
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!