Bitcoin Forum

I have been intrigued as to how far the S3 can be pushed and have been doing some tests over the last few days, running each chip_freq setting for approximately a day to get a more representative average result for that specific frequency.
I did this with a batch 6 S3 powered by a Dell PS-2521-1D server PSU rated at 550 watts connected via 2 PCIe connectors.

I carried out the testing over 5 days on 5 different sppeds starting with the stock speed of 218.75, and here's a summary of the settings and results.

chip_freq	| freq_value |	timeout |	GH/s(avg) |	HW Errors
218.75	1106	18	440	147
225	0882	18	452	117
250	0982	16	503	138
256.25	1406	15	516	155
262.5	0a02	15	529	200

I am not sure of the formula used to calculate the error percentage for the S3, however from the image below, you can work it out since I have all the values in there.

http://s26.postimg.org/o6gj66itl/upto262_5.png

I was amazed how well the temperatures were kept down by the S3 compared to the S1. Of note though, is that I keep my rigs outside the house, covered to protect them from the elements but very well ventilated.

A note about the PSU: The Dell PS-2521-1D has three 12V rails each pumping out approximately 15A on a 200-240V line. Even more interesting is that the PSU cost a mere GBP 10.00 from ebay!

I am not sure whether I can push the PSU any further as I do not have an anmeter hooked up to show the power being gobbled by the S3 at the higher clock speeds, however, from my initial tests, it seems the S3 can be pushed further without much ado. Anyone managed to clock higher?

UPDATE: - upgrade to cgminer 4.6 - 13th Sep 2014

I updated the overclocked S3 to the latest cgminer version 4.6 and below is the screen-shot after running for a day.
Note:
1. I am not sure what to attribute the drop in hashrate to, but its dropped from  an average of 529 to 514 (approx 15 GH/s over a day).
2. Hardware errors have also gone up by 50%+, though the percentage is still low generally. I would not have minded this number going up if the hash-rate was maintained or bettered.
3. The unit's GUI is very clearly more responsive (though you can not see that here), but the value of discarded shares has shot up again (did I mention I reduced the queue to 10 from the stock 4096?). I know that number is not useful, but the slight increase in temperature and the fan speed indicate to me the unit is working harder than before. Infact, I can attest to it as I hear the fans ramping up (they have a distict sound over the other fans I use on other units).

http://s26.postimg.org/50sp5lyyx/S3_262_5_with4_6.png

All in all, I am seriously wondering whether this upgrade is worth it on a performance level. It is well documented that 4.6 plugs some security flaws that are open in the stock version, but I am wondering whether it is worth the "pain" of losing 15 GH/s over a day's hashing.

-------- DEPRECATED! ---------- version 4.6 is no longer available Oct 2014, use 4.6.1 below
To upgrade to cgminer 4.6 follow this process.
1. SSH into the S3 and login
2. Issue the following commands sequentially.
  a) cd /usr/bin
  b) mv cgminer cgminer.bak
  c) wget http://ck.kolivas.org/apps/cgminer/antminer/s3/4.6.0-140908/cgminer
  d) chmod +x cgminer
  e) reboot

To revert back to the stock cgminer (assuming you followed the above process):
1. SSH into the S3 and login
2. Issue the following commands sequentially.
  a) cd /usr/bin
  b) mv cgminer cgminer.4_6
  c) mv cgminer.bak cgminer
  d) reboot

------ END DEPRECATED! ------

UPDATE: - upgrade to cgminer 4.6.1 - 10th Oct 2014

A further update to cgminer, aka version 4.6.1, was posted by ckolivas (https://bitcointalk.org/index.php?topic=671189.msg9134744#msg9134744) and being the ever inquisitive type I decided to install it on one of my S3+'s.

But first, an update to the previous version 4.6.0 which I had installed then removed due to the "apparent" drop in hashing speed. In the interim, I obtained a couple of S1 upgrade kits from bitmain (when they were still available) and upgraded a few of my S1's. The process required me to flash the now upgraded S1's with the S3+ firmware which I did, and I additionally installed cgminer 4.6.0 onto them. When I ran the upgrades, they were hashing marginally faster than my factory S3's and so I decided to upgrade the firmware on my S3's to the latest one AND install cgminer 4.6.0 and to my delight, the previously observed speed drop was no where!

Moving on, when the new update to cgminer was published, I installed it on both my upgraded (now) S3's and the factory S3's. In the announcement post, ckolivas mentions that version 4.6.1 does improve hashing speed to begin with, but overall it does not improve / increase the hashing speed. My observations are:
1. Hashing is more stable and gets up to speed quicker.
2. I have been hashing on slush which sets diff dynamically, and with version 4.6.1 my diff is set accurately quicker and remains stable for longer. Of course, I have only had this running for a few days.
3. On my machines, they are hashing marginally faster (and higher) than I have seen them before! So, I am happy to contradict the software author's opinion here.

Finally, to install cgminer version 4.6.1, the process is the same as before with only the file changing, i.e

Issue the following commands sequentially.
  a) cd /usr/bin
  b) mv cgminer cgminer.bak
  c) wget http://ck.kolivas.org/apps/cgminer/antminer/s3/4.6.1-141020/cgminer
  d) chmod +x cgminer
  e) reboot

EDIT: cgminer 4.6.1-141009 now deprecated  and un-available- http://ck.kolivas.org/apps/cgminer/antminer/s3/4.6.1-141009/cgminer

I'd recomend ensuring the S3 as the latest firmware if you want to install over the stock cgminer, however, it will run without the firmware update too.

UPDATE: - Adding frequencies to the latest firmware 21st Oct 2014

The stock firmware for the S3+ contains frequencies up to 250M, and should you want to overclock over that, you'll need to manually add the frequency. A guide for that can be found in the thread linked via: https://bitcointalk.org/index.php?topic=699064.msg8370071#msg8370071 (https://bitcointalk.org/index.php?topic=699064.msg8370071#msg8370071)

UPDATE: - New S3+ Firmware released by bitmain 25th October 2014

Bitmain released a new firmware for the S3+ that now includes version 4.6.1 of cgminer. Unfortunately the firmware, at the time of writing this, contains an error which makes it impossible to update the miner configuration. There is a fix for this:

1. Download and flash firmware from: https://bitmaintech.com/support.htm?pid=007201407180243004432lBQW28O0633
2. When the rig reboots, SSH into the S3 and login (remember if you chose not to keep settings while flashing, it will pop up on the default IP of 192.168.1.99 rather than its previous IP).
3. Enter this and press enter: sed -i 's/Save\&Apply/Save\&Apply/g' /usr/lib/lua/luci/model/cbi/cgminer/cgminer.lua

You can now browse to the miner configuration page and apply any changes. Also remember to change your network back to DHCP client as the firmware resets it to Static.


If this has been useful and you'd like to donate some BTC, please send to: 1AwgqD7A2KuQ4WT4273JXZPUf29BAbdp2
or point you rig for your chosen amount of minutes (or days ! ;) ) to: stratum+tcp://stratum.bitcoin.cz:3333 with the user pekatete and password x


UPDATE: 20th December 2014 - Freq 275 voltage setting 0815, timeout 14 overclock

Since the release of the firmware that allowed to set voltage, I have found another sweet spot for the S3+ at a frequency of 275. I had to reduce the timeout from that suggested in some posts on this forum to be able to get a reasonable HW error rate. I ended up with the following setting in the respective file: pb:value("14:275:0a82", translate("275M")) which translates into timeout: 14, frequency: 275, register value: 0a82. The voltage setting I used is: 0815 (see also the voltage OC thread I posted here: https://bitcointalk.org/index.php?topic=883197)

http://s7.postimg.org/4ko9o5wvv/S3_275.png

And after approx 24 hrs ....

http://s27.postimg.org/qf3ykc4gz/S3_275_24hr.png

And the poolside after approx 24 hrs ....

http://s18.postimg.org/8yx96xvu1/S3_275_24_poolside.png

nice freqs pekatete.

i tried 218.75 with 441gh/s avg and 0 HW ; 237.5 with 477gh/s avg amd 0 HW. When i tried 250 freq , i got allot off HW errors, about 200 in 5 mins. I modified back to 237.5 and rebooted.
Can somebody tell me why i got so manny HW errors?


Thanks
   

How are you powering your S3, i.e what is your PSU's power rating and how are you connecting it to the S3? Note that though I used just 2 PCIe connections for my test, I was using a server PSU that has 3 12V rails each pumping out at least 15A, so for my case, each +ve line in each PCIe plug can deliver 12V @ 7.5 Amps.

I use http://www.thermaltake.com/products-model.aspx?id=C_00001966 . I inserted all 4 connectors to my S3 . Do you think that my PSU is the problem ?
What do you recomand ?

That looks like its capable of running 2 slightly underclocked S3's, so should not be an issue running one. However, I do not know enough about how these desktop PSU's pump out their power. I'd suggest you use all 4 PCIe connection if you have not been doing so. If you still get such high errors, then it may be just a case of your unit not being able to overclock well.

yes, as i mentioned before ( i edited  my prev post ) i allready use all 4 conectors. Tomorow i will try with another s3 . Thank you for your help.
Cand you recomand me a server PSU that you think is best ?

Thanks

Your PSU seems fine, though since I do not know how it sends out its power, I can not be totally sure. If you want to go down the server PSU end, look at the one I used as stated in the first post. Bear in mind that you'll have to "make" the cables for it and will have to do some soldering (not plug and play as the one you have!).

What kind of concern do you have for damaging the unit? I believe I have batch 5 units, can I expect similar results?

I did not have any concern about damaging the unit, rather damaging the PSU. As mentioned, it is a 550 watt psu and since I could not measure the "wall" wattage at the overclocked speeds, I was worried I may be stretching the PSU beyond its reasonable capacity. Mind you, I have been running my S3 at the higher clock speed since and still hashing away without much ceremony!

what firmwere do you use in the s3

The original firmware (i.e without the advanced tab settings). I have never had any issues with the unit so I did not think it wise to update the firmware. I am waiting on an "opensource" cgminer for the S3 if ever that pops up and may try that out, other than that, IF IT AIN'T BROKE, DON'T FIX IT!
I think units from batch 6 upwards are quite solid for overclocking, though some earlier batches could also be.

you're in luck cgminer 4.6.0 built for ANTMINERS

https://bitcointalk.org/index.php?topic=671189.msg8722578#msg8722578

Thanks for the heads-up. I'll download onto my overclocked S3 and report back here (and there!).

UPDATE:
Got the latest cgminer installed on the overclocked S3 and it is hashing away nicely. Will update after its been running for a while.
To get it, I did this:
1. SSH into the S3 and login
2. Issue the following commands sequentially.
  a) cd /usr/bin
  b) mv cgminer cgminer.bak
  c) wget http://ck.kolivas.org/apps/cgminer/antminer/s3/4.6.0-140908/cgminer
  d) chmod +x cgminer
  e) reboot

In south east europe currently my S3 temps are 47-49c so no attempt for overclocking until
winter comes...good to see the freqs 

i will try 275mhz with the new cgminer
can help with the values because i only have 250mhz mhz max
now they are working fine at 250mhz, its bach1 with last firmwere and 4.6.0 cgminer

I upgraded the S3 with the latest cgminer 4.6 and have added the test results over a day to the OP.

Nice overclocks would be nice to get bfgminer support in these miners as cgminer just hogs everything.

Agreed, there is a duopoly of sorts with the cg/bfg miner mining software. Antminer (S1 / S2 / S3 / S3+ / series?) are on the TODO list for bfgminer, and that would be a good thing seeing (if we are to believe what we read!) a large percentage of the mining is done by Antminers. And who knows, we might even see hashing speed (and revenue) improvements if at all there still exists room for that with the astronomical difficulty increases of late.

HI PEKATETE

COULD YOU EXPLAIN TO US DETAILS ABOUT

chip_freq
| freq_value |   timeout |   GH/s(avg) |   HW Errors

WHAT DOES MEANS ?

COULD YOU TELL US HOW TO MANAGE THE ANTMINER INTERFACE?

COULD YOU TELL US THE MEANING OF EACH ONE PARAMETER?

THANKS!

1. chip_freq | freq_value | timeout -  these are the settings I applied to the asic-freq file (the unit is STILL running the stock S3 batch 6 firmware so no advanced tab!)
2. GH/s(avg) | HW Errors - these are the results I get having run the rig for at least a day (as per the image(s)).

I am not sure I can throw any authoritative light on how to manage the interface, as there is really nothing to manage as far as I can tell. But if you have a specific question / query, I'll offer my opinion.

Winter is coming! Russian winter.

Updated OP with upgrade to cgminer 4.6.1 (and 4.6.0 with firmware update).

Which firmware did you use with cgminer 4.6.1?
Was it this one - antMiner_S320140826.bin which it says supports S3+?  Is it ok for original S3s as well?

Yes, the latest firmware (for the S3+) will work with an original S3. My S3's are batch 6, which was before the S3+.
Note that after updating the firmware, you will have to re-install 4.6.1 as the firmware still ships with the bitmain cgminer (I think version 3 ..?)

Many thanks. I'll give it a go. :)

I hope you know the nuasances of updating antminer firmware! Here's a recap that gets a few people.
When you update the firmware, it will re-set the IP to the default one (can't recall, is it 192.168.1.99 ??) and set the network to static IP. So if you have any rigs on that IP, change them before you start.
Also since you'll be updating from a different IP, the UI will keep showing and reporting that it is still updating (in fact it may have already finished!). Thus after a minute or two after initiating the firmware update, open a new browser window and point it to 192.168.1.99
The first thing you should do after updating and loging in is to change the network back to DHCP client, then you'll be able to download cgminer, else you may (will) get a wget error.

Many thanks! I updated the firmware and then installed 4.6.1. The process seemed to go ok, but could you remind me how I check that the new cgminer is properly installed?  I only say that because if I look at the  system -> software tab, it says cgminer version is 3.12.0-1.  Possibly this screen doesn't get updated by loading 4.6.1, but thought I'd better check! :)

The UI will still say version 3.12.0 though I cannot recall how to return the correct version after you have updated. I vaguely recall you have to check via the SSH command line by issuing a call to the API (check the S3 Support thread, it is mentioned there).

Yes, you were right. 
From the S3 support thread, you use: /usr/bin/cgminer-api
Along with a lot of other stuff, this reports that I do have version 4.6.1.
Cheers.

My initial impressions with the new firmware and 4.6.1 is that the hash rate is very erratic, e.g. set on standard frequency of 218.75, it's varying between about 327 and 500, average so far 438, but gradually reducing.  I'll give it some time to settle.

Are you powering your rig properly and is your HW rate "normal"? I'd not worry too much about the 5s rate, as it can shoot all the way up to (in my case) 650, the key one is the avg rate. 438 seems low, but it "should" pick up in time (mine usually take 45mins to an hour to reach their peak avg).
PS. Also, what is your ambient? Do your temps look OK?

This S3 is one of two powered by an EVGA1000G. It's current average is 440 (I rebooted it 2.5 hours ago as it was drifting downwards quite badly), running at stock speed.  HW is 2.  Ambient is 27 degC - I close the windows at dusk, before that it was 24.  Temps currently 45 (was 43 with windows open).  Increasing frequency to just 225 immediately causes an 'x' in one of the asics.  I will try running the S3 on its own PSU tomorrow to test the power aspect.  Cheers.

It may indeed be the powering but that PSU should be very confortable running 2 S3's at stock (even overclocked within reason!).
That you get an x when you clock to 225 is rather telling though. If this is one of the very early S3's, did you get a chance to re-apply the heat paste?
I mention this because with one of my upgraded S3's (from S1), I used heat-pads rather than paste on the chips, and intitally some of the pads moved slightly from the chips when I was adding the heatsink; that unit kept "throwing up" and x now and again, and after updating to 4.6.1 it became a "main-stay". I decided to check the rig, unscrewed the heatsink and discovered what I mentioned above, aka the slipped heat-pads. I put them in place and added a bit of paste to the back and the x is now history (well, its only been a few days, but it has not appeared again ..... yet).
So it may be the case that if you have an early S3 (which were notorious for too much paste or non at all!) AND the unit was hashing OK before applying 4.6.1 then it is worth investigating that, otherwise I'd say 4.6.1 does not suit that unit.

Yes, it is one of the early units and when received, thermal paste was splashed all over the asic connectors. After cleaning, I first tried Artic Silver, which I use when o/c CPUs. This gave me the lowest temps I have seen with this S3, but after scare stories on the S3 o/c thread about Arctic Silver being electrically conductive, I removed it and applied Prolimatech, which increased temps by 1 degC compared to Arctic Silver.  I wasn't impressed by that, so bought some Zalman paste to try, which comes in a little bottle with a brush - easiest to apply by a mile, but quite expensive.  This gave the same temps as the Prolimatech.  TBH, I wish I hadn't removed the Arctic Silver now, although it's horrible to apply as it tends to trail as you lift off the applicator, so massive care is needed. 
Anyway, to try to get rid of the 'x', I redid all of the paste this morning, using the Zalman, as it's the quickest.  Unfortunately, the first time I ran at 225 again, the 'x' showed up in chain 1.  Had to reboot to get rid of it and reset to 218.  Just out of interest, I then tried it at 231.25.  After about 30 minutes, I got an 'x' again, but in chain 2 this time!  The chain 1 'x' has not re-appeared after 1.5 hours at 231.25.  Is there any risk, do you think, running with an 'x', because it seems to run very well at 231.25 apart from that?  Oh, BTW, I'm also running the S3 on its own Enermax PSU now, although as you suspected, I don't think that's the problem.

In my experience (and use), when / if the pool-side speed is within or above the expected, I tend to ignore the x. I actually have an S3 (though overclocked to 262.5) that from time to time gives the a couple of x's on the first chain and on other occassions one x on the second chain. My solution ...? I added a line to the scheduled tasks to reboot after every 8 hrs (that was after observation of the pattern of the x's appearing!).


