BITMAIN Antminer S1 support and OverClocking thread

[Darthswan]

hi guys,

i'm at a freq of 375 but my hw error rate is 7.7%, what's your advice?

what was the rate at 350?

[jjiimm_64]

hi guys,

i'm at a freq of 375 but my hw error rate is 7.7%, what's your advice?

what was the rate at 350?

imho, HW rates are not as important since i started using asics... bfl had alot, so does the ants.. it is the accepted share rate at the pool that counts... 

at 375 freq.. if the pool is reporting ~195Gh, what does it matter?

[Darthswan]

hi guys,

i'm at a freq of 375 but my hw error rate is 7.7%, what's your advice?

what was the rate at 350?

imho, HW rates are not as important since i started using asics... bfl had alot, so does the ants.. it is the accepted share rate at the pool that counts... 

at 375 freq.. if the pool is reporting ~195Gh, what does it matter?

I hear so many different views on this.  Some say it matters, some say it doesn't.  Curious, what is the consensus?

[jjiimm_64]

I am not going to claim much technical knowledge about chips.. but from what I read, sha2 asic chips gives up error checking for speed, hence the HW errors...

as long as the pool is reporting a good hashrate, which is estimated by accepted shares.. then your good to go, the pool pays you for your shares!!

[mindtrip]

Not sure if this has been answered here I read through most of this thread and did not find an answer.

When I have an Antminer S1 Setup an a multicoin profit switching pool as my primary is appears every time the pool changes coins my antminer Drops and switches to my backup pool for for about 5 min then switches back to my primary pool. I know this is an issue with version of Cgminer I am just curious if anyone has come up with a way to fix this on antminers?

[Darthswan]

I am not going to claim much technical knowledge about chips.. but from what I read, sha2 asic chips gives up error checking for speed, hence the HW errors...

as long as the pool is reporting a good hashrate, which is estimated by accepted shares.. then your good to go, the pool pays you for your shares!!

I wonder does a lot of hw affect the chips in any way?

[jedimstr]

I am not going to claim much technical knowledge about chips.. but from what I read, sha2 asic chips gives up error checking for speed, hence the HW errors...

as long as the pool is reporting a good hashrate, which is estimated by accepted shares.. then your good to go, the pool pays you for your shares!!

It's all about the balance.  If it's too much HW, you're losing accepted shares but if your overall hashrate is much higher, it could be desirable anyway.

Just have to find the sweet spot.  393.75mhz has worked best for me.

Mine:
375Mhz - 195 or so GHs - almost no HW errors
393.75Mhz - 204 GHs - 0.06% HW
400Mhz - 206 GHs - 1.98% HW

The HW seems miniscule in the example above, but 393.75 resulted in the best Accepted rate.

[mephke]

hi guys,

i'm at a freq of 375 but my hw error rate is 7.7%, what's your advice?

what was the rate at 350?

imho, HW rates are not as important since i started using asics... bfl had alot, so does the ants.. it is the accepted share rate at the pool that counts... 

at 375 freq.. if the pool is reporting ~195Gh, what does it matter?

btcguild says 199.59 GH/s at 375. i guess i'm happy with this then ;-)

[freebit13]

Hi all.  Just a few tips from someone who has overclocked many S1-s over the last few months. Specially the enabling of the asic autoprobe mode (tip #3) delivers optimum settings and performance.

Just my two cents.

1) Use the "joe" editor instead of the "vi" editor. It saves you a lot of irritation... Joe is much easier to use.
How:
- login to your miner, go to the System Tab, got to the Software sub-tab 
- click the small "Update Lists" button
- enter: joe  in the "Download and install package:" input box and press the OK button at the right
This will install the joe editor on your miner.

Commands:  joe <filename>
Just start moving around and editing your file. Press <ctrl><k> simultaneously to enter command mode , e.g. press H for help (<ctrl>+k H).
Press <ctrl>-k x  to save and exit.

(assuming that you are logged in to your miner using a secure-shell program)
2) Edit the /etc/config/cgminer file using "joe" ( joe /etc/config/cgminer ) as per instructions in this thread, changing option chip_frequency to '400' and option miner_count to '35' although the latter is obsolete after the following tip 3.


3) Edit the /etc/init.d/cgminer file to enable the automatic detection and hardware optimization that cgminer can perform on your Antminer!
joe /etc/init.d/cgminer

Change the line: $APP --lowmem --bitmain-options 115200:32:8:$_T0:$_cf:$_regv -q >/dev/null 2>&1
to: $APP --bitmain-auto -q >/dev/null 2>&1

This will auto-probe and install the optimal settings for your asic, depending on the frequency chosen in step 2
You can now choose to save and exit joe:  <ctrl>-k x

4) If you want to run on multiple pools simultaneously, balancing your miner's resources, add "--balance" to the line above, so that it becomes:
$APP --bitmain-auto --balance -q >/dev/null 2>&1

Reboot your miner.


I run three miners (different batches w. the 2014-2-7 firmware) @ www.angelminers.org with these settings and they perform great!
 
