Author

Topic: ANTMINER S3+ Discussion and Support Thread - page 160. (Read 710164 times)

hero member
Activity: 924
Merit: 1000
September 27, 2014, 03:39:03 PM
Do the ants work on Nicehash/Westhash to be exact.  I'm sure this has been discussed before and my ant s3+ are running stock config.

Work for me.  Running both S1 and S3 on westhash ATM.  I would say accepted rate is very close to theoretical, or what is shown in antminers stats.
I'm getting like 15k discarded for every 1k per the antminer ui is this normal?  And after 15 min running my btc address doesn't show up in the stats list.  Again not running anything other than from the antminer itself.
full member
Activity: 174
Merit: 100
September 27, 2014, 03:09:12 PM
I have been upgrading my s1's to s3's

Does anyone have a plan for the old S1 Blades?

I have 16 blades to re-home, any ideas?

https://bitcointalksearch.org/topic/diy-reward-100-antminer-s1s3-blade-on-raspberry-pi-671128

Seems to be software problem, I tried to connect blades to minepeon/RasPi using USB dongle and they are recognized as AMU but hash at about 4GH/s.
hero member
Activity: 868
Merit: 1000
September 27, 2014, 03:03:34 PM
I have been upgrading my s1's to s3's

Does anyone have a plan for the old S1 Blades?

I have 16 blades to re-home, any ideas?
full member
Activity: 174
Merit: 100
September 27, 2014, 03:03:07 PM
Do the ants work on Nicehash/Westhash to be exact.  I'm sure this has been discussed before and my ant s3+ are running stock config.

Work for me.  Running both S1 and S3 on westhash ATM.  I would say accepted rate is very close to theoretical, or what is shown in antminers stats.
hero member
Activity: 924
Merit: 1000
September 27, 2014, 02:52:47 PM
I just received my 3 S3+. I have 2 corsair hx850 PSU's. Will they be enough to run all 3 at stock speeds and would their be any wiggle room to OC them a bit?
Yes. Mine pull 360w at the wall stock.  So 2 on a psu at stock speeds should be just fine and the other all by itself on the 2nd.
member
Activity: 103
Merit: 10
September 27, 2014, 02:51:04 PM
I just received my 3 S3+. I have 2 corsair hx850 PSU's. Will they be enough to run all 3 at stock speeds and would their be any wiggle room to OC them a bit?
hero member
Activity: 924
Merit: 1000
September 27, 2014, 02:39:51 PM
Do the ants work on Nicehash/Westhash to be exact.  I'm sure this has been discussed before and my ant s3+ are running stock config.
soy
legendary
Activity: 1428
Merit: 1013
September 27, 2014, 11:35:01 AM
I was just thinking, since the copper was exposed there and connection to one or the other of those 2 pins is iffy, any thru hole in that is likely questionable.  Then the thought came to me that those 2 pins might be common to one or the other rails.  There are 4 clear test points, two +12v and two ground.  When it's open I'll check.  If common to one or the other I might run a jumper to a TP from the two pins.

....
Those 2 pins, arrow and pin beneath, are common to the 12v rail.  The next 2 pins to the left seem to be common to ground.


....

Restart is poor, slowly rising from 430.  Right now I have no confidence in this fix and cannot recommend it.  Sorry.

....

The board that has dropping hashrate, it had grossly overtightened screws to the inside heatsink and new, somewhat excessive, heatsink compound.  The inside heatsink doesn't remove easily sometimes and the board can flex.  I wonder if someone flexed it enough to split the underside soldering of an ASIC to the ground plane so it doesn't sink heat properly.  

....

Got it done now all there's left to do is let them run.  Fast running fan blade paired with the dropping hashrate blade.  The fast running fan blade had an A and an A1 as did its partner on the cool side.  The troublesome S3 had no A board that I could see and the troublesome dropping hashrate board had an S and an o.    Rebooting the dropping hashrate board S3 today before the swap didn't result in an acceptable restart - taking too much time. 
soy
legendary
Activity: 1428
Merit: 1013
September 27, 2014, 10:43:01 AM
It was falling quickly.  Shut it down, opened it up, made a change, do believe I fixed it.  It's been up 1h39m now, will get back later with stats and the fix.  Up 4 hours and looking good.  If still good later tomorrow I'll post.


Okay, after 10h44m the hashrate is 440.08.  That's fixed.

