ANTMINER S3+ Discussion and Support Thread

[Lowell904]

I found those here:

http://www.ebay.com/itm/20PCS-Lot-11x11x5MM-IC-Cooling-Cooler-Mini-Aluminum-Heatsink-For-Chip-Cooling-/221320177126?pt=US_Memory_Chipset_Cooling&hash=item3387b5e5e6

[1714607750]

1714607750

[1714607750]

1714607750

[1714607750]

1714607750

[WheresWaldo]

I was able to get the discarded amount lowered as well as the load. I changed the queue to 0 from 4096 and added --scan-time 1 --expiry 1 to the cgminer file.

***IF YOU ARE NOT SURE WHAT THIS MEANS DO NOT TRY AS YOU WILL BRICK YOUR UNIT***

This is the first attempt, not sure if 0 is the optimal queue value for all pools but if you are a P2P miner you may want to try this out. I use a smaller pool and my numbers have gone up. This is along the same tune you could do for an S1 but a far cry from what we did in the GPU days. I have another unit running at a lower speed but have the same results.
  
SSH in then:

Code:

vim /etc/init.d/cgminer
--scan-time 1 --expiry 1

Find line 75 PARAMS...at the end change --queue 0 and add --scan-time 1 --expiry 1 before the quotation.

***DO NOT TRY THIS UNLESS YOU FULLY UNDERSTAND AS YOU WILL BRICK YOUR UNIT****

Please stop telling people  to do anything but change the queue. Artificially lowering the discarded value serves no purpose whatsoever. Decreasing scan time and expiry are for the dark ages of CPU mining - paying any attention to the "discarded work" value is completely pointless and actually harmful. The only thing here that's making a difference to CPU load is decreasing the queue which they have set far too high by default. Please do not decrease it below 1 though.

Perfect so the queue should be set to 1.
For the P2P folks, scan time and expiry settings will not help them as there were no settings included? (yes/no)

I truly appreciate and respect your inputs both positive and negative.

I was able to get the discarded amount lowered as well as the load. I changed the queue to 0 from 4096 and added --scan-time 1 --expiry 1 to the cgminer file.

***IF YOU ARE NOT SURE WHAT THIS MEANS DO NOT TRY AS YOU WILL BRICK YOUR UNIT***

This is the first attempt, not sure if 0 is the optimal queue value for all pools but if you are a P2P miner you may want to try this out. I use a smaller pool and my numbers have gone up. This is along the same tune you could do for an S1 but a far cry from what we did in the GPU days. I have another unit running at a lower speed but have the same results.
 
SSH in then:

Code:

vim /etc/init.d/cgminer
--scan-time 1 --expiry 1

Find line 75 PARAMS...at the end change --queue 0 and add --scan-time 1 --expiry 1 before the quotation.

***DO NOT TRY THIS UNLESS YOU FULLY UNDERSTAND AS YOU WILL BRICK YOUR UNIT****

Please stop telling people  to do anything but change the queue. Artificially lowering the discarded value serves no purpose whatsoever. Decreasing scan time and expiry are for the dark ages of CPU mining - paying any attention to the "discarded work" value is completely pointless and actually harmful. The only thing here that's making a difference to CPU load is decreasing the queue which they have set far too high by default. Please do not decrease it below 1 though.

i agree with this boss 

without modifying anything...
tested at Ghash, the discarded will be 10times of accepted              <<best share will be a big 0
tested at Eligius, the Discarded will be as low as 0.01 x accepted      <<it'll showing ur best shares
tested at P2pool, same result as eligius..                                                         <<same as eligius

so... dont pay any attention to the "discarded", i dont know why, but maybe because of the pool that the "discarded" is pretty high at our miner

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!

[padrino]

I was able to get the discarded amount lowered as well as the load. I changed the queue to 0 from 4096 and added --scan-time 1 --expiry 1 to the cgminer file.

***IF YOU ARE NOT SURE WHAT THIS MEANS DO NOT TRY AS YOU WILL BRICK YOUR UNIT***

