Bitcoin Forum
December 12, 2017, 06:42:35 AM *
News: Latest stable version of Bitcoin Core: 0.15.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 [25] 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 »
  Print  
Author Topic: BITMAIN Antminer S1 support and OverClocking thread  (Read 143945 times)
Darthswan
Hero Member
*****
Offline Offline

Activity: 490


Best IoT Platform Based on Blockchain


View Profile
March 01, 2014, 10:43:18 AM
 #481

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?


     
     ██
    ███
  █ ███
 ██ ███
 ██ ███
 ██ ███
 ██ ███
 ██ ███
 ██ ███
 █  ██
   



         ▄▄▄██████████▄▄▄
      ▄████████████████████▄
    ▄████████████████████████▄
   █████▀▀▀▀▀▀███████▀▀▀▀▀▀████
  ██████      ███████      █████
 █████████▌   ███████   █████████
▐█████████▌   ███████   █████████▌
████████                   ███████
▐███████▄▄▄   ▄▄▄▄▄▄▄   ▄▄▄██████▌
 ██████████   ███████   █████████
  ██████▀▀▀   ███████   ▀▀▀█████
   █████      ███████      ████
    ▀████████████████████████▀
      ▀████████████████████▀
         ▀▀▀██████████▀▀▀


 
 ▄▄         ▄▄             ▄▄
▐██▌       ▐██▌           ███▌
▐██▌       ▐██▌     ▄▄▄▄▄▄███▌      ▄▄▄▄▄▄▄▄▄     ▄▄▄▄▄▄▄▄▄
▐██▌       ▐██▌   ▄██████████▌   ▄███████████   ▄██████████
▐█████████████▌  ███▀     ▐██▌  ▐███▀     ███  ▐███▀
▐██▌       ▐██▌ ▐██▌      ▐██▌  ███▌      ███  ███▌
▐██▌       ▐██▌  ███▄     ▐██▌  ▐███▄     ███  ▐███▄
▐██▌       ▐██▌   ▀██████████▌   ▀██████  ███   ▀██████████
▀▀         ▀▀       ▀▀▀▀▀▀▀▀       ▀▀▀▀  ▀▀▀      ▀▀▀▀▀▀▀▀


██
███
███
███ ██
███ ██
███ ██
███ ██
███ ██
███ ██
 ██ 
  █

.......Whitepaper.......
.
██████████████████████████████████████████████████████████████████████████████████████████████
.
FacebookTwitterBitcointalk
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1513060955
Hero Member
*
Offline Offline

Posts: 1513060955

View Profile Personal Message (Offline)

Ignore
1513060955
Reply with quote  #2

1513060955
Report to moderator
1513060955
Hero Member
*
Offline Offline

Posts: 1513060955

View Profile Personal Message (Offline)

Ignore
1513060955
Reply with quote  #2

1513060955
Report to moderator
jjiimm_64
Legendary
*
Offline Offline

Activity: 1862


View Profile
March 01, 2014, 04:20:08 PM
 #482

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?

1jimbitm6hAKTjKX4qurCNQubbnk2YsFw
Darthswan
Hero Member
*****
Offline Offline

Activity: 490


Best IoT Platform Based on Blockchain


View Profile
March 01, 2014, 04:48:53 PM
 #483

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?


     
     ██
    ███
  █ ███
 ██ ███
 ██ ███
 ██ ███
 ██ ███
 ██ ███
 ██ ███
 █  ██
   



         ▄▄▄██████████▄▄▄
      ▄████████████████████▄
    ▄████████████████████████▄
   █████▀▀▀▀▀▀███████▀▀▀▀▀▀████
  ██████      ███████      █████
 █████████▌   ███████   █████████
▐█████████▌   ███████   █████████▌
████████                   ███████
▐███████▄▄▄   ▄▄▄▄▄▄▄   ▄▄▄██████▌
 ██████████   ███████   █████████
  ██████▀▀▀   ███████   ▀▀▀█████
   █████      ███████      ████
    ▀████████████████████████▀
      ▀████████████████████▀
         ▀▀▀██████████▀▀▀


 
 ▄▄         ▄▄             ▄▄
▐██▌       ▐██▌           ███▌
▐██▌       ▐██▌     ▄▄▄▄▄▄███▌      ▄▄▄▄▄▄▄▄▄     ▄▄▄▄▄▄▄▄▄
▐██▌       ▐██▌   ▄██████████▌   ▄███████████   ▄██████████
▐█████████████▌  ███▀     ▐██▌  ▐███▀     ███  ▐███▀
▐██▌       ▐██▌ ▐██▌      ▐██▌  ███▌      ███  ███▌
▐██▌       ▐██▌  ███▄     ▐██▌  ▐███▄     ███  ▐███▄
▐██▌       ▐██▌   ▀██████████▌   ▀██████  ███   ▀██████████
▀▀         ▀▀       ▀▀▀▀▀▀▀▀       ▀▀▀▀  ▀▀▀      ▀▀▀▀▀▀▀▀


