From owner-freebsd-hackers Thu Sep 4 16:53:34 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA01853 for hackers-outgoing; Thu, 4 Sep 1997 16:53:34 -0700 (PDT) Received: from nico.telstra.net (nico.telstra.net [139.130.204.16]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id QAA01841 for ; Thu, 4 Sep 1997 16:53:30 -0700 (PDT) Received: from freebie.lemis.com (gregl1.lnk.telstra.net [139.130.136.133]) by nico.telstra.net (8.6.10/8.6.10) with ESMTP id JAA17081; Fri, 5 Sep 1997 09:49:56 +1000 Received: (grog@localhost) by freebie.lemis.com (8.8.7/8.6.12) id JAA27871; Fri, 5 Sep 1997 09:19:55 +0930 (CST) Message-ID: <19970905091954.07644@lemis.com> Date: Fri, 5 Sep 1997 09:19:54 +0930 From: Greg Lehey To: Brian Somers Cc: Mike Smith , Nate Williams , Jaye Mathisen , hackers@FreeBSD.ORG Subject: Re: Anyway to get connect speed with usermode ppp/tun0 device? References: <199709040051.KAA00434@word.smith.net.au> <199709042256.XAA26318@awfulhak.demon.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.81e In-Reply-To: <199709042256.XAA26318@awfulhak.demon.co.uk>; from Brian Somers on Thu, Sep 04, 1997 at 11:56:28PM +0100 Organisation: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8250 Fax: +61-8-8388-8250 Mobile: +61-41-739-7062 WWW-Home-Page: http://www.lemis.com/~grog Fight-Spam-Now: http://www.cauce.org Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Thu, Sep 04, 1997 at 11:56:28PM +0100, Brian Somers wrote: > [.....] >>> 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. That's reasonable, at least in theory. I don't think it applies to the case I was reporting, since the only thing I changed was the dialup connection. It also means that it wasn't in the local loop. > The error correction stuff, as you say, will hide this from the LQR > and application levels. If it's working. I think it was here, but there's only so much that the error correction stuff can handle. > 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). Flow control should take care of that. You should be able to run the modem link to a V.34 modem at 9600 bps if you want. >>>> 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 :-) No, they did away with those to improve the reliability of 64 kb RAMs. Greg