Author

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

full member
Activity: 166
Merit: 100
After the latest firmware update, one of my chips started showing '-'.

oooooooo ooooooo-
oooooooo oooooooo

It is not even an 'x', which confuses me. Anyone has any idea what this means?

I had that problem and the only way for me to fix it was to power off the unit and then back on. After that it went away.
full member
Activity: 168
Merit: 100
After the latest firmware update, one of my chips started showing '-'.

oooooooo ooooooo-
oooooooo oooooooo

It is not even an 'x', which confuses me. Anyone has any idea what this means?
newbie
Activity: 41
Merit: 0
I have a question about the stratum difficulty.  I have two Antminer S3s, and I'm using the GHash.IO mining pool.  Their FAQ says:
Quote
The optimal settings of the stratum difficulty depends on your hash-rate:
16+ GH/s - 16 difficulty
32+ Gh/s - 32 difficulty
64+ GH/s - 64 difficulty
128+ GH/s - 128 difficulty
256+ GH/s - 256 difficulty
512+ GH/s - 512 difficulty
1 TH/s - 1024 difficulty

So based on that, the setting would be 256 for each miner.  Does anyone actually alter this setting in their mining pool?  Or do you just keep the default setting?

thank you.
I don't think it's for each miner (unless you have them as different workers). If they're set as one worker, then set it to 512 (or 1TH if you can get it stable over 1000 GH/s). If they're separate workers then yea, 256 should be fine.

But Yes it works in every pool I've tried (4 or 5 different pools)

They are set up with different worker IDs.  I thought that was required.  I didn't know I could have two miners in the same pool with the same worker ID.  Does that work?  Is there an advantage to doing that?

No... It's hard to see/track your individual S3's performance...

I'm using separate workers for each of mine S3's ...256 diff... Grin

ZiG

But Yes it works in every pool I've tried (4 or 5 different pools)
newbie
Activity: 41
Merit: 0
I have a question about the stratum difficulty.  I have two Antminer S3s, and I'm using the GHash.IO mining pool.  Their FAQ says:
Quote
The optimal settings of the stratum difficulty depends on your hash-rate:
16+ GH/s - 16 difficulty
32+ Gh/s - 32 difficulty
64+ GH/s - 64 difficulty
128+ GH/s - 128 difficulty
256+ GH/s - 256 difficulty
512+ GH/s - 512 difficulty
1 TH/s - 1024 difficulty

So based on that, the setting would be 256 for each miner.  Does anyone actually alter this setting in their mining pool?  Or do you just keep the default setting?

thank you.
I don't think it's for each miner (unless you have them as different workers). If they're set as one worker, then set it to 512 (or 1TH if you can get it stable over 1000 GH/s). If they're separate workers then yea, 256 should be fine.

But Yes it works in every pool I've tried (4 or 5 different pools)

They are set up with different worker IDs.  I thought that was required.  I didn't know I could have two miners in the same pool with the same worker ID.  Does that work?  Is there an advantage to doing that?

No... It's hard to see/track your individual S3's performance...

I'm using separate workers for each of mine S3's ...256 diff... Grin

ZiG
ZiG
sr. member
Activity: 406
Merit: 250
I have a question about the stratum difficulty.  I have two Antminer S3s, and I'm using the GHash.IO mining pool.  Their FAQ says:
Quote
The optimal settings of the stratum difficulty depends on your hash-rate:
16+ GH/s - 16 difficulty
32+ Gh/s - 32 difficulty
64+ GH/s - 64 difficulty
128+ GH/s - 128 difficulty
256+ GH/s - 256 difficulty
512+ GH/s - 512 difficulty
1 TH/s - 1024 difficulty

So based on that, the setting would be 256 for each miner.  Does anyone actually alter this setting in their mining pool?  Or do you just keep the default setting?

thank you.
I don't think it's for each miner (unless you have them as different workers). If they're set as one worker, then set it to 512 (or 1TH if you can get it stable over 1000 GH/s). If they're separate workers then yea, 256 should be fine.

They are set up with different worker IDs.  I thought that was required.  I didn't know I could have two miners in the same pool with the same worker ID.  Does that work?  Is there an advantage to doing that?

No... It's hard to see/track your individual S3's performance...

I'm using separate workers for each of mine S3's ...256 diff... Grin

ZiG
newbie
Activity: 23
Merit: 0
I have a question about the stratum difficulty.  I have two Antminer S3s, and I'm using the GHash.IO mining pool.  Their FAQ says:
Quote
The optimal settings of the stratum difficulty depends on your hash-rate:
16+ GH/s - 16 difficulty
32+ Gh/s - 32 difficulty
64+ GH/s - 64 difficulty
128+ GH/s - 128 difficulty
256+ GH/s - 256 difficulty
512+ GH/s - 512 difficulty
1 TH/s - 1024 difficulty

So based on that, the setting would be 256 for each miner.  Does anyone actually alter this setting in their mining pool?  Or do you just keep the default setting?

thank you.
I don't think it's for each miner (unless you have them as different workers). If they're set as one worker, then set it to 512 (or 1TH if you can get it stable over 1000 GH/s). If they're separate workers then yea, 256 should be fine.

They are set up with different worker IDs.  I thought that was required.  I didn't know I could have two miners in the same pool with the same worker ID.  Does that work?  Is there an advantage to doing that?
sr. member
Activity: 280
Merit: 250
How do i set the difficulty?? My 1 miner ist set to 1000 ....
newbie
Activity: 9
Merit: 0
I have a question about the stratum difficulty.  I have two Antminer S3s, and I'm using the GHash.IO mining pool.  Their FAQ says:
Quote
The optimal settings of the stratum difficulty depends on your hash-rate:
16+ GH/s - 16 difficulty
32+ Gh/s - 32 difficulty
64+ GH/s - 64 difficulty
128+ GH/s - 128 difficulty
256+ GH/s - 256 difficulty
512+ GH/s - 512 difficulty
1 TH/s - 1024 difficulty

So based on that, the setting would be 256 for each miner.  Does anyone actually alter this setting in their mining pool?  Or do you just keep the default setting?

thank you.
I don't think it's for each miner (unless you have them as different workers). If they're set as one worker, then set it to 512 (or 1TH if you can get it stable over 1000 GH/s). If they're separate workers then yea, 256 should be fine.
newbie
Activity: 23
Merit: 0
I have a question about the stratum difficulty.  I have two Antminer S3s, and I'm using the GHash.IO mining pool.  Their FAQ says:
Quote
The optimal settings of the stratum difficulty depends on your hash-rate:
16+ GH/s - 16 difficulty
32+ Gh/s - 32 difficulty
64+ GH/s - 64 difficulty
128+ GH/s - 128 difficulty
256+ GH/s - 256 difficulty
512+ GH/s - 512 difficulty
1 TH/s - 1024 difficulty

So based on that, the setting would be 256 for each miner.  Does anyone actually alter this setting in their mining pool?  Or do you just keep the default setting?

thank you.
hero member
Activity: 686
Merit: 500
WANTED: Active dev to fix & re-write p2pool in C
Regarding Bitmain's lack of compliance with the GPL, my guess is that has more to do with lack of resources, messed up priorities, or just plain incompetence. I doubt there's any sinister intent on their part.

That having been said, they must make the time to comply with the licensing and make the source code available. No question.

Maybe they would make it a priority if everyone reading this thread wrote to Bitmain support asking for when they plan to be compliant and provide the source?

I'm going to write to them right now...

I hope I haven't started a big shitstorm here, and I also hope the cgminer devs don't think that I'm interfering with their affairs. However, as this absolutely concerns everyone involved in mining & the Open Source community - I felt obliged to voice my opinions.

I also wrote an email to Bitmain regarding this when I posted, and I genuinely believe that if the whole Bitcoin & Open Source community got behind the cgminer devs & voiced their concerns to Bitmain in any way possible, both privately & publicly, Bitmain will have no option than to address the situation in a timely and wholly agreeable manner for everyone sooner rather than later. Failure to do so by Bitmain can only leave one possible conclusion - and a nasty legal battle which nobody wants.

I suggest everyone help the cgminer devs in any way they can as a show of gratitude for all their work in the Bitcoin mining community.

Thanks also to everyone for the kind words on my post - I must admit I was slightly concerned about the reaction it might get, but once again the community has proven to me that there is still a togetherness in existence when the sh*t hits the fan  Grin
sr. member
Activity: 420
Merit: 250
Talking about cgminer redirects, does anyone know who unknown.servercentral.net comes from? My S3 seems to be connected to it. Can't place it to any of the pools I use (slush and btcguild).

  look like DNS thing

50.31.189.49
unknown.servercentral.net
IP Address Information
The Internet Service Provider (ISP) that owns the network address of 50.31.189.49 is Server Central Network and located in Illinois within the United States. The IP Address resolves to the DNS record of unknown.servercentral.net.
Network Communications


The following file have been seen to comunicate with this IP address in live environments.

TCP port 3333
cgminer.exe

 



I looked up that information too, which does not really give me any clue as to which pool it belongs. It connects on port 3333 so it really seems to be something to do with mining.


that ip address wasnt pool but ip is for DNS.
newbie
Activity: 21
Merit: 0
Talking about cgminer redirects, does anyone know who unknown.servercentral.net comes from? My S3 seems to be connected to it. Can't place it to any of the pools I use (slush and btcguild).

  look like DNS thing

50.31.189.49
unknown.servercentral.net
IP Address Information
The Internet Service Provider (ISP) that owns the network address of 50.31.189.49 is Server Central Network and located in Illinois within the United States. The IP Address resolves to the DNS record of unknown.servercentral.net.
Network Communications


The following file have been seen to comunicate with this IP address in live environments.

TCP port 3333
cgminer.exe

I looked up that information too, which does not really give me any clue as to which pool it belongs. It connects on port 3333 so it really seems to be something to do with mining.
legendary
Activity: 1150
Merit: 1004
Regarding Bitmain's lack of compliance with the GPL, my guess is that has more to do with lack of resources, messed up priorities, or just plain incompetence. I doubt there's any sinister intent on their part.

That having been said, they must make the time to comply with the licensing and make the source code available. No question.

Maybe they would make it a priority if everyone reading this thread wrote to Bitmain support asking for when they plan to be compliant and provide the source?

I'm going to write to them right now...
sr. member
Activity: 420
Merit: 250
Talking about cgminer redirects, does anyone know who unknown.servercentral.net comes from? My S3 seems to be connected to it. Can't place it to any of the pools I use (slush and btcguild).

  look like DNS thing

50.31.189.49
unknown.servercentral.net
IP Address Information
The Internet Service Provider (ISP) that owns the network address of 50.31.189.49 is Server Central Network and located in Illinois within the United States. The IP Address resolves to the DNS record of unknown.servercentral.net.
Network Communications


The following file have been seen to comunicate with this IP address in live environments.

TCP port 3333
cgminer.exe
newbie
Activity: 21
Merit: 0
Talking about cgminer redirects, does anyone know who unknown.servercentral.net comes from? My S3 seems to be connected to it. Can't place it to any of the pools I use (slush and btcguild).
member
Activity: 105
Merit: 10
BITMAIN claims it is the dc/dc converters which cause the drop in hashrate ...the symptoms of lack of inadequate voltage should manifest as malfunctioning chips in the form of x or - in the GUI...strangely on my miners which the hashrate drops I see nothing of the sort...in fact not even hardware errors....BUT the hashrate is still vanishing by the hour...where is it going and why? If it is really the dc/dc converters then why does changing the controller board affect mining speed (I thought the dc/dc converters they refer to are on the blades?)
I for one am looking for answers...and BITMAIN is just giving everyone the run around...from the start of the S3..first by announcing a product which did not even meet the advertised spec...then by offering a "discount" which is far less than the expected return in the long run (how does a 1 time 10% discount compensate for a continual 10% decrease in output) and rushing to deliver garbage to the customers which was so poorly designed that they had a fire sale on all the badly designed boards and call it S3+

Something really smells here....and I don't like it at all
sr. member
Activity: 420
Merit: 250
4 units (batch 1, first ~15min) arrived today and setup was a breeze.

gorgeous case, makes it feel like a solid consumer-grade product compared to the S1.

miner 1: 237.5MHz     477GH    (2.5hrs)
miner 2: 225MHz        417GH    (2hrs)
miner 3: 225MHz        450GH    (2hrs)
miner 2: 225MHz        413GH    (2hrs)

so far overclocking is a total grab-bag. looks like 2 of the miners lose hashrate at even a slight overclock, and the other has negligible improvement over stock. miner 1 will go for 250mhz tomorrow

I havent seen the invoice yet, but presumably it was about $400 CAD to import and receive all 4 miners.


 Was that $400 just for the HST or did you have to pay duty on the equipment as well?



I got mine of 4xS3 B6 were shipping by UPS for 229.00 (GST+10.00 Brok fee)
hero member
Activity: 546
Merit: 500
Owner, Minersource.net
I do wish the BITMAIN would publish the device driver details so that a current version of cgminer could be attained. I know at least 2 releases in 4 had notes about queue improvements and one at least specifically stated it generated work much faster. Also one of the last 3's had an improvement about how work was loaded into devices. I know for sure 3.12 is very old and I am positive that many work generation improvements have been added since then.

Exactly. I don't understand why they don't work more closely with the cgminer devs - using such an old miner for this equipment is false economy. There have been many improvements & optimixations since this cgminer release, not to mention a very important fix for work redirection by a third party.
Can we just SSH in to it and compile CGMiner to a newer version ?
One would assume that we have access to their modified code and driver for cgminer which the cgminer license stipulates, however they have ignored our requests for making that code available. I am considering what direction to take now about that license violation.

Indeed, I saw your post requesting access to the code - ignoring it seems a very strange course of action by Bitmain, especially since agreeing & cooperating would not only benefit everyone - but would also stay within the legally binding license terms.......

I hope they realize their error & do the right thing - as well as live up to their claim of supporting the Bitcoin community.

@ckolivas: Is there anything we, the community, can do to help? Maybe if we all started mailing them they will take notice?

Hmmmm.......Sorry to quote myself, but the more I think about this - the more it doesn't make any sense. in fact, it smells.

Apart from the obvious legal obligations pointed out by ckolivas, one of the hardest working & well respected Bitcoin community members there is, I find myself wondering why on earth Bitmain won't release their code - are they trying to hide something? I mean, the third party redirect fix was a very important update - why on earth would Bitmain not want to implement it? There are also a multitude of other fixes & improvements which Kano (where is he by the way?) listed in a previous post regarding the S2, but are still relevent:

Because:
1) The version in there throws away valid blocks on p2pool
2) The version in there doesn't block the recent stratum redirect problem
3) The version in there passes all shares to the pool even if they are below target (I'm sure pools must hate the S2 due to the major increase in CPU requirements at the pool)
4) The version in there has the API set to W:0/0 so anyone with network access can change your settings/pool/username (and the web page doesn't let you fix that)
5) The version in there has a modified API with different field names to the standard API so anyone using other software that reads the API must get that software changed (or use a proper API version of cgminer in the S2 Tongue)
.
.
.

By not cooperating with the cgminer devs request to release the code as they are legally bound to do - and not updating cgminer to incorporate the very important security fixes, Bitmain are not only breaking the law - but they are also arousing suspicion amongst the Bitcoin community as to why they are refusing to do so. For a company that claims to respect & care deeply for the Bitcoin community, this makes no sense to me whatsoever.

