ANTMINER S3+ Discussion and Support Thread - page 372.

WheresWaldo

full member

Activity: 210

Merit: 100

Quote from: -ck on July 27, 2014, 12:34:02 AM

Quote from: WheresWaldo on July 27, 2014, 12:30:01 AM

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 Tongue

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? Tongue

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

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.

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Quote from: Lowell904 on July 27, 2014, 12:44:49 AM

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.

Lowell904

member

Activity: 119

Merit: 10

Quote from: -ck on July 27, 2014, 12:34:02 AM

Quote from: WheresWaldo on July 27, 2014, 12:30:01 AM

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 Tongue

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

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Quote from: WheresWaldo on July 27, 2014, 12:30:01 AM

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 Tongue

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.

padrino

legendary

Activity: 1428

Merit: 1000

https://www.bitworks.io

Quote from: Lowell904 on July 27, 2014, 12:14:53 AM

Quote from: -ck on July 26, 2014, 11:50:55 PM

Quote from: ?? on ??

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..

WheresWaldo

full member

Activity: 210

Merit: 100

Quote from: Duce on July 27, 2014, 12:28:07 AM

Quote from: -ck on July 26, 2014, 11:50:55 PM

Quote from: ?? on ??

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.

Quote from: R4v37 on July 27, 2014, 12:05:45 AM

Quote from: -ck on July 26, 2014, 11:50:55 PM

Quote from: ?? on ??

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 Grin

without modifying anything...
tested at Ghash, the discarded will be 10times of accepted <0
tested at Eligius, the Discarded will be as low as 0.01 x accepted <tested at P2pool, same result 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 Tongue

There is a reason these options are here for us to optimize with the specific hardware we use!

Lowell904

member

Activity: 119

Merit: 10

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

Duce

full member

Activity: 175

Merit: 100

Quote from: -ck on July 26, 2014, 11:50:55 PM

Quote from: ?? on ??

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.

WheresWaldo

full member

Activity: 210

Merit: 100

Quote from: Lowell904 on July 26, 2014, 11:44:17 PM

Quote from: R4v37 on July 26, 2014, 11:08:39 PM

Nice. Please let us know if you see improvements.

He put heatsinks on the chokes, there really isn't any performance to gain by doing this.
Hopefully those have good thermal adhesive and dont fall off and short his board to kill his unit.
Would be more beneficial to have heatsinks on the actual small chip above the chokes. Either way, none of this should affect hashrate but may increase the longevity of the unit.

Lowell904

member

Activity: 119

Merit: 10

Quote from: -ck on July 26, 2014, 11:50:55 PM

Quote from: ?? on ??

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.

R4v37

sr. member

Activity: 266

Merit: 250

Quote from: -ck on July 26, 2014, 11:50:55 PM

Quote from: ?? on ??

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 Grin

without modifying anything...
tested at Ghash, the discarded will be 10times of accepted <0
tested at Eligius, the Discarded will be as low as 0.01 x accepted <tested at P2pool, same result 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

ZiG

sr. member

Activity: 406

Merit: 250

Quote from: -ck on July 26, 2014, 11:50:55 PM

Quote from: ?? on ??

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.

What is your recommendation(s), Boss... Grin

ZiG

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Quote from: ?? on ??

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.

Lowell904

member

Activity: 119

Merit: 10

Quote from: R4v37 on July 26, 2014, 11:08:39 PM

Nice. Please let us know if you see improvements.

grn

sr. member

Activity: 357

Merit: 252

Quote from: philipma1957 on July 26, 2014, 10:23:08 PM

Quote from: grn on July 26, 2014, 10:18:31 PM

Quote from: smracer on July 26, 2014, 09:58:54 PM

Quote from: messieuredouchebag on July 26, 2014, 07:21:34 PM

I put a six gauge wire on a 70 amp circuit breaker, from my main 200 amp fuse box to a spare room, how many s3's will I be able to run on that circuit, air conditioner is on a separate 20 amp breaker.

thanks in advance

70amp double pole? You can pull 56 constant amps through each wire at 120V each.

You could run about 34-36 S3's off that depending on how good your PSU's are.

It will get warm.

Stop right now. Call an electrician and get him/her to install a sub panel, tell the electrician your power needs. Do this before you burn your house down and void your insurance

edit: get permits and have it all inspected

in New Jersey, USA

you don't need an electrician if you own the home and you live in it. You do need a permit and an inspection.

Thats true in most US and Canadian jurasdictions. Still Call an electrician

R4v37

sr. member

Activity: 266

Merit: 250

WheresWaldo

full member

Activity: 210

Merit: 100

Quote from: Lowell904 on July 26, 2014, 07:44:48 PM

Quote from: faetos on July 26, 2014, 12:12:06 AM

