Topic: AntMiner S1 Underclocking, a thorough discussion (Read 8386 times)

Someone linked this thread elsewhere so I thought I may as well add that I released a current master cgminer release 4.9.1a for the S1
https://github.com/kanoi/cgminer-binaries/tree/master/AntS1

If it's there I'll find it.

Also noteworthy, the BTCGarden AM-V1 blades use almost identical VRM circuitry but two chips per instead of three, so an optimal point on a Tube should result in a slightly more efficient point (reduced current means reduced resistive losses in the regulator) on one of them with the same hardware mod. I may do a full analysis of a Garden board for comparison, if I have time.

I'm looking forward to your ASICMiner results sidehack, I under & over volted Rockminers RK/R3 boards and could not find any significant gh/w benefit worth chasing.

Trends

Just as a note, I'm starting an analysis on ASICMiner Tubes to see where they'll go. Our facility has hosted Tubes in the past, so I'm thinking about if the numbers look good, offering to undervolt for free any Tubes people want to send for hosting. They're getting to end-of-life definitely, but once we've completed our electrical upgrade and shift to the new rate schedule, all hardware will be $0.10/KWh flat. If I can get Tubes to put up decently in the 0.5-0.7W/GH area it might be worth looking into.

I should have results posted in a few days once I'm done running the jillion tests.

Ive got decent stability around 0.75-0.77V / 200-206MHz / TO=55 works and 90-100% of chips run well to produce 95-105GH/S1

going any lower to 0.7-0.74V / 193-200MHz / TO=50-60    seems to produce mixed results, usually 50-80%  of the chips function and I have around 50-75GH/S1

going any higher to 0.78-0.82V / 200-215MHz / TO=50-60    seems to produce decent results, generally 70-90% of the chips function and I have around 95-115GH/S1


i think these dont necessarily run well at the same settings as the S2 for whatever reason. running around 0.75-0.78V and 200MHz is probably the sweet spot

nice thread can't believe I have not read it until today.

Sometime when I have time I might crank mine down around 0.8, but right now they're still coming out ahead.

Also, I'm hoping to do a full workup on AM Tubes next week.

    

Who is running at .75v?

I still got to get around to underclocking mine so I can turn them back on!

looking forward to it :-)

Looks like we're getting some BTCGarden blades in, and possibly a KnC Jupiter module, so I might have some underclock data on those things in a few weeks. Depends on when (and if) stuff arrives, and what kind of time I have between jobs and holidays.

I have exactly one AM-V1, but we just got it in for the museum and I don't really feel like messing with it. I have nothing at all from RockMiner. If anyone's got either to sell at reasonable prices I can look 'em over.

I would be inteested to know if the AM-V1 can undervolt, same with rockminer gear.

MY EXPERIENCE WITH ROCKMINER VOLTAGE (relevant to rk-box and r3):
The regulator on these boards is not marked, but looks just like a TPS53355 seen on Antminer S1/S2 and Bitfury boards. However, it is arranged differently, without the same placement of R1/R2 that are used for raising/lowering voltage. (aplying pencil to R1 raises voltage, R2 decreases voltage). In the case of rockminer, no resistors were acessible that would reduce the voltage when resistance was reduced. only the oposite was seen - increase in voltage when R1 and R2 were simultaneously modded. physical replacement of the resistors would be the only solution i think

That's how I did the first, with a pot on a big ol' knob for super fine adjustments (I could tune it to 1mV easily). I've got resistors premade now to parallel on the existing 8200s that make 10mV increments, and I've been setting one bank, running for a few minutes, then moving up or down as necessary until the error rate hit threshold. I've a parts order coming Monday with the actual SMD resistors to do the swaps proper, instead of having through-hole resistors hanging off the boards.

I definitely need to read that external-controller thread for these guys and see what work y'all have done.

i have brought a bunch of potentometers that im adding to each blade (4 per section) and i plan on using that to fine tune each section, and adding them all together on the same controller (1 rasbpi) currently i have 5 done (those are pencil modded) so waiting for the last cp2102s to arrive to get the rest done, and waiting for those potentometers to arrive from china...

its amazing how much these chips can be pushed, but then, it just shows the craftmanship of these chips.

That is also an excellent point. I've got twelve running at the shop right now (underclocking is a work in progress) and it's a bit of a pain to reconfigure them when necessary.

I wanted to do it more from a "manageability" perspective.  Having so many individual controllers is a bit of a pain.  Right now I use a proxy for all my S1's.  Would be nice to

have one Cgminer instance for all of them.

The stock S1 controller, by my measures, only draws about 1W. Not too worried about that power overhead. But it would be nice to rig up something with more space-efficient cooling. Might as well use a single combined controller if you can get them stripped down and lumped into a more compact unit.


Oh, if anyone feels sufficiently benefitted by this work to toss donations, use the BTCMuseum address in my sig. We're buying up old hardware to put together a display of mining history, right now it's all funded by Novak and I's donations and mining on the stuff we're collecting.

I did the block erupter to uart adapter thing too.  Love breathing new life (or repurposing) old hardware.  I am thinking about making a high density miner based on the

S1 hardware.  Would like to get about 20 S1 blades running on one controller.

Right, I've got a handful of machines in hosting using Crazyguy's image for Pi and Cubie running Prismas. It's handy, but the interface (at least what little I've seen) doesn't provide near as much information as I would require to do the job right. I'd rather use a standalone (AM-specific) cgminer instance I can get full data from on the fly. I've never really been a fan of RPi myself, rather use a real computer if I can.

Regarding that adapter, Novak and I work together (GekkoScience is the business we started together) so I already know about 'em. He used one of my old Block Erupters to prototype on. I'll probably use one of the adapters he's gonna be batching (https://bitcointalksearch.org/topic/unofficial-usb-adapters-for-asicminer-tubeprisma-882348, I think about half of them are sold already) to do the testing, if he has any left by then. Pretty handy stuff that guy does.

Actually Crazyguy released a modified version of Cgminer with Minera for the Raspberry pi.  I use it to run one of my tubes.  I bought a generic cp2102 adapter on Amazon

to use with it.  Works really well with any pool.  Had to install a 1K pull-up resistor on the cp2102 adapter.  Here is the original post:

https://bitcointalksearch.org/topic/prismatube-cp2102-mod-working-865503

It probably won't be quite as straightforward to run as an S1, but... actually, I bet it will be if I can cgminer it. The VRMs are the same 53355DQP as the S1, S2, Cube, AM-V1 and a bunch of other hardware use, so I already know everything required to do the work. Just gotta find the time.

I would be interested in the tube experimenting.  I have three I run at around 0.75V that do 730Gh.  This dropped their power consumption by 50W per board.  Heat is much

more manageable as well.  No longer have to use two or more fans.

Yes, something quite a bit like that. Did you backsolve the hex values to make sure they all made sense? My only concern is if the code spits out anything with an OD=3, which can only be valid for frequencies at or below 125MHz. I only check and correct one depth of OD overshoot right now, which would correct OD=2 for frequencies between 250 and 500MHz.

Also, if you have the time to tune instead of setting all banks to the same stock value, I've been finding some banks that worked at voltages lower than my test data. I have one S1 that's pulling 140GH at 152WDC including fan and controller. I think every bank is at 830mV or better with ~1% HW though my test board did that at 850mV. Course one I did today had a few banks that required 860mV to stay clean.

I'm seriously impressed with their chips. 0.8W/GH is pretty good for year-old hardware that shipped at 2W/GH and was already ahead of the curve. I've got 12xS1 on a single DPS2K with power to spare. Figure in four or six months I'll take 'em to the lowerbound and keep 'em going for a while. They're helping fund the museum right now.

Here in another month or so (if I get time; we're starting to get some real work coming in) I plan on doing the same in-depth analysis on AM Tubes.

something like this? :-p


thanks to your efforts with testing different voltage settings on the s1, i now know exactly what to set my s1 boards at ( i have 20 ) should give me aprox 900 GHS for aprox same level as S3s :-p

I may have to read that thread sometime. I've been avoiding it for a while, though I think Novak was paying some attention. In any case, yes I don't mind you using that code. I like commenting the heck out of stuff in case someone else picks it up, and I hope it's actually good enough. There may still be some cases that break it; I should probably write a testbench at some point that feeds it every value from 1 to about 400 and backsolves the output for correctness.

Or I was thinking earlier, an easy way to do it would be to iteratively generate a list of all valid hex codes and then check for the real frequency closest to the desired. But that's kinda cheating. But it'd guarantee the solution.

fantastic, now it works with my odd test cases :-)

i tried myself to get the calculations to work about a month ago, and got stumped on the same, and had given up on it..

(well, im not the best cpp programmer in the world, but i can read the code, and do a little here and there..)

is it ok with you if i implement it into the cgminer i hacked for connecting s1 blades to cp2102s?

thread: https://bitcointalksearch.org/topic/diy-reward-100-antminer-s1s3-blade-on-raspberry-pi-671128

Alrighty, try it now. The problem was it had a check for lowerbound BS criteria (2^OD < 300) but not upperbound (2^OD > 1000) and somehow every test case I gave it didn't violate that. It checks for that condition now, and if it's met it halves the numerator (M+1) and halves the denominator (2^OD, by decrementing OD). The problem there is, if M+1 is an odd number, the halving automatically truncates to M/2 so it rechecks the M/2 and M+2/2 conditions (for the case of f=384MHz, M+1=123 so (M+1)/2=61.5 which truncates to 61 but rounds up to 62) for which one is closer and sticks with the M+1 with the least error. I don't guarantee it works for everything now, but it should work for every frequency for which the initial algorithm calculates an OD of 0, 1 or 2?

hmm, 268.75 returns 1502, but should be 1505..

but yeah everything up to 250 is correct, above, everything which is divideable with 12.5 is correct

I'm thinking it's something with values over 300, because I've put in an aslo of numbers between 200 and 275 and it gave good data on all them.

Additionally, ignore that thing I said about 768.75MHz. I had transcribed the binary wrong; it does actually come out to the correct frequency. But an OD of 2 is impossible for frequencies above 250MHz. I reckon that's where the issues lies; I need to put in an extra check for that condition.

the "funny" thing is, if you but in values that are divideable with 25 you do get the correct value in hex

I think you're right though, that the hex value isn't right. 3d06 comes out to 768.75 which is 384.375 * 2

It's somehow giving an OD of 2, which would actually make 3d07 I think, and actually get you 384.375MHz. But that violates BS constraints, because (2^2)*385 is not between 300 and 1000. I'll have to check over the parts that narrow the criteria.

hmm interresting, might be my g++... what version are you running?

hmm:

seems like its adding ffa to edge cases

Well dangit, quit finding test cases that break the code! You know I gotta solve problems when they're put in front of me.

Also, that's funny... just ran it three times, and I get:

desired setpoint frequency? 385
BS: 0 M: 122 N: 1 OD: 2
Hex value: 3d06
 Resulting actual clock: 384.375000
 Error from desired clock: -0.162339 %
 Expected hashrate output: 196.800000 GH/s
 Best estimate timeout: 35

option 'freq_value'   '3d06'
option 'chip_freq'    '385'
option 'timeout'      '35'


Looks like it might be an issue with the BS; I'll see if there's an initialization thing that my system doesn't mind.

the hex value is also off :-p

tried with your new code:

Yep, looks like I forgot to specify initial min=1 for the case initial i=1, which wasn't a problem with any of the test cases I gave it. Should be working now.

seems like there is an error in your program :-p

Regarding hashrates for a given frequency.

It appears that each chip is capable of 8MH per 1MHz clock rate. What this means is, per chip, the gigahashrate is f*.008

Each bank of an S1 board has 8 chips, so the per-bank gigahashrate is f*.008*8 or f*.064
A full S1 has 8 banks of 8 chips, so 64 chips; the gigahashrate per frequency for the whole machine is f*0.512

Individual VRMs output voltage to only their 8 ASICs. I have observed no problems from setting adjacent VRMs to different voltages. This may come in handy if one bank has a weak chip that can't run at the same point as the rest of the banks; the voltage for that bank can be turned up slightly without any issue.

To disable a VRM, tie a 1K resistor between GND and the end of R5/R68/R40/R54 closest to the inductor. The respective resistor for each given bank ties the buck controller's EN pin high by connecting it to the tap of a 3:1 voltage divider (200K+100K) on the 12V input. A 1K will pull this low and disable the VRM. I haven't tested extensively but it appears that disabling a VRM will cut communications with all downstream banks (comms, clock, something is down), meaning that you can't disable a VRM in the middle and leave the ones on the end functional. I can do some more testing sometime and see if there's a way around this, or if I'm mistaken.

If anyone doesn't know how to change clocks, it's pretty straightforward if you know SSH.

If you're on linux, just SSH into the miner's IP address. Windows users, I recommend a program called puTTy

The default user and password are the same as the config page - root/root

