AntMiner S1 Underclocking, a thorough discussion

[sidehack]

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 (350MHz@1.12Vcore) and the AntMiner S2 stock setpoint (196MHz@0.77Vcore) 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 250MHz@0.82V (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.

[klondike_bar]

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

[Trends]

sidehack

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

[sidehack]

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.

[Trends]

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

[sidehack]

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.

[Trends]

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

[sidehack]

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.

[Trends]

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

[7queue]

Oh I like that chart!

Thanks sidehack!

8 )

[sidehack]

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.

[sidehack]

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.

[CHAOSiTEC]

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

Code:

desired setpoint frequency? 368
BS: 0 M: 4198495 N: 0 OD: 0
Hex value: 20082f80
 Resulting actual clock: 104962400.000000
 Error from desired clock: 28522290.000000 %
 Expected hashrate output: 53740748.800000 GH/s
 Best estimate timeout: 0

option 'freq_value'   '20082f80'
option 'chip_freq'    '368'
option 'timeout'      '0'

[sidehack]

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.

[CHAOSiTEC]

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.

the hex value is also off :-p

tried with your new code:

Code:

desired setpoint frequency? 385
BS: 4198398 M: 122 N: 1 OD: 2
Hex value: 3ffbd06
 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'   '3ffbd06'
option 'chip_freq'    '385'
option 'timeout'      '35'

[sidehack]

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.

[CHAOSiTEC]

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.

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

hmm:

Code:

desired setpoint frequency? 406
BS: 4198398 M: 64 N: 0 OD: 2
Hex value: 3ffa002
 Resulting actual clock: 406.250000
 Error from desired clock: 0.061572 %
 Expected hashrate output: 208.000000 GH/s
 Best estimate timeout: 35

option 'freq_value'   '3ffa002'
option 'chip_freq'    '406'
option 'timeout'      '35'

seems like its adding ffa to edge cases

[sidehack]

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.

[CHAOSiTEC]

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.

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

[sidehack]

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.