My point exactly above (with regard to the x disappearing after reboot). Bummer that you had to re-do the paste, but since the S3 units to some extent are unique, that seems the only way you can get a solution for any individual unit / batch. Still, if all fails for now (and I were in your position), my last throw of the dice would be the blue wire hack, aka both fans at full pelt!

PS. If you get the chance to re-do your rig and detach the board from the big heatsink, could you clean the area in the middle behind the heat sensor chip? As in remove all and any paste that may be there (that will mean (I hope) the sensor will detect higher temps and thus run the fans faster).
EDIT: - aka in lieu of the blue wire hack!

Many thanks.  I'll try your suggestion about the big heatsink next.  My present hashrate is 454 but falling very slowly.  Better than before anyway.  As you suggest, best to keep the blue wire hack as the last resort!
It's amazing how Slush always finds a block when I have a machine offline!
 

If it is better than before, then you are making some headway. The falling hash-rate, like I always want to think, may just be a more difficult (no proof of this, just my thinking) block we are on so you are better off getting the picture / speed after at least 24hrs.


I am glad that you have taken over that mantle! Slush always seemed to do this to me, though of late, not so much ..... but now I know why, YOU!

LOL. Now if I can just get my machines to turn into block magnets when they're actually turned on!  ;D

Hey so I have a couple questions.

1. How do I know what firmware version I have? Under firmware version in the miner GUI is: Tue Aug 26 10:43:10 CST 2014

2. I have been running at 250M for 24 hours now and my temps are 40 and 43 and I have no "x"s. I'd like to overclock it to 262.5 like you've shown. How do I do this as you told me the other day in a different thread that the only way to overclock on the S3+ firmware is to use the advanced tab under miner configuration, but as I'm sure you know, it only supports a max of 250. Do I have to change firmware?

Thank you

1. Looks like you have the latest firmware (going by the date). When you check the bitmain site for firmware, the latest S3+ firmware is antMiner_S320140826.bin, and as you can decipher from the filename, thats your date! Also, the latest firmware has the dropdown frequency selection, whereas the former one does not.

2. To add the 262.5 frequency to the dropdown, you need to edit (via SSH) a different file ..... can't recall off my head which it is, but search through the S3 support thread, it is mentioned there. And no, you do not have to update your firmware.

Thank you.

https://bitcointalk.org/index.php?topic=699064.msg8370071#msg8370071

That's the instructions just in case anyone else has the same question. Took me a while to find.

Now for some more probably already answered questions.

Do I have the firmware you mentioned in the beginning of this thread called cgminer 4.6.1?

Has anyone made a table of power usage at different frequencies?

Yep, that is the post.
cgminer 4.6.1 does NOT come with the firmware so you'll need to follow the instructions to install it.
There are tables of power usage at different frequencies floating around, but again the best reference is the S3 thread.

PS. I'll add the info in the link about adding frequecies to the dropdown to the OP at a later time.

Alright. One final question before I go to bed. I've been messing with overclocking my miner all day, and I've found that running it at 250M delivers expected results. It runs at an average of 505 Ghash/s with low temps and low hardware errors. As soon as I kick it up to 256.25M, my temps stay down and it shows all 'o's for the status, but I get tons of hardware errors and low hash rates. I''m getting half as many hardware errors as accepted shares and about 480 Ghash/s. Why is this?
By the way, thanks for helping out this noob so much. It's much appreciated.

I have days when I notice the HW numbers spike to astronomical figures on the OC'd S3's, but a reboot via SSH always "settles" the unit down. Having said that, it may be one of several things, and I could be wrong but I'll offer a few:
1. You are not powering your S3 properly (I used only 2 connectors, but made sure the cables can adequately juice the unit)
2. If it is an earlier S3, you may need to re-apply the paste (bitmain did a very amateur job!) to enable your unit handle higher temps better.
3. Your unit's freq sweet spot is 250M (some units are less others more ... luck of the draw!).
On a personal level, if it hashes at 505GH/s with acceptable HW errors, I'd be over the moon.

FYI the link for cgminer is no longer valid.

wget http://ck.kolivas.org/apps/cgminer/antminer/s3/4.6.1-141020/cgminer will get you there

Thanks for mentioning that the link to 4.6.0 is no longer available (and I will add a note to that), however, just below that link in the OP is the link to cgminer 4.6.1 (including the similar process of installing it).

doh!  *grabs more coffee*  sorry.

^^ No worries.
Updated OP with link to adding frequencies to latest firmaware (Aug 2014) and highlighting the deprecation of cgminer 4.6.0

Looks like CK changed the file again, it should be:
wget http://ck.kolivas.org/apps/cgminer/antminer/s3/4.6.1-141020/cgminer

ah so I wasn't crazy!  Whew!

Just saw you already posted that link. Was not paying attention.

Updated OP, though both versions are still available unlike version 4.6.0 flat.

Even with the new cgminer file, my units are doing a little worse than with the previous one. I am guessing I am losing around 10-14 GH/s per device, which is not bad but when you have 11 of them it makes a slight difference.

Do you have the latest firmware on them? i had exactly the same experience with my batch 6 units and reverted to the stock cgminer, however (again as is documented in this thread), when I updated to the latest firmware, which I had to do when upgrading my S1's, I get the same result as the stock, or slightly better, but with the security flaws plugged.

Yeah I have the latest firmware, it is dated 8/26/2014. My issue is probably the 5 batch 1 miners I have, even though some of my batch 5 units are a little slow as well.

Yep, the earlier batches do not seem to be up to it. I suspect it is due to their poor temp handling and suggested to someone to re-do their heat paste; Though he had some good results using a conductive compound, he re-applied using a non conductive paste and has not reported their results. With several units .... that would be a day's work! Worth it? Not sure.

I replaced all the thermal paste on 1 of my batch 1 units and that fixed all of the X's and other issues. Not really worth it to start taking apart the rest.

Is upgrading to the latest CGminer for later batches of S3, including S3+ and upgraded S1's recommended?

