Yes, this is better. Before it barely got up to 435GH/s with the low hashing board on the right side when looking at the RJ45 connector end. The right side is the top chain and generally has the higher temperature and faster fan. In this case it had lower temperature and slower fan than the lower chain. So, taking the end plates and their fans, swapping ends and moving the controller board, put it back the way it was shipped, the questionable board on the cooler side.
Almost right away the average went above 441GH/s and has remained above 440GH/s for the last 3h 23m and is presently 442.04 tho the utility is only 15. No hardware errors in that time. It was started as the afternoon cooled. It remains to be seen what happens tonight as the humidity increases.
Oh well. A minor improvement over yesterday morning and there's even greater humidity as it rained. This morning the problem S3 is hashing at 434.15GH/s. A nice improvement over finding it down at 419GH/s in the AM. Guess I'll just have to settle with this hashrate. The good S3 immediately next to it is at 440.85. ...1½ hrs after running /etc/init.d/cgminer stop, it restarts automatically after a minute or two, the hashrate of the problem is up to 442.18GH/s(avg). It restarts with a fresh Elapsed duration. So, I'll schedule this to run middle of the night and again in the AM. Okay, I see this problem has been address in message #482 this forum with cgminer-avg-monitor script. Kudos. |
|
|
|
Yes, this is better. Before it barely got up to 435GH/s with the low hashing board on the right side when looking at the RJ45 connector end. The right side is the top chain and generally has the higher temperature and faster fan. In this case it had lower temperature and slower fan than the lower chain. So, taking the end plates and their fans, swapping ends and moving the controller board, put it back the way it was shipped, the questionable board on the cooler side.
Almost right away the average went above 441GH/s and has remained above 440GH/s for the last 3h 23m and is presently 442.04 tho the utility is only 15. No hardware errors in that time. It was started as the afternoon cooled. It remains to be seen what happens tonight as the humidity increases.
Oh well. A minor improvement over yesterday morning and there's even greater humidity as it rained. This morning the problem S3 is hashing at 434.15GH/s. A nice improvement over finding it down at 419GH/s in the AM. Guess I'll just have to settle with this hashrate. The good S3 immediately next to it is at 440.85. ...1½ hrs after running /etc/init.d/cgminer stop, it restarts automatically after a minute or two, the hashrate of the problem is up to 442.18GH/s(avg). It restarts with a fresh Elapsed duration. So, I'll schedule this to run middle of the night and again in the AM. |
|
|
|
The good S3 came up to 441GH/s avg within an hour while the questionable S3 from Florida was only hitting 100GH/s. Not one with a whole lot of patience, I decided to install the 0811.bin firmware on the questionable S3. Did. Then worried a bit as it was only doing 10GH/s avg for some time. I restarted cgminer (/etc/init.d/cgminer stop, /etc/init.d/cgminer start) and there was no apparent improvement. Then I noticed there was no frequency listed on the status page so of course into the new Advanced tab on miner config, I specified the default and saved. Up 6 minutes now and in the 400's GH/s. Time will tell.
...Now over an hour and the S3 from Florida, having the 0811.bin firmware, seems to have settled out at 435.65GH/s. What would explain this and its low fan speed is if an ASIC near the LM75A has some engines turned off - perhaps it had overheated at some point and damaged one. I have noticed that the lower center ASICs under the LM75A tend to have drier thermal paste than other ASICs. Center of the hashing board. The curve of the inside heatsink fins and the direction of spin on the fans seems the reason one board, the top chain, gets hotter and has the faster fan speed.
If an ASIC near the LM75A is damaged and turns off engines, it gives the system an inaccurate assessment of the board's temperature. ASICs toward either end working properly will be running hot.
...their logic that the lower hashing board should be on the cooler side made sense so it's been torn down again, end plates reversed, fans reversed, controller board moved to the other end, and reassembled. Now coming up.
Florida, land of the floating chads.
Yes, this is better. Before it barely got up to 435GH/s with the low hashing board on the right side when looking at the RJ45 connector end. The right side is the top chain and generally has the higher temperature and faster fan. In this case it had lower temperature and slower fan than the lower chain. So, taking the end plates and their fans, swapping ends and moving the controller board, put it back the way it was shipped, the questionable board on the cooler side. Almost right away the average went above 441GH/s and has remained above 440GH/s for the last 3h 23m and is presently 442.04 tho the utility is only 15. No hardware errors in that time. It was started as the afternoon cooled. It remains to be seen what happens tonight as the humidity increases. |
|
|
|
Is there a fairly simple way to create a redirect stratum address, perhaps one that is on an internal computer on my network, that I could point multiple AntMiners to.
The point being to easily change the mining pool address, worker, password, and difficulty, at just one place, and all miners would then switch to the new address?
Or if there is an easier way, is there a way to mass update settings on a multiple AntMiners all at once?
Many thanks!
Strato
Yeap...This is how BitMain is running their AntMiner's farm...  1...Run a Stratum Proxy .exe on a separate computer ...look at Slush pool for .exe file... 2...Let's assume that this computer with running proxy is @ 192.168.1.100 ...point all AntMiners at this address... 3...You done ...  ZiG Have done this often but this is good only for changing to different IP addresses of the same pool, not for different pools as you run into a credential problemo and need to go into each cgminer or bfgminer and change credentials. The miners that use the stratum have their credentials. I wonder if each antMiner has a stratum capability to act as a proxy for other machines. |
|
|
|
... Then worried a bit as it was only doing 10GH/s avg for some time.
Reboot the S3 via SSH (not sure whether this works via the GUI). If you noticed when this happened, it also had an uptime that started before you restarted cgminer. This happened to me (and I was able to replicate) after installing cgminer 4.6, but a reboot via SSH "clears" the relic numbers. the downside to not having a clean slate for your circumstances is that you will not have accurate uptime hashing speed(s). I agree but find that stopping/starting /etc/init.d/cgminer gets a clean time and doesn't cause the ssh to disconnect. |
|
|
|
yeah but greed is tough and getting 3 eggs from the goose each day instead of 2 eggs is very tempting.
Wondering if they are able to lay 2 eggs a day.  A goose, nah. Some hybrid leghorn chickens 2 eggs/day, yes. |
|
|
|
Interesting. The problem hashing board now in my first S3 is working fine and very stable. I just found there is a difference between my first well running S3 and the S3 that the problem board came out of, and that's is a different firmware on each. I haven't found a way to determine while ssh'd in, e.g. opkg list | grep antMiner comes up a blank. But, bruno033 pointed me to the firmware page and I see there the 0721.bin has a solid green light when running. The first S3 from the mid-west has that. When I saw that the S3 from Florida had a flashing green light when hashing I though I probably configured it differently than the first. But it must mean the S3 I got from Florida has the 0711.bin firmware because the other later options are the 0811.bin and the 0826.bin, both of which will have the Advanced Frequency change option on the miner configuration page. So, the questionable board is very stable at this point in the S3 having the 0721.bin firmware. Time will tell if it remains at 441 overnight as the humidity rises, e.g. right now the rh is 30%.
soy
Disappointment. The problem board now in a good S3 this morning is down to 431.45GH/s after 22 hours. Will swap boards to their originating S3's today and upgrade beyond the OpenWrt Barrier Breaker r38031 / LuCI Trunk (svn-r9909) firmware. Just now have both S3's back up and running with their original boards. The fast fan good board from the good S3, I should note the hashing boards had QC Passed stickers the later S3 from Florida didn't. The good board with a fast fan from the good unit which brought its fast fan rate to the questionable unit when moved yesterday, I took apart and reapplied new thermal compound. I found the temperature sensing IC to be in the center between the two rows of ASICs, an LM75A. So running lines of compound along the top ASICs and again along the bottom but not the center wold tend to prevent the heatsink from cooling the device and result in faster fan rates. The surface mount device below the fan connection and above the upper left ASIC is a 25.000 crystal. This good board had excellent compound. Only worked on one of the two as I've run out of compound. Of the board I put back in the questionable unit, I cleaned the ASIC pins but ran out of cleaning fluid so reassembled with new paste. The fan to the questionable board still remains relatively slow. I'd like to see that higher. I'll wait to see how these settle out then upgrade the firmware. The good board from the good S3 not only had a QC sticker but also had handwriting on the right side of the board between the ASICs, an "A" and another "A" or perhaps one was an A1. The questionable board had what looked like an "S" and a lower case "o". These letters were vertical after the fashion of oriental script. The good S3 came up to 441GH/s avg within an hour while the questionable S3 from Florida was only hitting 100GH/s. Not one with a whole lot of patience, I decided to install the 0811.bin firmware on the questionable S3. Did. Then worried a bit as it was only doing 10GH/s avg for some time. I restarted cgminer (/etc/init.d/cgminer stop, /etc/init.d/cgminer start) and there was no apparent improvement. Then I noticed there was no frequency listed on the status page so of course into the new Advanced tab on miner config, I specified the default and saved. Up 6 minutes now and in the 400's GH/s. Time will tell. ...Now over an hour and the S3 from Florida, having the 0811.bin firmware, seems to have settled out at 435.65GH/s. What would explain this and its low fan speed is if an ASIC near the LM75A has some engines turned off - perhaps it had overheated at some point and damaged one. I have noticed that the lower center ASICs under the LM75A tend to have drier thermal paste than other ASICs. Center of the hashing board. The curve of the inside heatsink fins and the direction of spin on the fans seems the reason one board, the top chain, gets hotter and has the faster fan speed. If an ASIC near the LM75A is damaged and turns off engines, it gives the system an inaccurate assessment of the board's temperature. ASICs toward either end working properly will be running hot. ...their logic that the lower hashing board should be on the cooler side made sense so it's been torn down again, end plates reversed, fans reversed, controller board moved to the other end, and reassembled. Now coming up. Florida, land of the floating chads. |
|
|
|
Interesting. The problem hashing board now in my first S3 is working fine and very stable. I just found there is a difference between my first well running S3 and the S3 that the problem board came out of, and that's is a different firmware on each. I haven't found a way to determine while ssh'd in, e.g. opkg list | grep antMiner comes up a blank. But, bruno033 pointed me to the firmware page and I see there the 0721.bin has a solid green light when running. The first S3 from the mid-west has that. When I saw that the S3 from Florida had a flashing green light when hashing I though I probably configured it differently than the first. But it must mean the S3 I got from Florida has the 0711.bin firmware because the other later options are the 0811.bin and the 0826.bin, both of which will have the Advanced Frequency change option on the miner configuration page. So, the questionable board is very stable at this point in the S3 having the 0721.bin firmware. Time will tell if it remains at 441 overnight as the humidity rises, e.g. right now the rh is 30%.
soy
Disappointment. The problem board now in a good S3 this morning is down to 431.45GH/s after 22 hours. Will swap boards to their originating S3's today and upgrade beyond the OpenWrt Barrier Breaker r38031 / LuCI Trunk (svn-r9909) firmware. Just now have both S3's back up and running with their original boards. The fast fan good board from the good S3, I should note the hashing boards had QC Passed stickers the later S3 from Florida didn't. The good board with a fast fan from the good unit which brought its fast fan rate to the questionable unit when moved yesterday, I took apart and reapplied new thermal compound. I found the temperature sensing IC to be in the center between the two rows of ASICs, an LM75A. So running lines of compound along the top ASICs and again along the bottom but not the center wold tend to prevent the heatsink from cooling the device and result in faster fan rates. The surface mount device below the fan connection and above the upper left ASIC is a 25.000 crystal. This good board had excellent compound. Only worked on one of the two as I've run out of compound. Of the board I put back in the questionable unit, I cleaned the ASIC pins but ran out of cleaning fluid so reassembled with new paste. The fan to the questionable board still remains relatively slow. I'd like to see that higher. I'll wait to see how these settle out then upgrade the firmware. The good board from the good S3 not only had a QC sticker but also had handwriting on the right side of the board between the ASICs, an "A" and another "A" or perhaps one was an A1. The questionable board had what looked like an "S" and a lower case "o". These letters were vertical after the fashion of oriental script. |
|
|
|
Interesting. The problem hashing board now in my first S3 is working fine and very stable. I just found there is a difference between my first well running S3 and the S3 that the problem board came out of, and that's is a different firmware on each. I haven't found a way to determine while ssh'd in, e.g. opkg list | grep antMiner comes up a blank. But, bruno033 pointed me to the firmware page and I see there the 0721.bin has a solid green light when running. The first S3 from the mid-west has that. When I saw that the S3 from Florida had a flashing green light when hashing I though I probably configured it differently than the first. But it must mean the S3 I got from Florida has the 0711.bin firmware because the other later options are the 0811.bin and the 0826.bin, both of which will have the Advanced Frequency change option on the miner configuration page. So, the questionable board is very stable at this point in the S3 having the 0721.bin firmware. Time will tell if it remains at 441 overnight as the humidity rises, e.g. right now the rh is 30%.
soy
Disappointment. The problem board now in a good S3 this morning is down to 431.45GH/s after 22 hours. Will swap boards to their originating S3's today and upgrade beyond the OpenWrt Barrier Breaker r38031 / LuCI Trunk (svn-r9909) firmware. |
|
|
|
Interesting. The problem hashing board now in my first S3 is working fine and very stable. I just found there is a difference between my first well running S3 and the S3 that the problem board came out of, and that's is a different firmware on each. I haven't found a way to determine while ssh'd in, e.g. opkg list | grep antMiner comes up a blank. But, bruno033 pointed me to the firmware page and I see there the 0721.bin has a solid green light when running. The first S3 from the mid-west has that. When I saw that the S3 from Florida had a flashing green light when hashing I though I probably configured it differently than the first. But it must mean the S3 I got from Florida has the 0711.bin firmware because the other later options are the 0811.bin and the 0826.bin, both of which will have the Advanced Frequency change option on the miner configuration page. So, the questionable board is very stable at this point in the S3 having the 0721.bin firmware. Time will tell if it remains at 441 overnight as the humidity rises, e.g. right now the rh is 30%.
soy S3 GUI Status/Overview shows the firmware version. 2nd is Aug 7 and 3rd (S3+) is Aug 26. Both S3+'s have the Aug 26 but both the S3's have OpenWrt Barrier Breaker r38031 / LuCI Trunk (svn-r9909) and although the two S3's have that identically they have different green LED functionality. |
|
|
|
|
Interesting. The problem hashing board now in my first S3 is working fine and very stable. I just found there is a difference between my first well running S3 and the S3 that the problem board came out of, and that's is a different firmware on each. I haven't found a way to determine while ssh'd in, e.g. opkg list | grep antMiner comes up a blank. But, bruno033 pointed me to the firmware page and I see there the 0721.bin has a solid green light when running. The first S3 from the mid-west has that. When I saw that the S3 from Florida had a flashing green light when hashing I though I probably configured it differently than the first. But it must mean the S3 I got from Florida has the 0711.bin firmware because the other later options are the 0811.bin and the 0826.bin, both of which will have the Advanced Frequency change option on the miner configuration page. So, the questionable board is very stable at this point in the S3 having the 0721.bin firmware. Time will tell if it remains at 441 overnight as the humidity rises, e.g. right now the rh is 30%.
soy
|
|
|
|
|
Better thermal paste spreading means slower fan and lower HW errors though not always fixing a declining hashrate. Slower fan means more economical running. If the thermal paste isn't spread well under the temperature sensing device, where ever it is, it will take a higher fan speed to lower its temperature.
|
|
|
|
Out of 9 unit I have about 3 that have fan problems,
One was at 100% on arrival.
One became intermittent 100%.
And now one became permanently at 100% . I heard it ramp up to 100% and now no amount of power cycling will fix the problem.
What's up with that ?
You could determine if there's any responsiveness at all by putting a fan forcing air in and later put the fan to suck air out, fans outboard the installed. Still if firing up a cold S3 shows max speed then it's not likely to change. |
|
|
|
Out of 9 unit I have about 3 that have fan problems,
One was at 100% on arrival.
One became intermittent 100%.
And now one became permanently at 100% . I heard it ramp up to 100% and now no amount of power cycling will fix the problem.
What's up with that ?
What does the GUI say 100% fan maxes out at? |
|
|
|
|
I wonder. If facing the RJ45 connector the hashing board on the right is the top row of o's and has the higher temp's, then it doesn't follow that the temperature sensing chip is there under the fan connector as that's the cooler end of the device.
|
|
|
|
|
While I had a board out I looked for two things, a) the date on the board - not found so must be under a heatsink, b) the IC id on the chip under the fan connection above to the left of the end ASIC. The print on the IC was unreadable. Next time I have a board out I'll take it into the sunlight with a loupe. I'll put a ohmmeter on any associated resistors and compare to another board. In situ measurement of caps often is impossible but I can give that a try as well.
|
|
|
|
|
Of note is that in moving the questionable board to the good unit, on its right side facing the RJ45 connector, and vice versa, the higher fan speed of the good unit has gone to the bad unit and the good unit now has a slower fan speed on the top row. So, fan speed seems absolutely dictated by the relative hashing board and not the controller board.
The questionable board has been carefully treated with heatsink compound while the good machine has its original heatsink compound. Perhaps the better heatsinking of carefully applied thermal paste dictates lower fan speed.
A quick check shows that the S3+'s have only a single large gold QC Passed sticker, as did the problem S3 while the good S3 had two QC stickers.
|
|
|
|
So the problem S3 was down around 430GH/s this morning and I decided to go over its probably reworked board, the board that had grossly over-tightened screws, but would try frequency change first.
It had been down to 430 so I tried changing the frequency to check out its effect on hashrate. In /etc/config/asic-freq I changed to f=225, rebooted and restarted cgminer to get a fresh time duration. I gave it some time but it came up very slowly only to 420 or so. And it was a cool morning! All the other machines were hashing perfectly. So, I tried again, this time with f=212.5 but again it came up slow and only to 417GH/s. So, I ripped it apart again.
I was going to concentrate on its ASICs at the hot end of the reworked board, but ended up getting distracted. What distracted me was that the board had marking in black ink at the far right under the top ASIC (on this board that would be near the intake fan). Might have been Chinese or a code of some kind. So, I cleaned that ACIC and the one under it with a spray of automobile brake cleaner such that all thermal paste was removed. Must be careful with the stuff as it will mar many plastics. I sprayed those ASICs cleaning around the pins, reapplied thermal compound to both sides of the blade and reassembled. The brake cleaner removed the notation marks on that blade. When I reassembled, for a change, I put the bad board on the right side facing the RJ45 connector.
I started it up then ran to the store and back. Right now the 'difficult' S3, at a frequency of 218.75, after 1hr 20min, has an average hashrate of 443.74GH/s. The temps are both 40° with fan speeds of 2040/1800. Time will tell.
Bummer. Up now over 6hrs and the hashrate has started to drop off. Could be to an increase in humidity and that the first S3 hasn't seen a similar tailing off of hashrate because its average is over a 12hr period but probably not as it's at 442.24GH/s utility 17 while the problem S3 has tailed off to 437.63, utility 15. Experience tells me it will continue to fall and tomorrow morning may be down around 420GH/s. Temps are 40/39 and fans 1920/1620. The good S3 has 40/38 3180/1920 and the good and questionable S3's are side by side. What jumps out are the higher fan speeds of the good S3. Too bad. 1:30AM, checking the problem S3 and its hashrate has dropped to 429.01GH/s after 9hr 55min. Since I have two S3's, I could take what I think is the bad board and swap it into the other S3 and see if the good S3 then has a falling hashrate - just to make sure which board is bad. What's wrong with that is that the other S3, purchased from a reseller in the mid-west, runs fine (presently 441.67GH/s) while the problem S3 is from Florida (and that guy wants me to remove the 1 star Amazon rating, screw him, opened the bottom of a box from a good one and put the probably returned problem in and sent it out as new). By morning the problem S3 will likely be down to 420GH/s. Wonder if it's accumulating errors in an ASIC that then shuts down engines over time. Wonder if China sends more problem S3's to Florida than elsewhere given that Florida is a problem state like Shanghai crime before 1949. I'm not a happy camper. soy You are where many others have been 2 months ago. There are simply units like that and you probably wont be able to change it. And with 429 you cant complain, they were advertised with 441 +/- 5% if i remember correct. As soon as I removed a heatsink I felt I was burning bridges regarding any return. Hadn't noticed at that point that the box had been opened at the bottom, clear tape slit all around, then resealed probably with a single strip of clear tape along the center bottom leaving the slit sides showing it had been opened. Then, because I said I wanted USPS, priority mail tape went around the box at its center over the replaced tape on the bottom and some haphazard slaps of priority tape on its side. I opened at the top. Kind of indicates he had this dog sitting there and a new unopened boxed S3 and kept the good one shipping the dog. Right now the hashrate after 18hrs 17 minutes is 419.77GH/s, temps 38/39 while the good S3 from the mid-west sitting next to it has 441.88GH/s, temps 39/37. 441*.095=418.95 soy And the price with shipping was $511.48. And Amazon probably sees a record of a return to this seller. Amazon returns are honored, albeit less so if opened and the heatsinks removed. Swapping the questionable board from Florida into the good unit from the mid-west I notice that the good unit has two QC Passed stickers of different sizes/colors while the slow unit has a single QC Passed sticker large gold. Perhaps a previous owner who returned the unit removed one QC sticker. The questionable board is into the good S3 and both are now up and running. I'll wait a bit until both have gained some temperature then restart cgminer on both so as to have uptime duration coincide. soy |
|
|
|
So the problem S3 was down around 430GH/s this morning and I decided to go over its probably reworked board, the board that had grossly over-tightened screws, but would try frequency change first.
It had been down to 430 so I tried changing the frequency to check out its effect on hashrate. In /etc/config/asic-freq I changed to f=225, rebooted and restarted cgminer to get a fresh time duration. I gave it some time but it came up very slowly only to 420 or so. And it was a cool morning! All the other machines were hashing perfectly. So, I tried again, this time with f=212.5 but again it came up slow and only to 417GH/s. So, I ripped it apart again.
I was going to concentrate on its ASICs at the hot end of the reworked board, but ended up getting distracted. What distracted me was that the board had marking in black ink at the far right under the top ASIC (on this board that would be near the intake fan). Might have been Chinese or a code of some kind. So, I cleaned that ACIC and the one under it with a spray of automobile brake cleaner such that all thermal paste was removed. Must be careful with the stuff as it will mar many plastics. I sprayed those ASICs cleaning around the pins, reapplied thermal compound to both sides of the blade and reassembled. The brake cleaner removed the notation marks on that blade. When I reassembled, for a change, I put the bad board on the right side facing the RJ45 connector.
I started it up then ran to the store and back. Right now the 'difficult' S3, at a frequency of 218.75, after 1hr 20min, has an average hashrate of 443.74GH/s. The temps are both 40° with fan speeds of 2040/1800. Time will tell.
Bummer. Up now over 6hrs and the hashrate has started to drop off. Could be to an increase in humidity and that the first S3 hasn't seen a similar tailing off of hashrate because its average is over a 12hr period but probably not as it's at 442.24GH/s utility 17 while the problem S3 has tailed off to 437.63, utility 15. Experience tells me it will continue to fall and tomorrow morning may be down around 420GH/s. Temps are 40/39 and fans 1920/1620. The good S3 has 40/38 3180/1920 and the good and questionable S3's are side by side. What jumps out are the higher fan speeds of the good S3. Too bad. 1:30AM, checking the problem S3 and its hashrate has dropped to 429.01GH/s after 9hr 55min. Since I have two S3's, I could take what I think is the bad board and swap it into the other S3 and see if the good S3 then has a falling hashrate - just to make sure which board is bad. What's wrong with that is that the other S3, purchased from a reseller in the mid-west, runs fine (presently 441.67GH/s) while the problem S3 is from Florida (and that guy wants me to remove the 1 star Amazon rating, screw him, opened the bottom of a box from a good one and put the probably returned problem in and sent it out as new). By morning the problem S3 will likely be down to 420GH/s. Wonder if it's accumulating errors in an ASIC that then shuts down engines over time. Wonder if China sends more problem S3's to Florida than elsewhere given that Florida is a problem state like Shanghai crime before 1949. I'm not a happy camper. soy You are where many others have been 2 months ago. There are simply units like that and you probably wont be able to change it. And with 429 you cant complain, they were advertised with 441 +/- 5% if i remember correct. As soon as I removed a heatsink I felt I was burning bridges regarding any return. Hadn't noticed at that point that the box had been opened at the bottom, clear tape slit all around, then resealed probably with a single strip of clear tape along the center bottom leaving the slit sides showing it had been opened. Then, because I said I wanted USPS, priority mail tape went around the box at its center over the replaced tape on the bottom and some haphazard slaps of priority tape on its side. I opened at the top. Kind of indicates he had this dog sitting there and a new unopened boxed S3 and kept the good one shipping the dog. Right now the hashrate after 18hrs 17 minutes is 419.77GH/s, temps 38/39 while the good S3 from the mid-west sitting next to it has 441.88GH/s, temps 39/37. 441*.095=418.95 soy And the price with shipping was $511.48. And Amazon probably sees a record of a return to this seller. Amazon returns are honored, albeit less so if opened and the heatsinks removed. Swapping the questionable board from Florida into the good unit from the mid-west I notice that the good unit has two QC Passed stickers of different sizes/colors while the slow unit has a single QC Passed sticker large gold. |
|
|
|
So the problem S3 was down around 430GH/s this morning and I decided to go over its probably reworked board, the board that had grossly over-tightened screws, but would try frequency change first.
It had been down to 430 so I tried changing the frequency to check out its effect on hashrate. In /etc/config/asic-freq I changed to f=225, rebooted and restarted cgminer to get a fresh time duration. I gave it some time but it came up very slowly only to 420 or so. And it was a cool morning! All the other machines were hashing perfectly. So, I tried again, this time with f=212.5 but again it came up slow and only to 417GH/s. So, I ripped it apart again.
I was going to concentrate on its ASICs at the hot end of the reworked board, but ended up getting distracted. What distracted me was that the board had marking in black ink at the far right under the top ASIC (on this board that would be near the intake fan). Might have been Chinese or a code of some kind. So, I cleaned that ACIC and the one under it with a spray of automobile brake cleaner such that all thermal paste was removed. Must be careful with the stuff as it will mar many plastics. I sprayed those ASICs cleaning around the pins, reapplied thermal compound to both sides of the blade and reassembled. The brake cleaner removed the notation marks on that blade. When I reassembled, for a change, I put the bad board on the right side facing the RJ45 connector.
I started it up then ran to the store and back. Right now the 'difficult' S3, at a frequency of 218.75, after 1hr 20min, has an average hashrate of 443.74GH/s. The temps are both 40° with fan speeds of 2040/1800. Time will tell.
Bummer. Up now over 6hrs and the hashrate has started to drop off. Could be to an increase in humidity and that the first S3 hasn't seen a similar tailing off of hashrate because its average is over a 12hr period but probably not as it's at 442.24GH/s utility 17 while the problem S3 has tailed off to 437.63, utility 15. Experience tells me it will continue to fall and tomorrow morning may be down around 420GH/s. Temps are 40/39 and fans 1920/1620. The good S3 has 40/38 3180/1920 and the good and questionable S3's are side by side. What jumps out are the higher fan speeds of the good S3. Too bad. 1:30AM, checking the problem S3 and its hashrate has dropped to 429.01GH/s after 9hr 55min. Since I have two S3's, I could take what I think is the bad board and swap it into the other S3 and see if the good S3 then has a falling hashrate - just to make sure which board is bad. What's wrong with that is that the other S3, purchased from a reseller in the mid-west, runs fine (presently 441.67GH/s) while the problem S3 is from Florida (and that guy wants me to remove the 1 star Amazon rating, screw him, opened the bottom of a box from a good one and put the probably returned problem in and sent it out as new). By morning the problem S3 will likely be down to 420GH/s. Wonder if it's accumulating errors in an ASIC that then shuts down engines over time. Wonder if China sends more problem S3's to Florida than elsewhere given that Florida is a problem state like Shanghai crime before 1949. I'm not a happy camper. soy You are where many others have been 2 months ago. There are simply units like that and you probably wont be able to change it. And with 429 you cant complain, they were advertised with 441 +/- 5% if i remember correct. As soon as I removed a heatsink I felt I was burning bridges regarding any return. Hadn't noticed at that point that the box had been opened at the bottom, clear tape slit all around, then resealed probably with a single strip of clear tape along the center bottom leaving the slit sides showing it had been opened. Then, because I said I wanted USPS, priority mail tape went around the box at its center over the replaced tape on the bottom and some haphazard slaps of priority tape on its side. I opened at the top. Kind of indicates he had this dog sitting there and a new unopened boxed S3 and kept the good one shipping the dog. Right now the hashrate after 18hrs 17 minutes is 419.77GH/s, temps 38/39 while the good S3 from the mid-west sitting next to it has 441.88GH/s, temps 39/37. 441*.095=418.95 soy And the price with shipping was $511.48. |
|
|
|
|
Show Posts
