Topic: BITMAIN Antminer S1 support and OverClocking thread - page 33. (Read 144941 times)

I knew I read this somewhere but I could not remember where but I have found it whilst looking for clues on tuning the Ant's

Future: We are designing a type of new control board based on ARM A8. When it is ready, the chain number can be up to 16, and the chip number can be up to 256 per chain.

https://github.com/AntMiner/AntGen1/blob/master/PCB/README.md

when I got it today antminer as a heap?

The formula is HW / (HW + DiffA + Diffr + DiffS) = %

I haven't managed to control the fan yet, but for those who don't care about noise and want better cooling you can just remove the blue wire from the fan connector (or cut it, if you're lazy). Just use a small precision flat blade screwdriver and push in the little locking tab at the back of the 4 pin fan connector. In the absence of a PWM signal the fan just spins up to full speed, which the Antminer is reporting as 3900RPM. Doing that dropped my temps from 47 to 35 at 400MHz.

Just remember, When overclocking the antminer u1's, you need to replace some of the resistors so the main asic's can get more power. That may be the case here. The HW rate may come down if the asic's got more voltage. Just a thought.

Here I come with my conclusion.

According to 'AntMiner U1 Manual' (I assumed that it's also for AntMiner S1 too)

The smallest increment is 6.25 MHz (which comes from 25/4)

Here come the freq_value and the hex.

375     MHz    '4E81'    OR   '0700'
387.5   MHz    '5E85'
393.75 MHz    '5F05'
400     MHz    '4F81'   OR   '0780'
406.25 MHz    '6005'
412.5  MHz     '6085'

Those come from calculation, only some (such as 4E81, 4F81, 6005) are tested.
Experiment on your own risk, don' forget to back up your file or config.

PS. The smallest increment would be  3.57 (25/7, also apply to 25/6, 25/5), but it will break some statements in the manual (NR= 1 or 2).
Anyway, I have tried something like

403.57 MHz with 1%   HW error
404.17 MHz with 1.2% HW error
405     MHz with 1.5% HW error

Each increment in MHz gave me a little more hashrate as well as more HW error.
They all worked for me, but I DO NOT recommend all of them.

To play safe, 400 MHz is the best one (for me for now), with relatively low HW error and stated in the manual+FAQ. =)

Hi,

One of my customers is claiming the unit was hashing just fine for around a day, then he powered it down carefully, moved it and it would not power up again (cgminer showed empty on miner status), after which he managed to get it to power on if he just plugged in one of the blades, however the fan would not spin (so he powered it down quickly).

Any ideas on this one?

HW rate doesnt really mean anything will fry, just means the chips are spitting out random data more often then valid results... due to being pushed to their limits at the voltage they are running. Increasing of voltage is what really can start to do damage ... that is if not done carefully =)

Also, I wonder what each of those fields in the OC equation actually mean...

Likely, and do not break any rule
(Even there is no N=1 seen before)
I am gonna try 406.25MHz with '6005' too

Here are values that do not break the rule.  
(Edited:: The strikethrough values violate the NR rule, which can be either 1 or 2)
(Even though it worked, but I'd better follow the manual)

7009              404.17   MHz
2810              405       MHz
6005              406.25   MHz
7089              408.33   MHz
6085              412.5   MHz

You should know what you are trying with your ant, I have no responsibility for any damages in any experiments.
Please double check the value with the rule.  I am now testing only 6005 with my ant, other values come from the calculation.

Here is '6005' expecting for 406.25 MHz hashrate running for 1.5 hr with 1.5% HW error.



FYI, So far, from 350MHz to 400MHz, and your hashrate changes from 180 to 200 GHash/s and a little more HW error.
which means increasing 50MHz to your ant provides more  20 GHash/s.
(every 5MHz gives you extra 2 GHash/s).  You could weight the risk and reward  

For me, 400MHz (0780/4F81) is fine 203 GHash/s with less than 1% HW error.
Other MHz's are still in the experiment.

Anyone know the effect of HW error affecting to the Antminer? Will it fry up our HW in long run or drop the hashrate?
Please suggest .. which one is better

0.  21x.x GHash/s with 4.xx% HW error
1.  207.x GHash/s with 1.5x% HW error
2.  205.x GHash/s with 1.1x% HW error
3.  203.x GHash/s with 0.8% HW error

I think if we change N = 1 .. it would make NR = 2 ... we could keep NO @ 2 .. this would result in 393mhz and all the values staying under the 1000 requirement.. =)

I think 5f05 would be 393mhz - confirmed and now .. no longer breaching that 1000 rule...

This is covered in the first few pages of the thread...

Tell me how do we change up the cgminer parameters

It did still work, as you and I already tried, but I don't know whether it will harm anything in the long run or not.
Otherwise, why it states like that.

