Topic: s9 > batch 16 and Auto-Tune Issues (Read 5476 times)

Maybe, but their target market is the "from new, stick it in a rack until it dies" people. They don't care about hobby miners too much, since that's not where their profit is (R4 excluded).

I find it quite interesting that they don't in fact appear to do any per-chip or per-board even tuning per-boot - it's just making sure that each board is as-shipped from factory, setting the ASIC speeds and expected core count, then trying all the boards.

There is no variance in the picked speeds at all, as far as I can see - it just validates that everything is within expected ranges.

When you do a new 'apply settings', it does some additional checks, but again, none of these appear to change the hashrate significantly.

Cheers,

Allan.

Ja. And to those who say it's more work for Bitmain's coders so Bitmain won't do it: Um, they just changed from using the Xilinx SOC to using one from Altera - pretty safe bet that the hardware change required significant re-coding of at a minimum the FPGA portion of it. Since the Cyclone-V still uses the same ARM-9 CPU as the Xilinx SOC did at least that bit would be mostly the same.

Implementing Eco modes is nothing compared to that

Steering here posted. Now to see if works....

For those late to the party, my humble opinion as to Why Bitmain has forced Auto-tune factory speed only. No chance to underclock if desired. Let's call that Eco-modes.

In short the reason is Bitmain being able to use all possible chips produced using the 16nm Fin FET process. As ALL makers of 16/14nm node chips know - including the likes of Intel and IBM - that node is very unforgiving. Last I saw reported was that current initially 'usable' chips yield is ~70% for more complex but physically more spread out GPU's CPU's, Network Fabric switches and such. Note the word initially. Users of 14/16nm CPU's and GPU cards are reporting far higher time related failures as in a couple months when it happens.

BTW: That 70% yield is only because CPU's and GPU's can be easily binned per their performance and priced accordingly. Great ones costing more $$, meh ones $. Bitmain also bins to some extent but have a far narrower range as to what is usable while meeting advertised power usage. Ergo, I'd put their chip yield around 50-60% at best. BitFury, BW.com, Canaan, and others chose to sacrifice power efff for more stable operation by using higher Vcore. Odds are Bitmain's T9 are the same - higher Vcore, screw lowest on the planet eff.

Point is, Bitmain can populate hash boards with different 'speed' chips, test/bin the boards for several 'speed-grades' then build miners that reach the +/- 10% advertised rate and be done with it. Their firmware sorts out as-sold Target total hash rate needed, tests each board to see what they can do, and then sets them to give target speed.

Summary to date done.STD info starts.

Downside is, they threw out the baby with the bathwater. They allow no changes to what the miner decides is Best.

From Bitmains POV I can understand their reasoning: To get better chip yield we need Auto-tune. It solves problem of a miner performing poorly if Optimum (for that particular miner) is changed. Given that in all probability most large farms will not be changing things until much later in the product life cycle. Makes sense. I also bet that later on we WILL see Eco-modes from Bitmain in Firmware updates to come...

Auto-tune and it's 'why' should have no bearing on under clocking/volting the miners (and in turn fan speed would drop as well) if a user wants to do that. The testing part of Auto-tune already gathers extensive data on each hash board and the chips on it. Give users the option of reducing hash rate/power and apply as an offset to the miner hash rate. Consult performance data to new target hash rate and apply. Retest if desired and tweak as needed. Done.

Should be easy-peasy with very very minimal coding... Full tilt Factory as Default, Eco for those who don't care.

Bumping this up due to a virulent STD (Serious Topic Deviation) has sprung up on the main Bitmain s9 thread re: Auto-tune and Bitmain disabling any 'Eco-mode" fiddling.

To be continued...

Did you solve the problem? I have the same code, and situation, please help

I can confirm it's both batch 16 and 17 that shipped with this auto-freq update.

Can someone please tell me if it is possible to flash to an older firmware version on batch 16 and 17 S9's, because the fan setting is not configurable any longer!  Nor can you over/under clock...

Does anyone have a copy of the 600 and 650mhz older firmware versions and could you post it on a free download site, preferably one in English.  There is another post on here where someone posted it on a polish download site but the codes do not work and I can not figure it out even with google translate.

Thank you!

I compared pics of a s9 b11 hash board to the b17 and the Vcore regulator sections look identical.

