One of my S3 temperature shows as 0 (for both chain 1, 2). How do I resolve this?
I tried to restart, reboot and nothing helped.
You have confirmed that is it mining and submitting?I tried to restart, reboot and nothing helped.
Yes
Topic: ANTMINER S3+ Discussion and Support Thread - page 369. (Read 710164 times)
Yes
One of my S3 temperature shows as 0 (for both chain 1, 2). How do I resolve this?
I tried to restart, reboot and nothing helped.
You have confirmed that is it mining and submitting? I tried to restart, reboot and nothing helped.
I cannot see any ASIC blade on my S3 :/ I can connect to it, it says "mining", but hash rate 0gh/s, no blade in the bottom part of miner status.
Firmware latest, help please
Firmware latest, help please
You check the pool address is correct along with the worker/password. If that doesn't help go reboot route.
I cannot see any ASIC blade on my S3 :/ I can connect to it, it says "mining", but hash rate 0gh/s, no blade in the bottom part of miner status.
Firmware latest, help please
Firmware latest, help please
Still no 7.7% refund 
anyone else got there's yet? Can someone from Bitmain please confirm that we will actually receive this today?
anyone else got there's yet? Can someone from Bitmain please confirm that we will actually receive this today?Nope still waiting
Waiting. They could at least tell us WHEN to expect it. How hard could it be to process these? It's a drop in the bucket compared to what they have collected just from users here alone.
One of my S3 temperature shows as 0 (for both chain 1, 2). How do I resolve this?
I tried to restart, reboot and nothing helped.
I tried to restart, reboot and nothing helped.
FWIW, After ~10 hours running with --queue 32, slightly overclocked to 225, share difficulty set to 256.
Does not seem to have affected hashing at all, but noticeable CPU load decrease.
Giving you generic advice regarding the queue setting is difficult because this is not my driver...I'd be surprised if it really needs to be that high though, and on a low powered system there is rarely anything to gain from anything even in the hundreds, let alone thousands.
Thanks for this. Going to run one of my units with --queue 32 overnight and see how the stats look when I wake up.
I tried it at 64 and got a high discard rate. I'll try it with 32 as you have and see if that will be my sweet spot. I removed the scan time and expiry as ck suggested.Does not seem to have affected hashing at all, but noticeable CPU load decrease.
Please, what would you suggest we set the queue, scan time and expiry to?
Again, do not touch scan time and expiry. Giving you generic advice regarding the queue setting is difficult because this is not my driver...I'd be surprised if it really needs to be that high though, and on a low powered system there is rarely anything to gain from anything even in the hundreds, let alone thousands.
I have been playing around with a variety of different numbers also best overall performance (load, HWE, Discards, and stales) I have gotten is setting all 3 settings to 1 and that is what I am staying with.
FWIW, After ~10 hours running with --queue 32, slightly overclocked to 225, share difficulty set to 256.
Does not seem to have affected hashing at all, but noticeable CPU load decrease.
Giving you generic advice regarding the queue setting is difficult because this is not my driver...I'd be surprised if it really needs to be that high though, and on a low powered system there is rarely anything to gain from anything even in the hundreds, let alone thousands.
Thanks for this. Going to run one of my units with --queue 32 overnight and see how the stats look when I wake up.
I tried it at 64 and got a high discard rate. I'll try it with 32 as you have and see if that will be my sweet spot. I removed the scan time and expiry as ck suggested. Does not seem to have affected hashing at all, but noticeable CPU load decrease.
Please, what would you suggest we set the queue, scan time and expiry to?
Again, do not touch scan time and expiry. Giving you generic advice regarding the queue setting is difficult because this is not my driver...I'd be surprised if it really needs to be that high though, and on a low powered system there is rarely anything to gain from anything even in the hundreds, let alone thousands.
Can any Canadians here sell me one?
Has their been any news on the S1 upgrade modules to upgrade with the S3 modules to use
No news yet. Curious myself. Have 9 S1's collecting dust I would like to upgrade if possible.Mine are going to be collecting dust at the end of this month when they get turned off however going into a partnership for mining as opted to pay me for energy costs so going to see how it works outs. other than that if it fails then ill probs end up holding them until theirs news of the upgrade modules and continue to trade on markets.
i have a strangest unit on most recent firmare.
At 212.5 speed is ~429 GH (after 12 hr), almost no HW errors, temp ~40
At 218.75, speed is ~420GH (after same time), almost no HW errors, same temp
At 225, speed is ~420GH after 12 hours (initially bumps to 455, then slowly drifts down), no errors, same temp
What exactly is the limiting factor here?
I am thinking that is is that darned Dc-Dc converter, so would be very eager to learn if someone got an improvement by attaching heat sink, etc.
At 212.5 speed is ~429 GH (after 12 hr), almost no HW errors, temp ~40
At 218.75, speed is ~420GH (after same time), almost no HW errors, same temp
At 225, speed is ~420GH after 12 hours (initially bumps to 455, then slowly drifts down), no errors, same temp
What exactly is the limiting factor here?
I am thinking that is is that darned Dc-Dc converter, so would be very eager to learn if someone got an improvement by attaching heat sink, etc.
Has their been any news on the S1 upgrade modules to upgrade with the S3 modules to use
No news yet. Curious myself. Have 9 S1's collecting dust I would like to upgrade if possible.
Has their been any news on the S1 upgrade modules to upgrade with the S3 modules to use or is this something that's going to take longer than expected as am tempted to buy a few new S3 however wanted just the modules so can upgrade my S1. I was reading that their where meant to be out around the same time as the S3 come out but still seen no updates in regards to upgrade modules to fit the S1 with the S3 modules
I don't see it that way. I see it as part of the risk if you offer paid utilities to someone. The rental agreement should include provisions to restrict or prohibit mining if the "landlord" doesn't want to pay for mining (or grow lamps, for that matter) as part of the electric.
I just recall my dormroom 20 years ago and I (and a roommate) could never have put up with the noise and heat from an S1 for more than 5 minutes.
I just recall my dormroom 20 years ago and I (and a roommate) could never have put up with the noise and heat from an S1 for more than 5 minutes.
Hey the s1's are quiet and not too hot. I had several of the 1000watt avolon 200 gh they are loud and hot i think 1 of them was actually worse than a 1th dragon.
Still no 7.7% refund anyone else got there's yet? Can someone from Bitmain please confirm that we will actually receive this today?
anyone else got there's yet? Can someone from Bitmain please confirm that we will actually receive this today?Nope still waiting
Still no 7.7% refund anyone else got there's yet? Can someone from Bitmain please confirm that we will actually receive this today?
anyone else got there's yet? Can someone from Bitmain please confirm that we will actually receive this today?
FWIW, After ~10 hours running with --queue 32, slightly overclocked to 225, share difficulty set to 256.
Does not seem to have affected hashing at all, but noticeable CPU load decrease.
Giving you generic advice regarding the queue setting is difficult because this is not my driver...I'd be surprised if it really needs to be that high though, and on a low powered system there is rarely anything to gain from anything even in the hundreds, let alone thousands.
Thanks for this. Going to run one of my units with --queue 32 overnight and see how the stats look when I wake up.
Does not seem to have affected hashing at all, but noticeable CPU load decrease.
Please, what would you suggest we set the queue, scan time and expiry to?
Again, do not touch scan time and expiry. Giving you generic advice regarding the queue setting is difficult because this is not my driver...I'd be surprised if it really needs to be that high though, and on a low powered system there is rarely anything to gain from anything even in the hundreds, let alone thousands.
What exactly is the beeg at s3
How big is this batch 5?
Yeah but having your miner queue work from 5minutes ago and gain nothing is also a waste.
Properly setting up a queue/scan-time/expiry can decrease the load of your unit and increase efficiency of the work done.
Proper settings isn't the dark age, it's just something that never is done right
There is a reason these options are here for us to optimize with the specific hardware we use! 
I wrote the software, I know what I'm talking about. You're barking up the wrong tree with scan time and expiry.Properly setting up a queue/scan-time/expiry can decrease the load of your unit and increase efficiency of the work done.
Proper settings isn't the dark age, it's just something that never is done right
There is a reason these options are here for us to optimize with the specific hardware we use! I'm not barking up any tree
You wrote a software and we use the optimal settings for the different hardware and pools we use. Correct?
queue of 4096 is not helping the S3 while a lower queue is, so I'm sorry if you misunderstood my post.
Should we just go put 99999 on all the settings and expect them to function the same?
Here is the thing.
Queue is the number of work units to have ready in advance of need. 4k is high. 0 means everytime something runs out of work the CPU right then has to make new work. Having a queue of 1 means it sends work then makes one more.
Expiry is the time in seconds to hold delayed or un submitted work. 1 second means if it can't send immediately it's thrown away.
Scan time is the time that it can work off of given work units. Using stratum you will not need this lower as there is plenty of local work.
P2pool is different some. But for anyone not using it the defaults for cgminer are fine. It doesn't waste tons of bandwidth trying a new unit every second or throwing away work on any network delay. The queue is far above the default of 1.
so, its not like we need to modify anything...
I did queue 0, scan-time 1, and expiry 1 as suggested on a stock S3 and I've been on failover for about 8 hours straight.
Hash rates are about the same both poolside and on the gui. Discards are way down and HW looks down too. Pool has next to no discards in failover but I was getting a lot in load-balance.
Would someone who know what they are talking about please provide some suggested settings, so we can start testing them out?
From above would, queue 1, scan-time 0, and expiry 0, be the way to go?
Jump to: