| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 536.1 | Sun board problem may be.. | CLPR01::PEYRACHE | Sarip Torppus Lanoiger | Fri Dec 03 1993 05:54 | 11 |
|
hi john,
read carrefullly note 730,953,937 in notes files upsar::ethernet_v2
seems to the same problem that you described.
in fact problem related to timing issued on some rev of Sun ethernet board
hope that help you
Jean-Yves
|
| 536.2 | sounds like the clock issue | DELNI::GIUNTA | | Fri Dec 03 1993 11:54 | 10 |
| Sounds like the clocking problem that we run into from time to time. The
notes referenced in the previous reply discuss it at length I believe. I
also have a copy of the report that explains it more fully which I can
forward to you.
Basically, the Sun machine has a board whose clock is out of tolerance. I
forget all the history exactly, but it seems to me that there was a batch or
two of parts slightly out of tolerance, so some of those boards are out there
and cause this problem once in a while. It's a known problem and I think Sun
has been pretty good about replacing the board when requested.
|
| 536.3 | Sounds logical to me | GIDDAY::MORETTI | Not drowning...waving | Sun Dec 05 1993 19:25 | 15 |
|
Cathy/Jean-Yves,
Thanks for the input and especially the info you sent Cathy. It was
very clear in pointing out the SUN problems and the reason behind not
adjusting the 90C to compensate for the SUNs out-of-spec ethernet clock
on SPARC 2's ethernet cards.
The customer is now taking up the issue with SUN but also appears to be
implementin ga DEMPR as a workaround (surely they should fix the root
of the problem=SUN!!) ohwell, we do our best.
Thanks again
John
|
| 536.4 | Ref .2: Copy of the report please | HGOVC::GUPTA | | Mon Dec 13 1993 21:13 | 12 |
| Ref .2:
Hi Cathy,
Can we have a copy of the report at some public place for us to have a
look ?
Or some other way for me to have a copy of the report being referenced
?
Thanks and regards,
Surender
|
| 536.5 | here's the report on clocking problem | DELNI::GIUNTA | | Tue Dec 14 1993 09:57 | 244 |
| <<< MOUSE::SYS$SYSDEVICE:[NOTES$LIBRARY]ETHERNET_V2.NOTE;1 >>>
-< Ethernet V2 >-
================================================================================
Note 1085.5 DECREPEATER 90T - UTP REPEATER 5 of 6
KALI::VISSER 236 lines 19-MAY-1992 14:10
-< problem report >-
--------------------------------------------------------------------------------
Lenac Architecture Group R. Webber
AR/I-4 SASE
J. Visser
Lenac
19 May 92
The Lenac Architecture Project
Ethernet Clock specs and Lenac repeaters
Problem Report for the Digital Ethernet Coaxial Manageable Repeater (DECMR)
with IEEE 802.3 Clocks Out of Specification
Rob Webber and John Visser
Contents:
o Problem Description
o Problem Isolation
o Problem Resolution
o Related Problem History
o Recommendations
1
Ethernet clock specs and Lenac repeaters
Problem Description
___________________
The problem occurs with a SUN Sparc 2 and a SUN IPC, each on
separate thinwire segments which are connected by a DECMR. The SUN IPC
is trying to boot from the SUN Sparc 2, causing large files to be
transferred between the two stations.
The error is a misalignment error. In the middle of a packet the
repeater appears to lose synchronization with the incoming packet. The
repeater then transmits the jam signal (data pattern 010101...) for the
duration of the transmit time.
Large packets (especially maximum size packets) have shown the
problem. Smaller packets (even as large as 934 bytes) have been
transmitted without error.
This problem was reported by Hong Kong University and is designated
as cld # AKO02074.
Problem Isolation
_________________
A LAN Analyzer was used to inspect the packets on the network. The
Analyzer reported that packets appearing on the same segment as the node
which transmitted them appeared normal, however those same packets after
being repeated by the DECMR appeared misaligned.
When the DECMR is replaced by a DEMPR the problem goes away. In
this case the two SUN nodes can communicate without any problems.
The SUN Sparc 2 with an internal Ethernet AUI interface using a 3COM
or DESTA transceiver shows the problem. When the SUN Sparc 2 is replaced
by a SUN SLC the problem also goes away and the SUN IPC can boot
normally.
Neither swapping the DECMR nor the SUN Sparc 2 solves the problem.
Problem Resolution
__________________
The cause of the problem is the SUN Sparc 2 Ethernet clock is not
within IEEE 802.3 specifications.
The reason the problem appears in large packets is with small
packets the cumulative error induced by the bad clock can be compensated
within the DECMR. Depending on the error in the transmitting clock as
the packet gets longer the error builds larger and larger until it
exceeds the elasticity buffer of the DECMR (designed to compensate for
differences in clock speeds within IEEE 802.3 specifications). At that
point the DECMR transmits the jam signal until the end of the packet
(until it senses carrier go away).
This explains why packets become corrupt after being repeated. The
2
Ethernet clock specs and Lenac repeaters
clock error exists even before the packet is repeated, though the
receiving stations and the LAN Analyzer do not detect the problem.
The reason the DEMPR transmits the packets correctly is because it
has a larger elasticity buffer (implemented as a FIFO) than the DECMR.
This allows it to tolerate a wider range of Ethernet clocks.
This also explains why the DECMR works correctly when the SUN Sparc
2 is replaced by a SUN SLC. The SUN SLC does not have the Ethernet clock
problem.
Related Problem History
_______________________
Another SUN Ethernet clock problem was reported on 8-May-1991. In
this case Dennis Faust reported a SUN model 147 was not able to
communicate through a DEMPR. SUN admitted to having an Ethernet clock
problem. A new SUN Ethernet card fixed the problem.
On 29-Nov-1991 Walter Brunner of Field Support detected a very
similar problem. His customer's SUN system would transmit properly
through a DEMPR and certain third party repeaters, though not through a
DECMR. The SUN Ethernet clocks were found to be out of specification.
Recommendations
_______________
The cause of the problem is the SUN Sparc 2 Ethernet clock is not
within IEEE 802.3 specifications. Our recommendation is to replace or
correct the Ethernet connection in the SUN Sparc 2 so that it is within
IEEE 802.3 clock tolerances.
Although it would be possible to modify the DECMR to allow this
problem to exist and still have maximum size packets repeated correctly,
we feel this would not be in the best interest of the customer. It is
not beneficial to the network to have IEEE 802.3 violations such as this
on the network. Furthermore if this faulty SUN Sparc 2 station was
allowed to remain on the network its clock problem could cause other
subtle, though detrimental, problems on the network such as Inter-Packet
Gap (IPG) time shrinkage.
As it is now, the inability to communicate through a DECMR for nodes
with too slow or fast clocks is isolated to the node with the bad clock.
Changing the repeater design would allow this node to succesfully transmit
packets through the repeater, but would perhaps move the problem to other
nodes, through the loss of packets due to shortened IPGs. This would be
more difficult to detect, and would involve many more stations in the
problem.
The only DECMR enhancement contemplated is to provide for management
notification in the event this situation arises. The signals indicating
fast or slow clock are already present in the gate array. Future
revisions may allow a trap with node identity information, to allow faster
isolation and replacement of faulty adapters.
3
Ethernet clock specs and Lenac repeaters
Note that this will occurr with the DECMR, DETMR, and any future
repeaters implemented using the Lenac repeater gate array.
[END OF REPORT]
4
|
| 536.6 | Similar problems with other machines | GIDDAY::COOPER | | Mon Feb 14 1994 00:58 | 28 |
|
Hi,
I am seeing a similar problem as mentioned previously with large frames
crossing the decrepeater 90c getting jammed. Unfortunately this is
occurring when frames are being sent from a Tandem system or from
Novell NE2000 cards in their PCs. There is a vax that works fine and
some PCs with 3conm cards the work also.
Has anyone seen any problems with this with these ethernet interfaces.
I appreciate the previous notes refer to a problem with SUN machines.
This is a new installation with a DEChub 90 and six DECrepeater 90Cs
replacing a 3com repeater that worked fine. As yet this has not been
paid for and unless I resolve these issues we might have some real
problems.
In the short term i am organising a DEMPR to try and get some of the
PCs to Tandem working as they have an urgent requirement to ftp large
files from the tandem to the Pcs.
Any help much appreciated.
Steve Cooper
Sydney CSC
|
| 536.7 | | KERNEL::LLOYDA | Don't worry... Be Happy ;^) | Wed Feb 16 1994 11:14 | 5 |
| I'm testing a DECrepeater 900TM tomorrow (16th of February) as this
uses a different type of clock checking. I'll let you know tomorrow
afternoon (UK time).
Al.
|
| 536.8 | Had to replace with DEMPRs | GIDDAY::COOPER | | Mon Feb 21 1994 21:48 | 23 |
|
Hi,
I have since installed another DECrepeater 90C from Logistics with the same
result.
It appears the only solution to our problem is to replace all 6 x decrepeater
90Cs with DEMPRs. This is currently being done.
The customer has spoken to Tandem and, of course, they claim that their ethernet
controllers are within specification. It is pretty hard to convince the customer
that the problem is not ours when they were running a 3com repeater without a
problem and we install DEMPRs which work also.
With the problem also visible on the NE2000 PC ethernet cards it is going to be
difficult to sell the DECrepeater 90C into multivendor PC environments with any
confidence.
Some comment from engineering would be appreciated.
Regards,
Steve
|