Has anybody found a fix for falling hashrate on some S3's? 

The miners I bought from Bitmain directly don't fade in hashrate (two S3+'s, two C1's and an S5) and the first S3 I bought from Cryptocrane on Amazon has been great and arrived in an unopened box an doesn't fade.  The S3 I bought from Pines in Florida on Amazon has been ratty and arrived in an open box opened at the bottom and carelessly closed.  When I saw it functioned poorly I re-pasted but found that both hashboards had already been re-pasted (if the pasting technique found on the first S3 was the norm).  I do believe the hashboards on the S3 from Pines in Florida had been removed perhaps by grasping the PCIE connectors and indelicately forcing the hashboards off the heatsinks.

I cleared an x on chain 2 ASIC 16 yesterday by re-applying the thermal paste on the front after carefully cleaning with a brush and solvent.  That x does not reappear. 

Problem is the usual falling hashrate at stock frequency without x's or dashes appearing.

2hrs; 443.19; amb. temp. 72°; watts at the wall 387w
4hrs; 441.12; amb. temp. 67°; watts at the wall 361w
5hrs; 434.01; amb. temp. 65°; watts at the wall 358w
7hrs; 427.40; amb. temp. 63°; watts at the wall 360w

The falling temperatures as day passed into night should have improved operation and there was less wattage used indicating fewer logic errors from for instance impurities outputting electrons striking/firing transistor gates inappropriately but yet the hashrate fell.

When I was troubleshooting failed SMT boards, the senior tech and I disagreed often.  Aside from regional differences, I'm not native to this area, he had no real troubleshooting skills and was the only tech allowed to run the SMT machine.  We both would troubleshoot boards.  I understood most of the circuits (excluding massive LSI chips) and did troubleshoot at a chip level while he would slather liquid flux on the components that usually fail and reflow solder on many, many components - this while not trying to understand the circuit operation.  I would often get boards he had no luck with.

I suspect I may have to try his technique, at least on the upper exposed voltage regulator circuitry.  Just ordered some liquid flux.  If the problems are at the ASIC level, I can only expect to bake the boards with the ASICs exposed and the rest covered but I've no plans to do that anytime soon.  Has anyone tried this with these?

Thanks.

soy

Cold morning I decided to move another S3 into the living room and dial them both up to 237.5.  I brought #2 in, the problem S3 that I had increased the rear fan speed by opening the blue wire and tieing it to 12v.  Cgminer was showing quite a good speed on that fan.  That chain #2 however had the last ASIC showing an x.    I tried various methods like dialing down the power supply voltage to 11.95v, didn't help, restarting again with the voltage dialed up to 12.15v, still the x would appear. 

In early posts on this forum I said I had found that looking at the RJ45 connector the board on the right was chain #1 and left chain #2.  I forget how I figured that out then, never having only plugged in a single board.  Today I tried only a single board on an S3 and found some confusing results. 

Disconnecting the ribbon cable from the board on the left, the controller card got no power.  Only connecting the ribbon cable to the board on the left but not the right looking at the RJ45 connector end, the controller lit, the miner started and showed that hashing board, the one on the left, as chain #1. 

This confused the heck out of me and I of course need to know which board had the x.  Putting both boards in, the board on the left provides power to the controller and becomes chain #2 if there are two boards but is called chain #1 if only one board is present.  At least that's what I believe to be the case because with two boards in the miner, unplugging the fan controlled by the board on the left, that's the exhaust fan, and firing it up shows chain #2 fan as having 0 speed.

So, since the dragon chain was showing the last ASIC on chain #2 as x, and since the ASICs count starts near the fan connector, down, across, up, across, down, across, etc, the last ASIC was positioned at the top closest to the intake fan. 

I suspected that since I had the exhaust fan going full blast for weeks that perhaps the hard air had brought in some conductive debris that lodged on the fan side of the ASIC.

