svilst@hotmail.com (svilen) wrote in message news:<f6b84cfe.0404301223.6002ff74@posting.google. com>...
> Thank you for the suggested ways to explore the problem.
> I hope the diagnostic output is not too copious.
>
> I'm using Slackware 9.0 - 2.4.20
[snip]

dmesg, etc. indicates everything OK -- the network stats, however ...

Looking over the outputs you posted, I'm inclined to think you've got
a hardware problem -- perhaps one that only shows up when pushing the
nics in this 486 to 100Mb.

It could be a marginal cable, a "worn" jack at either end, a bad port
on a hub/switch (if you're using one), or a questionable nic at the
far end of the connection. It might even be something subtle enough
that it would be very hard to isolate.

BTW, some of these "early" 486/PCI mobos could be a little flakey and
it usually shows up in nics and video cards. I would probably learn
to live with reliable 10Mb rather than working too hard to get 100Mb.

So the bottom line is how much time you're willing to invest sorting
out the possible causes. If it was me I would probably work on it in
my spare, nothing-better-to-do moments after going through the basics
of switching patch cords, ports, and checking performance of the far
end nic.

Re: your output and questions ...

--- ifconfig eth1 ---
....
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:1792 errors:530 dropped:0 overruns:0 frame:530
TX packets:2336 errors:5 dropped:0 overruns:0 carrier:5
collisions:0 txqueuelen:100

The RX line shows packet count and errors (total and catergorized)
recorded by the nic on its receiving circuit -- here 530 frames had
errors.

Frames are the "packets" used to send ethernet signals/data on the
wire. The error checking code (FCS/CRC) included in the frames
(calculated by the sending device) did not match what this nic's
receiving unit calculated using the same routines. These frames
(packets) are dropped immediately to guard against baaaad side
effects. These are caused by what is termed "noise" (a.k.a.
interference in laymen's terms). Could be caused by faulty hardware
circuits, cables not properly shielding the signal, or excessive EMI
(electromagnetic interference) emissions from another piece of
equipment in or near the nics/cable. Your error rate is nearly 30% --
IIRC, anything above ~0.3% is considered unaccepatble. This is a
serious hardware problem!

The TX line shows similar info for the transmitting circuit. 5 times
the nic had data to transmit but found no proper "carrier" signal on
the wire -- a carrier signal is needed to "carry" (cute, huh?) the
nic's data signal on the wire. This ain't good either. My experience
is that any carrier errors are "serious" unless you know their cause
beforehand.

TCP "acknowledges" the packets it receives so the sender knows they
arrived OK. DelayedAcks are acknowledgements of received packets that
are not getting back to the sender in a timely manner. In and of
themselves, they don't tell us much except that you've got a large
number of them -- some apps are known to generate quite a few. For
the details you can look at:
http://www.faqs.org/rfcs/rfc3465.html

The netstat output shows just how robust TCP is in the face of errors.
It slows things down (reduced throughput) but it keeps trying to get
the packets it "knows" should be arriving. And gets them.

hth,
prg
email above disabled