If you are a windows person then winscp is an easy option to connect to the miner and transfer files.

Pics of s9 b17 Vcore regulator section:
Font side
At least this looks near pristine!. That same area on many/most of my older s9's sorta look um, like someone spit on it and it dried... (seriously, doubt that is it more likely flux residue from bad cleaning). Nasty looking and highly unprofessional.


Back side showing no U2 DPOT.
Also R17 coming from a bus of some sort going to U2's pin-6 along with R101 and R102 are missing as well. 101-102 run between the DPOT and programming plug P1 pins 1 & 2 that was used for Sidehacks s7 undervolting mod.

To me, bottom line is that the PIC has direct coms with the Vcore regulator which from a design point makes perfect sense. I mean, since many/most regulators have internal EPROM or flash to store safe startup values and are quite happy to talk to a micro-controller once the uC wakes up, why add another layer (the DPOT) to things?
 Have all s9's been like this? Guess I gotta dig up pics of the bad s9 boards I sent to Bitmain Warranty...


Now to wait for the miner to finish playing with itself and get back to work....

edit: And 15min later -- back to full speed

Anyone here know how to ssh into the s9 and grab a copy of the on-board (part of the ARM based SOC) flash firmware aka the Factory Reset image that the controller uses when mounting the working partition(s)? Sadly, working knowledge of any 'UX is not one of the many hats I wear

For 1 it would make for a damn fine way to have a real backup vs just a settings file the 'backup' function does for us. For 1 I suppose the resulting file should be a directly usable xxxx.tar.gz file.

Tell ya what, considering that if a board in my b17 miner goes wonky I'll see what Bitmain Warranty can do about it vs sending to China, I'll look tomorrrow.

Reason is this post in the Official s9 thread https://bitcointalksearch.org/topic/m.16620404

Leads me to wonder if the PIC/MCU/whatever now has a direct link to the Vcore regulator...

From what I can tell on older s9's the regulator is identical to an s7. Even have a nice set of pins that can probably be used to program the voltage like an s7.

edit: Have you had a chance to look at disassembled s9  (batch 17?) code at https://onlinedisassembler.com/odaweb/HP7GAkIN ?

Way out of my league to dig into but the index points to many many interesting bits I don't recall seeing before...
Damn that brings back memories! I haven't dealt with assembly code since the mid-1970-s through maybe 1982. Motorola 6800, Z80 and a few others. Trying to cram functional work-with-the-world code into maybe 128k leaving 32k of changeable user memory if you were lucky... Good way to make someone feel real old there...

I haven't really probed but based on behavior I would guess the micro toggles the main buck's enable line. This was not on the S7. I would also guess but I haven't confirmed that the buck might be hardwired for a particular voltage. The one I looked at today, two adjacent boards had two different voltages. Since it's someone else's machines I'm not willing to poke around on 'em to see what goes where and does what, but if the buck is the same as S7 (looks like it at a glance) the DPOT is left unpopulated. I'd be interested to know if that's the case on the new version. If any of y'all have a board shoot craps and open it up it'd be great to get some high-res pictures of the regulator portion of the board.

a little update.

after 18 hours it started hashing with no intervention from me, but was showing all temps as 0 and fans going crazy, but hashrate seems ok.

hope bitmain can get back to me with a earlier firmware

Very cool.... looking through the index I see lots of v adjustment code.
Now question is: does the PIC talk directly to the Vreg or to a DPOT?

https://onlinedisassembler.com/odaweb/HP7GAkIN

With the miner & fans running you kind of see the area where the U2 pads are but I couldn't really tell 'cause the fans blur things... Maybe a well-timed flash could catch it.

 A snippet from the kernel logs shows they definitely are doing something to control Vcore on-the-fly.

Ok so ill wait till the kinks in this FW transition process are resolved, my miners are pretty happy with the last stable FW most operating happy at higher clock speeds and very stable in a controlled data center so I think ill skip this update as I dont need added headaches right now

Far as I can tell, the buck circuit is basically the same as the S7. U2 is the part replaced by a trimpot in the Cheap and Easy S7 Repair thread from a few months ago that has a bunch of pictures already.

Can you send a pic of the board and the part, so that it's easy to locate U2. Thanks