I would not be overly concerned about the the efficiency because server PSU's are built to power-up equipement for long periods and therefore they are going to always be more robust than an equivalent power rated desktop PSU. On the other hand, I would also not be surprised that they are Gold rated (or higher) as chadwickx16 suggests.

What would be ideal is that before you buy one, make sure it has the 12V rails adequate to power up whatever rig you need it for at your wall voltage and also ensure you find as much information about the PSU e.g turning it on, turning down the cooling fan ... etc (not hard to do via search engine). In most cases, you'll need to make the leads that power up your rig (or buy them from other miners) too.

Generally it is a LOT cheaper to get and deploy a server PSU than it is to get a boxed desktop PSU, and also a lot easier to get a server PSU working than it looks / seems.

Guys, wake up to server PSU's! they go for a pittance and are more robust than an equivalently rated (wattage wise) boxed PSU. Fifty bucks may sound like a steal until you find out an equivalent 2nd hand server PSU is 15 bucks give or take.
A server PSU's that would adequately power an overclocked S3 (and then some), can take the shape of:

http://store.vibrant.com/Dell-HY104.html?utm_source=amazon&utm_medium=ads&utm_campaign=Dell-HY104

also at fleabay

http://www.ebay.co.uk/itm/Dell-PowerEdge-1950-Power-Supply-HY104-0HY104-Z670P-00-7001080-Y100-PSU-/360931800592?pt=UK_Computing_PowerSupplies_EH&hash=item5409363610

It was just a matter of time before they released their code .... thanks for the headsup!
Sooooo then .... FULL STEAM AHEAD!!!!

Are the controller boards different from the S1 and S3? Visual inspection tells me they are one and the same.

As things stand this is, to an extent, pie in the sky because bitmain REFUSED to release the code for cgminer that they used for the S3. This is important because the code contains the driver for the new chip that is used in the S3.
What is astonishing is that cgminer is opensource and though the author / maintainer of cgminer tried to prevail over bitmain to release the source as per terms of license, last I knew was that bitmain were adamant not to release their code into public domain. I am quietly confident that they will change their stance soon as no organisation can take on the opensource movement and come out of it unscathed.

On a positive note, this can definitely be done with the S1 as the code (and thus driver for the chips) was released and is publicly available. Additionally, the S1 blades are connected by a single flat cable, so in the crudest form, a similar cable but with one end "stacked" with a female / male and the other end being the male would be sufficient to form the chain. Then we need to look at how the mining software uses the driver software to poll / find the chips, and whether we need to make any changes to that.

I am confident that this can be accomplished with an S1 controller board and no need to design a new one.

I can not see any performing at normal hash-rate, maybe I missed something.

First off, if you want advice that can be useful in your fault finding, a screenshot from ghash is NOT as usefule as a screenshot from your miners' Miner Status page, so if I were you, I'd post any number of the screenshots at your convenience.

It could be a power issue, it could be incorrect configuration of the pools or you may have duds on your hands (or a combination of all or none of those but another permutation of faults)!

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.



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



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

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)



And after approx 24 hrs ....



And the poolside after approx 24 hrs ....

LSTime - the time difference from NOW since a share was submited. (should be milliseconds / seconds for the current pool). On the S1, this value shows as the actual clock time.
Discarded - This is the work that has not been worked on. To ensure the miner is never out of work, the mining software gets / generates more work than it can handle in a specific time and queues it. However, once it gets the work, it has to submit the results back within a specific period of time else the work expires, and when this happens, it has to be discarded.

The discarded figure has been a source of contention on these boards with some suggesting it has no effect and others disagreeing. Nevertheless, there is a fix to reduce the number of discarded jobs which you can apply. (My experience was that after applying the fix, there was a minor improvement in the number of stale shares, but that may be dependent on the pool you are mining on).

Did you set up your own P2Pool node or just connected to a public node?
Generally, it can take a while for you to get a share registered, but I do not think there is anything like a minimum time before you see a share. Look on the P2Pool node dashboard you are mining on, and if they provide statistics for the miners connected to that node, double check to see if your address indicates you've been hashing. If so, then it is simply a case of you not having found a share.

Did you remember to power cycle or type reboot in putty? I am not sure if these settings can be picked up simply by restarting cgminer, but you can try that too, else, after changing the values in the asic-freq file, you have to restart the rig.

SSH into the S3 and un-quote to your required frequency. If you are not familiar with this process, read earlier in this thread, it is well explained.
I am not conversant with changing frequencies in the new firmware as I see no need to update mine, they are not broken so why fix anything?

Your PSU will run both S3's confortably at 225. If you want to overclock above that, then you'd ideally put each S3 on a separate PSU that can supply the required power. If I was in your place, I'd be happy to run both off the single 850 or even use the spare one and crank up the speeds on both. Getting another 850 PSU would NOT be on my radar.

