Air intake is from the front (PSU/Ethernet port side) THere are 4 fan connectors on the control PCB!  Always the policy is any modification of the unit will void the warranty... side note, reversing the fans should not do any damage. 2 fans to intake and 2 fans to suck them out of the box. Bitmain,
I assume air intake is on the front of the unit, where you plug the PSU? Is it OK to reverse the airflow by switching all 4 fans around? I need the front to be the exhaust side.
I was hoping it wouldn't void the warranty since it's such a minor thing. Bitmain had us switching PSUs and fans constantly with the S4, even hash board occasionally. Surely just reversing the fans should be allowable without voiding the warranty? I could be missing something but why not just turn entire unit around, instead of reversing fans? He needs the power plug to be in a certain position. I am assuming that all other power plugs on all his gear are the outake side. In my case it's mostly about having airflow where it needs to go while still having access to the front of the units. This pic will give you an idea with some of the rigs:  Wouldn't want all that hot air stagnating in back of them, exhaust needs to come out of the front where it's then extracted via a large fan to the exterior. |
|
|
|
Air intake is from the front (PSU/Ethernet port side) THere are 4 fan connectors on the control PCB! Always the policy is any modification of the unit will void the warranty... side note, reversing the fans should not do any damage. 2 fans to intake and 2 fans to suck them out of the box. Bitmain,
I assume air intake is on the front of the unit, where you plug the PSU? Is it OK to reverse the airflow by switching all 4 fans around? I need the front to be the exhaust side.
I was hoping it wouldn't void the warranty since it's such a minor thing. Bitmain had us switching PSUs and fans constantly with the S4, even hash board occasionally. Surely just reversing the fans should be allowable without voiding the warranty? I could be missing something but why not just turn entire unit around, instead of reversing fans? Yeah, that's the more logical thing to do. With the S4s I reversed the fans so I could still see the LCD screen, but there's no screen this time around. |
|
|
|
Air intake is from the front (PSU/Ethernet port side) THere are 4 fan connectors on the control PCB! Always the policy is any modification of the unit will void the warranty... side note, reversing the fans should not do any damage. 2 fans to intake and 2 fans to suck them out of the box. Bitmain,
I assume air intake is on the front of the unit, where you plug the PSU? Is it OK to reverse the airflow by switching all 4 fans around? I need the front to be the exhaust side.
I was hoping it wouldn't void the warranty since it's such a minor thing. Bitmain had us switching PSUs and fans constantly with the S4, even hash board occasionally. Surely just reversing the fans should be allowable without voiding the warranty? |
|
|
|
|
Bitmain,
I assume air intake is on the front of the unit, where you plug the PSU? Is it OK to reverse the airflow by switching all 4 fans around? I need the front to be the exhaust side.
|
|
|
|
Outside of the slightly (marginally) better power consumption, what's the point of this product? You can reach 2.5 TH/s with a regular S4 at half the price and without need for 210 volt power. I have to say that I don't understand at all why they spent the time to even design this miner.
That's simply not true. An S4 at 2500gh/s steady average will be consuming more than a 20A 120V circuit can handle. Half the price? Are you factoring in the 2x ~200$ power supplies you'll need to pull that off? (assuming you're original psu is dead since it likely is or will be in short order ) |
|
|
|
|
So I sold 2 S4s today locally for a very good price, and ordered 2 S4+ to replace them with. Very cheap upgrade after selling them.
Placed the order this morning, and I just got shipping notification. If there's something bitmain can't be faulted for, it's shipping on or ahead of time.
I never got an S5 or had much interest in it, so I can't say I know anything about these string setups for chips vs dc2dc. Is there a good explanation anywhere? I'd like to understand how the S4+ runs at the same frequency as the S4 (200Mhz) with 44 extra chips and manages to consume approximately the same wattage.
|
|
|
|
Cool, thanks. How stable are they? Do they need to be babysat?
More likely in the 3.5TH range, with overclocking. Unless you live in the arctic, the Bonus Neps like to overheat/shutdown due to KnC not including thermal pads. You'll want to install good heatsinks, or upgrade the fans, or both, depending on how much you want to spend. (listed in order of cheapest to pricey) Once you get them running, they tend to stay running fairly well. They can lock up every once in a while though. Cool, thanks. Has anyone sourced replacement thermal pads? Fucking KNC. |
|
|
|
Guys, how are the bonus Neptunes performing? I might be picking one up used today, want to know what I should expect.
3615 ghash. Cool, thanks. How stable are they? Do they need to be babysat? |
|
|
|
|
Guys, how are the bonus Neptunes performing? I might be picking one up used today, want to know what I should expect.
|
|
|
|
|
Bitmain, any chance you'll release an upgrade kit for existing S4s? Those of us that are using upgraded PSUs could easily swap the old board with the new ones.
|
|
|
|
If someone could point me in the right direction I'd appreciate it. I have a 4 S4's. Today one of then just stopped hashing. It still runs but just not doing any work, says o ghs on the led. I restart it and it gets up close to the 2TH and then slowly(over 10 mins) goes to 0 again. I updated the firmware, same thing happened. I leave these at work so its a pain in the ass to go there 3 times on a Saturday to reset them. I just got back the final time and as soon as I get home it say zero again. Please and thanks. Is this a symptom that I need a new PSU or is there something wrong with the miner. Thanks again
Try a new SD card with a new image flashed to it. |
|
|
|
Didnt realize people are using fiber for mining!
Bump for wondering how much bandwith a s5 uses in a day?
They aren't, a 10/100 switch is more than enough for mining. |
|
|
|
Which of those two PSUs you mentioned are the cheaper solution if you combine PSU + Board + cables?
If you only have 1 S4, probably the DP2000. If you have 2 S4s, you can run both of them off of 1 2880w. Either way, I'd probably go with the 2880w. |
|
|
|
Forget about undervolting, bitmain has disabled voltage control starting with firmware released on Jan 29th. If you want to undervolt and underclock, you'll have to use firmware from Oct. 16th.
The S4 should run on either 120v or 240v. You shouldn't be blowing fuses.
Hey do you know of any good mods that out for this. I know that nicehash has cgminer 4.9 available. I heard of a fan mod but seems dangerous and do know why people would want to lower fan speed would be nice to increase it to keep it cooler. A quiter fan would be nice but not at the cost of heat ruining the unit. The best mod you can do on the S4 is replacing the PSU which is a ticking time bomb, 4 out of 7 of mine failed, and the only reason I still have 3 working PSUs is because I pulled them and replaced them with proper server grade PSUS before they died. (IBM DPS2000 [2000w] and IBM H-2880 [2880w]) The fan mod isn't dangerous IMO, and bitmain adding the feature officially (via --bitmain-homemode toggle) seems to support that. If you don't care about noise, then no need to run that way except perhaps to prolong fan life. Yes, the fans fail often also. I brought 2x S4s into my house to run in the basement to provide heat during the past winter, and slowing the fans down made that possible in my case. Don't think my woman would have tolerated the noise else-wise. You aren;t actually slowing the fans down, rather pushing back the temperature at which they ramp up. Seems to cause a ~5c increase in temps, which is fine and a good tradeoff IMO. I was looking into the two psu's you recommended. (IBM DPS2000 [2000w] and IBM H-2880 [2880w]) niether of them see would be a perfect fit and the connections dont seem similar can you provide a link and if it needs new wires can you provide a link for that too. No, they won't fit inside the S4. I don't know of any PSU that would be the same form factor as the original. You'd need to run them externally and route the wires in where the old PSU was, you need wires that are 36" long. For the DPS2000, look up sidehack's breakout board + wires. For the 2880w, look up Finksy & J4bberwock's breakout board + cables. |
|
|
|
I'd take the SP20E, never bought directly from Spondoolies. Only picked up second hand SP20Es, would like a fresh one.  |
|
|
|
OK, thank you. Out of curiosity, what is your SPM target set to? |
|
|
|
And why do my slower rigs get hit with such high diff?  They are all asking for 8192 (except proxy which doesn't ever get the 32768 I'm asking for). The 60MH rig is especially prone to getting diff way too high as can be seen @ 131072.0000. |
|
|
|
Is there no way to force the difficulty setting? I received an Alcheminer 256MH/s today, and it needs 50000+ diff to work properly. Setting d=50000 (or any difficulty on any rig, really) on nice/westhash only starts the difficulty at that diff, then it gets adjusted up or down by the server. What's the point of being able to specify a difficulty if in reality it will get set automatically by vardif?
There is Suppose to be a setting even on N/W hash that disables vardif , i remember reading it one time under the tips for miner link at the bottom of any page on W/NHash. If they still allow it not sure and you may have use a proxy thu them if it won't connect  . I agree if you set it at a set #, i would think it won't go below that DIFF, but it still does even my script miner that needs 4096 dif to run at top speed, drops as it adjusts. Hmm, looks like I'll have to dig. Thanks for the tip. Difficulty should be handled this way: No lower than user's set difficulty but can increase if set too low. Unfortunately, our buyers still use low diff pools and some low diff coins require low pool diff. That is why we cannot keep high diffs (we want them, too, they put less load on our servers). The main mistake is on ASIC hardware producers. They save 30 cents off each machine and buy slower controllers. As a result, ASICs are always only guaranteed to work fine with Bitcoin or Litecoin mining, where diff is very high, but altcoins can have very low diffs, resulting in many shares that controllers are incapable of processing fast enough. And without altcoins, there is no point in existance of renting services. Thanks for the reply. I don't see the issue with users who need low diff. What we're asking for is when we set diff manually (for example 16384) that it actually gets set to 16384 and doesn't go lower. Doesn't matter if your server decides to assign higher than 16384, the ASICs can handle that. What needs to happen is when a diff is set using d=xxxxx, the server only sends xxxxx diff shares or higher. Right now, I've got the rig set to d=32768, and it starts at 16384 for some reason and then drops as low as 512 which totally kills the ASIC because it can't handle such low diff work. The way I understand it is that your difficulty option is broken. Fixing it to the way I'm describing would not affect low diff users, they could still set d=512 or let vardiff adjust it by not specifying a d=xxx parameter. The diff problem affects all my ASICs: S4, SP20, A2 Terminator, Titan, and Alcheminer 256MH. I've never bothered bringing the issue up since all of them can deal with the low diff shares, but the Achemist totally craps its self with low diff. Makes it unusable on nicehash, but when the diff does manage to stay high it works just fine. I hope I described the problem well enough, and I hope you can fix your code to lock in a specified difficulty when set by the user. Oh, I agree with manufacturers being ridiculous with the underpowered controllers. The Alchemist miner never sees above ~35% CPU usage though. As I explained before, if buyer uses pool that has diff 512, we cannot make miners have higher diff. If we did, then buyer would get much less "speed" at the target pool. If buyer uses high diff pool, we can make miners use low diffs - we filter out low diff shares and send only high diff shares to the pool. Vice verse we cannot do, because our stratum proxy cannot create new shares out of high diff shares. Ahhhhh, I see. I misunderstood what you were saying. In this example, from top to bottom: A2 90, A2 60, Titan, Achemist  The pool is sending work from different "jobs" to each miner, which is why they don't have the same diff? If I were to run them all through the proxy, they would all get the same diff work since they'd all be seen as 1 unit? Thanks Proxifying will not help. If buyer has low diff pool or mines low diff coin, there is nothing you can do but to press your ASIC provider to give you better software/firmware (if anything can be improved with new software at all). I understand that, what I meant was if I were to run all the rigs through a proxy they should all get the same diff (low or high) since they'd be seen as one available rig to your servers, correct? |
|
|
|
Is there no way to force the difficulty setting? I received an Alcheminer 256MH/s today, and it needs 50000+ diff to work properly. Setting d=50000 (or any difficulty on any rig, really) on nice/westhash only starts the difficulty at that diff, then it gets adjusted up or down by the server. What's the point of being able to specify a difficulty if in reality it will get set automatically by vardif?
There is Suppose to be a setting even on N/W hash that disables vardif , i remember reading it one time under the tips for miner link at the bottom of any page on W/NHash. If they still allow it not sure and you may have use a proxy thu them if it won't connect . I agree if you set it at a set #, i would think it won't go below that DIFF, but it still does even my script miner that needs 4096 dif to run at top speed, drops as it adjusts. Hmm, looks like I'll have to dig. Thanks for the tip. Difficulty should be handled this way: No lower than user's set difficulty but can increase if set too low. Unfortunately, our buyers still use low diff pools and some low diff coins require low pool diff. That is why we cannot keep high diffs (we want them, too, they put less load on our servers). The main mistake is on ASIC hardware producers. They save 30 cents off each machine and buy slower controllers. As a result, ASICs are always only guaranteed to work fine with Bitcoin or Litecoin mining, where diff is very high, but altcoins can have very low diffs, resulting in many shares that controllers are incapable of processing fast enough. And without altcoins, there is no point in existance of renting services. Thanks for the reply. I don't see the issue with users who need low diff. What we're asking for is when we set diff manually (for example 16384) that it actually gets set to 16384 and doesn't go lower. Doesn't matter if your server decides to assign higher than 16384, the ASICs can handle that. What needs to happen is when a diff is set using d=xxxxx, the server only sends xxxxx diff shares or higher. Right now, I've got the rig set to d=32768, and it starts at 16384 for some reason and then drops as low as 512 which totally kills the ASIC because it can't handle such low diff work. The way I understand it is that your difficulty option is broken. Fixing it to the way I'm describing would not affect low diff users, they could still set d=512 or let vardiff adjust it by not specifying a d=xxx parameter. The diff problem affects all my ASICs: S4, SP20, A2 Terminator, Titan, and Alcheminer 256MH. I've never bothered bringing the issue up since all of them can deal with the low diff shares, but the Achemist totally craps its self with low diff. Makes it unusable on nicehash, but when the diff does manage to stay high it works just fine. I hope I described the problem well enough, and I hope you can fix your code to lock in a specified difficulty when set by the user. Oh, I agree with manufacturers being ridiculous with the underpowered controllers. The Alchemist miner never sees above ~35% CPU usage though. As I explained before, if buyer uses pool that has diff 512, we cannot make miners have higher diff. If we did, then buyer would get much less "speed" at the target pool. If buyer uses high diff pool, we can make miners use low diffs - we filter out low diff shares and send only high diff shares to the pool. Vice verse we cannot do, because our stratum proxy cannot create new shares out of high diff shares. Ahhhhh, I see. I misunderstood what you were saying. In this example, from top to bottom: A2 90, A2 60, Titan, Achemist The pool is sending work from different "jobs" to each miner, which is why they don't have the same diff? If I were to run them all through the proxy, they would all get the same diff work since they'd all be seen as 1 unit? Thanks |
|
|
|
Is there no way to force the difficulty setting? I received an Alcheminer 256MH/s today, and it needs 50000+ diff to work properly. Setting d=50000 (or any difficulty on any rig, really) on nice/westhash only starts the difficulty at that diff, then it gets adjusted up or down by the server. What's the point of being able to specify a difficulty if in reality it will get set automatically by vardif?
There is Suppose to be a setting even on N/W hash that disables vardif , i remember reading it one time under the tips for miner link at the bottom of any page on W/NHash. If they still allow it not sure and you may have use a proxy thu them if it won't connect . I agree if you set it at a set #, i would think it won't go below that DIFF, but it still does even my script miner that needs 4096 dif to run at top speed, drops as it adjusts. Hmm, looks like I'll have to dig. Thanks for the tip. Difficulty should be handled this way: No lower than user's set difficulty but can increase if set too low. Unfortunately, our buyers still use low diff pools and some low diff coins require low pool diff. That is why we cannot keep high diffs (we want them, too, they put less load on our servers). The main mistake is on ASIC hardware producers. They save 30 cents off each machine and buy slower controllers. As a result, ASICs are always only guaranteed to work fine with Bitcoin or Litecoin mining, where diff is very high, but altcoins can have very low diffs, resulting in many shares that controllers are incapable of processing fast enough. And without altcoins, there is no point in existance of renting services. Thanks for the reply. I don't see the issue with users who need low diff. What we're asking for is when we set diff manually (for example 16384) that it actually gets set to 16384 and doesn't go lower. Doesn't matter if your server decides to assign higher than 16384, the ASICs can handle that. What needs to happen is when a diff is set using d=xxxxx, the server only sends xxxxx diff shares or higher. Right now, I've got the rig set to d=32768, and it starts at 16384 for some reason and then drops as low as 512 which totally kills the ASIC because it can't handle such low diff work. The way I understand it is that your difficulty option is broken. Fixing it to the way I'm describing would not affect low diff users, they could still set d=512 or let vardiff adjust it by not specifying a d=xxx parameter. The diff problem affects all my ASICs: S4, SP20, A2 Terminator, Titan, and Alcheminer 256MH. I've never bothered bringing the issue up since all of them can deal with the low diff shares, but the Achemist totally craps its self with low diff. Makes it unusable on nicehash, but when the diff does manage to stay high it works just fine. I hope I described the problem well enough, and I hope you can fix your code to lock in a specified difficulty when set by the user. Oh, I agree with manufacturers being ridiculous with the underpowered controllers. The Alchemist miner never sees above ~35% CPU usage though. |
|
|
|
|
Show Posts
