Hello all,
I got five replies. Thanks for those.
First the original query (in essence):
I have two networks bridged by a SUN sparc 2. When talking from one net to the
other from a Sparc 10, about 25% of packets are lost. This only occurs with the
Sparc 10. All other systems are OK. Other systems include IPX ELC and IPCs.
Also the Sparc 10 could talk without problems to all the other systems on its
subnet, but not well to anything on other subnets.
The statistics were gathered using ping -s (i.e. 1 packet per second on a
fairly quiet network). 25% of these went missing. What could have been causing
this?
I said that the Sparc 2 had Patch 100768-01 installed, but didn't think it was
relevant since it didn't have an effect until collisions were above 10% and
collisions were only about 3-5% on either of the networks.
I also mentioned in my original post that the Sparc 2 was connected to one
of the networks (the one with the Sparc 10) with a twisted pair hub and posited
that this was failing to keep up with the Sparc 10 data rate.
In fact this was the case. Having swapped out the hub, packets were no longer
lost.
Now the replies:
"Fuat C. Baran" <fuat@watsun.cc.columbia.edu>
asked if I had applied the above patch. As I said, I didn't think it would have
helped, though at one stage I was going to install it.
emcgon@compapp.dcu.ie (Eamonn McGonigle)
asked what I was using to find out how the packets were getting lost. You would
expect a degree of packet loss from spray (I tried that and got between 54 and
68% loss with spray). It was ping.
He suggested this as a debugging strategy:
>As regards a debugging strategy, I tend to work up the "OSI layers". Check
>the topology and termination of all your cables (a cable tracing gizmo is
>absolutely invaluable, but a multimeter and a good oscilloscope will do at a
>pinch). A faulty tranceiver is another possibility. If your sure the
>physical end of things is OK, start checking for "strange" ARP packets etc.
>It might be also worth checking routing tables & network masks.
I would add that a network sniffer is an invaluable tool for tracking down
hardware and MAC level problems. Unfortunately we don't have one of our own.
glenn@uniq.com.au (Glenn Satchell - Uniq Professional Services)
wrote:
>Just seems like the sparc 10 is putting out packets too quickly for the
>sparc 2 to accept them. I would think you will see similar statistics if
>you use the spray(8) command. This is to be expected as the ss10 is
>much faster than the ss2, however it is not a problem as such, since the
>network protocols automatically resend any dropped packets. The moral
>of the story is, that unless the collision rate is very high on this
>subnet and there are other machines being flooded with packets then
>don't worry too much about it.
This isn't quite right. If the Sparc 2 was unable to handle the the packets
from the Sparc 10, neither would the IPX's or IPC's etc, which could. If it was
a traffic problem, then the problem should have shown up as collisions, but it
didn't. It is very rare in normal circumstances to lose packets (unless you
are using spray) as opposed to getting collisions especially when the packets
are at a rate of 1 per second as in ping -s. It certainly was worth worrying
about this behaviour because it was making the Sparc 10 very slow for normal
work. In fact so slow, that people couldn't use it with out causing it physical
damage !! :-)
scb%electron.var.com%helios@uunet.UU.NET (Steve Brown)
wrote:
>What ethernet card are you using? The standard Sun ethernet card can't be used
>on an 4m based Sparcstation because it depends on a hardware latency that's
>present on 4c products, but not in multiprocessor products. You didn't mention
>what make or model the ethernet card was, but as far as I know the only
>ethernet expansion cards that can be used on 4m products are the FSBE and SSBE
>SCSI/Buffered Ethernet cards.
It was the standard builtin interface on the Sparc 10 and the card on the
Sparc 2 was the SUN's SCSI Ether card (SSBE) (guaranteed to work in both Sparc
2 and Sparc 10 since we asked them specially!!)
Anyway, thanks for all the replies.
Tom.
-------------------------------------------------------------------------------
Tom Crummey, EMAIL: tom@sees.bangor.ac.uk | /\
University of Wales, Bangor, | / \/\
School of Electronic Engineering Science, | /\/ \ \
Dean Street, Bangor, TEL: +44 (0)248 382806 | / ======\=\
Gwynedd, LL57 1UT, U.K. FAX: +44 (0)248 361429 | B A N G O R
-------------------------------------------------------------------------------
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:08:07 CDT