Newsgroups: comp.dcom.sys.cisco
Path: utzoo!utgpu!cunews!bnrgate!bcars223!fortinp
From: fortinp@bcars223.bnr.ca (Pierre Fortin)
Subject: Re: help needed debugging DDS 56kb prob
Message-ID: <1990Sep11.065249.26325@bnrgate.bnr.ca>
Summary: V35 problems?  BOY!! Did we have V35 problems...
Sender: news@bnrgate.bnr.ca (USENET News System)
Organization: Bell-Northern Research, Ltd. Ottawa Ontario CANADA
References: <25924@boulder.Colorado.EDU> <3970@ursa-major.SPDCC.COM>
Date: Tue, 11 Sep 90 06:52:49 GMT

In article <3970@ursa-major.SPDCC.COM>, dyer@spdcc.COM (Steve Dyer) writes:
> 
> In any event, the "fix" appears to have been a coincidence.  Having moved the
> equipment to its permanent resting place, the carrier transitions and
> interface resets (after a stable, peaceful weekend) have returned with a
> vengeance, even with the parameter set to 56kb.  I think I'm in the
> nether world of flaky cables/modems, and will pursue it on that level.

Here's a short list of the V.35 problems I've encountered over the last 
17 months:
 
  - V.35 applique Rev 3: inverted clocks; mods applied to some boards

  - V.35 applique Rev 4: inverted clocks; mods for Rev 3 boards applied
                         inadvertently to these boards (I have personally
                         seen at least three different attempts at clearing
                         up this problem)
                         We even had one unit in which the RxD line was 
                         leaking back out over one of the clock leads,
                         giving the appearance of a bad DCE.

  - DL551V T1 CSU/DSU:   most units bad (power supply drifting, incorrect
                         factory options, bad repairs, poor QC, etc.)  All
                         units were to be returned to Digital Link for 
                         checkout; don't know current status of this.

  - Screws (Yes, SCREWS!):  WHY is it that something as simple as a screw 
                         (actually screw threads) can cause problems; I 
                         guess we need patience testers...   V.35 connectors
                         are available with EITHER single- or double-helix
                         retaining screws!  Go figure...

  - V.35 cables:         Nearly all cables we tested were of poor quality.
                         We designed our own cable (verified to 70 feet)
                         where each pair is individually shielded (with the
                         source end only grounded); then an overall shield
                         grounded at both ends via a six-inch pig-tail to 
                         a spade-lug.  Major improvements!!!

  - MCI HDLC controller: The Rockwell HDLC controller chips with a date-code
                         prior to a certain date (contact cisco for date)
                         had bugs when the applied voltage was less than 
                         EXACTLY 5.00V.  In some literature I received from
                         cisco, there was a small piece of pink paper which
                         said that this should only affect short X.25 packets
                         with odd packet lengths; but, where there's smoke...

  - V.35 applique Rev 6: This applique is correct.  We are continuing to 
                         replace all pre-Rev-6 appliques with these newer ones.

  - Operations:          Our operations personnel used to make statements 
                         like:  "The CSU/DSUs never work in loopback"; this
                         has since been corrected.  Any comm gear which does
                         not work in loopback when the manufacturer claims
                         it does should be highly suspect.

                         In another instance, two links from different 
                         remotes (should have been [A]---[B0&B1]---[C]) were
                         connected incorrectly ([A]---[B1&B0]--[C]).  With
                         our fully redundant mesh topology, the ciscos never
                         complained, but you should have seen the highly
                         inefficient routing, BUT IT WORKED from the users'
                         perspective (a tip of the hat to cisco!!).

  - "Nah!" ;^)           Someone I talked to in another company which shall
                         forever remain nameless managed to find a cable and
                         screw it in.  Upon closer inspection, the cable was
                         found to have a female connector.  If you fail to 
                         spot the humor in this, check the sex of the V.35
                         appliques on your cisco...
  
These are the major points I can think of off the top of my head at this time
(it's 02:45).  
 
The general thrust of my message here is that, for what should be a mature
interface, expect problems ANYWHERE.  Likely you will find MORE than one 
problem.  Perhaps this has to do with the fact (someone please prove me wrong)
that there is no V.35 standard beyond the original which only covers the
approx. 40KB speed.  
 
Other things to note about V.35:
  - the DCE supplies both clocks SCR and SCT
  - the DTE *returns* the Tx clock (SCTE) to the DCE to account for 
    varying cable lengths at higher speeds 
  - double-check cable polarities on ALL pairs
 
Otherwise, V.35 was a piece of cake....  in the face!

...and now we're getting ready (hah!!) for the onslaught of T3 equipment...
Huh?  Why am I standing on this chair with a V.35 cable around my neck?

  
> 
> -- 
> Steve Dyer
> dyer@ursa-major.spdcc.com aka {ima,harvard,rayssd,linus,m2c}!spdcc!dyer
> dyer@arktouros.mit.edu, dyer@hstbme.mit.edu

Pierre Fortin
fortinp@bnr.ca

P.S.: If enough people send in their $35 (easy to remember ;^) ), we will
      seriously consider publishing  "Living with V.35" complete with over
      400 pages of tests, results, multi-channel scope traces, levels,
      power supply voltages, pictures of modifications, plus much more...
      :^)    :^)    P^)   ;^)
