Re: Ethernet card receiving influenced by CPU speed?

From: P Gentry (rdgentry1_at_cablelynx.com)
Date: 05/02/04 

Date: 1 May 2004 19:36:40 -0700

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

Relevant Pages

  • Re: [Security, resend] Instant crash with rtl8169 and large packets
    ... network switch can handle jumbo frames). ... and apparently NIC happily delivers packets with larger sizes, ... machines too. ... issue with these NICs -- the famous, ...
    (Linux-Kernel)
  • Re: [Security, resend] Instant crash with rtl8169 and large packets
    ... network switch can handle jumbo frames). ... doing the ping test with the above change (no more large packets were ... When this driver queues a skb in rx queue, it tells NIC the max size ... issue with these NICs -- the famous, ...
    (Linux-Kernel)
  • Re: NDIS IM driver Packet drop (Broadcom NIC)
    ... I wrote an IM filter driver that just count the number of packets hit ... Directed Frames Rx 9999999 ... I am using 4 proc machine with 2 onboard Broadcom NICs. ...
    (microsoft.public.development.device.drivers)
  • NDIS IM driver Packet drop (Broadcom NIC)
    ... When i send these packets to one NIC then it work fine. ... Directed Frames Rx 9999999 ... I am using 4 proc machine with 2 onboard Broadcom NICs. ...
    (microsoft.public.development.device.drivers)
  • Re: [RFC v1] hand off skb list to other cpu to submit to upper layer
    ... I am investigating an ip_forward performance issue with 10G IXGBE NIC. ... The 2nd receives the packets from one NIC and forwards them out ... As NICs supports multi-queue, I bind the queues to different logical ... cpu of different physical cpu while considering cache sharing carefully. ...
    (Linux-Kernel)