When I inspected the questionable S3 hashing board that had cropped to well below 418 the day before, I found that board surface between the last two pins on the right of the ribbon connector rear had raised green material.  That's pin 1 with the arrow and the pin immediately below it which I had called pin 20 but is possibly pin 2 being the adjacent conductor.  Touching the green material it came away easily and flaked free showing oxidized copper beneath.  Those two pins are common on the hashing board but the corresponding pins on the controller board are not.  They tested common on the hashing board with the ribbon removed.  Still, since it showed minor heat damage, the green material flaking off and the copper discoloration, I put a soldering iron on the pins then fired it up.  It was not a fix and the hashrate dropped quicker than usual.  Shutting it down and taking the top off, those pins were easily accessible so I soldered a quick jumper between the two pins with #28 wirewrap wire and closed.  It's been running ever since.

So, if you have an S3 that has a dropping hashrate, e.g. down to below 418GH/s in a few days, check the area of those two pins on the questionable board and if it shows indication of having heated from high current, try the jumper.  I believe this is a good fix.


soy



could you post a picture of that area please, i do have the same problem with one of mine, and the problem S3 does have a higher temp diff between the 2 boards
+1
please post a picture!

I had been up early as I had to go out but posted first.  The 10h44m 440.08GH/s is now a 16hr10m 437.19GH/s so it is still falling but two days ago it would be down to 437 in 3hours not 10 hours.  So, clearly there's a big improvement but this isn't a comprehensive fix.

To see the area I needed a loupe.  The area in question is between the pin having the arrow on the 20 pin connector and the pin below it, this on the ASIC side of the board.  Because the area is 1/10" between the pins I am not able to produce an an accurate photo.  Take a magnifying glass and a tooth pick and try moving the green surface material.  If it had been heated enough to separate it from the copper beneath it, it will flake.  If not it will remain in place.


But since this didn't last as a fix and is just a good improvement,  I'll be opening it up again and will try to get a photo.  I'll be opening it up to swap out the right board looking at the RJ45 end because it has a normal fan speed and I have another machine with a board that runs its fan normally above 3000 (3180 at the moment).

When I was running the cgminer-avg-monitor app at the stock 439 and at the stock checking rate of every half hour,  it was triggering a restart every half hour because it didn't reattain a good hashrate and because the hashrate decline was so steep.  I'll run the program now and see how it responds post-jumper.
member
Activity: 194
Merit: 10
September 27, 2014, 10:09:42 AM
It was falling quickly.  Shut it down, opened it up, made a change, do believe I fixed it.  It's been up 1h39m now, will get back later with stats and the fix.  Up 4 hours and looking good.  If still good later tomorrow I'll post.


Okay, after 10h44m the hashrate is 440.08.  That's fixed.

When I inspected the questionable S3 hashing board that had cropped to well below 418 the day before, I found that board surface between the last two pins on the right of the ribbon connector rear had raised green material.  That's pin 1 with the arrow and the pin immediately below it which I had called pin 20 but is possibly pin 2 being the adjacent conductor.  Touching the green material it came away easily and flaked free showing oxidized copper beneath.  Those two pins are common on the hashing board but the corresponding pins on the controller board are not.  They tested common on the hashing board with the ribbon removed.  Still, since it showed minor heat damage, the green material flaking off and the copper discoloration, I put a soldering iron on the pins then fired it up.  It was not a fix and the hashrate dropped quicker than usual.  Shutting it down and taking the top off, those pins were easily accessible so I soldered a quick jumper between the two pins with #28 wirewrap wire and closed.  It's been running ever since.

So, if you have an S3 that has a dropping hashrate, e.g. down to below 418GH/s in a few days, check the area of those two pins on the questionable board and if it shows indication of having heated from high current, try the jumper.  I believe this is a good fix.


soy



could you post a picture of that area please, i do have the same problem with one of mine, and the problem S3 does have a higher temp diff between the 2 boards
+1
please post a picture!
legendary
Activity: 1358
Merit: 1002
September 27, 2014, 08:37:57 AM
It was falling quickly.  Shut it down, opened it up, made a change, do believe I fixed it.  It's been up 1h39m now, will get back later with stats and the fix.  Up 4 hours and looking good.  If still good later tomorrow I'll post.


Okay, after 10h44m the hashrate is 440.08.  That's fixed.