Running the latest firmware, I upgraded all of the miners to CGMiner 4.6.1 and hashing restarts every few minutes. Overclocking is minimal - 237.5 to 243.75 with temps between 39 and 41 degrees.  The miner itself doesn't restart, only the hashing.

I had to revert back to the CGMiner included with the firmware and they hash continuously without trouble.

I have not experienced the restarts that have been reported in several threads after upgrading to the earlier version of cgminer 4.6.1
Could you try and get the exact version of cgminer that restarts? If you look at the OP, there are two versions of 4.6.1

Okay well I have upgraded the cgminer on my S3's and will be working on upgrading my S1s to 4.2.0 while I wait for the S3's to settle down to decide if I want to try and push the freq.  

CGMiner 4.6.1-141020 is what I used.

I have not experienced this yet and I upgraded to http://ck.kolivas.org/apps/cgminer/antminer/s3/4.6.1-141020/cgminer

If you care to try (and it is worth your while), could you upgrade to 4.6.1-141009 (link in OP) which is what I used and do not get any unexpected restarts? Also, what batch of S3+'s is that?

That version is no longer available on the website.  S3+ Batch 8. I tried it on S3 Batch 5's as well. All of them exhibit the same issue.

Would using the latest (version 4.7) binary work on an S3 or does it need to be specifically compiled for the S3?

I am not sure whether version 4.7 would work, but i see no reason why not if you can get it onto the S3. Basically, the one targeted for the S3 is simply stripped down to only include drivers for the S3, whereas the general release one contains drivers for multiple rigs (thus it should be bigger!).

I cannot seem to find the minor version of cgminer installed on my rigs (simply 4.6.1 via cgminer-api), but yes you are right, the older cgminer has now been pulled down (which was not the case a couple of hours ago!). I suggest the next logical thing to do is to ask on the cgminer thread.

Either way, I don't want this cgminer version issue to take away from the immense help this post as been in ensuring my little mining Op is running as efficiently as possible.  So...thanks!!!

 :-* :-*

Just got back from Best Buy and checked my miners again and it looks like we are doing much better.  Most are cruising above 500 GH/s and very low HW issues.  Also heat is hovering in the low to mid 40's c.  Thanks again Pekatete!

BTW my miners are batch 8 and 9 (two each) on the http://ck.kolivas.org/apps/cgminer/antminer/s3/4.6.1-141020/cgminer
 update.

^^^ very well and you are welcome.
hopefully, you get to mine an entire block ... all on your own!

Haha I gave up on that long ago.  Actually I did point my miners at bitsolo.net over the weekend while I was building my P2Pool server.  But now I have my own P2Pool server that I am running.  Mining a block is enticing...and I may devote my S1's to the task once I retire them, but I am trying to get a few more hashes out of them first...

