Pages:
Author

Topic: BFL ASIC Firmware & Hardware, Understanding & Optimization - page 2. (Read 15647 times)

hero member
Activity: 988
Merit: 1000
Latest shipped SC60 Ser#13xx  has
DEVICE: BitFORCE SC0x0aFIRMWARE: 1.2.90x0aIAR

loaded, any source available?
sr. member
Activity: 252
Merit: 250
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
sr. member
Activity: 850
Merit: 331


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
sr. member
Activity: 252
Merit: 250
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.
legendary
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
Just an FYI - the cgminer API has always reported that in the stats command.
sr. member
Activity: 850
Merit: 331
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
legendary
Activity: 1400
Merit: 1000
I owe my soul to the Bitcoin code...
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.
hero member
Activity: 532
Merit: 500
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.
sr. member
Activity: 850
Merit: 331
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

sr. member
Activity: 360
Merit: 250
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.
legendary
Activity: 1400
Merit: 1000
I owe my soul to the Bitcoin code...
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?
sr. member
Activity: 360
Merit: 250
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.
sr. member
Activity: 360
Merit: 250
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
----------------------------------------------------------------------------
sr. member
Activity: 252
Merit: 250
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.
newbie
Activity: 18
Merit: 0
Here is a picture inside the cabinet before the fans were installed.

http://subjectreality.com/miner/cabinet2.png
newbie
Activity: 18
Merit: 0
I built a cabinet to reduce the sound of my BFL 60GH/s miner. It has three chambers insulated with foam. There are four 120mm intake fans pulling cool air in from the floor and another four pushing out the back at the top. I built a little power supply for the fans that draw 15 W. I had hoped to sit the miner vertically pushing air upwards but it won't run that way.

The temperature is about 2-3 deg C higher which I will work on. 59 on the floor is now 63 C in the cabinet. It is significantly quieter and I expect to be able to sleep now.

 http://subjectreality.com/miner/cabinet.png
legendary
Activity: 1890
Merit: 1003
@ BTC-Engineer/Nasser

I don't think you are talking to who you think you are.
Who are we talking to then?

Those who can read have a clear advantage.
BTW: Are you not the one who first corrected me, as a non English native speaker, after my first posting in this thread, by not only just telling me what I've done wrong. You quoted a multi-page posting, just to point out one wrong spelled word. This really helped a lot!

To answer your question, just to avoid that anyone thinks I like this confusion.
I guess you mean BFL-Engineer, also known as Mr. Nasser from BFL.
I'm BTC-engineer. And just for the case - I was first here.
 
You would do me, and I guess most others also a big favor by avoiding this topic or even better, reducing your 'activity' on a Kindergarten section in this forum, for users without a real life.
I understand, making a fan grill is a challenge.



...and in all honesty, it is an improvement. (who designs these original pieces?)
sr. member
Activity: 360
Merit: 250
@ BTC-Engineer/Nasser

I don't think you are talking to who you think you are.
Who are we talking to then?

Those who can read have a clear advantage.
BTW: Are you not the one who first corrected me, as a non English native speaker, after my first posting in this thread, by not only just telling me what I've done wrong. You quoted a multi-page posting, just to point out one wrong spelled word. This really helped a lot!

To answer your question, just to avoid that anyone thinks I like this confusion.
I guess you mean BFL-Engineer, also known as Mr. Nasser from BFL.
I'm BTC-engineer. And just for the case - I was first here.
 
You would do me, and I guess most others also a big favor by avoiding this topic or even better, reducing your 'activity' on a Kindergarten section in this forum, for users without a real life.
legendary
Activity: 1890
Merit: 1003
That is very embarrassing.... Roll Eyes

I will eliminate any topics misdirected at BTC-Engineer.

@ BTC-Engineer

I'll leave some posts so that continuity across the thread makes sense. I offer my apologies on mis-identifying you.
Pages:
Jump to: