Are Ethernet frame errors due to hardware or software?

I have an SMC NIC using epic100 module in a 2.4.25 kernel. It connects to
both a NetWare server (IPX) and to Windows computers (TCP/IP) via a 24 port
Dell (100) switch. The epic100 module also causes mii and crc32 modules to
load (but I don't know anything at all about these).

I am getting what I'd call a lot of frame errors when I run 'ifconfig
eth0' and I do not know if the problem lies in hardware or in software.

Here is the ifconfig output:
eth0 Link encap:Ethernet HWaddr 00:E0:29:07:356
inet addr:192.168.1.1 Bcast:192.168.1.255 Mask:255.255.255.0
IPX/Ethernet 802.2 addr:000000E1:00E0290735D6
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:416496004 errors:0 dropped:0 overruns:0 frame:20959
TX packets:417831834 errors:0 dropped:0 overruns:8 carrier:0
collisions:0 txqueuelen:1000
RX bytes:1497261187 (1427.8 Mb) TX bytes:3327349473 (3173.2 Mb)
Interrupt:10 Base address:0xd000

I have searched groups.google.com NG comp.os.linux.networking and found no
answer. Are frame errors due to problems with hardware or with software?

Do you have any suggestions as to what might be causing my frame errors?

TIA,
buck

buck <(E-Mail Removed)> said:
>I have an SMC NIC using epic100 module in a 2.4.25 kernel. It connects to
>both a NetWare server (IPX) and to Windows computers (TCP/IP) via a 24 port
>Dell (100) switch. The epic100 module also causes mii and crc32 modules to
>load (but I don't know anything at all about these).
>
>I am getting what I'd call a lot of frame errors when I run 'ifconfig
>eth0' and I do not know if the problem lies in hardware or in software.

Hardware; something at very low level causes bad frames to exist on your
network. Bad frames would be things like packets with incorrect length
(over or under the specification limits), or bad frame checksums. Could
even be an intermittent cable causing packet corruption on the wire.

>Here is the ifconfig output:
>eth0 Link encap:Ethernet HWaddr 00:E0:29:07:356
> inet addr:192.168.1.1 Bcast:192.168.1.255 Mask:255.255.255.0
> IPX/Ethernet 802.2 addr:000000E1:00E0290735D6
> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> RX packets:416496004 errors:0 dropped:0 overruns:0 frame:20959

.... note though, that with your packet counts, the error rate is around
0.005% (or, one bad packet out of 20000) -- so, a very small one; I
wouldn't expect you to be able to measure the (end-user) performance
effects of this.
--
Wolf a.k.a. Juha Laiho Espoo, Finland
(GC 3.0) GIT d- s+: a C++ ULSH++++$ P++@ L+++ E- W+$@ N++ !K w !O !M V
PS(+) PE Y+ PGP(+) t- 5 !X R !tv b+ !DI D G e+ h---- r+++ y++++
"...cancel my subscription to the resurrection!" (Jim Morrison)

buck <(E-Mail Removed)> wrote in message news:<Xns951A7FE8AC08Bbuckprivatemil@63.223.5.246> ...
> I have an SMC NIC using epic100 module in a 2.4.25 kernel. It connects to
> both a NetWare server (IPX) and to Windows computers (TCP/IP) via a 24 port
> Dell (100) switch. ...

> I am getting what I'd call a lot of frame errors when I run 'ifconfig
> eth0' and I do not know if the problem lies in hardware or in software.
> RX packets:416496004 errors:0 dropped:0 overruns:0 frame:20959

> Do you have any suggestions as to what might be causing my frame errors?

It does seem a bit high, depending over what period that is! But it
is probably not causing you any real problems, even so.

The main cause of framing errors in the days of co-ax networks was
collisions, which were prefectly normal. But you say you are using a
switch, so that should be routing the traffic without collisions.
My first thought would be to look at the cabling to the switch.

If it's not that, then dump the switch and use a cross-over cable to
each of the other machines in turn and run some traffic. I'm sure it
will be fine. if so, it might suggest that the switch is not coping
perfectly.

But, as I say, it's livable with, isn't it?

(E-Mail Removed) (Robert E A Harvey) wrote in
news:(E-Mail Removed) om:

Thanks, Robert and Juha!

I now have a preliminary plan:
Run a _new_ patch cord from the switch to the _other_ NIC (3c905b).
Swap the patch cord from the 3Com to the SMC.
Restart the network so eth0 is still the internal interface.
Test.

If the frame errors stay with the SMC then it is the Bad Boy.
If not, then (assuming a good new patch cord <shrug>) replace the switch.
If still No Joy, I'll unplug users until I find who is sending the bad
frames.

Are there any holes in that logic (my mother taught me to ask <g>)?

And yes, I do notice slowness. That is what prompted me to check things
out...

buck

Are you using any application that might use clamp-mss? Just a thought.

raqueeb hassan
bangladesh