You'll be looking for the file '/etc/config/asic-freq', which is a text file used as a config for setting the ASIC frequency. Pretty easy to follow that nomenclature. The fun part of editing the text file is, as far as I know, the only available editor is 'vi' - which was written back in the day when terminal connections ran on morse-code speeds and keystrokes were precious commodities. To edit text in the file, first press 'i' (or 'I", whatever - I don't think it's case-sensetive) to drop into "insert" mode. Add your values, comment out unused lines, whatever needs to be done.
Hitting ESC will take you back out of "insert" mode. The ":" character is used for commands in vi; entering ':wq!' will save and force a quit. 'reboot' will restart your miner with the new frequency settings applied.

'freq_value' - the hex number used to calculate the frequency
'chip_freq' - the frequency displayed by cgminer
'timeout' - used by cgminer for ASIC communication timing

Calculating the hex value for a given frequency is kind of a pain. Basically, the hex value needs to be backtraced to binary, and then divided into about five pieces. Starting from the MSB (most significant bit, usually the leftmost):

15 - 0
14 - BS
13:7 - M
6:2 - N
1:0 - OD

To calculate the frequency, the above-mentioned variables are tossed into an equation:

f = 25(M+1) / (N+1)(2^OD)

There are, of course, constraints to this. For one, N is a 5-bit value but can only equal 0 or 1. Additionally, the following must be true:

For BS=1, 62.5<= f <= 1000
                 500 <= f(2^OD) <= 1000
For BS=0, 37.5<= f <= 600
                 300 <= f(2^OD) <= 600

This limits the effective precision, because your denominator can now range only within {1,2,4,8} and your OD is limited based on BS and f. It usually doesn't have much effect on the end result, and frequencies can generaly be calculated within 1%.

hex	dec	bin
0	0	0000
1	1	0001
2	2	0010
3	3	0011
4	4	0100
5	5	0101
6	6	0110
7	7	0111
8	8	1000
9	9	1001
A	10	1010
B	11	1011
C	12	1100
D	13	1101
E	14	1110
F	15	1111

Binary is fairly easy to parse once you get the hang of it. At the rightmost bit (the Least Significant Bit, or LSB) you assign a value of 1. Moving left, the values double - to 2, 4, 8 and so on. It's the same as the tens places in decimal counting, except instead of increasing powers of ten (1, 10, 100) you have increasing powers of 2. If there's a '1' at any place, its associated 'place value' is added to the total. So the hex value D, or in decimal 13, is in binary '1101' - which means 1x1 + 0x2 + 1x4 + 1x8, so 1+4+8 = 13. Simple as that. Hex is just a single-digit way of expressing values between 0 and 15. Hex actually is short for "hexadecimal", in which you can see "hex" 6 and "deci" 10, so 16 total. Just as decimal runs on tens, with values being 0-9, and binary runs on twos, with values being 0-1, hexadecimal runs on 16s with values 0-15 (represented as 0-F).

For an example, say f=300. The stock config file tells us the hex for this is 0b81, so the binary version is 0000 1011 1000 0001
If we break that down into our frequency formula, we get:

0|0|0010111|00000|01

15 - 0 - 0 - 0
14 - BS - 0 - 0
13:7 - M - 0010111 - 23
6:2 - N - 00000 - 0
1:0 - OD - 01 - 1

So now we have f = 25(23+1) / (0+1)(2^1) = (25)(24)/(1)(2) = (600)/(2) = 300
f(2^OD) = (300)(2^1) = (300)(2)=600, so BS=0 applies.


I'm not entirely sure how timeouts should best be calculated, but after a bit of statistics on some working values, I figure timeout=13800/frequency - rounded to the nearest 5 - works pretty well.

I wrote up some quick code that, given a clock speed, generates the best BS, M, N, OD, and timeout and prints the data. The code is at www.gekkoscience.com/misc/set_freq.cpp if anyone's interested. Sample output for f=300:

#./set_freq
desired setpoint frequency? 300
BS: 0 M: 23 N: 0 OD: 1
Hex value: 0b81
 Resulting actual clock: 300.000000
 Error from desired clock: 0.000000 %
 Expected hashrate output: 153.600000 GH/s
 Best estimate timeout: 45

option 'freq_value'   '0b81'
option 'chip_freq'    '300'
option 'timeout'      '45'



You should be able to copy-paste the config outputs at the end directly into /etc/config/asic-freq and let it rip.

