My original problem:
A 4/65C running 4.0.3c was unable to dump to a remote tape drive on a 3/50,
apparently due to a massive level of dropped packets.
Many people responded and I thank you all. The most comprehensive answer came
from Hal Stern at Sun, and what he said covers what everyone else said.
----- Begin Included Message -----
what you are seeing is evidence of the speed at which the ss-1 can write
packets to the network. it's a *fast* machine with a fast network interface.
the real problem is that the 3/50 can't accept packets coming in that
quickly becuase it runs out of buffers in the ethernet driver -- it's
certainly capable of receiving at sparc speeds, but only if it has the
headroom to handle the traffic.
a few suggestions:
(a) don't hang the exabyte off of the 3/50. you'll kill the 3/50 dumping
from the ss-1. move the drive to the ss-1; under 4.1 it works
"stock" and under 4.0.3 you need the CONSULT-SS1TAPE special,
available through your local sun sales dude or dudette.
(b) check the ethernet input error rate on the 3/50 and see if you're
dropping packets at the local interface. use netstat -i to
check the input error rate; if it's more than 0.025% (yes,
that small) then you should crank up the number of ethernet
receive buffers (see attached note on how to do this)
(c) for file service, this shouldn't be a problem. the 8k buffers you're
getting back from the ss-1 fileserver only comprise 6 IP packets,
so it's kind of hard for the 3/50 to drop any of them (dump is
a completely different story because it's an hour or so of
continuous packet traffic). going from 3/50 to ss-1 is not a
problem because the sparc network interface is able to consume
packets from the wire and pass them up the protocol stack very
quickly.
--hal stern
sun microsystems
northeast area consulting group
The default number of ie ethernet receive buffers provided
in SunOS 4.0.x may be inadequate for some Sun-3 NFS servers
and cause some degradation in server NFS performance.
We suggest that customers who have Sun-3 servers running
SunOS 4.0.x do the following simple check of the ie ethernet
input error rate and and apply the patch below if applicable:
Determine the percentage of ie ethernet input errors
by issuing the command:
netstat -i
and dividing the number of received packets ("Ipkts") by the
number of input errors ("Ierrs"). If this input error rate
is higher than .025% (.00025) you should consider experimenting
with the number of ie receive buffers to see if increasing
the number of receive buffers will decrease this input error
rate.
In SunOS 4.0.x, the ethernet driver parameters are not
generally configurable so you'll have to use 'adb' to modify
the on-disk version of /vmunix and reboot. In SunOS 4.1,
these parameters are in /sys/sunif/ie_conf.c and /sys/sunif/le_conf.c
Make a backup copy of /vmunix before proceeding by:
cp /vmunix /vmunix.old
IE Ethernet Driver Parameters:
Name Default Comment
ie_rbds 10 receive buffer descriptors (tiny)
ie_rfds 9 receive frame descriptors (tiny)
ie_rbufs 25 receive buffers (~1500 bytes each)
Try increasing ie_rbds to 20, ie_rfds to 19, and ie_rbufs to
40 and see if this decreases the ie input error rate. Note:
ie_rfds must always be less than ie_rbds, and ie_rbufs must
always be greater than to ie_rbds.
adb -w -k /vmunix /dev/mem
ie_rbds?W 14 <-- 14 hex is 20 decimal
ie_rfds?W 13 <-- 13 hex is 19 decimal
ie_rbufs?W 28 <-- 28 hex is 40 decimal
<control-D>
Reboot and run this modified /vmunix for a few days to see
if this change decreased the rate of ie ethernet input
errors.
If the new ie ethernet input error rate is not significantly
different from the previous value, the input errors are being
caused by some other problem, probably electrical in nature.
note that in 4.1 systems, there are "high" and "low" values;
the "high" values are used if multiple ethernet interfaces are
present.
----- End Included Message -----
netstat showed no less than 3.5% dropped packets so I tried the adb which
did not work, it said undefined symbol. The real answer is to get the patch
tape and move the tape drive.
Thanks to all
Alastair Young
alastair@eucad.uucp
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:05:58 CDT