When I inspected the questionable S3 hashing board that had cropped to well below 418 the day before, I found that board surface between the last two pins on the right of the ribbon connector rear had raised green material.  That's pin 1 with the arrow and the pin immediately below it which I had called pin 20 but is possibly pin 2 being the adjacent conductor.  Touching the green material it came away easily and flaked free showing oxidized copper beneath.  Those two pins are common on the hashing board but the corresponding pins on the controller board are not.  They tested common on the hashing board with the ribbon removed.  Still, since it showed minor heat damage, the green material flaking off and the copper discoloration, I put a soldering iron on the pins then fired it up.  It was not a fix and the hashrate dropped quicker than usual.  Shutting it down and taking the top off, those pins were easily accessible so I soldered a quick jumper between the two pins with #28 wirewrap wire and closed.  It's been running ever since.

So, if you have an S3 that has a dropping hashrate, e.g. down to below 418GH/s in a few days, check the area of those two pins on the questionable board and if it shows indication of having heated from high current, try the jumper.  I believe this is a good fix.


soy



could you post a picture of that area please, i do have the same problem with one of mine, and the problem S3 does have a higher temp diff between the 2 boards
member
Activity: 98
Merit: 10
September 27, 2014, 05:58:17 AM

Okay, after 10h44m the hashrate is 440.08.  That's fixed.

When I inspected the questionable S3 hashing board that had cropped to well below 418 the day before, I found that board surface between the last two pins on the right of the ribbon connector rear had raised green material.  That's pin 1 with the arrow and the pin immediately below it which I had called pin 20 but is possibly pin 2 being the adjacent conductor.  Touching the green material it came away easily and flaked free showing oxidized copper beneath.  Those two pins are common on the hashing board but the corresponding pins on the controller board are not.  They tested common on the hashing board with the ribbon removed.  Still, since it showed minor heat damage, the green material flaking off and the copper discoloration, I put a soldering iron on the pins then fired it up.  It was not a fix and the hashrate dropped quicker than usual.  Shutting it down and taking the top off, those pins were easily accessible so I soldered a quick jumper between the two pins with #28 wirewrap wire and closed.  It's been running ever since.

So, if you have an S3 that has a dropping hashrate, e.g. down to below 418GH/s in a few days, check the area of those two pins on the questionable board and if it shows indication of having heated from high current, try the jumper.  I believe this is a good fix.


soy




Well sorted mate.  Hope that has fixed it for you.  If you have a chance, could you post a small pic of the area containing the pins?  Also, could you remind me, looking from the ethernet end, which hashing board relates to which row on the web interface, please?  
Mine has averaged 440.27 since the last reboot, 13 hours ago and the temperature is the same for each board at 43.  If it stayed at that speed, I'd be very pleased, but in the past it's always started drifting down again at some point.  From reading your post, I think that I need to watch the temperatures when that happens and see if the one board starts running cooler than the other, indicating the lower hash.  I hadn't thought of doing that before, so thank you. Smiley
hero member
Activity: 756
Merit: 500
September 27, 2014, 03:36:11 AM
Maybe I'm just really lucky but I have never had a single problem with anything I've bought from Bitmain.  3 S1s and 6 S3s.  I am a pretty lucky guy though  Wink
soy
legendary
Activity: 1428
Merit: 1013
September 26, 2014, 08:06:50 PM
The fans give a speed indication output.  I don't know what kind, digital or analog.  The fan speed is controlled by pulse width modulation.  I don't see a corresponding hashing board temperature and fan speed though one goes up so does the other.  If I saw three miners having a 40° board temperature and all three have the same speed, I'd say there was a digital feedback loop but this is not the case.  So, one might assume that there is a ramp or curve that says when the temperature is A the fan speed supply voltage will be X, temp B gets voltage Y and temp C gets voltage Z.  The speed indication just giving an indication of change versus temperature to the user.

The bad hashing board having a declining hashrate and a declining temperature might indicate the fault is elsewhere except that even after a cold start, after significant cooling time such that hashing starts over 442 and works its way down over hours, shows a lower temperature and fan speed early on.  If that slower fan speed causes errors away from the temperature sensor, those ASICs may shut down engines and slow hashrate but not quickly effect temperature indication.