Oh I like that chart!

Thanks sidehack!

8 )

I honestly think that the way you have detailed your results and posted them will entice others to mod their gear and
Keep them S1's running.

Great job sidehack, truly appreciated

Trends

Others might like the info. I like to be thorough, after all. Really I should have done this a couple months ago, but I didn't worry a lot about messing with S1 because I've only had two since about June and, here at the shop, power is cheap enough that they're still slightly profitable at stock settings (about a nickel a day, but still).

Maybe in the next few weeks I'll do the same for a Tube. Novak's already posted instructions on hacking a USB BE into a USB serial adapter for them, after all.

No I'm fine with the info sidehack.
I've done several resistor change outs on the S1's I just thought you had done something a little different.
thanks

Trends

That is correct. The divider pair on mine was 8200/9760. As an example, on mine I used a 5K6 resistor across the 8200 which (for ease of installation and because I had a through-hole resistor) I tied between the junction of the two adjacent resistors and the high side of a nearby output cap. That requires much less precision than attaching leads directly to the pads of a 0603 SMD component. I measured between 0.815 and 0.825 in a quick check of VRMs on the board after modification, variance mostly due to the 5% tolerance of the 5K6 resistor.
On one VRM I did replace the 8200 with a 3K3 5% and got the same results. I can post pictures of some things later on if desired. It probably wouldn't hurt to put up information about changing clock speeds as well, as that requires SSH and config file editing. I'll also include info on calculating the hex values for various frequency setpoints and the expected hashrate calculations.

So just to be clear
 "Parallel R: The resistor value required in parallel with the VRM feedback resistor, to achieve Vset" is the value of the resistor (calculated?) to add to R3, R66, R38 or R52 if R3, R66, R38, R52 are left in place.

Correct

I'm not entirely sure. The only problem I had with timeout settings was at the 200MHz neighborhood (200, 196, 193). At timeout 70, the draw current would bounce between about 0.8A and 0.2A (idle) as chips would start to hash, and then all drop out. I'm assuming something in the communication between controller and ASICs was hosing it; once I set timeout to 80 everything worked wonderfully.

The only thing I really saw affecting the HW rate was a Vcore too low at a particular frequency. It makes sense, as in CMOS ICs all the switching is done by charge displacements; higher voltages are required to push a given charge through a given impedance faster, and higher gate charges are required to meet source-drain impedance thresholds for switching. Setting the voltages too low will keep the weakest transistors in the IC from switching effectively, introducing bit errors in the pipeline and returning bad data.

Someone with more software knowledge of Bitmain hardware can probably tell you more about what the timeout setting actually does. I've focused so far on the hardware.

sidehack

how would the T/O settings affect the HW error rate?

very nice overview! Im picking up some s1 units this weekend to undervolt a little bit and now i think i know where to aim for if i want 1w/GH

Having recently acquired some AntMiner S1 that another miner in my acquaintance was disposing of for the cost of shipping, I decided to see just how efficiently these little guys could run. With that in mind I set up a test to measure the board-level DC power draw of the mining hardware at various parameter setpoints of core voltage and clock speed.

I connected a controller to a single hashing board with three VRMs disabled. The fourth VRM was wired for precise manual output voltage adjustments in the range of 1.20-0.60V. The controller and fan were powered separately, so only the power required by the single enabled VRM and its bank of 8 ASICs was measured (the idle current from the controller-powering 3.3V buck is  considered negligible).

