Date: Fri, 5 Sep 1997 09:19:54 +0930 From: Greg Lehey <grog@lemis.com> To: Brian Somers <brian@awfulhak.org> Cc: Mike Smith <mike@smith.net.au>, 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? Message-ID: <19970905091954.07644@lemis.com> In-Reply-To: <199709042256.XAA26318@awfulhak.demon.co.uk>; from Brian Somers on Thu, Sep 04, 1997 at 11:56:28PM %2B0100 References: <199709040051.KAA00434@word.smith.net.au> <199709042256.XAA26318@awfulhak.demon.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19970905091954.07644>