| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 4287.1 | There are many fly-by-night cable installers out there.... | NETCAD::BATTERSBY | | Tue Mar 18 1997 09:07 | 25 |
| I would offer a couple of suggestions in the form of questions
to put in proper context the statement...
>> All wiring is Cat-5 cable that has been checked
>>with an analyzer.
What make/brand of Cat-5 cable was installed? Berk-Tek? Mohawk? etc.
What kind/make of Cat-5 analyzer was used? Wirescope? Pentatester? etc.
There are lots of cable vendors who make Cat-5 cable of a wide variable
quality.
There are also testers/analyzers (and installers/services) of variable
quality too. Vendors who have recently come into the business of
installing Cat-5 cable because of the increase in 10BASE-T useage,
think they can install Cat-5 cable for applications like FDDI and
100BASE-T using the same techniques and considerations that they
can get away with on 10BASE-T are likely on the increase.
Things to look for are long runs where the Cat-5 cable is run parallel
and perhaps even tie-wrapped with electrical conduit, run too close
to flourescent ceiling light fixtures, run in elevator shafts near large
motors, or care was not taken in total elimination/avoidance of kinks
in the cable.
Bob
|
| 4287.2 | | NPSS::WADE | Network Systems Support | Tue Mar 18 1997 10:02 | 5 |
|
Please escalate this as an IPMT case against the DEFHU.
Bill
|
| 4287.3 | Update - Looks like the DEFPA-UA is the problem | CSC32::R_BUCK | Authenticated and assimilated | Tue Mar 25 1997 16:27 | 32 |
| Figured I should at lease provide an update and some answers to the
questions in .1 Per Bill Wade, the customer problem was elevated as an
IPMT and quite a bit more research and testing has been done.
Field engineer did not identify the actual manufacturer of the premise
wiring or even who installed it. The device used to test the wiring is
a Microtest PentaScanner (SP?). Test data was collected for review
later if needed. Testing was done by injecting a signal at the wiring
closet end and attaching the analyzer to the wall plate with a short
piece of cable (1 meter?).
In the lab here we managed to get a ~207 ft Cat-5 cable made that we
then connected a DECconcentrator 900TH and an Alpha system with a
DEFPA-UA, (REV D01 we believe). Ran a pretty extensive test with
no errors after moving 4 billion frames. The test results were
communicated to the field engineer and updated in the IPMT case.
Most recent information from the field engineer is that some Silicon
Graphics workstations, connected over the same wiring, running TP FDDI
to the DECconcentrator 900TH, are working fine. Based on this
information, the field engineer is concentrating on the DEFPA-UA
adapters as the faulty component in this situation. He believes that
the adapters in the Alpha systems at his site are rev C01. There is
still a remote chance that the drivers for the adapter that are
provided with the version of Digital UNIX he is running, could be part
of the problem. However, since this appears to be a signal strength
issue, it would seem highly unlikely that software drivers have
anything to do with it.
Thanks to all for your comments, questions, and suggestions.
Randall Buck
MCS - Network Support
|
| 4287.4 | A problem has been identified | CSC32::R_BUCK | Authenticated and assimilated | Tue Apr 15 1997 10:14 | 7 |
| Another update:
Latest IPMT update confirms a problem with FDDI UTP products, when used
with cable lengths exceeding 30 meters. I am not sure if I can/should
publish the entire update since it appears to indicate that additional
work needs to be done and proper procedures followed to get the problem
corrected. Bottom line, expect a product revision and an ECO/FCO.
|
| 4287.5 | Don't know about FCO, ECOs are in process | NPSS::KIRK | | Thu Apr 17 1997 15:18 | 7 |
| Please do not assume that an FCO will be implemented. Not all
product suffers from the problem. When we first tried to isolate the
problem, we had to test a significant number of units to find enough
for the analysis required.
We are working the ECO implementations. When they are in place we will
have a mechanism to replace known failed units at customer sites.
|
| 4287.6 | | CSC32::R_BUCK | Authenticated and assimilated | Mon Apr 21 1997 15:41 | 13 |
| >Please do not assume that an FCO will be implemented. Not all
>product suffers from the problem. When we first tried to isolate
>the problem, we had to test a significant number of units to find
>enough for the analysis required.
Ahh... I do apoligize for stating that an FCO would be coming. Tried
to be carefull about what I put in the reply. Certainly do not want to
pass along bad information! Thanks again for the update and
correction. Really appreciate all of the work put into solving this
one.
Randall Buck
MCS - Network Support
|