BITMAIN Antminer S1 support and OverClocking thread - page 20.

faxfan2002

member

Activity: 83

Merit: 10

Quote from: Swimmer63 on March 09, 2014, 03:00:31 PM

Where do you find the firmware updates?

https://github.com/AntMiner/AntGen1/tree/master/firmware

Swimmer63

legendary

Activity: 1593

Merit: 1004

Where do you find the firmware updates?

faxfan2002

member

Activity: 83

Merit: 10

Quote from: jedimstr on March 07, 2014, 03:24:30 PM

Quote from: faxfan2002 on March 07, 2014, 03:00:21 PM

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?

On the latest firmware, I did an overclock to 375 and I got around ~190, overclocking to 393 this drops to ~185. Very odd, seems to have a sweet spot of 375. Does anyone have a list of the settings for 380, 385 etc??

bestbest

newbie

Activity: 8

Merit: 0

Please help me.

Fri Mar 7 20:26:33 2014 daemon.info sysinit: ntpd: resolved peer 0.openwrt.pool.ntp.org to 203.185.69.60
Fri Mar 7 20:26:33 2014 daemon.info sysinit: ntpd: sent query to 203.185.69.60
Fri Mar 7 20:26:33 2014 daemon.info sysinit: ntpd: reply from 203.185.69.60: reach 0x01 offset -7.486008 delay 15.006532 status 0x24 strat 1 refid 0x50505300 rootdelay 0.000000
Fri Mar 7 20:26:33 2014 daemon.info sysinit: Alarm clock
Fri Mar 7 20:26:33 2014 daemon.info sysinit: ntpd: resolved peer 3.openwrt.pool.ntp.org to 203.158.111.11
Fri Mar 7 20:26:33 2014 daemon.info sysinit: ntpd: sent query to 203.158.111.11
Fri Mar 7 20:26:48 2014 daemon.info sysinit: ntpd: resolved peer 2.openwrt.pool.ntp.org to 203.158.118.2
Fri Mar 7 20:26:48 2014 daemon.info sysinit: ntpd: sent query to 203.158.118.2
Fri Mar 7 20:26:48 2014 daemon.info sysinit: ntpd: resolved peer 1.openwrt.pool.ntp.org to 203.185.69.60
Fri Mar 7 20:26:48 2014 daemon.info sysinit: ntpd: sent query to 203.185.69.60
Fri Mar 7 20:26:48 2014 daemon.info sysinit: ntpd: resolved peer 0.openwrt.pool.ntp.org to 203.158.118.2
Fri Mar 7 20:26:48 2014 daemon.info sysinit: ntpd: sent query to 203.158.118.2
Fri Mar 7 20:26:48 2014 daemon.info sysinit: ntpd: reply from 203.158.111.11: reach 0x01 offset -7.522214 delay 15.078239 status 0x24 strat 2 refid 0xcbb9453c rootdelay 0.004685
Fri Mar 7 20:26:48 2014 daemon.info sysinit: ntpd: reply from 203.158.118.2: reach 0x01 offset -0.003117 delay 0.042517 status 0x24 strat 2 refid 0xcbb9453c rootdelay 0.006317
Fri Mar 7 20:26:48 2014 daemon.info sysinit: ntpd: reply from 203.185.69.60: reach 0x01 offset -0.002515 delay 0.039494 status 0x24 strat 1 refid 0x50505300 rootdelay 0.000000
Fri Mar 7 20:26:48 2014 daemon.info sysinit: Alarm clock
Fri Mar 7 20:26:48 2014 daemon.info sysinit: ntpd: resolved peer 3.openwrt.pool.ntp.org to 203.158.118.2
Fri Mar 7 20:26:48 2014 daemon.info sysinit: ntpd: sent query to 203.158.118.2
Fri Mar 7 20:27:01 2014 cron.info crond[577]: crond: user root: process already running: /usr/bin/cgminer-monitor

I read FAQ . but i don,t understand .

STEP 1 : Modify/etc/init.d/cgminer