Before anyone starts breaking my balls accusing me of stirring things up trying to discredit Bitmain - I am a customer who has Bitmain hardware & am quite happy with it. I am merely pointing out the legally binding obligations Bitmain are ignoring, as well as trying to highlight the contempt that Bitmain are showing towards ckolivas & kano - without who, mining & Bitcoin would not be what it is today. We, as a community owe it to the cgminer devs to make sure that all hardware manufacturers respect their requests to release their code as stated in the open source license agreement. If they refuse - we should all be concerned as to the reasons why.

Sorry to ramble, but I'm a great believer in Open Source & what the cgminer devs have done, and continue to do. We owe them  Grin

+1 Here.
I have been asking/badgering their reps in person for the last few months about this, nothing but BS answers to be honest.
legendary
Activity: 1358
Merit: 1002
I do wish the BITMAIN would publish the device driver details so that a current version of cgminer could be attained. I know at least 2 releases in 4 had notes about queue improvements and one at least specifically stated it generated work much faster. Also one of the last 3's had an improvement about how work was loaded into devices. I know for sure 3.12 is very old and I am positive that many work generation improvements have been added since then.

Exactly. I don't understand why they don't work more closely with the cgminer devs - using such an old miner for this equipment is false economy. There have been many improvements & optimixations since this cgminer release, not to mention a very important fix for work redirection by a third party.
Can we just SSH in to it and compile CGMiner to a newer version ?
One would assume that we have access to their modified code and driver for cgminer which the cgminer license stipulates, however they have ignored our requests for making that code available. I am considering what direction to take now about that license violation.

Indeed, I saw your post requesting access to the code - ignoring it seems a very strange course of action by Bitmain, especially since agreeing & cooperating would not only benefit everyone - but would also stay within the legally binding license terms.......

I hope they realize their error & do the right thing - as well as live up to their claim of supporting the Bitcoin community.

@ckolivas: Is there anything we, the community, can do to help? Maybe if we all started mailing them they will take notice?

Hmmmm.......Sorry to quote myself, but the more I think about this - the more it doesn't make any sense. in fact, it smells.

Apart from the obvious legal obligations pointed out by ckolivas, one of the hardest working & well respected Bitcoin community members there is, I find myself wondering why on earth Bitmain won't release their code - are they trying to hide something? I mean, the third party redirect fix was a very important update - why on earth would Bitmain not want to implement it? There are also a multitude of other fixes & improvements which Kano (where is he by the way?) listed in a previous post regarding the S2, but are still relevent:

Because:
1) The version in there throws away valid blocks on p2pool
2) The version in there doesn't block the recent stratum redirect problem
3) The version in there passes all shares to the pool even if they are below target (I'm sure pools must hate the S2 due to the major increase in CPU requirements at the pool)
4) The version in there has the API set to W:0/0 so anyone with network access can change your settings/pool/username (and the web page doesn't let you fix that)
5) The version in there has a modified API with different field names to the standard API so anyone using other software that reads the API must get that software changed (or use a proper API version of cgminer in the S2 Tongue)
.
.
.

By not cooperating with the cgminer devs request to release the code as they are legally bound to do - and not updating cgminer to incorporate the very important security fixes, Bitmain are not only breaking the law - but they are also arousing suspicion amongst the Bitcoin community as to why they are refusing to do so. For a company that claims to respect & care deeply for the Bitcoin community, this makes no sense to me whatsoever.

Before anyone starts breaking my balls accusing me of stirring things up trying to discredit Bitmain - I am a customer who has Bitmain hardware & am quite happy with it. I am merely pointing out the legally binding obligations Bitmain are ignoring, as well as trying to highlight the contempt that Bitmain are showing towards ckolivas & kano - without who, mining & Bitcoin would not be what it is today. We, as a community owe it to the cgminer devs to make sure that all hardware manufacturers respect their requests to release their code as stated in the open source license agreement. If they refuse - we should all be concerned as to the reasons why.

