From: muench-philip@math.yale.edu (Philip Muench)
Newsgroups: comp.dcom.lans.ethernet,comp.sys.sun.admin,comp.sys.sun.hardware
Subject: Re: slooow network access on *some* suns in a UTP net
Date: 23 Jan 1993 17:08:04 -0500
Organization: Yale University Mathematics Dept., New Haven, CT 06520-2155
Distribution: world,local
NNTP-Posting-Host: cantor.math.yale.edu

In article <1993Jan13.150408.4243@arizona.edu> Leonard@Arizona.EDU writes:
>In article <3583@ncr-mpd.FtCollinsCO.NCR.COM>, Karen Allen@FtCollins.NCR.COM writes
>(with carriage returns added by yours truly): 
>
>| Background:
>| We've just moved from a thicknet network to a 10BaseT net. We've purchased Allied 
>| Telesis UTP transceivers, CentreCOM 210T. Alot of our suns use a common Openwindow 
>| area on our server, a SS10/510. 
>| 
>| Problem:
>| In our "old" network, the OW server was a sparc2, it took most users 30-40 seconds to 
>| bring up OW off that server. In our new UTP environment, with the SS10 server, it takes 
>| *some* systems 3-4 minutes to bring up OW. Note: not ALL sun OW clients take this long, 
>| some OW sessions come up in the 30-40 second timeframe.
>| 
>| Our network traffic and the load on the SS10 is light, so I'm thinking it has something to do 
>| w/ SQE on the transceiver. We have it disabled on all the tranceivers. We tried enabling it 
>| on a transceiver off a client that is slow, it didn't make any difference. I'm wondering if 
>| heartbeat on the SS10 is enabled .. we are coming right out of the UTP port on that guy, 
>| no transceiver involved there. 
>
>Fiddling with SQE shouldn't help you any here.  SQE *must* be off on all transceivers
>to which 802.3 repeaters, such as your 10baseT hub, connect.  SQE *should* be on on
>all transceivers to which DTEs, such as stations and bridges, connect, although having
>SQE off on such transceivers shouldn't hurt performance.
>| 
>| Any suggestions ? Have other folks run into this ? 
>
>We've seen this kind of problem frequently in our 10baseT installations.  It has 
>usually been due to cabling problems: excessive dB loss on the UTP runs, shoddy
>punchdowns, poorly constructed patch cables, bent jack pins, etc.
>
>Our standard is now to verify our 10baseT installations with the following tests:
>1. A physical layer test of each port, using a MicroTest PairScanner.  We check
>cable length, dB loss, near-end crosstalk, etc., to verify that the cable path 
>meets 10baseT requirements.  If it doesn't, we re-work the line.
>2. Then, a network-layer test.  Our standard test is to send 1000 1500-byte
>ICMP echoes (PINGs) to the remote station and verify that no more than 0.4%
>of packets are lost.  (An even better test, if you have a PING client that can
>generate it, such as a Cisco router, is to issue 8192-byte PINGs - we require
>that no more than 1% of such packets [actually, 6-frame packet trains] be lost.)
>| 
>| Thanks for any help !!
>| 
>| K
>|
>| Karen Allen              email: Karen.Allen@FtCollinsCO.NCR.COM
>| NCR Microelectronics     Phone: (303) 225-4828
>
>Hope this helps,
>
>Aaron
>
>Aaron Leonard (AL104), <Leonard@Arizona.EDU>
>University of Arizona Network Operations, Tucson AZ 85721
   The network can be slowed greatly by even one device that talks out 
of turn because it does not know the rules or can not hear other devices
and be polite.
   Even if wires, end devices, and external transceivers are within
specifications, you will have troubles if your hubs, which are
multiport repeaters with internal transceivers, are not within
specifications. By the time a signal has hopped through a 
hub it may have been distorted to the point where the next
device to receive it does not recognize it as a valid signal.
It is possible that the recipient addressed in a packet receives
a corrupt packet much of the time, and the sender, not knowing
that the packet has, in effect, been lost, must wait for its
acknowledgment timeout interval to elapse before the sender
will retry.
   Also, if a repeater fails to repeat a signal to all other ports or
fails to detect a collision and propagate a jam signal to all
ports, a talker may receive no indication that a packet has been
lost. A similar problem arises if the propagation delay between
two points on the net exceeds the maximum allowed.
A properly functioning network depends on every end
device being able to hear every other one and obeying the rule
of not starting to talk until silence occurs, and on the propagation
delay being short enough compared to the minimum packet duration
that even if two talkers start to talk
within a short time, because the second one does not realize the
first one's packet is on the way, the first talker will still be
talking when the second talker's packet arrives (or a jam signal
propagated by a repeater arrives), and the first
talker will realize his packet has collided. This is a normal
collision, and produces runt packets (shorter than minimum normal
packet) when the talkers truncate their packets. A normal collision
does not cause long delays, because all talkers realize their packets
have collided; they will retry sending their packets soon, but not
all at once. Late collisions, produced when a second talker does
not realize the first talker has already been talking a while or
when the second talker just does not obey the rules, can cause
very long delays, because the first talker may have finished talking
by the time second talker's packet arrives; in the first talker's
neighborhood, there is no collision and the first talker does
not realize that a collision has occurred elsewhere.
The first talker's intended recipient(s) probably receive a 
corrupt packet longer than a runt,
but because the packet is detected as corrupt when it fails a
cyclic redundacy check (CRC), it is discarded. Late collisions
typically show up in error counts as CRC errors, frame alignment
errors (packet length not a whole number of bytes), or both.
The first talker waits for its acknowledgment interval to elapse
before it retries sending the packet.
   Any time you have more than a few percent network utilization
and talkers not hearing each others signals well, you can expect
packet loss in late collisions. 
   Since the source address field is
near the beginning of a packet, only the first talker's address
can be read by a network analyzer; the late talker's address is 
buried in the overlap of the packets. You may want to collect
error statistics from your hubs's management agents and sift out
the worst numbers to locate the guilty elements; only the hub
(and the end device itself) can tell that a end device is talking without
having to recognize the device by its address.
   You may prefer to or 
have to turn off parts of the network to see which one seems to
be causing trouble for the others. One of the advantages of
10BASE-T is the ease with which small or large parts of the network
can be disconnected and reconnected, sometimes by remote control.
   Turning off parts of your
network for more than 10 seconds at a time is risky if you
have time-critical protocols like local-area VAX cluster
connections (LAVC). 
   Turning off parts of your network for any
perceptible time is risky if you have protocols like Local Area
Transport (LAT) that do not expect packets to be lost and will 
abort a session if an acknowledgment is lost under some circumstances.
But since you have a packet loss problem, the users probably are
having their sessions aborted even without your intervention.
   If the management agent in a hub communicates on the network,
the agent itself could be one of the guilty devices, and it
might not even keep error statistics on itself, since it is
not an external port of the hub.
-Philip Muench
 muench@cantor.math.yale.edu 128.36.23.26
Newsgroups: comp.dcom.lans.ethernet