Article View: comp.dcom.sys.cisco
Article #663Re: help needed debugging DDS 56kb prob
From: Pierre Fortin
Date: Tue, 11 Sep 1990 06:52
Date: Tue, 11 Sep 1990 06:52
106 lines
6157 bytes
6157 bytes
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^) ;^)
Technical Details
Message-ID:
<1990Sep11.065249.26325@bnrgate.bnr.ca>Path:
arc1-ca.pugleaf.net!utzoo!utgpu!cunews!bnrgate!bcars223!fortinpReferences:
<25924@boulder.Colorado.EDU> <3970@ursa-major.SPDCC.COM>Show Full Headers
Complete Article Headers
Newsgroups: comp.dcom.sys.cisco Path: arc1-ca.pugleaf.net!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