So the slow fan speed relative to temperature should be addressed.  The problem may be in the pulsed width voltage supply line.  A partial open, high resistance, in a plated thru hole, e.g. dull drill bit left fiber in the hole, the hole only partly plated.  So, that's where I'll look first when I troubleshoot.  I'll follow the pulsed with fan voltage first, then the ground and perhaps the speed indication pair, looking for something amiss.  But not today.

Way overly optimistic without a schematic.  I shut it down and inspected.  Inspected and check grounds.  I'd have liked to trace the fan lines but the multilayered board precluded that and without a schematic that's that.  The only thing I found amiss is between pins 1 and 20 of the ribbon cable connection - the green covering had been lifted between the two pins as if those pins had carried quite a bit of current at one time and heated that area.  So no joy.

I would imagine that might happen if someone tried powering the S3 putting connectors to only the one side and the other side tried to hash with current across the controller board.

Started falling along regular lines.  My first S3, the good unit from the mid-west not Florida, has a hashing board that always runs at over 3k.  No unusual noise.  Wish I had a strobe tach.  My next course of action is to put the fast fan board on the warmer side of the bad S3.  So, although the bad board has a slow running fan there may be some compensation tho if it's not a cooling issue....


It was falling quickly.  Shut it down, opened it up, made a change, do believe I fixed it.  It's been up 1h39m now, will get back later with stats and the fix.  Up 4 hours and looking good.  If still good later tomorrow I'll post.
soy
legendary
Activity: 1428
Merit: 1013
September 26, 2014, 06:26:39 PM
The fans give a speed indication output.  I don't know what kind, digital or analog.  The fan speed is controlled by pulse width modulation.  I don't see a corresponding hashing board temperature and fan speed though one goes up so does the other.  If I saw three miners having a 40° board temperature and all three have the same speed, I'd say there was a digital feedback loop but this is not the case.  So, one might assume that there is a ramp or curve that says when the temperature is A the fan speed supply voltage will be X, temp B gets voltage Y and temp C gets voltage Z.  The speed indication just giving an indication of change versus temperature to the user.

The bad hashing board having a declining hashrate and a declining temperature might indicate the fault is elsewhere except that even after a cold start, after significant cooling time such that hashing starts over 442 and works its way down over hours, shows a lower temperature and fan speed early on.  If that slower fan speed causes errors away from the temperature sensor, those ASICs may shut down engines and slow hashrate but not quickly effect temperature indication.

So the slow fan speed relative to temperature should be addressed.  The problem may be in the pulsed width voltage supply line.  A partial open, high resistance, in a plated thru hole, e.g. dull drill bit left fiber in the hole, the hole only partly plated.  So, that's where I'll look first when I troubleshoot.  I'll follow the pulsed with fan voltage first, then the ground and perhaps the speed indication pair, looking for something amiss.  But not today.

Way overly optimistic without a schematic.  I shut it down and inspected.  Inspected and check grounds.  I'd have liked to trace the fan lines but the multilayered board precluded that and without a schematic that's that.  The only thing I found amiss is between pins 1 and 20 of the ribbon cable connection - the green covering had been lifted between the two pins as if those pins had carried quite a bit of current at one time and heated that area.  So no joy.

I would imagine that might happen if someone tried powering the S3 putting connectors to only the one side and the other side tried to hash with current across the controller board.

Started falling along regular lines.  My first S3, the good unit from the mid-west not Florida, has a hashing board that always runs at over 3k.  No unusual noise.  Wish I had a strobe tach.  My next course of action is to put the fast fan board on the warmer side of the bad S3.  So, although the bad board has a slow running fan there may be some compensation tho if it's not a cooling issue....
soy
legendary
Activity: 1428
Merit: 1013
September 26, 2014, 05:05:51 PM
Tried the suggestion of disconnecting PSU entirely (unplugged both sets of the 6 pins), still not working. Tried it with all 4 6-pin slots used (overclock), still not working. Went back to my original set up (one PSU, 2 sets of 6 pins like the working miner), restarted, and tried to ping it, no response to the ping (also my router doesn't note it like it does with the working miner)

Have you a linux machine, other than the miner, on the network?  First try nmap 192.168.1.* | more to see what is on the network.  The last line of the nmap output for antMiners will identify as Paragon Technologies or sometimes as Unknown.   If nmap doesn't find it and your subnet is something other than 192.168.1.0, then try running tcpdump and watching the traffic looking for an out-of-subnet IP transmitting.
member
Activity: 98
Merit: 10
September 26, 2014, 04:31:04 PM
Ah, my problem S3 has been running 1d 16h and has slowed to 418.15.  Three hours ago it was 418.80.

I have been in an acrimonious email exchange with the reseller.  So, for me to ask him to submit the slow hashing blade for exchange would beg an extended delay.  To request an exchange from Bitmain would probably be met by an instruction to return the slow hashing board to the reseller.

I'm not certain it would be in my interest to return the hashing board.  If Bitmain would accept the board directly what is the estimated turn around time?  What is the estimated shipping from the US?  Answers to these questions would help inform my decision how to proceed.  Thanks.

soy


I realise that you may have tried this, but one of my S3s is similar to yours and gets slower and slower, eventually ending up in the 300s, so when I can see that its average is going down towards 420 again, I reboot it.  On the first or second reboot, it starts hashing at around 460 or more, with good speed for hours until it gradually starts sinking again over the next day or so.  With this method, I keep it averaging 440 for most of the time, which I can't complain about.  Sorry if you already tried and discounted this!  Smiley

Yes, a cold boot restores relatively normal hashrates but there is a continual decline.  I'm hoping it will settle out at a hashrate that is a stable floor.  I had tried anticipating when it would hit 5% less than 441, knowing that end point, 418.5, if the plot tracked a capacitor charging track a single timeconstant predicted five timeconstants would have expired this afternoon.  It finished early because the cold boot was late afternoon and much of that first timeconstant the S3 was in a cooler environment so the prediction was long.

Does either of your fan speeds seem slow relative to temperature?

Rebooting will restore the hashing for a while I suppose and cost less than a return.  

My fan speeds are ok relative to temperature.  However, my temp is 1 to 2 deg higher than standard, because I don't use the original fans; the units are in my office and I couldn't stand the noise.  I think that rebooting has been the best strategy for me and as you say, it's cheaper than a return, with the delay associated with that, although I suppose that if you got a really good one back...  but who knows?  I'm just going to carry on rebooting mine.  Smiley
hero member
Activity: 569
Merit: 500
September 26, 2014, 04:24:32 PM
can someone explain this to me? What is wrong with this picture? I am running the latest image.... Fans even hitting 12,400 RPM, pretty soon my S3 is going to be flying around the room!



I have one where the fan speed is reporting as way too high seeing how these fans max out at 3000 rpm. I just ignore it because sound comparisons are telling me the fan is not spinning that fast and is in fact spinning at the proper speeds....

It would be nice to see why they are reporting this. I would swap out some other fans and see if its a faulty fan sense but logic dictates its a software problem because if the fan was actually reporting that speed the s3 would NEVER adjust it higher when it gets hotter and I hear the faulty reading s3 changing its fans speeds when it gets a little hotter....

Side note on your pictures.... 50C 51C?? wow you running those way too hot...
the ones I have sitting just out in the open not in a server room are at 42c/40c. u live in a bakery?

Yes, I want them to run hot because I make eggs in the morning on pan on top of the miner, and cookies in the evenings Wink I run these in my office, I have 17 of them plus other miners in a room with just one 6" vent. The degrees is about 95-100F, and there hasn't been any problems. Chips don't need to be that cold, they just need air over them to run. All the miners have been running fine, its just these funky readings and the fans do move faster, but I don't think they are REALLY going 12,000 RPM or they would be extremely loud.



are they all at 50C? the max speed on these is 3000rpm.
The real reason I cant be bothered with swapping a fan is I dont feel like taking those metal cages off and I think removing them requires you to unplug the power.  where if they were sitting out in the open I would try another fan asap! like the upgrade kit ones I did...
I tested a fan on one of those cuz the 2nd boards show no fans at all...
soy
legendary
Activity: 1428
Merit: 1013
September 26, 2014, 03:44:25 PM
The fans give a speed indication output.  I don't know what kind, digital or analog.  The fan speed is controlled by pulse width modulation.  I don't see a corresponding hashing board temperature and fan speed though one goes up so does the other.  If I saw three miners having a 40° board temperature and all three have the same speed, I'd say there was a digital feedback loop but this is not the case.  So, one might assume that there is a ramp or curve that says when the temperature is A the fan speed supply voltage will be X, temp B gets voltage Y and temp C gets voltage Z.  The speed indication just giving an indication of change versus temperature to the user.

The bad hashing board having a declining hashrate and a declining temperature might indicate the fault is elsewhere except that even after a cold start, after significant cooling time such that hashing starts over 442 and works its way down over hours, shows a lower temperature and fan speed early on.  If that slower fan speed causes errors away from the temperature sensor, those ASICs may shut down engines and slow hashrate but not quickly effect temperature indication.

So the slow fan speed relative to temperature should be addressed.  The problem may be in the pulsed width voltage supply line.  A partial open, high resistance, in a plated thru hole, e.g. dull drill bit left fiber in the hole, the hole only partly plated.  So, that's where I'll look first when I troubleshoot.  I'll follow the pulsed with fan voltage first, then the ground and perhaps the speed indication pair, looking for something amiss.  But not today.

Way overly optimistic without a schematic.  I shut it down and inspected.  Inspected and check grounds.  I'd have liked to trace the fan lines but the multilayered board precluded that and without a schematic that's that.  The only thing I found amiss is between pins 1 and 20 of the ribbon cable connection - the green covering had been lifted between the two pins as if those pins had carried quite a bit of current at one time and heated that area.  So no joy.

I would imagine that might happen if someone tried powering the S3 putting connectors to only the one side and the other side tried to hash with current across the controller board.
newbie
Activity: 4
Merit: 0
September 26, 2014, 03:23:05 PM
I was directed here as maybe a quick fix for a problem. Please point me elsewhere if appropriate.

Just set up two s3 b9's with identical PSU's and ran fine for 4 days till I needed to change one of the configuration settings on both devices.

I changed the setting (password field for the first pool, actually getting used as a hashing control for a lower limit of payout acceptable) and then clicked the "Save&Apply". I monitored for a while and just got to wondering "did the setting actually take effect properly" as things didn't seem kosher, so I used the reboot option from the web page on both devices.

On reboot one would not display a good status LED (although the NIC LED's look good). Both the red and green LED's are dark, not even brief flashing (even though they did light till the NIC cycled). If I try to access it with the browser I get the initial page "LuCI - Lua Configuration Interface" but the auto link to the status overview eventually times out. It also doesn't generate heat (I have them side by side and there is a big difference in heat output between the working one and the failing one)

I tried leaving the failing one off for 20 minutes or so. That didn't help. I then swapped the PSU's on the theory that there wasn't enough electrical output on one PSU. That made no difference, working one with the other PSU still worked, failing one with the "working" PSU still failed.

Thoughts on what I could try that won't make it so I can't return it?

For those with S3's acting up, try to go back to the original image. Or, if its slow, try the S3+ firmware. These are nice miners, but they are not consistent. In order to get all miners going, either go backwards or forwards with the firmware. Just my 2 cents for you to try. Have you tried the S3+ firmware yet?
Given the length of time since purchase, I'm hesitant. Like I said. I'd rather not do something that makes it impossible to return. If I brick it, then I'm stuck. I'll wait and see what others have to say that might help and are less drastic. (An additional diagnostic that is more information would be great, even if the diagnostic really does then point at a firmware upgrade. I'd then be willing to go there.)

I doubt you will brick it, I have done many S3+ compatible firmware update, and I also went backwards. No issues. Email tech support, and if they ask if you should upgrade it, that way you can say you were just following their instructions.  I think there was a security issue with the original firmware.

I just tried an SSH access and the one device just times out the connection, the working one lets me log on as root. I think it's interesting that the first LuCI page comes up even though other pages and SSH don't work. At this point, without better diagnostics, I'd be inclined to let bitmain tell me what to do.

Trouble is that the downed miner won't bring up the HTTP interface, so there is no possibility at installing different firmware. Anyone know how to reset the device? We've tried the instructions for reset shown here, but no joy.

Can you ping it? If so try another browser? Default should be 192.168.1.99.


I've noticed that if I ssh into an S3 and command halt, unless I cold boot I can't get in.  The device will acknowledge a ping but port 80 seems closed.  And the halt command stops the cgminer-monitor so it doesn't restart at otherwise 3 minutes most.

Tried the suggestion of disconnecting PSU entirely (unplugged both sets of the 6 pins), still not working. Tried it with all 4 6-pin slots used (overclock), still not working. Went back to my original set up (one PSU, 2 sets of 6 pins like the working miner), restarted, and tried to ping it, no response to the ping (also my router doesn't note it like it does with the working miner)
Jump to: