[net.lan] Overall failure rates of Sytek pcp cards

katzman@harvard.ARPA (Cynthia Katzman) (01/09/85)

I just finished checking out the overall failure rate of 20/222, pcp
cards here at Harvard.  (Budget time...)  This information is based
on an 8 month period, with an average of 302 pcp cards in use.  Infant
mortality was NOT really a factor as only 40 new cards were factored
in over this 8 month period.  But, a glance of some information I
have obtained from the early days, leads me to believe that infant
mortality is really extremely high, and doesn't really represent what
happens after GI gets their hands on those cards!

Over the past 8 months, I've sent back 39 pcp cards, 2 modems (out of
33) and don't ask about the switch.  (ok... its been back to Mountain View
3 times and still doesn't work... verified by the local Sytek tech.
support)  

2 of the 39 cards had to go back immediately to General Instruments.  
(A failure that they simply didn't fix.  Re-set the one card, and it 
shorted the whole box into a re-set.)

The problems varied a wide range, but we now have a 3 day testing
procedure that generally weeds out the cards before they get into 
the field, either back from GI, or new.  Maybe if Sytek Q.C. did
a bit more testing, we wouldn't be stuck with this infant mortality 
problem.  However, I must say I have found both Sytek and GI to be
most helpful.

BOTTOM LINE:

Average monthly failure rate is 2%.
Projected yearly failure rate is 20%.

We have had a number of problems implementing these S-muxes to several
hosts.  EIA flow control is a major concern to use.  Presently, we have
it implemented on only 4 of out 20 hosts.  We feel we really need EIA
because of a healthy and growing EMACS lobby.  DTR is often an issue
as a short spike of only 380 nano-seconds blows a session away.  For
some reason, the Accord DH board likes to toggle DTR when using EIA
flow control.  We have found that after the Able DHs are wrapped for
EIA, they work like a charm in all respects.  There are a couple of other 
thorns in our side.  One is the Series 1 protocol Converter having
problems with both baud rate conversions and dtr (I understand the
new version of the Yale package ought to help..).  The second has
to do with a BBN C70 that simply doesn't want to support both DTR and
DCD, with EIA flow control. (EIA is essential with the PEN editor)

Other than these few problems, we are rather comfortable with the
LocalNet 20 product.  We are looking into the possibility of using
their bisync product.  We have some bisync units presently in test.
I'd like to hear about some practical experiences with bisync.  Anyone
out there?  What may we be getting into?


Cynthia Katzman 
harvard!uvax!katzman 
(617) 495-1272

phil@amdcad.UUCP (Phil Ngai) (01/12/85)

> thorns in our side.  One is the Series 1 protocol Converter having
> problems with both baud rate conversions and dtr (I understand the
> new version of the Yale package ought to help..).  The second has

Speaking of such things, has anyone else tried the new IBM 7171 protocol
converter? We just installed one and it seems to work real nice so far.

-- 
 AMD assumes no responsibility for anything I may say here.

 Phil Ngai (408) 749-5790
 UUCP: {ucbvax,decwrl,ihnp4,allegra}!amdcad!phil
 ARPA: amdcad!phil@decwrl.ARPA