ANTMINER S3+ Discussion and Support Thread

[PlanetCrypto]

The point is, the "pool" is paying out more than it can ever take in on a PPS model so somethings up somewhere.

Trying to build a bitcoin affiliate network is what they are saying, also they claim the payout of bonus may last up until 5TH. This suggests they could end it sooner if they reach the goals for the pool.

If something is to good to be true it usually is. But on the other hand, if I had the resources, and could afford it, I would do the exact same thing to promote my own business, though perhaps not as aggresive as 12.5%

*Edit I am on the NY server, I only had a few minor disconnects, which may have to do with the fact the pool / company is in process of being built.

stratum+tcp://east2.bitcoindigger.com:3333

STILL dead ! I'll let test miner run for 10 minutes to see if it corrects but I doubt it.

Edit: Seems it was a worker issues _ instead of .

I am running 1 s-3 on it seems okay.  I did the VA server as I may be closer to it then the NY one.

I am in the Midwest and run all 12 miners (9-S1's and 3-S3's) on the VA server.

My 2 S1's are on the VA server.
Did a ping to all of them and east1 (VA) had the lowest times (~80ms).
I'm in Minnesota.

Didn't read the previous post about not posting about pools in this thread.
Won't happen again.
Sorry.

[1714659178]

1714659178

[1714659178]

1714659178

[1714659178]

1714659178

[1714659178]

1714659178

[1714659178]

1714659178

[Askit2]

I believe the setting is quite pool specific. I used to use --queue 1 but found I got a lower DOA rate & slightly better performance using --queue 0 with the cpu at ~80% - but I'm pointing mine at p2pool so maybe that's why? Load is currently: 1.58 1.62 1.40 @ 237.5

Thanks for the feedback. I'm pointing them at Slush, with Bitminter as a backup (failover).

Don't see how the CPU% is dependent on the OC, but I ran tests on 3 different clocks, with 3 different queue settings. The load was pretty high on all of them.

Everytime there is a new block the cpu has to make 4097, 129, 3, 2, or 1 work unit to send out immediately. There is always 1 with a queue of 0 you have 1 work unit prepped to send to the next chip needing work. with 4096 you have 4097 work units ready to go out. At the end of a block you still have 1 to 4097 work units ready to go. The cpu will have far less load spikes on a lower number. I started with 2 (three prepped in total) but noticed 1 (2 ready at all times) used a bit less cpu. I then moved to 1 and got just under 2 UNLESS I go to the Realtime Graphs tab. The big advantage to something slightly above 0 but less then maybe 16 is that if most of your hashing chips suddenly ran out of work there is enough work for half of them queued up. At least for one work unit each.

I really did prefer 2 ish but 0 seems to be less loaded and pool results aren't significantly different for me.

[visdude]

Update....the latest firmware is a disaster on my miners...I don't like how the asic frequencies are only read from the rom (read only) for starters...the clock selections defaulting to 237.5 was the first sign, along with the other details I mentioned in the first post I made regarding this new firmware..back to 0721 for me and I don't get x's on stock like I do with the new firmware...all in all I think its a piece of junk and should be pulled from bitmain site...and what is the deal with the july 28 firmware...I had it on a few of my ants and now its gone due to the flash "upgrade" downgrade...I cant honestly see any benefit from having the latest August firmware...and for those who will say it helps with overclocking...if that is the help you need to overclock, please quit while you are ahead  

interesting observations and thanks for sharing. I just saw the firmware update on the site and downloaded but now hesitant to update.

Anyone out there that updated and had no issues?

As the saying goes, "don't fix it if it ain't broke".

[crazyates]

I believe the setting is quite pool specific. I used to use --queue 1 but found I got a lower DOA rate & slightly better performance using --queue 0 with the cpu at ~80% - but I'm pointing mine at p2pool so maybe that's why? Load is currently: 1.58 1.62 1.40 @ 237.5

Thanks for the feedback. I'm pointing them at Slush, with Bitminter as a backup (failover).

Don't see how the CPU% is dependent on the OC, but I ran tests on 3 different clocks, with 3 different queue settings. The load was pretty high on all of them.

Everytime there is a new block the cpu has to make 4097, 129, 3, 2, or 1 work unit to send out immediately. There is always 1 with a queue of 0 you have 1 work unit prepped to send to the next chip needing work. with 4096 you have 4097 work units ready to go out. At the end of a block you still have 1 to 4097 work units ready to go. The cpu will have far less load spikes on a lower number. I started with 2 (three prepped in total) but noticed 1 (2 ready at all times) used a bit less cpu. I then moved to 1 and got just under 2 UNLESS I go to the Realtime Graphs tab. The big advantage to something slightly above 0 but less then maybe 16 is that if most of your hashing chips suddenly ran out of work there is enough work for half of them queued up. At least for one work unit each.