Sorry to ramble, but I'm a great believer in Open Source & what the cgminer devs have done, and continue to do. We owe them  Grin

Ever since I read ckolivas' post regarding his request to Bitmain, I started thinking along the same train of thought that you just expressed (even bordering on paranoia Smiley).  I'd hate to think that some nefarious chit has been added to the code.



what if, say 5 % og your mining is being redirected... from the cgminer app that, aparently no one can see the source code for...

some questions indeed....
legendary
Activity: 1081
Merit: 1001
I do wish the BITMAIN would publish the device driver details so that a current version of cgminer could be attained. I know at least 2 releases in 4 had notes about queue improvements and one at least specifically stated it generated work much faster. Also one of the last 3's had an improvement about how work was loaded into devices. I know for sure 3.12 is very old and I am positive that many work generation improvements have been added since then.

Exactly. I don't understand why they don't work more closely with the cgminer devs - using such an old miner for this equipment is false economy. There have been many improvements & optimixations since this cgminer release, not to mention a very important fix for work redirection by a third party.
Can we just SSH in to it and compile CGMiner to a newer version ?
One would assume that we have access to their modified code and driver for cgminer which the cgminer license stipulates, however they have ignored our requests for making that code available. I am considering what direction to take now about that license violation.

Indeed, I saw your post requesting access to the code - ignoring it seems a very strange course of action by Bitmain, especially since agreeing & cooperating would not only benefit everyone - but would also stay within the legally binding license terms.......

I hope they realize their error & do the right thing - as well as live up to their claim of supporting the Bitcoin community.

@ckolivas: Is there anything we, the community, can do to help? Maybe if we all started mailing them they will take notice?

Hmmmm.......Sorry to quote myself, but the more I think about this - the more it doesn't make any sense. in fact, it smells.

Apart from the obvious legal obligations pointed out by ckolivas, one of the hardest working & well respected Bitcoin community members there is, I find myself wondering why on earth Bitmain won't release their code - are they trying to hide something? I mean, the third party redirect fix was a very important update - why on earth would Bitmain not want to implement it? There are also a multitude of other fixes & improvements which Kano (where is he by the way?) listed in a previous post regarding the S2, but are still relevent:

Because:
1) The version in there throws away valid blocks on p2pool
2) The version in there doesn't block the recent stratum redirect problem
3) The version in there passes all shares to the pool even if they are below target (I'm sure pools must hate the S2 due to the major increase in CPU requirements at the pool)
4) The version in there has the API set to W:0/0 so anyone with network access can change your settings/pool/username (and the web page doesn't let you fix that)
5) The version in there has a modified API with different field names to the standard API so anyone using other software that reads the API must get that software changed (or use a proper API version of cgminer in the S2 Tongue)
.
.
.

By not cooperating with the cgminer devs request to release the code as they are legally bound to do - and not updating cgminer to incorporate the very important security fixes, Bitmain are not only breaking the law - but they are also arousing suspicion amongst the Bitcoin community as to why they are refusing to do so. For a company that claims to respect & care deeply for the Bitcoin community, this makes no sense to me whatsoever.

Before anyone starts breaking my balls accusing me of stirring things up trying to discredit Bitmain - I am a customer who has Bitmain hardware & am quite happy with it. I am merely pointing out the legally binding obligations Bitmain are ignoring, as well as trying to highlight the contempt that Bitmain are showing towards ckolivas & kano - without who, mining & Bitcoin would not be what it is today. We, as a community owe it to the cgminer devs to make sure that all hardware manufacturers respect their requests to release their code as stated in the open source license agreement. If they refuse - we should all be concerned as to the reasons why.

Sorry to ramble, but I'm a great believer in Open Source & what the cgminer devs have done, and continue to do. We owe them  Grin

Ever since I read ckolivas' post regarding his request to Bitmain, I started thinking along the same train of thought that you just expressed (even bordering on paranoia Smiley).  I'd hate to think that some nefarious chit has been added to the code.

Jump to: