Pages:
Author

Topic: ANN: custom BFL firmware - tested 5-7GH pool meas. improvement on 60GH singles (Read 7213 times)

sr. member
Activity: 1316
Merit: 254
Sugars.zone | DatingFi - Earn for Posting

can you share the results?

Well my hash rate did increase, so did my hardware errors. Pool side was terrible so i flashed back only to be plagued with network issues that should be resolved tomorrow ( I hope ) I currently can not be sure what was going on as Eligius was having stats troubles at the time, my network switch has serious latancy issues and i have been switching between cg and bfg due instability.

May try again once all has settled down..
member
Activity: 112
Merit: 10
I have just flashed this to a little single, great  Grin

Went to flash my second one .

Quote
jtag> detect
warning: TDO seems to be stuck at 0
error: not found: queue is empty
jtag>

Anyone have any ideas ? Am using a PI as jtag and have tried with a second PI

Edit : got a cable wrong  Roll Eyes Flashing now..

can you share the results?
sr. member
Activity: 1316
Merit: 254
Sugars.zone | DatingFi - Earn for Posting
I have just flashed this to a little single, great  Grin

Went to flash my second one .

Quote
jtag> detect
warning: TDO seems to be stuck at 0
error: not found: queue is empty
jtag>

Anyone have any ideas ? Am using a PI as jtag and have tried with a second PI

Edit : got a cable wrong  Roll Eyes Flashing now..
legendary
Activity: 1726
Merit: 1018
Well shoot this firmware isn't letting me realize any gain on the pool side hashrate.  CGMiner certainly reports a higher hashrate but the increased HW errors are eating it all.  I installed 1.2.8 from the official releases and it only hashed at 15 Gh/s.  I don't think I am up to modifying my own firmware.  I didn't check what firmware came on it but I think I'll try some of the older ones.
legendary
Activity: 1726
Merit: 1018
does this firware work on the 30GH?

I would also like to know if it works on the 30GHz, or if anyone has tried.

It does and I did.  Went from 21.5 Gh/s to 27.3 Gh/s but I am also getting 8% HW errors now.  I think I was getting 2 or 3% HW errors before.  I haven't tried any of the other firmwares out there.   My unit was technically a 25 Gh/s as I never paid for the upgrade to 30.
sr. member
Activity: 327
Merit: 250
does this firware work on the 30GH?

I would also like to know if it works on the 30GHz, or if anyone has tried.
member
Activity: 80
Merit: 10
So...I guess we need an AVR Dragon or similar to load this? 

Is there also some kind of disassembling instructions on how to take apart the Single?
member
Activity: 80
Merit: 10
So...I guess we need an AVR Dragon or similar to load this? 

http://www.digikey.com/product-detail/en/ATAVRDRAGON/ATAVRDRAGON-ND/1124251?WT.mc_id=PLA_1124251  $53 not bad when you can get an extra 5%-15% from most Singles...Rev.2 Chips atleast seem to have much better chances hitting the mid 60 GH/s range

Sorry if this is a dumb question but is there a way to identify if we have Rev2 chips?

legendary
Activity: 1862
Merit: 1518
does this firware work on the 30GH?
sr. member
Activity: 462
Merit: 250
well I tried it on a second single SC, gives 6% HW error and 61.x Ghash...which is the same that the latest firmware from Luke Jr gives, except with 5% more error.  Basically no benefit at all, I'm guessing this really only helps rev 2 chips. 

where did you get Luke Jr firmware?
newbie
Activity: 48
Merit: 0
After playing with different values for each chip.  I can varied Hash increases and associated HW errors. 

What is a acceptable HW error?  I'm trying to quantify if my hashing increase is just being wasted as HW errors.

thanks
sr. member
Activity: 658
Merit: 250
I flashed two singles which apparently had Rev1 chips with this firmware. After a cursory look at the code it seemed like it supports both Rev1 and Rev2 chips so I flashed away. No chips could be brought up with 16 engines on either one, so I assume they are Rev1.

Stock valid hashrates were 59 and 61. After flashing and manually tuning chip speeds I got the 59 unit to 61.5, and the 61 unit to 62.5 valid hashrate. However, one chip on the unit originally doing 59 now seems to produce 15% HW errors, no matter what speed it's set to. I even tried 5. I'll try tinkering around and maybe set all chips to speed 7 to figure out what's going on, it definitely wasn't even close to that amount of HW errors with the stock firmware (which AFAIK sets all chips to 7). Overall this is a definite improvement, but I'm wondering what's causing that one chip to have degraded performance now. Maybe increasing the speed of other chips can also cause some chips to generate more errors?
legendary
Activity: 2450
Merit: 1002
bumpity in case anyone new is browsing and interested but didnt know this existed =)
sr. member
Activity: 467
Merit: 250
CGMiner run, 2h20m
Code:
[2013-10-27 23:44:53] Started at [2013-10-27 21:24:18]                    
 [2013-10-27 23:44:53] Runtime: 2 hrs : 20 mins : 34 secs                    
 [2013-10-27 23:44:53] Average hashrate: 62375.0 Megahash/s                    
 [2013-10-27 23:44:53] Solved blocks: 0                    
 [2013-10-27 23:44:53] Best share difficulty: 159K                    
 [2013-10-27 23:44:53] Share submissions: 3869                    
 [2013-10-27 23:44:53] Accepted shares: 3835                    
 [2013-10-27 23:44:53] Rejected shares: 34                    
 [2013-10-27 23:44:53] Accepted difficulty shares: 115140                    
 [2013-10-27 23:44:53] Rejected difficulty shares: 522                    
 [2013-10-27 23:44:53] Reject ratio: 0.9%                    
 [2013-10-27 23:44:53] Hardware errors: 7871                    
 [2013-10-27 23:44:53] Utility (accepted shares / min): 27.30/min                    
 [2013-10-27 23:44:53] Work Utility (diff1 shares solved / min): 815.47/min