I really did prefer 2 ish but 0 seems to be less loaded and pool results aren't significantly different for me.

I understand how the queue works; I've been using cgminer since v 1.4 or something silly like that.

When I dropped down to queue=1, my hashrate dropped from ~480 to ~460. I'm running it with a queue of 16 for now, but my load is still 2+.

But to answer my original question: this sounds like something that other people are living with, and is normal?

[visdude]

Please keep your "pool" spam off the Bitmain thread - I & others don't want to scroll past quote upon quote about how good/shit it is while trying to find info about Bitmain products.

Thanks.

No, thank you!  You beat me to it.

[contactlight]

I just applied the firmware update on one of my miners and after the reboot something was wrong. It wouldn't start mining and the CPU load would be very high. I went ahead to reset the settings and rebooted. Now I can't access the device at all.

How is the physical hard reset done again?

[yslyung]

I just applied the firmware update on one of my miners and after the reboot something was wrong. It wouldn't start mining and the CPU load would be very high. I went ahead to reset the settings and rebooted. Now I can't access the device at all.

How is the physical hard reset done again?

pin hole next to lan port /led

[jimmyoh]

I just applied the firmware update on one of my miners and after the reboot something was wrong. It wouldn't start mining and the CPU load would be very high. I went ahead to reset the settings and rebooted. Now I can't access the device at all.

How is the physical hard reset done again?

pin hole next to lan port /led

Also, if you haven't done so already, make sure to uncheck the "save settings" on the firmware update page.
If don't your Miner Status page while remain blank.
That last FW update caused more problems than it fixed so went back to the older one.

[visdude]

Wow!  It's even hotter today for my S3s than yesterday.  Ambient room temperature peaked at 37.3C (99.2F).  They have been clocked higher at 237.5M this time around and drawing 408W at the wall but didn't seem to skip a beat at all.  These were the stats during that particular period:

[dankefoss]

Why does 250M make my miner go slower with an x in the asic status...

Same with me. I had the most stable of miners and now with the update from yesterday, I am losing a chip (x). Same frequency, nothing else changed. My other miner seems to be performing the same or a little better.

[crazyates]

Wow!  It's even hotter today for my S3s than yesterday.  Ambient room temperature peaked at 37.3C (99.2F).  They have been clocked higher at 237.5M this time around and drawing 408W at the wall but didn't seem to skip a beat at all.  These were the stats during that particular period:

Your fans aren't really running at 15k RPM, are they?

[visdude]

Wow!  It's even hotter today for my S3s than yesterday.  Ambient room temperature peaked at 37.3C (99.2F).  They have been clocked higher at 237.5M this time around and drawing 408W at the wall but didn't seem to skip a beat at all.  These were the stats during that particular period:

Your fans aren't really running at 15k RPM, are they?

I don't think so.  I'm sure I'd notice if it's spinning at 15K.  It's been like that since day 1, hot or cold .  If Bitmain doesn't care about fixing it, then I don't care as long as I know they are spinning and pushing/pulling air.

[Atomar]

Wow!  It's even hotter today for my S3s than yesterday.  Ambient room temperature peaked at 37.3C (99.2F).  They have been clocked higher at 237.5M this time around and drawing 408W at the wall but didn't seem to skip a beat at all.  These were the stats during that particular period:

Your fans aren't really running at 15k RPM, are they?

My fans showing both 15300! Allways. And they run for sure NOZ that fast. Wired Thing. Even with the new firmware.
Does anybudy know how to fix that ?

[Fahlcor]

Not an endorsement at all but the S3 Ants work perfect on Nicehash.  Best return I have got from any pool and beating Coinwarz calc/thash.

Thanks for making nice product Bitmain.  My miners are running stock B5 firmware and all 12 are running like champs.  Not touching any new firmware with a 10 foot pole.

And the ants obviously like 40 C as the fans seem to spin down to keep them there.

