Topic: AntMiner S1 Underclocking, a thorough discussion - page 2. (Read 8332 times)

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 )