██
███
███
███ ██
███ ██
███ ██
███ ██
███ ██
███ ██
 ██ 
  █

.......Whitepaper.......
.
██████████████████████████████████████████████████████████████████████████████████████████████
.
FacebookTwitterBitcointalk
jjiimm_64
Legendary
*
Offline Offline

Activity: 1862


View Profile
March 01, 2014, 05:00:10 PM
 #484



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!!

1jimbitm6hAKTjKX4qurCNQubbnk2YsFw
mindtrip
Legendary
*
Offline Offline

Activity: 1061



View Profile WWW
March 01, 2014, 05:02:13 PM
 #485

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
Hero Member
*****
Offline Offline

Activity: 490


Best IoT Platform Based on Blockchain


View Profile
March 01, 2014, 05:06:03 PM
 #486



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?


     
     ██
    ███
  █ ███
 ██ ███
 ██ ███
 ██ ███
 ██ ███
 ██ ███
 ██ ███
 █  ██
   



         ▄▄▄██████████▄▄▄
      ▄████████████████████▄
    ▄████████████████████████▄
   █████▀▀▀▀▀▀███████▀▀▀▀▀▀████
  ██████      ███████      █████
 █████████▌   ███████   █████████
▐█████████▌   ███████   █████████▌
████████                   ███████
▐███████▄▄▄   ▄▄▄▄▄▄▄   ▄▄▄██████▌
 ██████████   ███████   █████████
  ██████▀▀▀   ███████   ▀▀▀█████
   █████      ███████      ████
    ▀████████████████████████▀
      ▀████████████████████▀
         ▀▀▀██████████▀▀▀


 
 ▄▄         ▄▄             ▄▄
▐██▌       ▐██▌           ███▌
▐██▌       ▐██▌     ▄▄▄▄▄▄███▌      ▄▄▄▄▄▄▄▄▄     ▄▄▄▄▄▄▄▄▄
▐██▌       ▐██▌   ▄██████████▌   ▄███████████   ▄██████████
▐█████████████▌  ███▀     ▐██▌  ▐███▀     ███  ▐███▀
▐██▌       ▐██▌ ▐██▌      ▐██▌  ███▌      ███  ███▌
▐██▌       ▐██▌  ███▄     ▐██▌  ▐███▄     ███  ▐███▄
▐██▌       ▐██▌   ▀██████████▌   ▀██████  ███   ▀██████████
▀▀         ▀▀       ▀▀▀▀▀▀▀▀       ▀▀▀▀  ▀▀▀      ▀▀▀▀▀▀▀▀


██
███
███
███ ██
███ ██
███ ██
███ ██
███ ██
███ ██
 ██ 
  █

.......Whitepaper.......
.
██████████████████████████████████████████████████████████████████████████████████████████████
.
FacebookTwitterBitcointalk
jedimstr
Hero Member
*****
Offline Offline

Activity: 784



View Profile
March 01, 2014, 05:07:34 PM
 #487



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
Newbie
*
Offline Offline

Activity: 24


View Profile
March 01, 2014, 06:09:24 PM
 #488

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
Hero Member
*****
Offline Offline

Activity: 546

I got Satoshi's avatar!


View Profile
March 01, 2014, 09:52:07 PM
 #489

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 Smiley

Thanks again for sharing!

Decentralize EVERYTHING!
tss
Hero Member
*****
Offline Offline

Activity: 742


View Profile
March 02, 2014, 07:58:16 AM
 #490

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

Activity: 1862


View Profile
March 02, 2014, 02:01:48 PM
 #491


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 Smiley

Thanks again for sharing!


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

1jimbitm6hAKTjKX4qurCNQubbnk2YsFw
freebit13
Hero Member
*****
Offline Offline

Activity: 546

I got Satoshi's avatar!


View Profile
March 02, 2014, 02:54:33 PM
 #492

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 Smiley

Thanks again for sharing!

for #2 you should edit the file /etc/config/asic-freq
Yup, thanks, it was kinda implied by no.1 Wink

Decentralize EVERYTHING!
Cheeseater
Sr. Member
****
Offline Offline

Activity: 351


View Profile
March 03, 2014, 10:56:04 PM
 #493



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
Hero Member
*****
Offline Offline

Activity: 784



View Profile
March 04, 2014, 01:50:08 AM
 #494



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
Legendary
*
Offline Offline

Activity: 1061



View Profile WWW
March 04, 2014, 03:57:49 AM
 #495



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
Newbie
*
Offline Offline

Activity: 1


View Profile
March 05, 2014, 10:03:23 PM
 #496



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
Sr. Member
****
Offline Offline

Activity: 351


View Profile
March 06, 2014, 02:21:55 AM
 #497



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
Member
**
Offline Offline

Activity: 83


View Profile
March 07, 2014, 08:00:21 PM
 #498



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
Hero Member
*****
Offline Offline

Activity: 784



View Profile
March 07, 2014, 08:24:30 PM
 #499



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
Hero Member
*****
Offline Offline

Activity: 742



View Profile
March 07, 2014, 11:00:57 PM
 #500



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

Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 [25] 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!