cnt=0
if [ ! -f /tmp/cgminer-ntpd-done ]; then
while [ "$NTPD_RET" != "0" ]; do
ntpd -d -n -q -N \
-p 0.openwrt.pool.ntp.org \
-p 1.openwrt.pool.ntp.org \
-p 2.openwrt.pool.ntp.org \
-p 3.openwrt.pool.ntp.org
cnt=$ (($cnt+1))
if [ $cnt -gt 2 ];then
echo cnt
break
fi

NTPD_RET=$?
done

touch /tmp/cgminer-ntpd-done
fi

STEP 2: Disable NTPD client for linux

STEP 3: Re-power antminer

Please explain me step by step.

thankyou so much.

samsonn25

hero member

Activity: 882

Merit: 1003

Quote from: faxfan2002 on March 07, 2014, 03:00:21 PM

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

jedimstr

hero member

Activity: 798

Merit: 1000

Quote from: faxfan2002 on March 07, 2014, 03:00:21 PM

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?

faxfan2002

member

Activity: 83

Merit: 10

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.

Cheeseater

sr. member

Activity: 351

Merit: 250

Quote from: jedimstr on March 03, 2014, 08:50:08 PM

Quote from: Cheeseater on March 03, 2014, 05:56:04 PM

Quote from: jedimstr on March 01, 2014, 12:07:34 PM

Quote from: jjiimm_64 on March 01, 2014, 12:00:10 PM

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.

wise1080

newbie

Activity: 1

Merit: 0

Quote from: mindtrip on March 03, 2014, 10:57:49 PM

Quote from: jedimstr on March 03, 2014, 08:50:08 PM

Quote from: Cheeseater on March 03, 2014, 05:56:04 PM

Quote from: jedimstr on March 01, 2014, 12:07:34 PM

Quote from: jjiimm_64 on March 01, 2014, 12:00:10 PM

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

mindtrip

legendary

Activity: 1167

Merit: 1009

Quote from: jedimstr on March 03, 2014, 08:50:08 PM

Quote from: Cheeseater on March 03, 2014, 05:56:04 PM

Quote from: jedimstr on March 01, 2014, 12:07:34 PM

Quote from: jjiimm_64 on March 01, 2014, 12:00:10 PM

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

jedimstr

hero member

Activity: 798

Merit: 1000

Quote from: Cheeseater on March 03, 2014, 05:56:04 PM

Quote from: jedimstr on March 01, 2014, 12:07:34 PM

Quote from: jjiimm_64 on March 01, 2014, 12:00:10 PM

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'

Cheeseater

sr. member

Activity: 351

Merit: 250

Quote from: jedimstr on March 01, 2014, 12:07:34 PM

Quote from: jjiimm_64 on March 01, 2014, 12:00:10 PM

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

freebit13

hero member

Activity: 616

Merit: 500

I got Satoshi's avatar!

Quote from: jjiimm_64 on March 02, 2014, 09:01:48 AM

Quote from: freebit13 on March 01, 2014, 04:52:07 PM

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 Wink

jjiimm_64

legendary

Activity: 1876

Merit: 1000

Quote from: freebit13 on March 01, 2014, 04:52:07 PM

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

tss

hero member

Activity: 742

Merit: 500

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

freebit13

hero member

Activity: 616

Merit: 500

I got Satoshi's avatar!

mephke

newbie

Activity: 24

Merit: 0

Quote from: jjiimm_64 on March 01, 2014, 11:20:08 AM

Quote from: Darthswan on March 01, 2014, 05:43:18 AM

Quote from: mephke on March 01, 2014, 04:33:24 AM

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 ;-)

jedimstr

hero member

Activity: 798

Merit: 1000

Quote from: jjiimm_64 on March 01, 2014, 12:00:10 PM

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.

Darthswan

hero member

Activity: 818

Merit: 508

Quote from: jjiimm_64 on March 01, 2014, 12:00:10 PM

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?

mindtrip

legendary

Activity: 1167

Merit: 1009

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?

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