[TAG] Meaning of overruns & frame in ifconfig output

[Francis Daly]

On Fri, Apr 07, 2006 at 09:35:44AM +0200, Ramon van Alteren wrote:
> On 7 Apr , 2006, at 2:38 AM, Francis Daly wrote:
> >On Thu, Apr 06, 2006 at 10:41:50PM +0200, Ramon van Alteren wrote:

Hi there,

> >>Out of pure interest would anyone know the exact definition (or  
> >>provide
> >>me with pointers to said definition) of the fields overrun and  
> >>frame in
> >>the output of ifconfig.
> >
> >The source code might :-)
> 
> Kept that as a last resort, my C coding & reading skills is at best  
> rusty and at worst non-existant.

As backup for the "random file on the web" info,
/usr/include/linux/netdevice.h on my 2.4-series machine includes in the
definition of "struct net_device_stats", in the "detailed rx_errors:"
section 
        
  unsigned long   rx_frame_errors;        /* recv'd frame alignment error */
  unsigned long   rx_fifo_errors;         /* recv'r fifo overrun          */

which seems consistent with that information.  (Similar entries appear
in a few other headers there too.)

And egrep'ing some nic drivers for "rx_frame_errors|rx_fifo_errors"
reveals notes like "Packet too long" for frame and "Alignment error"
for fifo.

So if it's wrong, it appears consistently wrong.

> >I hope the above isn't useless.
> 
> Certainly not, at the very least it will serve to enlight my soul  
> with knowledge,
> which is a good thing (tm)
> FYI: It took me awhile to pinpoint this bottle-neck, most answers  
> google turned up pointed to badly configured or malfunctioning  
> hardware and or pci-busmaster stuff.
> 
> This is a well-configured Intel 100Mbit NIC with busmastering enabled  
> which is apparently flooded with http-traffic to the point that it  
> can not generate interrupts fast enough to get the frames out of it's  
> buffer. That's the first time I've ever seen that.

As to the cause of the errors -- fifo overrun, once the nic is
configured and negotiated right, might just mean "you have a (seriously)
large amount of traffic on that interface".  Presumably you've already
considered what devices might be generating that traffic, and isolating
things on their own network segment.  An alternative is that the machine
itself is too busy to process the interrupts and data, but you would
likely have spotted that sooner.

frame alignment, on the other hand (again, presuming that it isn't just
an artifact of a nearly-full buffer) suggests that some other device is
generating a dubious frame.  Any consistent pattern in source MAC or IP
which can be used to point the finger?

Good luck with it,

	f
-- 
Francis Daly        francis at daoine.org