I'd not give up on it if I were you, it is just a matter of luck! And seeing you are running your own P2Pool node (and I am assuming on a Linux box), it will be trivial for you to setup a ckpool with a ckproxy (to point your S1's to) and run your solo efforts from there too whenever you choose (rather than some-one else's pool). Just a thought ....

Oh, hello devil on my shoulder.  I was wondering where you have been hiding lately...

Hi m8, not sure if it's me you're thinking of above, but I did have my best results with Arctic Silver conductive paste and my latest application of Zalman paste was a lot of effort for not much reward.  I've just bought some Innovation Cooling IC Diamond 7-Carat thermal compound, so will give that a whirl when I have a chance.  Still deliberating about doing the big central heatsinks - presumably this involves removing the blades?  Is that a straightforward process?  I get funny results with my asics at different frequencies: one 'x' always shows up at 225, but not at higher frequencies and similarly with some of the others, so although I always get an 'x' at higher frequencies somewhere, it's often in different places.  Also, my hashrate is rubbish at higher freqs anyway now, it only goes quicker at 231 and that doesn't seem to last long.  I tend to keep it at the default 118 now and main task is to stop my hashrate dwindling away, which gradually seems to happen on my problem s3.
BTW, I've upgraded to ck's latest cgminer (4.6.1-141020) and seems ok so far - no restarts, etc.  I also removed --queue 4096 and added --lowmem in the cgminer startup script, as recommended by ck.
 

Yes moss, that was a reference to you, and thanks for updating us. Bummer about having to run at stock freqs ...
Removing board from the heatsink does not involve much more than removing the top heatsink, just another set of screws then you slide it off (you do not have to unscrew the heatsinks from the braces).
I have not tried adding the --lowmem switch yet as I do not readily know the process, but will dig around tonite (or tomorow) and try it.
Thanks again for keeping us up to date.

Looks like Bitmain released new firmware with version 4.6.1. I upgraded a couple of miners to that to see if I get better results. I did notice they changed the display on the mining status page slightly in the new version.

You are right! They have had the new firmware up for a while going by the date, i.e 13th October 2014
I'll update one of my S3's and see how well it does ... thanks for the headsup!

The date on the firmware is from last week, but they've only had it up for day or two. I did notice a major problem. The miner configuration page has some HTML errors preventing you from being able to make any changes to that page, including frequency.

I'll report it to Bitmain.

That is the under-statement of the year thus far!
The firmware update is completely un-usable! The configuration page is where you point to your mining pool from, and if the page can not load, you can not change / add any pools and the rig defaults to mining on the shipped pools (bitmain's pools?). Honestly Bitmain, your reputation is going down the drain here!

OK, there is a fix for the error thrown by the new firmware update.
Do this ONLY after you have updated to the firmware of 13th Oct 2014
1. SSH into you S3 and login
2. Enter this: sed -i 's/Save\&Apply/Save\&Apply/g' /usr/lib/lua/luci/model/cbi/cgminer/cgminer.lua
Press enter and all should be OK. You can now enter the miner configuration page.

EDIT: Updated OP with instructions.

Bitmain released a new firmware fixing the issue.

Have anyone damaged a unit by OCing to like 250?

Or is it "safe" to just max them out? (if you don't get high numbers of HW-error)...

It there anything ells that I should look out for while OC to know if i run them to hard?

Best regards, and happy Halloween!

/Badz

So long as you have the unit powered properly (and you do not mind the increase in power consumption), then clock to your pleasure. Of-course when errors start geting out of hand e.g > .99% (with the new firmware you can check the %) then keep going! I have an upgraded S1 to S3 unit that is running at freq 268.5 with ~539 GH/s, however, my S3's won't go beyond 262 without the HW getting "out of hand".
PS. My guide to HW % is just mine, not official and I have not seen anyone recomend it anywhere. Follow at your own risk!

Hi m8.  Another little update...  I tried to do the big heatsinks between the boards, but could not remove one of the screws (as you know, they go through the board itself) whatever I tried - the others were very tight too, but I managed those. In the end, I gave up on that part of the plan. However, the rest of the plan seems to have worked well: I redid the outer heatsinks using Diamond 7-Carat thermal compound and I fitted little heatsinks on the DC-DC converter chips.  Since doing that, the problem S3 has sat solidly at 440 Ghash/s for weeks.  So a big result (so far...).  ;D

Edit:  Hmmm.  My first forced reboot today (19th Nov) of the problem S3 since 'fixing' it.  Average hash was heading south, after being rock solid for weeks.  Didn't see that coming... :(
Edit2: Lost my average hash reading (again), so updated to latest firmware to see if that improved things.  Ran reliably at 440 Ghash/s until 23rd Nov, when it suddenly stopped hashing and started beeping for 5 minutes.  Couldn't find anything wrong via the web interface and it suddenly started working again - back at 440Ghash/s.  Other S3 on same router not affected.  Don't know what caused that... ???

New post overcloking with voltage setting in new firmware: https://bitcointalk.org/index.php?topic=883197.0

I just tried this and after building up to normal speed, the hashrate dropped back down to about 1.3GH/s a few minutes later.  I checked the frequency and it was set as expected.  The hashrate started increasing again, but quite slowly, so I decided to reflash to the previous firmware for now.
Have you tried it yet?

I've just updated the thread with a 24hr comparison of my previous OC @ 262.5 and the HW rate has drastically reduced.
I can pretty much guarrantee that this will work for all BM1382 boards, it just depends on whether you want to do it. First, run it at a frequency within the bitmain spec (the black numbers in the last table) with the voltage set. The rate will take a while to settle and will at the very least match the spec rate (expected hash in the last table), but more likely beat it (as I have demonstrated). More important though, is the lower HW rate (and again, do not jump at conclusions after the first half hour, let it run for a few hours).
If you feel the HW rate is low enough (even not and just feel like it!), turn up the freq within that voltage range (this is mine through my tests not bitmain's) and you should be OK.

For the 262.5 freq test, the voltage setting is 0750, which is the datasheet voltage for freq 250. Start with 250 and I bet you'll get very few HW errors and a good hash speed, then if you feel like it, turn up the freq and watch your hash-speed increase, with still few HW errors.

Thanks pekatete.  Much appreciated.  I'll try it again over the weekend. :)
Cheers.

Updated OP with freq 275 OC with voltage setting.

I continue to find this extremely frustrating.  I am running 6 S3+ units, each supplied by a 750-800W power supply with a single 12V rail and all four PCI-E connectors connected.  I tried the 275/0815 settings, and exactly the same thing happened as the last time.  Hour 1: fantastic, all units over 500 GH/s, holy crap why did I not do this earlier.  Hour 2: OK, but hashrates down both as reported by units and at the pool.  Hour 3: terrible, all hashrates reported by units and by pool way below stock results.  So I have yet again reverted everything to 225/231/243/237/225/237 with voltage left blank.

I do not understand the mechanism here.  If it is heat, why does it take 2 hours to show up?  With the OC settings, all chips show up as "o" and working.  But the hashrate results speak for themselves.  But why the very prominent jump in hashrate for the first hour, but then utter crap out in hour 3?  Can anybody explain this?

Just a few pointers that may help:
1. The voltage setting from the datasheet for the freq of 275 is both 0800 and 0850, so you can try anything within / around that range.
2. Hash rate falling in a few hours is NOT the "end of the day". Overall hash-rate is what matters in the long run (I usually let it run for 12 - 24hrs). If you are not getting X's on chips when the hash-rate is falling, I'd let it run as long as this did NOT coincide with a sustained increase in HW errors.
3. Do not be spooked by a fairly high HW error % at the start, and here I mean if the rate is less than or around 0.01 in the first few minutes to an hour, let it run.

S3 variants are the same but handle differently, so you may have to try different voltage settings (even freq settings). For example, the 262.5 freq does not ship from bitmain, but it turns out to be a sweet spot for most S3 variants!

Which firmware are you using?

I am using the 1024 firmware, the only change on top of that is adding the new frequencies into cgminer.lua.  All six units stable again at the lower frequencies with no voltage setting.

Trying again on one unit, this time with ckolivas's S3 cgminer 4.6.1 build, also deleting --queue and adding --lowmem.  I can't think of anything else to try.  The S3's are in a ventilated space, so the ambient temperature over the three hour period is constant.  Why would I get great results for 1+ hours, but poor results over 3 hours?

Trying again on one unit, this time with ckolivas's S3 cgminer 4.6.1 build, also deleting --queue and adding --lowmem.  I can't think of anything else to try.  The S3's are in a ventilated space, so the ambient temperature over the three hour period is constant.  Why would I get great results for 1+ hours, but poor results over 3 hours?
[/quote]

Possibly easier to simply post a shot of your web UI, but I'll ask just in case:
1. What temps do you have on that rig?
2. What is the HW %
3. What freq are you running at?
4. If you've recently started the rig, could you post the cgminer startup string (usually logged in system log ...?)?
5. Finally, could you also post the freq setting line that you are running from the cgminer.lua file?

Possibly easier to simply post a shot of your web UI, but I'll ask just in case:
1. What temps do you have on that rig?
Right now showing 43 & 42 25 minutes in (and reporting 538 GH/s avg), it don't think it got above 44 the last time I tried it.  Ambient temp in the room 18C.

2. What is the HW %
0 (zero).  Last try it got a an occasional HW error, but they were minor.  One of the six units got a bogged down in HW errors, but then performed well when I dropped the frequency to 268.

3. What freq are you running at?
275/0815 target, last night's test I ran five that way, then the one I dropped to 268/0815.

4. If you've recently started the rig, could you post the cgminer startup string (usually logged in system log ...?)?
From the process tab:
cgminer --bitmain-options 115200:32:8:14:275:0a82 -o stratum+tcp://us1.ghash.io:3333 -O USER.WORKER:Any -o stratum+tcp://stratum.mining.eligius.st:3334 -O ADDR_WORKER:Any -o stratum+tcp://mint.bitminter.com:3333 -O USER_WORKER:PASS --bitmain-nobeeper --api-listen --api-network --bitmain-checkn2diff --bitmain-hwerror --version-file /usr/bin/compile_time --lowmem

5. Finally, could you also post the freq setting line that you are running from the cgminer.lua file?
pb:value("14:275:0a82", translate("275M"))
[/quote]

Thanks for the help! Answers above in bold.

Did you try 275/0800 before 275/0815?
The datasheet states 2 voltages for that freq, 0800 and 0850. You should try 0800 first and increment if you get LOTS of HW errors or a very low hash-rate. For freq 275, you should have hit at least 550 Gh/s(avg) in the hour IF your HW % is low and no x's showing. EDIT: Saying that, the 538 you are getting with no HW errors is not bad either but I should expect your rig to give at least 550.

PS. I think you'll have to start one machine at a time .... also, I'll address the other bits as and when ...

I remember reading somewhere that it is not a good idea to run without a queue, rather have a reduced one to the 2048 one that ships. I run mine with  --queue 1024, so you could possibly try  --queue 512 if you are averse to having a long one. (I am not conversant with the why's of this, so please don't ask!)

I assume that when your avg hash-rate falls you restart(ed) immediately, so seeing you have no HW errors, could you let it run for at least an hour after that and see whether you get any HW errors and / or x's on the chips?
I also noticed that the 5s hash-rate flactuates whenever a new block is started / a block is about to end, but soon builds up, so that may be something you have to bear in mind (assuming your hash-rate recovers!).

Not this time, just went with 0815.  1 hour in now, showing average 539 GH/s.  You can see the slowdown starting though, average is decreasing, and temps now 42/38.  I am consistently getting 1 hour of improved performance, then the slowdown starts.

Unit hashrate dropping sharply now after the 1 hour run, average down to 533.  HW errors now 3 for 0.0093%.

If hashrate keeps falling, I will report the numbers and try again with 0800.

I'm only going to try this with the one unit, the improvement was so dramatic the last time that when it was solid for an hour, I upgraded all 6.  But I have yet to have an OC last more than 90 minutes or so.

That's fair enough, if it is falling that quickly into its uptime, and now registering errors, I expect you'll soon enough see x's on chips too, and if that happened would explain the consistent hash-rate drop-off very well ...... temp build-up!

EDIT: You'll probably have a better run with the 0800 setting .... but see this out for now to get a definitive result.

Here's where that came from, ckolivas's recommendation when he released the S3 binary I am currently using on the OC unit:

Death spiral on the OC unit definitive now, average down to 523 GH/s.  All chips good with "o", still just the 3 HW errors, temps 42/38.  This would bother me less if I had some explanation for what is happening.

On the queue, I'll take ckolivas' word over what I may recall ...

And yes, that is more like a death spiral, too damn right! I'd have expected it to be flashing x's all over + an increase in HW errors at this point, but then again the new binaries support that --bitmain-hwerror option (or such like) that I have never gotten my head around! I think its that time to try the 0800 setting .... I am convinced it is a heat problem your rigs are encountering due to its consistency in drop-off, so reducing the voltage may help (but may need a power cycle, infact I'd say do one even though I do all my tests initially without one).

OK, I'm going to call it a death spiral now.  98 minutes into the run, 15m hashrate of 375 at the pool, miner reports average dropped to 495.  All chips still "o", temps 41/41, and a total of 5 HW errors.  But I would also expect the symptoms you describe with an overheat, and I'm not seeing them.  No increasing temps, no "x"s on the chips, HW errors still negligible.  Fan speeds are dropping, now 1800-1900, down from 2200-2300.  So the unit is getting cooler as it slows down.  I saw the same behavior on all six units, so we are missing something here.

On the one test unit, I will now try 250/0750, hardware reset then software reset.  Will see what happens!  One thing I am wondering is if we are triggering an internal chip overheat of some kind, that throttles it back but doesn't report a bunch of failures.  So we try to push them harder, and they actually go slower.  But I'm just guessing at this point.

There, my friend, is the sign you are looking for!

Fan speeds dropping ... unit is getting cooler

That means there are some chips that have gone offline! EDIT: Either that, or the chips are not getting work ..... now you see how that the queue argument was formented in my mind?

Its your rig, but I'd try 275/0800 first. Simply enter the voltage, save and apply then do a power cycle.
On pushing them harder if they are going to throttle back without showing any outward sign ..... that is the question.

Does it?  Why are all chips still reporting "o" and not "-" or "x"?  That is why I'm wondering about the internal throttling.  There should be plenty of work, I have tried leaving queue at default as well as deleting queue parameter completely.  I have not tried --queue 1024 yet though.  But I saw the same result with two different pools and with and without deletion of the parameter.

New test run started: 1024 firmware, 250/0750, queue left at stock, cgminer left at stock.  Only change to stock is the additional options in cgminer.lua, which do not change the 250 values.

OK, I need to catch up on my sleep ..... getting to 2am where I am so I'll pick up from where you got to in a several hours' time.

Sorry, missed this post.  I will try 275/0800 after we see what happens with 250/0750.  My procedure lately is to put in freq/volt, save & apply, power cycle, then system/reboot.  I added on the last step after just a power cycle would result in bad stats in Miner Status.  Have you tried OC on an S3+ with factory thermal paste?  The six I am working with are untouched.  So if it is a chip-level thermal problem that is not reported to the sw, then I guess that could explain the difference here.

I used to have that issue (and always had to do an SSH reboot after a power cycle). Of late, though, it seems to have been fixed .... all I did once is before I rebooted via SSH, I first went into the System -> Start Up tab and stopped cgminer, then entered reboot in the SSH window. Now the stats are OK after a brutal power cycle .... (but I was called names when I mentioned the stats problem on this forum!)


I did OC one S3+ before I redid the paste which worked OK at 262.5 (which was the only "good" freq I had at the time). I now redo all the S3's I get by, at the very least, putting heat-pads on the chips, so for now all have been "modded" if you like.

It took longer, but 250/0750 also a dead end.  Over 500 first hour, then down.  After 3h down to 485 average, 458 last hour on the pool.  All "o" on the chips and only 1 HW.  Dropping to 243/0750 for the next run.

It doesn't happen every time, but a significant % of power cycles result in Miner Status using the previous elapsed time, so everything gets pushed lower.  A warm reboot always results in the correct outcome.  This is a funny hobby to have, these things have minds of their own.

243/0750 also a dead end, dropped to 4h running average of 471, with last hour on the pool at 449.  Trying 237/0750.

I also started playing with the slowest of the others (225 for 453, no voltage change).  Trying 250/0750, and so far 2 hours in it is rock solid at the expected 504.  Not going to count those chickens, will see what it looks like tomorrow.

237 was repeated "x" from chips over four reboots, so bailed.  231 was 428 over an hour at the pool, also bailed.  That unit just doesn't want to OC.  Reverted to 225/no-volt.

Other unit, however, continues to hum along at 504 after 5h.  I do not understand these things.

I noticed that repeated x's clear when you restart cgminer e.g via the System Start Up tab (which also happens when you Save & Apply settings) - just saying so you can reduce your restart / reboot cycle length.

Been said a lot of times. S3's are the same, but different ..... most of the S3 variants in my stable run best at different settings, and those with the same settings, on the same pool, over the same connection produce differing results! So there goes.

All three OC experiments failed.  Both of the other units I tried 250/0750 with looked fantastic for the first hour, then slid into slow decline without any symptoms other than declining hashrate.  They bottomed out at about 430 after 12 hours.  Reverting to stock and taking a break!

I am not by any means disputing your results as that would be futile, however if I may point out my experience with S3's, it is very rare that you find any two units hashing the same, even when using similar freq & voltage settings, PSU and connected to the same pool.

In your case however, that you have experienced the same wall of performance after the first hour, and that happening on most of your units, leads me to believe the issue must be local to your setup.

My first instinct was a heat / temperature problem, however, you seem to discount this as a possibility, and that the units run as normal on stock frequencies seems to justify that. I am not completely sold though since I have never run an S3 variant at temps as high as yours. Before the season change and my moving my rigs outside, I had them all running the fans at full pelt, aka blue wire hack, which kept the temps low, and now that the seasons have changed and my rigs reside in the garden, my temps are a lot lower.

My second guess is how you are powering your rigs. Though you appear to have the right PSU's, this may be a cause if you have them all plugged into the same extension lead. They may not trip your circuit, but they will compete for power, especially if you are running them off a 110v circuit.

If you choose to attempt the OC again, I wish you luck, but I think in your instance I have given as much help as I possibly can, bearing in mind I am neither an engineer nor an electrician.

Thanks for trying to help!  I am both an engineer and an electrician.  I do not think I have power issues, as all 6 units are running from Corsair 750 or 800W supplies, with all four PCI-E connectors well seated.  Three power supplies are on one 20A 120V circuit, and three are on another.  So there is plenty of spare power.

I think what is happening is a slow overheating.  Interestingly, the S3s do not appear to respond by increasing the fan speeds, instead the hash rate goes down as we have discussed.  All six units are in a well ventilated space that stays around 18C.  The S3s report temps around 39-42C, so not very high.

If I find the time, I may try redoing the paste and/or maxing the fan speeds to see if that helps.  I will also keep an eye out for any S3 firmware updates that fix something.  For now, I have concluded that my six units are not overclockable other than the slight bump I get from setting the frequencies to 225/231/243/237/225/237 for the six.

Very frustrating to see such promising hashrate increases in the first hour, but then nothing sustainable.  But overall I am impressed with the units, they are all working to spec and running just fine.

Even though this thread is a bit old, i just wanted to stop by and tell you that YOU my friend are a GOD.

i followed your instructions and my s3+ is doing 553gh stable, with very little HW like 0.0002% for 48hours.
tonight i will doing my other 5 units

Happy Hashing to everyone

Still running your S3's Pek?

Yep, still running them ...

OC'ing them?
Or underclocking now?

All still OC'd - I have a few on freq 262 @ 0750 and another lot on freq 281.25 @ 0755 (those seem to be the sweet spots for my rigs).

Solid eh?

We have some S2's still running on Freicoin network. Amazing they just keep going. We had to exchange out the flamed out PSUs we had with them originally though. They didn't last a month. We swapped out and didn't even bother RMA/Replacing via Bitmain just no point.

Someone probably clever (or clever at copying) put them out somewhere, and I put a link to them in the OP somewhere.
Freq 281.25 has a timeout of 14 and  freq_value of 1606 (you can play with the voltage to suit your rig ....)

HW is OK .... go to
250M
0750 volt

if you have a good PSU.

You are good to go .... even 262.5M @0750 volt (if cables are bigger than 16AWG populate all 4 PCI-E ports)

@pakatete i'm trying to change via putty

vim /etc/config/asic-freq

config 'asic-freq' 'default'

        option 'freq_value'    '0a82'  #275M
        option 'chip_freq'     '275'
        option 'timeout'       '14'

        #option 'ereq_value'    '1286'  #237.5M
        #option 'chip_freq'     '237.5'
        #option 'timeout'       '17'

        #option 'freq_value'    '0882'  #225M
        #option 'chip_freq'     '225'
        #option 'timeout'       '18'

        #option 'freq_value'    '1106'  #218.75M
        #option 'chip_freq'     '218.75'
        #option 'timeout'       '18'

        #option 'freq_value'    '1086'  #212.5M
        #option 'chip_freq'     '212.5'
        #option 'timeout'       '18'

250M to 275,,,but in miner configuration menu still 250...how to change it....
many thanks...