S1:210   0d 9h 15m 2s   449.24   453.37   0   0.0021%   402,628   2,048   UUU   0.2073   0   2520   2520 1440   40   39 40
S1:211   0d 8h 26m 58s   463.29   475.92   0   0.0138%   3,152,112   2,048   UUU   0.13   0   4020   4020 1680   40   40 40
S1:212   0d 9h 11m 24s   462.17   451.12   0   0.0128%   453,492   2,048   UUU   0.3807   0   3420   3240 3420   39   39 39
S1:213   0d 9h 10m 42s   478.88   453.08   0   0.0174%   13,183,229   1,000   UUU   0.2416   0   1620   1620 1560   40   38 40
S1:214   0d 9h 10m 31s   482.52   479.14   0   0.0012%   7,223,355   2,048   UUU   0.0827   0   1920   1920 1560   40   40 38
S1:215   0d 9h 10m 3s   467.46   441.25   0   0.0054%   6,928   2,048   UUU   0.2207   0   3600   3600 1620   41   39 41
S1:216   0d 9h 0m 48s   458.94   476.88   0   0.0018%   3,790,128   2,048   UUU   0.2666   0   1860   1860 1620   40   40 40
S1:217   0d 9h 4m 23s   438.85   445.99   0   0.008%   166,728   1,000   UUU   0.3658   0   2520   2520 1680   39   39 38
S1:218   0d 9h 3m 41s   470.49   463.01   0   0.0053%   7,342   2,048   UUU   0.1764   0   2940   2940 2040   40   37 40
S1:219   0d 9h 2m 53s   469.22   453.46   0   0.0048%   4,203,450   2,048   UUU   0.4787   0   1860   1860 1620   39   38 39
S1:220   0d 9h 1m 26s   469.62   475.45   0   0.0116%   765,930   2,048   UUU   0.3104   0   3840   3840 1380   40   40 40
S1:221   0d 9h 1m 23s   441.22   440.07   0   0.0023%   248,037   2,048   UUU   0.3358   0   3180   3180 1560   39   39 39

oh and Ant monitor rocks for easy watching them all.  Bitmain should buy and include this software.

Fahlcor

[visdude]

Wow!  It's even hotter today for my S3s than yesterday.  Ambient room temperature peaked at 37.3C (99.2F).  They have been clocked higher at 237.5M this time around and drawing 408W at the wall but didn't seem to skip a beat at all.  These were the stats during that particular period:

Your fans aren't really running at 15k RPM, are they?

My fans showing both 15300! Allways. And they run for sure NOZ that fast. Wired Thing. Even with the new firmware.
Does anybudy know how to fix that ?

Well, if it's not a firmware issue, then perhaps it's hardware-related.  I don't know the quality of sensors Bitmain has been using in their devices but I kinda lost faith in them.  It's already obvious that these fan speeds are not realistic.  Like I said, as long as the fans themselves are spinning (and seem to audibly change RPM every now and then), I don't care about the reported numbers anymore.  But that's just me.  One of my S1s used to turn all "x" on me yet hash rates on both sides were never actually affected.  I just hope that the temperature sensors in these units are up to par because they are more crucial than anything else but considering the significant differences/variations in S3 temperature readings posted by members in here, I doubt it.

So, in a way, we're flying blind here.  We're really not sure what we're getting.  I think physically monitoring our units is the best way to stay on top of it since we cannot really rely on these numbers.

A little food for thought:  How did we manage to successfully run mining farms using USB miners that were not equipped with temperature sensors?

[visdude]

Not an endorsement at all but the S3 Ants work perfect on Nicehash.  Best return I have got from any pool and beating Coinwarz calc/thash.

Thanks for making nice product Bitmain.  My miners are running stock B5 firmware and all 12 are running like champs.  Not touching any new firmware with a 10 foot pole.

And the ants obviously like 40 C as the fans seem to spin down to keep them there.

S1:210   0d 9h 15m 2s   449.24   453.37   0   0.0021%   402,628   2,048   UUU   0.2073   0   2520   2520 1440   40   39 40
S1:211   0d 8h 26m 58s   463.29   475.92   0   0.0138%   3,152,112   2,048   UUU   0.13   0   4020   4020 1680   40   40 40
S1:212   0d 9h 11m 24s   462.17   451.12   0   0.0128%   453,492   2,048   UUU   0.3807   0   3420   3240 3420   39   39 39
S1:213   0d 9h 10m 42s   478.88   453.08   0   0.0174%   13,183,229   1,000   UUU   0.2416   0   1620   1620 1560   40   38 40
S1:214   0d 9h 10m 31s   482.52   479.14   0   0.0012%   7,223,355   2,048   UUU   0.0827   0   1920   1920 1560   40   40 38
S1:215   0d 9h 10m 3s   467.46   441.25   0   0.0054%   6,928   2,048   UUU   0.2207   0   3600   3600 1620   41   39 41
S1:216   0d 9h 0m 48s   458.94   476.88   0   0.0018%   3,790,128   2,048   UUU   0.2666   0   1860   1860 1620   40   40 40
S1:217   0d 9h 4m 23s   438.85   445.99   0   0.008%   166,728   1,000   UUU   0.3658   0   2520   2520 1680   39   39 38
S1:218   0d 9h 3m 41s   470.49   463.01   0   0.0053%   7,342   2,048   UUU   0.1764   0   2940   2940 2040   40   37 40
S1:219   0d 9h 2m 53s   469.22   453.46   0   0.0048%   4,203,450   2,048   UUU   0.4787   0   1860   1860 1620   39   38 39
S1:220   0d 9h 1m 26s   469.62   475.45   0   0.0116%   765,930   2,048   UUU   0.3104   0   3840   3840 1380   40   40 40
S1:221   0d 9h 1m 23s   441.22   440.07   0   0.0023%   248,037   2,048   UUU   0.3358   0   3180   3180 1560   39   39 39