Quote from: Lowell904 on July 25, 2014, 11:56:57 PM

Quote from: faetos on July 25, 2014, 11:19:38 PM

Quote from: Duce on July 25, 2014, 11:05:52 PM

Quote from: faetos on July 25, 2014, 11:01:18 PM

Quote from: Xian01 on July 25, 2014, 10:40:39 PM

Quote from: ?? on ??

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***

Thanks for this post ! Going to try this on one of my units and see how it works out.

This was default on the new firmware:

PARAMS="$AOPTIONS $POOL1 $POOL2 $POOL3 $_pb $_ow $_bec --api-listen --api-network --bitmain-checkn2diff --bitmain-hwerror --queue 4096"

I tried it on one by adding the --scan-time 1 --expiry 1 flags, but didn't see any difference in discards or load. Maybe some of you will have better luck.

Did you change the Queue to 0?

that I did not do - misread what you wrote. YES!! Just changed it and am seeing really good numbers. Discards are negligible now - 20 accepts and 3 discards. Load dropped from high 2s to under 2. AWESOME!!!!! You rock!

Since I've never SSH one of these, I don't want to risk bricking it.

If this fix turns out to be solid though, I hope Bitmain will include it in the next firmware release.

Or maybe I'll learn to SSH. On a side note. Does anyone know if you can get a better GHS/watt ratio by under-clocking the S1?

I'll tell you how to do it, but not going to go into every detail (how to SSH, sed, etc). Not responsible for you f'ing your stuff up.

1. SSH into the miner
2. cd /etc/init.d
3. cp cgminer cgminer.bak (in case you really muck it up, cgminer.bak will be your backup)
4. Enter this in the terminal: sed -i 's/--queue 4096"/--queue 0 --scan-time 1 --expiry 1"/g' cgminer
5. press enter
6. go to the web interface of the miner - Status > Miner Configuration > Save & Apply - this will restart cgminer with the new settings
7. go tip Duce for figuring this out for us

Duce, where's your tip jar? I owe you.

This is what you're changing:

Original --> PARAMS="$AOPTIONS $POOL1 $POOL2 $POOL3 $_pb $_ow $_bec --api-listen --api-network --bitmain-checkn2diff --bitmain-hwerror --queue 4096"

New & Improved --> PARAMS="$AOPTIONS $POOL1 $POOL2 $POOL3 $_pb $_ow $_bec --api-listen --api-network --bitmain-checkn2diff --bitmain-hwerror --queue 0 --scan-time 1 --expiry 1"

//S1 undervolt guide - https://bitcointalksearch.org/topic/m.5838713

I'm attempting this mod, but when I enter sed -i 's/--queue 4096"/--queue 0 --scan-time 1 --expiry 1"/g' cgminer into putty, I get "no such file or directory". Does anyone know what I am doing wrong, I'm afraid to go much further.

this guide is better https://bitcointalksearch.org/topic/m.8040869

Quote from: Biodom on July 26, 2014, 07:35:49 PM

Quote from: WheresWaldo on July 26, 2014, 07:02:48 PM

Overnight run Grin

so far so good...

~450watts for ~500gh/s

I think the massive HW spike is from internet outtage, it was at 40HW very early in the morning. Who knows. Either way it's minimal compared to 22,000 shares at 256 diff ( ~5mil shares )

Did you mod this machine?
Looks awesome

I did not! set it to 250 frequency and let it run.

I am surprised at the low HW errors, problem is, just like shares, is the HW need to be multiplied by any value? or is it 100 HW errors at 256diff then 256,000 HW errors?
Things are difficult without the cgminer software window open Grin

Quote from: Stinky_Pete on July 26, 2014, 07:28:23 PM

Quote from: WheresWaldo on July 26, 2014, 07:02:48 PM

Overnight run Grin

so far so good...

~450watts for ~500gh/s

I think the massive HW spike is from internet outtage, it was at 40HW very early in the morning. Who knows. Either way it's minimal compared to 22,000 shares at 256 diff ( ~5mil shares )

Do you have any special cooling?

stock, running it in a 26C ambient with no additional airflow anywhere

faetos

hero member

Activity: 744

Merit: 514

gotta let a coin be a coin

Quote from: Biodom on July 26, 2014, 10:35:15 PM

Quote from: faetos on July 26, 2014, 10:24:39 PM

Quote from: Biodom on July 26, 2014, 10:10:28 PM

Quote from: faetos on July 26, 2014, 09:54:01 PM

Quote from: Lowell904 on July 26, 2014, 09:43:28 PM

Quote from: sjc1490 on July 26, 2014, 09:40:15 PM

Quote from: Lowell904 on July 26, 2014, 09:11:36 PM

Quote from: Biodom on July 26, 2014, 07:35:49 PM

Quote from: WheresWaldo on July 26, 2014, 07:02:48 PM

Overnight run Grin

so far so good...

~450watts for ~500gh/s

I think the massive HW spike is from internet outtage, it was at 40HW very early in the morning. Who knows. Either way it's minimal compared to 22,000 shares at 256 diff ( ~5mil shares )

Did you mod this machine?
Looks awesome

I see that your discards are very low. Did you change any other settings besides the frequency when you OCed?

I am sure he did the cgminer parameter changes as many of us did, go back a couple of pages and read through the previous posts.

I have read this entire thread over the last couple of weeks and I have been trying. What do I have to type into putty to access the parameter that need changing?

We've covered this in depth today. The thread is messy, but this one liner will change what you need once you've SSHed onto your miner:

Code:

sed -i 's/--queue 4096"/--queue 0 --scan-time 1 --expiry 1"/g' /etc/init.d/cgminer

Go restart cgminer in the web interface by going to miner configuration and hitting save and apply. That will restart cgminer with the new config above.

Ok, I ssh into miner, enter the code above, hit return/enter
then (without exiting ssh?) go to web gui and just restart the miner by "save and apply" in configuration (although change was made by sshing)
right?
you cannot just use :wq or other command while still in ssh mode (after you entered the code string)?

sed is basically doing what vi does.
1. SSH to miner
2. enter this

Code:

 sed -i 's/--queue 4096"/--queue 0 --scan-time 1 --expiry 1"/g' /etc/init.d/cgminer

and press enter
3. exit SSH (CTRL-D) or exit
4. go do the web admin thing

Duce came up with the idea on making the changes. His guide here: https://bitcointalksearch.org/topic/antminer-s3-discussion-and-support-thread-671189 goes the vi route. sed/vi accomplish the same task. We're just showing you guys different ways of doing it.

The reason I used sed in my example is that I know that there is only one value `--queue 4096"` that will get changed and it's less daunting than vi.

Great, thanks...not a coder, but I think I got it... big thanks to Duce and you.

Always willing to help - Duce deserves the credit

Biodom

legendary

Activity: 3892

Merit: 4331

Quote from: faetos on July 26, 2014, 10:24:39 PM

Quote from: Biodom on July 26, 2014, 10:10:28 PM

Quote from: faetos on July 26, 2014, 09:54:01 PM

Quote from: Lowell904 on July 26, 2014, 09:43:28 PM

Quote from: sjc1490 on July 26, 2014, 09:40:15 PM

Quote from: Lowell904 on July 26, 2014, 09:11:36 PM

Quote from: Biodom on July 26, 2014, 07:35:49 PM

Quote from: WheresWaldo on July 26, 2014, 07:02:48 PM

Overnight run Grin

so far so good...

~450watts for ~500gh/s

I think the massive HW spike is from internet outtage, it was at 40HW very early in the morning. Who knows. Either way it's minimal compared to 22,000 shares at 256 diff ( ~5mil shares )

Did you mod this machine?
Looks awesome

I see that your discards are very low. Did you change any other settings besides the frequency when you OCed?

I am sure he did the cgminer parameter changes as many of us did, go back a couple of pages and read through the previous posts.

I have read this entire thread over the last couple of weeks and I have been trying. What do I have to type into putty to access the parameter that need changing?

We've covered this in depth today. The thread is messy, but this one liner will change what you need once you've SSHed onto your miner:

Code:

sed -i 's/--queue 4096"/--queue 0 --scan-time 1 --expiry 1"/g' /etc/init.d/cgminer

Go restart cgminer in the web interface by going to miner configuration and hitting save and apply. That will restart cgminer with the new config above.

Ok, I ssh into miner, enter the code above, hit return/enter
then (without exiting ssh?) go to web gui and just restart the miner by "save and apply" in configuration (although change was made by sshing)
right?
you cannot just use :wq or other command while still in ssh mode (after you entered the code string)?

sed is basically doing what vi does.
1. SSH to miner
2. enter this

Code:

 sed -i 's/--queue 4096"/--queue 0 --scan-time 1 --expiry 1"/g' /etc/init.d/cgminer

and press enter
3. exit SSH (CTRL-D) or exit
4. go do the web admin thing

Duce came up with the idea on making the changes. His guide here: https://bitcointalksearch.org/topic/antminer-s3-discussion-and-support-thread-671189 goes the vi route. sed/vi accomplish the same task. We're just showing you guys different ways of doing it.

The reason I used sed in my example is that I know that there is only one value `--queue 4096"` that will get changed and it's less daunting than vi.

Great, thanks...not a coder, but I think I got it... big thanks to Duce and you.

Topic: ANTMINER S3+ Discussion and Support Thread - page 372. (Read 710164 times)