This is the first attempt, not sure if 0 is the optimal queue value for all pools but if you are a P2P miner you may want to try this out. I use a smaller pool and my numbers have gone up. This is along the same tune you could do for an S1 but a far cry from what we did in the GPU days. I have another unit running at a lower speed but have the same results.
  
SSH in then:

Code:

vim /etc/init.d/cgminer
--scan-time 1 --expiry 1

Find line 75 PARAMS...at the end change --queue 0 and add --scan-time 1 --expiry 1 before the quotation.

***DO NOT TRY THIS UNLESS YOU FULLY UNDERSTAND AS YOU WILL BRICK YOUR UNIT****

Please stop telling people  to do anything but change the queue. Artificially lowering the discarded value serves no purpose whatsoever. Decreasing scan time and expiry are for the dark ages of CPU mining - paying any attention to the "discarded work" value is completely pointless and actually harmful. The only thing here that's making a difference to CPU load is decreasing the queue which they have set far too high by default. Please do not decrease it below 1 though.

I was having other issues before this mod like wrong hash rates at the gui and more HW errors than I would have liked. While load balancing I was getting a lot of discards at the pool I was using. Maybe it doesn't make much difference, but after this mod things look good at the pools, discards and HW look great, but hash rates seem way off still. I think the firmware is buggy and could be improved.

Edit: hash rates look good now on failover. Testing load-balancing now. Results = not hashing well at the pools. sticking to failover until we figure this out.

How should we revert back if need be, or what would be ideal parameters. I'm hoping that I could always just re-flash the firmware if need be.

Con is obviously much more of an expert than I am but I would drop scan-time and expiry completely, revert queue to the default of 1 (or remove it complete, it defaults to 1)... Perhaps a higher queue value is better for the S3 but 4096 was taking the CPU usage off the charts and starving the system..

[-ck]

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.

[Lowell904]

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.

Please, what would you suggest we set the queue, scan time and expiry to?

[-ck]

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 have not reviewed their driver, nor do I have the hardware, but a value of zero is too low given the core work generation code in cgminer hence why 1 is the default. I'm not explicitly aware of why they chose such a high queue. There is a good chance that their driver design is not asynchronous enough to ensure the device remains busy and they played with settings till they found one that would keep it busy. 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. High CPU usage in and of itself is not necessarily harmful if it does a better job of keeping the device busy, unless the CPU usage is always 100% or more, and then that leaves no headroom for any other services on the operating system of these underpowered devices and as soon as there's anything else to do, latencies get perpetuated across all the running software.

[-ck]

I should also add that with underpowered CPUs that are always overloaded, using a pool with a large coinbase unfortunately will make things worse and increase the CPU usage further. "Generation" coinbases where your coins are generated instead of sent to you (such as those used by Eligius and p2pool) are two examples. That doesn't preclude them from being used, but it's worth experimenting to see if it matters.

[WheresWaldo]

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.

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?

[R4v37]

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.

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?

sir, ghash vs eligius vs p2pool
pls try these pools with the modified queue and scantime...

hope we can see something WOW here

[Xian01]

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.

Thanks for this. Going to run one of my units with --queue 32 overnight and see how the stats look when I wake up.

[visdude]

I found those here:

http://www.ebay.com/itm/20PCS-Lot-11x11x5MM-IC-Cooling-Cooler-Mini-Aluminum-Heatsink-For-Chip-Cooling-/221320177126?pt=US_Memory_Chipset_Cooling&hash=item3387b5e5e6

It looks like the same heat sinks that the Chinese vendors package the RPi cases with.

[grn]

Thank you BITMAIN for sorting out our payment issue within 6 hours. it was entirely my error and you fixed it

[WheresWaldo]

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.

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?

sir, ghash vs eligius vs p2pool
pls try these pools with the modified queue and scantime...

hope we can see something WOW here

Yeah if you need, just modify your own config, point them at the two pools and conduct your own tests 

My discarded practically disappeared and my load times were dropped by 1/3 1/2... I am happy enough with this. I can't justify why the same overclock is higher now and why the hashrate more stable

[Duce]

