[ale] RX-OVR on SLIP connections

[Omar Loggiodice]

Jeff Barber Writes :
:
:Hi folks,
:
:I use C-SLIP to connect to the office from home and have noticed that
:netstat -i always claims to have almost as many RX-OVRs (receiver
:overruns) as RX-OKs.  I recently installed a 16550 COM port (this
:seemed to have no effect on the problem) and have a reasonably fast
:box (486-66) with a decent amount of RAM (16M).  Has anyone else seen
:this behavior?
:

Hi Jeff, 
   You probably got an answer for this already, but here it goes anyway.

   The reason why you are observing as many RX-OVRs as RX-OKs in your
C-SLIP connection is because RX-OVR, IN THE CASE OF C-SLIP connections; 
is NOT representing buffer overruns, but rather the number of SLIP frames
that were COMPRESSED. This information is current as of Kernel 1.3.71 and
net-tools-1.3.6-BETA4.(BTW, the same is true for TX-OVRs)

   In other words, your connection is in good shape because the 
frames are being compressed. 

WHY?

  The NETSTAT program is displaying the rx_fifo_errors member of the "C"
struct enet_statistics, as opposed to the rx_over_errors member. My
assumption is that early during the development of netstat rx_fifo_errors
was used to report overrun errors, but when C-SLIP was developed the proper
member (rx_over_errors) was used in the slip driver at the kernel level; and
since there was no place to report statistics about the number of compressed
frames, rx_fifo_errors was chosen to hold this data (this is done by the
C-SLIP driver in /usr/src/linux/drivers/net/slip.c), but netstat was never
changed.

Yes, I would consider this a bug in netstat. It should inform the user that
this is not the number of buffer overruns, but rather the number of compressed
frames. (Actually it should add a column title called something like
RX-COMPR for compressed connections).

:I don't see any obvious effects from it -- i.e. broken connections, 
:timeouts, delays, etc. -- though it's hard to tell whether the
:performance is as good as it should be (28.8 always seems s l o w
:after using Ethernet all day at the office).  I do know that large
:scale FTP downloads don't seem to get better than 2K or so per second,
:which seems slow for a 28.8 modem, but again I don't have any easy way
:to diagnose what's going on.  Any ideas?
:
:
Hi Jeff, 

   You probably got an answer for this already, but here it goes anyway. 
   The behaviour you are observing is perfectly normal, but it is not
documented on man pages or other sources (that I know of). 
:-- Jeff (an ALE newbie)
:


-- 
____________________________________________________________________
            /   __  __  __  - __  __ / - _  __  ologgio at vrainn.com
  Omar R.  /__ /_/ /_/ /_/ / /_/ /_/ / /_  /-_  CIS: 74040,1543
                  __/ __/                         
___C++/6_yrs____Virtual Reality/4_yrs____Vorl_____Linux(free)_______
Apple ]['s, remember Applesoft?