Antminer S3 batch 6 overclocking

[canford]

4. If you've recently started the rig, could you post the cgminer startup string (usually logged in system log ...?)?
From the process tab:
cgminer --bitmain-options 115200:32:8:14:275:0a82 -o stratum+tcp://us1.ghash.io:3333 -O USER.WORKER:Any -o stratum+tcp://stratum.mining.eligius.st:3334 -O ADDR_WORKER:Any -o stratum+tcp://mint.bitminter.com:3333 -O USER_WORKER:PASS --bitmain-nobeeper --api-listen --api-network --bitmain-checkn2diff --bitmain-hwerror --version-file /usr/bin/compile_time --lowmem

I remember reading somewhere that it is not a good idea to run without a queue, rather have a reduced one to the 2048 one that ships. I run mine with  --queue 1024, so you could possibly try  --queue 512 if you are averse to having a long one. (I am not conversant with the why's of this, so please don't ask!)

Here's where that came from, ckolivas's recommendation when he released the S3 binary I am currently using on the OC unit:

Here's an updated S3 binary.

http://ck.kolivas.org/apps/cgminer/antminer/s3/4.6.1-141020/cgminer

Recommended if you're mining on p2pool for the default binary actually discards stale shares which you should never do, especially on p2pool. Also includes changes to queuing and memory usage that were necessary on S4 but probably only of minor benefit here. Recommend you edit the cgminer startup script to remove the --queue value entirely, and add --lowmem. Performance should be pretty much unchanged.

Death spiral on the OC unit definitive now, average down to 523 GH/s.  All chips good with "o", still just the 3 HW errors, temps 42/38.  This would bother me less if I had some explanation for what is happening.

[1715666668]

1715666668

[1715666668]

1715666668

[1715666668]

1715666668

[1715666668]

1715666668

[pekatete]

Here's where that came from, ckolivas's recommendation when he released the S3 binary I am currently using on the OC unit:

Here's an updated S3 binary.

http://ck.kolivas.org/apps/cgminer/antminer/s3/4.6.1-141020/cgminer

Recommended if you're mining on p2pool for the default binary actually discards stale shares which you should never do, especially on p2pool. Also includes changes to queuing and memory usage that were necessary on S4 but probably only of minor benefit here. Recommend you edit the cgminer startup script to remove the --queue value entirely, and add --lowmem. Performance should be pretty much unchanged.

Death spiral on the OC unit definitive now, average down to 523 GH/s.  All chips good with "o", still just the 3 HW errors, temps 42/38.  This would bother me less if I had some explanation for what is happening.

On the queue, I'll take ckolivas' word over what I may recall ...

