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

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..

can you share the results?

I have just flashed this to a little single, great  

Went to flash my second one .


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

Edit : got a cable wrong   Flashing now..

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.

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.

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

Is there also some kind of disassembling instructions on how to take apart the Single?

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

does this firware work on the 30GH?

where did you get Luke Jr firmware?

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

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?

bumpity in case anyone new is browsing and interested but didnt know this existed =)

CGMiner run, 2h20m

BEFORE


AFTER

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.

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. 

hrm weird.... try reuncommenting do_not_use_engine_zero ...
other than that not sure, guess u may just be stuck w/ stock firmware =P

I tried and it's not help
All changes that i made:

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.

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.

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...

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 =(

I uncommented DO_NOT_USE_ENGINE_ZERO and it's not helped.

It's likely not working because this firmware tries to activate engine 0 on all chips. Jalapenos don't support that.

I tried to run this on Jalapeno. I uncommented #define __PRODUCT_MODEL_JALAPENO__ in std_defs.h and compiled without any problem but after programing LED didn't flash.

If you don't want to go the AVR Dragon route, you could try this : http://randomcontent.wolfnexus.net/RandomSite/reflashing-a-butterfly-labs-jalapeno-with-only-a-raspberry-pi/

Any easy way to flash these for those of us who don't have a JTAG? via USB perhaps? (doubtful)

Sent small donation as well to GenTarkin.  This Firmware Mod is a welcome upgrade for any BFL ASICs IMHO

pre-emptive donation sent.. looking forward to flashing my singles when the JTAG hardware shows up. Well done.. you've done a lot of the things I'd been thinking about, but aren't a good enough coder to actually DO.

thanks much dude! =)

Thanks GenTarkin, donated!

No worries, glad you were able to revert back and not have anymore issues.  I'm very impressed w/ the performance increase from your FW thus far and anything else that comes from it down the road is just a bonus.

Thanks again and i've been running the FW for about 15+ hours and everything is great.

Well I ran into issues w/ the lower HW error & slightly less clocks. Im not exactly sure what the cause is yet, but my single would just kinda stop mining after a good 40mins in my recent testing. I went back to the build that I released publicly(to you guys) and this problem has not happened. So... yeah... lol, may just have to deal w/ the more laxed engine enabling & next might be trying to see if I can figure out other word values for the clock index(see if can bring clock speed even higher)

I have an STK-500, would that work also?

Yes it will.  Same firmware for all products.  Just make sure to watch the Temps and have proper cooling because these Chips get very hot.

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

I have a little single and i am wondering if there would also be a potential to tune it a little bit. Would this work for little single too?

yes you need AVR dragon to flash.

yes I will update thread, at this point Im out of ideas to get further actual performance from, other than by seeing if theres additional values that can be used to adjust the clock generator upwards.

So...I guess we need an AVR Dragon or similar to load this? 

I just replaced the 120mm and 92mm fans (on Single) w/ ones i'd bought in bulk a few months ago and loaded up your Firmware that i'd downloaded yesterday....very happy to say that I went from just under 58GH ---->64.6 GH/s!  Getting about 2.5-3% hardware errors but am very happy with the improvements!  

I'd done a few tweaks with the Stock firmware on a couple of other singles that yielded a 2GH/s increase or so but this was phenomenal, w/ your FW, over 6 GH/s improvement and temps are around 69-70. I've taken the front plates off and replaced the 120mm fans w/ 1350 RPM Yate Loons and the 92mm w/ Panflo 2650 RPM fans as well.

Thanks for your time and effort on this GenTarkin, it's very much appreciated.  Feel free to keep this thread updated as i'm sure more people will be interested as they come across it.  Every little bit helps when trying to scrape by just to get a ROI on these...and I have to admit, your Firmware tweaks worked much better then I would've guess  


BTW, are you able to upload your newest build?  I will gratefully take 400-700mh/s less w/ 50% less HW errors.  Don't worry about things being perfect, we are just happy you've made improvements!

Still working on tweaking things. I did set that !define to define w/ no adverse affect. Its weird, the comment right above it even reinforced that its supposed to be !define... I wonder why, maybe its just redundant or something, I cant find anything else in the code that does it elsewhere.

donation addy:  12jjayHWtUci3ygPXD4i2yUHMySytiUBd4

The latest tweak or test is turning on running heavy diagnostics w/ the 3 nonce test... Doing this disabled only a few more of my engines but not nearly as much as stock. I really believe that running the diags at a lower clock yield more accurate results  as to what engines are pretty much useless at any clock vs others that work fine otherwise... just have more potential for error as clocks raise.

So, my latest build yields 400-700mh/s less avg rate, but dropped my HW by about 50%

Good work! I will try it out later!

Where is your BTC address so I can donate?

Excellent!

Great work, GenTarkin !!!
I just flashed one of my 2 Singles.
It jumped from 63GH/s to 66GH/s (I had done some work with the firmware already, like disabling "tune down").

Hey guys.....
First of all this is highly experimental code...as such if you blow up ur shit, not my fault. Ive provided both source and elf in the link below.

Ive been slaving away for the last 3 days at wrapping my head around, and tweaking BFL firmware.
Ive done some major changes that basically, reliably seem to get most peoples singles(60GH) an additional 5-7GH/s pool measureable.
My single stock was 58.4GH ... now its 64.8GH ... nearly all engines are enabled and happily hashing away.
Here is the source and the elf is also prebuilt in the debug folder.

http://www.fileswap.com/dl/oPZeK2NqSm/

Some changes, off the top of my head, a lot of my changes are in ASIC_engine.c
Ive created 4 user specifiable variables at the top - they are commented
1. specifies the frequency to boot the chips at
2. specifies the frequency to perform diagnostics on chips
3. specifies the frequency chips operate at during actual runtime
4. specifies the error threshold for the rewritten diagnostics routine I written against the engine processor(I still dont know if the processor is a seperate part of each engine or what, but the coding makes it sound like it)

These are specified using the index values (not frequency)

I only run the "processor diags" on each engine, I run them 20x(40 tests) on my single and I have set the threshold to 0 .. so if any error at all that engine gets disabled. Otherwise engine is left on. ( run no other diagnostics on single) ... on my particular single this leaves only 1 engine disabled(stock I had several engines turned off).  So, its a very relaxed testing scheme as you can see, but I believe it provides enough to allow cgminer to measure speed incorrectly & HW error as well... whereas leaving all engines on.... well the engines that cant even return a response to cgminer dont even get flagged as HW Error... and create fake hashrate readouts.

Its my theory that the multi level chip clock frequency initialization Ive created...actually helps the engines come on line more reliably. Whereas BFL's method of booting up chips at full boar clockspeed ... actually can hinder more engines. Also, the way Ive written the processor diag for each engine...is a more relaxed method of testing, think of it as "benefit of the doubt"..

Future things to tweak:
1: mhz readout accuracy. - the way mhz is measured on these devices is kinda just guesswork. The firmware sends a job to engine, figures out how long it takes then calculates resultant mhz and assigns that as mhz for entire chip. I may write it so it does several samples of that job then averages reported time taken and use that as mhz...

2: ...theres a function called __ENGINE_AUTHORITIVE_ACTIVITY_SUPERVISION ... and looking at how it gets called and what its designed to do... I think it actually doesnt end ever getting properly executed. I see that there is an if statement in file HighLevel_Operations.c ... which looks like it should be inside a loop...cuz it incriments a value each time and if equals 200 then it executes the if statement... Problem is... I dont see where the loop is!?!?.... So, I think that if statement never gets executed and its designed to be runtime engine error handling.    ....BFL....
If anyone could look at this and see...that would be great!