I used a 12V server PSU as the power source, delivered through a 0.1ohm 1% shunt resistor across which I measured the voltage drop, for input current calculations. I used an oscilloscope for the DC power input (measured at the board's connector, below the shunt) and the VRM output voltage (measured at the output capacitors). It was observed that the fan would pull 12V 1A at maximum speed, and the controller (managing 64 ASICs at 250MHz) consumed 0.34A at 3.3VDC; the maximum additional power draw past board draw, then, is expected to be around 13W. At lower board power consumption, the fan requires much less power; assuming half power for the fan, additional power draw would be around 7W.

I included stable voltage ranges for every 25MHz from 400MHz down to 150MHz, and included the stock setpoint ([email protected]) and the AntMiner S2 stock setpoint ([email protected]) for references. The durations of tests varied, most being between 8 and 20 minutes before sample data was recorded. I tried to run up at least a DiffA of 3000, but sometimes I got distracted and ran more; other times, I got impatient (especially during slow-clock tests) and cut it off at less (typically the 20-minute point). For the first batch of samples (400MHz) I reset the voltage after each dataset was recorded, but did not reboot the device. The calculated error data for each sample at 400MHz is based off the DiffA and HW deltas from the previous sample. For all other samples, the machine was rebooted after setting Vcore.

All measurements were taken on an AntMiner S1 with a build date of 2013/11/18, with a VRM feedback resistor pair R3/R12 of 8200 ohms and 9760 ohms, respectively. All resistor modification calculations are based on this pairing.

GH Expected: Expected gigahashrate for a bank of 8 chips at the setpoint frequency
GH Total: The total expected hashrate for a 64-chip S1 at the setpoint frequency
GH Measured: Reported average hashrate during the measurement period
DiffA: Reported DiffA by the end of the measurement period
HW: Reported HW (hardware errors) by the end of the measurement period
Volts in: DC line voltage into the hashboard, measured at the board terminals
Current in: DC line current into the hashboard, measured across the input shunt (see above)
Power in: DC line power into the hashboard ( Vin*Iin )
Vcore: Measured average VRM output voltage during the sample time
W/GH: The power per measured gigahash-per-second ( Pin/GHM )
HWE Percent: Percentage of hardware errors for the sample period ( HW/[DiffA + HW] )
W/GHE: Watts per expected gigahash-per-second ( Pin/GHE )
Vset: The VRM desired-setpoint voltage, to 0.01V
Replacement R: The resistor value required to replace the VRM feedback resistor (R3, R66, R38, R52), to achieve Vset
Parallel R: The resistor value required in parallel with the VRM feedback resistor, to achieve Vset

Setpoint MHz	GH Expected	GH Total	GH Measured	DiffA	HW	Volts in	Current in	Power in	Vcore	W/GH	HWE Percent	W/GH Expected	Vset	Replacement R	Parallel R
400	25.6	204.8	25.4	4351	0	11.60	3.91	45.36	1.125	1.79	0.00%	1.77	1.130
			25.5	6783	1	11.61	3.81	44.23	1.112	1.73	0.04%	1.73	1.110	8052	446124
			25.6	9599	21	11.63	3.71	43.15	1.100	1.69	0.71%	1.69	1.100	7889	208238
			25.3	12927	208	11.64	3.60	41.90	1.083	1.66	5.32%	1.64	1.080	7564	97523
			24.9	16639	581	11.65	3.51	40.89	1.068	1.64	9.13%	1.60	1.070	7401	75990
375	24.0	192.0	23.8	3014	0	11.65	3.49	40.66	1.110	1.71	0.00%	1.69	1.110	8052	446124
			24.3	3711	0	11.66	3.41	39.76	1.088	1.64	0.00%	1.66	1.090	7727	133856
			24.0	3089	0	11.67	3.36	39.21	1.079	1.63	0.00%	1.63	1.080	7564	97523
			24.2	3327	0	11.67	3.29	38.39	1.069	1.59	0.00%	1.60	1.070	7401	75990
			26.6	3199	0	11.68	3.23	37.73	1.060	1.42	0.00%	1.57	1.060	7239	61745
			24.1	3327	29	11.68	3.18	37.14	1.049	1.54	0.86%	1.55	1.050	7076	51622
			23.5	3071	65	11.69	3.12	36.47	1.040	1.55	2.07%	1.52	1.040	6913	44059
			22.9	3711	212	11.70	3.04	35.57	1.029	1.55	5.40%	1.48	1.030	6751	38194
350	22.4	179.2	24.4	3839	0	11.71	2.97	34.78	1.049	1.43	0.00%	1.55	1.050	7076	51622
			22.9	3327	0	11.71	2.92	34.19	1.040	1.49	0.00%	1.53	1.040	6913	44059
			22.4	3199	0	11.72	2.85	33.40	1.029	1.49	0.00%	1.49	1.030	6751	38194
			22.1	3327	0	11.73	2.80	32.84	1.019	1.49	0.00%	1.47	1.020	6588	33512
			23.8	5119	0	11.73	2.75	32.26	1.009	1.36	0.00%	1.44	1.010	6425	29689
			22.4	3071	6	11.73	2.69	31.55	0.999	1.41	0.19%	1.41	1.000	6263	26508
			22.0	3071	69	11.74	2.64	30.99	0.990	1.41	2.20%	1.38	0.990	6100	23819
			21.5	4067	229	11.75	2.58	30.32	0.979	1.41	5.33%	1.35	0.980	5937	21517
			22.0	4735	0	11.66	3.41	39.76	1.120	1.80	0.00%	1.78	1.120	8215
325	20.8	166.4	20.6	3583	0	11.75	2.56	30.08	1.010	1.46	0.00%	1.45	1.010	6425	29689
			21.2	3071	0	11.76	2.52	29.64	1.000	1.40	0.00%	1.42	1.000	6263	26508
			20.8	3071	0	11.76	2.46	28.93	0.989	1.39	0.00%	1.39	0.990	6100	23819
			21.0	3071	0	11.77	2.42	28.48	0.980	1.36	0.00%	1.37	0.980	5937	21517
			21.4	3071	0	11.77	2.36	27.78	0.968	1.30	0.00%	1.34	0.970	5775	19524
			21.2	3455	0	11.78	2.32	27.33	0.960	1.29	0.00%	1.31	0.960	5612	17781
			20.8	3071	2	11.78	2.27	26.74	0.950	1.29	0.07%	1.29	0.950	5449	16245
			21.5	4863	45	11.79	2.22	26.17	0.939	1.22	0.92%	1.26	0.940	5287	14880
			19.8	4351	172	11.79	2.17	25.58	0.928	1.29	3.80%	1.23	0.930	5124	13660
300	19.2	153.6	19.0	15743	0	11.80	2.11	24.90	0.951	1.31	0.00%	1.30	0.950	5449	16245
			18.7	3199	0	11.81	2.05	24.21	0.938	1.29	0.00%	1.26	0.940	5287	14880
			19.1	3071	0	11.81	2.02	23.86	0.931	1.25	0.00%	1.24	0.930	5124	13660
			19.0	2687	0	11.82	1.97	23.29	0.920	1.23	0.00%	1.21	0.920	4961	12562
			19.2	2431	0	11.82	1.92	22.69	0.909	1.18	0.00%	1.18	0.910	4799	11569
			18.7	2687	2	11.83	1.89	22.36	0.901	1.20	0.07%	1.16	0.900	4636	10666
			18.7	2687	32	11.83	1.85	21.89	0.890	1.17	1.18%	1.14	0.890	4473	9843
			18.2	2559	121	11.84	1.81	21.43	0.881	1.18	4.51%	1.12	0.880	4311	9088
275	17.6	140.8	17.4	3199	0	11.86	1.67	19.81	0.880	1.14	0.00%	1.13	0.880	4311	9088
			17.7	4351	0	11.86	1.63	19.33	0.870	1.09	0.00%	1.10	0.870	4148	8394
			17.8	4479	0	11.86	1.59	18.86	0.860	1.06	0.00%	1.07	0.860	3985	7754
			18.4	3455	21	11.87	1.55	18.40	0.850	1.00	0.60%	1.05	0.850	3823	7161
			17.0	3583	110	11.87	1.52	18.04	0.841	1.06	2.98%	1.03	0.840	3660	6611
250	16.0	128.0	16.2	3583	0	11.89	1.39	16.53	0.840	1.02	0.00%	1.03	0.840	3660	6611
			16.4	2559	0	11.89	1.36	16.17	0.830	0.99	0.00%	1.01	0.830	3497	6098
			16.1	3327	0	11.89	1.33	15.81	0.820	0.98	0.00%	0.99	0.820	3335	5620
			16.0	3071	4	11.90	1.29	15.35	0.810	0.96	0.13%	0.96	0.810	3172	5173
			15.2	3327	46	11.90	1.26	14.99	0.802	0.99	1.36%	0.94	0.800	3009	4754
			15.2	3839	240	11.90	1.23	14.64	0.791	0.96	5.88%	0.91	0.790	2847	4360
225	14.4	115.2	14.3	3199	0	11.91	1.12	13.34	0.789	0.93	0.00%	0.93	0.790	2847	4360
			15.0	2815	0	11.91	1.09	12.98	0.780	0.87	0.00%	0.90	0.780	2684	3990
			15.3	3071	0	11.91	1.06	12.62	0.770	0.83	0.00%	0.88	0.770	2521	3641
			14.3	3199	56	11.92	1.03	12.28	0.759	0.86	1.72%	0.85	0.760	2359	3311
			15.1	3071	121	11.92	1.01	12.04	0.750	0.80	3.79%	0.84	0.750	2196	2999
200	12.8	102.4	12.6	3199	0	11.93	0.95	11.33	0.768	0.90	0.00%	0.89	0.770	2521	3641
			12.7	4351	0	11.93	0.93	11.09	0.759	0.87	0.00%	0.87	0.760	2359	3311
			13.1	3967	0	11.94	0.91	10.87	0.749	0.83	0.00%	0.85	0.750	2196	2999
			12.5	4479	0	11.94	0.88	10.51	0.739	0.84	0.00%	0.82	0.740	2033	2704
			14.0	3583	0	11.94	0.86	10.27	0.729	0.73	0.00%	0.80	0.730	1871	2424
			12.7	3583	8	11.94	0.85	10.15	0.721	0.80	0.22%	0.79	0.720	1708	2157
196	12.5	100.0	12.8	3199	0	11.93	0.94	11.21	0.770	0.88	0.00%	0.90	0.770	2521	3641
			13.1	3199	2	11.95	0.82	9.80	0.720	0.75	0.06%	0.78	0.720	1708	2157
175	11.2	89.6	11.6	3071	0	11.96	0.74	8.85	0.719	0.76	0.00%	0.79	0.720	1708	2157
			11.2	2559	0	11.97	0.72	8.62	0.709	0.77	0.00%	0.77	0.710	1545	1904
			12.1	3327	1	11.97	0.70	8.38	0.697	0.69	0.03%	0.75	0.700	1383	1663
			9.7	3199	2	11.97	0.62	7.42	0.691	0.77	0.06%	0.66	0.690	1220	1433
150	9.6	76.8	9.6	3199	1	11.98	0.60	7.19	0.690	0.75	0.03%	0.75	0.690	1220	1433

Noteworthy data points:
- 350MHz @ 1.12Vcore, stock S1 setpoint
- 196MHz @ 0.77Vcore, stock S2 setpoint
- 225MHz @ 0.77Vcore, maximum S2 stability point at stock Vcore
- 200MHz @ 0.72Vcore, minimum stability point at 200MHz - some ASICs were unstable below this voltage, causing resets
- 175MHz @ 0.69Vcore, hashrate reports low due to one chip dropping out entirely; remaining 7 hashed well (average 1.39GH, expected 1.20)
- 150MHz @ 0.69Vcore, minimum stable at 150MHz. At 0.68Vcore all chips dropped out and reported 'X' in ASIC status

I currently have a full machine modified for operation at [email protected] (using a 5k6 5% parallel resistor), for which the expected output is 128.0GH at a total power draw (including half-power 6W fan and 1W controller) of about 133W. I measured the power draw at 11.34V 11.52A (using a 1% 0.05ohm shunt; the PSU interface board's 5% shunt measurement reported 11.43A), for 130.6W DC power consumption. The current stats, at 0h 31m 53s operation, are 128.61GH, 59HW, 56191DiffA
This equates to a DC efficiency of 1.02W/GH with a hardware error rate of 0.1%
The fan is reporting 1020RPM, temps 41/43C in a ~65F ambient environment

A note on the maximum S2 stability point at stock Vcore: the S2 uses the same VRM hardware ( 53355DQP monolithic synchronous buck driver ) as in the S1 (and also ASICMiner Cubes and Tubes). Because the S2 is clocked and volt-set to a lower operating point, each ASIC draws far less current than the ASICs in a stock-set S1. The S1 allocates 8 ASICs per VRM; the S2 allocates 16. Therefore, at any particular setpoint on the S1, the power draw per VRM for the same setpoint on the S2 is doubled. If an S1 is stable at 0.77Vcore 225MHz, it is logical to think the S2 would be also. However, the power draw from the S2's VRMs would be twice the 12.62W seen by the S1, at 25.24W. Assuming a 90% efficient regulator (which efficiency typically drops as current increases, due to parasitic resistances in the inductor and drive FETs), that's an estimated output power of 22.72W; as we're outputting 0.77V the current draw is then 29.5A. The 53355DQP is rated for 30A, which means that you're stressing it to 98% capacity continuously. With a best-case efficiency of 95% (and a few other assumptions, to make the comparison easier), the output power is 23.98W, with an output current of 31.1A, a good 3% past rating. With this in mind, it is probably a terrible idea to try and clock an S2 up to 225MHz even if ASIC cooling was adequate.