And yes, that is more like a death spiral, too damn right! I'd have expected it to be flashing x's all over + an increase in HW errors at this point, but then again the new binaries support that --bitmain-hwerror option (or such like) that I have never gotten my head around! I think its that time to try the 0800 setting .... I am convinced it is a heat problem your rigs are encountering due to its consistency in drop-off, so reducing the voltage may help (but may need a power cycle, infact I'd say do one even though I do all my tests initially without one).

[canford]

And yes, that is more like a death spiral, too damn right! I'd have expected it to be flashing x's all over + an increase in HW errors at this point, but then again the new binaries support that --bitmain-hwerror option (or such like) that I have never gotten my head around! I think its that time to try the 0800 setting .... I am convinced it is a heat problem your rigs are encountering due to its consistency in drop-off, so reducing the voltage may help (but may need a power cycle, infact I'd say do one even though I do all my tests initially without one).

OK, I'm going to call it a death spiral now.  98 minutes into the run, 15m hashrate of 375 at the pool, miner reports average dropped to 495.  All chips still "o", temps 41/41, and a total of 5 HW errors.  But I would also expect the symptoms you describe with an overheat, and I'm not seeing them.  No increasing temps, no "x"s on the chips, HW errors still negligible.  Fan speeds are dropping, now 1800-1900, down from 2200-2300.  So the unit is getting cooler as it slows down.  I saw the same behavior on all six units, so we are missing something here.

On the one test unit, I will now try 250/0750, hardware reset then software reset.  Will see what happens!  One thing I am wondering is if we are triggering an internal chip overheat of some kind, that throttles it back but doesn't report a bunch of failures.  So we try to push them harder, and they actually go slower.  But I'm just guessing at this point.

[pekatete]

<snip> .... </snip> But I would also expect the symptoms you describe with an overheat, and I'm not seeing them.  No increasing temps, no "x"s on the chips, HW errors still negligible.  Fan speeds are dropping, now 1800-1900, down from 2200-2300.  So the unit is getting cooler as it slows down. .... <snip> ... </snip>

There, my friend, is the sign you are looking for!

Fan speeds dropping ... unit is getting cooler

That means there are some chips that have gone offline! EDIT: Either that, or the chips are not getting work ..... now you see how that the queue argument was formented in my mind?

[pekatete]

On the one test unit, I will now try 250/0750, hardware reset then software reset.  Will see what happens!  One thing I am wondering is if we are triggering an internal chip overheat of some kind, that throttles it back but doesn't report a bunch of failures.  So we try to push them harder, and they actually go slower.  But I'm just guessing at this point.

Its your rig, but I'd try 275/0800 first. Simply enter the voltage, save and apply then do a power cycle.
On pushing them harder if they are going to throttle back without showing any outward sign ..... that is the question.

[canford]

<snip> .... </snip> But I would also expect the symptoms you describe with an overheat, and I'm not seeing them.  No increasing temps, no "x"s on the chips, HW errors still negligible.  Fan speeds are dropping, now 1800-1900, down from 2200-2300.  So the unit is getting cooler as it slows down. .... <snip> ... </snip>

There, my friend, is the sign you are looking for!

Fan speeds dropping ... unit is getting cooler

That means there are some chips that have gone offline! EDIT: Either that, or the chips are not getting work ..... now you see how that the queue argument was formented in my mind?

Does it?  Why are all chips still reporting "o" and not "-" or "x"?  That is why I'm wondering about the internal throttling.  There should be plenty of work, I have tried leaving queue at default as well as deleting queue parameter completely.  I have not tried --queue 1024 yet though.  But I saw the same result with two different pools and with and without deletion of the parameter.

New test run started: 1024 firmware, 250/0750, queue left at stock, cgminer left at stock.  Only change to stock is the additional options in cgminer.lua, which do not change the 250 values.

[pekatete]

New test run started: 1024 firmware, 250/0750, queue left at stock, cgminer left at stock.  Only change to stock is the additional options in cgminer.lua, which do not change the 250 values.

OK, I need to catch up on my sleep ..... getting to 2am where I am so I'll pick up from where you got to in a several hours' time.

[canford]

On the one test unit, I will now try 250/0750, hardware reset then software reset.  Will see what happens!  One thing I am wondering is if we are triggering an internal chip overheat of some kind, that throttles it back but doesn't report a bunch of failures.  So we try to push them harder, and they actually go slower.  But I'm just guessing at this point.

Its your rig, but I'd try 275/0800 first. Simply enter the voltage, save and apply then do a power cycle.
On pushing them harder if they are going to throttle back without showing any outward sign ..... that is the question.

Sorry, missed this post.  I will try 275/0800 after we see what happens with 250/0750.  My procedure lately is to put in freq/volt, save & apply, power cycle, then system/reboot.  I added on the last step after just a power cycle would result in bad stats in Miner Status.  Have you tried OC on an S3+ with factory thermal paste?  The six I am working with are untouched.  So if it is a chip-level thermal problem that is not reported to the sw, then I guess that could explain the difference here.

[pekatete]

Sorry, missed this post.  I will try 275/0800 after we see what happens with 250/0750.  My procedure lately is to put in freq/volt, save & apply, power cycle, then system/reboot.  I added on the last step after just a power cycle would result in bad stats in Miner Status.

I used to have that issue (and always had to do an SSH reboot after a power cycle). Of late, though, it seems to have been fixed .... all I did once is before I rebooted via SSH, I first went into the System -> Start Up tab and stopped cgminer, then entered reboot in the SSH window. Now the stats are OK after a brutal power cycle .... (but I was called names when I mentioned the stats problem on this forum!)

Have you tried OC on an S3+ with factory thermal paste?  The six I am working with are untouched.  So if it is a chip-level thermal problem that is not reported to the sw, then I guess that could explain the difference here.

I did OC one S3+ before I redid the paste which worked OK at 262.5 (which was the only "good" freq I had at the time). I now redo all the S3's I get by, at the very least, putting heat-pads on the chips, so for now all have been "modded" if you like.

[canford]

It took longer, but 250/0750 also a dead end.  Over 500 first hour, then down.  After 3h down to 485 average, 458 last hour on the pool.  All "o" on the chips and only 1 HW.  Dropping to 243/0750 for the next run.

[canford]

My procedure lately is to put in freq/volt, save & apply, power cycle, then system/reboot.  I added on the last step after just a power cycle would result in bad stats in Miner Status.

I used to have that issue (and always had to do an SSH reboot after a power cycle). Of late, though, it seems to have been fixed .... all I did once is before I rebooted via SSH, I first went into the System -> Start Up tab and stopped cgminer, then entered reboot in the SSH window. Now the stats are OK after a brutal power cycle .... (but I was called names when I mentioned the stats problem on this forum!)

It doesn't happen every time, but a significant % of power cycles result in Miner Status using the previous elapsed time, so everything gets pushed lower.  A warm reboot always results in the correct outcome.  This is a funny hobby to have, these things have minds of their own.

[canford]

It took longer, but 250/0750 also a dead end.  Over 500 first hour, then down.  After 3h down to 485 average, 458 last hour on the pool.  All "o" on the chips and only 1 HW.  Dropping to 243/0750 for the next run.

243/0750 also a dead end, dropped to 4h running average of 471, with last hour on the pool at 449.  Trying 237/0750.

I also started playing with the slowest of the others (225 for 453, no voltage change).  Trying 250/0750, and so far 2 hours in it is rock solid at the expected 504.  Not going to count those chickens, will see what it looks like tomorrow.

[canford]

It took longer, but 250/0750 also a dead end.  Over 500 first hour, then down.  After 3h down to 485 average, 458 last hour on the pool.  All "o" on the chips and only 1 HW.  Dropping to 243/0750 for the next run.

243/0750 also a dead end, dropped to 4h running average of 471, with last hour on the pool at 449.  Trying 237/0750.

I also started playing with the slowest of the others (225 for 453, no voltage change).  Trying 250/0750, and so far 2 hours in it is rock solid at the expected 504.  Not going to count those chickens, will see what it looks like tomorrow.

237 was repeated "x" from chips over four reboots, so bailed.  231 was 428 over an hour at the pool, also bailed.  That unit just doesn't want to OC.  Reverted to 225/no-volt.

Other unit, however, continues to hum along at 504 after 5h.  I do not understand these things.

[pekatete]

It took longer, but 250/0750 also a dead end.  Over 500 first hour, then down.  After 3h down to 485 average, 458 last hour on the pool.  All "o" on the chips and only 1 HW.  Dropping to 243/0750 for the next run.

243/0750 also a dead end, dropped to 4h running average of 471, with last hour on the pool at 449.  Trying 237/0750.

I also started playing with the slowest of the others (225 for 453, no voltage change).  Trying 250/0750, and so far 2 hours in it is rock solid at the expected 504.  Not going to count those chickens, will see what it looks like tomorrow.

237 was repeated "x" from chips over four reboots, so bailed.  231 was 428 over an hour at the pool, also bailed.  That unit just doesn't want to OC.  Reverted to 225/no-volt.

Other unit, however, continues to hum along at 504 after 5h.  I do not understand these things.

I noticed that repeated x's clear when you restart cgminer e.g via the System Start Up tab (which also happens when you Save & Apply settings) - just saying so you can reduce your restart / reboot cycle length.

Been said a lot of times. S3's are the same, but different ..... most of the S3 variants in my stable run best at different settings, and those with the same settings, on the same pool, over the same connection produce differing results! So there goes.

[canford]

It took longer, but 250/0750 also a dead end.  Over 500 first hour, then down.  After 3h down to 485 average, 458 last hour on the pool.  All "o" on the chips and only 1 HW.  Dropping to 243/0750 for the next run.

243/0750 also a dead end, dropped to 4h running average of 471, with last hour on the pool at 449.  Trying 237/0750.

I also started playing with the slowest of the others (225 for 453, no voltage change).  Trying 250/0750, and so far 2 hours in it is rock solid at the expected 504.  Not going to count those chickens, will see what it looks like tomorrow.

237 was repeated "x" from chips over four reboots, so bailed.  231 was 428 over an hour at the pool, also bailed.  That unit just doesn't want to OC.  Reverted to 225/no-volt.

Other unit, however, continues to hum along at 504 after 5h.  I do not understand these things.

I noticed that repeated x's clear when you restart cgminer e.g via the System Start Up tab (which also happens when you Save & Apply settings) - just saying so you can reduce your restart / reboot cycle length.

Been said a lot of times. S3's are the same, but different ..... most of the S3 variants in my stable run best at different settings, and those with the same settings, on the same pool, over the same connection produce differing results! So there goes.

All three OC experiments failed.  Both of the other units I tried 250/0750 with looked fantastic for the first hour, then slid into slow decline without any symptoms other than declining hashrate.  They bottomed out at about 430 after 12 hours.  Reverting to stock and taking a break!

[pekatete]

All three OC experiments failed.  Both of the other units I tried 250/0750 with looked fantastic for the first hour, then slid into slow decline without any symptoms other than declining hashrate.  They bottomed out at about 430 after 12 hours.  Reverting to stock and taking a break!

I am not by any means disputing your results as that would be futile, however if I may point out my experience with S3's, it is very rare that you find any two units hashing the same, even when using similar freq & voltage settings, PSU and connected to the same pool.

In your case however, that you have experienced the same wall of performance after the first hour, and that happening on most of your units, leads me to believe the issue must be local to your setup.

My first instinct was a heat / temperature problem, however, you seem to discount this as a possibility, and that the units run as normal on stock frequencies seems to justify that. I am not completely sold though since I have never run an S3 variant at temps as high as yours. Before the season change and my moving my rigs outside, I had them all running the fans at full pelt, aka blue wire hack, which kept the temps low, and now that the seasons have changed and my rigs reside in the garden, my temps are a lot lower.

My second guess is how you are powering your rigs. Though you appear to have the right PSU's, this may be a cause if you have them all plugged into the same extension lead. They may not trip your circuit, but they will compete for power, especially if you are running them off a 110v circuit.

If you choose to attempt the OC again, I wish you luck, but I think in your instance I have given as much help as I possibly can, bearing in mind I am neither an engineer nor an electrician.

[canford]

All three OC experiments failed.  Both of the other units I tried 250/0750 with looked fantastic for the first hour, then slid into slow decline without any symptoms other than declining hashrate.  They bottomed out at about 430 after 12 hours.  Reverting to stock and taking a break!

I am not by any means disputing your results as that would be futile, however if I may point out my experience with S3's, it is very rare that you find any two units hashing the same, even when using similar freq & voltage settings, PSU and connected to the same pool.

In your case however, that you have experienced the same wall of performance after the first hour, and that happening on most of your units, leads me to believe the issue must be local to your setup.

My first instinct was a heat / temperature problem, however, you seem to discount this as a possibility, and that the units run as normal on stock frequencies seems to justify that. I am not completely sold though since I have never run an S3 variant at temps as high as yours. Before the season change and my moving my rigs outside, I had them all running the fans at full pelt, aka blue wire hack, which kept the temps low, and now that the seasons have changed and my rigs reside in the garden, my temps are a lot lower.

My second guess is how you are powering your rigs. Though you appear to have the right PSU's, this may be a cause if you have them all plugged into the same extension lead. They may not trip your circuit, but they will compete for power, especially if you are running them off a 110v circuit.

If you choose to attempt the OC again, I wish you luck, but I think in your instance I have given as much help as I possibly can, bearing in mind I am neither an engineer nor an electrician.

Thanks for trying to help!  I am both an engineer and an electrician.  I do not think I have power issues, as all 6 units are running from Corsair 750 or 800W supplies, with all four PCI-E connectors well seated.  Three power supplies are on one 20A 120V circuit, and three are on another.  So there is plenty of spare power.

I think what is happening is a slow overheating.  Interestingly, the S3s do not appear to respond by increasing the fan speeds, instead the hash rate goes down as we have discussed.  All six units are in a well ventilated space that stays around 18C.  The S3s report temps around 39-42C, so not very high.

If I find the time, I may try redoing the paste and/or maxing the fan speeds to see if that helps.  I will also keep an eye out for any S3 firmware updates that fix something.  For now, I have concluded that my six units are not overclockable other than the slight bump I get from setting the frequencies to 225/231/243/237/225/237 for the six.

Very frustrating to see such promising hashrate increases in the first hour, but then nothing sustainable.  But overall I am impressed with the units, they are all working to spec and running just fine.

[kaltar]

Even though this thread is a bit old, i just wanted to stop by and tell you that YOU my friend are a GOD.

i followed your instructions and my s3+ is doing 553gh stable, with very little HW like 0.0002% for 48hours.
tonight i will doing my other 5 units

Happy Hashing to everyone

[Bicknellski]

Still running your S3's Pek?

[pekatete]

Still running your S3's Pek?

Yep, still running them ...