Bitcoin Forum

Bitcoin => Hardware => Topic started by: Prelude on January 03, 2016, 05:55:21 PM



Title: Collecting Data on B8 S7 Failure Rates
Post by: Prelude on January 03, 2016, 05:55:21 PM
It seems B8 S7 is the worst to date, with many failures reported. We can expect B9 to be the same since bitmain indicated B8 was the final design, which leads me to believe that B9 = B8 with a later shipping date.

I personally have 1 dead B8 board, board #3 and it died within 2 weeks of powering it on. I think we'll find that most people with a failure will also be board #3.

Bitmain has, to date, been very slow to respond to my RMA request. I'm giving them the benefit of the doubt right now due to the holidays.

If you've had a failure in another batch, you can indicate that by voting for the last option. In that case, I kindly request that you don't cast a second vote to indicate which board # failed, but instead post those details manually in this thread. That will allow us to gather details specifically for B8 in the poll.


Title: Re: Collecting Data on B8 S7 Failure Rates
Post by: marvykkio on January 03, 2016, 06:07:54 PM
fuck I bought 3x s7 batch 8, and tomorrow should send
My god we hope that work well


Title: Re: Collecting Data on B8 S7 Failure Rates
Post by: yslyung on January 03, 2016, 06:11:22 PM
it's called chain in antminer GUI

Chain #1 is far Right then middle is Chain #2 & lasltly Chain #3 is on the Left with miner facing towards you.

2x B8 arrived same day mined only for about 7-8 hours.

1 showed 0 temp with 30 ASIC chips & dashes ----------

2nd was working fine till low hashrate with lots of HW errors

disconnected both problematic board, documented the details with pics & mailed BMT waiting for approval to remove them then more pics to be sent & wait for reply then send it back to BMT.

I think entire process will take a minimum of 2 weeks for boards to return even i'm located in asia.

PSU are dps 2000 bb's, i even swapped them. no good. same issue.

in a couple of hours (GMT +8) china will wake & end of holidays for BMT.

let's see what kind of reply i get.

on another note, 1 of my b5 had a problem too, board arrived to BMT & now more waiting.



https://i.imgur.com/TCVPXc9.png



Title: Re: Collecting Data on B8 S7 Failure Rates
Post by: Prelude on January 03, 2016, 06:19:25 PM
Thanks for posting that info, yslyung.


Title: Re: Collecting Data on B8 S7 Failure Rates
Post by: yslyung on January 03, 2016, 06:36:17 PM
Thanks for posting that info, yslyung.

no worries mate. sharing is caring.

thx for starting the thread too.


Title: Re: Collecting Data on B8 S7 Failure Rates
Post by: notlist3d on January 03, 2016, 07:06:05 PM
I could be lucky but B8 I have still has no issues hashing.  I have kinda took it easy on it, no OC or pushing.   Don't know if it matters but using the Bitmain PSU (should not matter).

Only thing that was it seems they truly did mean +10 on efficiency when they put it.  So it had a lower efficiency with lower chips, but guess that is not a failure.


Title: Re: Collecting Data on B8 S7 Failure Rates
Post by: hawkfish007 on January 03, 2016, 07:39:45 PM
I have 2 B8s with no issues, also never overclocked and running Dec 11 firmware. I am wondering if people are overclocking them to death.


Title: Re: Collecting Data on B8 S7 Failure Rates
Post by: nhando on January 03, 2016, 07:48:10 PM
DOES SCREECHING FAN count as a failure?  Also the lack of any response or care for my issue probably could be categorized as a failure regardless of what batch.    Other than that my Batch 8 are running fine for a week.  Still have another 1 to be power up tomorrow, hoping for the best.


Title: Re: Collecting Data on B8 S7 Failure Rates
Post by: dmwardjr on January 03, 2016, 07:54:12 PM
I have one batch 8 that hashed fine for a while then check on them one day after all my rigs failed over from number 1 pool to number 2 pool.  It was hashing at approximately 3,000 GH/s on the number 2 pool.  Eventually, number 1 pool came back up and was "Alive" again but still only 3,000 GH/s [Meaning, 2 boards hashing instead of 3].  I did not see any "x" or "-" for any blades.  I rebooted several times and I simply "save and apply" several times with no success of 4,700 GH/s again.  I disconnected that rig and hooked up another rig to take it's place.  That rig is sitting to the side at the moment.  I'm planning on getting back to checking that rig again later this evening or tomorrow to see if it still has the same issue.  I'll keep you updated.


Title: Re: Collecting Data on B8 S7 Failure Rates
Post by: dmwardjr on January 03, 2016, 07:55:02 PM
DOES SCREECHING FAN count as a failure?  Also the lack of any response or care for my issue probably could be categorized as a failure regardless of what batch.    Other than that my Batch 8 are running fine for a week.  Still have another 1 to be power up tomorrow, hoping for the best.

Unfortunately, I don't think "screeching fan" will count.  Maybe it will.  It's hard to say what they would do...


Title: Re: Collecting Data on B8 S7 Failure Rates
Post by: yslyung on January 03, 2016, 08:12:01 PM
I have 2 B8s with no issues, also never overclocked and running Dec 11 firmware. I am wondering if people are overclocking them to death.

the ones + all the s7 i have are on stock clock. just 7-8 hrs of hashing & gone. sob sob

btw, both failures on b8 is on chain #1 including b5 also chain #1.

1 of the b8 comes with the whooong whooong whoong sound.

placed a small double sided tape on the grill reduced the sound. could've stick another one but it will block the airflow & i'm fine with the reduced whooooong whooooooooooooooooooooooooooooooooooong whooooooooooooooooooooooooooong


Title: Re: Collecting Data on B8 S7 Failure Rates
Post by: hawkfish007 on January 03, 2016, 08:24:37 PM
I have 2 B8s with no issues, also never overclocked and running Dec 11 firmware. I am wondering if people are overclocking them to death.

the ones + all the s7 i have are on stock clock. just 7-8 hrs of hashing & gone. sob sob

btw, both failures on b8 is on chain #1 including b5 also chain #1.

1 of the b8 comes with the whooong whooong whoong sound.

placed a small double sided tape on the grill reduced the sound. could've stick another one but it will block the airflow & i'm fine with the reduced whooooong whooooooooooooooooooooooooooooooooooong whooooooooooooooooooooooooooong

I had a couple of boards on chain 1 and 2 fail on me from B1. I replaced them but the one on chain #1 failed again, it is in China to be delivered tomorrow. Seems like chain #1 is the source of failure for many.

nhando,

I think it will be cheaper if you replace the fan by yourself, they might want you to send the fan at your cost for RMA.


Title: Re: Collecting Data on B8 S7 Failure Rates
Post by: citronick on January 03, 2016, 09:00:56 PM
I have 4 x B8s in my small farm, they are running but running hot +10c compared to other batches 600mhz.

1. all 7 x S7s are patched with Dec11 FW on 1st Jan 2016.
2. the irritating whoooooo sound has gone away in the last 2 x B8 ordered in mid-Dec (but they are running high temp 68-72c at fans 100%)
3. the whoooo sound in the other earlier 2 x B8 was rectified at 54% fan ratio with acceptable temp ~ 60-65c
4. the rest of the S7s are 600mhz variants, running 55% fan speed (to eliminate the whoooo sound) with 55-65c temps
5. All my S7s are VERTICALLY mounted - stock fans blowing upwards - with 2 box fans running at medium from below the rack.
6. HWE% are very small and I am satisfied with the hashing rate and quite stable to my liking.
7. All fans are stock with no mods.
8. My electrical setup was recently upgraded and all S7s are with dedicated points at 10amp/240v per point. I now have my own separate 120A/240v power distribution board for the miners.
9. The PSU power cord are all standardized with 1.5mm 13AMP/250v BS1363.
10. Each of the S7 are powered by the stock 1600w PSU from BMT with no mods.
11. All the above hashing power (33TH+) goes to kano.is since early Dec.
12. 5 x S7s were bought directly from BMT and shipped by DHL. No shipping issues.

That's my setup and journey so far, thanks to the many tips and guidance from this forum.

Although I don't have any bad units from BMT (fingers crossed), I feel for the rest because the miners are quite an investment. Hang on in there and keep sharing so that we could collectively help each other....

... TTYL.... kano just hit another one!


Title: Re: Collecting Data on B8 S7 Failure Rates
Post by: nhando on January 03, 2016, 11:33:53 PM
I have 2 B8s with no issues, also never overclocked and running Dec 11 firmware. I am wondering if people are overclocking them to death.

the ones + all the s7 i have are on stock clock. just 7-8 hrs of hashing & gone. sob sob

btw, both failures on b8 is on chain #1 including b5 also chain #1.

1 of the b8 comes with the whooong whooong whoong sound.

placed a small double sided tape on the grill reduced the sound. could've stick another one but it will block the airflow & i'm fine with the reduced whooooong whooooooooooooooooooooooooooooooooooong whooooooooooooooooooooooooooong

I had a couple of boards on chain 1 and 2 fail on me from B1. I replaced them but the one on chain #1 failed again, it is in China to be delivered tomorrow. Seems like chain #1 is the source of failure for many.

nhando,

I think it will be cheaper if you replace the fan by yourself, they might want you to send the fan at your cost for RMA.

I will order a spare fan as my ant hill will continue growing so I will more than likely being needing spares anyway.  Is Ebay the best choice?  What is a fair price after shipping?

Anyone have these?  Are they any good?

http://www.ebay.com/itm/Replacement-Antminer-120mm-Fan-5000rpm-20in-cables-4pins-connector-BEST-/131665902676?hash=item1ea7e63c54:g:EiwAAOSwnH1WXl-D


Title: Re: Collecting Data on B8 S7 Failure Rates
Post by: dmwardjr on January 04, 2016, 12:36:12 AM
I will order a spare fan as my ant hill will continue growing so I will more than likely being needing spares anyway.  Is Ebay the best choice?  What is a fair price after shipping?

Anyone have these?  Are they any good?

http://www.ebay.com/itm/Replacement-Antminer-120mm-Fan-5000rpm-20in-cables-4pins-connector-BEST-/131665902676?hash=item1ea7e63c54:g:EiwAAOSwnH1WXl-D

I'm not familiar with the brand.  Others here may be.  It's a damn good price for sure for 3.4 Amp 5000 RPM fan.  I paid $24.00 w/free shipping for each of 10 units on Amazon from one seller in mid summer for 5,000 RPM; 250 CFM @ 3.4 Amps specs.  Now you will pay about the same but will also pay for shipping for about $30.00 each fan on Amazon.  I like the price of the one you found.  I'm just not sure of the durability.  Only time will tell.


Title: Re: Collecting Data on B8 S7 Failure Rates
Post by: lovenlifelarge on January 04, 2016, 12:04:12 PM
I don't have an S7 so please ignore if u choose just wanted to see if someone else has tried this as i'm thinking of buying some from the jan batch.

If 1 board has died & u own 2 of them can u link them on to another controller & see if they work??

Maybe the controller has issues not the board?

I haven't seen anyone in the forums mentioning trying this method??

Let me know if this helps? It may speed up the RMA issues if its just a controller..

I seem to remember someone talking about bung controllers before too..

Like the ones with the S5 that came with the first few S7's.


Title: Re: Collecting Data on B8 S7 Failure Rates
Post by: sidehack on January 04, 2016, 03:06:28 PM
I forget offhand what batch it was from, but I had an S7 come in for hosting and one board approximately caught fire as soon as I turned on the power. One fan has also failed and been replaced. The owner had previously sold it on eBay and it was returned as nonfunctional a few weeks later; he RMA'd two boards before it got to me. I suspect the eBay customer bought many from different places and put all the failed parts into one case to return so he wouldn't have to deal with separate RMAs (in which case he screwed over one seller pretty badly). Currently that is speculation. What is not speculation is that "one" S7 ended up with three failed boards (at least one of which failed with a light show) and one failed fan (which died after about two weeks on my shelf).


Title: Re: Collecting Data on B8 S7 Failure Rates
Post by: NotFuzzyWarm on January 05, 2016, 11:18:29 PM
fuck I bought 3x s7 batch 8, and tomorrow should send
My god we hope that work well
Odds are they should be fine. I have 3 of the earlier ones from Batch-8 and they are running perfectly. Never OC'd, fans turned down to 50-55%, all running the Bitmain PSU's. I've also placed an order for 2 more from batch-8 that I should get in a week or so.


Title: Re: Collecting Data on B8 S7 Failure Rates
Post by: gerrys on January 06, 2016, 04:42:39 PM
I had a chain #2 board fail after ~16hrs of use in a S7-B8 (was reporting 21 ASICs)
The unit was running default clock speed with a IBM 2880W PS. The temps were all
under 40°C prior to the failure.
The board has been shipped back for warranty (at my cost) and the responses from Bitmain
are that there won't be any compensation for the down time (failed Dec. 18) or my shipping costs. 


Title: Re: Collecting Data on B8 S7 Failure Rates
Post by: klondike_bar on January 06, 2016, 05:02:36 PM
Ive had mine almost two weeks, been feeding it outside air (below freezing) and its been at these settings for over 48hrs now:

18% fans (had to modify a file to use settings <20%)
725Mhz = 4.85TH, 0.012% errors, temps 62-68C

it was originally powered by a gold 1350w PSU, but for better effiviency its now split  between the 1350W gold(2 blades + controller) and a 650W gold(1 blade) since i was otherwise running at 90-95% capacity on the single PSU


Title: Re: Collecting Data on B8 S7 Failure Rates
Post by: yslyung on January 06, 2016, 05:10:29 PM
not b8 not mine, one of my friends s7 :

https://i.imgur.com/drWMcJ2.jpg


Title: Re: Collecting Data on B8 S7 Failure Rates
Post by: Gornidah on January 06, 2016, 09:09:22 PM

it was originally powered by a gold 1350w PSU, but for better effiviency its now split  between the 1350W gold(2 blades + controller) and a 650W gold(1 blade) since i was otherwise running at 90-95% capacity on the single PSU


I've done almost the same, 1300 EVGA powers 2 blades, and NOX URANO 850 TX powers 1 board+ controller.
Running at max 61c, but I'm not doing any overclock ( for now) :D


Title: Re: Collecting Data on B8 S7 Failure Rates
Post by: hawkfish007 on January 06, 2016, 09:25:56 PM
not b8 not mine, one of my friends s7 :

https://i.imgur.com/drWMcJ2.jpg

Scarry, I see 2 burned PCIe cables, was he powering each blade with 2 PCIe only?


Title: Re: Collecting Data on B8 S7 Failure Rates
Post by: yslyung on January 06, 2016, 10:38:42 PM
3 pcie, 3rd can't see cuz it's molten pcie LoL


Title: Re: Collecting Data on B8 S7 Failure Rates
Post by: scyth33 on January 07, 2016, 04:43:03 AM
which file did you have to modify to get it to work <20%?

Ive had mine almost two weeks, been feeding it outside air (below freezing) and its been at these settings for over 48hrs now:

18% fans (had to modify a file to use settings <20%)
725Mhz = 4.85TH, 0.012% errors, temps 62-68C

it was originally powered by a gold 1350w PSU, but for better effiviency its now split  between the 1350W gold(2 blades + controller) and a 650W gold(1 blade) since i was otherwise running at 90-95% capacity on the single PSU



Title: Re: Collecting Data on B8 S7 Failure Rates
Post by: handytxg on January 07, 2016, 07:44:10 PM
Does anyone here have successfully get board replacment from bitmain?
I have sent both email and ticket got no reply at all.. its almost a week already.


Title: Re: Collecting Data on B8 S7 Failure Rates
Post by: VirosaGITS on January 07, 2016, 09:00:28 PM
S7 received, preliminary 20 mins run gives 4.74TH/s fan 50%, watt 1440 on two 1050 EVGA GS/G2. I estimated 1475w based on Bitmain's numbers. So a EVGA g2 1300 would run this fine albeit at 1450Watts~


Title: Re: Collecting Data on B8 S7 Failure Rates
Post by: hawkfish007 on January 07, 2016, 09:29:33 PM
Does anyone here have successfully get board replacment from bitmain?
I have sent both email and ticket got no reply at all.. its almost a week already.


Yes, 2 boards and a fan replaced.


Title: Re: Collecting Data on B8 S7 Failure Rates
Post by: Frank-White on January 08, 2016, 04:46:31 PM
November 2015 2 x antminer S7 batch 5 from antminerdistribution.com, these guys are based in the Netherlands, Europe.

Long story short: 1 Miner gave in almost immediately after power up.. hashing for one hour before it went dead....
Miner 2 took about 10 days to stop hashing on blade 1 en reduce hashing on blade 2...

after a couple of  emails between me and antminerdistribution.com..
1  miner sent back to them within a week...

2 blades and a controller (controller just to be sure) returned to AD within about 2 weeks.

To keep things positive: 
this company is doing everything in their power to find a solution, great communication, they call me instead of having me to call them.


Not happy, however the guys from this seller absolutely ROCK! keep up the good work ;-)
Really hope the manufacturer takes as much care of their customers as these guys...



Title: Re: Collecting Data on B8 S7 Failure Rates
Post by: VirosaGITS on January 18, 2016, 01:15:22 PM
S7 received, preliminary 20 mins run gives 4.74TH/s fan 50%, watt 1440 on two 1050 EVGA GS/G2. I estimated 1475w based on Bitmain's numbers. So a EVGA g2 1300 would run this fine albeit at 1450Watts~

Almost through the first 2 weeks. The miner mine 4.72 TH/s when supercooled (Fans@3k, Temp at 50c). The HWE% is still at 0. 130 errors in 5 days. So far so good, i hope the unit last a long time.

With the 0 HWE% i guess i would be able to get a good OC potential out of it. But on 120v15A breakers, i'd be pushing the circuit over 80% load, so, maybe in the future if i get access to 240v or 20a breakers.


Title: Re: Collecting Data on B8 S7 Failure Rates
Post by: Frank-White on January 19, 2016, 10:06:30 AM
Just had a board failing on a S7  (4,73 TH/s) .. not to my surprise board number 1

Bad engineering from Bitman.

Why?

Board 1 has the small heatsinks on the outside (half the size of the inside heatsinks) AND the airflow is partially blocked by the fan mounting plate on the inlet and exhaust...
no wonder board 1 will fail first... it just isn't getting enough cooling... fans @ 75% in a 10 degree centigrade room.

Taking the board out an replacing it with a "dummy filler" so it will keep on hashing at 66% while waiting for a replacement.

looking at the failure rates it doesn't come as a surprise that board 2 has the lowest failure rates, there is logic in 1 failing first and 3 failing second, when looking at the size and placement of the heatsinks.

other S7 (4,86) running smooth in the same room for a week now..

edit: fan percentage added/typo


Title: Re: Collecting Data on B8 S7 Failure Rates
Post by: yslyung on January 19, 2016, 04:36:09 PM
received my b8 replacement boards, took roughly abt 2 weeks, they're mining fine now for abt 8 hrs or so.

boards are ver 1.1


Title: Re: Collecting Data on B8 S7 Failure Rates
Post by: VirosaGITS on January 19, 2016, 04:43:58 PM
Just had a board failing on a S7  (4,73 TH/s) .. not to my surprise board number 1

Bad engineering from Bitman.

Why?

Board 1 has the small heatsinks on the outside (half the size of the inside heatsinks) AND the airflow is partially blocked by the fan mounting plate on the inlet and exhaust...
no wonder board 1 will fail first... it just isn't getting enough cooling... fans @ 75% in a 10 degree centigrade room.

Taking the board out an replacing it with a "dummy filler" so it will keep on hashing at 66% while waiting for a replacement.

looking at the failure rates it doesn't come as a surprise that board 2 has the lowest failure rates, there is logic in 1 failing first and 3 failing second, when looking at the size and placement of the heatsinks.

other S7 (4,86) running smooth in the same room for a week now..

edit: fan percentage added/typo

What C where you reading on the board? All my boards are +- 2c from one another; 53C, 51C, 52C. So if board one had poorer heatsink i think you would be able to see the difference somewhat in the temp readings?


Title: Re: Collecting Data on B8 S7 Failure Rates
Post by: Frank-White on January 21, 2016, 07:13:31 PM



"What C where you reading on the board? All my boards are +- 2c from one another; 53C, 51C, 52C. So if board one had poorer heatsink i think you would be able to see the difference somewhat in the temp readings?"

At the moment I am reading 56 on Chain 1
and 62 on chain 2
Freq 693 fans @ 45% room temp 20 centigrade

To me it looks like the side boards suffer most from the air obstruction of the fan mounting plates

.
Replaced the broken board with a "dummy" piece of hardwood.
Had to "wedge" the side on the intake, otherwise the fan was blowing air back.


Title: Re: Collecting Data on B8 S7 Failure Rates
Post by: VirosaGITS on January 21, 2016, 07:21:48 PM



"What C where you reading on the board? All my boards are +- 2c from one another; 53C, 51C, 52C. So if board one had poorer heatsink i think you would be able to see the difference somewhat in the temp readings?"

At the moment I am reading 56 on Chain 1
and 62 on chain 2
Freq 693 fans @ 45% room temp 20 centigrade

To me it looks like the side boards suffer most from the air obstruction of the fan mounting plates

.
Replaced the broken board with a "dummy" piece of hardwood.
Had to "wedge" the side on the intake, otherwise the fan was blowing air back.

I see, so your temps goes up in the 60s.

Maybe this is a tip that can help people, or maybe not but; When i put it on the left side, at least thats the side i got mine on, the temps are much tighter, the lower temp is higher but the highest temp is lower.

Hopefully that doesnt break anything but thats what the sensors report.


Title: Re: Collecting Data on B8 S7 Failure Rates
Post by: OstlerDev on January 23, 2016, 02:13:57 AM
I have been running mine for over a month straight, no issues and only a 0.0085% HW error rate. Fans are currently set to 40% and it has hosted with toom.im so lots of airflow around it. I do have it up for sale but its been without any issues since I got it!

Panel: https://i.imgur.com/CwUSlW0.png


Title: Re: Collecting Data on B8 S7 Failure Rates
Post by: sloopy on January 29, 2016, 05:26:48 PM
My first batch 8 unit delivered in December has lost a hash board.
I've swapped the cable from control to board and tried a different power supply.
The other two boards are hashing fine except one of them runs 10c higher than the rest of all S7 hash boards including the other one which is running int he unit with the failed board.
This is also the first S7 I bought which has the whooooooo whooooooo sound that is so annoying. I love the sound of fans, but that noise will make you crazy.


No response from Bitmain as the first 24 hours since initial contact winds down.
I sent an e-mail to info, I sent a follow up to Yoshi, and called Colorado and left a voice message which went was not returned.
I will fill out a ticket but I thought info@bitmaintech was handling all warranty claims on S7s.
If you e-mail them about buying 100 S7s you get a response pretty fast. Within a few hours or less depending on the time of day there. You e-mail about a warranty problem and wait, and wait.




Title: Re: Collecting Data on B8 S7 Failure Rates
Post by: elysimai on January 29, 2016, 05:35:06 PM
there's a way to get 1 bitcoin per month????????


Title: Re: Collecting Data on B8 S7 Failure Rates
Post by: alh on January 29, 2016, 10:31:18 PM
I saw a posting in the "Main Antminder S7" thread about a Chinese Spring Festival that starts now, and runs for about two weeks.  Just thought folks here might want to know, and/or to confirm it.


Title: Re: Collecting Data on B8 S7 Failure Rates
Post by: sloopy on January 30, 2016, 09:43:33 PM
Yeah, I was trying to even buy a hash board so I could run until after the celebration but I was told there are not any more shipments leaving mainland China for the continental US until after.

**Edit 1: My apologies for the size of the pictures. If the mods want them removed so it doesn't take the whole page let me know.)
**Edit 2: The last time I posted a bunch of pictures I received some interesting actions. I didn't strip personal information and it isn't being lazy, I use my real name quite a bit, but usually not completely out in public. I'd appreciate not using it openly or using my personal information against me in any way haha, but if you have recommendations of security aspects please tell me.


I cannot wait for some real competition in the miner hardware manufacturing field. I know that there aren't any companies who are going to challenge bitmain on every front. They have dug in, and any hardware built is hardware sold no matter what.
...But, if just one company with a vision for long term relationships building long term success comes in the hardware arena I don't care how low bitmain drops the price, they will lose massive amounts of orders.

