....bitmain shows the stock freq as being whatever freq the miner ships with...
Yes, and in the image you showed,
the middle board shipped with an average frequency of 477.47.
Since when not bickering over # of Angels dancing on a pinhead you both do have good info from time to time -- Unignored and had to pop in...
You are both right... To me the whole main issue stems from the 16/14nm node process variability and the resulting wide range of speed/voltages the chips will even run at. That in part is probably why unlike all their other chips, Bitmain has not released any data sheets on the chips. The yields per-wafer are too variable. Could be outstanding, often mostly usable with decent performance followed by usable but 'meh'.
As a result, Bitmain bins (grades) chips per-performance and builds boards with different grade chips. eg, they know w-board built with grade-x chips will be happiest running at y-speed/voltage for z-expected board hash rate. As Genie keeps saying, speed/voltage data for each board (I will assume it is after testing each completed board!) is burned into the PIC at the factory. To me those settings stored in the PIC are the OEM specs for
that board.
However - that data read from the PIC can/will be overwritten if desired either by Auto-tune or by manually changing the
volatile cgminer.conf file or whatever Bitmain calls it. Awesome Miner monitoring software used to do it all the time via the cgminer API but is of course temporary - a reboot puts you back to what the Firmware has recorded in NV memory. All Auto-tune does is just verify that the PIC settings work, if not, it tweaks the settings for .conf a bit and re-tests until it can work or decides to give up on the board and Fail it.
Anywho, Bitmain bins completed hash boards by hash rate, then later selects different speed boards to assemble into miners that produce advertised
total hash rate. Again, some boards can be great, other will be 'meh'. Either way the miner produces as-advertised hash rate and Bitmain gets to sell more chips-per wafer. Maybe not the best solution to the usable chip-yield problem but it works.
If Bitmain is giving back our ability to once again set speeds and have it stick between reboots then it better be per-board otherwise Genie's technical nit-picking definition of over clocking (which I agree with) certainly comes into play. In that light it must be the user manually-setting the speed faster than what the OEM PIC data shipped with.
When doing the IP Reporter button trick to reset Firmware to the embedded backup image the one problem with it is: Sure, we get to manually set speed to out hearts content BUT it is just 1 speed setting for all boards. Ergo the best board has to run at what the worst one likes... Sure, can speed it up but then are OC'ing the slower board
Along the lines of this, anyone ever cherry-pick 3 outstanding boards from their miners and put them into 1 miner? I have a few s9 boards that together should do over 17THs but have yet to try it. Wonder if Bitmain has code to prevent that? Each board should be running at or near the PIC data settings but if the miner in total is running faster than as-shipped, is that over clocking?