ANTMINER S3+ Discussion and Support Thread

[Unacceptable]

Well if it's right in the gui like that it will be way easier to set than on my S1, thanks.

I'll keep looking for a performance summary, bound to be 9ne posted around here somewhere.

at this point in time, someone should figure out a way to undervolt and underclock these things instead of trying to overclock them.

they are near the end of their profitability.

True, but for a hobby miner that is not concerned with profit I want maximum hash rate at the most stable setting.   

That's exactly why I got the S3+ with the proper firmware,to underclock it very soon   

Got a second one coming in late this week     At $115 with shipping,bout the only miner I see making ROI in about 3 months or less............

Be looking for a third in a week or 2.Hope to underclock them to about 300-325 watts.

[Mikestang]

Well if it's right in the gui like that it will be way easier to set than on my S1, thanks.

I'll keep looking for a performance summary, bound to be 9ne posted around here somewhere.

at this point in time, someone should figure out a way to undervolt and underclock these things instead of trying to overclock them.

they are near the end of their profitability.

True, but for a hobby miner that is not concerned with profit I want maximum hash rate at the most stable setting.  

That's exactly why I got the S3+ with the proper firmware,to underclock it very soon  

Got a second one coming in late this week     At $115 with shipping,bout the only miner I see making ROI in about 3 months or less............

Be looking for a third in a week or 2.Hope to underclock them to about 300-325 watts.

Good plan.  I eventually want to add something like an sp20 to my little home set up.  I look forward to the next hardware releases so that the sp20's and S5's will cost what the S3 does today (and the S3 like the S1 I guess...).

[aarons6]

Well if it's right in the gui like that it will be way easier to set than on my S1, thanks.

I'll keep looking for a performance summary, bound to be 9ne posted around here somewhere.

at this point in time, someone should figure out a way to undervolt and underclock these things instead of trying to overclock them.

they are near the end of their profitability.

True, but for a hobby miner that is not concerned with profit I want maximum hash rate at the most stable setting.  

That's exactly why I got the S3+ with the proper firmware,to underclock it very soon  

Got a second one coming in late this week     At $115 with shipping,bout the only miner I see making ROI in about 3 months or less............

Be looking for a third in a week or 2.Hope to underclock them to about 300-325 watts.

not exactly sure where you got your calculations.. i hate to burst your bubble but with zero electricity costs, running at 225mhz @ 450 ghs it will take 6 to 8 months to roi 115$ @ 0.004877 BTC per day for the next 5 days, then dropping down to 0.004492 a day and then 0.004241 a day, etc

calculating in the next couple diff increases over 5%..



if you OC them, they will make more, but cost more to run.. if you pay for power this isnt always the best idea
there was someone that posted a chart on the s3 and how much less efficient it runs at higher speeds. running the most efficient at around 200mhz

[Unacceptable]

Well if it's right in the gui like that it will be way easier to set than on my S1, thanks.

I'll keep looking for a performance summary, bound to be 9ne posted around here somewhere.

at this point in time, someone should figure out a way to undervolt and underclock these things instead of trying to overclock them.

they are near the end of their profitability.

True, but for a hobby miner that is not concerned with profit I want maximum hash rate at the most stable setting.  

That's exactly why I got the S3+ with the proper firmware,to underclock it very soon  

Got a second one coming in late this week     At $115 with shipping,bout the only miner I see making ROI in about 3 months or less............

Be looking for a third in a week or 2.Hope to underclock them to about 300-325 watts.

not exactly sure where you got your calculations.. i hate to burst your bubble but with zero electricity costs, running at 225mhz @ 450 ghs it will take 6 to 8 months to roi 115$ @ 0.004877 BTC per day for the next 5 days, then dropping down to 0.004492 a day and then 0.004241 a day, etc

calculating in the next couple diff increases over 5%..



if you OC them, they will make more, but cost more to run.. if you pay for power this isnt always the best idea
there was someone that posted a chart on the s3 and how much less efficient it runs at higher speeds. running the most efficient at around 200mhz

I pay power out of my pocket,as long as I keep to about 1000 watts.I gave up trying to calculate with power deducted,it's incorrect,but the only way I can justify mining anymore...

Just a better way to gain BTC than being gouged at LBTC or going thru an exchange.So with 2 S3's @ $230 @ 900hg=.01 btc per day (approx),I need 1 BTC (atm) to break even=3 months 10 days or thereabouts.