Many of you have heard me mention this in the past but in my company, there is a core group of guys who will do whatever it takes, whenever it takes - to keep our customers running. Hell, we do it for people who have never even purchased a product from us just so we can begin to earn their trust and respect.
The best thing about it, this kind of behavior becomes a habit, a way of thinking, and a real way of doing business.  
We offer free phone support for whoever has the product as long as someone has it and is trying to make it run. It isn't support for life, as in your life, it is free support as long as anyone who has possession of the product would like to have assistance, 24x7x365.

Sure, we have some people who abuse our after hours emergency support and call to ask something extremely simple, but, for all of those times I've answered the emergency line and the guy asked me to help him with a part number for a bolt there are also the few times per year when the VP / CEO of a large competitors client calls because his entire production facility is about to begin sending people home because they don't have a system functioning. Not to mention our own clients who are all very important. At least the big boys can usually afford backup systems where the Mom and Pop shop or the guy with his equipment in a garage behind his house with his house mortgaged to the hilt and he is taking a gamble with every penny they have right down to the kid's college tuition and their retirement money...

You may think how can a bitcoin miner and those situations have common attributes? Or, some people say 'You should never invest more than you can afford to lose" ...and I agree with that line of thought in almost all situations, especially bitcoin related, but...

Everyone has their own reasons for purchasing a miner, and everyone has their own level of importance this box has in their lives. It should be just as important, if not more important to cater to the problem situations no matter who it is, when it is. We are talking about a scenario every single one of us who deal with the RMA process with these guys must go through. Dont get me wrong, I know there are some people who've had fantastic experiences. Unfortunately, the only time(s) I have received even a reply to a message or call I initiated was not from anyone who should have been the first response. For the S7 warranty issue it should have been the factory or someone in China.

Yoshi's job is partly to handle US domestic sales. He has helped me and never even mentioned if I bought through him he could give me much better support. I have seen Wolfen state the same, that Yoshi has taken care of him. "...But what about having to pay an extra X percent on top of the miner I already cant gain ROI" -- Well, let's start adding some things up...

Nah, no math, but say it adds $100 per unit? For me today I would be willing to pay an expedite fee to get this hash board fixed. The things needs to be running and sometimes to some people that is more important than the cost. Within reason obviously but I would purchase another miner if I could also have a hash board sent with it, and pay for the board of course. Or, pay a premium for the board, and wait for the RMA process. I'm hearing 5- 6 weeks from china. :/
What would they lose buy having someone answer the phone and sell parts at list price?

Where is the company that is like most other manufacturers, again, for example, I can put a part in a box and have it almost anywhere int he world before the end of the next day. (I do this all the time.) Sure, there are issues sometimes, but I offer to ship to a forwarder on the border if it is an adjoining country like Mexico. The customer can handle it from there. I will help any way possible but in that situation as long as I did the proper paperwork, I fulfilled my responsibility. Sometimes I put things on Southwest, American, etc freight flights. Anywhere they fly I can get a part there many times before UPS or Fedex, and many times it is less expensive. All you need to do is fill out some paperwork and go through some things with the airline.

The people I see here are smart, they are frugal, many are patient, many know what they want and when they want it, everyone is different about what they may pay but today almost every business has a webfront store where you can drop some things in the basket and checkout. Every business has a support line you can call and get some warranty help within an hour or so. Most places including my own are immediate service unless you decide you want to hold for a specific person. Which happens frequently with certain people. Those people care.

Please do not think I am a Bitmain hater. I was, but I stopped being that. I bought my share of S7sand have spent way too many coins on S3 (I love the S3 tanks, above average miner design imo) S4 (I do not like the S4 and bitmain did not make that right with most people who purchased an S4. It was my first very bad experience with bitmain.) S5 (Was the opposite of the S3 mmini tank, the plastic sides warped, hash boards fried, but many people made a lot of money early. I wasn't one of them but I've had my share of S5s through the summer and have 4 left now. Two of which have lost part of the chain, so down about 20% hashrate average on each.
Prelude todl me the S4+ corrected the mistakes with the S4, and that is great. I did not buy one used or new. S4 is a bitch for shipping and some of them can be a real PITA many because of the stock power supply. Why didn't bitmain bite the bullet and start shipping a 1600 watt replacement? Do the right thing. and now the S7.

I learned with the S7 if you have a fan failure you are responsible for sourcing and replacing the fan. You do not see that when you purchase it, or in the warranty, but I was ignored by them repeatedly. Yoshi took care of me, again, I later find out he really only has to help the people who buy from him, and he must have a markup to cover such because he is paying the high prices. I have no doubt he gets a discount for x amount but providing good support is worth something, and part of that "something" is valuable in monetary terms. Bitcoin, USD, or whatever it takes.

The biggest things about these companies who call me int he middle of the night about to send people home because they have ran out of work for them to do, is, usually something simple. Shipping a part, if they work with me, or one of our senior people we can narrow it down, or, ship them enough parts to do so.

It is easy to do. It does cost money. Maybe I am the minority and I am one of the few who see the value in having a straight forward way to even begin the RMA process. A Phone number you can call and receive assistance, somewhere you can order parts 24-7 and select your shipping method with the normal choices for Global / World Ship next day, second day, etc.

Yeah, I think there is a big vacuum for someone to step in and offer average customer service and do very well. I don't believe Spondoolies lost money overall, I think they did very well outside the manufacturing also, they have a good deal of resources and moved to what works for them. (My opinion, by my experience with companies in comparable manufacturing businesses.)
I think a company could step in and start selling a $599.00 S7 equivalent today for two weeks and stop for a week and only sell them for 999.00 or some similar marketing game which would still make them obscene profits but if they offered average customer service and RMA process as most modern companies do then they would quickly own the market. I am saying average company. Don't even talk about a startup full of excited entrepreneurs who would always be on top of things.

There must be a whole different side to Bitmain service and response that I have not been able to experience.
I understand vacation, I've already said my thing there, too many ways to handle people on vacation, everyone who makes something people want on a weekend eventually figures out a way to give it to them.

I have been told by a couple of people here on the forum, and I will summarize, that I was too impatient, and I expect too much for this industry.
I would be ecstatic if I could come here and post raving reviews regarding my experiences with warranty situations and simply purchasing a part or product. That would make me happier. I don't like things about the pool, but I am talking about the mining hardware and how we as a community are consistently buying more.

I hope that after Chinese New Years I am able to talk with someone within the first few days so we can begin the warranty claim and see what they say. I've started tickets through the main bitmain site about the S7. I also used bitmain zendesk per Yoshi.
That is what I should expect when purchasing this product. I should purchase extra miners, some parts from ebay, or just deal with it. There is not an opportunity to purchase factory parts, receive support, or don't even think about trying to process a warranty for a week and a half or so.

Yeah, I know. Which is why again, I think there is a hole to fill and it is too bad I don't see anyone with both the money and the ethics, but hell, maybe we will see some real competition this year. It could get very interesting this fall. Things will tighten up. Rich get richer, and many home miners will be doing better relative to some of those richer. Some of those may not be handling the squeeze quite the way they expect.  

I don't expect a company to put anything above profits. It must make a profit.
Repeat business and offering "after sales" support and product offerings are the biggest money makers. Complete Miners and every part in them should be available to be ordered anytime until X date. IF Bitmain (the manufacturer) ends up with a few extra of something on the shelf they can never sell, they write it off. People and software are smart enough to know what you aren't going to need as many of.  It is also understood there may be backorders.

Have a company able to sell those parts 24-7 for you if you don't have time to take ont he headache of the details. There are plenty of people who can repackage parts and ship them for 10%.

https://i.imgur.com/AyvA3ph.jpg?1

https://i.imgur.com/P8c3c6n.jpg?1

https://i.imgur.com/AAZx9w7.jpg?1

https://i.imgur.com/NcSly5P.jpg?1


Two of the issues I've found so far dissecting this are so trivial they shouldn't have happened.


Title: Re: Collecting Data on B8 S7 Failure Rates
Post by: sloopy on February 02, 2016, 03:23:18 PM

02-02-16 Update
The Good News:
I received a reply from Bitmain customer service!
The "Whatever" News:
I was told to be patient, they are on vacation.
There are spare miners in the US, but they are for their "large" accounts in case they need one until the factory returns from vacation.
Be patient, until they return on the 15th.

If anyone else has found a way to receive warranty service before then, please let me know.
I am buying Avalons.



Title: Re: Collecting Data on B8 S7 Failure Rates
Post by: RadekG on February 02, 2016, 03:40:46 PM
Just FYI: Antminer S7 working at superhigh temperatures 80C+

(automatic shutdown works at 85C not 80C!)

http://www.pantin.cz/S7.jpg


Title: Re: Collecting Data on B8 S7 Failure Rates
Post by: boomin on February 03, 2016, 07:49:01 AM
I have 10 S7 B8 from early december - KNOCK ON WOOD.  No problems.

Stock firmware - actually using recycled cointerra power supplies.  1 to each pair of boards (6 pci each and 1 for controller)  My design and so far so good!

I am the first to flame a company when deserved.  But I think a lot of people don't understand that overclocking is not free and you can't keep the miners running well without controlled temperatures..


Boomin

p.s. but I did have my fair share plus of ant S4 problems. 


Title: Re: Collecting Data on B8 S7 Failure Rates
Post by: klondike_bar on February 04, 2016, 06:57:54 PM
Just FYI: Antminer S7 working at superhigh temperatures 80C+

(automatic shutdown works at 85C not 80C!)


good to see, mine commonly pushes into the 70-74C range during the daytime on a warm day (10C outdoor intake) and drops to about 55-60C during extremely cold nights (-5C outdoor intake and has had no problems. fan speeds set 15-18% depending on weekly temperature forecast to keep it ideally around 65C average



Title: Re: Collecting Data on B8 S7 Failure Rates
Post by: citronick on February 05, 2016, 07:35:18 PM
one of my S7 B8 has been restarting frequently - first time I have seen this happening - the rest of the B8's are ok - running full speed at 700mhz/4.6th-4.9th with latest Dec FW

I underclock it to 650mhz but it still ever so often starts rebooting again...

Changed Mhz to 600 but after rebooting it came back at 650mhz -- is this normal?

Anyone experienced this symptoms before?


Title: Re: Collecting Data on B8 S7 Failure Rates
Post by: wikkidtt on February 06, 2016, 08:20:12 PM
Board 1 just died in my batch 9

Had to unplug it as it would just cause it not to mine.


Who do I contact for warranty repair?


Title: Re: Collecting Data on B8 S7 Failure Rates
Post by: fr4nkthetank on February 07, 2016, 07:50:15 PM
Please dont run your antminer at over 80c, I am scared for your house :)   Just because you can, doesnt mean you should lol.  although i'm sure you are just doing it for test purposes.  I'm too scared to even over clock mine at this point, I feel as soon as I touch another setting the miner will suicide itself.


Title: Re: Collecting Data on B8 S7 Failure Rates
Post by: citronick on February 08, 2016, 02:44:01 AM
one of my S7 B8 has been restarting frequently - first time I have seen this happening - the rest of the B8's are ok - running full speed at 700mhz/4.6th-4.9th with latest Dec FW

I underclock it to 650mhz but it still ever so often starts rebooting again...

Changed Mhz to 600 but after rebooting it came back at 650mhz -- is this normal?

Anyone experienced this symptoms before?

i managed to get some kernel info -- can anyone help me see whats wrong with this s7?
Now.. the s7 cant wake up from the dead... i have to wait an hour or two  before it goes OK for about 15mins then freezes again requiring powershutdown

Code:

System
Miner Configuration
Miner Status
Network

Overview
Administration
Monitor
Kernel Log
Upgrade
Reboot

Kernel Log


[    0.000000] Booting Linux on physical CPU 0x0
[    0.000000] Initializing cgroup subsys cpu
[    0.000000] Linux version 3.8.13 (xxl@armdev01) (gcc version 4.7.4 20130626 (prerelease) (Linaro GCC 4.7-2013.07) ) #22 SMP Tue Dec 2 15:26:11 CST 2014
[    0.000000] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=50c5387d
[    0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
[    0.000000] Machine: Generic AM33XX (Flattened Device Tree), model: TI AM335x BeagleBone
[    0.000000] Memory policy: ECC disabled, Data cache writeback
[    0.000000] On node 0 totalpages: 65280
[    0.000000] free_area_init_node: node 0, pgdat c06cb100, node_mem_map c0726000
[    0.000000]   Normal zone: 512 pages used for memmap
[    0.000000]   Normal zone: 0 pages reserved
[    0.000000]   Normal zone: 64768 pages, LIFO batch:15
[    0.000000] AM335X ES1.0 (neon )
[    0.000000] PERCPU: Embedded 8 pages/cpu @c0934000 s9408 r8192 d15168 u32768
[    0.000000] pcpu-alloc: s9408 r8192 d15168 u32768 alloc=8*4096
[    0.000000] pcpu-alloc: [0] 0
[    0.000000] Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 64768
[    0.000000] Kernel command line: console=ttyO0,115200n8 init=/sbin/init
[    0.000000] PID hash table entries: 1024 (order: 0, 4096 bytes)
[    0.000000] Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
[    0.000000] Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
[    0.000000] __ex_table already sorted, skipping sort
[    0.000000] allocated 524288 bytes of page_cgroup
[    0.000000] please try 'cgroup_disable=memory' option if you don't want memory cgroups
[    0.000000] Memory: 255MB = 255MB total
[    0.000000] Memory: 236136k/236136k available, 26008k reserved, 0K highmem
[    0.000000] Virtual kernel memory layout:
[    0.000000]     vector  : 0xffff0000 - 0xffff1000   (   4 kB)
[    0.000000]     fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)
[    0.000000]     vmalloc : 0xd0800000 - 0xff000000   ( 744 MB)
[    0.000000]     lowmem  : 0xc0000000 - 0xd0000000   ( 256 MB)
[    0.000000]     pkmap   : 0xbfe00000 - 0xc0000000   (   2 MB)
[    0.000000]     modules : 0xbf800000 - 0xbfe00000   (   6 MB)
[    0.000000]       .text : 0xc0008000 - 0xc0612cf0   (6188 kB)
[    0.000000]       .init : 0xc0613000 - 0xc06554c0   ( 266 kB)
[    0.000000]       .data : 0xc0656000 - 0xc06cc020   ( 473 kB)
[    0.000000]        .bss : 0xc06cc020 - 0xc0725e3c   ( 360 kB)
[    0.000000] Hierarchical RCU implementation.
[    0.000000] RCU restricting CPUs from NR_CPUS=4 to nr_cpu_ids=1.
[    0.000000] NR_IRQS:16 nr_irqs:16 16
[    0.000000] IRQ: Found an INTC at 0xfa200000 (revision 5.0) with 128 interrupts
[    0.000000] Total of 128 interrupts on 1 active controller
[    0.000000] OMAP clockevent source: GPTIMER1 at 24000000 Hz
[    0.000000] sched_clock: 32 bits at 24MHz, resolution 41ns, wraps every 178956ms
[    0.000000] OMAP clocksource: GPTIMER2 at 24000000 Hz
[    0.000000] Console: colour dummy device 80x30
[    0.000352] Calibrating delay loop... 545.07 BogoMIPS (lpj=531968)
[    0.015411] pid_max: default: 32768 minimum: 301
[    0.015645] Security Framework initialized
[    0.015742] Mount-cache hash table entries: 512
[    0.025667] Initializing cgroup subsys cpuacct
[    0.025699] Initializing cgroup subsys memory
[    0.025762] Initializing cgroup subsys blkio
[    0.025906] CPU: Testing write buffer coherency: ok
[    0.026433] CPU0: thread -1, cpu 0, socket -1, mpidr 0
[    0.026510] Setting up static identity map for 0x8038c820 - 0x8038c86c
[    0.027897] Brought up 1 CPUs
[    0.027921] SMP: Total of 1 processors activated (545.07 BogoMIPS).
[    0.029213] devtmpfs: initialized
[    0.093759] pinctrl core: initialized pinctrl subsystem
[    0.093979] rstctl core: initialized rstctl subsystem
[    0.094476] regulator-dummy: no parameters
[    0.094989] NET: Registered protocol family 16
[    0.095756] DMA: preallocated 256 KiB pool for atomic coherent allocations
[    0.105540] pinctrl-single 44e10800.pinmux: 142 pins at pa f9e10800 size 568
[    0.106313] platform 49000000.edma: alias fck already exists
[    0.106345] platform 49000000.edma: alias fck already exists
[    0.106373] platform 49000000.edma: alias fck already exists
[    0.107588] gpiochip_add: registered GPIOs 0 to 31 on device: gpio
[    0.107772] OMAP GPIO hardware version 0.1
[    0.109119] gpiochip_add: registered GPIOs 32 to 63 on device: gpio
[    0.110441] gpiochip_add: registered GPIOs 64 to 95 on device: gpio
[    0.111908] gpiochip_add: registered GPIOs 96 to 127 on device: gpio
[    0.112441] of_get_named_gpio_flags exited with status 52
[    0.112472] gpio-rctrl rstctl.3: loaded OK
[    0.117271] omap-gpmc 50000000.gpmc: GPMC revision 6.0
[    0.120549] hw-breakpoint: debug architecture 0x4 unsupported.
[    0.122754] cpsw.0: No hwaddr in dt. Using 84:eb:18:ec:46:14 from efuse
[    0.122786] cpsw.1: No hwaddr in dt. Using 84:eb:18:ec:46:16 from efuse
[    0.138287] bio: create slab <bio-0> at 0
[    0.150454] edma-dma-engine edma-dma-engine.0: TI EDMA DMA engine driver
[    0.150687] of_get_named_gpio_flags: can't parse gpios property
[    0.150903] vmmcsd_fixed: 3300 mV
[    0.153963] SCSI subsystem initialized
[    0.154450] usbcore: registered new interface driver usbfs
[    0.154583] usbcore: registered new interface driver hub
[    0.154860] usbcore: registered new device driver usb
[    0.156925] omap_i2c 44e0b000.i2c: bus 0 rev0.11 at 400 kHz
[    0.158447] input: tps65217_pwr_but as /devices/ocp.2/44e0b000.i2c/i2c-0/0-0024/input/input0
[    0.160667] DCDC1: at 1500 mV
[    0.161809] vdd_mpu: 925 <--> 1325 mV at 1100 mV
[    0.162985] vdd_core: 925 <--> 1150 mV at 1100 mV
[    0.164097] LDO1: at 1800 mV
[    0.165176] LDO2: at 3300 mV
[    0.167118] LDO3: 1800 mV
[    0.168280] LDO4: at 3300 mV
[    0.169268] tps65217 0-0024: TPS65217 ID 0xe version 1.2
[    0.170037] omap_i2c 44e0b000.i2c: unable to select pin group
[    0.170750] omap_i2c 4819c000.i2c: bus 1 rev0.11 at 100 kHz
[    0.173106] omap_i2c 4819c000.i2c: unable to select pin group
[    0.173345] media: Linux media interface: v0.10
[    0.173450] Linux video capture interface: v2.00
[    0.173573] pps_core: LinuxPPS API ver. 1 registered
[    0.173668] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it>
[    0.174404] Advanced Linux Sound Architecture Driver Initialized.
[    0.175603] Switching to clocksource gp_timer
[    0.193884] NET: Registered protocol family 2
[    0.194901] TCP established hash table entries: 2048 (order: 2, 16384 bytes)
[    0.194989] TCP bind hash table entries: 2048 (order: 3, 40960 bytes)
[    0.195080] TCP: Hash tables configured (established 2048 bind 2048)
[    0.195175] TCP: reno registered
[    0.195268] UDP hash table entries: 256 (order: 1, 12288 bytes)
[    0.195317] UDP-Lite hash table entries: 256 (order: 1, 12288 bytes)
[    0.195742] NET: Registered protocol family 1
[    0.196309] RPC: Registered named UNIX socket transport module.
[    0.196330] RPC: Registered udp transport module.
[    0.196344] RPC: Registered tcp transport module.
[    0.196358] RPC: Registered tcp NFSv4.1 backchannel transport module.
[    0.196735] Trying to unpack rootfs image as initramfs...
[    2.120833] Freeing initrd memory: 14772K
[    2.121553] CPU PMU: probing PMU on CPU 0
[    2.121583] hw perfevents: enabled with ARMv7 Cortex-A8 PMU driver, 5 counters available
[    2.122107] omap2_mbox_probe: platform not supported
[    2.126022] VFS: Disk quotas dquot_6.5.2
[    2.126253] Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
[    2.127626] NFS: Registering the id_resolver key type
[    2.127722] Key type id_resolver registered
[    2.127738] Key type id_legacy registered
[    2.127805] jffs2: version 2.2. (NAND) (SUMMARY)  © 2001-2006 Red Hat, Inc.
[    2.128261] msgmni has been set to 490
[    2.131127] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 249)
[    2.131154] io scheduler noop registered
[    2.131171] io scheduler deadline registered
[    2.131223] io scheduler cfq registered (default)
[    2.133056] tps65217-bl tps65217-bl: no platform data provided
[    2.133098] tps65217-bl: probe of tps65217-bl failed with error -22
[    2.134007] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
[    2.136755] omap_uart 44e09000.serial: did not get pins for uart0 error: -19
[    2.137041] 44e09000.serial: ttyO0 at MMIO 0x44e09000 (irq = 88) is a OMAP UART0
[    2.854188] console [ttyO0] enabled
[    2.858996] [drm] Initialized drm 1.1.0 20060810
[    2.877638] brd: module loaded
[    2.887912] loop: module loaded
[    2.891377] at24 0-0050: 32768 byte 24c256 EEPROM, writable, 1 bytes/write
[    2.898662] at24 1-0054: 32768 byte 24c256 EEPROM, writable, 1 bytes/write
[    2.905936] at24 1-0055: 32768 byte 24c256 EEPROM, writable, 1 bytes/write
[    2.913206] at24 1-0056: 32768 byte 24c256 EEPROM, writable, 1 bytes/write
[    2.920476] at24 1-0057: 32768 byte 24c256 EEPROM, writable, 1 bytes/write
[    2.958928] bone-capemgr bone_capemgr.8: bone: scan failed (1 time)
[    3.497991] bone-capemgr bone_capemgr.8: bone: scan failed (2 time)
[    4.037047] bone-capemgr bone_capemgr.8: bone: scan failed (3 time)
[    4.576109] bone-capemgr bone_capemgr.8: bone: scan failed (4 time)
[    5.115170] bone-capemgr bone_capemgr.8: bone: scan failed (5 time)
[    5.654233] bone-capemgr bone_capemgr.8: bone: scan failed (6 time)
[    6.193299] bone-capemgr bone_capemgr.8: bone: scan failed (7 time)
[    6.732358] bone-capemgr bone_capemgr.8: bone: scan failed (8 time)
[    7.271421] bone-capemgr bone_capemgr.8: bone: scan failed (9 time)
[    7.810483] bone-capemgr bone_capemgr.8: bone: scan failed (10 time)
[    8.318470] bone-capemgr bone_capemgr.8: Failed to scan baseboard eeprom
[    8.325535] bone-capemgr: probe of bone_capemgr.8 failed with error -110
[    8.335067] nand_get_flash_type: 2c,da against 2c,da
[    8.340596] ONFI param page 0 valid
[    8.344268] ONFI flash detected
[    8.347586] NAND device: Manufacturer ID: 0x2c, Chip ID: 0xda (Micron MT29F2G08ABAEAWP), 256MiB, page size: 2048, OOB size: 64
[    8.359500] omap2-nand: detected x8 NAND flash
[    8.364165] nand: using OMAP_ECC_BCH8_CODE_HW ECC scheme
[    8.369771] omap2-nand: using custom ecc layout
[    8.374611] 10 ofpart partitions found on MTD device omap2-nand.0
[    8.381004] Creating 10 MTD partitions on "omap2-nand.0":
[    8.386678] 0x000000000000-0x000000020000 : "spl"
[    8.393558] 0x000000020000-0x000000040000 : "spl_backup1"
[    8.401012] 0x000000040000-0x000000060000 : "spl_backup2"
[    8.408432] 0x000000060000-0x000000080000 : "spl_backup3"
[    8.415705] 0x000000080000-0x000000240000 : "u-boot"
[    8.423965] 0x000000240000-0x000000260000 : "bootenv"
[    8.430927] 0x000000260000-0x000000280000 : "fdt"
[    8.437539] 0x000000280000-0x000000780000 : "kernel"
[    8.448551] 0x000000800000-0x000001c00000 : "root"
[    8.471965] 0x000001c00000-0x000003000000 : "config"
[    8.495734] OneNAND driver initializing
[    8.503245] edma-dma-engine edma-dma-engine.0: allocated channel for 0:17
[    8.510533] edma-dma-engine edma-dma-engine.0: allocated channel for 0:16
[    8.520837] edma-dma-engine edma-dma-engine.0: allocated channel for 0:43
[    8.528123] edma-dma-engine edma-dma-engine.0: allocated channel for 0:42
[    8.537378] usbcore: registered new interface driver asix
[    8.543222] usbcore: registered new interface driver cdc_ether
[    8.549503] usbcore: registered new interface driver smsc95xx
[    8.555625] usbcore: registered new interface driver net1080
[    8.561648] usbcore: registered new interface driver cdc_subset
[    8.567959] usbcore: registered new interface driver zaurus
[    8.573945] usbcore: registered new interface driver cdc_ncm
[    8.580688] usbcore: registered new interface driver cdc_acm
[    8.586645] cdc_acm: USB Abstract Control Model driver for USB modems and ISDN adapters
[    8.595023] Initializing USB Mass Storage driver...
[    8.600249] usbcore: registered new interface driver usb-storage
[    8.606548] USB Mass Storage support registered.
[    8.611576] musb-hdrc: version 6.0, ?dma?, otg (peripheral+host)
[    8.618233] musb-hdrc musb-hdrc.0.auto: pdev->id = 0
[    8.623473] musb-hdrc musb-hdrc.0.auto: drivers/usb/musb/musb_dsps.c:468 dsps_musb_init: OK
[    8.632238] musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, bulk combine, bulk split, HB-ISO Rx, HB-ISO Tx, SoftConn)
[    8.632261] musb-hdrc: MHDRC RTL version 2.0
[    8.632275] musb-hdrc: setup fifo_mode 4
[    8.632303] musb-hdrc: 28/31 max ep, 16384/16384 memory
[    8.632456] musb-hdrc musb-hdrc.0.auto: *** mode=3
[    8.637501] musb-hdrc musb-hdrc.0.auto: *** power=250
[    8.643443] musb-hdrc musb-hdrc.1.auto: pdev->id = 1
[    8.648689] musb-hdrc musb-hdrc.1.auto: drivers/usb/musb/musb_dsps.c:468 dsps_musb_init: OK
[    8.657455] musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, bulk combine, bulk split, HB-ISO Rx, HB-ISO Tx, SoftConn)
[    8.657476] musb-hdrc: MHDRC RTL version 2.0
[    8.657490] musb-hdrc: setup fifo_mode 4
[    8.657512] musb-hdrc: 28/31 max ep, 16384/16384 memory
[    8.657630] musb-hdrc musb-hdrc.1.auto: *** mode=1
[    8.662671] musb-hdrc musb-hdrc.1.auto: *** power=250
[    8.667978] musb-hdrc musb-hdrc.1.auto: MUSB HDRC host driver
[    8.674382] musb-hdrc musb-hdrc.1.auto: new USB bus registered, assigned bus number 1
[    8.682617] musb-hdrc musb-hdrc.1.auto: supports USB remote wakeup
[    8.682732] usb usb1: default language 0x0409
[    8.682790] usb usb1: udev 1, busnum 1, minor = 0
[    8.682814] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
[    8.689942] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    8.697513] usb usb1: Product: MUSB HDRC host driver
[    8.702730] usb usb1: Manufacturer: Linux 3.8.13 musb-hcd
[    8.708397] usb usb1: SerialNumber: musb-hdrc.1.auto
[    8.714277] usb usb1: usb_probe_device
[    8.714305] usb usb1: configuration #1 chosen from 1 choice
[    8.714371] usb usb1: adding 1-0:1.0 (config #1, interface 0)
[    8.714581] hub 1-0:1.0: usb_probe_interface
[    8.714603] hub 1-0:1.0: usb_probe_interface - got id
[    8.714630] hub 1-0:1.0: USB hub found
[    8.718700] hub 1-0:1.0: 1 port detected
[    8.722864] hub 1-0:1.0: standalone hub
[    8.722885] hub 1-0:1.0: individual port power switching
[    8.722903] hub 1-0:1.0: no over-current protection
[    8.722920] hub 1-0:1.0: Single TT
[    8.722942] hub 1-0:1.0: TT requires at most 8 FS bit times (666 ns)
[    8.722962] hub 1-0:1.0: power on to power good time: 10ms
[    8.723006] hub 1-0:1.0: local power source is good
[    8.723113] hub 1-0:1.0: enabling power on all ports
[    8.724160] mousedev: PS/2 mouse device common for all mice
[    8.732521] omap_rtc 44e3e000.rtc: rtc core: registered 44e3e000.rtc as rtc0
[    8.740307] i2c /dev entries driver
[    8.745700] pps_ldisc: PPS line discipline registered
[    8.751177] Driver for 1-wire Dallas network protocol.
[    8.758405] omap_wdt: OMAP Watchdog Timer Rev 0x01: initial timeout 60 sec
[    8.765976] cpuidle: using governor ladder
[    8.770298] cpuidle: using governor menu
[    8.774835] of_get_named_gpio_flags exited with status 6
[    8.774854] of_get_named_gpio_flags: can't parse gpios property
[    8.774870] of_get_named_gpio_flags: can't parse gpios property
[    8.774907] omap_hsmmc mmc.4: of_parse_phandle_with_args of 'reset' failed
[    8.782141] omap_hsmmc mmc.4: Failed to get rstctl; not using any
[    8.788924] edma-dma-engine edma-dma-engine.0: allocated channel for 0:25
[    8.796135] edma-dma-engine edma-dma-engine.0: allocated channel for 0:24
[    8.803470] mmc.4 supply vmmc_aux not found, using dummy regulator
[    8.810425] omap_hsmmc mmc.4: pins are not configured from the driver
[    8.824282] hub 1-0:1.0: state 7 ports 1 chg 0000 evt 0000
[    8.844228] pinctrl-single 44e10800.pinmux: pin 44e10854 already requested by 44e10800.pinmux; cannot claim for gpio-leds.7
[    8.855921] pinctrl-single 44e10800.pinmux: pin-21 (gpio-leds.7) status -22
[    8.863226] pinctrl-single 44e10800.pinmux: could not request pin 21 on device pinctrl-single
[    8.872209] leds-gpio gpio-leds.7: pins are not configured from the driver
[    8.879473] of_get_named_gpio_flags exited with status 53
[    8.879497] of_get_named_gpio_flags exited with status 54
[    8.879518] of_get_named_gpio_flags exited with status 55
[    8.879539] of_get_named_gpio_flags exited with status 56
[    8.879602] of_get_named_gpio_flags exited with status 53
[    8.879898] of_get_named_gpio_flags exited with status 54
[    8.880118] of_get_named_gpio_flags exited with status 55
[    8.880308] of_get_named_gpio_flags exited with status 56
[    8.880921] ledtrig-cpu: registered to indicate activity on CPUs
[    8.887642] edma-dma-engine edma-dma-engine.0: allocated channel for 0:36
[    8.894835] omap-sham 53100000.sham: hw accel on OMAP rev 4.3
[    8.902962] omap-aes 53500000.aes: OMAP AES hw accel rev: 3.2
[    8.909246] edma-dma-engine edma-dma-engine.0: allocated channel for 0:5
[    8.916454] edma-dma-engine edma-dma-engine.0: allocated channel for 0:6
[    8.928924] usbcore: registered new interface driver usbhid
[    8.934836] usbhid: USB HID core driver
[    8.941814] TCP: cubic registered
[    8.945330] Initializing XFRM netlink socket
[    8.949889] NET: Registered protocol family 17
[    8.954706] NET: Registered protocol family 15
[    8.959549] Key type dns_resolver registered
[    8.964193] VFP support v0.3: implementor 41 architecture 3 part 30 variant c rev 3
[    8.972304] ThumbEE CPU extension supported.
[    8.976906] Registering SWP/SWPB emulation handler
[    8.982912] registered taskstats version 1
[    9.039022] davinci_mdio 4a101000.mdio: davinci mdio revision 1.6
[    9.045436] davinci_mdio 4a101000.mdio: detected phy mask fffffffe
[    9.059860] libphy: 4a101000.mdio: probed
[    9.064163] davinci_mdio 4a101000.mdio: phy[0]: device 4a101000.mdio:00, driver SMSC LAN8710/LAN8720
[    9.074042] Detected MACID = 84:eb:18:ec:46:14
[    9.078725] cpsw 4a100000.ethernet: NAPI disabled
[    9.085396] omap_rtc 44e3e000.rtc: setting system clock to 2000-01-01 00:00:00 UTC (946684800)
[    9.101807] ALSA device list:
[    9.104949]   No soundcards found.
[    9.109144] Freeing init memory: 264K
[    9.113062] Failed to execute /init
[    9.375255] compile Dec  3 2015--15:59:46
[    9.379523] CM_PER_SPI1_CLKCTRL 0x10002
[    9.383549] spi_vaddr 0xfa1a0000
[    9.386931] version 0x40300a0b
[    9.390120] OMAP2_MCSPI_SYSSTATUS 0x1
[    9.393949] OMAP2_MCSPI_MODULCTRL 0x1
[    9.397775] OMAP2_MCSPI_CHCONF0 0x180103c5
[    9.402309] Initial OMAP2_MCSPI_IRQSTATUS{0x0}OMAP2_MCSPI_IRQENABLE{0x0}
[    9.409454] hash ok
[    9.411677] hashtest OK
[    9.418228] bitmain-asic: success to register device
[    9.433706] Detect hardware version = 4
[    9.437780] fix hardware version
[    9.441160] hardware_version = 0x4
[    9.444819] S5 ctrl board test V1.1
[    9.448729] bitmain_asic_open ok
[   10.808985] stop send work to all chain
[   10.814200] Sending open core work
[   10.819132] Send new block cmd
[   10.923742] Division by zero in kernel.
[   10.927800] [<c001051d>] (unwind_backtrace+0x1/0x8c) from [<c0193c53>] (Ldiv0+0x9/0x12)
[   10.936215] [<c0193c53>] (Ldiv0+0x9/0x12) from [<bf805843>] (nonce_query+0x4e/0xe4 [bitmain_spi])
[   10.945508] [<bf805843>] (nonce_query+0x4e/0xe4 [bitmain_spi]) from [<bf801891>] (bitmain_asic_close+0x68/0x114 [bitmain_spi])
[   10.957437] [<bf801891>] (bitmain_asic_close+0x68/0x114 [bitmain_spi]) from [<c0094f27>] (__fput+0x9b/0x154)
[   10.967709] [<c0094f27>] (__fput+0x9b/0x154) from [<c003b13d>] (task_work_run+0x79/0x8c)
[   10.976189] [<c003b13d>] (task_work_run+0x79/0x8c) from [<c000eb75>] (do_work_pending+0x51/0x5c)
[   10.985384] [<c000eb75>] (do_work_pending+0x51/0x5c) from [<c000c693>] (work_pending+0x9/0x1a)
[   10.994388] timeout {0x189b}
[   10.997402] rev timeout {0x9b180080}
[   11.001212] set_baud cmd_buf[0]{0x86}cmd_buf[1]{0x10}cmd_buf[2]{0x1a}cmd_buf[3]{0x17}
[   11.009405] send BC data:
[   11.009405] 0x0000: 0x03 0x00 0x00 0x00 0x86 0x10 0x1a 0x17
[   11.023346] send BC data:
[   11.023346] 0x0000: 0x03 0x02 0x00 0x00 0x86 0x10 0x1a 0x17
[   11.040921] send BC data:
[   11.040921] 0x0000: 0x03 0x05 0x00 0x00 0x86 0x10 0x1a 0x17
[   11.152255] set_voltage cmd_buf[0]{0xaa}cmd_buf[1]{0xb7}cmd_buf[2]{0x25}cmd_buf[3]{0xcd}
[   11.160711] send BC data:
[   11.160711] 0x0000: 0x03 0x00 0x00 0x1a 0xaa 0xb7 0x25 0xcd
[   11.175687] send BC data:
[   11.175687] 0x0000: 0x03 0x02 0x00 0x1a 0xaa 0xb7 0x25 0xcd
[   11.193265] send BC data:
[   11.193265] 0x0000: 0x03 0x05 0x00 0x1a 0xaa 0xb7 0x25 0xcd
[   11.304598] bitmain_asic_close
[   11.765096] jffs2: Empty flash at 0x00fa918c ends at 0x00fa9800
[   11.807189] jffs2: Empty flash at 0x00fac814 ends at 0x00fad000
[   11.910970] jffs2: notice: (148) jffs2_build_xattr_subsystem: complete building xattr subsystem, 0 of xdatum (0 unchecked, 0 orphan) and 0 of xref (0 dead, 0 orphan) found.
[   12.882167] net eth0: initializing cpsw version 1.12 (0)
[   12.890047] net eth0: phy found : id is : 0x7c0f1
[   12.895033] libphy: PHY 4a101000.mdio:01 not found
[   12.900067] net eth0: phy 4a101000.mdio:01 not found on slave 1
[   15.965277] libphy: 4a101000.mdio:00 - Link is Up - 100/Full

Copyright © 2013-2014, Bitmain Technologies


Title: Re: Collecting Data on B8 S7 Failure Rates
Post by: dogie on February 14, 2016, 03:12:55 AM
What would they lose buy having someone answer the phone and sell parts at list price?
I don't know, and I don't know what happened to the US repair place and why its not being used as much. Seemed a good idea but I guess they didn't like the cost.


S5 (Was the opposite of the S3 mmini tank, the plastic sides warped, hash boards fried, but many people made a lot of money early.
The S5 was manufactured on a scale we'd never before seen in Bitcoin land, so the 'high' fail rate mainly just more units existing. And I mean a lot more.


I learned with the S7 if you have a fan failure you are responsible for sourcing and replacing the fan.
The fans are a shame. I repeatedly asked them to reconsider a model as there were many reports of the same premature failure method - the bearing failing and making the fan assembly literally fall off. I reported it on the S4, but it was used again in S5, S7 etc.


I don't believe Spondoolies lost money overall
Money before + money in = money out + money after. We all know they don't have much money after so either they didn't sell enough or their costs were too high (more likely).


I think a company could step in and start selling a $599.00 S7 equivalent today for two weeks and stop for a week and only sell them for 999.00 or some similar marketing game which would still make them obscene profits but if they offered average customer service and RMA process as
No one would buy a miner at a 70% price premium in the hoep of better support. As we've seen with re-sellers, customers are price and delivery sensitive rather than support sensitive, as re-sellers inherently increase the warranty risk.


Don't even talk about a startup full of excited entrepreneurs who would always be on top of things.
I have worked with far too many pre-startup mining companies, unfortunately enthusiasm doesn't pay the bills.


There must be a whole different side to Bitmain service and response that I have not been able to experience.
I don't know, its a hard job dealing with markets across the entire world on a budget. I have to say though, the volume of support requests wasn't that unreasonable for the amount of orders going out so at least a size-able majority would never require contact again.


I understand vacation, I've already said my thing there, too many ways to handle people on vacation, everyone who makes something people want on a weekend eventually figures out a way to give it to them.
Chinese vacations are very, very different to anything we can imagine over here. People don't just 'take' holiday over these periods, the entire COUNTRY goes on holiday simultaneously. I guess the only comparison would be from Christmas to New Years but there were no gaps in between and no one did anything. This includes couriers and distribution on top of staff.


**Edit 1: My apologies for the size of the pictures. If the mods want them removed so it doesn't take the whole page let me know.
You can manually set width, height or both:
Code:
[img width=600]https://i.imgur.com/AyvA3ph.jpg[/img]

And make the image a link back to the full size:
Code:
[url=https://i.imgur.com/AyvA3ph.jpg][img width=600]https://i.imgur.com/AyvA3ph.jpg[/img][/url]


Title: Re: Collecting Data on B8 S7 Failure Rates
Post by: boomin on February 14, 2016, 08:36:45 AM
I'm going to guess that a lot of the failures are novice miners without temperature controlled environment.  Or power supplies that aren't up to snuff.  I blew up some S4's trying to overclock and get that .1% but my time repairing and downtime of shipping etc made it FAR from worth it.  I just wish we could turn down Difficulty LOL - that's my real current problem.  Really Fu**ing up my ROI forecasts!

Carry on.

Boomin