[TAG] Meaning of overruns & frame in ifconfig output

Ramon van Alteren ramon at vanalteren.nl
Fri Apr 7 11:35:44 MSD 2006


I'm on-list but thanx for CC-ing anyway ;-)

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.

>
> But there's a 450 kB 45-page pdf at both
> <URL: http://www.utica.edu/academic/institutes/ecii/publications/ 
> articles/
> A0472DF7-ADC9-7FDE-C80B5E5B306A85C4.pdf >
> and <URL: http://www.computer-tutorials.org/ebooks/ 
> 02_summer_art1.pdf >
>
> with the heading
>
> International Journal of Digital Evidence
> Summer 2002, Volume 1, Issue 2
>
> "Error, Uncertainty, and Loss in Digital Evidence"
> Eoghan Casey, MA
>
> which includes on p29
>
> """
> One manufacturer provides the following information about interface  
> errors,
> including datagrams lost due to receiver overruns a.k.a.  FIFO  
> overruns (NX Networks,
> 1997).
>     ?  packet too long or failed, frame too long: "The interface  
> received
>     a packet that is larger than the maximum size of 1518 bytes for an
>     Ethernet frame."
>     ?  CRC error or failed, FCS (Frame Check Sequence) error: "The
>     interface received a packet with a CRC error."
>     ?  Framing error or failed, alignment error: "The interface  
> received
>     a packet whose length in bits is not a multiple of eight."
>     ?  FIFO Overrun: "The Ethernet chipset is unable to store bytes in
>     the local packet buffer as fast as they come off the wire."
>     ?  Collision in packet: "Increments when a packet collides as the
>     interface attempts to receive a packet, but the local packet  
> buffer
>     is full.  This error indicates that the network has more  
> traffic than
>     the interface can handle."
>     ?  Buffer full warnings: "Increments each time the local packet
>     buffer is full."
>     ?  Packet misses: "The interface attempted to receive a packet,
>     but the local packet buffer is full.  This error indicates that  
> the
>     network has more traffic than the interface can handle."
> """

Mmm interesting link, more reading material for the stack ;-)
Thanks

>
> This is friend-of-a-friend third hand stuff by now, of course, but it
> certainly sounds reasonable to me, and might give you pointers to some
> more terms to search for to find something demonstrably authoritative.
>
>> I've been searching google for an answer, but that mostly turns up  
>> false
>> positives from all the people over the years that have posted their
>> ifconfig output on the internet.
>
> For what it's worth,
>
> /proc/net/dev packet framing error overrun
>
> was what I was what I (eventually) asked Google for, before asking for
>
> "NX Networks" ifconfig
>
> which found the two links.
>
>> I'm seeing these (overrun & frame errors) on a NIC in a load-balancer
>> which services just the incoming http-requests (outgoing uses direct
>> routing) and I'm buying new ones tomorrow. I am however still curious
>> what these values actually mean.
>
> 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.


Grtz Ramon

--
In the beginning, there was nothing. And God said, 'Let there be Light.'
And there was still nothing, but you could see a bit better.








More information about the TAG mailing list