From: jfu2@quads.uchicago.edu (Carlo Graziani)
Newsgroups: comp.sys.sun.misc
Subject: Sparc1 + SunOS 4.1.2 + Thin ethernet = problem ?
Date: 13 Apr 92 17:47:31 GMT
Reply-To: jfu2@midway.uchicago.edu
Organization: University of Chicago Computing Organizations

Hi.  Like the subject line says, we have a thin etehrnet local network
of Sparc Station 1's running SunOS 4.1.2.  Shortly after we upgraded
to 4.1.2 we noticed a problem doing backups to a remote
tape drive over the network using "dump".  The backups would take much
longer than expected, and sometimes the machines would hang up altogether.
A sunview performance meter monitoring ethernet packets showed that rather
than a steady stream of packets, there would be a short peak (perhaps 10
seconds wide) followed by zero activity for times ranging up to a minute
or so.  During these "dead times" there would be no cpu or disk activity
either.  This phenomenon was observed on each of our Sparc1's.

We performed a number of experiments, and ruled out a number of possible
causes:

1)  We dumped to /dev/null on the remote machine, to see if the problem
was with the tape drive.  The problem persisted, so the tape drive is not
the problem.

2)  We dumped to /dev/null on the local machine, so that there was no
network activity involved.  This was in order to test whether the problem
was something other than the network (e.g. the disk or the cpu).  The
problem disappeared --- that is, there were no "dead time" phenomena
observed using performance meters monitoring disk and cpu activity.  The
meters just pegged, cruised along, and did not slow down until the end
of the dump.

3)  We attempted the same dump command on a Sparcstation 2 running 4.1.2
on the same network as our other machines.  There was no evidence of the 
problem.  It appears to be a feature of the Sparc1 architecture running
4.1.2.

4)  We replaced the transceiver cables and transceiver boxes.  No change.

5)  Our friendly Sun hardware maintenance contractors came out and swapped
the cpu board on one of the machines.  Didn't make a lick of difference.

6)  We created a "mini-network," consisting of two Sparc Station 1's
running 4.1.2, each with it's own disk and system files, connected by
about 7 feet of thin etehernet cable.  The purpose was to see whether
somehow our network was too long, or the cable somehow "kinked", or
some other network problem existed, and that was responsible for the
problem.  The problem was still present using the "mini-network".  Thus
our network is not responsible.

7)  We tried the command using a Sparc Station 1 running 4.1.2 attached
to a THICK ethernet network.  This time the performance, as measured
using the packet meter, was considerably better.  It was still not
optimal, but while ragged, it never hung for an appreciable amount of
time.  Rather, it would peak-fall-peak-fall-etc, never spending more
than a fraction of a second at zero (i.e. virtually no dead time).  Of
course, optimal (or even expected) performance would be
peak-cruise-fall-at-end-of-dump, so something is still not quite
right.

8)  We loaded SunOS 4.0.3.  The problem disappeared.  The ethernet
performance meter peaked-cruised-fell-at-end-of-dump.  We noticed that
the scale of the maximum packet rate was about half what it had been
under 4.1.2 --- during the dump under 4.1.2, the packet meter had full
scale set to 512 packets/sec, while during the dump under 4.0.3 it
had full scale set at 256 packets/sec.  The dump terminated in a fraction
of the time it took under 4.1.2, as a consequence of the more sustained
throughput.

9)  We re-loaded 4.1.2, but ran the dump using the dump program from 4.0.3,
which is somewhat different from the version provided with 4.1.2.  This was
to test whether the problem was with the dump program itself.  The problem
re-appeared.  We observed the "dead time" effect again.  Now the ethernet
packet meter had full scale set to 512 packets/sec.  The problem is not
the dump program.

Our conclusions:

SunOS 4.1.2 was probably not designed with the Sparc Station 1 architecture
in mind.  As a result, the kernel tries to jam ethernet packets down the
network at a rate that saturates the networking hardware (by which I mean
the Sparc station's internal ethernet hardware and the network cable system,
collectively).  The performance is marginally acceptable if the network is
thick ethernet rather than thin ethernet.

Questions:  Has anyone else had these problems?  If so, does Sun know about
it?  If so, does there exist a patch for it?

Carlo Graziani
Dept. of Physics
University of Chicago
carlo@nu.uchicago.edu