Just two PCIE connectors plugged closest to the RJ45 and it normally runs for six months minimum, I just look 2 days ago the low hashrate. 
Take a look at your screen shot, ASIC Status, one of your boards is dead, you're hashing with 1/2 an S3.
Topic: ANTMINER S3+ Discussion and Support Thread - page 54. (Read 710241 times)
Take a look at your screen shot, ASIC Status, one of your boards is dead, you're hashing with 1/2 an S3.
Please try power it off, wait for 10-15 minutes then power it back on!
Hello, I come to you because I 've realized a problem of hashrate on my S3 no more than 200GH/s
here is the screenshot
Thank you in advance .
here is the screenshot
Thank you in advance .
Just two PCIE connectors plugged closest to the RJ45 and it normally runs for six months minimum, I just look 2 days ago the low hashrate.
Hello, I come to you because I 've realized a problem of hashrate on my S3 no more than 200GH/s
here is the screenshot
Thank you in advance .
here is the screenshot
Thank you in advance .
You have power going to how many PCIE connectors? Using all 4? only 2? only 1? Plugged in closest to the RJ45 socket end?
Hello, I come to you because I 've realized a problem of hashrate on my S3 no more than 200GH/s
here is the screenshot
http://img15.hostingpics.net/pics/827500antminer.png
Thank you in advance .
here is the screenshot
http://img15.hostingpics.net/pics/827500antminer.png
Thank you in advance .
Anyone handy with fixing these. I just listed my 2Ths S4 on ebay starting at $49 (no reserve). Does need some sort of repair.
http://www.ebay.com/itm/Bitmain-Antminer-S4-BATCH-2-Bitcoin-Miner-2Th-s-SHA256-Mining-AS-IS-Power-on-/281651706290?
Vegas
http://www.ebay.com/itm/Bitmain-Antminer-S4-BATCH-2-Bitcoin-Miner-2Th-s-SHA256-Mining-AS-IS-Power-on-/281651706290?
Vegas
My first S3+ should arrive any day, looking forward to it, woo! I plan to factory reset it and flash with the latest firmware straight away, like I did with my S1.
As a hobby miner I love that I can pick up the older tech for a mere fraction of what it retailed new for. Can't wait for the next gen to come out so that the used S5 price drops by 80%.
As a hobby miner I love that I can pick up the older tech for a mere fraction of what it retailed new for. Can't wait for the next gen to come out so that the used S5 price drops by 80%.
my s3s are on the 12/19 firmware and they are rock solid stable at 440ghs @ 218.75
its not a firmware problem.
its not a firmware problem.
Both S3 of mine running all on Firmware from 9th January..stable and the S3+ too
Picture from 1 S3:
1 S3+
^^^ 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
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.
.... 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.
.... 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.
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.
------------------------
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.
.... 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.
^^^ 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.
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.
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.
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.
^^^ 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
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.
^^^ 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
^^^ 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.
^^^ 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.
Jump to: