From owner-freebsd-hackers  Thu Sep  4 16:27:47 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id QAA29522
          for hackers-outgoing; Thu, 4 Sep 1997 16:27:47 -0700 (PDT)
Received: from awfulhak.demon.co.uk (awfulhak.demon.co.uk [158.152.17.1])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA29517
          for <hackers@FreeBSD.ORG>; Thu, 4 Sep 1997 16:27:37 -0700 (PDT)
Received: from gate.lan.awfulhak.org (localhost [127.0.0.1])
	by awfulhak.demon.co.uk (8.8.5/8.8.5) with ESMTP id XAA26318;
	Thu, 4 Sep 1997 23:56:28 +0100 (BST)
Message-Id: <199709042256.XAA26318@awfulhak.demon.co.uk>
X-Mailer: exmh version 2.0zeta 7/24/97
To: Mike Smith <mike@smith.net.au>
cc: Greg Lehey <grog@lemis.com>, Nate Williams <nate@mt.sri.com>,
        Jaye Mathisen <mrcpu@cdsnet.net>, hackers@FreeBSD.ORG
Subject: Re: Anyway to get connect speed with usermode ppp/tun0 device? 
In-reply-to: Your message of "Thu, 04 Sep 1997 10:21:41 +0930."
             <199709040051.KAA00434@word.smith.net.au> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Thu, 04 Sep 1997 23:56:28 +0100
From: Brian Somers <brian@awfulhak.org>
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

[.....]
> > 1.  The line is flaky, and it's causing errors.
> > 2.  The modem isn't falling back.
> > 3.  LQR is counting those errors and reporting them.
> 
> This is all well and good until you add an error-correcting layer to 
> the equation.
> 
> If 1., then the receiving end will request a retransmission.  If the 
> errors are really bad, then one or both ends will attempt 2.  At any 
> rate, there should be no errors for 3. to detect; the error-correcting 
> protocol is meant to guarantee error-free data transmission.

Ah, but if 1., where the ``line'' means the serial cable between the 
UART & the modem ("It always seems to happen when I switch on the 
radio", or "My ISP had a guy with an electric screwdriver playing 
with their modem rack"), or if we've got sio overflows, or if the other 
side is just sending us crap, *this* is where we see the FCS errors.

The error correction stuff, as you say, will hide this from the LQR 
and application levels.

Interrestingly enough, I guess a modem that "falls forward" 
(increases its data rate) may force sio overflows by essentially 
catching up with the DTR speed (if DTR is set pretty low).

> > > and might be related to the other hanging things up.
> > 
> > I don't understand what you're saying here.
> 
> I'm not sure either; the most common cause of FCS errors on modern PPP 
> links is flow control problems; it's possible that the terminal server 
> you were connected to just dropped its guts, or the modem likewise.

Cosmic rays are common too :-)

> mike
> 
> 

-- 
Brian <brian@awfulhak.org>, <brian@freebsd.org>
      <http://www.awfulhak.org>
Don't _EVER_ lose your sense of humour....