oh and Ant monitor rocks for easy watching them all.  Bitmain should buy and include this software.

Fahlcor

I take it that you didn't read the last couple of pages that contain references on "pool" spamming.

[Askit2]

I believe the setting is quite pool specific. I used to use --queue 1 but found I got a lower DOA rate & slightly better performance using --queue 0 with the cpu at ~80% - but I'm pointing mine at p2pool so maybe that's why? Load is currently: 1.58 1.62 1.40 @ 237.5

Thanks for the feedback. I'm pointing them at Slush, with Bitminter as a backup (failover).

Don't see how the CPU% is dependent on the OC, but I ran tests on 3 different clocks, with 3 different queue settings. The load was pretty high on all of them.

Everytime there is a new block the cpu has to make 4097, 129, 3, 2, or 1 work unit to send out immediately. There is always 1 with a queue of 0 you have 1 work unit prepped to send to the next chip needing work. with 4096 you have 4097 work units ready to go out. At the end of a block you still have 1 to 4097 work units ready to go. The cpu will have far less load spikes on a lower number. I started with 2 (three prepped in total) but noticed 1 (2 ready at all times) used a bit less cpu. I then moved to 1 and got just under 2 UNLESS I go to the Realtime Graphs tab. The big advantage to something slightly above 0 but less then maybe 16 is that if most of your hashing chips suddenly ran out of work there is enough work for half of them queued up. At least for one work unit each.

I really did prefer 2 ish but 0 seems to be less loaded and pool results aren't significantly different for me.

I understand how the queue works; I've been using cgminer since v 1.4 or something silly like that.

When I dropped down to queue=1, my hashrate dropped from ~480 to ~460. I'm running it with a queue of 16 for now, but my load is still 2+.

But to answer my original question: this sounds like something that other people are living with, and is normal?

I didn't intend to imply you hadn't been using cgminer or that you didn't know how the queue worked. I only wanted to point out that I find it less likely that running even more processor cycles initially to get to a certain level of queued work would be somewhat less likely to help improve speed. I do see how an increase from 440 to 480 would represent a 8.333333% increase in speed. Likely the processor requirements to keep up with said improvement in hashing speed are fairly linear. If you are running 90% at 440 I would expect nearly 99% at 480. That having been said I also would wonder how bogging the cpu down for longer initially and maintaining a higher average load would improve hashing speed. I suppose since the new work can be queued up farther down the line and cgminer wouldn't run out of work maybe it makes sense. I do see that you tested it and I don't want to infer you have made a mistake. I don't think you have. I just find it very curious.

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.

This analysis also ignores the serial load as that is separate unless BITMAIN actually has them running direct USB. Meaning the load will be actually higher for cgminer then it appears on top or the process tree.

[bluecityste]

Hi, just set up my new s3 this morning.

It's working at bitminter (verified hashing on there pool) but it won't let me get passed the login page on the miner user interface, I.e. I get to log on, enter root root as per normal and then the following appears:

/usr/lib/lua/luci/dispatcher.lua:448: Failed to execute function dispatcher target for entry '/'.
The called action terminated with an exception:
/usr/lib/lua/luci/sauth.lua:87: Session data invalid!
stack traceback:
   [C]: in function 'assert'
   /usr/lib/lua/luci/dispatcher.lua:448: in function 'dispatch'
   /usr/lib/lua/luci/dispatcher.lua:195: in function </usr/lib/lua/luci/dispatcher.lua:194>

Anyone have any ideas? Do I need to reset and start again?
Thanks

[bluecityste]

Powered off 5 times, then on the 6th it let me back in....panic over

[Ilan1]

I read somewhere that the new firmware update shows a new Freq tab or something, I have just uploaded it but don't see any changes?