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
Just write a cron job so the miner will reboot every 2 hours.
I have it rebooting with a script found early in this thread but with some mods. Still, it's not right and when the flux gets here I'll try and fix it if I'm not busy with something else.
Actually I don't have it rebooting but essentially this command is run"etc/init.d/cgminer stop && sleep 2 &&etc/init.d/cgminer start ". This doesn't work forever of course as something like errors build up.
I have it set to run cg.sh at 421GH/s.
Also, we had a power outage in heavy rain sometime last night which probably explains the hashrate of 4.
I put it in last night. It echos restart to a file. In that file is:
ran cg.sh at 2015-03-30-04-30-04 because avg hashrate: 420
ran cg.sh at 2015-08-30-04-30-04 because avg hashrate: 4
ran cg.sh at 2015-03-30-16-30-04 because avg hashrate: 417
It runs every hour on the half hour. I manually shut it down mid-day today to try a test: I stopped the cron 3 minute repetition because it restarts cgminer if cgminer is stopped but not sure when that 3 minutes times out relative to my needs - and I wantedto try hashing stopped for some additional minutes with the fan running to cool it down some, then after a timeout, restarted cgminer hoping it would show lower power usage and quicker return to a reasonable hashrate. Had to go out so really didn't get handle if it's worth stopping hashing for some minutes versus just stopping and starting cgminer.