Then I can sell the S3's & MAYBE upgrade to something better........

I gave up my bank account,free banking is not free banking,the fee's were growing & my income was shrinking..........so I work for cash now  

[soy]

Well if it's right in the gui like that it will be way easier to set than on my S1, thanks.

I'll keep looking for a performance summary, bound to be 9ne posted around here somewhere.

at this point in time, someone should figure out a way to undervolt and underclock these things instead of trying to overclock them.

they are near the end of their profitability.

True, but for a hobby miner that is not concerned with profit I want maximum hash rate at the most stable setting.  

That's exactly why I got the S3+ with the proper firmware,to underclock it very soon  

Got a second one coming in late this week     At $115 with shipping,bout the only miner I see making ROI in about 3 months or less............

Be looking for a third in a week or 2.Hope to underclock them to about 300-325 watts.

not exactly sure where you got your calculations.. i hate to burst your bubble but with zero electricity costs, running at 225mhz @ 450 ghs it will take 6 to 8 months to roi 115$ @ 0.004877 BTC per day for the next 5 days, then dropping down to 0.004492 a day and then 0.004241 a day, etc

calculating in the next couple diff increases over 5%..



if you OC them, they will make more, but cost more to run.. if you pay for power this isnt always the best idea
there was someone that posted a chart on the s3 and how much less efficient it runs at higher speeds. running the most efficient at around 200mhz

I pay power out of my pocket,as long as I keep to about 1000 watts.I gave up trying to calculate with power deducted,it's incorrect,but the only way I can justify mining anymore...

Just a better way to gain BTC than being gouged at LBTC or going thru an exchange.So with 2 S3's @ $230 @ 900hg=.01 btc per day (approx),I need 1 BTC (atm) to break even=3 months 10 days or thereabouts.

Then I can sell the S3's & MAYBE upgrade to something better........

I gave up my bank account,free banking is not free banking,the fee's were growing & my income was shrinking..........so I work for cash now  

Yes.  Looking at the net hashrate over time versus value of Bitcoin, it looks like mining takes its toll on value.  If the effect is true then when payout halves next year, I'm *guessing* Bitcoin value will increase but not quite 2x, it will be another drop in profit.  But the up to 2x increase in Bitcoin value will be great for anyone holding BTC.  Now if we have to cash in mined BTC to meet electric costs it means that BTC ain't getting saved for that BTC value increase.

Point is that if one is a retiree and paying for power every month without a financial cushion that would allow betting on BTC value increase, it's getting tough.

[soy]

Yes but I'm a retired technician and one does what one does.

Just my thinking this .... I believe the updated firmware ALSO updates the PIC firmware and it is this (the PIC firmware) that causes / results in the diminishing hashrate on the newer firmware. If you have a copy of the old firmware, I'd be tempted to extract that hex file from the old firmware and put it in the overlay directory then rebooting (of course, do backup the existing hex file before copying the older one, and that at your own risk!).

Also, repasting, when done, needs to be preceded by a thorough clean and removal of the old paste. Again, just my thinking, but I found that using slightly thicker thermal pads gave better results on the S3's I had than any (recomended) non conductive thermal paste I could lay my hands on.

I don't have a miner open and didn't notice a PIC when I did.  May I ask where is it?

[pekatete]

Yes but I'm a retired technician and one does what one does.

Just my thinking this .... I believe the updated firmware ALSO updates the PIC firmware and it is this (the PIC firmware) that causes / results in the diminishing hashrate on the newer firmware. If you have a copy of the old firmware, I'd be tempted to extract that hex file from the old firmware and put it in the overlay directory then rebooting (of course, do backup the existing hex file before copying the older one, and that at your own risk!).

Also, repasting, when done, needs to be preceded by a thorough clean and removal of the old paste. Again, just my thinking, but I found that using slightly thicker thermal pads gave better results on the S3's I had than any (recomended) non conductive thermal paste I could lay my hands on.

I don't have a miner open and didn't notice a PIC when I did.  May I ask where is it?

PIC chip is on the control board. I am not sure that is the PIC in the image, as I could not easily / quickly get to the control board (and can not remember whether I actually saw one on the control board), but it surely has one. The image below is from one of the S1 to S3 upgraded rigs that I keep outside so I can run at max with the fans blowing their hardest (aka blue wire hack).

EDIT: the chip shown in the image is NOT the PIC I was refering to, that one is for the ethernet (which it resides next to)

If you SSH into your rig, the hex file resides in /overlay/etc/config and is named miner_pic.hex and I believe this is reflashed every time the rig has a cold / power reboot.

http://s12.postimg.org/l87wy1pm5/WP_000124.jpg

[soy]

Yes but I'm a retired technician and one does what one does.

Just my thinking this .... I believe the updated firmware ALSO updates the PIC firmware and it is this (the PIC firmware) that causes / results in the diminishing hashrate on the newer firmware. If you have a copy of the old firmware, I'd be tempted to extract that hex file from the old firmware and put it in the overlay directory then rebooting (of course, do backup the existing hex file before copying the older one, and that at your own risk!).

Also, repasting, when done, needs to be preceded by a thorough clean and removal of the old paste. Again, just my thinking, but I found that using slightly thicker thermal pads gave better results on the S3's I had than any (recomended) non conductive thermal paste I could lay my hands on.

I don't have a miner open and didn't notice a PIC when I did.  May I ask where is it?

PIC chip is on the control board. I am not sure that is the PIC in the image, as I could not easily / quickly get to the control board (and can not remember whether I actually saw one on the control board), but it surely has one. The image below is from one of the S1 to S3 upgraded rigs that I keep outside so I can run at max with the fans blowing their hardest (aka blue wire hack).

EDIT: the chip shown in the image is NOT the PIC I was refering to, that one is for the ethernet (which it resides next to)

If you SSH into your rig, the hex file resides in /overlay/etc/config and is named miner_pic.hex and I believe this is reflashed every time the rig has a cold / power reboot.

http://s12.postimg.org/l87wy1pm5/WP_000124.jpg

Unfortunately the S3#2 from Pines in Florida having a falling hashrate went thru some testing.  First test I did was swap controller boards and S3#2 still dropped in hashrate.  After more testing I took one of the boards out of the S3#2 and put it in my excellent, which had arrived in an unopened box, S3#1 from Cryptocrane in the mid-west.  With that both miners would drop in hashrate at about the same rate.  I left it like that for quite a while having them restart cgminer at low hashrates then about a month ago put them back the way they were except S3#2's controller was in S3#1 and since I would need reconfigure the settings as the controller has the miner's identity, I left it but it does run S3#1 at 440 rather than 441.  So the dropping hashrate does not track the controller board and its PIC.  Perhaps what you're saying is that the PIC can be tweaked to give a false reading because as is the falling hashrate stays with the original boards on S3#2.

And on another note,  with a cold morning the other day and S3#1 in my living room, I decided to try a higher frequency (for the first time on the miner) and raised the frequency to 237.5M as it is the next step up on this firmware, this instead of propane heat.  It ran fine, no x's for the couple of days I ran it at that 237.5M and got a hashrate up around that of my S3+'s although the S3+ firmware has a frequency available between the 218.75M and 237.5M choices of the S3's.

It warmed up yesterday so I put the frequency back to 218.75M and restarted.  Now my good S3#1 wouldn't come up to 440 any more and was sticking around 435.  I had moved it a little and considered that since it's been running well since putting the boards back to their original miners (except the controllers) and since my dog has a bed in the clear space near the miner, and although I have a layer of cheesecloth filtering the fan intake, perhaps moving it a little caused dust to dislodge and have an effect and that the lower hashrate wasn't the result of some functional change of the hardware or software other than from dust.  So, I just finished opening it and without removing any heatsinks, cleaned out all dust accessible, and there was more than a little.  Right now after reassembly, at 56m1s it's at 441.24GH/s(avg).  Glad hardly covers it as a description of relief on its recovery.

[pekatete]

^^^ I don't think there's more to add to that ..... I don't have a malfunctioning S3 variant, but will dig up the old firmware, extract the PIC firmware and do a raw comparison, if there is a discrepancy, I'll replace the PIC hex file with the old one and see what happens ... just don't hold your breath as that may not be for a while.

[soy]

^^^ I don't think there's more to add to that ..... I don't have a malfunctioning S3 variant, but will dig up the old firmware, extract the PIC firmware and do a raw comparison, if there is a discrepancy, I'll replace the PIC hex file with the old one and see what happens ... just don't hold your breath as that may not be for a while.

No problem.  I'm still thinking the S3#2 hashrate fall is somehow related to rough removal of the heatsinks from the hashing boards and some hairline crack at a capacitor or resistor, fixed with a touch of flux and fine handling of a soldering iron will stop the hashrate fall although that rough handling could just as easily put a crack in the solder of an ASIC pin which I can't fix with an iron.  Though the PIC issue might somehow relate to the very minor albeit detectable lower hashrate of the controller from S3#2 onto S3#1.

[pekatete]

^^^ I don't think there's more to add to that ..... I don't have a malfunctioning S3 variant, but will dig up the old firmware, extract the PIC firmware and do a raw comparison, if there is a discrepancy, I'll replace the PIC hex file with the old one and see what happens ... just don't hold your breath as that may not be for a while.

No problem.  I'm still thinking the S3#2 hashrate fall is somehow related to rough removal of the heatsinks from the hashing boards and some hairline crack at a capacitor or resistor, fixed with a touch of flux and fine handling of a soldering iron will stop the hashrate fall although that rough handling could just as easily put a crack in the solder of an ASIC pin which I can't fix with an iron.  Though the PIC issue might somehow relate to the very minor albeit detectable lower hashrate of the controller from S3#2 onto S3#1.

Well, it has been widely reported that the newer firmwares depict diminishing hash-rate syndrome ...... and I can not attribute that to your particular hairline crack diagnosis. Thats not to say it is not may be the case for your #2, but most definitely not for the multitude other reported rigs.

[soy]

^^^ I don't think there's more to add to that ..... I don't have a malfunctioning S3 variant, but will dig up the old firmware, extract the PIC firmware and do a raw comparison, if there is a discrepancy, I'll replace the PIC hex file with the old one and see what happens ... just don't hold your breath as that may not be for a while.

No problem.  I'm still thinking the S3#2 hashrate fall is somehow related to rough removal of the heatsinks from the hashing boards and some hairline crack at a capacitor or resistor, fixed with a touch of flux and fine handling of a soldering iron will stop the hashrate fall although that rough handling could just as easily put a crack in the solder of an ASIC pin which I can't fix with an iron.  Though the PIC issue might somehow relate to the very minor albeit detectable lower hashrate of the controller from S3#2 onto S3#1.

Well, it has been widely reported that the newer firmwares depict diminishing hash-rate syndrome ...... and I can not attribute that to your particular hairline crack diagnosis. Thats not to say it is not may be the case for your #2, but most definitely not for the multitude other reported rigs.

The repasting suggestion appeared fairly early.  It was almost described as something one should do even if there were no serious faults showing.  This led to many miners being taken offline in a period when return was still pretty good but hashrate rising so a gainsay motive isn't out of the question.  How many S3 owners, attempting the repasting, were not electronic techs with SMT experience who would not comprehend that flexing a circuit board tends to damage SMT solder joints.  It could very well be that falling hashrate happened almost always after repasting.  I'd venture we don't know.

[pekatete]

The repasting suggestion appeared fairly early.  It was almost described as something one should do even if there were no serious faults showing.  This led to many miners being taken offline in a period when return was still pretty good but hashrate rising so a gainsay motive isn't out of the question.  How many S3 owners, attempting the repasting, were not electronic techs with SMT experience who would not comprehend that flexing a circuit board tends to damage SMT solder joints.  It could very well be that falling hashrate happened almost always after repasting.  I'd venture we don't know.

OK, now you are stretching it to unrealistic levels .......

Most reports of falling hashrates (and this is an old topic well documented in this very thread) were after the December '14 and January 19th firmware release(s), if I recall correctly. The Oct, Nov or Dec '14 firmware(s) introduced the voltage setting  but inadvertently removed the reset button functionality. Subsequent releases were supposed to restore the reset button functionality that had gone un-noticed for a few months. The buggy newer firmware that introduced the voltage setting to the S3 variant was the reason most people decided to update their firmwares to take advantage of the voltage settings. Of course the firmware flashing led to the discovery of the reset button bug as people wanted to use it to revert to the older firmware because of, mainly, the falling hash-rate syndrome with the newer firmware.

Again, if I recall correctly, the repasting was supposed to be a measure suggested to mitigate the falling hashrate syndrome of the latter newer firmware. So basically, if ever there was damage caused by repasting (I doubt that though), it simply excercebated the problem and did not cause it, in my opinion.

[soy]

The repasting suggestion appeared fairly early.  It was almost described as something one should do even if there were no serious faults showing.  This led to many miners being taken offline in a period when return was still pretty good but hashrate rising so a gainsay motive isn't out of the question.  How many S3 owners, attempting the repasting, were not electronic techs with SMT experience who would not comprehend that flexing a circuit board tends to damage SMT solder joints.  It could very well be that falling hashrate happened almost always after repasting.  I'd venture we don't know.

OK, now you are stretching it to unrealistic levels .......

Most reports of falling hashrates (and this is an old topic well documented in this very thread) were after the December '14 and January 19th firmware release(s), if I recall correctly. The Oct, Nov or Dec '14 firmware(s) introduced the voltage setting  but inadvertently removed the reset button functionality. Subsequent releases were supposed to restore the reset button functionality that had gone un-noticed for a few months. The buggy newer firmware that introduced the voltage setting to the S3 variant was the reason most people decided to update their firmwares to take advantage of the voltage settings. Of course the firmware flashing led to the discovery of the reset button bug as people wanted to use it to revert to the older firmware because of, mainly, the falling hash-rate syndrome with the newer firmware.

Again, if I recall correctly, the repasting was supposed to be a measure suggested to mitigate the falling hashrate syndrome of the latter newer firmware. So basically, if ever there was damage caused by repasting (I doubt that though), it simply excercebated the problem and did not cause it, in my opinion.

Repasting per se didn't damage, flexing may have.  The hashing boards and the inside heatsink do not part easily as you know.  That difficult separation would result in many just 'trying harder' with the result hashboards were bent/flexed.

[pekatete]

^^^ enough from me said on that .... we'll have to agree to disagree as I believe it is so far fetched to assume all the reported falling hash-rate that coincided with the newer firmware installation should be attributed to repasting (or handling during repasting).

On the miner_pic.hex file, I've just noticed a few things.
1. The Dec 19th firmware has the /overlay/etc/config directory structure with the miner_pic.hex file in it.
2. The Oct 24th firmware does NOT have that directory heirachy.
3. Both have the  config settings / directive file to flash the hex file in /etc/config and the file is pic-update and it expects the hex file to reside in the same (non-volatile?) directory, i.e in /etc/config
NOTE: I say non-volatile because as far as I'd expect, the overlay directory SHOULD be volatile but the /etc/config should persist over reboots, of course due to the very bug that introduced the reset button bug, the file system is messed up (for lack of a better word!) on the buggy firmware.

So it should follow that extracting and copying the Aug '14 miner_pic.hex file into the /etc/config directory should result in reflashing the PIC on reboot. I'll do this as soon as I can re-install my MinGW environment and extract the hex file.

[ZymurBits]

.... we'll have to agree to disagree as I believe it is so far fetched to assume all the reported falling hash-rate that coincided with the newer firmware installation should be attributed to repasting (or handling during repasting).

Throwing in my 2 bits, I experienced the deteriorating hashrate phenomenon after installing a newer firmware (I think 12/19).  After reverting back to 10/24 firmware, I haven't had that problem.

[soy]

Oops.  Checking the good S3, S3#1, after a day at 237.5M and a great hashrate which I didn't record and don't trust my memory.  Now before that S3#1 ran dependably at ~440GH/s but afterwards seemed to be stuck between 435&438, getting to the 440+ area for a while after startup but dropping 2-4GH after warming.  No x's have ever showed on S3#1.  So, unless I'm wrong, overclocking even for only a day or two will degrade the hashrate/frequency.  Am checking now GH/f/wattage from 100M and upward.  Perhaps efficiency improved?  Will know in a day.  This test I'm doing is 2hr/frequency so perhaps not attaining full GH/s at each.

------------------------

Okay, S3#1 is back to normal after working my way up the frequency ladder.  440.46GH/s(avg) after 20 hours at 218.75M.  So the hashrate drop wasn't permanent.

[soy]

.... we'll have to agree to disagree as I believe it is so far fetched to assume all the reported falling hash-rate that coincided with the newer firmware installation should be attributed to repasting (or handling during repasting).

Throwing in my 2 bits, I experienced the deteriorating hashrate phenomenon after installing a newer firmware (I think 12/19).  After reverting back to 10/24 firmware, I haven't had that problem.

I feel like Linus in football season with Lucy moving the placed football causing Linus to fall.  I took your suggestion but didn't see any 10/24 S3 firmware so went to an earlier, 20140721, version and found myself back at the firmware I had before trying others.  I had worked my way up to 20141013 which repeatedly came up with GUI failures so I backed down to 20140811.  But you said earlier so I again tried the next earlier which was as I Mentioned 20140721, the LuCI.  Can't help feeling like I've been played, Lucy LuCI.

So the 20140721 firmware was replaced last night requiring me to replace the rebooting at low hashrate script and by this morning it had run twice for low hashrate, e.g. below 421.

Waiting on that liquid flux which only left California yesterday.

After restarting cgminer the second time since firmware change, there was an x on each chain on this S3#2.  x's at chain1#2 and chain2#8.  This, the S3 from Pines in Florida sold as new but arriving in an opened box, has had x's various times at chain1#2, chain2#6, chain2#8 and chain2#16 but as mentioned previously the chain2#16 was cleared by cleaning the ASICs with a brush and solvent as it sits near the intake fan and at that time I had the fan on full 12v continually and may have pulled in some debris that hit that ASIC.

[aarons6]

.... we'll have to agree to disagree as I believe it is so far fetched to assume all the reported falling hash-rate that coincided with the newer firmware installation should be attributed to repasting (or handling during repasting).

Throwing in my 2 bits, I experienced the deteriorating hashrate phenomenon after installing a newer firmware (I think 12/19).  After reverting back to 10/24 firmware, I haven't had that problem.

I feel like Linus in football season with Lucy moving the placed football causing Linus to fall.  I took your suggestion but didn't see any 10/24 S3 firmware so went to an earlier, 20140721, version and found myself back at the firmware I had before trying others.  I had worked my way up to 20141013 which repeatedly came up with GUI failures so I backed down to 20140811.  But you said earlier so I again tried the next earlier which was as I Mentioned 20140721, the LuCI.  Can't help feeling like I've been played, Lucy LuCI.

So the 20140721 firmware was replaced last night requiring me to replace the rebooting at low hashrate script and by this morning it had run twice for low hashrate, e.g. below 421.

Waiting on that liquid flux which only left California yesterday.

After restarting cgminer the second time since firmware change, there was an x on each chain on this S3#2.  x's at chain1#2 and chain2#8.  This, the S3 from Pines in Florida sold as new but arriving in an opened box, has had x's various times at chain1#2, chain2#6, chain2#8 and chain2#16 but as mentioned previously the chain2#16 was cleared by cleaning the ASICs with a brush and solvent as it sits near the intake fan and at that time I had the fan on full 12v continually and may have pulled in some debris that hit that ASIC.

my s3s are on the 12/19 firmware and they are rock solid stable at 440ghs @ 218.75
its not a firmware problem.

[aarons6]

^^^ I don't think there's more to add to that ..... I don't have a malfunctioning S3 variant, but will dig up the old firmware, extract the PIC firmware and do a raw comparison, if there is a discrepancy, I'll replace the PIC hex file with the old one and see what happens ... just don't hold your breath as that may not be for a while.

No problem.  I'm still thinking the S3#2 hashrate fall is somehow related to rough removal of the heatsinks from the hashing boards and some hairline crack at a capacitor or resistor, fixed with a touch of flux and fine handling of a soldering iron will stop the hashrate fall although that rough handling could just as easily put a crack in the solder of an ASIC pin which I can't fix with an iron.  Though the PIC issue might somehow relate to the very minor albeit detectable lower hashrate of the controller from S3#2 onto S3#1.

Well, it has been widely reported that the newer firmwares depict diminishing hash-rate syndrome ...... and I can not attribute that to your particular hairline crack diagnosis. Thats not to say it is not may be the case for your #2, but most definitely not for the multitude other reported rigs.

The repasting suggestion appeared fairly early.  It was almost described as something one should do even if there were no serious faults showing.  This led to many miners being taken offline in a period when return was still pretty good but hashrate rising so a gainsay motive isn't out of the question.  How many S3 owners, attempting the repasting, were not electronic techs with SMT experience who would not comprehend that flexing a circuit board tends to damage SMT solder joints.  It could very well be that falling hashrate happened almost always after repasting.  I'd venture we don't know.

ive repasted my s3s..

the heatsinks on these are on the outside.. you dont have to take anything apart.
its not difficult.. there is 4 screws and they are spring loaded.. meaning you cant over tighten them..

as long as you werent a complete idiot and put the heatsinks on upside down, you cant really screw it up.

clean the chips off, just put a dab of new paste on each chip, screw the heatsink back on.

when i took mine off there were 3 chips that didnt have any paste at all and 2 or 3 only had about 20% covered.

just make sure you use non conductive thermal paste..
i think i used MX-4.