I should also add that with underpowered CPUs that are always overloaded, using a pool with a large coinbase unfortunately will make things worse and increase the CPU usage further. "Generation" coinbases where your coins are generated instead of sent to you (such as those used by Eligius and p2pool) are two examples. That doesn't preclude them from being used, but it's worth experimenting to see if it matters.

Understood, thank you.

[visdude]

Based on the figures thown about on here, I gather that tweaking the S3 to achieve 500 GH/s increases the overall at-the-wall wattage by 32% with only a 14% increase in hash rate.  This 14% hash rate gain by itself also consumes more than twice the energy at 1.83 W/GH/s (2.38x more compared to the stock .77 W/GH/s).  Is it worth it?  Are we getting too carried away with tweaking and modding?  How do these figures affect ROI?  I can't help thinking that this is getting to be about interweb bragging rights on whose S3 achieves 0.5 TH/s.

Perhaps there are some hardcore mathematician/statistician among us that could elaborate on this subject.

[bobsag3]

Based on the figures thown about on here, I gather that tweaking the S3 to achieve 500 GH/s increases the overall at-the-wall wattage by 32% with only a 14% increase in hash rate.  This 14% hash rate gain by itself also consumes more than twice the energy at 1.83 W/GH/s (2.38x more compared to the stock .77 W/GH/s).  Is it worth it?  Are we getting too carried away with tweaking and modding?  How do these figures affect ROI?  I can't help thinking that this is becoming to be about interweb bragging rights on whose S3 achieves 0.5 TH/s.

Perhaps there are some hardcore mathematician/statistician among us that could elaborate on this subject.

It gives those of us with cheaper power or such more options for more hashrate now, and then it can always be dropped back down when diff etc rises

[visdude]

Based on the figures thown about on here, I gather that tweaking the S3 to achieve 500 GH/s increases the overall at-the-wall wattage by 32% with only a 14% increase in hash rate.  This 14% hash rate gain by itself also consumes more than twice the energy at 1.83 W/GH/s (2.38x more compared to the stock .77 W/GH/s).  Is it worth it?  Are we getting too carried away with tweaking and modding?  How do these figures affect ROI?  I can't help thinking that this is becoming to be about interweb bragging rights on whose S3 achieves 0.5 TH/s.

Perhaps there are some hardcore mathematician/statistician among us that could elaborate on this subject.

It gives those of us with cheaper power or such more options for more hashrate now, and then it can always be dropped back down when diff etc rises

That's a very valid point.  Anyway, the overall power consumption is really not that bad at 500 GH/s which is around 0.9 W/GH/s (I just figured this out just now).

[WheresWaldo]

Based on the figures thown about on here, I gather that tweaking the S3 to achieve 500 GH/s increases the overall at-the-wall wattage by 32% with only a 14% increase in hash rate.  This 14% hash rate gain by itself also consumes more than twice the energy at 1.83 W/GH/s (2.38x more compared to the stock .77 W/GH/s).  Is it worth it?  Are we getting too carried away with tweaking and modding?  How do these figures affect ROI?  I can't help thinking that this is getting to be about interweb bragging rights on whose S3 achieves 0.5 TH/s.

Perhaps there are some hardcore mathematician/statistician among us that could elaborate on this subject.

It's actually ~20% power increase.  

Calculating ROI off one unit is just silly.
Look at the difficulty increase from 16.8 to 18.7 in past two weeks. It will continue to get worse. Every week-two weeks your ROI is going to get extended and extended.

If you pay for power or if you don't is the biggest factor in terms of ROI. Either way the small increase of hashrate at the current difficulty should give you multiples more of profit than it is a "power cost"

[Zawamiya]

You guys also need to take account that your s3 would last shorter if you overclock

[WheresWaldo]

You guys also need to take account that your s3 would last shorter if you overclock

Yes but on which basis? Degradation due to voltages? temperature of the chips? There is a higher chance of electric costs being more than the mining profits on these units for many before they die.
If the quality of these units are decent, hopefully they will last long like the heavily overclocked S1's floating out there.