Subject: Re: Serial port issues on Sun4/260
To: Chris Torek <jaywon!BSDI.COM!torek@life.ai.mit.edu>
From: David Gilbert <pci!jaywon!dgilbert@life.ai.mit.edu>
List: port-sparc
Date: 01/17/1996 21:04:49
>>>>> "Chris" == Chris Torek <torek@BSDI.COM> writes:

>> The Zilog chips that are used in so many of Sun built-in serial
>> ports are not capable of automatic flow control.

Chris> Thus, if you are sending from the zs chip to a modem, the modem
Chris> can drop CTS to get the zs chip to shut up for a while, but the
Chris> zs chip will never wiggle any signal to get the modem to shut
Chris> up.  This means you must never overflow the zs chip's fifo.

	Does this actually happen?  I think that I've noticed the
modem overflow on sending, but this is just based on my casual
observation of modem lights.

	Another thing that's getting to me right now is that the cost
of running the modem seems to be extrodinarily high.  The system lag
is shooting way up when data is flowing --- especially inbound.  Is
there anything that can be done with this driver?

	Anyone with knowledge of this code should be able to test it
--- just loop the two serial ports together and try driving
data... you should loose stuff pretty quickly.  Is it also possible
that we can shrink the overhead in higher priority interupts.

	For one, I'm still seeing significant lag caused by disk
access.  I don't know where to attack this.

	In my experience (speaking to the STREAMS issue), I am not
loosing data in the software buffer since it's size has been
increased.  I am only loosing data from the hardware buffer.  Streams
would not be of help there.

Dave.

-- 
----------------------------------------------------------------------------
|David Gilbert, PCI, Richmond Hill, Ontario.  | Two things can only be     |
|Mail:      dgilbert@pci.on.ca                |  equal if and only if they |
|http://www.pci.on.ca/~dgilbert               |   are precisely opposite.  |
---------------------------------------------------------GLO----------------