how long is an estimated life span of an antminer s3?
how can anybody know this? it's a brand new product without almost any testing prior to shipment. they tested it for a a week....max they'll last 2 weeks TM and then you'll have to wait. |
|
|
|
OK, so one of my new S3 machines is hashing at 402.75Gh/s. Frequency is 218.75. One of the strings (if that is the word) is showing oooooxo-. Rebooting through the web interface, or physically power cycling doesn't fix it. Reading through this thread the suggestions are
1) Downclock to 212
2) Update firmware
3) Dismantle and replace thermal compound
Which of these is most likely to fix the hashing? Is there anything else I should try?
You also could do nothing and just let it hash at 402GHs. The extra 30GHs isn't probably worth the downtime and effort. 30GHs is worth $0.46 per day at the current difficulty/price. freq 212.5 takes 2 minutes with a ssh in. It has done wonders for my 2 machines see charts I have stayed at 430gh note that drop off was a power outage last night due to a T-Storm. These 2 units are in an office building. I have no direct access during non business hours. what I love about s-1's and s-3's is they reboot and fire back up working after black outs no attention or effort on my part. Note after the blackout I am back to 430gh  I'm going to try the 212.5 freq as you suggest. I see over 8 hours or so they slip to 430. If that's where they want to be then I don't want to waste the extra power trying to keep them at a speed they can't handle. |
|
|
|
|
Those G4s take me back. Heavy as hell but reliable.
|
|
|
|
I've gone to GREAT lengths to cool my DC/DC modules but am still having issues getting anything over 430gh. I never get any ASIC errors at higher frequencies, though 212 will force one of my boards to not be recognized by the controller.  Chip temps are 31 degrees, DC/DC modules are cool to the touch. I do see 475+ for about 30-45 minutes on one unit but it tapers off below 430 after more than 10 hours. Using server power supplies and a separate PWS for the fans. (They are 12V 2A each) I really love this pic. BTCkenstein coming to life in the DC. Throw a mad scientist in there and the pic is perfect. |
|
|
|
The huge amount of discards and so low accepted then thats because they are the opposite? discards = accepted and accepted = discards?
I'll repeat because this message seems to keep getting forgotten Ignore discards!They have nothing to do with hashrate, share acceptance, efficiency or anything else of any relevance today. They are an internal value which was only of relevance in the getwork era. Trying to optimise this value is futile, and lowering the value achieves nothing. It annoys the crap out of me that it was ever displayed in these standalone devices because people get hung up about it and it is of zero relevance. CK laying down the LAW!!! "Note to self: don't mention anything about discards around CK. LOL, thank you again for your advice. |
|
|
|
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.    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. 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. |
|
|
|
|
Did anyone receive the refund yet? Mine is still in init status.
|
|
|
|
 Overnight run  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: 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 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://bitcointalk.org/index.php?topic=671189.msg8029279#msg8029279 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 |
|
|
|
Overnight run 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: 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 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://bitcointalk.org/index.php?topic=671189.msg8029279#msg8029279 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. |
|
|
|
Overnight run 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: 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. |
|
|
|
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: 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**** Before Config Change (I added a line so it is easy to see, I took it out when I finished)  After Config Change  Ant Before  Ant After CHECK THE LOAD VALUES I appreciate you posting this I too have no idea why they set such a high queue on the units Has anyone else had any luck reducing discards with this mod. I've been learning about how to SSH and I think I want to try it. I'm getting a lot of discards and some of the pools are reporting strange hash rates and other feedback, after I played around with load balancing and balancing. I don't want to speak on Duce's behalf, but experience seems to show at this point that there is possible detriment to changing the queue value from 4096. BMT seems to have done this for a reason. I am seeing no difference in performance using modified expiry and scan-time settings. I'm working with about 36-hours worth of data at this point. I made these changes yesterday and my discards dropped x10 and the load is around 1.8 for both. My discards were x15 of accepted shares now then are only x.10. You have to restart cgminer for the changes to take effect. If you want you can use sed to replace the values in the file (it only occurs once): sed -i 's/--queue 4096"/--queue 0 --scan-time 1 --expiry 1"/g' /etc/init.d/cgminer From what I've seen (not from the above posts) is a lot of people posting really are missing some technical fundamentals to just get the boxes online. Where did they hear about bitcoin mining anyway? It's weird. |
|
|
|
I'm just looking at this thread and bitmain site. And what i can see, quality went down the drain.i mean, quality in regards of delivery on time, process of any refunds, simple information to community.
Now it seems bitmain asking for btc in advance which is basically preorder.
With s1 there was no issues related to delivery of miners. Now im reading people waiting to get their s3 mining week or more!
I was hesitating to order B1,B2,B3 and it seems i didnt lost a lot. as all batches was delayed and now batch 4 and 5 is simple proeorder with no warranty that will be delivered in time frame given.
I dont know whats the issue is but even labeling boxes as miner means issues for end user.
I am fan of bitmain but at this stage whats the point of ordering when their are not in stock?
Price is nice but again waiting time for B5 will kill any profit if any. We looking at least 14 days to receive any miner. What if customs will delay the process? Whats safe quantity to order? I was thinking to order 10. Any ideas how this will look for customs?
no miner is for sale at a better price and faster delivery. have they slipped from the s-1 yeah just a bit. down the drain no. down the drain would be what knc did from the early jupiter last nov to this years neptune. Based on all that i can see and read. these s-3's are better then the s-2's but not quite as good as the s-1's. By that I mean all aspects of the miner. I order 4 so far I have 2 hashing 2 on the way. when they come I will order 2 more. after those 2 come I will assess my next move. right now the mining game is very tough. Maybe i was to harhs to say down the drain. But i compering s1 to s3 situation. And thought maybe they will do same what they done with s1. I bought abut 20+ s1 with sushi and bitmain and never had any issues. I still think mining is something which will make few BTC before is not profitable anymore but for small people like me is getting more difficult and will not be easier. 10 units will make roughly 3 BTC a month. yeah I am in your boat. always less then 5-8k worth of gear. not tiny maybe a little bigger then small. but these days to be middle sized means 20th. I can't provide 20th in terms of the power needed. that would be 42-44 s-3s that comes to about 15 k-watts. I can do 4k to 6k in the winter. I can do 2k in the summer. right now I am running 14 gridseed blades in my home around 1250 watts. 2 s-3's in my friends office. 1 dragon miner in china 32mh in the zencloud a few icefury usb sticks in bitsolo.net-----------hey you never know 2 more s-3's in batch 4 when these com to my home i will be close to 1950 watts and that is about all I can do in house. what's always fun is while we work out where to put each piece and the wife starts vacuuming and shuts it all down. |
|
|
|
|
These guys are king of the BBQ miner. If you guys need any Texas beef brisket to go with these smoking hazards let me know. Scam Hole will take your chicken pre-order now.
|
|
|
|
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://bitcointalk.org/index.php?topic=526060.msg5838713#msg5838713 |
|
|
|
What happened jjj? Did MAT break your heart?
Shilling just isn't the same anymore. |
|
|
|
|
This is truly the time when we will see what kind of company they will be. When stuff goes a bit sideways how do they react? I hope they do the right thing by you guys. We need solid, honest companies in this industry.
|
|
|
|
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! |
|
|
|
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. |
|
|
|
The Greek word ἐλευθερία (pronunciation: [elefθeˈria]), commonly transliterated in English as eleutheria or phonetically spelled eleftheria, is an ancient and modern Greek term for, and personification of, liberty. http://en.wikipedia.org/wiki/EleutheriaI made this mistake with his name myself 2 years ago and I thought he might be Greek. Look harder at his handle, you'll see it isn't eleutheria. Oddly enough, the Eleuthria / Eleutheria connection is something I was completely unaware of until a few years ago when somebody asked me about it in #btcguild. I don't think ckolivas was the first to ask, but it's possible. The Eleuthria name was something I made up in high school. I learned C & C++ programming basics by working on MUDs in middle school and high school. Eleuthria was a name I came up with for one of the games. For a swords & sorcery fantasy title, generally more vowels = better, and that's where "Eleuthria" came from. Pronunciation being 'Eee-loo-three-uh' or 'El-oo-three-uh' (it's shifted over the years). It wasn't my primary handle on the internet though, I'm not quite sure why I used it for Bitcoin. Had I known I would end up making BTC Guild, I probably would've picked one that wasn't feminine! Amazing how our handles all get about. Mine came from a bunch of drunken band members saying "fetus" over and over (no idea why) and when I had to pick a handle I misspelled it in all my genius and ended up with faetos. Oh well.  I really hope things work out ok for the guild. It'd be a shame to see an institution like this get shuttered due to poorly written NY laws. Here in Texas we could care less what they do much less what the federal govt does or says |
|
|
|
|
Show Posts
