Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!olivea!spool.mu.edu!caen!uakari.primate.wisc.edu!aplcen!boingo.med.jhu.edu!haven.umd.edu!ni.umd.edu!sayshell.umd.edu!louie
From: louie@sayshell.umd.edu (Louis A. Mamakos)
Newsgroups: comp.sys.next
Subject: Re: notes for people installing NeXT SLIP
Message-ID: <1991Jun28.211147.1085@ni.umd.edu>
Date: 28 Jun 91 21:11:47 GMT
References: <1991Jun27.071351.17884@milton.u.washington.edu> <1991Jun27.124556.27545@ni.umd.edu> <1991Jun28.143819.2188@percy.rain.com>
Sender: usenet@ni.umd.edu (USENET News System)
Organization: University of Maryland, College Park
Lines: 23
Nntp-Posting-Host: sayshell.umd.edu

In article <1991Jun28.143819.2188@percy.rain.com> nerd@percival.rain.com (Michael Galassi) writes:
>You need hardware flow control any time you don't know the actual
>throughput of your modem.  This will be the case with any v42bis
>(LAPM) or mnp5 modem where the data stream is compressed and the
>compression ratio is a function of the data (i.e. varies over time).

But the issue here is why Mark was experiencing zs0 overrun errors.

The point that I made is that I am running my NeXT serial port at 9600
BPS, and the modem interface at 9600 BPS; the bytes are not going to
come in from the modem any faster than 9600 BPS.  I am not
experiencing overrun errors on input on my machine, and was surprised
that Mark was on his.  MNP or V.42 Compression really doesn't become
an issue here.

I'm still interesting in finding out the circumstances under which
input overruns are occuring.  Were you doing I/O to the OD or floppy
disk at the time?  Playing sounds?  Printing to a NeXT printer?  From
the debugging that I was doing, I noticed that the line discipline
input routine usually gets called with 15 bytes at a time; this gives
plenty of time to do other things in between.

louie