On a side note, I run my S3 overclocked to 256.25 (approx 420 watts) at the moment off a 550 watt server PSU and it is running OK for a day now with just 140 HW errors. I am planning on cranking it up to higher speeds since my PSU can pump out approx 440 - 460 watts, so in your case, the 850 for each will be a bit of an overkill.

General rule of thumb: Make sure the power draw exerted on the PSU is within 80% of its rated output. If the PSU is a gold or platinum, I'd stretch that to 85%. This is for both the longevity of the PSU and the ability to efficiently power-up your rig.

In your case, the PSU is rated @ 850 watts * 0.8 = 680 watts
Thus should have each of your S3's setup at speeds that will consume a maximum of 340 watts each.
According to info on this thread, @ chip_freq '225', power draw is approx 346 watts and at chip_freq '237.5', power draw is approx 375 watts.

So now you know why you are getting a high HW error rate. You gain NOTHING from HW errors, but in the medium to long run, you could lose some of your chips.

1. HX 750 should be more than adequate to overclock a single S3 to the maximum speeds in the asic-freq file confortably. i am not conversant with the connections on this particular PSU, but if you have all four populated on the S3 then, on both ends, you should be hitting the advertised speeds. If not, you probably drew the short straw as they are both B6 (of which I have a couple doing as advertised on a 550W psu)!
2. Slush hourly speeds displayed on the My Account page SHOULD be higher than the LUCI speeds (at least one of mine pointed there does) since you have been running for over an hour.

Having said that, I think the unit does not use the full extent of the advertisied wattage at the over-clock speeds if it does not hit them. Small consolation probably (and even smaller decrease in consumption), but thats how the chips fall. though I have to say, for batch 6, at least both miners should be hitting 480Gh/s.

I think this is the trick bitmain missed! Rather than offering an upgrade that amounts to junking the old boards, I'd have been happy with chaining WITH undervolting too!

The S3 takes a while to come to speed, so you have to leave it running at least several hours to a day to get definitive numbers. if that then:
1. What wattage (and efficiency) is your PSU?
2. What batch was this if you know? (the latter batches seem to overclock better)
3. What are the speed you mention here? Are they pool speeds or machine (luci) speeds?
You'll also notice that the hashing speed by the minute / hour is, like you say, all over the place but also bear in mind that the "jobs" being hashed are never the same! Thus, the average hashing spped by both your miner and the pool you are hashing with take a while to settle.

The chip names (numbers) are different and so is their manufacturing process. If you look at the S1, it has 32 chips on each blade (64 chips in total) that deliver a stock speed of 180 Gh/s, whereas the S3 has 16 chips per blade (32 in total) delivering a stock 441 Gh/s. the only similarity is that they are made by the same company.

I am sure if you ventilate the latter batches' S3's properly (as in either cutting the blue wires or replacing the stock fans with un regulated 150+ CFM's), and power it up with a decent PSU, you can easily surpass 600 Gh/s without much ceremony. Another cooling method would be dismounting the blades from their stock vulcan-grip layout, and installing fans blowing on both heatsinks; this coupled with at least a 750 watt PSU (and of-course the correct frequency settings) can get you well into the 650 Gh/s, again, without much ceremony.

PS. untested and do at your own risk!

I am sure you are barking up the wrong tree here. Firstly, the chips in the machines are different and while the improvement over the old chips was to deliver more hashing speed for less energy, I suppose something has to give in terms of power consumption at lower speeds.

The efficiencies in comparing the two chips should be focused on the overall power consumption for hashing speed. If they'd designed the new chip to primarily consume less power when hashing at lower speeds, then it would probably have meant that it would consume (exponentially) more power when hashing at higher speeds than it does in its current state! Something has to give. What you cannot question however, is the efficiency of the S3 over the S1, call it something else if you insist.

What are you on about? Check your own post.
For an S3 201Gh/s = 154W
where as
for an S1 140Gh/s = 166W

you get MORE speed for less wattage, that is better efficiency in my book!
Put another way, for only 154 watts on an S3, you get more hashing speed than you would get from an S1 consuming 400 watts (i.e running at 180Gh/s). That is less than half the power usage for more speed!

If your intention is to draw less power from the wall, then yes, lowering the frequency will result in less power draw from the wall.

I don't know what to think of this S1 upgrade kit. It essentially is buying a new S3, albeit at a reduced price on a "full" S3 shipping on the same date.
When the upgrade idea was first mooted, I thought it'd take the shape of a chip-side heatsink (including the votage regulators) as opposed to an upgrade that amounts "junking" the old boards, or even a controller board that allowed for chain-linking more than the standard two boards and running them under-volted / under-clocked.

Though it may make BTC sense by the time these hit the market, I can not help but feel there has been a missed opportunity here. I may want (and possibly get) the upgrade, but I will also want to keep using the old boards.