I cut down a 1" paint brush so instead of 1½" length bristles it has 3/4" bristles.  Taking off the outside heatsink of board #2 on the left, I cleaned off as much of the thermal paste from ASICs as I could then sprayed each with auto brake cleaner and used the paint brush to clean the pins and adjacent components as well as possible taking most care with the top ASIC closest to the fan.  Then after cleaning the heatsink and applying a small bit of thermal paste to each ASCI, I put the heatsink back in place and buttoned it up.

I started it off at 237.5M.  It's run 39 minutes and all ASICs look good but it's running slow, 412.45GH/s (avg).  Maybe it will improve, maybe it will run better at stock frequency, maybe it will run best at exactly 12v from the power supply, don't know.  But what I do see is that the x from the ASIC on top closest to the fan on that board is no longer an x.

Those are available in chrome at Walmart.  I've been using a less expensive 4 shelf white cart found in the laundry section going for ~$12.59.  Caveat, they don't mention those work best when a small cable tie is used to fasten each shelf to a cross bar.  Otherwise it's a no screw fit together deal.  So cheap I've been using one per miner and supplies.  Thinking of putting two miners and supplies on each to exploit window access better.

I noticed the PCIE hashboard connecters are a slightly lower tolerance quality than in C1 or previous.

So, you'd be capable of fabricating water cooled sinks for S3's and S5's?

Ah, but would the cover PCIE connections ports line up?

Thanks for the offer but I solved it with a simple reset, albeit if holding the reset button in for 90 seconds is simple.  That's what I mentioned in the previous post as, at least for me, better than taking the cover off, removing the microSD card and dd'ing an image to the card then putting the card back, cover on, and returning the miner to its installation.

The hard reset fixed the failure to accept ssh logins.

I like your idea of saving an image having DHCP set.  Saving an image, an archived backup, that can be used on any C1 is a good idea.  After wakeup on the subnet one could change the configuration to a static IP and unique miner ID.

When I fix the second C1 using the 90 second reset I'll save an archive copy after setting DHCP.  
-----------------

Later I realized that a settings archive probably won't fix a ssh failure to login.  Failure occurred when I copied the file addition to /sbin to the permanent record using cp -rf /etc/shadow /config/ and resetting restores the /config/ while a settings archive might not.

It seems deliberate as if to dissuade.  

And no, simply flashing the card wouldn't give me the fix I need.  It would be in the .1.0 network after flashing the card unless you have an idea how to reset the 192.168.1.99 to another subnet on the card before it goes in the machine.

So, no.  Holding the reset for 90 seconds brings it to that, 192.168.1.99,  state.

The S5's wake up to DHCP so subnets are not a problem.  But water cooled has lower temps than hard fan like the S5.

The second C1 still has the ssh login failure.  To test if the problem was a wrong key failure, I ssh'd in from a machine that had never connected to the second C1 but the failure still occurred.

Okay, without taking the hood off,  reset the miner using the hard reset button.  To get a reliable reset I had to use an egg timer set for 1min30sec and with the button depressed applied power and started the timer.  Using a spare router I did finally get 192.168.1.99 and although I had gotten this before, after changing the options it got lost so this time first thing I did was only change static to DHCP.  That worked and checking the router I found the assigned IP. logged in and it seemed okay.  I shut it down and timed out 90 seconds dead no power with the RJ45 cable disconnected.  After 90 seconds dead I put the ethernet cable to the subnet switch and started the miner.  Then it was up and running on the subnet.  It seems luckier to leave the default pools to be among the last thing to change, heh, heh.  Oh, and ssh login works with root/admin.  Haven't done the second C1 with the login problem tho.  A couple of things I did notice, the first time after getting it up on the subnet, I put the laptop in that room up on the subnet as well and went to ssh in.  I said no to permanently remember the key and was refused.  When I ssh'd in from my regular machine it asked to permanently remember the key again although it had the key from before the change.  So, reflashing won't fix the ssh won't allow login.  Hard reset does and keeps the new firmware and changes the key such that one needs to give it a permanent yes. 

truc·u·lent
ˈtrəkyələnt/
adjective
adjective: truculent

    eager or quick to argue or fight; aggressively defiant.
    "his days of truculent defiance were over"
    synonyms:   defiant, aggressive, antagonistic, combative, belligerent, pugnacious, confrontational, ready for a fight, obstreperous, argumentative, quarrelsome, uncooperative;

This crap has my whole subnet down

Yes, perhaps.  I run nmap and see it has port 22/tcp ssh open as well as 80/tcp http but it's no help.

Since I'm at the Dec firmware maybe I should use the reset button, a hard reset should do it.

Or first I can restore to the Nov as I saved an archive then reflash to the newer firmware - it may be that just because I put don't save the settings, it looked at the firmware and say it's the same so I won't.

--------------
System Configuration Restore Successed -- rebooting
 Firmware still Dec 17 so Restore is only for setting not firmware.
 

The problem again:  On both C1's I put a script in /sbin and ran cp -rf /etc/shadow /config/ but then lost ssh login on both.  root/admin root/mypassword root/root, nothing works.

C1#1 had a November firmware and C1#2 had the December firmware.  I just used the GUI Upgrade to flash a new image and brought C1#1 up to the Wed Dec 17 firmware.  I flashed while retaining setting because it's not on the 192.168.1.0 network.  I still cannot ssh into the C1.

So I reflashed with Keep Settings unchecked.  Waited 90 seconds.  Shut the miner down.  Then expecting the miner to wakeup on the 192.168.1.0 network, swapped routers.  Then I couldn't find the miner on the .1.0 net so I ran tcpdump and saw the antminer looking for the gateway of the other network.  So I swapped the miner to the other network and do have a GUI but still can't login to ssh.  But it seems to be happily mining on the old settings, e.g. 243.75M/0725.

I know flashing the image changed the firmware when it changed from Nov to Dec firmware on Overview->System->File System Version.  But when I flashed that firmware again with the Keep Settings unchecked, it didn't revert to the stock settings. 

And on removing the board from the cooling block or inside heatsink on any S3 or C1, it looks like peeling it off would lead to damage.  These board were not made to flex.  I suggest one of the break off razor knives with a new long blade.  After screws are removed, slide in at a lower corner and work across.  

I have an slow s3 from Pines Computer in Florida bought on Amazon.  I suspect careless peeling may be the reason the boards are slower and inefficient.  If the underside ASIC heatsink plate soldering to the ground plane underneath has been damaged then it will be hotter.  A board flex could do that.  It will be the first Bitmain miner I will eventually retire and then I'll put it in an oven with the ASICs exposed to reflow the solder then test.

I attempted a check of the thermal paste.  Tried to do this without cutting the cooling connection but instead twisting.  Didn't work.  I gave up and let it be.  Those screw pairs on the S3's and S3+'s are only half used on each side, one screw per pair.  Probably thru hole and the other board on the far side using the other screw.  Easy to strip one of those and since not a pair it gets difficult.  Unless you plan to go hole hog and rip it apart ....

Really loving this machine.

Okay, up and running.  Wow.  It's light.  Surprised to find only 4 PCIE connections instead of 8.  I don't see anywhere in the GUI an option to change from CST to EDT.  Now to switch subnets.....

And didn't wake up to .1.99 but rather DHCP.  Glad I have nmap functional as my new router is a pain to log into.

Ah, finished my back room wiring to add an S5.  Just looked and it's in Anchorage.  Scheduled delivery tomorrow by end of day.  Happy with UPS!

Conclusion: the after market Syscooling pumps that have sharp edges and corners are too fragile for dependable use with these miners.  The stock Syscooling pumps with chamfered edges and corners have maybe twice the plastic thickness.   

The JD Weld I applied to the out port interface with the pump housing and along the seam, that after prepping/cleaning the surface with acetone, may have been okay but when I put the pump in place it again leaked at the out port and this after doing away with the heavy tubing and going with clear tubing so there's less weight on the port tube.  Disgusted, I taped the out port tube from the barb back to the pump housing with electrical tape almost up to the level of the barb and tried again.  This seems to be working.