By the way, here is a great video with simple instructions on how to upgrade your S1's firware: http://www.youtube.com/watch?v=HIAvtb2SnJY


Cheers!

Martin.

~ https://www.angelminers.org - stop ego-mining, start sharing! Charity 2.0 ~ 

Hey Martin, thanks for the tips, this make things a lot easier, although I did notice some things along the way, but I'm on an older firmware so it might be different (this script is also a bit of a mess):

1. Editing the /etc/config/cgminer file had no effect on my speeds, the asic-freq file seems to override it
2. $APP didn't change anything either, I found that only editing AOPTIONS made any difference. Making changes and looking in the system log seems to confirm this.
3. when using --bitmain-auto, my ant won't hash, it connects and all, but won't hash (as mentioned I'm on older firmware), does "--bitmain-auto" actually show up in your system log?
4. I added the --balance parameter to the PARAMS string, but that's just me being pedantic

I also noticed a non-related problem with ntp never working properly and found that at the bottom of the init.d/cgminer file, there are leading digits and points before the addresses which breaks the script. I removed them (0.openwrt.org) and finally ntp seems to work

Thanks again for sharing!

[tss]

is there a way to change the low end value for the rpm speed of the antminer fan?

[jjiimm_64]

Hey Martin, thanks for the tips, this make things a lot easier, although I did notice some things along the way, but I'm on an older firmware so it might be different (this script is also a bit of a mess):

1. Editing the /etc/config/cgminer file had no effect on my speeds, the asic-freq file seems to override it
2. $APP didn't change anything either, I found that only editing AOPTIONS made any difference. Making changes and looking in the system log seems to confirm this.
3. when using --bitmain-auto, my ant won't hash, it connects and all, but won't hash (as mentioned I'm on older firmware), does "--bitmain-auto" actually show up in your system log?
4. I added the --balance parameter to the PARAMS string, but that's just me being pedantic

I also noticed a non-related problem with ntp never working properly and found that at the bottom of the init.d/cgminer file, there are leading digits and points before the addresses which breaks the script. I removed them (0.openwrt.org) and finally ntp seems to work

Thanks again for sharing!

for #2 you should edit the file /etc/config/asic-freq

[freebit13]

Hey Martin, thanks for the tips, this make things a lot easier, although I did notice some things along the way, but I'm on an older firmware so it might be different (this script is also a bit of a mess):

1. Editing the /etc/config/cgminer file had no effect on my speeds, the asic-freq file seems to override it
2. $APP didn't change anything either, I found that only editing AOPTIONS made any difference. Making changes and looking in the system log seems to confirm this.
3. when using --bitmain-auto, my ant won't hash, it connects and all, but won't hash (as mentioned I'm on older firmware), does "--bitmain-auto" actually show up in your system log?
4. I added the --balance parameter to the PARAMS string, but that's just me being pedantic

I also noticed a non-related problem with ntp never working properly and found that at the bottom of the init.d/cgminer file, there are leading digits and points before the addresses which breaks the script. I removed them (0.openwrt.org) and finally ntp seems to work

Thanks again for sharing!

for #2 you should edit the file /etc/config/asic-freq

Yup, thanks, it was kinda implied by no.1

[Cheeseater]

I am not going to claim much technical knowledge about chips.. but from what I read, sha2 asic chips gives up error checking for speed, hence the HW errors...

as long as the pool is reporting a good hashrate, which is estimated by accepted shares.. then your good to go, the pool pays you for your shares!!

It's all about the balance.  If it's too much HW, you're losing accepted shares but if your overall hashrate is much higher, it could be desirable anyway.

Just have to find the sweet spot.  393.75mhz has worked best for me.

Mine:
375Mhz - 195 or so GHs - almost no HW errors
393.75Mhz - 204 GHs - 0.06% HW
400Mhz - 206 GHs - 1.98% HW

The HW seems miniscule in the example above, but 393.75 resulted in the best Accepted rate.

Could you please post the the freq and time out numbers you're using for 393.75? I can't seem to find them in the thread. Thanks

[jedimstr]

I am not going to claim much technical knowledge about chips.. but from what I read, sha2 asic chips gives up error checking for speed, hence the HW errors...

as long as the pool is reporting a good hashrate, which is estimated by accepted shares.. then your good to go, the pool pays you for your shares!!

It's all about the balance.  If it's too much HW, you're losing accepted shares but if your overall hashrate is much higher, it could be desirable anyway.

Just have to find the sweet spot.  393.75mhz has worked best for me.

Mine:
375Mhz - 195 or so GHs - almost no HW errors
393.75Mhz - 204 GHs - 0.06% HW
400Mhz - 206 GHs - 1.98% HW

The HW seems miniscule in the example above, but 393.75 resulted in the best Accepted rate.

Could you please post the the freq and time out numbers you're using for 393.75? I can't seem to find them in the thread. Thanks

        option 'freq_value'    '5f05'  #393.75M
        option 'chip_freq'     '393.75'
        option 'timeout'       '36'

[mindtrip]

I am not going to claim much technical knowledge about chips.. but from what I read, sha2 asic chips gives up error checking for speed, hence the HW errors...

as long as the pool is reporting a good hashrate, which is estimated by accepted shares.. then your good to go, the pool pays you for your shares!!

It's all about the balance.  If it's too much HW, you're losing accepted shares but if your overall hashrate is much higher, it could be desirable anyway.

Just have to find the sweet spot.  393.75mhz has worked best for me.

Mine:
375Mhz - 195 or so GHs - almost no HW errors
393.75Mhz - 204 GHs - 0.06% HW
400Mhz - 206 GHs - 1.98% HW

The HW seems miniscule in the example above, but 393.75 resulted in the best Accepted rate.

Could you please post the the freq and time out numbers you're using for 393.75? I can't seem to find them in the thread. Thanks

        option 'freq_value'    '5f05'  #393.75M
        option 'chip_freq'     '393.75'
        option 'timeout'       '36'

I am using the same seems to run much better then 400

[wise1080]

I am not going to claim much technical knowledge about chips.. but from what I read, sha2 asic chips gives up error checking for speed, hence the HW errors...

as long as the pool is reporting a good hashrate, which is estimated by accepted shares.. then your good to go, the pool pays you for your shares!!

It's all about the balance.  If it's too much HW, you're losing accepted shares but if your overall hashrate is much higher, it could be desirable anyway.

Just have to find the sweet spot.  393.75mhz has worked best for me.

Mine:
375Mhz - 195 or so GHs - almost no HW errors
393.75Mhz - 204 GHs - 0.06% HW
400Mhz - 206 GHs - 1.98% HW

The HW seems miniscule in the example above, but 393.75 resulted in the best Accepted rate.

Could you please post the the freq and time out numbers you're using for 393.75? I can't seem to find them in the thread. Thanks

        option 'freq_value'    '5f05'  #393.75M
        option 'chip_freq'     '393.75'
        option 'timeout'       '36'

I am using the same seems to run much better then 400

First of all Hello for my first post and second I agree with the above, after experimenting with a few frequency's and running 10 hour benchmarks on each i have found the sweet to spot to be 393.75, at 375 i get no hardware errors at all for a speed of about 195gh but at 393 it gains that extra 10gh (205gh) with very minimal HW. Its interesting that another small bump above this can push the HW error rate well over 1%. So i guess bottom line is don't set it at 400 its not worth 1-2gh for all the hardware errors imo. I'm going to try some cooling mods on the unit and will post results later

[Cheeseater]

I am not going to claim much technical knowledge about chips.. but from what I read, sha2 asic chips gives up error checking for speed, hence the HW errors...

as long as the pool is reporting a good hashrate, which is estimated by accepted shares.. then your good to go, the pool pays you for your shares!!

It's all about the balance.  If it's too much HW, you're losing accepted shares but if your overall hashrate is much higher, it could be desirable anyway.

Just have to find the sweet spot.  393.75mhz has worked best for me.

Mine:
375Mhz - 195 or so GHs - almost no HW errors
393.75Mhz - 204 GHs - 0.06% HW
400Mhz - 206 GHs - 1.98% HW

The HW seems miniscule in the example above, but 393.75 resulted in the best Accepted rate.

Could you please post the the freq and time out numbers you're using for 393.75? I can't seem to find them in the thread. Thanks

        option 'freq_value'    '5f05'  #393.75M
        option 'chip_freq'     '393.75'
        option 'timeout'       '36'

Thanks changed a cranky 400 to these and its much happier now.

[faxfan2002]

Just received my 3rd S1 today and it is incredible slow (170GH/S) and with relatively (compare to other my other s1's) high hardware errors (0.1 compared to ~.01).

The one thing I will say is that when I received it I could see absolutely no thermal grease / paste leakage at all, temp's don't seem to be issue +1/2c above my other two miners but they do have a pull fan on them.

Any suggestions? I don't want to OC until I'm sure the unit is ok.

[jedimstr]

Just received my 3rd S1 today and it is incredible slow (170GH/S) and with relatively (compare to other my other s1's) high hardware errors (0.1 compared to ~.01).

The one thing I will say is that when I received it I could see absolutely no thermal grease / paste leakage at all, temp's don't seem to be issue +1/2c above my other two miners but they do have a pull fan on them.

Any suggestions? I don't want to OC until I'm sure the unit is ok.

Update the firmware to the latest?

[samsonn25]

Just received my 3rd S1 today and it is incredible slow (170GH/S) and with relatively (compare to other my other s1's) high hardware errors (0.1 compared to ~.01).

The one thing I will say is that when I received it I could see absolutely no thermal grease / paste leakage at all, temp's don't seem to be issue +1/2c above my other two miners but they do have a pull fan on them.

Any suggestions? I don't want to OC until I'm sure the unit is ok.

There is no thermal grease because they cleaned it up while it was farming last month.  jk