Antminer S3 batch 6 overclocking

[pekatete]

Have anyone damaged a unit by OCing to like 250?

Or is it "safe" to just max them out? (if you don't get high numbers of HW-error)...

It there anything ells that I should look out for while OC to know if i run them to hard?

Best regards, and happy Halloween!

/Badz

So long as you have the unit powered properly (and you do not mind the increase in power consumption), then clock to your pleasure. Of-course when errors start geting out of hand e.g > .99% (with the new firmware you can check the %) then keep going! I have an upgraded S1 to S3 unit that is running at freq 268.5 with ~539 GH/s, however, my S3's won't go beyond 262 without the HW getting "out of hand".
PS. My guide to HW % is just mine, not official and I have not seen anyone recomend it anywhere. Follow at your own risk!

[1714052290]

1714052290

[moss]

Even with the new cgminer file, my units are doing a little worse than with the previous one. I am guessing I am losing around 10-14 GH/s per device, which is not bad but when you have 11 of them it makes a slight difference.

Do you have the latest firmware on them? i had exactly the same experience with my batch 6 units and reverted to the stock cgminer, however (again as is documented in this thread), when I updated to the latest firmware, which I had to do when upgrading my S1's, I get the same result as the stock, or slightly better, but with the security flaws plugged.

Yeah I have the latest firmware, it is dated 8/26/2014. My issue is probably the 5 batch 1 miners I have, even though some of my batch 5 units are a little slow as well.

Yep, the earlier batches do not seem to be up to it. I suspect it is due to their poor temp handling and suggested to someone to re-do their heat paste; Though he had some good results using a conductive compound, he re-applied using a non conductive paste and has not reported their results. With several units .... that would be a day's work! Worth it? Not sure.

Hi m8, not sure if it's me you're thinking of above, but I did have my best results with Arctic Silver conductive paste and my latest application of Zalman paste was a lot of effort for not much reward.  I've just bought some Innovation Cooling IC Diamond 7-Carat thermal compound, so will give that a whirl when I have a chance.  Still deliberating about doing the big central heatsinks - presumably this involves removing the blades?  Is that a straightforward process?  I get funny results with my asics at different frequencies: one 'x' always shows up at 225, but not at higher frequencies and similarly with some of the others, so although I always get an 'x' at higher frequencies somewhere, it's often in different places.  Also, my hashrate is rubbish at higher freqs anyway now, it only goes quicker at 231 and that doesn't seem to last long.  I tend to keep it at the default 118 now and main task is to stop my hashrate dwindling away, which gradually seems to happen on my problem s3.
BTW, I've upgraded to ck's latest cgminer (4.6.1-141020) and seems ok so far - no restarts, etc.  I also removed --queue 4096 and added --lowmem in the cgminer startup script, as recommended by ck.
 

Yes moss, that was a reference to you, and thanks for updating us. Bummer about having to run at stock freqs ...
Removing board from the heatsink does not involve much more than removing the top heatsink, just another set of screws then you slide it off (you do not have to unscrew the heatsinks from the braces).
I have not tried adding the --lowmem switch yet as I do not readily know the process, but will dig around tonite (or tomorow) and try it.
Thanks again for keeping us up to date.

Hi m8.  Another little update...  I tried to do the big heatsinks between the boards, but could not remove one of the screws (as you know, they go through the board itself) whatever I tried - the others were very tight too, but I managed those. In the end, I gave up on that part of the plan. However, the rest of the plan seems to have worked well: I redid the outer heatsinks using Diamond 7-Carat thermal compound and I fitted little heatsinks on the DC-DC converter chips.  Since doing that, the problem S3 has sat solidly at 440 Ghash/s for weeks.  So a big result (so far...).  

Edit:  Hmmm.  My first forced reboot today (19th Nov) of the problem S3 since 'fixing' it.  Average hash was heading south, after being rock solid for weeks.  Didn't see that coming...
Edit2: Lost my average hash reading (again), so updated to latest firmware to see if that improved things.  Ran reliably at 440 Ghash/s until 23rd Nov, when it suddenly stopped hashing and started beeping for 5 minutes.  Couldn't find anything wrong via the web interface and it suddenly started working again - back at 440Ghash/s.  Other S3 on same router not affected.  Don't know what caused that...

[pekatete]

New post overcloking with voltage setting in new firmware: https://bitcointalk.org/index.php?topic=883197.0

[moss]

New post overcloking with voltage setting in new firmware: https://bitcointalk.org/index.php?topic=883197.0

I just tried this and after building up to normal speed, the hashrate dropped back down to about 1.3GH/s a few minutes later.  I checked the frequency and it was set as expected.  The hashrate started increasing again, but quite slowly, so I decided to reflash to the previous firmware for now.
Have you tried it yet?

[pekatete]

New post overcloking with voltage setting in new firmware: https://bitcointalk.org/index.php?topic=883197.0

I just tried this and after building up to normal speed, the hashrate dropped back down to about 1.3GH/s a few minutes later.  I checked the frequency and it was set as expected.  The hashrate started increasing again, but quite slowly, so I decided to reflash to the previous firmware for now.
Have you tried it yet?

I've just updated the thread with a 24hr comparison of my previous OC @ 262.5 and the HW rate has drastically reduced.
I can pretty much guarrantee that this will work for all BM1382 boards, it just depends on whether you want to do it. First, run it at a frequency within the bitmain spec (the black numbers in the last table) with the voltage set. The rate will take a while to settle and will at the very least match the spec rate (expected hash in the last table), but more likely beat it (as I have demonstrated). More important though, is the lower HW rate (and again, do not jump at conclusions after the first half hour, let it run for a few hours).
If you feel the HW rate is low enough (even not and just feel like it!), turn up the freq within that voltage range (this is mine through my tests not bitmain's) and you should be OK.

For the 262.5 freq test, the voltage setting is 0750, which is the datasheet voltage for freq 250. Start with 250 and I bet you'll get very few HW errors and a good hash speed, then if you feel like it, turn up the freq and watch your hash-speed increase, with still few HW errors.

[moss]

New post overcloking with voltage setting in new firmware: https://bitcointalk.org/index.php?topic=883197.0

I just tried this and after building up to normal speed, the hashrate dropped back down to about 1.3GH/s a few minutes later.  I checked the frequency and it was set as expected.  The hashrate started increasing again, but quite slowly, so I decided to reflash to the previous firmware for now.
Have you tried it yet?

I've just updated the thread with a 24hr comparison of my previous OC @ 262.5 and the HW rate has drastically reduced.
I can pretty much guarrantee that this will work for all BM1382 boards, it just depends on whether you want to do it. First, run it at a frequency within the bitmain spec (the black numbers in the last table) with the voltage set. The rate will take a while to settle and will at the very least match the spec rate (expected hash in the last table), but more likely beat it (as I have demonstrated). More important though, is the lower HW rate (and again, do not jump at conclusions after the first half hour, let it run for a few hours).
If you feel the HW rate is low enough (even not and just feel like it!), turn up the freq within that voltage range (this is mine through my tests not bitmain's) and you should be OK.

For the 262.5 freq test, the voltage setting is 0750, which is the datasheet voltage for freq 250. Start with 250 and I bet you'll get very few HW errors and a good hash speed, then if you feel like it, turn up the freq and watch your hash-speed increase, with still few HW errors.

Thanks pekatete.  Much appreciated.  I'll try it again over the weekend.
Cheers.

[pekatete]

Updated OP with freq 275 OC with voltage setting.

[canford]

I continue to find this extremely frustrating.  I am running 6 S3+ units, each supplied by a 750-800W power supply with a single 12V rail and all four PCI-E connectors connected.  I tried the 275/0815 settings, and exactly the same thing happened as the last time.  Hour 1: fantastic, all units over 500 GH/s, holy crap why did I not do this earlier.  Hour 2: OK, but hashrates down both as reported by units and at the pool.  Hour 3: terrible, all hashrates reported by units and by pool way below stock results.  So I have yet again reverted everything to 225/231/243/237/225/237 with voltage left blank.

I do not understand the mechanism here.  If it is heat, why does it take 2 hours to show up?  With the OC settings, all chips show up as "o" and working.  But the hashrate results speak for themselves.  But why the very prominent jump in hashrate for the first hour, but then utter crap out in hour 3?  Can anybody explain this?

[pekatete]

I continue to find this extremely frustrating.  I am running 6 S3+ units, each supplied by a 750-800W power supply with a single 12V rail and all four PCI-E connectors connected.  I tried the 275/0815 settings, and exactly the same thing happened as the last time.  Hour 1: fantastic, all units over 500 GH/s, holy crap why did I not do this earlier.  Hour 2: OK, but hashrates down both as reported by units and at the pool.  Hour 3: terrible, all hashrates reported by units and by pool way below stock results.  So I have yet again reverted everything to 225/231/243/237/225/237 with voltage left blank.

I do not understand the mechanism here.  If it is heat, why does it take 2 hours to show up?  With the OC settings, all chips show up as "o" and working.  But the hashrate results speak for themselves.  But why the very prominent jump in hashrate for the first hour, but then utter crap out in hour 3?  Can anybody explain this?

Just a few pointers that may help:
1. The voltage setting from the datasheet for the freq of 275 is both 0800 and 0850, so you can try anything within / around that range.
2. Hash rate falling in a few hours is NOT the "end of the day". Overall hash-rate is what matters in the long run (I usually let it run for 12 - 24hrs). If you are not getting X's on chips when the hash-rate is falling, I'd let it run as long as this did NOT coincide with a sustained increase in HW errors.
3. Do not be spooked by a fairly high HW error % at the start, and here I mean if the rate is less than or around 0.01 in the first few minutes to an hour, let it run.

S3 variants are the same but handle differently, so you may have to try different voltage settings (even freq settings). For example, the 262.5 freq does not ship from bitmain, but it turns out to be a sweet spot for most S3 variants!

[IITravel01]

I continue to find this extremely frustrating.  I am running 6 S3+ units, each supplied by a 750-800W power supply with a single 12V rail and all four PCI-E connectors connected.  I tried the 275/0815 settings, and exactly the same thing happened as the last time.  Hour 1: fantastic, all units over 500 GH/s, holy crap why did I not do this earlier.  Hour 2: OK, but hashrates down both as reported by units and at the pool.  Hour 3: terrible, all hashrates reported by units and by pool way below stock results.  So I have yet again reverted everything to 225/231/243/237/225/237 with voltage left blank.

I do not understand the mechanism here.  If it is heat, why does it take 2 hours to show up?  With the OC settings, all chips show up as "o" and working.  But the hashrate results speak for themselves.  But why the very prominent jump in hashrate for the first hour, but then utter crap out in hour 3?  Can anybody explain this?

Which firmware are you using?

[canford]

I continue to find this extremely frustrating.  I am running 6 S3+ units, each supplied by a 750-800W power supply with a single 12V rail and all four PCI-E connectors connected.  I tried the 275/0815 settings, and exactly the same thing happened as the last time.  Hour 1: fantastic, all units over 500 GH/s, holy crap why did I not do this earlier.  Hour 2: OK, but hashrates down both as reported by units and at the pool.  Hour 3: terrible, all hashrates reported by units and by pool way below stock results.  So I have yet again reverted everything to 225/231/243/237/225/237 with voltage left blank.

I do not understand the mechanism here.  If it is heat, why does it take 2 hours to show up?  With the OC settings, all chips show up as "o" and working.  But the hashrate results speak for themselves.  But why the very prominent jump in hashrate for the first hour, but then utter crap out in hour 3?  Can anybody explain this?

Which firmware are you using?

I am using the 1024 firmware, the only change on top of that is adding the new frequencies into cgminer.lua.  All six units stable again at the lower frequencies with no voltage setting.

[canford]

I continue to find this extremely frustrating.  I am running 6 S3+ units, each supplied by a 750-800W power supply with a single 12V rail and all four PCI-E connectors connected.  I tried the 275/0815 settings, and exactly the same thing happened as the last time.  Hour 1: fantastic, all units over 500 GH/s, holy crap why did I not do this earlier.  Hour 2: OK, but hashrates down both as reported by units and at the pool.  Hour 3: terrible, all hashrates reported by units and by pool way below stock results.  So I have yet again reverted everything to 225/231/243/237/225/237 with voltage left blank.

I do not understand the mechanism here.  If it is heat, why does it take 2 hours to show up?  With the OC settings, all chips show up as "o" and working.  But the hashrate results speak for themselves.  But why the very prominent jump in hashrate for the first hour, but then utter crap out in hour 3?  Can anybody explain this?

Which firmware are you using?

I am using the 1024 firmware, the only change on top of that is adding the new frequencies into cgminer.lua.  All six units stable again at the lower frequencies with no voltage setting.

Trying again on one unit, this time with ckolivas's S3 cgminer 4.6.1 build, also deleting --queue and adding --lowmem.  I can't think of anything else to try.  The S3's are in a ventilated space, so the ambient temperature over the three hour period is constant.  Why would I get great results for 1+ hours, but poor results over 3 hours?

[pekatete]

I am using the 1024 firmware, the only change on top of that is adding the new frequencies into cgminer.lua.  All six units stable again at the lower frequencies with no voltage setting.

Trying again on one unit, this time with ckolivas's S3 cgminer 4.6.1 build, also deleting --queue and adding --lowmem.  I can't think of anything else to try.  The S3's are in a ventilated space, so the ambient temperature over the three hour period is constant.  Why would I get great results for 1+ hours, but poor results over 3 hours?
[/quote]

Possibly easier to simply post a shot of your web UI, but I'll ask just in case:
1. What temps do you have on that rig?
2. What is the HW %
3. What freq are you running at?
4. If you've recently started the rig, could you post the cgminer startup string (usually logged in system log ...?)?
5. Finally, could you also post the freq setting line that you are running from the cgminer.lua file?

[canford]

I am using the 1024 firmware, the only change on top of that is adding the new frequencies into cgminer.lua.  All six units stable again at the lower frequencies with no voltage setting.

Trying again on one unit, this time with ckolivas's S3 cgminer 4.6.1 build, also deleting --queue and adding --lowmem.  I can't think of anything else to try.  The S3's are in a ventilated space, so the ambient temperature over the three hour period is constant.  Why would I get great results for 1+ hours, but poor results over 3 hours?

Possibly easier to simply post a shot of your web UI, but I'll ask just in case:
1. What temps do you have on that rig?
Right now showing 43 & 42 25 minutes in (and reporting 538 GH/s avg), it don't think it got above 44 the last time I tried it.  Ambient temp in the room 18C.

2. What is the HW %
0 (zero).  Last try it got a an occasional HW error, but they were minor.  One of the six units got a bogged down in HW errors, but then performed well when I dropped the frequency to 268.

3. What freq are you running at?
275/0815 target, last night's test I ran five that way, then the one I dropped to 268/0815.

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

5. Finally, could you also post the freq setting line that you are running from the cgminer.lua file?
pb:value("14:275:0a82", translate("275M"))
[/quote]

Thanks for the help! Answers above in bold.

[pekatete]

3. What freq are you running at?
275/0815 target, last night's test I ran five that way, then the one I dropped to 268/0815.

Did you try 275/0800 before 275/0815?
The datasheet states 2 voltages for that freq, 0800 and 0850. You should try 0800 first and increment if you get LOTS of HW errors or a very low hash-rate. For freq 275, you should have hit at least 550 Gh/s(avg) in the hour IF your HW % is low and no x's showing. EDIT: Saying that, the 538 you are getting with no HW errors is not bad either but I should expect your rig to give at least 550.

PS. I think you'll have to start one machine at a time .... also, I'll address the other bits as and when ...

[pekatete]

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!)

[pekatete]

2. What is the HW %
0 (zero).  Last try it got a an occasional HW error, but they were minor.  One of the six units got a bogged down in HW errors, but then performed well when I dropped the frequency to 268.

I assume that when your avg hash-rate falls you restart(ed) immediately, so seeing you have no HW errors, could you let it run for at least an hour after that and see whether you get any HW errors and / or x's on the chips?
I also noticed that the 5s hash-rate flactuates whenever a new block is started / a block is about to end, but soon builds up, so that may be something you have to bear in mind (assuming your hash-rate recovers!).

[canford]

Did you try 275/0800 before 275/0815?

Not this time, just went with 0815.  1 hour in now, showing average 539 GH/s.  You can see the slowdown starting though, average is decreasing, and temps now 42/38.  I am consistently getting 1 hour of improved performance, then the slowdown starts.

[canford]

2. What is the HW %
0 (zero).  Last try it got a an occasional HW error, but they were minor.  One of the six units got a bogged down in HW errors, but then performed well when I dropped the frequency to 268.

I assume that when your avg hash-rate falls you restart(ed) immediately, so seeing you have no HW errors, could you let it run for at least an hour after that and see whether you get any HW errors and / or x's on the chips?
I also noticed that the 5s hash-rate flactuates whenever a new block is started / a block is about to end, but soon builds up, so that may be something you have to bear in mind (assuming your hash-rate recovers!).

Unit hashrate dropping sharply now after the 1 hour run, average down to 533.  HW errors now 3 for 0.0093%.

If hashrate keeps falling, I will report the numbers and try again with 0800.

I'm only going to try this with the one unit, the improvement was so dramatic the last time that when it was solid for an hour, I upgraded all 6.  But I have yet to have an OC last more than 90 minutes or so.

[pekatete]

2. What is the HW %
0 (zero).  Last try it got a an occasional HW error, but they were minor.  One of the six units got a bogged down in HW errors, but then performed well when I dropped the frequency to 268.

I assume that when your avg hash-rate falls you restart(ed) immediately, so seeing you have no HW errors, could you let it run for at least an hour after that and see whether you get any HW errors and / or x's on the chips?
I also noticed that the 5s hash-rate flactuates whenever a new block is started / a block is about to end, but soon builds up, so that may be something you have to bear in mind (assuming your hash-rate recovers!).

Unit hashrate dropping sharply now after the 1 hour run, average down to 533.  HW errors now 3 for 0.0093%.

If hashrate keeps falling, I will report the numbers and try again with 0800.

I'm only going to try this with the one unit, the improvement was so dramatic the last time that when it was solid for an hour, I upgraded all 6.  But I have yet to have an OC last more than 90 minutes or so.

That's fair enough, if it is falling that quickly into its uptime, and now registering errors, I expect you'll soon enough see x's on chips too, and if that happened would explain the consistent hash-rate drop-off very well ...... temp build-up!

EDIT: You'll probably have a better run with the 0800 setting .... but see this out for now to get a definitive result.