I use a NetBSD 1.4.2 host as the target for backup from a SCO host.
The SCO host has a 10/100 Intel PRO+ or similar ethernet adapter
(built into the motherboard) and the NetBSD host (one of two similarly
configured machines) has a 3Com 905B-TX adapter.

Originally, the NetBSD target ran 1.4 and did not support the 3Com,
so I had it installed with a different adapter on the 10MHz segment
of our network, which is linked to the 100MHz segment by a switch.
The 100MHz segment is shared by most of the servers and a handful
of reserved workstations, whereas the rest of the organisation
(around a hundred, mostly Windows-based workstations) are on various
switched 10MHz segments.  It is all one large subnet.

I upgraded in the last few days and, after some tests on the 10MHz
segment, put the fresh server on the 100MHz segment.  Unfortunately, I
didn't notice at first that the actual network transfer was happening
very slowly.  When I tried it over the 100Mhz link, however, it got
even worse.  It was probably already slow previously, seeing as part
of the reason for upgrading was to improve throughput by upgrading to
100MHz ethernet.  But under the new conditions throughput dropped
incredibly.  It didn't feel bad at the interactive level, but it was
dysmal on file transfers: for example, the 2MB SCO Unix kernel took 24
seconds (21 to the other, similar, NetBSD server).  Between NetBSD
boxes, the same transfer did not register in the seconds field.

At first (in other words, until I thought of it again), I thought the
cure would lie with smoothing out some wrinkles in the SCO networking
(which is still an option, as they confess to some issues with the
Intel interface), but it dawned on me that the behaviour changed when
I migrated from 1.4 to 1.4.2 and I wonder what networking changes in 
NetBSD would have such a dramatic effect.

I now have the NetBSD box back on the 10MHz segment, but file
transfers are still abysmally slow, although the 24 seconds above have
been reduced to 14.

Any suggestions on tweaking NetBSD to be more like its previous self
(however wrong) will save me from making adjustments to SCO Unix.  The
SCO Unix installation is not very tidy (too many things thrown
together in a hurry by an apprentice :-) and I must confess that
having access to the sources of NetBSD has spoilt me for dealing with
source-obscured operating systems.  In other words, I have a high
level of prejudice to stop me from wanting to accept responsibilities
for things that may go wrong with the SCO server.

Thanks a lot to everyone.

++L