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. I use all 4 PCIE connections and gather the three conductors of each polarity to 16 gauge copper stranded good for 15 amps. Short a couple of connectors one time, I tried using only two PCIE and those conductors got warm. So, you're moving a lot of current. |
|
|
|
What's the minimum per fan CFM on a 2x fan setup?
I'm able to run at a frequency of 250M hashing almost 800GH/s with two old PSU fans. These fans can't be more than 20 CFM each. This thing seems stable just below 50 deg.
If you want to run it at default freq (350) you need minimum 200 cfm in my opinion. Something like 2 120 cfm fan using a push pull setup should work. Be sure to be below 60 on each blade. Just took a ruler to an Arctic Freezer i30 and the fan screw spacing looks good. I have two sitting here. I'll be moving one to my S5 unless someone can tell me why it would be a mistake. I see a few pages back someone suggested an Arctic Cooler fan but someone said it doesn't move enough air. So, putting a lower CFM fan as pull would degrade over no pull fan at all? Well, I see what I have to do. After I characterize my S3+'s, I'll characterize my S5 stock. I'll have determined my watt fraction per gigahash. I'll add the pull fan. I'll let it stabilize then characterize it again. The fan wattage will have been added. If the increased air flow has reduced errors and their associated energy cost sufficiently to decrease the watt fraction per gigahash then it's good. Of course this will have to be done on two days at the same time of day so the temps are the same. |
|
|
|
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 . You have power going to how many PCIE connectors? Using all 4? only 2? only 1? Plugged in closest to the RJ45 socket end? |
|
|
|
I tested underclocking-volting the C1.
The best setting was suggested by another user 2 weeks ago:
675/200 530W 803Mhs 0.66W/Mhs
760/250 790W 1008Mhs 0.783W/Mhs
FYI I have an EVGA 1300W gold.
Wish he had included F° & inHg. And is the supply on 120vac or 230vac? 120vac recorded at the wall with a kill-a-watt. It's 21-22C around the miner 32C in the miner web admin. It was 36C with the default setting. Just did this yesterday, kill-a-watt, 118vac, ambient 79.95°F, 29.52inHg, 250M/0760, 1002.88GH/s(avg) 819watts, 1.233GH/s/w .811w/GH/s. Then at ambient 77.9°F, 29.54inHg, 243.75M/0675, 982.76GH/s(avg) 792watts, 1.241GH/s/w .8059 w/GH/s. I'd decided to run my C1's at 243.75M/0675 to reduce the current away from max on that circuit. After I characterize my S3+'s I'll come back and look at 200M/0675 because that frequency agrees with best I found on an S3 but happened to be at the coolest point in the day. I'd appreciate your feedback when you get to 80°F ambient. I know these are less efficient power supplies and my initial application was at ½ full load capacity but with the C1's they at 56.9% of full capacity each. Running at 243.75M/0675 @ 79.9°F my hashboards read 35,38,36,38 & 981.12GH/s(avg). ~700 feet above sea level soy I had wondered once about an air mass flow sensor and if it would applicable here. But, the LM75A could generate data that would simulate an air mass flow sensor output. So, air flow ability to cool ASICs should determine fan speed. If fan speed is increased according to a formula calculated at sea level it would be less than optimal on a humid day or at higher altitudes. If the fan speed is determined by the LM75A state and increased to lower the LM75A output, then the air's mass is less a factor. I wonder which it is. |
|
|
|
What's the minimum per fan CFM on a 2x fan setup?
I'm able to run at a frequency of 250M hashing almost 800GH/s with two old PSU fans. These fans can't be more than 20 CFM each. This thing seems stable just below 50 deg.
If you want to run it at default freq (350) you need minimum 200 cfm in my opinion. Something like 2 120 cfm fan using a push pull setup should work. Be sure to be below 60 on each blade. Just took a ruler to an Arctic Freezer i30 and the fan screw spacing looks good. I have two sitting here. I'll be moving one to my S5 unless someone can tell me why it would be a mistake. I see a few pages back someone suggested an Arctic Cooler fan but someone said it doesn't move enough air. So, putting a lower CFM fan as pull would degrade over no pull fan at all? |
|
|
|
I tested underclocking-volting the C1.
The best setting was suggested by another user 2 weeks ago:
675/200 530W 803Mhs 0.66W/Mhs
760/250 790W 1008Mhs 0.783W/Mhs
FYI I have an EVGA 1300W gold.
Wish he had included F° & inHg. And is the supply on 120vac or 230vac? I'm jealous 'cause I don't get anywhere near that W/GH/s with my exceptionally cheap power supplies @ 250M/0760. |
|
|
|
.... 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. |
|
|
|
|
Summer coming. Adding a little water to the tank every day or two. Without the sharp cornered Syscooling and only the champer edge Syscooling in place no refilling necessary. So, tho there is no detectable leak a little water is going somewhere with the after market Syscooling pump in place. With summer in mind I bit the bullet and bought one of those large tall tank pumps but from China. No rush I figure.
|
|
|
|
|
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.
|
|
|
|
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. |
|
|
|
^^^ 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. |
|
|
|
^^^ 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. |
|
|
|
10-4, soy. I will post back if I have to try the reset.
I am moving my internet hard line into my home office tomorrow.
If I still can't locate the miner on 192.168.1.98 or 99 on my hardwired 192.168.1.1 router then I will reset.
I want to try to narrow this down before I re-boot the miner.
Thanks for all the replies!
I had to hard reset a few S3's and a C1 before and all it took is push the button, count to 10. Power off, push button again for 10 seconds, power off and after it comes back it's factory reset. Lucky you! Ah, if everything worked the way it should.... The reset button is a great tool if it works. I guess I have not used it as much as I should have, i resorted to flashing SD most of time with the C1. I do have a S3 controller that is a great doorstop it shows what happens if you lose power during firmware update. It was my fault so I take the blame on that happening. Try 90 seconds on that doorstop! Use an egg timer. |
|
|
|
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.jpgUnfortunately 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. |
|
|
|
10-4, soy. I will post back if I have to try the reset.
I am moving my internet hard line into my home office tomorrow.
If I still can't locate the miner on 192.168.1.98 or 99 on my hardwired 192.168.1.1 router then I will reset.
I want to try to narrow this down before I re-boot the miner.
Thanks for all the replies!
I had to hard reset a few S3's and a C1 before and all it took is push the button, count to 10. Power off, push button again for 10 seconds, power off and after it comes back it's factory reset. Lucky you! Ah, if everything worked the way it should.... |
|
|
|
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? |
|
|
|
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. |
|
|
|
|
Yes but I'm a retired technician and one does what one does.
|
|
|
|
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. |
|
|
|
Ahhh ... I was in the wrong forum earlier.
I have a miner that I cannot see on my network.
I see that I can use the reset button but it is a 90 second depression. Wow, no wonder it did't work for me.
After this reset, I will be able to access the miner at 192.168.1.99 ??
Would appreciate feedback on how that 90 second depression of the reset works out for you. Found out from Linksys routers but a full minute often works with them. Bet they get a lot of trashed routers because that long reset isn't described in many places. With the C1, I hear the fan spin down at around 40 seconds and if that's the completion of some cycle then another similar cycle brings it to 80 seconds so 90 is a safe bet and the period they describe for rebooting I think. |
|
|
|
|
Show Posts