Anyway, as I calculate ...

5e82 = 387.5   MHz
5f02 = 393.75 MHz
5f82 = 400      MHz
6002 = 406.25 MHz
6082 = 412.5   MHz

You may try @387.5 MHz for 4F01 and 5E82 to see any differences. HW errors or something else??
If nothing different, 4F01 may be the better choice.

Ah, very handy!! so, if I did this right, 5f02 should be 393mhz!

5e82 ~ 387mhz
7e03 ~ 390mhz
5f02 ~ 393mhz
7f03 ~ 396mhz
6082 ~ 406mhz


Im noticing, in my calculations that by setting OD=3, which in turn sets NO=8 means you have much finer grain speeds ...  

The only part Im confused about is when BS=1 equation .. are those 2 requirements after that? because the 5f82 ... which is NO=4 ... is 400*4 (1600) which is not under the stated 1000
But it still works? ...

Here they are ...



It comes from the Antminer U1 overclock manual. But I think this should be compatible to Antminer S1, too.

Let's see the example of why 0780 and 4F81 are 400MHz.

HEX                   BINARY                          15/BS         M                               N                            OD
0780                 0000  0111  1000  0000       00          00 0111 1   = 15          000 00  = 0              00 = 0 which NO=1
4F81                 0100  1111  1000  0001       01          00 1111 1   = 31          000 00  = 0              01 = 1 which NO=2
5F82                 0101  1111  1000  0010       01          01 1111 1   = 63          000 00  = 0              10 = 2 which NO=4

Fout = 25 * (M+1) / ((N+1)*NO)

Fout(0780) = 25 * (15+1) / (1*1) = (25*16)/1 = 400 MHz
Fout(4F81) = 25 * (31+1) / (1*2) = (25*32)/2 = 400 MHz
Fout(5F82) = 25 * (63+1) / (1*4) = (25*64)/4 = 400 MHz

Actually, 5F82 is also 400 MHz, but due to the instruction below 500 <= Fout * NO <=1000
Fout(5F82) = 400MHz, therefore,  Fout*4 = 1600 and over 1000.

So I think I should not config 5F82 for 400MHz, according to this manual.
I don't say that it does not work (I tried it before understanding the HEX, it worked)
but you have also another 2 freq_values which give you the same MHz and get along with the instruction in the manual.

A little bit too long, anyway, I hope you enjoy my lecture, lol.

Any questions are welcome.



If this is useful, any donations/tips are welcome => 12QAQhbmTzV7sJ9sg8xT96JAneE4S89sS6  

Did u just figure out those particular ones or do you know what the actual "pattern/equation" is?

I now figure out the HEX.

400MHz     = 0780, = 4F81 and also = 5F82, but 0780 and 4F81 are preferable,
                  as it comes with the config and don't know whether 5F82 will do any harm.
387.5 MHz = 4F01 and also = 5E82, you may try 4F01, it should be OK (may give different HW error, but same MHz)

So I tried something like 412.5 MHz '5001', and again very high HW errors 4.x% (~ 425MHz's HW error).
I think I have good-enough cooling, it might be the hardware stuff for the error, so I went back to 400MHz then.

Refer to the manual, what I can tell you is that the freq_value ends with '2' should not be over 250MHz.
So you'd better use the freq_value ends with '0' or '1' instead.

For freq_value ends with '3', you won't get any better result than 400MHz, and also quite risky for the hardware.

FYI, also 6082 = 412.5MHz and 6002 = 406.25MHz (Risky, it's over 250MHz)
I have no responsibility for any damages for any experiments.

in my tests, 0780 & 4f81 yielded the same result - so I think they are both very close, if not 400mhz

I can confirm that my overnight test seems to be a success... averaging 197GH @ .59% HW ... which is higher than the 375mhz setting, but lower than 400mhz
I dont know what the exact equation is for figuring out hashrate based on clock but the numbers match up with 512*mhz = mh/s
Based on that equation, 5e82 seems to clock in right around 384mhz

Also, if someone wants to experiment w/ the xx83 ranges ... I imagine the values will start in the 6x83...

Thanks to GenTarkin for the tests, which you stated '5e82' seems to be some value between 375-400 MHz.

So, I'm now trying '5f82'  with '34' timeout.  As I guess it should be something 400MHz++.
It seems OK with the 208-212 avg, together with 0.57% HW error.

Edit:: As time goes by, hashrate seems to drop to 205-206, but still higher than '4f81' 400MHz which I got avg of 203 GHash/S.
However, this test took place during night period, I am not sure whether the lower temp at night helped for the extra hashrate or not.



I've already tried '6082' (higher hashrate) and it came out with 4.4% HW error.

I get 5% more hashrate with 0780 then with 4f81 but why not try it yourself?