Path: utzoo!attcan!utgpu!news-server.csri.toronto.edu!mailrus!cs.utexas.edu!usc!jarthur!nntp-server.caltech.edu!piglet!madler
From: madler@piglet.caltech.edu (Mark Adler)
Newsgroups: comp.sys.next
Subject: Re: 9600 bps serial communications
Message-ID: <1990Aug19.174042.29384@laguna.ccsf.caltech.edu>
Date: 19 Aug 90 17:40:42 GMT
References: <1990Aug17.134755.25158@laguna.ccsf.caltech.edu> <765@venice.SEDD.TRW.COM> <3213@gmdzi.UUCP>
Sender: news@laguna.ccsf.caltech.edu
Organization: California Institute of Technology, Pasadena
Lines: 27


In response to my 9600 bps serial question Paul Verket writes:
>> I think you might have a flow control (or lack of it) problem. I run a
>> modem at 9600 without any problems.

and Jelske Kloppenburg adds:
>> and I run two modems at 19200 without any problems.

Paul is quite correct---this is a case where the calculator does not respond to
xon/xoff flow control.  I posted my question aware of that, with the belief
that my NeXT should be able to keep up with the incredibly low rate of about
1000 characters per second WITHOUT having to slow down the source to less than
that.  It seems clear to me that the hardware is more than capable of that, and
that the serial drivers are not getting the resources they need (physical
memory? cpu?) to do the job.  By the way, this is when the computer is not
engaged in any other activities (at least no others that I've requested, and
I'm the only user).  Also, Kermit transfers from my calculator also experience
an undue number of packet failures and 9600 bps, and I suspect that the cause
is the same: lost characters in long continuous transmissions (in this case,
long is only about 100 or so characters, the length of a packet before Kermit
wants an acknowledge).

I hope that NeXT has tried to improve or is improving the serial drivers for
version 2.0.

Mark Adler
madler@piglet.caltech.edu