BEFORE
Code:
DEVICE: BitFORCE SC
FIRMWARE: 1.2.9
IAR Executed: NO
CHIP PARALLELIZATION: YES @ 16
QUEUE DEPTH:40
THEORETICAL MAX: 54219 MH/s
ENGINES: 239
FREQUENCY: 274 MHz
CRITICAL TEMPERATURE: 0
TOTAL THERMAL CYCLES: 0
XLINK MODE: MASTER


AFTER
Code:
DEVICE: BitFORCE SC
FIRMWARE: 1.2.9
IAR Executed: NO
CHIP PARALLELIZATION: YES @ 16
QUEUE DEPTH:40
THEORETICAL MAX: 64887 MH/s
ENGINES: 255
FREQUENCY: 291 MHz
CRITICAL TEMPERATURE: 0
TOTAL THERMAL CYCLES: 0
XLINK MODE: MASTER
sr. member
Activity: 467
Merit: 250

For those trying to flash with UrJTAG, you need a .bin version of this code. As of 10/27/13, taking from this thread...

Bitforce_SC_Tarkin_129.bin: http://www53.zippyshare.com/v/68475857/file.html
Bitforce_SC_Tarkin_129.hex:  http://www53.zippyshare.com/v/15496017/file.html

Hopefully this saves someone the pain I went through today. First donor single went from 53GH to 62.4GH (cap still in place) but much happier. Thanks again GenTarkin for all your hard work.
hero member
Activity: 608
Merit: 500
well I tried it on a second single SC, gives 6% HW error and 61.x Ghash...which is the same that the latest firmware from Luke Jr gives, except with 5% more error.  Basically no benefit at all, I'm guessing this really only helps rev 2 chips. 
legendary
Activity: 2450
Merit: 1002
hrm weird.... try reuncommenting do_not_use_engine_zero ...
other than that not sure, guess u may just be stuck w/ stock firmware =P
newbie
Activity: 20
Merit: 0
I uncommented DO_NOT_USE_ENGINE_ZERO and it's not helped.

Try upping the boot frequency, specified at the top of ASIC_engine.c ... the variables you see commented, try setting the boot index one higher.
I tried and it's not help
All changes that i made:
Code:
/*************** Product Model *********************/
#define __PRODUCT_MODEL_JALAPENO__
//#define    __PRODUCT_MODEL_LITTLE_SINGLE__
//#define __PRODUCT_MODEL_SINGLE__
//#define __PRODUCT_MODEL_MINIRIG__

Code:
/////////////////////////////////////////////////////////////////////////
// This means DO NOT USE ENGINE 0. It's needed for the actual Version
#define DO_NOT_USE_ENGINE_ZERO

Code:
// USER CHANGEABLE VARIABLES###################################################
//specify freq index of booting up chips
const unsigned int __ASIC_BOOT_FREQ = 6;
//specify freq index of diag tests on chips
const unsigned int __ASIC_TEST_FREQ = 6;
//specify % errors detected at which engines are considered failed for __TOTAL_DIAGNOSTICS_RUN ... (0 = allow no failure, 100 = allow all)
const unsigned int failPercentThreshold = 0;
//specify running freq index of each chip manually
const unsigned int __ASIC_FREQUENCY_PERCPU_MAP[16] = { 9,9,9,9,9,9,9,9,9,9,9,9,9,9,9,9 };
//backup def const unsigned int __ASIC_FREQUENCY_PERCPU_MAP[16] = { 9,9,7,8,8,9,9,7,9,8,7,8,9,7,9,9 };
//END##########################################################################
hero member
Activity: 608
Merit: 500
My hardware error rate jumped to like 11% from about 0.5% with this firmware so it seems that all the extra hashrate is just bad hashrate =(

Depends on what shape ur chips are actually in. Yours seem to be pretty bad =(

With the mentioned tweaks, actual pool measured hashrate(taking into account HW error, rejects etc...) for me went from 57 to 64GH...
Well it wasn't a complete waste of time, I had a pretty early firmware so I ended up flashing to the latest stock version from luke jr and the hashrate went up to about 62 with a 1.2% error rate.  It used to give about 0.5% error so it did go up but I gained 2-3Ghash so it's still a real gain.

Will test your firmware on my other units when I have time, hopefully it's just this one SC that's bad.
legendary
Activity: 2450
Merit: 1002
I uncommented DO_NOT_USE_ENGINE_ZERO and it's not helped.

Try upping the boot frequency, specified at the top of ASIC_engine.c ... the variables you see commented, try setting the boot index one higher.
Pages:
Jump to: